transition to ipv6 cgv6-edited

White Paper Service Provider Transition to IPv6: NAT, NAT64, 6RD, DS-‐LITE and Carrier Grade IPv6

Email: [email protected]

Service Provider Transition to IPv6 2

Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]

Fred Bovy EIRL – Ipv6 For Life! © 2012

Table of Contents 1 Introduction: Transition Technologies Needed for Decades ........................................ 3

2 Dual-‐Stack .................................................................................................................. 3

3 Network Address Translation ..................................................................................... 3 3.1 Network Address Translation from NAT to NPT6 ................................................................................ 3 3.1.1 IPv4 to IPv4 Translation: NAT or NAT44 .................................................................................................. 3 3.1.2 IPv6 to IPv6 Translation: NAT66 to NPT6 ................................................................................................ 4 3.1.3 Network Address Translation from NAT-‐PT to NAT464 .................................................................... 5 3.1.4 IPv4 to IPv4 Translation: Double NAT or NAT444 ............................................................................... 5

4 Tunneling ................................................................................................................... 8 4.1 IPv4 in IPv6 Tunneling + NAT (LSN): DS-‐Lite ......................................................................................... 8 4.2 IPv6 in IPv4 Tunneling ................................................................................................................................... 10 4.2.1 IPv6 in IPv4 Static Tunnels ........................................................................................................................... 10 4.2.2 IPv6 in IPv4 Automatic Tunnels ................................................................................................................. 10

4.3 IPv6 in IPv4 MPLS Tunneling ...................................................................................................................... 12

5 Carrier Grade IPv6 (CGv6) ......................................................................................... 12 5.1 Network Address Translation ..................................................................................................................... 12 5.2 Tunneling. ............................................................................................................................................................ 12


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


1 Introduction: Transition Technologies Needed As connected devices become more pervasive, available IPv4 addresses decline and soon will be completely depleted. IPv6 has been around for more than 10 years and supported by most operating systems and network vendors. Despite this, most service providers and companies have not transitioned to this next generation Internet protocol. As a consequence, more time is needed to allow a smooth transition to IPv6. Because of this, you may need to support mixed IPv4 and IPv6 networks for a few more years.

Maximum performance, security, and other benefits will be achieved once the transition to IPv6 is complete. Meanwhile, features, performance, and security will have to be compromised in order to support IPv4 nodes and applications.

There are three transition methods: -‐ Dual-‐stack -‐ Network Address Translation (NAT44, NAT64, DNS64, NAT444, NAT464) -‐ Tunneling (6rd, DS-‐Lite, 6PE, 6VPE)

This paper discusses each.

2 Dual-‐Stack Dual-‐stack is the preferred transition method. All workstation and server operating systems (Windows, MAC, Linux) come configured as dual-‐stack by default. 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 will be used to discover the nodes and IPv6 will be used to breach security if the IPv6 security is not as strong as IPv4 security.

3 Network Address Translation When the Internet community became concerned about IPv4 address depletion, they created workarounds. These workarounds included classless interdomain routing (CIDR) or variable-‐length subnet masking (VLSM) to save addresses, Dynamic Host Configuration Protocol (DHCP) for better address management, and Network Address Translation (NAT).

3.1 Network Address Translation from NAT to NPT6

3.1.1 IPv4 to IPv4 Translation: NAT or NAT44

Introduced in the mid-‐90s to support private addressing, NAT and NAT44 extended the life of IPv4 by making people think that address depletion would no longer be an issue. However, NAT also introduced some side effects—both good and bad. RFC2993 discusses the architectural implications, advantages, and problems of NAT.


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


On one hand, NAT broke the end-‐to-‐end IP model. Applications that must be supported, like DNS or FTP, require NAT software updates (application layer gateway [ALG]). For more details about ALG, see RFC2663: NAT Terminology and Considerations.

When an inside host must be reachable from an outside public space, it consumes a public address and a static translation must be configured. Some users see this as a security feature. IPv4 firewalls usually do NAT, but a NAT router is not a firewall!

Stateful NAT is a bottleneck, a single point of failure, and can be the target of denial of service (DoS) attacks.

On the other hand, with NAT and private addresses, users are not constrained by public addresses (address independence). NAT also permits obscuring the end user network. Hiding topology and hosts makes some people think that NAT is an important security feature. For these reasons, some architects will not consider a network design without NAT! RFC6092 provides recommendations for implementing security in an IPv6 network. This document also differentiates between actual security and the features of NAT gateways.

3.1.2 IPv6 to IPv6 Translation: NAT66 to NPT6

