Comments on: Using IPv6 by default with wget http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/ Samuel Tardieu's dual-sided blog Sun, 06 Jul 2008 06:56:56 +0000 http://wordpress.org/?v=2.3.3 By: Pierre B. http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/#comment-73707 Pierre B. Wed, 31 Oct 2007 23:00:07 +0000 http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/#comment-73707 It's not quite a question of having global IPv6 address, it's a question of having the machine configured with a IPv6 route to the destination. If connect(2) immediately returns EHOSTUNREACH or ENETUNREACH, there's absolutely no problem. That's what happens on FreeBSD. I don't know about exactly what Linux does. I do agree with Sam, the default wget behaviour is a bad design choice. A few days ago I tried to update some FreeBSD ports from my IPv6-connected FreeBSD machine, and seeing fetch(1) timeout after successfully establishing IPv6 ftp connections gave me a clue that my IPv6 filters were not set correctly (they didn't let "icmp6 packet too big" through, which prevented correct MTU negotiation; MTU was at 1280 instead of 1500 because I'm connected through a tunnel). If fetch had used IPv4 by default like wget does, I would never have seen this. It’s not quite a question of having global IPv6 address, it’s a question of having the machine configured with a IPv6 route to the destination. If connect(2) immediately returns EHOSTUNREACH or ENETUNREACH, there’s absolutely no problem. That’s what happens on FreeBSD. I don’t know about exactly what Linux does. I do agree with Sam, the default wget behaviour is a bad design choice.

A few days ago I tried to update some FreeBSD ports from my IPv6-connected FreeBSD machine, and seeing fetch(1) timeout after successfully establishing IPv6 ftp connections gave me a clue that my IPv6 filters were not set correctly (they didn’t let “icmp6 packet too big” through, which prevented correct MTU negotiation; MTU was at 1280 instead of 1500 because I’m connected through a tunnel). If fetch had used IPv4 by default like wget does, I would never have seen this.

]]> By: Stéphane Bortzmeyer http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/#comment-73685 Stéphane Bortzmeyer Wed, 31 Oct 2007 16:58:56 +0000 http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/#comment-73685 > will try an IPv6 connection if the destination node has an AAAA DNS record Do note that, besides a few obvious cases (no local IPv6 address, only link-local IPv6 addresses, etc), it may be difficult to know if a IPv6 address is reachable or not. You have to try, since there is no global sysctl parameter saying "net.ipv6.use_it=1". PS: and it is not Linux, NetBSD has a similar issue. Practical rule: do not configure global IPv6 addresses if you do not have IPv6 connectivity. > will try an IPv6 connection if the destination node has an AAAA DNS record

Do note that, besides a few obvious cases (no local IPv6 address, only link-local IPv6 addresses, etc), it may be difficult to know if a IPv6 address is reachable or not. You have to try, since there is no global sysctl parameter saying “net.ipv6.use_it=1″.

PS: and it is not Linux, NetBSD has a similar issue.

Practical rule: do not configure global IPv6 addresses if you do not have IPv6 connectivity.

]]> By: Olive http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/#comment-73668 Olive Wed, 31 Oct 2007 13:34:41 +0000 http://www.rfc1149.net/blog/2007/10/31/using-ipv6-by-default-with-wget/#comment-73668 The main reason would be that brain-dead OSes (Linux, for example), will try an IPv6 connection if the destination node has an AAAA DNS record, which will fail in most cases for clients not connected to an IPv6 network (which is still the huge majority of cases). Then you have to wait for the standard TCP timeout in case of a TCP connection, before falling back to IPv4. This gives a bad impression of Linux as having "slow" networking. The main reason would be that brain-dead OSes (Linux, for example), will try an IPv6 connection if the destination node has an AAAA DNS record, which will fail in most cases for clients not connected to an IPv6 network (which is still the huge majority of cases). Then you have to wait for the standard TCP timeout in case of a TCP connection, before falling back to IPv4. This gives a bad impression of Linux as having “slow” networking.

]]>