[atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses

Hi,

some may find it controversial, but I don't think any effort should be
spent at extending the life of IPv4. In this case, by extending the address
space.

On Tue, Feb 16, 2021 at 4:52 PM Robert Kisteleki <robert at ripe.net> wrote:

> Dear All,
>
> A little bit of poking since there were no reactions to this question on
> the MAT mailing list.
>
> Before embarking on evaluating what it takes for RIPE Atlas to
> contribute to this, I'd like to ask for some input from the community;
> is this something we should spend energy on? More specifically, would it
> be worthwhile for us to spend time on evaluating the cost of /
> implementing such measurements in RIPE Atlas?
>
> Regards,
> Robert Kisteleki
>
>
>
> On 2021-01-26 08:28, Seth David Schoen wrote:
> > 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.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20210216/c2126527/attachment.html>