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@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.

I guess that others already expressed all arguments in favor and against the idea and they all sounds rational so bigger problem is to express what has bigger value for us. Personally, from perspective of company with global dual-stack platform, I would like to spend my time and energy on IPv6, automation, RPKIs, prefix leaks, providers relationships and prefix propagation rather than on figuring out how to prolong IPv4 life. Enabling 0/8 and 240/4 sounds simple but it requires global coordination to make it work and we already have community fully occupied with other activities. I think that decision about enabling 240/4 should be made 15-20 years ago and now it's too late to make the effort worth it (it will take years to implement). Still I can imagine that we have anti IPv-6 providers desperate enough to use 240/4 instead of paying for prefixes on the second hand market of IPv4. For these folks RIPE Atlas with enabled 0/8 and 240/4 would be a useful feature to troubleshoot problems which they will for sure face as early adopters. Regards, Grzegorz From: Robert Kisteleki <robert@ripe.net> Organisation: RIPE NCC Date: Tuesday 2021-02-16 at 15:52 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Cc: Seth David Schoen <schoen@loyalty.org> Subject: Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses 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.