pointer

Tag Archives: ipv4

Common Deployment Pains with IPv6: How to Identify and Fix Them

Yesterday was World IPv6 Launch day. Last year saw World IPv6 Day, the single largest test of IPv6 interconnectivity, in which several major Internet sites enabled IPv6 as a 1-day test. For this year’s event, the participating companies have turned on IPv6 and plan to keep it on – some participants, like Google and Facebook, never turned it off the first time! Last year was merely a precursor to this year’s event in hopes that it would entice Internet service providers, home hardware makers, operating system vendors, and web companies to start preparing their services for IPv6 in order to ensure a successful transition from IPv4 for everybody.

It is a fact that the world is running out of new IPv4 addresses – in fact, Asia has already run out – meaning the time to incorporate IPv6 is quickly approaching. And rightfully so! IPv6 is already a proven protocol and provides several cool advancements that we discussed in a little more detail in IPv6: Is It Finally Time. In fact, IPv6 was widely used even as far back as the 2008 Olympic Games.

For this blog, we are going to take a deeper dive into the transition to IPv6 and help provide you with the common problems that might arise while deploying this protocol and how to fix them.

Connectivity
The largest historical problem with IPv6 has been just getting connectivity. Until recently, there were few ISPs who provided IPv6, especially to residential users. One of the major goals of World IPv6 Launch was to bring IPv6 as an option to a larger audience via ISP and home router support. While the Internet Society acknowledges that it’s unlikely for IPv6 demand to be widespread – their target number is 1% of consumers – the goal is to make sure it’s available as an option for anyone who wants to use it.

After ensuring that access is available, the next problem is how to configure IPv6 access with respect to IPv4. Should you use one of the tunneling mechanisms, or one of the NAT transition methods? The short answer is neither! Given that IPv6 does not interfere with “classic” IPv4, it only adds complication to bind the two together artificially. Given the historical scarcity of IPv6 support, connectivity for most users did require using a tunnel broker, but native IPv6 support from ISPs means that the best answer is to run “Dual Stack,” using both IPv4 and IPv6 at the same time.

Before bringing up IPv6 connectivity, don’t forget the basics of Internet information hygiene: use a firewall! Most modern equipment should have at least a basic level of support for IPv6 traffic security policies. The good news is that, given that IPv6 does not require (nor should it support) NAT, the security policy should be straightforward to configure.

IPv6 addresses look different than IPv4, so it’s easy to get confused about what addressing best practices should be. It’s tempting to use Stateless Address Auto-Configuration (SLAAC) to reduce configuration overhead, but that creates technical debt in a network. SLAAC uses the MAC address of an interface as a GUID to reduce the chance of duplicate addresses. Aside from privacy issues in including a hardware-specific identifier in a globally routable address, SLAAC adds unnecessary length to an IPv6 address. Greater manageability comes from re-applying the IPAM lessons of DHCP. Whereas a SLAAC address would have a format like 2001:db8::7ee9:d3ff:ffe46:86bb, a DHCP address for the same machine could be 2001:db8::1c. While DHCPv6 may take a little more time to deploy, it will make daily administration much simpler.

MTU, fragmentation, and ICMP
The first “unexpected” problem with IPv6 will likely come from bad habits learned with IPv4 regarding MTU, fragmentation, and ICMP. In IPv4, oversized packets are split into fragments by routers along the path. In IPv6, routers will simply return an ICMPv6 error message for oversized packets – it is the job of the sending node to handle its own fragmentation. Why would a node choose to fragment unreliably at layer 3 when it can rely on TCP at layer 4? If a programmer didn’t query the OS for path MTU, and instead relied on the Ethernet MTU of 1500 bytes, minus 20 bytes for IPv4 and 20 bytes for TCP, that leaves 1460 bytes for TCP data in each datagram. However, the IPv6 header is at least 40 bytes – resulting in 20 fewer bytes in the same Ethernet MTU. While most common network applications, such as web browsers, have been by now extensively tested with IPv6, there may be legacy applications that were not coded with dynamic values from the network stack, which will cause oversized packets. Those oversize notifications will be delivered via ICMPv6. However, aggressive security practices in IPv4 have sometimes recommended blocking ICMP messages other than ping. Therefore, increased header size in IPv6, plus lack of router fragmentation, may couple with overzealously blocked ICMPv6 to create packets that don’t reach their destination and don’t allow delivery of diagnostic error messages. The problem may be especially hard to find if the local LAN switches allow jumbo Ethernet frames, which specifically allow otherwise oversized frames – the packets will flow on local subnets between L2 and L3 switches, but will be dropped by Internet routers.

HTTP Compliance
The final transition problem with IPv6 will be a subtle one. HTTP is simple from a protocol perspective, but it hides layers of complexity, because the vast majority of web pages include tags to tell the browser to load additional content, potentially from a different server. Web pages on IPv6-hosted servers will likely load content from IPv4-hosted servers for quite some time. During the initial transition, web pages may load slowly if non-IPv6-compliant DNS servers ignore requests for AAAA IPv6 records, causing the user’s PC to time out and try the IPv4 A record. Given that this problem would exist on the server side – which may be literally on the far side of the Internet – the problem may persist until the server maintainer upgrades to a modern version of DNS and/or their web service infrastructure. Fortunately, this problem has been recognized in various formats since at least 2005 (see RFC 4074). The DNS lookup method – AAAA or A – is controlled by the browser itself, and this problem is being actively addressed. APNIC Labs did research in late 2011 that shows Internet Explorer 9 has a 21-second timeout, but Google Chrome uses a method that reduces the delay to 0.3 seconds – and recent Firefox versions are even faster. Additionally, there may be filtering and processing solutions using a local DNS server which will perform the lookup recursion for the end node, resolving the problem through a combination of resolution caching and forced protocol fallback. The paradox of the Internet is that HTTP drove the mass adoption which is leading to IPv4 exhaustion, but HTTP may be the last major protocol to be fully IPv6 compliant.

The good thing is that most of your users really won’t notice anything different when using IPv6. IPv6 is supported by all major PC operating systems and all major Internet client applications like Web browsers. While there may be some smaller issues, such as the aforementioned content on IPv6 pages referencing IPv4 sites, the majority of the web will not cause any problems for IPv6.

For legacy applications and users such as developers who need to use numbered IPv4 addresses, there is still nothing to fear. IPv6 is a new protocol: rather than a patch which replaces or changes IPv4, IPv6 will run in parallel, so legacy applications should continue to function unless and until the company eventually decides to turn off IPv4, possibly several decades from now.

IPv6 is here and it is best to come to the party prepared. For an easy transition it is important to have a solid grasp of the tools that will help clear the way for this new protocol as well as what to look for if issues do occur.