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. A web site operator can detect these users using JavaScript and potentially warn them about the problem, see Warning broken users with JavaScript.

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. There's also an article about the problem in Wikipedia.

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. This is well documented in I-D.vandevelde-v6ops-harmful-tunnels.

6to4 router functionality is implemented and often enabled by default in a large number of home gateway products made by several different vendors. This is unfortunately in accordance with Microsoft's requirements for Windows-compatible home routers. It is recommended to disable 6to4 functionality whenever possible.

Android

Apple Mac OS X

Mac OS X, in versions earlier than 10.6.5, do not de-prioritize 6to4 compared to IPv4.

Solution: Upgrade Mac OS X to the latest available version.

Versions predating 10.6.x «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.

Alternative solution: Add the following lines to the file /etc/gai.conf (create it if it doesn't exist):

Microsoft Windows

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).

Home gateways and broadband routers

Apple

The AirPort wireless base station (likely also the Time Capsule), will advertise the prefix ::/64 on its LAN interfaces if it is set up with IPv6 mode tunnel while having a private (RFC 1918) address assigned to its WAN interface. As the resulting auto-configured addresses are invalid, hosts on the LAN will suffer dual-stack breakage. The bug was last reported in firmware version 7.4.2, and is confirmed to be fixed in firmware version 7.5.2).

Solution: Upgrade the firmware of the AirPort/Time Capsule to the latest available version (instructions).

AVM

Certain models of the AVM FRITZ!Box is known to have ULA (RFC 4193) functionality based on recommendations from I-D.ietf-v6ops-ipv6-cpe-router revision 07 or earlier. When enabled, this leads to dual-stack problems for all hosts behind the router due to the fact that ULA addresses isn't special-cased by any modern operating system. ULA addresses cannot be used for connectivity to the global IPv6 internet.

Cisco Linksys

The Cisco Linksys E3000 is known to number LAN hosts from the documentation prefix 2001:db8::/32 using DHCPv6, while the WRVS4400N is pre-configured with 2005:123:456:789::/64 for its default DHCPv6 range. Other models that share the same software code might of course also have the same problem. These addresses are bogons and cannot be successfully used for any communication on the IPv6 internet.

Solution: Ensure the routers are operating in IPv4-only mode. On the WRVS4400N, this setting is found under Setup -> IP Versions in its web interface.

D-Link

Several D-Link models from the DIR and DSL series (at least DSL-584T, DSL-G624T, DSL-G664T, DSL-G684T), 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 32.1.5.0 (the 2001:0500: part of the IPv6 address). If the operating system or web browser prefers to use IPv4, it will be unable to connect to the destination.

Italian ISP Wind/Infostrada is reported to have distributed the DSL-G624T to its customer base over a period of several years.

It doesn't happen all the time - it appears to be timing-dependent. Mozilla Firefox browsers are hit particularly bad, due to the fact that it will request AAAA lookups even if the local host does not have an IPv6 address.

Solution: Attempt to upgrade the firmware of the router to the latest version. If that doesn't help, replace the router.

Alternative work-around 1: If the user is using Mozilla Firefox, disable AAAA lookups by setting the value network.dns.disableIPv6 to true in the about:config advanced settings editor.

Alternative work-around 2: Disable IPv6 in the operating system, which will in most cases suppress AAAA lookups.

Bugs in operating system TCP/IP stacks

Apple Mac OS X

Use of IPv6 with only link-local addresses

When attempting to connect to a dual-stacked destination when the system has only link-local IPv6 addresses (but at the same time a default IPv6 route), a 75 second timeout is incurred per AAAA record. IPv6 is preferred over IPv4 in this case due to lack of support for RFC 3484 in Mac OS X's system resolver. A system will be vulnerable to this bug if it has received an ICMPv6 Router Advertisement message that does not contain any Prefix Information Options, for example. Portugese ISP SAPO is known to distribute a CPE to its customers (Pirelli A1000G) that emits such RAs by default.

This will especially affect users of Mozilla Firefox, as it requests AAAA records even though the system does not have any global IPv6 addresses (see bug #614526), and will attempt to connect to the IPv6 addresses in preference to falling back to IPv4. Safari also suffered from this problem up until Mac OS X 10.6.4.

Solution: Identify and disable the source of the ICMPv6 Router Advertisement packets.

Work-around 1: If the user is using Mozilla Firefox, disable AAAA lookups by setting the value network.dns.disableIPv6 to true in the about:config advanced settings editor.

Handling of Router Advertisements with a lifetime of 0

When receiving an Router Advertisement packet with a lifetime of 0, Mac OS X-based hosts will incorrectly install a default route. It appears that a Prefix Information Option must be present in the RA packet for the bug to take effect.

The technique of using a lifetime of 0 to announce an IPv6 router without global connectivity is used by devices conforming to I-D.ietf-v6ops-ipv6-cpe-router in the case where ULA addressing are used within the residental site. In this situation the Mac OS X host will attempt to use ULA IPv6 addresses for global connectivity, leading to timeouts towards dual-stacked content.

Apple bug ID: 8705091.

Work-around: Identify and disable the source of the ICMPv6 Router Advertisement packets.

Handling of ICMPv6 Destination Unreachable

When a router in the network responds to a TCP SYN packet with an ICMPv6 Destination Unreachable, Mac OS X will re-transmit the TCP SYN packet five times with intervals of one second before giving up, even though the ICMPv6 code indicates that the situation is permanent and further attempts are pointless (e.g. Code 2 - Beyond scope of source address). In other words, an avoidable four-second timeout is incurred for every outgoing TCP connection.

Microsoft Windows

Handling of ICMPv6 Destination Unreachable

Microsoft Windows appears to ignore received ICMPv6 Destination Unreachable completely, instead falling back on the overall connection timeout mechanism. This causes a completely avoidable 21 second long timeout to occur for every outbound TCP connection.

Apple iOS

No fallback from IPv6 to IPv4

Apple iOS 4.2 is reported to not be able to fall back from IPv6 to IPv4, if the initial IPv6 connection attempt fails.

Short of ensuring that any IPv6 connectivity present work perfectly, there is no known workaround. IPv6 cannot be disabled in iOS 4.2.

This bug is reported to Apple in #8702877.

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 192.88.99.1 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.
--Nathan Ward

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.