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