Carrier Grade NAT (CGN) and Large Scale NAT (LSN) are often presented as "IPv6 Transition Technologies". In reality CGN, LSN, or any other mechanisms that provide IPv4-to-IPv4 connectivity on Network Address Translator (NAT) platforms (i.e. NAT444) are NOT transition mechanisms to IPv6. They are technologies to prolong IPv4 address availability by using private IPv4 address space in Service Provider (SP) networks.
Some SPs may need to deploy CGN/LSN to manage the IPv4 address shortage in their networks while deploying IPv6 services to customers. However, SPs who do not deploy IPv6 services simultaneously with CGN/LSN will need to revisit the same issue in a few years' time and resolve the same scaling problem as their customer base continues to expand. If there is no IPv6 in customer access networks then customers cannot secure IPv6 reachability.
Deploying CGN/LSN without deploying IPv6 services come with some of the negative consequences of using NAT:
- Breaks the end-to-end model of IP
- Breaks end-to-end security
- Serious consequences for lawful intercept
- Non-NAT friendly applications mean more upgrades
- Mandates the network keeps the state of the connections
- Difficult to scale NAT performance for large networks as number of available ports per customer is restricted
- Makes fast rerouting and multihoming difficult
Deploying CGN/LSN in IPv4-only SP networks will likely create a "double NATed" environment, as most Customer Premise Equipment (CPE) already have NAT functionality. This further increases the complexity of networks, compounding the negative impacts described above. More disadvantages:
- The SP needs a large, costly NAT device in the aggregation or core layers
- Technical drawbacks of NAT (above)
- Sharing IPv4 addresses among multiple users could increase behavioural, security, and liability implications
- Multiple NATs can create difficulties in tracking the association of port/address and subscriber, not to mention lawful intercept issues and increased difficulty for network troubleshooting
- Prevents subscribers from using IPv6 content, services, and applications
As it is described above, it is best for SPs to avoid deploying IPv4-to-IPv4 CGN/LSN. However, if CGN/LSN is required, the SP needs to also deploy IPv6 simultaneously to ensure business continuity. There are several transition technologies available, including Dual-Stack, NAT64, DS-Lite, 6RD, etc.
Dual-Stack is the simplest option from an operational standpoint; however, it may take multiple iterations of transition mechanism deployments to reach that final goal. To minimize operation complexity during the transition period, it is important to minimize the number of iterations of transition technology implementation on the road to a native IPv6 network. This will help to minimize capital and operating expenditures.
The most optimal way to manage the IPv6 transition process is to deploy IPv6 support and connectivity for new subscribers. Many SPs have adopted this strategy, allowing them to provide IPv6 services by default. Read more about their experiences in IPv6 Transition Stories and IPv6 Best Current Practices.
- RFC7021: Assessing the Impact of Carrier-Grade NAT on Network Applications (Sept 2013)
- Internet Access Pricing in a Post-IPv4 Runout World, Lee Howard, Time Warner Cable (.docx)
- White Paper: The Business Case for Delivering IPv6 Services Now, Cisco (PDF 0.8MB)
- IPv6 Transition Technologies, Alastair Johnson, Alcatel Lucent (PDF 2.2MB)
- How can Network Operators face IPv4 address exhaustion? Dr Philip Smith, APNIC (PDF 1.5MB)