If you know of any issues that customers might encounter during the transition to IPv6, please add a subheading to this page and explain both the problem and how to address it.
«Broken» users unable to access dual-stacked content
A small number of users have some kind of misconfiguration or bug in their internet connection that makes them unable to properly access dual-stacked web sites. More often than not, these users have no problems accessing IPv4-only sites, which causes them to perceive the dual-stacked site as the one having problems.
The existence of these users is unfortunately causing content providers to put off enabling IPv6. For more information, see these presentations by Yahoo (https://sites.google.com/site/ipv6implementors/2010/agenda/07 Fesler Y\!atGIPv6ImpConf.pdf?attredirects=0), Google, and Redpill Linpro.
This section attempts to document the most common causes as to why this happens, and how end users can solve it. It is based on real operational experience from running dual-stacked web sites.
Use of transitional IPv6 connectivity
Transitional IPv6 connectivity (6to4 or Teredo), is usually less reliable than IPv4. For this reason, the end user's web browser should prefer to use IPv4 when attempting to access dual-stacked site.
6to4 router functionality is implemented and often enabled by default in a large number of home gateway products made by several different vendors. It is recommended to disable this functionality whenever possible.
MS Windows automatically enables Teredo and 6to4 whenever possible. The system resolver library will de-prioritize their use, but not all applications use the system resolver library and will therefore end up preferring the less reliable transitional IPv6 connectivity.
Solution: Disable 6to4 and Teredo, by entering the following commands in an Administrator shell:
Internet Connection Sharing
If Internet Connection Sharing is enabled on any interface (it doesn't even have to be connected), the Windows hosts will announce itself as an IPv6 router to the local network. This will in turn cause problems for other operating systems that doesn't de-prioritize transitional IPv6 connectivity, notably Mac OS X (see below).
Solution: Disable Internet Connection Sharing whenever unused, and disable 6to4 and Teredo as described above.
Opera web browser
The Opera web browser uses its own resolver library, and would in versions earlier than 10.50 (on Microsoft Windows) and 10.63 (on Mac OS X and Linux) prefer transitional IPv6 connectivity above IPv4.
Solution: Upgrade Opera to the latest available version.
Mac OS X
Mac OS X, in versions earlier than 10.6.5, do not de-prioritize 6to4.
Solution: Upgrade Mac OS X to the latest available version.
Versions predating 10.6 «Snow Leopard»
At the time of writing, the patch that de-prioritizes 6to4 is only available for the «Snow Leopard» series (10.6.x). Avoiding 6to4 entirely is the best solution, but might not always be possible or feasible when another device in the network is announcing itself as a 6to4 router.
Solution: Disable IPv6 completely in the operating system: System Preferences -> Network -> Advanced -> TCP/IP -> Configure IPv6 -> Off.
The GNU C Library will de-prefer transitional IPv6 connectivity if the local IPv4 address is not a private one (RFC 1918), due to a strict interpretation of RFC 3484 (see SW#11438).
Alternative solution: Add the following lines to the file /etc/gai.conf (create it if it doesn't exist):
Earlier versions of Android preferred transitional IPv6 connectivity above IPv4.
Solution: Upgrade Android to version 2.2 Froyo or later
Home gateways and broadband routers
Several D-Link models from the «DIR» and «DSL» series, do not correctly forward DNS responses for hostnames with both A and AAAA records published. What it does is to stuff the first 32 bits of the AAAA record into the A record that's being returned to the end user's computer. In other words, getipv6.info will incorrectly resolve to 220.127.116.11
Firewall Config Issue
Especially if you have users on Vista.
It does this IPv6 tunnelling thing that on the surface
appears really cool. When you try and talk IPv6 to
something other than link-local: (in order)
- If you have a non-RFC1918 (ie. 'public') address, it fires up 6to4.
- If you have an RFC1918 address, it fires up Teredo.
Seems cool in theory, and you'd think that it would really help global IPv6 deployment - I'm sure that's how it was intended, and I applaud MS for taking a first step. But in practice, however, this has essentially halted any IPv6 /content/ deployment that people want to do, as user experience is destroyed.
You can help, though - here's the problem:
6to4 uses protocol 41 over IP. This doesn't go through NAT, or stateful firewalls (generally). Much like GRE.
Because of this, if you're a enterprise-esque network operator who runs
non-RFC1918 addresses internally and do NAT, or you do stateful firewalling, PLEASE, run a 6to4 relay on 18.104.22.168 internally, but return
ICMPv6 unreachable/admin denied/whatever to anything that tries to send data out through it. Better yet, tell your firewall vendor to allow you to inspect the contents of 6to4 packets, and optionally run your own 6to4 relay, so outgoing traffic is fast.
Even if you don't want to deploy IPv6 for some time, do this at the very least RIGHT NOW, or you're preventing those of us who want to deploy AAAA records alongside our A records from doing so. If you need configs for <vendor/OS B/C/J/L>, post a message to the NANOG list and I'll write some templates.
I see this sort of IPv4 network quite commonly at universities, where students take their personal laptops and throw them on the campus 802.11 network. While disabling the various IPv6 things in Vista at an enterprise policy level might work for some networks, it doesn't for for a university with many external machines visiting. So, if you're a university with a network like this (ie. most universities here in NZ, for example), please spend a day or two to fix this problem in your network - or better yet, do a full IPv6 deployment.
Increased Latency to your IPv6 Content
If you do deploy an IPv6 network for your content, set up a Teredo relay, and point 2001::/32 at it. Your viewers/users will automatically use this relay when accessing your content, and their traffic to you will be over IPv4, all they way from their PC to your network - so, equivalent performance as IPv4. Note that I say relay here, not server.
Mozilla.org are doing this for example. Cue Matthew Zeier.
Check out Enabling IPv6 on a Mail Server.
Unfortunately, not all Domain Registrars are providing IPv6 Glue yet
It may be tough to get IPv6 AAAA records for your nameservers into the DNS Glue records, depending on your registrar.
Check out DNS Registrars IPv6 Support Status, let's build a list of who does and does not.