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