IPv4 Addresses – Why Are They Running Out?

The IPv4 Address Shortage

According to Vint Cerf (the father of IP), the IPv4 32-bit address size of was chosen arbitrarily. IP was a government/academic collaborative experiment, and the current public Internet was never envisioned. The IP paradigm was that each connected device would have a unique IP address (all packets sent between IP devices would be end-to-end connected from the source IP address to the destination IP address), and many protocols using IP depend on each device having a unique IP address.

Assuming we could use every possible IPv4 address*, there are only 4,294,967,296 possible IPv4 addresses, but (as of September 2018) the current world population is 7,648,290,361. As you can see, there are not enough possible IPv4 addresses for every person to have even one, but many people have a computer, printer, cell phone, tablet, gaming console, smart TV, etc., each requiring an IP address, and that doesn’t even touch on the business needs for IP addresses. We are also on the cusp of the IoT (Internet of Things), where every device needs an IP address: light bulbs, thermostats, thermometers, rain gauges and sprinkler systems, alarm sensors, appliances, vehicles, garage door openers, entertainment systems, pet collars, and who knows what all else. All this adds up to the fact that IPv4 simply cannot handle the addressing needs of the modern world.

*There are blocks of IPv4 addresses that cannot be used for host addressing. For example, multicast has a block of 268,435,456 addresses that cannot be used for host addressing. IANA maintains the IANA IPv4 Special-Purpose Address Registry at https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml to document all the special address blocks and their purposes.

IANA (Internet Assigned Numbers Authority) ran out of IPv4 address blocks to assign to the RIRs (Regional Internet Registries) to be assigned in their respective regions, and the RIRs have now also run out of IPv4 addresses to assign in each region. ISPs (Internet Service Providers) and companies that want or need IPv4 addresses can no longer get IPv4 addresses from their RIRs and now must try to buy IPv4 addresses from businesses that may have extra (as the IPv4 address shortage deepens, the price of IPv4 addresses goes up).

Even if all the IPv4 addresses that are reserved for special purposes and cannot be used for host addressing were made available for use, we would still be in the same position because there are simply not enough IPv4 addresses due to the limited size of IPv4 addresses.

Mitigating the IPv4 Address Shortage

IANA and the RIRs would have run out of IPv4 addresses many years before they did if IANA and the IETF (Internet Engineering Task Force) had not adopted mitigations for the IPv4 address shortage. One important mitigation was the deprecation of IPv4 network classes in favor of CIDR (Classless Inter-Domain Routing). Classful addressing only allows for three assigned network sizes (16,777,216, 65,536, or 256 total host addresses per network), meaning that many addresses are wasted (a business needing only 300 host addresses would need to be allocated a classful network that has 65,536 possible host addresses, wasting over 99% of the addresses in the classful network), but CIDR allows for network sizes to fit more closely with network address requirements (a business needing only 300 host addresses could be allocated a CIDR /23 network that has only 510 usable host addresses), wasting far fewer addresses and still providing some room for growth.

By far, the mitigation that has had the biggest impact on extending the life of IPv4 is the use of Private Addressing and a variant of NAT (Network Address Translation) called NAPT (Network Address Port Translation), which is what most people mean when they refer to NAT or PAT (PAT is a vendor-specific term for NAPT). Unfortunately, NAPT is an ugly workaround that breaks the IP end-to-end paradigm, and that breaks protocols that depend on unique IP addressing, requiring even more ugly workarounds.

NAT/NAPT

The concept of NAT is pretty simple: it replaces either or both the source and destination IPv4 addresses in a packet header as the packet passes through the NAT device. In practice, it requires computation because the IPv4 header has a computed field to check the integrity of the IPv4 header, and any change made to the IPv4 header requires recalculation of the field, and some transport protocols in the packet payload also have their own computed fields that must be recalculated, using computing resources in the NAT device that could be used for packet forwarding.

In Basic NAT, the NAT device has a pool of IPv4 addresses that it uses to replace the source IPv4 addresses of the packet headers for IPv4 packets sent from an inside network to an outside network, and it maintains a translation table in order to translate the destination IPv4 addresses of traffic returning from the outside network in order to deliver the packets back to the correct hosts on the inside network. This also requires resources on the NAT device to build and maintain the translation table, and to perform table lookups. This resource utilization can slow the forwarding of packets because the resources used by NAT are taken from the resources that could be used for packet forwarding.

NAPT takes Basic NAT further by also translating the transport protocol addresses (ports) for TCP and UDP, and the Query IDs for ICMP. By also translating the transport-layer addresses, NAPT allows the use of a single outside IPv4 address for many inside host IPv4 addresses. NAPT is even more resource intensive than Basic NAT because it requires a separate table for each transport-layer protocol, and it must also perform the integrity calculations for the transport protocols.

The use of Private IPv4 addressing, that can be reused on multiple networks (you may have noticed that most home/residential networks default to use the same 192.168.1.0/24 network, which is in one of the IANA allocated Private IPv4 address ranges), along with NAPT, allows business and home users to each use a single outside (public) address for a large inside (privately addressed) network. This saves many, many IPv4 addresses (several times the total number of possible IPv4 addresses) and has extended the life of IPv4 far beyond the point at which it would have collapsed without NAPT. NAPT does have some serious drawbacks:

