Sunday, July 10, 2016

Transitions, getting from here (IPv6) to there (IPv4)

by Craig Miller

Parlez vous IPv6?
There will be no IPv6 flash-cut-over. This is not news, but the methods of transition might be. We will be living with IPv4 for some years to come, and to help us stay connected are several transition mechanisms.

Bolstered by the news (from Google and others) that IPv6 traffic on the internet was up to 10%, I set up an IPv6-only network in my house. Initially the network was only connected to the internet via IPv6. I found it is a dark world out there. Although many ISPs are moving to IPv6 with ARIN finally running out of IPv4 addresses last fall (of 2015), the content providers are still slow to enable IPv6. I was surprised and disheartened that most of my news providers (CBC, BBC, NBC, ABC, CBS, FoxNews) were all only running the legacy IP protocol, and therefore inaccessible from my IPv6-only network.

Transitions, how to get there

The easiest transition mechanism to use is dual-stack. And I have discussed this in previous posts (see Dual Stack, the good, the bad, the ugly). But there is a cost to dual-stack, specifically to network administration and maintenance. Now routers have to be configured for IPv4 and IPv6, the same with firewalls and DNS, and other networking elements.

But the good news is that once the IPv6 pipes are turned up, dual-stack just kind of works. Mostly because if there is an IPv4-only service, the host (e.g. your laptop) will just use IPv4 to connect, and the lack of IPv6 will be transparent to the end user.

Simplify the Network

We had it good after IP won the protocol wars. We didn't have to run multi-protocol routers (of the 90s) which supported not only IP but Novel/IPX, AppleTalk, Vines, and NetbEUI. We only had to support one protocol, IP(v4), and that was much easier.

Companies such as Facebook, and T-Mobile have figured out that it is easier to support just one networking protocol as well, and they have chosen IPv6. But how does one prevent seeing the dark world I did in my little IPv6-only network?

DNS64 returning false addresses

Enter NAT64/DNS64, RFC 6146. Yes, in the past I said that NAT is bad, and it is, but NAT64 is more like protocol translation, translating from IPv6 to IPv4 (and back). NAT64 relies on two things, 1) the large address space of IPv6, and 2) DNS64 resolving IPv4-only hosts into a special IPv6 address.

When the user wants to go to a IPv4-only service, DNS64 will return a special IP address starting with the prefix* 64:ff9b::/96 (e.g. 64:ff9b::c73b:9607). The connection will be opened to this address, which happens to be the NAT64 box. Since the IPv4 address is encoded in the last 32 bits of the special IPv6 address, the NAT64 opens an IPv4 connection to the legacy service acting as a protocol translation proxy service. Like IPv4 NAT, it keeps a session table, and can return packets from the legacy service to IPv6-only user's laptop.
A nice feature of this transition mechanism, besides a simpler internal IPv6 network, is that the DNS64 service does not have to be located inside your network. Google has made a public DNS64 service available at 2001:4860:4860::64

Testing NAT64 with OpenWRT

Letting Google's DNS64 do the hard work, means that one only needs setup a NAT64 service. On OpenWRT, it is possible to setup NAT64 service, although it is not a simple install and go, as the NAT64 package tayga has been removed from the most recent release repository. However the package can be found in the 12.09 release. The UCI (Universal Configuration Interface) does not work on the latest release (15.05.1), but following the quick setup instructions on the tayga website should get you going.

Although NAT64 on OpenWRT is great for a test network to give you some experience in using the transition technology of NAT64/DNS64, it is not recommended for a production network. Tayga runs in user space, and is somewhat slow.

Production quality vendors such as Cisco support NAT64 as well.

Industry moving to NAT64

Apple has made a big push in iOS 10 to have all new/updated apps in the app store support NAT64 (or IPv6-only) networks. Google with Android 6, while not making quite the commitment Apple has made, will support NAT64 (and IPv6-only) networks if the app supports it (alas there are still too many apps which are v4-only). ChromeOS works well in a NAT64/IPv6-only environment, but like Android, there are applications which are IPv4-only.

With the simplicity of only supporting one protocol on the network, and a transition mechanism the industry is behind, there is no time like the present to start gaining some experience with NAT64, and shine the light into your IPv6-only network.

*although it possible to use other prefixes for NAT64 (than 64:ff9b::/96 RFC 6052), Google's DNS64 returns addresses with this prefix, which makes life easier.

No comments:

Post a Comment