On 04/02/15 08:25, Brian E Carpenter wrote:
But throttling ICMP(v6) to avoid primitive DOS attacks might not be so rare, and that would lead to random loss of PTBs. Anyway, it's pretty easy to determine that PTBs are getting dropped, but pretty hard to find out exactly where it happens. tom+lists(a)cloudflare.com wrote: Unfortunately, yes. You'll see some other very large web properties doing the same. Too many tunnels, ICMP isn't reliable (nor does it work happily with some load balancing techniques or anycast).
Surely these would also be a problem in IPv4-land where TCP with PMTU discovery is the norm? A quick TCP test to Cloudflare shows that TCP/IPv4 packets are coming from them with the DF bit set in the IP header (per normal PMTU discovery), which elicits pretty much exactly the same MTU behaviour in IPv4 as in IPv6. I don't think I've seen significant PMTU problems in IPv4, despite the prevalence of PPP-over-whatever with not-quite-1500 MTUs (ugh!), for a decade or so. These days, firewall folk mostly know not to filter PTBs, or more accurately, have NATs and stateful firewalls that know how to pass ICMP unreachables based on connection state, and do so as a matter of course. Filtering aside, PMTU discovery is pretty robust for most TCP applications, since every oversize retry can generate a PTB, and the PMTU is highly cache-able and the effect of a stale or over-aggregated PMTU cache entry is benign. Yet this isn't the first example I've seen of minimum MTUs in use in IPv6 to avoid PTBs. Granted, DNS applications where a PMTU re-send effectively doubles the length of the transaction (and requires a bunch more state to be kept by the server) is a slightly different case to TCP, but I can't see why this should be an issue in TCP over IPv6 when it isn't in IPv4. Do we have yet another example of IPv6 implementers making all the same mistakes they made with IPv4 (and a few more besides)? -- don