With the introduction of IPv6 and its 128-‐bit addresses, NAT was no longer needed to provide a unique address to Internet users and the end-‐to-‐end IP model was restored. Larger address space was a main driver for IPv6. The introduction of NAT66 into IPv6 was a frustration for IPv6 proponents. In addition to its well-‐known problems, NAT66 broke the security implemented by IPSec by changing the IPv6 header. But proponents of NAT did not like that NAT benefits were missing from IPv6 and also argued that NAT could solve the multihoming issue. After much discussion and an RFC to document everything, the IETF rejected the proposed NAT66 drafts. RFC5902 discusses the pros and cons of NAT66. It tries to justify the request for NAT66:

« 2. What is the problem? The discussions on the desire for IPv6 NAT can be summarized as

follows. Network address translation is viewed as a solution to achieve a number of desired properties for individual networks: avoiding renumbering, facilitating multihoming, making configurations homogenous, hiding internal network details, and providing simple security. »

RFC4864 explains IPv6 solutions to the NAT66 claimed benefits without requiring any address translation. NAT supporters were not deterred. They responded by developing a simplified stateless NAT66 that was renamed Network Prefix Translation or NPT6, which was approved in RFC6296.


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


3.1.3 Network Address Translation from NAT-‐PT to NAT464

3.1.3.1 NAT-‐PT (RFC2766)

For transitioning to IPv6, Network Address Translator-‐Protocol Translator (NAT-‐PT) was the first protocol translation method implemented by Cisco IOS. NAT-‐PT equates to NAT64 + NAT46 + ALG.

NAT64 is the NAT translation initiated by the IPv6 side, and NAT46 was initiated by the IPv4 side. NAT-‐PT was the answer for all the cases, but it consumed many resources and IOS running NAT-‐PT was process switching with the very low performances we know.

Use of NAT-‐PT is now deprecated (RFC4966).

3.1.3.2 NAT64/DNS64

3.1.3.2.1 What is the problem we want to solve?

Workstations run dual-‐stack by default. Equipment using Windows, MAC OS, and Linux operating systems is set up with dual stack by default. It is not difficult to upgrade a workstation if it runs an old operating system without dual stack. From the initialization side, IPv6 support is not the problem. On the other hand, it may be more difficult to upgrade an application to support IPv6.

3.1.3.2.2 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 by 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.1.3.2.3 Stateless or Stateful NAT64

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 an IPv4 address is needed for each translated IPv6 address. Stateful is required if multiple IPv6 addresses must map to the same IPv4 address.

3.1.4 IPv4 to IPv4 Translation: Double NAT or NAT444

NAT at the CPE has already permitted to IPv4 to last for 20 more years and now the ISPs are starting to use NAT one more time at the next level with NAT444. 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. Carrier-‐grade NAT (CGN) and large-‐scale NAT ( LSN) refer to NAT running at the service provider instead of the CPE.


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


Figure 1. NAT 444

A device in a customer network might send a packet to an Internet destination with a source address of 10.1.1.1. The CPE NAT translates the source address to, for example, 172.16.1.1 with accompanying port mapping. At the LSN, the source address is translated to the public IPv4 address, say 201.15.83.1 again with port mapping, and the packet is routed to the destination. Responding packets to 201.15.83.1 are routed to the service provider’s aggregate IPv4 address, then to the appropriate LSN, which translates the destination address back to 172.16.0.1 and forwards the packet to the corresponding CPE NAT, which translates the destination address to 10.1.1.1. This looks simple, but this design is not without issues.

One 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.

Also, it becomes impossible to track a user using its IP address. If a new application requires an ALG, it must be installed by the SP. Another issue is the possibility of address overlaps between the customer’s network and the private addresses used by the service provider. For example, if the provider uses addresses out of the 172.16.0.0/12 block between the LSN and the CPE NAT, and the customer addresses his network out of the same block, uniqueness between the two zones is lost and packets might be misrouted. Insuring that customers use non-‐conflicting address ranges can be an administrative headache for the provider.


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


Figure 2. Firewall Blocks Packets with Private Source Address

Yet another issue occurs when a customer wants to send packets to another customer behind the same LSN. Filtering policies in firewalls, router ACLs, and even servers often block packets from outside the network that have private source addresses. To circumvent this problem, packets must pass through the LSN so that their source addresses can be translated to a public address and then switched back through the LSN to the destination. LSN resources are consumed even though the packets are not going to a destination beyond the LSN. A proposed solution to these problems is to reserve a block of the remaining public IPv4 space as an “ISP shared address” space. Because the address block would be reserved for use in NAT444 architectures, the same addresses can be used behind different LSNs the same way RFC1918 addresses are used for private networks. Because the address would not be RFC1918 addresses, they would not conflict with the private addresses in any customer network. Also because they are not RFC1918 addresses, filtering policies will not block them. Packet flows between customers behind the same LSN will not have to pass through the LSN. Another solution is to use IPv6 on the CPE NAT-‐to-‐LSN link; this is NAT464. It will go in the good direction with IPv6 between the customer and the service provider.


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


3.1.4.1 NAT464

A problem with this design is that now the CPE must perform NAT46 address translation instead of NAT44. This design will require upgrading all the CPEs, which is an expensive solution.

Figure 3. NAT464

4 Tunneling There are a few choices for encapsulating IPv4 in IPv6, IPv6 in IPv4, or IPv6 in MPLS IPv4.

4.1 IPv4 in IPv6 Tunneling + NAT (LSN): DS-‐Lite

Because all customers will not migrate at once to IPv6, a big problem for service providers is supporting RFC1918 IPv4 customers after the backbone has migrated to IPv6. Dual Stack Lite (DS-‐Lite) solves this with IPv4 in IPv6 tunneling and NAT44.

Another problem is that all the applications will not migrate to IPv6 at once either and the clients will need to run IPv4 and dual-‐stack for a while to access the IPv4 servers. DS-‐Lite will permit this.

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


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


Figure 4. DS-‐Lite IPv4 in IPv6 Tunnel

Figure 5. DS-‐Lite = IPv4 in IPv6 Tunnel + LSN


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


Figure 7. IPv6 Routed Directly. IPv4 Routed to LSN.

4.2 IPv6 in IPv4 Tunneling

IPv6 in IPv4 was the first overlay tunnel used during the transition to IPv6. The first experimental IPv6 network, the 6BONE, was created from overlay tunnels connecting IPv6 islands across the IPv4 Internet. IPv6 in IPv4 tunnels can be statically or automatically configured.

4.2.1 IPv6 in IPv4 Static Tunnels

For IPv6 in IPv4 static tunnels or 6in4 static, you must configure the tunnel source and destination IPv4 addresses. This is the least unsecure option as you can control the source and destination of the tunnel. If possible, use IPSec to secure these tunnels.

4.2.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 IPv6 addressing. Teredo and Intra-‐Site Automatic Tunnel Addressing Protocol (ISATAP) automatic tunnels are not intended for service providers and are not discussed here.

4.2.2.1 6to4: The Origin (RFC3056)

The first popular automatic tunnels were 6to4. These tunnels solved two problems: IPv6 addressing and automatic destination tunnel configuration. They provided the reserved IPv6 prefix—2002::/16. Following this prefix was the 6to4 gateway public IPv4 address. This way, the destination IPv4 address of the tunnel was coded in the


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


destination IPv6 address. For instance, if a 6to4 gateway public IPv4 address was 193.2.4.5, the IPv6 site that 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. For ISPs, the biggest problem with 6to4 is the lack of flexibility due to the fixed 2002::/16 prefix. 6to4 also lacks basic security features (RFC3964). 6to4 is now deprecated.

4.2.2.2 6rd: The Next Generation (RFC5969)

Free Telecom, a French ISP, 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 IPv6 service to their customers.

6rd was implemented in Cisco IOS Software Release 15.1(3)T and is documented in RFC5969.

Figure 6. 6rd, 6to4 with a Customized Prefix


Fred Bovy

Transitionn to IPv6

22/08/11 2:03 PM

[email protected]


4.3 IPv6 in IPv4 MPLS Tunneling

For service providers with an IPv4 MPLS backbone, the transition methods are IPv6 Provider Edge Router (6PE) and IPv6 VPN Provider Edge Router (6VPE).

6PE is for the transport of IPv6 on top of MPLS IPv4. 6VPE adds the support of IPv6 in MPLS-‐VPN. The VRF can be dual-‐stack. Both are stable, efficient, and scalable methods to provide IPv6 services over an IPv4 MPLS backbone. While 6PE and 6VPE are important transition methods for service providers, they are not discussed in this white paper.

5 Carrier Grade IPv6 (CGv6) CGv6 is the Cisco solution to support service providers during the transition to IPv6. CGv6 runs on a dedicated carrier-‐grade service engine on the CRS-‐1. CGv6 is also available on Cisco ASR 9000 with IOS-‐XR and Cisco ASR 1000 with Cisco IOS-‐XE Software.

5.1 Network Address 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 represents the Roman numerals for 4 (IV) and 6 (VI); in other words, NAT46 and NAT64.

5.2 Tunneling.

CGv6 supports 6rd and DS-‐Lite. For more information about the Cisco CGv6 solution, visit http://www.cisco.com/go/cgv6 and http://www.ccmi.com/IPv6/Cisco_CGv6.pdf

Fred BOVY, CCIE #3013 [email protected]

transition to ipv6 cgv6-edited

Technology

fredbovy transitionntoipv6

natornat44 introducedinthemid

nat464 tunneling6rd

andnetworkad translationnat

vpe thispaperdiscusseseach

itconsum public