On 2011-04-20 13:05, Dan Wing wrote: >> -----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.
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. 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
