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 <[email protected]> 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. >
