Transition to IPv6 at the Service Providers: NAT64, 6RD, DS-LITE and Carrier Grade IPv6 (CGv6)

Introduction: Transition technologies needed for decades.While the Internet is still growing very fast with more connected devices every day, the available IPv4 addresses declines and will be completely depleted very soon. As IPv6 is now implemented for more than 10 years and available on most Operating Systems and Network vendors, most Service Providers and even more companies have not yet switched to the next generation Internet protocol. As a consequence we still need to buy some time to allow a smooth transition to IPv6. It is planned that we will need to support mixed IPv4 and IPv6 networks for decades.

Clearly, maximum performances, security and other benefits we can think about running IPv6 will be achieved when transition will be over. During transition we will need to compromise features, performances and security for the benefit of supporting old IPv4 nodes and applications.
The transitions methods fall into three categories:

-      Dual-Stack
-      Encapsulation (6RD, DS-Lite, 6PE, 6VPE)
-      Translation (NAT64, DNS64)

1. Dual-Stack

This is the preferred transition method. All the Operating Systems (Windows, MAC OS, Linux) for any workstation or server platforms come configured dual-stack by default. This is a trivial case, when a host needs to transmit a packet, it sends a DNS Request to get an address. If the DNS reply includes both IPv6 and IPv4 addresses, it will prefer the IPv6.
The only drawback of this method is the duplicated effort to maintain IPv4 and IPv6 concurrently. Also, you must apply the same level of security to both protocols or you may risk that IPv4 be used to discover the nodes and then IPv6 will be used to get in if the IPv6 security is not as strong as IPv4 for instance.

2. Encapsulation

There are a few possible choices for encapsulating IPv6 in IPv4 or IPv6 in MPLS IPv4.

2.1. IPv6 in IPv4 Encapsulation

The IPv6 in IPv4 tunnels can be statically or automatically configured.

2.1.1. IPv6 in IPv4 Static Tunnels
For the 6in4 static, you must configure the Tunnel source and destination IPv4 addresses. It is the less unsecure as you can control source and destination of the tunnel. If possible use IPSec to secure such tunnels.

2.1.2. IPv6 in IPv4 Automatic Tunnels
With automatic tunnels, you don’t need to configure the IPv4 destination of the tunnel. Automatic tunnels also provide the IPv6 addressing. TEREDO and ISATAP automatic tunnels are not intended for Service Provides and are not discussed here.

2.1.2.1. 6to4: the origin (RFC3056)
The first popular automatic tunnels were 6to4. 6to4 solved two problems, IPv6 addressing and automatic destination tunnel configuration. It provided the reserved IPv6 prefix, 2002::/16. Following this prefix was configured the 6to4 gateway public IPv4 address.  This way, the destination IPv4 address of the tunnel was coded in the destination IPv6 address. For instance if a 6to4 Gateway public IPv4 address was 193.2.4.5, the IPv6 site which would be reachable from this 6to4 Gateway would use the prefix: 2002:193.2.4.5::/48 or 2002:c102:405::/48.

Microsoft provided 6to4 relays on the Internet using the IPv4 anycast address 192.88.99.1 for anyone using 6to4 to have access to the IPv6 Internet from IPv4.

The biggest problem with 6to4 for Internet Service Provider is the lack of flexibility due to the fixed 2002::/16 prefix. 6to4 also lack of any basic security feature (RFC3964).

6to4 is now deprecated.

2.1.2.2. 6RD: the next generation
Free Telecom, a French Internet Service Provider customized the code of a 6to4 platform to accept any ISP prefix instead of 2002::/16 and provided instant IPv6 access to their customers. They provided the relays to access the IPv6 Internet and called this 6RD for IPv6 Rapid Deployment. 6RD became the de facto standard for Service Providers with an IPv4 backbone to provide an IPv6 service to their customers.

6RD is implemented in IOS since 15.1(3)T and is documented in RFC5969.

