Victor Pellan

IPv4 address exhaustion: What are the consequences for the users?

In 2019, the European IP address allocation organization, the RIPE NCC, announced that it no longer had available IP address blocks. This announcement officially confirms the IPv4 address exhaustion in the world, following Africa in 2017, North America in 2015, Latin America in 2014, and Asia-Oceania in 2011. However, for a user wanting to connect a new device to the internet, they will not encounter any difficulties and will not notice any significant differences between 2018 and today. Similarly, there don't seem to be any differences for a new customer subscribing to an Internet Service Provider (ISP). This article will explain what this exhaustion means, what measures are currently in place to address it, the known solutions, and attempt to explain why the situation is becoming concerning not only for industry players but also for consumers. Brief history of the Internet Protocol (IP): In 1981, the first non-experimental version of the Internet Protocol, IPv4 [RFC 791], was described and implemented starting from 1982. It uses 32-bit addresses, limiting the number of available addresses to less than 4 billion (excluding the 324 million addresses reserved over the years). However, until 1989, the internet was primarily used in military and academic contexts until the first commercial ISP emerged. Since then, the depletion of the address space was anticipated, and during the following decade, methods to delay this depletion and alternatives were developed, with two of them becoming particularly important: NAT and IPv6. NAT (Network address translation) [RFC 3022] is a method that allows connecting a private network (composed of private addresses [RFC 1918]) to a single public address through a NAT router that performs address translation, port forwarding, connection tracking, etc. The implementation of NAT is not standardized, so the functions may vary across NAT routers. To the rest of the world, an entire network connected to the same NAT appears as a single device, and it is the router's responsibility to correctly forward the received data. On the other hand, IPv6 [RFC 8200] is not intended as a temporary solution like NAT but rather as a replacement for IPv4. It uses 128-bit addresses instead of 32 bits, significantly increasing the number of available addresses from 4 billion to 340 undecillion (or 340 x 10^36). However, the challenge is that, when IPv6 was defined in 1996, such a replacement seemed feasible, but more than 25 years later, it is much more complicated and time-consuming to replace the existing networks. Current state of the Internet: As of June 2020, less than 30% of networks connected to the internet support IPv6. For an IPv6 network to communicate with an IPv4 network and vice versa, it is necessary to use "hacks" such as IPv6 tunnels within the IPv4 network (6in4) [RFC 4213] or IPv6 <-> IPv4 address translators (NAT64) [RFC 6146]. These solutions greatly complicate existing networks, whereas the transition to IPv6 was intended to simplify them. It becomes evident that having only an IPv6 address would pose serious connectivity issues with the rest of the network. For this reason, all ISPs providing an IPv6 address also provide an IPv4 address. The only exceptions are mobile networks, as the 4G specifications make IPv6 usage mandatory and IPv4 optional and obsolete. However, most of these networks still use NAT to connect to the rest of the IPv4 network. ISPs continue to assign IPv4 addresses despite the exhaustion through various solutions. The two main solutions are Dynamic Host Configuration Protocol (DHCP) and Carrier-grade NAT (CGN). DHCP [RFC 2131] is a protocol introduced in 1993 that automatically assigns an IP address to a device (typically a router) when it connects to the network. Thus, an ISP can dynamically assign an IP address only when the device is connected to the network and have more clients than available addresses. However, this protocol, although still used for administrative purposes, only partially solves the problem, as devices are rarely disconnected today. The second solution, which is now preferred, is CGN. CGN [RFC 6888] involves deploying NAT on a large scale. Instead of assigning an IP address per household, it is possible to assign a single IP address per residence, building, street, neighborhood... What are the disadvantages and repercussions of NAT and CGN? NAT breaks several principles and conventions, such as the OSI model rule that requires the separation of different network layers, whereas NAT operates at both the network and transport layers in the simplest cases. It also breaks the "end-to-end" principle, which states that functions verifying data reliability and security should be located at the network endpoints, with intermediate nodes like routers performing only simple functions. However, an average user is not affected by these broken principles and conventions. On the other hand, there are several aspects that can significantly impact a user. A NAT stores information it transmits to correctly forward data upon reception, which poses serious issues of security, reliability, and scalability. This can result in slower and less stable connections for the user. To overcome the inevitable port-forwarding blockage caused by CGN, the Port Control Protocol (PCP) [RFC 6887] was introduced, allowing sending a port mapping request to a CGN. Although PCP resolves the port-forwarding issue, it is another "hack" that potentially introduces security and scalability problems. Lastly, in the case of CGN, bans (in games, forums, applications...) based on a user's IP address connected to that CGN will result in blocking all households using the same public IP address, meaning connected to the same CGN. Conclusion: Faced with these problems, a simple solution emerges: the transition of the majority of IPv4 networks to IPv6. Although this solution is not perfect (removing all intermediate steps would cause problems for mobility, i.e., maintaining the same IP address while changing base stations), it would still resolve most of the encountered problems and replace the "hacks" used in anticipation of the IPv4 address exhaustion. This transition would improve the user experience for everyone and spare technicians, engineers, and researchers from numerous headaches. Bibliography: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.zakon.org/robert/internet/timeline/ http://v6asns.ripe.net/v/6?s=_ALL http://www.hawa.work/426/14%20DHCP%20and%20NAT.pdf https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20200708