Residential Network Address Translation (NAT)
Pervasiveness of IPv4 Network Address Translation (NAT) and continued scarcity of IPv4 addresses has resulted in organizational addressing challenges. Organizations desire a globally unique address space to support their businesses, but IPv4 addresses are increasingly secluded in enclaves making them localized.
The diagram below shows a familiar end-to-end network topology often drawn during a troubleshooting exercise. A residential broadband client sits on the left side safely sequestered behind their consumer-grade router with its stateful packet filter. Their Internet provider connects them to the public Internet. The server in a co-location data center on the right is behind another stateful firewall performing a one-to-one static NAT.
The subscriber network uses one portion of the private address space and if everything within that residence has a unique address within that home network prefix everything is great. The same is true for the server farm; no overlapping addresses. In this diagram, there are three different domains of IPv4 addresses that require unique addressing, the client, public Internet and server co-location networks. Within each domain the addresses assigned to nodes must be unique and are only locally-significant to that one domain. The nodes in the other domains have no knowledge of the addresses used in the other domains. The significance of the IP address is local to within that address domain bordered in each instance by NAT.
Enterprise Network Address Translation (NAT)
When it comes to two enterprises communicating with each other over the Internet, they can each use overlapping 10.0.0.0/8 addresses within their private networks. So long as they are performing NAT on their perimeter firewalls, they can communicate using protocols like HTTP that allow for the changing of the source IP address. The diagram below shows this topology of domains with locally-significant addressing.
Since all enterprises are using NAT at their perimeters, their addresses are “locally significant” to the internal enterprise networks and, as a result, the end-to-end addressing model is not enabled. When enterprises need to collaborate or with a worldwide economy of partners, suppliers, customers, their options are limited. Mergers and acquisitions are messy at best, and nearly impossible at worst. Enterprises are up against a rock-and-a-hard-place and may soon need to investigate using multiple-layers of NAT internally just like the Internet Service Providers (ISP). This adds operational overhead, increased troubleshooting times, and the cost of the Carrier-Grade NAT (CGN)/Large-Scale-NAT (LSN) equipment.
Enterprises felt that they would never exhaust their supply of private RFC 1918 IPv4 addresses. For example:
- 10.0.0.0/8 gave them 224 (or 16,777,216) addresses
- 172.16.0.0/12 gave them 220 (or 1,048,576) addresses
- 192.168.0.0/16 gave them 216 (or 65,536) addresses
What they didn’t anticipate was the inefficiency of hierarchical addressing (with or without summarization) and the subnetting “tax” whereby additional host addresses are lost through subnetting. Also, most enterprises failed to get high utilization percentages on their internal /24 subnets. High address utilization can be difficult to achieve on wired LANs, but in wireless networks, organizations must dramatically reduce the DHCP IPv4 lease times. Years ago, DHCP lease durations used to be a week, now they are often set to 24 hours. In some environments, the lease-time may be as short as 4 hours (with renewal occurring at half the lease-time, thus every 2 hours).
Just because your laptop has a private IPv4 address, it isn’t yours for long. You are just temporarily borrowing it, kind of like a parking space. IPv4 addresses are ephemeral and some organizations struggle to accurately determine which device had an IPv4 address at a particular point-in-time.
Large-Scale Network Address Translation (NAT)
Below is a diagram of another plausible scenario where the service provider is using the IANA-Reserved IPv4 Prefix for Shared Address Space (RFC 6598) 100.64.0.0/10 within their network. The service provider employs a Carrier-Grade NAT (CGN)/Large-Scale NAT (LSN) system at their Internet perimeter and use the 100.64.0.0/10 prefix for allocating addresses to subscribers’ routers or mobile subscriber devices. Within the cloud service provider infrastructure on the right, an application load balancer function defines the boundary for the “10-net” (in this example: 10.1.0.0/16) addresses used for cloud server instances.
This scenario could affectionally be referred to as NAT4444. In this scenario, there are four different addressing domains with their own locally-significant addressing. Each domain has no awareness of the addressing used in the other domain. The cloud load balancer receives numerous connection requests but has no confidence in the authenticity of the client IP address in the HTTP(S) header.
There are downsides of this type of a NAT4444 scenario that can negatively impact applications (RFC 7021). There have been many presentations on the impacts of Carrier-Grade NAT on various applications. Using so many NATs along the traffic path can make troubleshooting difficult, if not impossible. Therefore, some network engineers are interested in methods of detecting NAT4444 occurring along the traffic path.
IPv4 Address Scarcity within Private Enterprise Networks
Large enterprises are starting to experience difficulties using private IPv4 addresses due to the inefficiency of hierarchical addressing as well as subnetting overhead. Not only are their public IPv4 addressing resources limited, but so too is their use of private RFC 1918 reserved address space. Their internal private address space is becoming more saturated and densely populated. Inefficient internal private IPv4 addressing can quickly exhaust the 10.0.0.0/8 range. Some large organizations have exhausted their supply of “10-net” addresses and this becomes more important as enterprises try to deploy cloud infrastructure and create hybrid-IT connectivity (not to mention attempting to deploy any IoT solutions internally with such a limited supply of addresses).
Large organizations are now desperately seeking solutions to their addressing shortage. Even enterprises are now considering using 100.64.0.0/10 (RFC 6598) IPv6 transition space, that is intended only for ISPs. Netflix is already doing this in their AWS virtual networks because they don’t have enough 10-net addresses for their cloud infrastructure. The problem with this practice is that this IPv4 address block is specifically intended for service providers to facilitate their deployment of IPv6 for their customers. It is not intended for enterprises to use as a substitute for typical private or public IPv4 addressing for services but rather is supposed to be used for IPv4 as a Service (v4aaS) (see blogs part 1, part 2, part 3). Soon enterprises may find that if they use 100.64.0.0/10 addresses (say for example in their branches or remote offices), conflicts may occur with their service provider which may also be using 100.64.0.0/10 addresses for its broadband Internet connections to SOHO subscribers.
Recently, a large enterprise asked me what I thought about them using the U.S. DoD’s 7.0.0.0/8 within their enterprise networks. Since this address space is not advertised with BGP to the default-free-zone Internet backbone routing tables, their feeling was that this was “safe” to use internally. I fervently discouraged this practice.
In the early 2000s, large enterprises were starting to consider using 1.0.0.0/8 and 2.0.0.0/8 internally, but then due to address exhaustion, these addresses were assigned to RIRs and allocated to companies. As a result, if your enterprise is employing this bad practice by using these previously unallocated and unassigned blocks, you may start to experience problems.
Desperate organizations are also revisiting RFC 2544, titled Benchmarking Methodology for Network Interconnect Devices. This RFC noted that the IPv4 address range 198.18.0.0 through 198.19.255.255 (198.18.0.0/15) could be used for benchmark performance testing. Now organizations are considering using this in their private networks (and also considering additional reserved ranges identified in IETF RFC 5735 Special Use IPv4 Addresses). Enterprises may also be considering the purchase of addresses on the open market and going through the address transfer process, but each year that becomes a more expensive proposition. Often, the public reputation of the IPv4 address blocks that are for sale on the transfer market have poor reputation and are often found on block lists, thus making them unusable.
IPv6 For The Win
For more than a decade, the Internet Society (ISOC) and the five RIRs have been encouraging organizations to obtain IPv6 addresses and to start using them. However, many enterprises continue to dismiss the warnings that the Internet has reached some absolute constraint due to the lack of IPv4 addresses. Most organizations dismissed IPv6 in the early 2000s when they first heard of it. Their thinking was that they would use NAT at the perimeter:
- to give themselves more usable private addresses
- to use the statefullness of the outbound NAT to keep the Internet from “learning” about their internal routing topology
What they didn’t anticipate was:
- the deluge of internal devices on the access networks with the advent of wireless LANs; e.g., smart-phones and tablets and now the influx of IoT devices
- virtualization driving higher densities of systems in the data center and the “stretching” of the data center networks to remote facilities or cloud infrastructure
The fact is that IPv6 provides an abundance of globally unique addresses for any possible conceivable application. IPv6 relieves the pressure on addressing that all organizations are experiencing. The absence of the necessity for NAT in IPv6 networks makes for a reduction in the anonymity of bad-actors on the Internet and a restoration of the end-to-end model.
Consider the diagram below that shows the same types of environments described above, but now all using IPv6 addresses from the global unicast address (GUA) space 2000::/3.
The simplicity of IPv6 addressing schemes as well as the ubiquity of IPv6 support in hosts, network devices, and service provider networks makes IPv6 deployment more achievable than ever.
Conclusions:
“Local significance” is a term that was first used with Frame Relay DLCIs, ATM VPIs/VCIs, MPLS labels, and Ethernet MAC addresses. However, now the term “locally-significant” also applies to how we use IPv4 addresses today. Contemporary use of multiple layers of NAT has made IPv4 addresses ephemeral and domain-specific.
IPv6 offers a refreshingly simple global addressing model and an abundance of addressing resources for any possible application that consumers, enterprises, service providers, and content providers could dream of.
All organizations should be making progress toward IPv6 adoption to start to relieve their long-term dependence on IPv4 addresses. The 12-step journey to an IPv6-only network starts with the first step, admitting you have an IPv4 address dependency problem.
Scott Hogg (@ScottHogg) is CTO of HexaBuild.io, an IPv6 consulting and training company. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF) and authored the Cisco Press book on IPv6 Security. Follow HexaBuild on Twitter and LinkedIn.