2.2. IPv4 in IPv6 EncapsulationAnother problem for the Service Providers was to support the IPv4 Only devices using RFC1918 private addresses after they have migrated their backbone to IPv6.

Dual Stack Lite (DS-Lite) solves the IPv4 in IPv6 encapsulation problem and the NAT44 translation from private to public address.

Also, DS-Lite uses the IPv6 source address of the tunnel with the IPv4 source address and the source port number to identify the inside connection. Without it, there would be no way to differentiate two overlapping customers using the same RFC1918 private address.

DS-Lite is a very attractive method to deal with IPv4 address depletetion, while it also gives the Service Provider a chance to start their backbone migration to IPv6. Then, when the customer is ready to switch to IPv6, the Service Provider is just ready to provide the right service.

2.3. IPv6 in IPv4 MPLS EncapsulationFor Service Providers with IPv4 MPLS backbone, the transition methods are 6PE and 6VPE. 6PE is for the transport of IPv6 on the top of MPLS IPv4.

6VPE adds the support of IPv6 in MPLS-VPN. The VRF can be dual-stack.

Both are very stable and scalable methods to provide IPv6 service over an IPv4 MPLS backbone.

3. Translation

 3.1 Network Address Translation from NAT44 to NPT6

 3.1.1 IPv4 to IPv4 Translation: NAT44 and double NAT, NAT444
Introduced in the middle of the 90s to support private addressing, NAT or NAT44 has extended the life of IPv4 making people think that address depletion will not be an issue anymore. But NAT also introduced some side effects. RFC2993 discusses the Architectural Implications of NAT, the advantages and also the problems.

On one hand, NAT complicates everything and breaks the end-to-end model of IP. Applications that cannot be NAT friendly and must be supported require NAT software updates (Application Layer Gateway).
When an inside host must be reachable from the outside public space, it consumes a public address and a static translation must be configured.

Stateful NAT, far from being a security feature is also a simple point of failure and can be the target of a DoS attacks.

On the other hand, with NAT and private addresses, the users don’t have any more constraint with public addresses (addresses independence).

NAT also permit to obscure the end user network. Hiding topology and hosts makes some people think that NAT is an important security feature.
For these reasons, some architects cannot think about a network design without NAT! If someone says that NAT is bad they defend it as a religion.

NAT444 refers to double NAT where NAT44 is performed a first time by the CPE at the customer’s site and then a second time by the Service Provider LSN. Carrier’s Grade NAT or CGN and Large Scale NAT or LSN refer to NAT running at the Service Provider instead of the CPE.

NAT444 is a simple design but is not without issues.

A first one is about the risk to see an overlapping address used by the link between the CPE NAT and the LSN. If one of the customers networks uses the same address than the address used on this link, we have a serious problem.

Another possible issue is if a customer of a LSN wants to send a packet to another customer of the same LSN. If the packet is locally switched without source address translation, there is a high risk that a firewall will drop it because packets with a private RFC1918 source address are usually dropped. The solution is for the LSN to do an address translation using a public shared address. As there is no such reserved public address for NAT444, this could be an open issue.

Regarding these two problems, one may prefer to use an alternate design.

The choices are either to use NAT464 instead. With NAT464, the links between the CPE NAT and the LSN are IPv6 but this requires the NAT CPE to run NAT46 instead of NAT44 and we may need to upgrade the all the CPEs that is a quite expensive solution.

Another, much preferred alternate choice would be to use DS-Lite instead. With DS-Lite there is no need for IPv6 to IPv4 header translation at the CPE. DS-Lite tunnels the IPv4 packets in IPv6 instead, then a NAT44 translation is done at by the Service Provider LSN. And because DS-Lite uses the tunnel IPv6 source address in addition to the IPv4 source address and the source port to identify the endpoint, there is no more a problem with IPv4 address depletion, the tunnel IPv6 Source address make the source endpoint unique anyway.

