Alternative Re: ipv4/25s and above Re: 202211201009.AYC

John Gilmore gnu at toad.com
Sun Nov 27 22:49:10 UTC 2022


John Curran <jcurran at istaff.org> wrote:
>> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>
> ... this Internet draft ... can't be safely deployed in the actual
> real-world Internet

The draft *has been* safely deployed in the actual real-world Internet.
It is in all Linux nodes since 2008, and all recent Cisco routers.  We
know that this step is safe, because it was already done a decade ago,
and the Internet did not descend into flames (except on mailing lists
;-).  The draft is just trying to help the paperwork catch up with the
implementations.

So it seems that John Curran was criticizing a strawman rather than the
draft above (which I co-authored).  Perhaps the confusion is that John
thought that the draft would actually allocate 240/4 addresses to
end-users for end-user purposes.  Doing that would be unsafe in today's
big Internet (though major squatters are already using these addresses
in private clouds, as RIPE and Google have documented).  Allocating
these addresses would be far more controversial than just updating the
code in IPv4 implementations.  Therefore, the draft doesn't do that.
Instead it would just clear out the cobwebs in implementations, which
would some years later, after more work, allow a responsible party to
make such allocations.  John's suggestion that "it's unsafe to do this
safe change, because we don't yet know *when* some later change will be
safe" is simply incorrect.

Perhaps what the draft failed to explain is that "Merely implementing
unicast treatment of 240/4 addresses in routers and operating systems,
as this draft proposes, does not cause any interoperability issues.
Hundreds of millions of IPv4 nodes currently contain this unicast
treatment, and all are interoperating successfully with each other and
with non-updated nodes."  We'll add something like that to the next
version.

	John Gilmore
	IPv4 Unicast Extensions Project
	


More information about the NANOG mailing list