IPV6 Means More Interim Headaches (by Jim MacLeod)

On June 6th of this year, some of the biggest names in tech joined together for World IPv6 Launch Day to herald the transition from IPv4. Now that the fanfare has died down, what does this mean for you? Many think it will mean more headaches than reward with administrators complaining that IPv6 has longer addresses, and users complaining of application delays due to IPv6 to IPv4 fallback.

Let’s take a look at these two potential issues and how to solve them.

Problem: The Addressing Trap
Ask anyone what the benefit of IPv6 is, and most will say more available addresses, which means longer addresses. Initial reaction from many engineers is that these new addresses are too long to remember. This is only partially right; understanding how the IPv6 addresses work, along with some planning, results in addressing that is as simple as current IPv4 addressing.

IPv6 addresses, like IPv4 addresses, are composed of 3 parts:

1. The global routing prefix, assigned by the Regional Internet Registry (RIR) like ARIN in the US or RIPE in Europe
2. The local subnet, locally administered at the router level, and
3. The individual node, administered by either DHCP, self-assigned addresses (SLAAC), or manually (static).

Essentially, everything past the prefix is under local administrative control.

While IPv6 addresses are longer than IPv4, they include an innovation that will increase their ease of use over IPv4 as much as CIDR notation did over explicit subnet masks. In IPv6, sequential blocks of 0x00 can be written just as a double colon (‘::’). Therefore,the key to ease of use in IPv6 addresses is to assign addresses to create the largestnumber of sequential zeroes.

Solution: Assign Addresses
Create subnets from the left, and use DHCP to assign node addresses from the right. For subnets, assign the left-most sedectet (16-bit block) first, starting from the lowest number. For nodes, simply configure DHCP to start counting at 2 – assuming that 1 is the default gateway.

For example, with the global prefix 2001:db8::/32, the worst-case scenario would be to start subnetting from the right, and use SLAAC to self-assign nearly random numbers. That would be 2001:db8:0:1:xxxx:xxxx:xxxx:xxxx. Instead, start subnetting from the left (which leaves room for later hierarchical expansion) and use sequential DHCP. The result is an address more like 2001:db8:1:0:0:0:0:2 – which shortens to 2001:db8:1::2 – which is much easier to manage and remember. Administrators will soon start to omit the global routing prefix, much as they do for IPv4, and casually call this node “1::2”.

Problem: Failed Connections with IPv6 To IPv4 Fallback
With the world quickly running out of new IPv4 addresses, the time to incorporate IPv6 is now. When adding IPv6 to your network, it is important to be prepared for problems that may arise.

The most common issue for the next few years will likely be IPv6 to IPv4 fallback. Any node that has IPv6 enabled with a valid address will prefer to use IPv6 over IPv4. However, until IPv6 deployment becomes more widespread and stable, full connectivity may not be possible. Therefore, the node will attempt to connect via IPv6, fail, and typically re-try the connection via IPv4. Depending on the OS and the application, that re-try can be nearly instant, or it can range from 20 to 180 seconds or even more!

Solution: Switch Web Browsers
The fallback problem has been studied, tested, and solved by some web browsers much better than others. On Windows, Internet Explorer still relies on the OS to time out, leading to 20 second fallback delays. The best browsers for a mixed IPv4/IPv6 environment are Chrome and Firefox, which have sub-second failover. On MacOS, Safari has also solved the problem. (On some versions of Firefox, this feature may be turned off by default, so open the about:config page and set “network.http.fast-fallback- to-IPv4” to True.)

Problem: Fragmented Packet Blackholes
One feature included in IPv6 to make the network run faster is to do fragmenting on the sender side, rather than on routers along the packet path. If one of the network links between the client and server can’t forward large packets, in IPv4 it breaks the packets into fragments, but in IPv6 it simply sends an ICMPv6 “Packet Too Big” message back to the sender to retransmit in smaller packet sizes. While most transit on the modern Internet allows Ethernet-sized frames, there are still some ways to shrink the effective MTU, like an IPSec VPN. IPv6 nodes need to be able to receive the “Packet Too Big” messages, otherwise the large packets they send along that path to that destination will simply disappear, as with a blackhole route.

The problem is that, in recent years, it has become common practice to block ICMP on the firewall to prevent shenanigans like route hijacking, source squelching, or destination black-holing. While these issues will not go away with IPv6, IPv6 relies on the ICMPv6 “Packet Too Big” message to be returned to the sender for automatic Path MTU Discovery. Blocking those messages can lead to the frustrating situation where small packets can go through, but big packets can’t. This means that ping will likely work, and that the TCP 3-way handshake will likely work to open a socket and establish the connection. However, data won’t flow. A network administrator not aware of this issue might incorrectly deduce that the problem is therefore in the application, or on the server, leading to longer resolution time.

Solution: Know what you’re blocking
Firewalling some ICMPv6 messages may still be a good idea from a security perspective, but “Packet Too Big” is mandatory for a healthy network.

Problem: IPv6 in Unexpected Places
I personally ran into an issue with IPv6 in a hotel room. Given my previous experiences with hotel Wi-Fi, I wasn’t surprised that I couldn’t get online, but I was astonished when OmniPeek showed me that my laptop was trying to send and receive IPv6. Normally, the captive portal at a hotel or coffee shop will intercept your web connection, and send a HTTP redirect to show you the registration screen. However, on this particular network, IPv6 was enabled on the router but not supported by the captive portal. Therefore, my web requests were sent by my laptop via IPv6, giving me partial connectivity, but all IPv4 connections were captured by the captive portal. The result was that I couldn’t use the web because the portal kept interfering, but I couldn’t get to the portal to authenticate because it wouldn’t capture IPv6. Once I finally used our OmniPeek network analyzer to see what was happening, I turned off IPv6 and everything worked just fine.

Public Wi-Fi hotspots, like hotel networks, are unlikely yet to have IPv6, which makes them vulnerable to a security attack using fake IPv6 Router Advertisements. If users can see each other’s packets, an attacker can enable an IPv6-to-IPv4 gateway on his/ her computer, and use ICMPv6 Router Advertisements to convince the other computers that it is the local default gateway for IPv6. Given the preference that PCs have for IPv6 over IPv4, any IPv6-enabled PCs will happily start sending traffic through that fake router, giving the attacker the ability to intercept information, redirect traffic to malicious websites, and possibly even pretend to be the actual user.

Solution: Don’t Use IPv6 in Public
While I want to recommend that you use IPv6 wherever possible, the sad truth is that most locations aren’t using it, and it can cause connection and/or security problems if it’s not set up right. For now, only use IPv6 at home, at work, or on networks you trust. Once enough of us have IPv6 set up on the client side, there will hopefully be enough demand to make its use mainstream. Until then, use it sparingly and decrease your risk.

Looking Forward
As IPv4 addresses continue to dwindle, adding more IPv6 addresses to your network is essential for preparing for the time when adding IPv4 addresses is no longer an option. Because the most common IPv6 problem today stems from incomplete deployment, turning IPv6 on now will help advance the total IPv6 traffic levels, leading to more consistent deployment and greatly reduced problems.

Addressing and IPv4 fallback are two common problems, but there are plenty more like neighbor discover and message control. What are you seeing as your organization deploys IPv6? Got any tips on how to avoid unnecessary headaches?



Author Profile - Jim MacLeod is a Product Manager at WildPackets. He has been in the networking industry since 1994, and started doing protocol analysis in 1996. His experience includes positions in firewall and VPN setup and policy analysis, log management, Internet filtering, anti-spam, intrusion detection, network monitoring and control, and of course packet sniffing.