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

Hi Robert, 

my 2c: I don't think that any effort should be spent trying to ride a dead horse. The sooner IPv4 finally becomes obsolete, the better.

Best regards, 

  Peter.

> On 16. Feb 2021, at 15:51, 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.
>