There is never enough. Whatever you name in the world of networking, there is simply not enough. There are not enough ports. There is not enough speed. There is not enough bandwidth. Many times, the problem of ‘not enough’ manifests itself as ‘too much’ — there is too much buffering and there are too many packets being dropped.
Not so long ago, the Internet community decided there were not enough IP addresses and decided to expand the address space from 32 bits in IPv4 to 128 bits in IPv6.
The IPv6 address space is almost unimaginably huge — 2 to the 128th power is about 340 trillion, trillion, trillion addresses. That is enough to provide addresses to stacks of 10 billion computers blanketing the entire Earth. Even a single subnet of this space is enough to provide addresses for a full data centre where hundreds of virtual machines are being created every minute; each /64 (the default allocation size for an IPv6 address) contains 4 billion IPv4 address spaces.
But, what if the current IPv6 address space is not enough? As it so happens, engineers working in the Internet Engineering Task Force (IETF) have created two different solutions over the years for just this eventuality.
In 1994, RFC 1606 provided a ‘letter from the future’ describing the eventual deployment of IPv9, which was (in this eventual future) coming to the end of its useful lifetime because the Internet was running out of numbers. In RFC 1606, it is noted that IPv9’s 42 levels of hierarchy had proven popular, but not all the levels had found a use. The highest level in use seems to be level 39, which was being used to address individual subatomic particles.
“The up to 42 deep hierarchy of routing levels built into IPv9 must have been one of the key features for its wide deployment. The ability to assign a whole network, or group of networks to an electronic component must be seen as one of the reasons for its takeup. The use of the Compact Disk Hologram units is typical of the usage. They typically have a level 37 network number assigned to each logical part, and a level 36 network number assigned to the whole device. This allows the CDH management protocol to control the unit as a whole, and the high-street vendor to do remote diagnostics on discreet elements of the device. This still allows sub-chip routing to be done using the 38th level addressing to download new nanocode. As yet, no requirement has been found for levels 40-42, with level 39 still being used for experimental interrogation of atomic structure of components where required.”
Part of the dwindling address space considered in RFC 1606 was the default allocation of about 1 billion addresses to each household. As the number of homes built increased globally, the IPv9 address space came under increasing pressure. The allocation of groups of addresses to recyclable items was not helpful, either, regardless of the ability to multicast ‘all cardboard items’ in a recycling bin.
An alternate proposal, written many years later, is RFC 8135, which considers ‘complex addressing in IPv6’. RFC 8135 begins by describing the different ways in which a set of numbers (such as the 128-bit space in the IPv6 address) can be represented, including integers, prime, and composite. Each of these is considered in some detail but eventually rejected for various reasons. For instance, integer (or fixed point) addresses are rejected because the location of a host is not fixed, so fixed point addresses are a poor representation of the host. Prime addresses are likewise rejected because they take too long to compute, and composite addresses are rejected because they are too difficult to differentiate from prime addresses.
RFC 8135 proposes a completely different way of looking at the 128-bits available in the IPv6 address space. Rather than treating IPv6’s address space as a simple integer, the specification advocates for treating it as a floating number. This allows for a much larger space, particularly as aggregation can be indicated through scientific notation.
The main problem the authors note with this proposal is users may believe that when they assign a floating address to their device, the device itself thereby becomes waterproof and ‘floating’. The authors advise users to count on a waterproofing app (available in most app stores) for this function, rather than counting on the floating address. The authors also note that duct tape can be used to permanently attach a floating address to a fixed device if needed.
The danger, of course, is that network designers, network operators, and protocol designers could end up embracing the ridiculous in the quest for ‘more’.
It all brings to mind the point Andrew Tanenbaum made in a standard work on networking. In Computer Networks, Tanenbaum calculates the bandwidth of a station wagon full of magnetic tape (specifically, VHS format) backups. After considering the amount of time it would take to drive the station wagon across the continental United States of America, he concludes the vehicle has more bandwidth than any link available at that time. A similar calculation could be made with a mid-sized shipping box available from any overnight package carrier, filled with SSD drives (or similar). The conclusion, according to Dr Tanenbaum, is networks are a sop to human impatience.
As there is no bound to human impatience, no matter how much you have, as RFC 1925 says, you will always need more.
This post was adapted from the original at Rule 11.
Russ White is a Network Architect at Juniper Networks.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.