IPv6 day and tunnels

Mon Jun 4 03:14:15 UTC 2012

In message <4FCC11B2.2090405 at ttec.com>, Joe Maimon writes:
> Well, IPv6 day isnt here yet, and my first casualty is the browser on 
> the wife's machine, firefox now configured to not query AAAA.
> 
> Now www.facebook.com loads again.
> 
> Looks like a tunnel mtu issue. I have not as of yet traced the 
> definitive culprit, who is (not) sending ICMP too big, who is (not) 
> receiving them, etc.
> 
> www.arin.net works and worked for years. www.facebook.com stopped June 1.
> 
> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
> 
> Or was the fix incorporating the breakage into the basic design?
> 
> In IPv4 I can make tunneling just work nearly all of the time. So I have 
> to munge a tcp mss header, or clear a df-bit, or fragment the 
> encapsulated packet when all else fails, but at least the tools are 
> there. And on the host, /proc/sys/net
> 
> In IPv6, it seems my options are a total throwback, with the best one 
> turning the sucker off. Nobody (on that station) needs it anyways.
> 
> Joe

If facebook isn't working for you over a tunnel, and other sites are,
complain to the site.

If they don't let through ICMPv6 PTB then the site needs to add
"route change -inet6 change -mtu 1280" or equivalent to every box.

This isn't rocket science.  If you choose to break PMTU discovery
then you can take the necessary steps to avoid requiring that PMTU
Discovery works.  This is practical for IPv6.  For IPv4 it is
impractical to do the same.

The IPv6 Advanced Socket API even has controls so that you can make
the PMTUD choice on a per socket basis.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org