<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><font size="4">Hi, Bill:</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">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.<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">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 </font><font size="4"><font size="4">(second grey
background box)</font>. 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.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">
<a class="moz-txt-link-freetext" href="https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/">https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/</a> <br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">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.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">Regards,</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">Abe (2022-03-12 11:15)
</font><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2022-03-11 11:34, William Herrin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAP-guGXKnwxvSYFz=5B1MGU4z2GV_yG9UfUC4rmqketriKQ1QQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen <a class="moz-txt-link-rfc2396E" href="mailto:aychen@avinta.com"><aychen@avinta.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">2) My curiosity questions were not about "when" or "how", but "why" and for "whom".
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Particularly at a time that IPv4 was planned to be "dead" soon, what was its "Future" that deserved to be Reserved for?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<p><br>
</p>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>