In case other 6to4 clients can't figure out why fp.o is beyond their reach over IPv6, here's some fixing I did to make access to fp.o over 6to4 work for me.
I hadn't had a problem with hanging connections to other IPv6 sites, but I have for fp.o. I heard from Mike M on IRC that others had reduced their MTU to get 6to4 to work with fp.o.
Starting there, my eventual solution was to put the following in the mangle table in ip6tables on my 6to4 router (all one line, of course):
-A FORWARD -o tun6to4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
6to4 has an MTU of 1480 for most people, but 1472 for DSL. Probably something isn't generating an ICMP packet-too-big to send back to fp.o when the link MTU drops. Alternatively the packet could be getting dropped in transit or ignored by fp.o. Of course, clamping MSS in ip6tables only works for TCP.
On Tue, 8 Sep 2009, Allen Kistler wrote:
In case other 6to4 clients can't figure out why fp.o is beyond their reach over IPv6, here's some fixing I did to make access to fp.o over 6to4 work for me.
I hadn't had a problem with hanging connections to other IPv6 sites, but I have for fp.o. I heard from Mike M on IRC that others had reduced their MTU to get 6to4 to work with fp.o.
Starting there, my eventual solution was to put the following in the mangle table in ip6tables on my 6to4 router (all one line, of course):
-A FORWARD -o tun6to4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
6to4 has an MTU of 1480 for most people, but 1472 for DSL. Probably something isn't generating an ICMP packet-too-big to send back to fp.o when the link MTU drops. Alternatively the packet could be getting dropped in transit or ignored by fp.o. Of course, clamping MSS in ip6tables only works for TCP.
ipv6 has caused a lot of problems for certain people, very non-obvious, takes several hours to fix problems. I wonder if there's anything more we can do on our end.
-Mike
We could instead advertise www.ipv6.fp.o and make people choose to use v6 or not. Google does this today for exactly these reasons (failures elsewhere in the network we can't control). Kind of defeats the purpose though.
-- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux
-----Original Message----- From: Mike McGrath mmcgrath@redhat.com
Date: Wed, 9 Sep 2009 08:20:34 To: Fedora Infrastructurefedora-infrastructure-list@redhat.com Subject: Re: fp.o content via IPv6
On Tue, 8 Sep 2009, Allen Kistler wrote:
In case other 6to4 clients can't figure out why fp.o is beyond their reach over IPv6, here's some fixing I did to make access to fp.o over 6to4 work for me.
I hadn't had a problem with hanging connections to other IPv6 sites, but I have for fp.o. I heard from Mike M on IRC that others had reduced their MTU to get 6to4 to work with fp.o.
Starting there, my eventual solution was to put the following in the mangle table in ip6tables on my 6to4 router (all one line, of course):
-A FORWARD -o tun6to4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
6to4 has an MTU of 1480 for most people, but 1472 for DSL. Probably something isn't generating an ICMP packet-too-big to send back to fp.o when the link MTU drops. Alternatively the packet could be getting dropped in transit or ignored by fp.o. Of course, clamping MSS in ip6tables only works for TCP.
ipv6 has caused a lot of problems for certain people, very non-obvious, takes several hours to fix problems. I wonder if there's anything more we can do on our end.
-Mike
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Wed, 9 Sep 2009, Matt Domsch wrote:
We could instead advertise www.ipv6.fp.o and make people choose to use v6 or not. Google does this today for exactly these reasons (failures elsewhere in the network we can't control). Kind of defeats the purpose though.
Why not do this and continue working on ipv6 on the rest of the systems?
-sv
On Wed, Sep 9, 2009 at 7:48 AM, Seth Vidalskvidal@fedoraproject.org wrote:
On Wed, 9 Sep 2009, Matt Domsch wrote:
We could instead advertise www.ipv6.fp.o and make people choose to use v6 or not. Google does this today for exactly these reasons (failures elsewhere in the network we can't control). Kind of defeats the purpose though.
Why not do this and continue working on ipv6 on the rest of the systems?
+1. Personally I would say why work on another solution, but I can only get IPV6 via tunnels of tunnels :).
On 09/09/2009 09:48 AM, Seth Vidal wrote:
On Wed, 9 Sep 2009, Matt Domsch wrote:
We could instead advertise www.ipv6.fp.o and make people choose to use v6 or not. Google does this today for exactly these reasons (failures elsewhere in the network we can't control). Kind of defeats the purpose though.
Why not do this and continue working on ipv6 on the rest of the systems?
"rest of the systems" == rest of the world. could take a while :)
This is precisely IPv6's catch-22: if providers don't implement IPv6, then end user networks won't get fixed. If end user networks don't get fixed, providers won't implement IPv6.
The hosts that require an explicit hostname (ipv6.google.com) tend to get used very rarely, and are poorly integrated into the existing site.
There tend to be three main policy choices:
1) Work through the problems. The ideal, and also the most difficult. The most irritating to end users.
2) Wikimedia approach: deploy IPv6 as first class citizen for all engineer/admin services, where presumably the end user has some knowledge when delays or strange errors appear. wait a bit to deploy IPv6 on main, public-facing, Windows-user-using sites.
3) Google DNS approach: Whitelist networks that are IPv6-safe: Using a feature such as BIND views, return AAAA records, or not, depending on whether the querying system is in the whitelist.
A nice approach and OK for google, but IMO probably too much trouble and manual labor for fp.o. An alternate approach, possibly viable for fp.o, could be to blacklist (== no AAAA records returned in DNS) networks that are terminally broken.
If people wanted to pursue alt#3, I'm pretty sure BIND views will do the trick... they worked for me in the past, delivering two different versions of a zone depending on whether the querying party was "external" or "internal" to the network on which I deployed that config. http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html
Jeff
On Wed, 9 Sep 2009, Jeff Garzik wrote:
On 09/09/2009 09:48 AM, Seth Vidal wrote:
On Wed, 9 Sep 2009, Matt Domsch wrote:
We could instead advertise www.ipv6.fp.o and make people choose to use v6 or not. Google does this today for exactly these reasons (failures elsewhere in the network we can't control). Kind of defeats the purpose though.
Why not do this and continue working on ipv6 on the rest of the systems?
"rest of the systems" == rest of the world. could take a while :)
This is precisely IPv6's catch-22: if providers don't implement IPv6, then end user networks won't get fixed. If end user networks don't get fixed, providers won't implement IPv6.
In fairness IPv6 is sort of a second class citizen atm. Between me, domsch and the volunteers we've had, several hours of time in the last week have been spent debugging connectivity issues wrt ipv6.
-Mike
On Tue, 08 Sep 2009, Allen Kistler wrote:
In case other 6to4 clients can't figure out why fp.o is beyond their reach over IPv6, here's some fixing I did to make access to fp.o over 6to4 work for me.
I hadn't had a problem with hanging connections to other IPv6 sites, but I have for fp.o. I heard from Mike M on IRC that others had reduced their MTU to get 6to4 to work with fp.o.
Starting there, my eventual solution was to put the following in the mangle table in ip6tables on my 6to4 router (all one line, of course):
-A FORWARD -o tun6to4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
6to4 has an MTU of 1480 for most people, but 1472 for DSL. Probably something isn't generating an ICMP packet-too-big to send back to fp.o when the link MTU drops. Alternatively the packet could be getting dropped in transit or ignored by fp.o. Of course, clamping MSS in ip6tables only works for TCP.
I also have 6to4 setup on my home machine. I'm no IPv6 expert (or networking expert, really), but I believe two things should be happening here:
1. the packet too big ICMP message should be coming from your tunnel box 2. the MSS and path MTU should already be set even before it gets to this point, in the router advertisement messages.
I suspect that since you have a smaller MTU than default, changing the MTU on your tunnel interface should solve the #1 problem (ip -6 link set dev tun6to4 mtu 1472)
Changing your radvd.conf (if you're using radvd) to have "AdvLinkMTU 1472;" should fix #2.
To verify the changes took effect, you can look for the router advertisement message, seen via "tcpdump -nvs 1500 ip6":
16:18:48.435516 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::200:ff:fe00:0 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64 ... mtu option (5), length 8 (1): 1480
You can see this in "ip -6 route | grep default" in a client box:
default via fe80::200:ff:fe00:0 dev peth2 proto kernel metric 1024 expires 0sec mtu 1480 advmss 1420 hoplimit 64
(I should mention that curl over my 6to4 tunnel works fine with a mtu of 1480 getting the fedoraproject front page)
[I apologize for sending so many messages on this topic, this probably belongs on a different mailing list]
- the packet too big ICMP message should be coming from your tunnel box
I talked this over with a friend who knows more about networking, and he pointed out that I had this point backwards. What I said is only true if you're uploading. When you're getting the web page (downloading), the ICMP fragmentation needed message (from the DSL provider's termination router) gets sent to the 6to4 tunnel endpoint (the publicly run end), which probably just throws it away. So the webserver never gets a notice that its packets are being dropped.
That said, the various MSS fixes (point #2 and the origional poster's iptables command) avoid the problem for TCP.
On Thu, Sep 10, 2009 at 05:16:23AM +0000, Daniel Drown wrote:
That said, the various MSS fixes (point #2 and the origional poster's iptables command) avoid the problem for TCP.
rhel5, which is what we're running in production, has a kernel old enough that it doesn't have the iptables --clamp-mss-to-pmtu capability for ipv6.
We've had over 5000 successful connections using ipv6 this week, and about 5 _reported_ failures. In the same time, we've had millions of successful v4 connections. I'm inclined to believe the failures, while annoying, are still few and far between compared with the rest of our traffic. I'm not quite ready to turn off ipv6 again, or switch to forcing "knowledgable" users to use www.ipv6.fp.o, as it would drop our IPv6 userbase to effectively zero.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm having no trouble using IPv6, with a AYIYA tunnel from SixXS.
I can SSH to proxy4 over IPv6, and visit the site with IPv6.
I agree with Matt that we shouldn't just right now switch off IPv6 or make it only restricted to www.ipv6.fp.o. If we did that, the other domains wouldn't get any IPv6 because something like https://www.ipv6.admin.fedoraproject.org/mirrormanager/ is a bit too long and would cause a huge mess in the zone file.
We should wait and see until Saturday or Sunday and see if we hear any more issues before taking big actions like disabling IPv6 or acting like Google about IPv6 (subdomain for IPv6).
Darren VanBuren onekopaka@gmail.com ==================== http://theoks.net/
On Sep 9, 2009, at 10:29 PM, Matt Domsch wrote:
On Thu, Sep 10, 2009 at 05:16:23AM +0000, Daniel Drown wrote:
That said, the various MSS fixes (point #2 and the origional poster's iptables command) avoid the problem for TCP.
rhel5, which is what we're running in production, has a kernel old enough that it doesn't have the iptables --clamp-mss-to-pmtu capability for ipv6.
We've had over 5000 successful connections using ipv6 this week, and about 5 _reported_ failures. In the same time, we've had millions of successful v4 connections. I'm inclined to believe the failures, while annoying, are still few and far between compared with the rest of our traffic. I'm not quite ready to turn off ipv6 again, or switch to forcing "knowledgable" users to use www.ipv6.fp.o, as it would drop our IPv6 userbase to effectively zero.
-- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
infrastructure@lists.fedoraproject.org
-
Allen Kistler -
Daniel Drown -
Darren VanBuren -
Jeff Garzik -
Matt Domsch -
Matt Domsch
-
Mike McGrath -
Seth Vidal -
Stephen John Smoogen