WKBI #586, Redploying most of 127/8 as unicast public

David Conrad drc at virtualized.org
Thu Nov 18 18:02:01 UTC 2021


On Nov 18, 2021, at 9:00 AM, John R. Levine <johnl at iecc.com> wrote:
>> The only effort involved on the IETF's jurisdiction was to stop squatting on 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly be better used elsewhere by others who may choose to do so.
> 
> The IETF is not the Network Police, and all IETF standards are entirely voluntary.

True…

> Nothing is keeping you from persuading people to change their software to treat class E addresses as routable other than the detail that the idea is silly.

Of course, it’s not quite that simple.

First, https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml <https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml> would need to be updated, then the RIRs would need to issue a request according to https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en <https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en>. At that point, existing requests lodged at the RIRs could be fulfilled using the formerly reserved space. Network operators that received the allocations could then number their devices with the new address space and announcing that space into the routing system.

Of course, there are probably an unknowable number of “bogon” filters out there that are hardcoded into various bits of infrastructure that would need to be updated. There are also various hardware, firmware, and software IP stack implementations, perhaps sitting in closets somewhere, that still think they can’t use reserved space that would need to be updated/replaced.

As far as I can tell, assertions about the scale of that update/replace exercise are based on limited data. Perhaps as an alternative to declaring various chunks of reserved space as free for use, a chunk of that space could be allocated to one or more of the RIRs and announced with a set of services placed upon it to see just how much actually breaks, similar to what APNIC and Cloudflare did with 1.1.1.0/24?

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211118/d5d60e24/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211118/d5d60e24/attachment.sig>


More information about the NANOG mailing list