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.
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:
- Encapsulation (6RD, 4RD, DS-Lite, A+P, 6PE, 6VPE)
- Translation (NAT64, DNS64, dIVI, dIVI-pd, NAT444, NAT464)
A video of introduction can be found here: http://youtu.be/TqmKCqYsk5A
Hurricane Electrics provides a script which provides a Global IPv6 Deployment Progress Report:
A site reports 6281 referenced IPv6 Web sites on the Internet:
CISCO started CCO on IPv6:
JUNIPER has started an IPv6 Web site:
We have already almost 2000 IPv6 Applications:
Here is a presentation that shows how to upgrade applications to support IPv6:
Most ISPs have started to provide an IPv6 service to their customers.
The Mobile Phone networks are migrating to IPv6, this is a requirement for 4G/LTE:
Cable Networks with DOCSIS 3.0 now support IPv6.
All the workstations now come with IPv6 as the preferred protocol: Windows, Linux, Mac OS X. Even your iPhone WiFi is running IPv6.
There are some solutions to make the most of the last available IPv4 addresses but these solutions only apply to the consumers market and not to the enterprises. The consumers will only have a need for IPv4 addresses as long as some content will not be available from IPv6.
The Enterprises who will need public IP addresses will not be able to get an IPv4 address in most countries and will have no choice than starting the new offices with IPv6. We are going to see what are the options for these enterprises to keep the communication between the existing IPv4 sites and the new one running IPv6 but the only solution for the long term is the full migration to IPv6.
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.
But to run dual stack, we also need IPv4 addresses.
We are going to see that some new solutions based on NAT running at the Service Provider (Carrier Grade Nat or Large Scale Nat) or a solution for Address Sharing using the IPv4 source port (A+P) permit to make the most of the remaining IPv4 addresses. Problem is that these solutions are only good for the consumers market; the enterprises will have no choice than using IPv6
There are a few possible choices for encapsulating IPv6 in IPv4 or IPv6 in MPLS IPv4.
3.1. IPv6 in IPv4 Encapsulation
The IPv6 in IPv4 tunnels can be statically or automatically configured.
3.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.
3.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.
184.108.40.206. 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 220.127.116.11, the IPv6 site which would be reachable from this 6to4 Gateway would use the prefix: 2002:18.104.22.168::/48 or 2002:c102:405::/48.
Microsoft provided 6to4 relays on the Internet using the IPv4 anycast address 22.214.171.124 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).
126.96.36.199. 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.
3.2. IPv4 in IPv6 Encapsulation
3.2.1 DS-Lite = IPv4 in IPv6 Tunneling + LSN
Another 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. Another solution, 4RD is quite similar to DS-Lite but without LSN (NAT44) at the ISP. NAT is optional and left at the CPE.
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.
3.2.2 A+P = IPv4 Tunneling + Address Sharing
Another very promising method is A+P. A+P proposes to use some bits of the IPv4 source ports to multiplex an IPv4 address with many users without using NAT. It connects IPv4 sites using any tunnels: IPv6, IPv4 or Layer 2. A+P can be running from the hosts or from the CPEs. If the hosts are not upgraded the CPEs will do some translation for the hosts which still think they have all the source ports available where it is no longer the case as each site may have a range of allowed source ports.
A+P also needs some signaling to request the available source port for a given user.
A+P has many benefits over the LSN based solutions like DS-Lite as it does not have the scalability issue of LSN, does not require any ALG. It does not break the end to end model of the Internet and it is still possible to track a user from its IPv4 source address and its source port.
A+P also comes with some restrictions compared to the current IPv4 model. For instance, all the ports are no longer available for any application that may require a specific port. ICMP also needs some particular processing has it does not have a port. It is also required to reassemble the fragments, as we need the port information in each packet.
Again A+P is just a tool to help the transition and buy some time for the consumers. It is not a long-term solution and will not help the enterprises which will requires public addresses without any port restrictions.
A+P is still in development process, most of the signaling protocols have the status “Work In Progress” and it may seem a bit strange to keep investing in IPv4, a protocol that is now End Of Life!
FT Orange supports A+P. For implementation see ORANGE Beijing Lab web page:
3.3. IPv6 in IPv4 MPLS Encapsulation
For 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.
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 major issue is scalability. Behind the CPE, the customer may be running many devices. Each device may generate many data streams. There is not yet enough production experience to know the upper boundaries of how many customer networks a single LSN can manage, either in terms of performance or in terms of mapping steams to a single public IPv4 address. It will be very difficult to manage these LSN and provide enough resource where needed in term of CPU or memory because nobody could predict how many real users will sit behind an address. These devices will require a very close monitoring for capacity planning to upgrade the devices before the performances drop or before there will be no more resource for new translation isolating some parts of the network.
And this LSN is a single point of failure. If the device restarts and looses all the states, many users sessions will have to get restarted.
Also with NAT444 it is no longer possible to track a user with its address. If an application needs an ALG, the SP must install the ALG. It is no longer possible for the user who wants to run a server to configure some static translation to allow it.
This will not be a solution for enterprises, which will need public addresses, but only for the consumers with some service degradation anyway. And why the consumers may need IPv4 addresses? Answer: Only to access some IPv4 content because all the platforms now run IPv6 by default. When enough servers will have migrated to IPv6 there will be no more point for consumers to get an IPv4 address.
There are also issues about the network design itself.
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.
Actually there is a big difference between Stateful NAT464 and Stateless NAT464 also called dIVI and dIVI-pd for Prefix Delegation. dIVI-pd is used by A+P to share an IPv4 public address among multiple users/CPE without the help of NAT or double NAT.
“Stateless NAT464 (dIVI, dIVI-PD) is intended to benefit the network operators (ISPs) to effectively share the public IPv4 addresses among a set of customers (since IANA has run out of public IPv4 addresses). In parallel, it leverages IPv6 in the network in a manner that makes IPv4-customer originated traffic looks like native IPv6 traffic in the network, resulting in simplified operations. More importantly, (unlike CGN44, DS-Lite, CGN64 etc.) dIVI/dIVI-PD does not require any Stateful NAT, DNS64 and ALG in the network, thereby benefiting the network operator to not deal with any NAT logging etc. dIVI maintains end-to-end address transparency and bidirectional-initiated communications.
Suffice to say that Stateless NAT464 (dIVI, dIVI-PD) keeps any stateful NAT44 where it belongs – Customer Premises (e.g. Homes).”
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.
4.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.
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.
188.8.131.52. 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.
184.108.40.206. 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 220.127.116.11 address will be converted to the AAAA record with 64:FF9B::18.104.22.168 or 64:FF9B::C12D:501 address.
22.214.171.124. 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(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.
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 will support DS-Lite in the future
 CISCO IOS XE