Dan, >> 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.
Thanks, this was helpful. I suspect that native (dual stack) end-to-end probably works as well as IPv4, but see that the various tunneling solutions don't. Bob > > -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 >>> [email protected] >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
