Some Notes on IPv4 Address Space

Most of you will be aware there are currently several initiatives to make IPv4 address space formerly & formally considered ‘special addresses’ – and hence not to be used for common Internet traffic – usable (by some definition of ‘usable’).
The motivation behind such efforts is clear: namely depletion of RFC 1918 space within many organizations, often aggravated by insufficient assignment and distribution schemes in the past. This motivation is understandable. However there is – as will turn out for good reasons – quite some debate about this, and in this post I want to give some technical overview plus provide a bit of perspective, too.

As I laid out in my “A Brief History of the IPv4 Address Space” post the concept of ‘special addresses’ has existed for a long time. The following picture shows the current “IANA IPv4 Special-Purpose Address Registry”:

Looking at this it becomes clear that there are significant differences between them as for their function or scope. There might also be quite some differences as for the actual handling of them on network devices or hosts.

Their ‘can not be routed’ attribute might have a different scope:

  • over the Internet.
  • in transit even within seemingly isolated/closed networks.

This property of not being forwarded across specific links (as explicitly prescribed for some of them in the individual RFCs) can be enforced by different methods:

  • filtering of routing information of such networks (see e.g. RFC 1918).
  • filtering of traffic with a source address from such networks. This is the classic ‘bogon filtering’ performed in many enterprise networks on their Internet uplink devices.
  • filtering of traffic with a destination address of these blocks.

These respective methods can be implemented on different devices:

  • on routers
  • on middleboxes, for example (but not only) firewalls
  • on individual hosts (by means of a local packet filtering component or within the IP stack/on the kernel level).

Furthermore this behavior can be configurable, or not. It might be enabled by default, or not. Operators or sysadmins might be aware of the behavior and/or related config options, or not.
Some of the above intricacies are nicely illustrated in Emile Aben’s RIPE Labs article on “The Curious Case of 128.0/16”.

On the other hand looking at the numbers and the size of some of these blocks it becomes clear that a good chunk of the overall IPv4 address space belongs to the ‘Special-purpose addresses’ which, in times of IPv4 address space depletion ever getting more acute, whets the appetite of people thinking about ways to make them usable. The most prominent initiative is the “IPv4 unicast extensions project”.

The main idea here is to modify the Linux kernel (and others, but the idea was primarily presented in Linux circles) in a way that allows to use various parts of the special address space as regular unicast addresses. The line of reasoning is summarized in a slide set containing this one:

As a long-time Internet enthusiast I have to admit there’s a lot of good thoughts in that presentation. I particularly like the innovation angle and the care for startups.

Still, let’s evaluate the idea from a practitioners’ perspective. As laid out above there’s a variety of handling (usually: suppression) methods and places besides the Linux kernel for these addresses. This in turn makes it probably very hard in a sufficiently large or complex network to create full transparency if/where those addresses are filtered, especially as in the past there wasn’t much need to keep track of their actual handling (as they were dropped anyway, at some point in the network).
Honestly, even without my IPv6 hat (ok, here we are, I mentioned it 😉 ) I would be highly skeptical if the unicast-extensions approach is going to work outside small & isolated environments. E.g. how would one make sure that users from remote corporate sites connecting through different types of SOHO firewalls (different models from different ages) can actually flawlessly connect to data center located services operating on ‘extended IPv4 unicast addresses’?

Finally there’s the question if these addresses are going to be used as another block of private addresses (as the recently added support of in the Linux 5.3 kernel seems to imply) or if those are going to a new pool of ‘available IPv4 addresses’ to be distributed to the public via IANA/the RIRs. In that case, observing IPv4 address space related market dynamics in the last years, those addresses might well & soon end up in the hands of ‘the incumbents’, e.g. large cloud providers. Which wouldn’t exactly help innovators & startups then… but wait, ‘innovators’ are not exactly the population that should learn IPv4 anyway, right? 😉

tl;dr: I do not expect these addresses to be fit for (whatever) purpose within the next 24–48 months in the vast majority of environments.

Published by Enno

Old-school networking guy with a certain focus on network security. This blog is a private blog and it contains private musings, even though I have a day job around the Internet Protocol. I leave it to the valued reader to guess which version of it ;-). Some tweets on related topics at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: