nanog mailing list archives

Re: IPv6 day and tunnels


From: Mark Andrews <marka () isc org>
Date: Mon, 04 Jun 2012 13:14:15 +1000


In message <4FCC11B2.2090405 () 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 () isc org


Current thread: