What are the downsides of enabling IPv6 in public-facing services?
Our internal network and internal services are IPv6-enabled, and we're considering enabling IPv6 on public-facing SMTP, DNS and Web servers. All the guides / whitepapers I've read on the subject speak only about the benefits, but I'm sure there are also some downsides. For example:
- Clients with IPv6 via tunnels will have slower access to our services if we enable IPv6.
- Clients with broken IPv6 won't be able to access them at all.
Given that only very small percentage of users have working IPv6, and those that do are usually dual-stack, I'm inclined to think that enabling IPv6 when you don't control both sides of the communication channel is actually a bad idea in 2011.
Is there any research / papers / articles on this subject?
Solution 1:
This article is an overview of a real-life experiment. They claim to have only minor issues.
Maybe it may help a little to configure your DNS servers to send IPv6 answers only on IPv6 interfaces - it will rule-out ISPs that have no IPv6 at all. Not all clients use DNS resolvers provided by their ISP, but most do. Also ISP having IPv6 doesn't mean it's customers having IPv6. Yet it is some improvement.
BTW, if someone is smart enough to setup tunnel, he probably knows what he does and should blame nobody but himself. :)
Edit:
BIND9 Manual:
filter-aaaa-on-v4 This option is only available when BIND 9 is compiled with the --enable-filter- aaaa option on the ”configure” command line. It is intended to help the transition from IPv4 to IPv6 by not giving IPv6 addresses to DNS clients unless they have connections to the IPv6 Internet. This is not recommended unless absolutely necessary.
... This mechanism is applied to authoritative as well as non-authoritative records. ...
Solution 2:
World IPv6 day earlier this year was a test of just this. Results were mixed, but ended up better than feared. The fear was mass brokenness as IPv6-enabled clients in v6 islands couldn't get access to v6 sites, but that ended up not happening nearly as often as had been theorized.
A big take-away is that modern browsers handle the v4/v6 jiggery-pokery in a way that doesn't tick off users nearly as much as it did even two years ago.
Practically, one of the bigger hits for going v6 is that some v6 clients that have v6 tunnels rather than v6 native connections to the internet may end up having their traffic take a longer/slower path to your site than they would on native v4. It'll still work, it'll just load slower.
Solution 3:
The results of World IPv6 Day have shown that this is not a major issue. Someone with an IPv6 tunnel has consciously chosen for that tunnel, so if the tunnel is much slower than IPv4 then this is by choice of the user/sysadmin. The current browsers (Firefox, Chrome, Safari, and even IE in the near future) will use a system called Happy Eyeballs, or something like it. Very rough description of this: When opening an IPv6 connection there is a short timer set (I think Chrome uses 300ms). If that timer expires before the IPv6 connection is made then it will try to set up an IPv4 connection. The user will not notice any potential problems with IPv6.