I’ve been running IPv6 on my home network for a while now. Since my provider doesn’t provide native IPv6 all external traffic occurs via 6to4.
Last week I setup 6to4 on my server which lives inside a local ISP’s colocation facilities. This provided IPv6 connectivity between my home network and the server. The only changes required were a couple of ACL modifications and configuring sendmail to listen on an IPv6 socket. Sadly I did discover that ejabberd cannot listen to both IPv4 and IPv6 addresses on the same port.
For a little experiment I decided to add an AAAA record to www.coverfire.com and see how much IPv6 traffic arrives. I know that the IPv6 Internet is vastly smaller than the IPv4 Internet so I didn’t expect a huge amount of traffic. In order to analyze whatever traffic arrived I captured all IPv6 port 80 traffic for the duration of the experiment.
The results of this experiment were disappointing. Over about 1.5 days there were only five IPv6 hosts which visited the site. One of the five hosts wasn’t even able to establish a TCP connection. From the capture file it looks like the ACKs from my server never arrived at the remote host. Of the five addresses, four were 6to4 addresses. I found this a little surprising. Also interesting is the fact that there was no traffic from Teredo hosts.
A more interesting question is whether or not adding an AAAA record has caused troubles for people visiting the site via IPv4. See this article for one of the reasons why AAAA records can cause IPv4 users trouble.
For anyone who is interested I have uploaded the quick Python hack I used to analyze the capture file.
I would be interested to see how more reliable the service would have been if you’d got native v6 for your server..
If you simply add a AAAA record (in addition to the A record) many hosts that are using an automatic tunnel will actually prefer the “A” response.
IMHO, a more interesting experiment is to use a little javascript & .jpg magic to force visitors to transparently (to them) load an IPv4-only pic, an IPv6-only pic and an IPv4+IPv6 pic … get a better idea of who is IPv6 capable vs. who is using IPv6 to actually get to you.
Another interesting thing would be to monitor the DNS requests coming in, watch how many visitors request AAAA’s …
/TJ
PS – while my employer’s site is certainly not a “big volume” site, we have been dual-stacked for almost 3 years now …
5 ipv6 out of how many ips in total?
TJ,
Your little Javascript/JPG experiment is a good idea. I may try that.
I don’t have the numbers for during my experiment but in general there is a surprising amount of AAAA queries. I did some analysis of DNS traffic on a small ISP’s main recursive server last year (http://www.coverfire.com/archives/2008/07/28/more-fun-with-dns-packet-captures/).
Corsac,
I didn’t capture IPv4 traffic so the best I can do is look at the Apache logs right now. There were roughly 180 unique hosts visit during the experiment.
Andy,
I’ve been thinking of trying this again with a Sixxs tunnel instead of 6to4. Hopefully I get around to that :)
I would be interested to see how more reliable the service would have been if you’d got native v6 for your server..
Pingback: Five Minutes » Blog Archive » Blogv6
I’d just like to point out that if you’re using Linux, telling ejabberd to listen on both IPv4 and IPv6 is pointless, because if you tell it to bind to ::, it includes ::ffff:0.0.0.0, which are the IPv4-compatible addresses. Basically it means it still works with IPv4.
My ejabberd runs set to inet6, not inet, and it still works on IPv4. For more information, see my answer to a related question on Server Fault.
Thanks Jeremy. Do you have an example ejabberd config you could share?
This will hopefully illustrate it clearly enough.