3.1.2. IPv6 to IPv6 Translation: NAT66 to NPT6
With IPv6 and its 128 bit long addresses, NAT was no longer needed to provide a unique address to all the Internet users and the end-to-end model of IP was restored. Larger address space was one of main driver for IPv6 and having NAT66 back in IPv6 was like a nightmare for IPv6 people.

In addition to all the well-known problems, NAT66 would also break the security implemented by IPSec as it would change the IPv6 header.  But the NAT people were missing the NAT benefits in IPv6 and also argued that NAT could also solve the multihoming issue. Therefore after a lot of discussions and RFC to document everything, the IETF rejected the proposed NAT66 drafts.

RFC5902 is a discussion about the pro and cons of NAT66.

RFC4864 explains all the IPv6 solutions to the NAT66 claimed benefits without requiring any address translation.
The NAT supporters were not defeated and they came back again with a simplified stateless NAT66 renamed Network Prefix Translation or NPT6. Possibly because it was no longer called NAT66 but NPT6, it was approved in RFC6296.

3.2. Network Address Translation from NAT-PT to NAT64

3.2.1 NAT-PT (RFC2766)
For transition to IPv6, NAT-PT has been the first proposed translation method.
NAT-PT was NAT64 + NAT46 + Application Layer Gateway.
NAT64 is the NAT translation initiated by the IPv6 side, NAT46 initiated by the IPv4 side. NAT-PT was the answer for all the cases but it was also very high resource consuming and IOS running NAT-PT was process switching with the very low performances we know.

NAT-PT is now deprecated (RFC4966).
3.2.2. NAT64/DNS64

3.2.2.1. What is the problem we want to solve?
The workstations are running dual stack by default. Windows, MAC OS and Linux boxes are setup with dual stack by default and it is not difficult to upgrade a workstation if it runs an old OS and we need it. So from the initialization side, IPv6 support is not the problem.

On the other hand, if an application has been written for IPv4, it may cost a lot of money and it would not be a good idea to rewrite it to support IPv6.

So what part of NAT-PT do we need to cover most cases?  NAT64 and DNS64.

3.2.2.1. DNS64 (RFC6147)
NAT64 relies on DNS64 to manage the DNS request and send a reply to the source with an IPv6 prefix built from the IPv4 address received from the target node. DNS64 first sends a request for a AAAA prefix. If it receives an error, it then tries to ask an A prefix. Then if it receives an answer, DNS64 converts it to a AAAA ipv6 prefix.

This ipv6 address is built using a NAT64 Well Known Prefix (64:FF9B::/96) followed with the IPv4 address coded as an IPv6 address. The A record with 193.45.5.1 address will be converted to the AAAA record with 64:FF9B::193.45.5.1 or 64:FF9B::C12D:501 address.

3.2.2.2. Stateless or Stateful NAT64
Then the packet from the source is routed to the NAT64 box using the normal IPv6 routing. The NAT64 box translates the IPv6 packet to an IPv4 packet and sends it to the target. It also performs the opposite when the answer comes back from the IPv4 host.

NAT64 can be stateless[1](see RFC6052) or stateful (see RFC6145, RFC6146 and RFC6052).
Stateless means that we need an IPv4 address for each translated IPv6 address.
Stateful if multiple IPv6 addresses must map to one IPv4 address.

4. Carrier Grade IPv6 (CGv6)

This is the CISCO solution to support the Service Providers during the transition to IPv6.
It is running on a dedicated Carrier Grade Service Engine on the CRS-1. CGv6 is also available on the ASR9000 with IOS-XR and the ASR1000 with IOS-XE Operating System.

Translation. CGv6 supports double NAT444 where NAT44 is performed at the CPE and again at the Service Provider. CGv6 also supports Address Family Translation or IVI, which means IV, and VI, in other words NAT46 and NAT64.

Encapsulation. CGv6 supports 6RD and DS-Lite.

For more information about Cisco Carrier-Grade IPv6 Solution (CGv6), visit
http://www.cisco.com/go/cgv6 and
http://www.ccmi.com/IPv6/Cisco_CGv6.pdf