On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen <aychen@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 -- William Herrin bill@herrin.us https://bill.herrin.us/