• NAPT breaks the IP end-to-end paradigm, and it only works with TCP, UDP, and ICMP, breaking other transport protocols. There are also application-layer protocols that use TCP or UDP that are broken by NAPT, even though TCP and UDP nominally work with NAPT. Other mitigations, e.g. STUN/TURN, may be available for some application-layer protocols, but they can add cost and complexity.
• NAPT is very resource intensive, slowing packet forwarding compared to what is possible without using any form of NAT. Some vendors add dedicated hardware to mitigate the need to steal resources from packet forwarding, but this comes at added expense, size, complexity, and power usage.
• When using NAPT, traffic initiated from outside the NAPT network cannot be delivered to the inside network because there is no translation entry in the translation table, which is added by inside-initiated traffic. The single outside (public) address is configured on the NAT device, and any packets with that destination IPv4 address and no entry for the source IPv4 address in the translation table for the transport protocol is assumed to be for the NAPT device, itself, not the inside network. There is a mitigation, called Port Forwarding, for this problem.
• Port Forwarding basically configures, manually, a permanent entry in a translation table to allow outside-initiated traffic that is destined to a particular transport protocol and address for the protocol to be delivered to a particular inside host. This does have the drawback of only allowing one inside host to be the target for a particular transport protocol and address. For example, if there are multiple web servers on the inside network, only one of the web servers can be exposed on TCP port 80 (the default for web servers).
• Because the IPv4 address shortage is so severe, the ISPs (Internet Service Providers) are running out of public addresses to assign to their customers. The ISPs can no longer get any more public addresses, so they have adopted some mitigations that especially hurt home/residential users. The ISPs want to reserve their precious public address pool for their business customers that are willing to pay for the privilege of getting public addresses. To do that, the ISPs are now starting to assign Private or Shared addresses to their home/residential customers, and the ISPs use NAPT on their own routers to facilitate the use of multiple Private or Shared addresses on a single public address. That creates a situation where a home/residential network is behind two NAPT translations (ISP NAPT to customer NAPT), and port forwarding configured by the customer on the home/residential router no longer works because it is broken by the ISP NAPT, which is not configured to forward the port to the customer router.
• Many people make the mistake of equating NAPT and security because the inside hosts cannot be directly addressed from outside. This is a false sense of security. Because a firewall connecting a network to the public Internet is a convenient place to run NAPT, that simply confuses the situation. It creates a dangerous perception that that NAPT, itself, is the firewall, and a real firewall is unnecessary. Network security comes from firewalls, which block all outside-initiated traffic by default, only allowing traffic it is explicitly configured to permit, possibly doing a deep inspection on the packet contents to drop dangerous packet payloads. What some people fail to realize is that, without a firewall, either in hardware or software, on the outside of or built into the NAPT device, to protect the NAPT device, the NAPT device itself is vulnerable. If the NAPT device is compromised, it, and by extension an attacker, has full access to the privately addressed inside network. Outside-initiated packets that do not match a translation table are destined to the NAPT device, itself, because it is the device that is actually addressed with the external address, so the NAPT device can be directly attacked.

The Solution to the IPv4 Address Shortage

The IETF predicted the IPv4 address shortage, and it created the solution: IPv6, which uses 128-bit addresses, meaning there are 340,282,366,920,938,463,463,374,607,431,768,211,456 (340 undecillion) possible IPv6 addresses. The almost unimaginable number of IPv6 addresses removes the need for NAPT (IPv6 doesn’t have any NAT standards, the way IPv4 does, and the experimental IPv6 NAT RFC specifically forbids NAPT), restoring the original IP end-to-end paradigm. The mitigations for the IPv4 address shortage are meant to extend the life of IPv4 until IPv6 is ubiquitous, at which point IPv4 should fade away.

Humans cannot really comprehend numbers of the size used for IPv6. For example, a standard IPv6 network uses 64 bits for each of the network and host portions of the network address. That is 18,446,744,073,709,551,616 possible IPv6 standard /64 networks, and that same (huge) number of host addresses for each of those networks. To try to understand a number that large, consider tools that scan all the possible addresses on a network. If such a tool could scan 1,000,000 addresses per second (unlikely), it would take over 584,542 years to perform the scan on a single /64 IPv6 network. Currently, only 1/8 of the total IPv6 address space is allocated for global IPv6 addresses, which works out to 2,305,843,009,213,693,952 standard IPv6 /64 networks, and if the world population is 21 billion in the year 2100 (a somewhat realistic number), every one of those 21 billion people could have 109,802,048 standard IPv6 /64 networks, each network having 18,446,744,073,709,551,616 possible host addresses. Unfortunately, the (decades of) IPv4 address shortage has so ingrained address conservation in people, that many people simply cannot let it go, and they try to apply it to IPv6, which is pointless and actually detrimental. IPv6 is actually designed to waste addresses.

The IETF also had the advantage of hindsight, and it improved IP (in IPv6) by removing features of IPv4 that didn’t work well, improving some IPv4 features, and adding features that IPv4 didn’t have, creating a new and improved IP. Because IPv6 is a completely separate protocol from IPv4, it can be run in parallel with IPv4 as the transition is made from IPv4 to IPv6. Hosts and network devices can run both IPv4 and IPv6 on the same interface at the same time (dual-stacked), and each is invisible to the other; there is no interference between the two protocols.

The problem with IPv6 is that it is actually a completely different protocol that is incompatible with the ubiquitous IPv4, and the mitigations for the IPv4 address shortage are seen by many people to be “good enough.” The result is that it has been over 20 years since IPv6 was standardized, and we are just now getting some real traction in using IPv6 (Google reports, as of September 2018, worldwide IPv6 adoption of over 20%, and the IPv6 adoption rate in the U.S. is over 35%). The reason we are finally moving to IPv6 is that there are simply no more unused IPv4 addresses to be assigned.

There are other obstacles, all part of the IPv4 culture, that are simply hard for people to look past. Many people are also scared of IPv6, having grown up and being comfortable with IPv4, warts and all. For example, the IPv6 addresses appear to be large and ugly compared to IPv4 addresses, and that seems to put many people off. The reality is that IPv6 is often easier and more flexible than IPv4, especially for addressing, and the lessons learned in IPv4 have been applied to IPv6 from the beginning.