On Tue, Feb 3, 2015 at 3:40 PM, Simon Allard

wrote:

A fair number if you include customers who are tunnelled in PPPoE and have their MTU set to 1492.

I'm a bit of a newbie on this side of things so apologies if this is a stupid question. So, with a situation like what Simon describes above what tends to fix the issue of the (generally) default TCP MSS of 1460 not fitting inside of this. Does path MTU discovery tend to fix this, or does change TCP MSS on a CPE (or BNG?) tend to fix it instead? Cheers Dave

On 2015-02-03 14:40, Dave Mill wrote:

So, with a situation like what Simon describes above what tends to fix the issue of the (generally) default TCP MSS of 1460 not fitting inside of this. Does path MTU discovery tend to fix this, or does change TCP MSS on a CPE (or BNG?) tend to fix it instead?

Two reasons for a content provider to force a small TCP MSS: (1) Working around broken networks that filter ICMPv6 Packet Too Big messages (2) One less RTT than waiting on an ICMPv6 PTB I don't condone any of the above reasons.

On 3/02/2015 18:46, Mark Foster wrote:

I realise there is this ideal world where we don't have to transit networks beyond our control, but why is (1) not condoned in your view?

Because history has shown that the "be liberal in what you accept, conservative in what you emit" mantra is actually really bad at motivating others to fix their broken stuff.

On 04/02/2015 10:55, Jasper Bryant-Greene wrote:

...

On 4/02/2015, at 10:33 am, Jeremy Visser wrote:

...

On 3/02/2015 18:46, Mark Foster wrote: I realise there is this ideal world where we don't have to transit networks beyond our control, but why is (1) not condoned in your view?

Because history has shown that the "be liberal in what you accept, conservative in what you emit" mantra is actually really bad at motivating others to fix their broken stuff.

OTOH, it's pretty good at keeping networks working.

And, if we're getting philosophical, it's morally neutral: it doesn't matter whether the broken stuff is intentional or human error, and it doesn't needlessly punish an innocent user. But there is one case where the mantra is dangerous: it tells you not to implement BCP 38. In terms of IPv6 MTU size, a server site that limits its outbound MTU to 1280, but accepts larger inbound packets, is just playing safe. Brian

On 04/02/2015 05:18, Matthew Luckie wrote:

...

Two reasons for a content provider to force a small TCP MSS:

(1) Working around broken networks that filter ICMPv6 Packet Too Big messages

How many networks on the path back to a content provider filter PTB messages, apart from the content provider itself? I'd have thought a transit network filtering a PTB would be extremely rare.

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. Brian

On 04/02/2015 16:40, Don Stokes wrote:

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)?

Basically, I think the answer is yes. There's RFC 4890 on ICMPv6 filtering but I'm not sure that all implementations and/or deployments are following it yet. There may still be bad configuration advice floating around for some products. The situation is also bad for IPv6 extension headers, and RFC 7045 is too new to have had much effect yet. Brian

On 04/02/2015 18:16, Tom Paseka wrote:

looping this all back, we've just posted: https://blog.cloudflare.com/path-mtu-discovery-in-pracrice/

I have tried accessing the url but it clearly states "The page you are looking for cannot be found.". Eliezer