<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="4">Dear Colleagues:</font><font size="4"><br>
</font></p>
<p><font size="4">0) I was made aware of a recent discussion on
this Forum that cited our work on the 240/4 NetBlock, </font><font
size="4"><font size="4">nicknamed EzIP (Phonetic for Easy IPv4)</font>.
(Please see, at the end of this MSG, the URL to the discussion
and the highlighted text where the citation was made.)</font></p>
<p><font size="4">1) As the lead investigator of the EzIP
Project, I would like to formally introduce our solution by
bringing your attention to an overview whitepaper:</font></p>
<p><font size="4">
<a class="moz-txt-link-freetext" href="https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf">https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf</a></font></p>
<p><font size="4"> In a nutshell, EzIP proposes to disable the
program codes in current routers that have been disabling the
use of the 240/4 NetBlock. The cost of this software engineering
should be minimal. The EzIP deployment architecture is the same
as that of the existing CG-NAT (Carrier Grade Network Address
Translation). Consequently, there is no need to modify any
hardware equipment. There is an online setup description (</font><font
size="4"><font size="4">Reference II)</font>, called RAN
(Regional Area Network), that </font><font size="4"><font
size="4">demonstrates the </font>feasibility of this
approach.</font></p>
<p><font size="4">2) There are additional consequential benefits
by deploying EzIP, such as those mentioned by our comment to
Reference III in the above whitepaper.</font></p>
<font size="4">I look forward to addressing your thoughts.<br>
</font>
<p><font size="4"><br>
</font></p>
<p><font size="4">Regards,</font></p>
<p><br>
</p>
<font size="4">Abe (2022-03-07 17:14 EST)<br>
VP Engineering<br>
Avinta Communications, Inc.<br>
</font><font size="4">Milpitas, CA 95035 USA</font><br>
<font size="4">+1(408)942-1485</font><br>
<font size="4">Skype: Abraham.Y.Chen</font><br>
<font size="4">eMail: <a class="moz-txt-link-abbreviated" href="mailto:AYChen@Avinta.com">AYChen@Avinta.com</a></font><br>
<font size="4">WebSite: <a class="moz-txt-link-abbreviated" href="http://www.Avinta.com">www.Avinta.com</a></font>
<p><font size="4"><br>
</font></p>
<p>***********************<br>
</p>
<p><font size="4"><a class="moz-txt-link-freetext" href="https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html">https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html</a></font></p>
<h1>Class D addresses? was: Redploying most of 127/8 as unicast
public</h1>
<b>Greg Skinner</b>
<a
href="mailto:nanog%40nanog.org?Subject=Re%3A%20Class%20D%20addresses%3F%20was%3A%20Redploying%20most%20of%20127/8%20as%20unicast%20public&In-Reply-To=%3CFEDBF677-BC75-47F3-A92D-2611F43283BA%40icloud.com%3E"
title="Class D addresses? was: Redploying most of 127/8 as unicast
public">gregskinner0 at icloud.com
</a><br>
<i>Mon Nov 29 18:47:14 UTC 2021</i>
<ul>
<li>Previous message (by thread): <a
href="https://mailman.nanog.org/pipermail/nanog/2021-November/216640.html">Class
D addresses? was: Redploying most of 127/8 as unicast public
</a></li>
<li>Next message (by thread): <a
href="https://mailman.nanog.org/pipermail/nanog/2021-November/216602.html">Class
E addresses? 240/4 history
</a></li>
<li> <b>Messages sorted by:</b>
<a
href="https://mailman.nanog.org/pipermail/nanog/2021-November/date.html#216766">[
date ]</a>
<a
href="https://mailman.nanog.org/pipermail/nanog/2021-November/thread.html#216766">[
thread ]</a>
<a
href="https://mailman.nanog.org/pipermail/nanog/2021-November/subject.html#216766">[
subject ]</a>
<a
href="https://mailman.nanog.org/pipermail/nanog/2021-November/author.html#216766">[
author ]</a>
</li>
</ul>
<hr>
<pre>><i> On Nov 24, 2021, at 5:08 PM, William Herrin <<a href="https://mailman.nanog.org/mailman/listinfo/nanog">bill at herrin.us</a>> wrote:
</i>><i>
</i>><i> On Wed, Nov 24, 2021 at 4:36 PM David Conrad <<a href="https://mailman.nanog.org/mailman/listinfo/nanog">drc at virtualized.org</a>> wrote:
</i>>>><i> I like research but what would the RIRs study? The percentage of the
</i>>><i>
</i>>><i> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
</i>>><i> and they said similar things when 1.1.1.0/24 was stood up as an
</i>>><i> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.
</i>><i>
</i>><i> Hi David,
</i>><i>
</i>><i> I don't recall there being any equipment or software compatibility
</i>><i> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
</i>><i> I recall it, there were concerns with prior local use and potential
</i>><i> trash traffic. It seemed likely those concerns could be addressed with
</i>><i> experiments, and the experiments in fact addressed them.
</i>><i>
</i>><i> The prior local use worry reared its head again with 240/4 but given
</i>><i> the prior experience with 1.0.0.0/8 I don't personally believe we need
</i>><i> to re-run that experiment just because the numbers are part of a
</i>><i> different block.
</i>><i>
</i>><i>
</i>>><i> Seems to me that a number of folks on this list and during this
</i>>><i> discussion would disagree with a blanket assertion that 240/4
</i>>><i> is “dysfunctional on the 2021 Internet” - some of them even
</i>>><i> wrote a draft discussing the possibility.
</i>><i>
</i>><i> Line them up. Show of hands. Who really thinks that if we assign
</i>><i> 240.0.0.1 to a customer tomorrow without waiting for anyone to clean
</i>><i> up their software and hardware, you won't get enough complaints about
</i>><i> things not working that you have to take it back and assign a
</i>><i> different address instead?
</i>><i>
</i>><i>
</i>>><i> 1. Move 240/4 from "reserved" to "unallocated unicast"
</i>>><i>
</i>>><i> OK, but this seems like a quibble. The status for 240/4 is “
</i>>><i> RESERVED: designated by the IETF for specific non-global-unicast
</i>>><i> purposes as noted.” The “as noted” part is “Future Use”.
</i>><i>
</i>><i> It's not a quibble. Some vendors take the current status to mean
</i>><i> "treat it like unicast until we're told otherwise." Others take the
</i>><i> status to mean, "packets with these addresses are bogons without a
</i>><i> defined routing behavior until we're told otherwise." The result is
</i>><i> incompatible behavior between vendors. Changing that direction to
</i>><i> "treat it like unicast" without ambiguity is not a quibble.
</i>><i>
</i>><i> Regards,
</i>><i> Bill Herrin
</i>><i>
</i>><i> --
</i>><i> William Herrin
</i>><i> <a href="https://mailman.nanog.org/mailman/listinfo/nanog">bill at herrin.us</a>
</i>><i> <a href="https://bill.herrin.us/" class="moz-txt-link-freetext">https://bill.herrin.us/</a>
</i>
For what it’s worth, I’ve been tracking this issue on other netops mailing lists. There is a recent post on the LACNOG list from Leandro Bertholdo
<<a href="https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html" class="moz-txt-link-freetext">https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html</a>> <font color="#ff0000">referencing <a href="https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/</a>
<<a href="https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/</a>>, a draft proposing another way to make additional IPv4 address space available
I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4. Subsequent googling about the draft turned up a presentation
<<a href="https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf" class="moz-txt-link-freetext">https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf</a>> describing how the techniques described could be deployed.</font> I noticed that the presentation
made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast Extensions Project have done in that area.
The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should contact the authors.
—gregbo
</pre>
<p><font size="4">*******************</font><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>