Hi mat-wg,
I'm Seth, formerly a staff technologist at EFF and one of the
co-developers of Let's Encrypt and Certbot.
Recently, I've been working with John Gilmore on the IPv4 Unicast
Extensions Project, which aims to make some of the IPv4 address blocks
that were reserved in the 1980s and 1990s (and that continue to be unused,
or nearly so) available for addressing and routing on the Internet.
This project involves many different kinds of work, including writing
software patches to make various OSes and devices willing to generate
and accept packets to reserved addresses, writing Internet-Drafts to
describe addressing policy changes with IETF, testing devices to see how
they actually treat such packets, talking to various constituencies
about these proposals, and working with the Internet measurement
community to understand how the Internet as a whole treats packets to or
from currently-reserved address ranges, and how that treatment evolves
over time.
Two prominent examples that are already supported by Linux hosts are the
netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use").
According to Internet standards created in the 1980s and still in
effect, these address ranges cannot be allocated and should not be
assigned to hosts or used on the public Internet. However, several key
implementations started allowing 240/4 addresses about 11 years ago
during an earlier IETF attempt to open up that netblock, including
Linux, Android, macOS, iOS, and Solaris. In 2019, Linux kernel version
5.3 allowed ordinary unicast use of 0/8. Today, there are rumors that
various organizations are currently using such reserved addresses as
unofficial RFC 1918-like private address space, without formal policy
coordination with anyone. (There is even some public documentation from
Google suggesting making private use of 240/4.)
I participated in the Atlas probe deployathon in November and
successfully got a probe up and running. I have also been talking to
a few RIPE people about our interests and managed to confirm that
(regardless of their underlying OS or network treatment) the Atlas
software probes will reject probing any reserved address space, while
the backend infrastructure will refuse to ask probes to connect to it.
So, I'm here to introduce our project and ask the community's view about
removing these restrictions so that such addresses can actually be
probed and measured. We understand and hope that the majority of such
tests would currently result in errors. Even the errors themselves
could be interesting: for example, we would like to know how often
routing to reserved address ranges fails on a probe host, versus on the
probe host's first-hop router, versus inside of ISP infrastructure. We
would also like to see how this changes over time as a result of OS
software changes that roll out into the field. We would also like to
see whether we can detect unofficial use of particular reserved address
ranges as private address space. Our medium-term goal is to advertise
global routes to portions of these reserved address spaces, and use the
probes to assess how well those routes propagate through the Internet,
and find where blockages occur. Clearly, we can't do this until both
the probe firmware, and the central dispatcher, allow tests to these
addresses. Our long-term goal is to have these addresses treated as
ordinary unicast addresses by all nodes, including Atlas probes, so the
Atlas changes to remove the restrictions would be useful permanent
changes.
