 | Issue: | Asia-Pacific III 2013 |
| Article no.: | 3 | |
| Topic: | Integrated IPv6 migration (CGv6) solutions on High End Routers | |
| Author: | Ramji Vaithianathan | |
| Title: | Ramji Vaithianathan, Senior Technical Leader, High End Routing Group | |
| Organisation: | Cisco | |
| PDF size: | 201KB |
About author
Ramji Vaithianathan, Senior Technical Leader, High End Routing Group, Cisco
Ramji Vaithianathan is a Senior Technical Leader in Cisco Systems. He works for High End Routing group which develops high speed routers mainly for Telecom Companies.
Ramji Vaithianathan has over 15 years of experience in working with High End Routing Systems in Cisco Systems and has been a lead in the area of Hardware based forwarding. He has also worked in architecting IPv6 migration solutions on High End Routers. He works closely with various Telecom customers in implementing various features on these platforms.
Prior to Cisco, he has worked with Cellnet Data Systems, USA, Wipro Information Technology Ltd., India and CRI A/S Denmark in various areas, mainly involving Network Software development.
Ramji Vaithianathan has given various technical talks about hardware based forwarding and in the area of IPv6 migration solutions. He has also co-authored an RFC on NAT64.
Ramji Vaithianathan has a B. Tech in Electrical Engineering and M. Tech in Computer Science from IIT Madras.
Article abstract
IPv4 address depletion is a critical problem for the functioning of IP networks. NAT has been used to alleviate pressure in private networks, and could do so for carrier networks. It is needed because the migration to IPv6 can only happen gradually, during which time IPv4 and IPv6 must co-exist, in a variety of scenarios. Multiple solutions help in this migration, involving dual stacks hosts, carrier address translation and tunneling IPv4 addresses in IPv6. There are several options for implementing IP security, at the end-node, the first hop or the last hop. Many Telecom service providers require these solutions to be embedded in their high end routers for speed, flexibility and easy manageability.
Full Article
IPv4 Depletion Problem and migration to IPv6
We are all aware of the IPv4 address depletion issue – there are only close to 4 billion unique IPv4 addresses available, while Internet enabled devices are growing at such a rapid rate worldwide that it is not possible to assign a unique IPv4 address to all of them. For many years, Network Address Translation (NAT) was considered a solution for the problem. Private IPv4 address ranges were reused across multiple networks. When hosts needed to access the Internet, NAT translated these private addresses to a public address in a dynamic fashion. Multiple private addresses were translated to the same public address, and the TCP/UDP port numbers distinguished the sessions originating from different private addresses. Hence this was referred to as Port Address Translation (PAT) in some documents. NAT/PAT had its own problems, especially when these private addresses were also embedded inside the payload of the packets. This needed inspection inside the payload to extract these address and translate them during the NAT process. Hence NAT became complex and certain applications never worked over NAT. NAT is a short term solution until all Internet devices migrate to IPv6 based addressing, which can support address ranges in the order of magnitude of more than – 3×1038 ,or 2128 to be exact.
Converting all end devices and servers in the world to IPv6 cannot be achieved in a single stroke and the migration will continue over a large number of years. During this timeframe, IPv6 based networks and IPv4 based networks need to co-exist. The subsequent sections discuss some of these inter-op cases and solutions, which are referred to collectively as Carrier Grade IPv6 (CGv6) protocols.
IPv6 based hosts talking to IPv4 based servers
With the proliferation of Internet enabled (3G, LTE) mobile devices, each mobile device requires its own IP address. They are provided with IPv6 address, as IPv4 addresses are not available, but they still need to communicate with legacy IPv4 servers. To support this communication, ‘stateful’ NAT64 translation protocol is proposed.
• An IPv6 source address from an end device is mapped dynamically to a public IPv4 address. Similar to IPv4 NATting, multiple IPv6 addresses would map to the same public IPv4 address by using UDP/TCP ports as distinguishing factors for the sessions.
• Servers’ destination IPv4 addresses are globally unique in the Internet space. These IPv4 addresses are embedded in an IPv6 address with a ‘well-known’ prefix. The IPv4 address is later extracted and used when the packet is converted from V6 to V4.
IPv6 based private networks talking to IPv4 based private networks
In many enterprises, the networks are migrated in a phased manner. Parts of the enterprise are migrated to IPv6 network, whereas other parts of the enterprise network with legacy servers still use IPv4 addresses. Since these are private networks, each host in the IPv6 network is allocated an IPv6 address with an embedded private IPv4 address. When the IPv6 host talks to an IPv4 based server, it embeds the IPv4 address of the server with a known IPv6 prefix. The IPv6 packet is translated to IPv4 packet in ‘stateless’ fashion, before entering the IPv4 network by extracting the IPv4 addresses from IPv6 addresses. Reverse communication from IPv4 hosts to IPv6 servers is also possible. Here the IPv4 addresses are prefixed with a known IPv6 prefix to convert them to IPv6 addresses. This is referred to as stateless NAT64 translation, as the conversion from IPv4 to IPv6 address or the other way around is achieved by adding/removing known IPv6 prefixes to/from the IPv4 address.
Tunneling IPv6 packets over transit IPv4 networks
During the early migration phase to IPv6, there could be islands of IPv6 networks which are inter-connected to each other using IPv4 based networks. A tunneling mechanism encapsulates the IPv6 packets in IPv4 and transports them over the IPv4 networks. Gateways decapsulate these IPv4 packets, extract the underlying IPv6 packets and forward them to the other IPv6 network. There are multiple mechanisms here:
• 6 rd (IPv6 rapid deployment) – Various telecom companies, including Free Telecom in France, are using this. This tunneling mechanism uses known IPv6 prefixes with embedded IPv4 addresses to indicate the routing gateways.
• 6 to 4 – This mechanism is similar to 6 rd, but with a globally well-known IPv6 prefix 2002::/16 for tunneling.
Dual Stack hosts
During the later migration phases, islands of IPv4 networks hosting legacy IPv4 servers could exist. The end-hosts in IPv6 networks would have both IPv4 and IPv6 addresses and are referred to as Dual Stack hosts. They communicate with other IPv6 servers in a native fashion, using IPv6. However, they use IPv4 to communicate with IPv4 servers. Since there is no direct IPv4 connectivity, the IPv4 packets are tunneled using IPv6 packets, to reach gateways that decapsulate and forward the IPv4 packets to the legacy IPv4 servers. There are multiple mechanisms here:
• DS-Lite (Dual-stack-Lite) – Hosts have a private IPv4 address in addition to an IPv6 address. When talking to IPv4 servers, they use these private IPv4 addresses and tunnel the packet over an IPv6 tunnel. At the other end, the IPv4 packet is extracted from the tunnel, the private IPv4 source address is NATed to a public IPv4 address and sent to the IPv4 server. Since there is NATing involved, it is a ‘stateful’ mechanism.
• MAP-T and MAP-E – These are stateless mechanism to translate or encapsulate IPv4 packets over IPv6 transport.
IPv6 Security
Amidst all the migration technologies, the operator is always worried about the IPv6 Security, regardless of the adoption percentages. It is important to analyze the best possible location to deploy IPv6 Security. There can be three locations where network operators can deploy link security: (1) at the end-nodes, (2) First-Hope within the network and (3) at the last hop.
The end-node security model is best for distributed model where end-nodes take care of themselves. This model works well where centralized administration cannot be provided. It is useful for threats coming directly from the link, but it provides poor protection from offlink devices. This model uses Secure Neighbor Discovery architecture (SeND).
The first Hop model is based on centralized security administration. It is similar to the above mentioned model but the security is pushed towards to the first hop device (towards the end-user). Hence this model is far more scalable than the above model and is also very efficient in protecting threats from offlink devices. This model also uses SeND architecture.
The last-router model is also a centralized model for defending against threats coming from the outside of the link that should be protected. A property of this model is that both the attached and the downstream links are well protected. By the same token, this model will be risky for threats that come from inside, e.g. when a device has been compromised.
Where to implement the interworking protocols
Traditionally, standalone gateways in enterprise networks provided IPv4 NAT for packets sent to the Internet. However due to the complexity of CGv6 protocols, CGv6 services are hosted on High End Routers such as Broadband Networking Gateway (BNG) routers or on even the core routers of the Service Providers network. This provides the following advantages:
• The number of devices managed by the Service Providers is reduced.
• There are fewer inter-operation issues between various devices.
• Uniform CLI (Command Line Interface) is used to manage the routing and the CGv6 protocols
• Much of the translation functionality could be implemented in the hardware, in these High-End Routers that provide high throughput.
Preserve, Prepare and Prosper
Migration to IPv6 in a phased manner helps us connecting the billions of devices that are getting connected to the Internet. This transition helps to:
Preserve investments in IPv4 infrastructure, assets, and delivery models
Prepare for the smooth, incremental transition to IPv6 services that are interoperable with IPv4
Prosper through accelerated subscriber, device, and service growth that are enabled by the efficiencies and scale that IPv6 can deliver.
References
1. The China Education and Research Network (CERNET) IVI Translation – RFC 6219 http://tools.ietf.org/html/rfc6219
