> -----Original Message----- > From: Bob Hinden [mailto:bob.hin...@gmail.com] > Sent: Tuesday, April 19, 2011 4:20 PM > To: Dan Wing > Cc: Bob Hinden; 'Philip Homburg'; 'David Woodhouse'; ipv6@ietf.org > Subject: Re: PMTU blackhole detection > > Dan, > > > >> On the other hand, the difference between 1500 and 1280 is so small, > I > >> wonder if breaking things just because you want to send packets > >> at 1500 bytes makes a lot of sense. > >> > >> One other thing, if this makes the IPv6 experience worse than > industry > >> standard for IPv4, then maybe it is also not a good idea. > > > > The IPv6 headers are 20 bytes bigger than IPv4 headers, so a fairer > > comparison is 1500 against 1260 (1260=1280-20). That is, with a 1500 > > byte MTU with IPv4, the effective data payload is 1480 bytes > (assuming > > no IP options, which is a reasonable assumption with IPv4); with a > > 1280 byte MTU with IPv6, the effective data payload is 1240 bytes > > (assuming no IPv6 extensions). That's a 16.2% reduction in data > > payload size from IPv4 to IPv6, with a commensurate increase in > > number of packets to send the same data (assuming MTU-sized packets). > > I am a little confused by the comparisons being made in this thread. > > There is no guarantee that an 1500 IPv4 packet won't be fragmented, so > a path that drops ICMPv4 packet too big messages will cause PMTU to > fail. The 1280 number is the size of an MTU that IPv6 traffic can go > on with out a need to be fragmented (that is, no PMTU issue). > > If a path can deliver 1500 byte IPv4 packets, it can also deliver 1500 > byte IPv6 packets. The resulting payloads will be 20 byte less for > IPv6, but that less than a 2% difference in payload size. > > I doubt middle boxes are going to let ICMPv4 packet too big messages > through, and drop ICMPv6 packet too big messages. > > Am I missing something here?
Yes. Over the years, the IETF's own website has suffered two outages (and perhaps three) that were attributed to IPv6 PMTUD failures. To my knowledge, it has suffered no outages attributed to IPv4 PMTUD failures. Google runs its IPv6-facing properties using a 1280 byte MTU, likely to avoid adding IPv6 PMTUD failures to the reasons that IPv6 might provide a worse user experience than IPv4. Afterall, there is no need to try to resolve all problems at once while we're getting IPv6 off the ground. So, while I agree that 1500 should work equally well for both IPv4 and IPv6, it seems that for whatever combination of reasons, it works less well on IPv6 than IPv4. This is perhaps user error (configuration mistakes on firewalls or ACLs), more common use of IPv6-over-IPv4 tunnels than IPv4-over-IPv4 tunnels, bugs in vendor equipment, or something else. -d > Bob > > > > > > > This isn't quite "packets per second will increase by 16.2%", though, > > as of course not all packets are 'full'. But there will be a pps > > increase. > > > > -d > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
