Please understand, I'm a big IPv6 advocate. I use it on all my own machines. It is deployed on some local networks I use. There is extraordinarily strong IPv6 expertise here. The guy who maintains our network (David Malone) literally wrote the book on IPv6 network administration. The host ftp.ie.debian.org is centrally hosted at heanet.ie, which is a centre for IPv6 deployment and expertise, a sixxs tunnel broker, which extends direct IPv6 service to universities here, etc.
> This kind of thing tends to work best when both sides know their > stuff. Here they do. They know their stuff here too. Maybe someone in the middle is messing things up. Maybe something is temporarily or accidentally configured in a suboptimal fashion, somewhere. Maybe some router had a hiccup and its IPv6 stuff went a little sour until someone notices and tickles it. Whatever. The thing is, there is much less pressure to keep the *global* IPv6 network tuned, and sometimes it takes a while for problems to be recognized and repaired. This is not due to malice or deliberate neglect. It is due to the fact that IPv4 problems cause immediate serious blowback, while IPv6 problems do not. It is a chicken-and-egg problem, and ranting about how nice it would be if everyone deployed IPv6 and gave it a lot of tender loving care does not help. > None of this is caused by IPv6, it's just sucky networking. OBVIOUSLY! But for the moment, IPv4 problems get recognized and repaired rapidly, and IPv6 problems do not. Why? Chicken-and-egg. No one relies on IPv6 because it is unreliable. Why is it unreliable? Because no one relies on it! > ... Google is fully IPv6-enabled Sort of. I've used http://ipv6.google.com/. But Google has IPv6 disabled at the DNS level for www.google.com, albeit perhaps only for some requests. Watch: $ curl --ipv4 --silent --show-error http://www.google.com | wc -c 218 $ curl --ipv6 --silent --show-error http://www.google.com | wc -c curl: (6) Couldn't resolve host 'www.google.com' Why? Because enabling it would break or degrade performance on many IPv6-enabled clients, which would blithely prefer IPv6 and get sporadic service. If the clients defaulted to preferring IPv4, then this wouldn't be a problem, and Google could put IPv6 addresses into all DNS records, without risk. That's what I'd like to see happen. It won't until clients default to "prefer IPv4." So Google is your IPv6 poster child? Watch! $ ping -c2 www.google.com PING www.l.google.com (216.239.59.104) 56(84) bytes of data. 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=1 ttl=237 time=2.57 ms 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=2 ttl=237 time=2.25 ms $ ping6 -c2 ipv6.google.com PING ipv6.google.com(fx-in-x68.google.com) 56 data bytes --- ipv6.google.com ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms $ timeout 60 telnet ipv6.google.com http Trying 2001:4860:a003::68... Timeout: aborting command ``telnet'' with signal 9 Killed > I think you have no solid technical arguments against IPv6. I want to see IPv6 deployed. I'm not making a technical argument against IPv6. What I'm arguing against is making it hard for people to deploy IPv6 by setting up defaults that cause enabling IPv6 to break things! Problems and risks induced by "prefer IPv6" are delaying full deployment on both "client" networks and on servers. What I'm arguing against is default configurations that make it easy for enabling IPv6 to break things. If we instead deliberately make it *hard* for enabling IPv6 to break things, then people will actually enable IPv6. Which is what I want! > ... it's been *ages* since I've had to deal with a v6-induced issue. You are lucky; that is quite unusual. But wait: you get much degraded access to ftp.ie.debian.org over IPv6 than over IPv4. So you *do* have an v6-induced issue: degraded service to that particular host. --Barak. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org