> -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Tuesday, April 19, 2011 8:01 PM > To: Dan Wing > Cc: 'Bob Hinden'; [email protected] > Subject: Re: PMTU blackhole detection > > On 2011-04-20 13:05, Dan Wing wrote: > >> -----Original Message----- > >> From: Bob Hinden [mailto:[email protected]] > >> Sent: Tuesday, April 19, 2011 4:20 PM > >> To: Dan Wing > >> Cc: Bob Hinden; 'Philip Homburg'; 'David Woodhouse'; [email protected] > >> 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. > > Specifically, I discovered while I was a 6to4 user that some > sites, but not others, could successfully complete a SYN/ACK > exchange (where all the packets were well below 1280 bytes) but > never replied to the first HTTP GET command. iirc, it seemed > that the server would set its TCP MSS to 1440, regardless of the > client setting 1220, and presumably the server sent 1500 byte > IPv6 packets that never arrived. I never could debug it.
Ben Stasiewicz has done some research on IPv6 MTU problems, http://ripe60.ripe.net/presentations/Stasiewicz-Measurements_of_IPv6_Path_MTU_Discovery_Behaviour.pdf -d > In this situation a 6to4 relay (like any other tunnel end point) > should behave according to section 3.2 of RFC 4213. That's quite > a complicated section and I suppose there may be buggy > implementations, even in the absence of ICMP filtering. > > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
