IPv6 is going to be a fruitful source of configuration mistakes

July 30, 2012

I recently ran into an odd problem. If I visited a website with my regular Firefox session, it came up fine and normally, but if I tried to visit it in my testing Firefox I instead got a generic advertising page for a VPS provider (the VPS provider that the website was hosted on, in fact). Testing now shows that I would have gotten the same results with Chrome or lynx, but that if I had tried this from work instead of from home, everything would have seen the real website.

Of course, you already know the punchline here because I put it in the title of this entry. The website has both an IPv4 and an IPv6 address; the IPv4 address worked while the IPv6 address got the generic VPS ad page. I presume that this is inadvertent and happened because something, somewhere, was not told that this IPv6 address should be recognized as being associated with the website. (There are plausible Apache VirtualHost mistakes that would do this, for example.)

What is interesting in a somewhat depressing way is how odd and unclear the symptoms were. I'm technically inclined and my own sysadmin, so it only took a little bit of head scratching before the penny dropped (and I verified my suspicions). Now imagine this happening (over and over again) to some of your users. Won't that be a fun problem report?

This is not a new problem, but this is the first time I've seen it caused by what was clearly a configuration slipup instead of things like routing problems. I suspect that this sort of thing is going to happen over and over again as we see more and more IPv6 usage. In a sense, configuring things for IPv6 has been (and to a large part still is) something that wasn't necessary for the system to work .

Sidebar: Why my symptoms were what they were

My home machine has a real IPv6 connection, but none of the machines at work do (my office workstation has a 6to4 IPv6 address, which evidently isn't good enough to count as an IPv6 address for this VPS provider). My testing Firefox, Chrome, and lynx all are IPv6 enabled and prefer IPv6 addresses over IPv4 ones, but my regular Firefox session is not (because it is proxied through an IPv4 only ad-stripping proxy).


Comments on this page:

From 194.168.32.194 at 2012-08-01 04:12:31:

I came across this problem on a small scale the other day. We have a Puppet config that automatically restricts access to Apache /server-status to known management IPs and 'localhost'. On a RHEL 6 system, I discovered that "apachectl status" didn't work. Turned out that RHEL 6 has IPv6 configured by default, that the apachectl call to /server-status (using elinks) goes over IPv6 loopback by default and that without the IPv6 'localhost6' address in the ACL, it gets blocked.

- Ade
Written on 30 July 2012.
« The periodic strangeness of idiomatic Python
Ruminations on the future of ZFS »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jul 30 00:02:37 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.