Bug#268631: force preference of IPv4 over IPv6
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.
Reply to: