Adjustments to IPv4 could free up millions of addresses • The Register
It may have been nearly three years since the world officially exhausted all available IPv4 internet addresses, but now a new initiative has been proposed that could free up hundreds of millions of addresses currently unused – or are they?
As the world slowly moves towards wider adoption of the new IPv6 protocol, which offers a large address space, the continued and widespread use of IPv4 has caused problems as all available ranges of the approximately 4.3 billion addresses it supports have been widely assigned.
Now it looks like Seth Schoen, former senior technologist at the Electronic Frontier Foundation and co-founder of Let’s Encrypt, has made proposals collectively labeled either the IPv4 Unicast Extensions Project or the IPv4 Cleanup Project (both are used on the the project’s GitHub page).
Writing in a post on the APNIC BlogSchoen detailed his proposals.
These are also described in four Internet drafts filed with the Internet Engineering Task Force (IETF), which call for four categories of “special” addresses currently unavailable for standard addressing purposes to be redefined as addresses ordinary unicasts, meaning they should no longer be considered reserved, invalid, or loopback addresses.
The reasons for the existence of these special addresses date back to the creation of the IPv4 version of the Internet Protocol in the early 1980s, but many of them have never been used for the purpose for which they were reserved, according to Schoen. , but still continued to be treated as special addresses.
These four address categories targeted by the project include the lowest address in each IPv4 subnet, 240/4, 0/8 and 127/8. Each was booked for a different reason, and Schoen acknowledges that each presents a different set of challenges to change.
Of the four, the fix lowest address is considered the least problematic. It proposes to eliminate a duplicate broadcast address within each LAN segment.
The standard broadcast address on a subnet is the highest (i.e. 255 on a 24-bit subnet which uses 8 bits for host addresses), but for historical reasons the address “zero” (i.e. 0) is also reserved, according to Schoen.
Changing this only frees up one address per subnet, but allows organizations to “take a small step to unilaterally increase the efficiency of their use of their existing IPv4 allocations”.
Other changes require software changes in IPv4 implementations, which will undoubtedly set off alarm bells among all IT administrators.
However, Schoen says some of these changes are already widely used, in particular the proposed changes for 240/4 addresses which were reserved as a Class E network block for future use, comprising a total of 256 million addresses.
Turning them into recognized unicast addresses was already proposed to the IETF over a decade ago and apparently implemented in several operating systems now running on millions of nodes on the Internet, and “caused no problem over the past decade,” he said.
The Address range 0/8 includes an additional 16 million addresses reserved for potential automatic device configuration based on ICMP messages, but these are effectively unused (except for 0.0.0.0).
Similarly, 127/8 represents another 16 million address block that has been reserved as loopback addresses, and this is maintained despite the fact that virtually all applications use only one loopback address (127.0. 0.1).
Schoen’s proposal is to reduce the range of this block so that only 127.0/16 is reserved for local loopback purposes.
Whether these changes are really necessary is debatable, since many organizations still using IPv4 will be sitting behind a network address translation (NAT) gateway that presents a small number of IP addresses to the outside world and operates a private addressing scheme on the internal network. network.
Nevertheless, Schoen believes these measures will prove useful during the interminable transition from IPv4 to IPv6, if the demand for IPv4 space continues to exist.
“We continue to encourage implementers to make the required changes and develop hotfixes to support them. These addresses will gradually become more useful as more implementations accept them as a valid address space” , he wrote. ®