202203071610.AYC Re: Making Use of 240/4 NetBlock

Abraham Y. Chen aychen at avinta.com
Sat Mar 12 16:15:36 UTC 2022


Hi, Bill:

1)    Thanks for confirming my understanding of the 240/4 history. 
Basically, those in charge of the Internet appear to be leaving the 
community in the state of informal debates, since there is no more 
formal IPv4 working group.

2)    On the other hand, there was a recent APNIC blog that specifically 
reminded us of a fairly formal request for re-designating the 240/4 
netblock back in 2008 (second grey background box). To me, this means 
whether to change the 240/4 status is not an issue. The question is 
whether we can identify an application that can maximize its impact.

https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/

3)    " ... Changes to hardware and software to make use of 240/4 as 
ordinary unicast IP addresses can and should proceed in parallel to such 
debate. ":     Agreed. Since through the EzIP Project, we have 
identified that the hardware does not need change, and the software 
modification is minimal, we should proceed to discuss what is the best 
application for the 240/4 netblock, after is re-classified as an 
ordinary unicast address pool.

Regards,


Abe (2022-03-12 11:15)


On 2022-03-11 11:34, William Herrin wrote:
> On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen<aychen at avinta.com>  wrote:
>> 1)    Thanks for the reference. However, Informative Reference 7 of our IETF Draft cites another IANA document which puts the initial date of the 240/4 topic back to 1981-09 which was much earlier, in fact, coincided with that of RFC 791.
> Hi Abraham,
>
> As I said, RFC1112 documents the _most recent_ standards action with
> respect to 240/4. The earlier RFC 791 you mention described 224/3
> (which included 240/4) as "escape to extended addressing mode" which
> it specified as "undefined" and "reserved for future use." RFC 988
> then redefined and split 224/3 into "class D" and "class E" addresses,
> defined "class D" as multicast and "class E" as reserved for future
> use without any particular purpose. This saw updates in RFC1112 which
> has the current disposition of "class E" aka 240/4.
>
> RFC 1112 spends a grand total of one sentence on Class E addresses. If
> you're looking for more, you won't find it. That one sentence is all
> they said.
>
>
>> 2)    My curiosity questions were not about "when" or "how", but "why" and for "whom".
> As documented or unambiguously inferred, "why" is because the folks in
> the 1980s wanted to hold some addresses aside for uses not then known,
> and "for whom" was explicitly undefined.
>
>
>> Particularly at a time that IPv4 was planned to be "dead" soon, what was its "Future" that deserved to be Reserved for?
> As I've said in other postings on the subject, I believe the time has
> passed where it was reasonable to expect that a non-unicast use might
> be found for 240/4 within the remaining lifetime of the IPv4 protocol.
> Nor is there any reason to believe we will need more of another sort
> of address such as multicast or broadcast. More, it's well understood
> that the network routing and software client behavior for anycast is
> identical to unicast, and indeed addresses defined as global unicast
> have been routinely allocated to anycast uses. I thus think a
> standards action changing 240/4 from "reserved, undefined" to
> "reserved, unicast" is justified.
>
> Exactly what unicast use remains a reasonable topic of debate. Such
> debate, however, is irrelevant to the hardware and software
> implementing it which need only care that the addresses should be
> handled in normal unicast routing and termination. Changes to hardware
> and software to make use of 240/4 as ordinary unicast IP addresses can
> and should proceed in parallel to such debate.
>
> Regards,
> Bill Herrin
>
>


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220312/d274dfac/attachment.html>


More information about the NANOG mailing list