Due to the declining pool of available IPv4 addresses, service providers are motivated to find ways to convert their subscriber communications to IPv6. If they can do this they have an unlimited number of IPv6 addresses they can give to their subscribers. However, the vast majority of content and services remain IPv4-only. Therefore, methods to translate IPv6 packets to and from IPv4 packets are required to help smooth the transition to IPv6.
While dual-stack is the preferred transition mechanism to tunneling or translation, the problem with dual-stack is that the nodes require both IPv4 and IPv6 addresses. What if you don't have IPv4 addresses? Well, then you have to deploy an IPv6-only system. However, the problem we are in right now is that the vast majority of content remains IPv4-only. How do those new Internet services or users communicate to the rest of the legacy IPv4 world?
The center of this issue is that IPv6 was originally deemed to not need any form of translation like Port-Address Translation (PAT) because the intention was for every system to have a public IP address. IPv6 was designed to have many transition mechanisms because of the realities of "no flag day". The IPv6 purists vehemently protest any form of NAT and the security practitioners clamor that NAT is not a security strategy. Regardless, Network Address Translator - Protocol Translator (NAT-PT) was developed (RFC 2766). There were implementations of NAT-PT but there were also documented issues with NAT-PT. The issues involved DNS translation, security, multicast, fragmentation, scalability, and the fact that NAT disrupts applications with addresses embedded in the payload or security mechanisms like IPsec, among many others. Therefore, the IETF v6ops working group worked to move NAT-PT to historic status in July of 2007 with RFC 4966.
As time went on, we learned more about the realistic IPv6 transition strategies. It became clear that the industry at large had waited too long to implement IPv6 and now the scarcity of IPv4 addresses was becoming a huge issue. The IETF realized that some form of translation was going to be necessary and if the IETF didn't dictate the best method then the manufacturers would come up with many non-standard methods of performing the task. It was better to try to tackle the issue and draft a standard even though no-one liked the compromises. In 2009, the IETF BEHAVE working group formed and there has been rapid movement to define solutions to the problems that will appeal to the majority.
The issues related to translation are deeply rooted in service provider network architectures. Service providers realize that it is difficult to charge extra for IPv6 connectivity and that there are challenges and costs associated with deploying IPv6. Service providers would like to have lower-cost options to deploying IPv6 that may not involve running dual-protocol throughout their networks. Concepts like 6rd and DS-Lite have also become intertwined with the concepts of translation. If you are curious on some of the background information of CGN and LSN and DS-Lite, Jeff Doyle has written a few really good articles. Carolyn Duffy Marsan has also written a good article on IPv6 and Carrier-Grade NAT. Just as this debate was heating up, a year ago there was the NANOG46 panel that discussed the issues related to NAT, 6rd and DS-Lite.
First, I should probably explain a little bit about the terminology. NAT44 is what most of use on a daily basis. NAT44 systems translate private IPv4 addresses into public IPv4 addresses for use on the Internet. Most of what is in use should probably be referred to as Port Address Translation (PAT) because a single public IPv4 address is used. NAT is the term that gets used most frequently but NAT44 is more precise. NAT444 is what we are destined for in the near future when the IPv4 address crunch happens. We will perform NAT44 at our homes with our broadband Internet access routers, the service provider will use private addressing for their infrastructure and then perform a second NAT44 on their Large Scale NAT (LSN) device that connects at their Internet POPs. I am not looking forward to this transition period. Based on this nomenclature, a NAT64 system converts an IPv6 packet into an IPv4 packet that can traverse the Internet. Furthermore, NAT464 is a term used to describe the situation where IPv6 network connectivity exists between the customer's NAT device and the service provider's LSN. NAT46 is the compliment to NAT64 but it is unlikely at this stage if IPv4-only hosts will need to access IPv6-only services.
The issue is that the ink is still trying on some of these standards. Currently there are very few devices that support NAT64. The service providers are nervous because they need solutions quick because the clock is ticking and it take time to properly engineer the operations of a large-scale system that services millions of customers. Cisco has their Cisco Carrier-Grade IPv6 Solution (CGv6) and last year they published a paper on their solutions. Cisco offers their Carrier-Grade Services Engine (CGSE) for Carrier Routing System (CRS-1) and ASR routers as LSN devices. Cisco has a configuration guide and a command reference for configuring NAT on IOS XR. Juniper has had good IPv6 support across their products. Junos 10.2 support DS-Lite on MX80 Ethernet Services Routers. Juniper has a good whitepaper on these very topics. The Internet Systems Consortium (ISC) has developed their Address Family Transition Router (AFTR) in conjunction with Comcast. This system is CGN software that implements DS-Lite. Suzanne Woolf from ISC spoke about their solution at NANOG46.
My colleagues from the Rocky Mountain IPv6 Task Force (RMv6TF) thought it would be a good idea to perform a test of an early NAT64/DNS64 implementation. Ebben Aries and Chuck Sellers brought their extensive IPv6 knowledge and their toys to my office and we spent a morning experimenting and testing. We set up a simple test using the Ecdysis open-source implementation of a NAT64 and DNS64 gateway provided by Viagenie. This implementation provides independent NAT64 and DNS64 functions running within a single Fedora Linux-based LiveCD. The NAT64 function converts IPv6 and IPv4 packets and handles the routing and forwarding of packets. The DNS64 function converts AAAA queries from the IPv6-only host into IPv4-only A record queries and maintains the mapping between the two. You can learn more about NAT64 and DNS64 from a presentation by Ivan Pepelnjak titled "NAT64 and DNS64 in 30 minutes".
The setup was simple. We simply requested the download of the Linux LiveCD from the Ecdysis web page. We then burned the ISO image (ecdysis-fedora-12-x86_64-20100226.iso) to a CD and put it into a laptop that had two network interfaces. We started by connecting one laptop interface to an IPv4-only network capable of reaching the Internet. The other laptop interface was connected to an IPv6-only network where our test computers were located. The configuration of the Ecdysis system was pretty simple. Here are the configuration modifications we made on the Ecdysis system.
- Configured IPv4 address on the external interface
- Created an IPv4 static default route toward the upstream next-hop router
- Configured IPv4 Internet DNS resolver
- Configured IPv6 address on the internal interface
- Configured an IPv6-only network that uses an IPv6 default route toward the Ecdysis laptop
The configuration files are contained in the root directory. The magic-quick-start.sh file restarts the unbound service. The nat64-config.sh contains the majority of the configuration details. The reserved well-known IPv6 prefix 64:FF9B::/96 was already defined. When you do an "ifconfig -a" you will notice that you have a nat64 interface. There are several other online resources to aid with configuration if you want to test this yourself.
When we set this up we used both Windows 7 and Apple computers as IPv6-only clients. The Windows 7 hosts performed well as IPv6-only hosts because they auto-configured their addresses and use IPv6 for their DNS queries. What we discovered was that Apple laptops didn't work well through the gateway. The Apple computers autoconfigured their addresses but had problems receiving the proper IPv6 DNS resolver due to lack of DHCPv6 support. Our only issues were related to how the Apple computers handled operating in an IPv6-only environment. There are well-known problems with how OS-X 10.6 handles IPv6 DNS resolutions that prevent them from reaching IPv6-only web content.
The Microsoft Windows 7 test computers we used worked flawlessly with IPv6-only connectivity going through the NAT64/DNS64 gateway. The only problem was that these computers couldn't reach IPv6-only web sites on the Internet. When the computers performed an IPv6 lookup they were provided AAAA records, but the test computers had "broken" IPv6 connectivity to the Internet. Remember that the upstream interface on the Ecdysis laptop is IPv4-only and no tunnel is configured. That is because in our test bed we only had upstream IPv4-only Internet connectivity.
Obviously, not having to perform NAT is preferable to performing NAT, but NAT is unfortunately a reality of the world we live in. Hopefully you can experiment for yourself with this Ecdysis NAT64/DNS64 implementation and learn about how this type of translation may benefit your organization.