<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<font size="4">Dear Colleagues:</font><br>
<div class="moz-forward-container"><font size="4"> <br>
</font>
<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,
nicknamed EzIP (Phonetic for Easy IPv4). (Please see, at the
end of this MSG, the URL to the discussion and the highlighted
text where the citation was made.)</font><font size="4"><br>
</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"> </font></p>
<p><font size="4"> English: <a class="moz-txt-link-freetext"
href="https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf"
moz-do-not-send="true">https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf</a></font></p>
<p><font size="4"> Spanish: <a class="moz-txt-link-freetext"
href="https://www.avinta.com/phoenix-1/home/RevampTheInternet_ES.pdf"
moz-do-not-send="true">https://www.avinta.com/phoenix-1/home/RevampTheInternet_ES.pdf</a></font></p>
<p><font size="4"> Portuguese: <a
class="moz-txt-link-freetext"
href="https://www.avinta.com/phoenix-1/home/RevampTheInternet_PT.pdf"
moz-do-not-send="true">https://www.avinta.com/phoenix-1/home/RevampTheInternet_PT.pdf</a></font></p>
<p><font size="4"> In a nutshell, EzIP proposes:</font></p>
<p><font size="4"> A. 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. <br>
</font></p>
<p><font size="4"> B. 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. <br>
</font></p>
<p><font size="4"> There is an online setup description called
RAN (Regional Area Network), </font><font size="4"><font
size="4">(Reference II), </font>that demonstrates the
feasibility of this approach.</font></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.<br>
</font>
<p><br>
<font size="4"> </font></p>
<p><font size="4">I look forward to addressing your thoughts.</font></p>
<font size="4"> <br>
Regards,<br>
</font>
<p><br>
</p>
<font size="4">Abe (2022-03-08 09:22 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
moz-txt-link-freetext" href="mailto:AYChen@Avinta.com"
moz-do-not-send="true">AYChen@Avinta.com</a></font><br>
<font size="4">WebSite: <a class="moz-txt-link-abbreviated"
href="http://www.Avinta.com" moz-do-not-send="true">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://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html"
moz-do-not-send="true">https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html</a></font></p>
<h1>[lacnog] Draft: Unicast Use of the Formerly Reserved 127/8 </h1>
<b>Leandro Bertholdo</b> <a
href="mailto:lacnog%40lacnic.net?Subject=Re%3A%20%5Blacnog%5D%20Draft%3A%20Unicast%20Use%20of%20the%20Formerly%20Reserved%20127/8&In-Reply-To=%3C86B6BC4D-1D2B-406A-978B-09F459FBD585%40penta.ufrgs.br%3E"
title="[lacnog] Draft: Unicast Use of the Formerly Reserved
127/8" moz-do-not-send="true">berthold en penta.ufrgs.br </a><br>
<i>Lun Nov 29 07:15:28 -03 2021</i>
<ul>
<li>Mensaje anterior: <a
href="https://mail.lacnic.net/pipermail/lacnog/2021-November/008894.html"
moz-do-not-send="true">[lacnog] Draft: Unicast Use of the
Formerly Reserved 127/8 </a></li>
<li>Próximo mensaje: <a
href="https://mail.lacnic.net/pipermail/lacnog/2021-November/008888.html"
moz-do-not-send="true">[lacnog] Draft: Unicast Use of the
Formerly Reserved 127/8 </a></li>
<li> <b>Mensajes ordenados por:</b> <a
href="https://mail.lacnic.net/pipermail/lacnog/2021-November/date.html#8895"
moz-do-not-send="true">[ fecha ]</a> <a
href="https://mail.lacnic.net/pipermail/lacnog/2021-November/thread.html#8895"
moz-do-not-send="true">[ hilo ]</a> <a
href="https://mail.lacnic.net/pipermail/lacnog/2021-November/subject.html#8895"
moz-do-not-send="true">[ asunto ]</a> <a
href="https://mail.lacnic.net/pipermail/lacnog/2021-November/author.html#8895"
moz-do-not-send="true">[ autor ]</a> </li>
</ul>
<hr>
<pre>Oi Fernando,
O que eu quero dizer é que problema é independente de ser endereçamento global ou não.
Esses blocos são simplesmente considerados violações de uso na maioria dos softwares,
sistemas operacionais e implementações dos protocolos.
Ou seja, qualquer coisa no sentido de usa-los precisa de todo aquele trabalho.
Eu simplesmente não consigo ver como chegar-se a qualquer meio termo nesse sentido - todo
mundo que produz equipamentos de rede vai ter que revisar o código.
Se considerarmos que, o uso como endereçamento global é o máximo ganho possível,
e ainda assim não vale o esforço, qualquer outro uso não fará sentido.
De 2007 a 2009 se conversou sobre o reuso. Note que a primeira proposta foi para uso
privado, que depois evoluiu para simplesmente tornar esses endereços válidos:
* August 3, 2007 - Redesignation of 240/4 from "Future Use" to "Limited Use for Large Private Internets
<a href="https://datatracker.ietf.org/doc/html/draft-wilson-class-e-00" class="moz-txt-link-freetext" moz-do-not-send="true">https://datatracker.ietf.org/doc/html/draft-wilson-class-e-00</a>
* March 2, 2008 - Reclassifying 240/4 as usable unicast address space
<a href="https://datatracker.ietf.org/doc/html/draft-fuller-240space-00" class="moz-txt-link-freetext" moz-do-not-send="true">https://datatracker.ietf.org/doc/html/draft-fuller-240space-00</a>
* September 13, 2008 - Reclassifying 240/4 as usable unicast address space
<a href="https://datatracker.ietf.org/doc/html/draft-fuller-240space-01" class="moz-txt-link-freetext" moz-do-not-send="true">https://datatracker.ietf.org/doc/html/draft-fuller-240space-01</a>
Passaram-se mais de 10 anos e nem isso foi adiante. Esses IPs ainda sao considerados
invalidos pelas RFCs correntes.
Linux responde como argumento invalido
Routers também…
Apple também
Resumindo, os equipamentos atuais não tem suporte. Se os sistemas operacionais e routers fossem atualizados
os provedores de acesso deveriam realizar upgrade em *TODOS* os equipamentos, e eventualmente algum equipamento
legado teria que ser substituído, assim como foi para suportar IPv6.
O que eu quero dizer no final das contas é que estamos revisitando um problema que muita gente já estudou e avaliou.
Essa proposta não foi descartada de imediato. Muita gente já gastou muito tempo achar uma saída por esse caminho...
Acredito que será difícil você encontrar suporte para qualquer proposta nesse sentido 15 anos depois.
Outro ponto é a demanda (ou falta dela) que o Rubens citou. Até hoje não ouvi nenhuma operadora reclamando
de falta de endereçamento privado que elas não achassem uma saída.
A solução que várias operadoras tem usado para liberar os IPs de backbone é por colocar toda a rede com
endereçamento IPv6 e transportar IPv4 sobre IPv6 (normalmente MPLS).
Ou seja, existem soluções viáveis que não dependem de nenhuma nova RFC.
<font color="#ff0000">A proposta do Chen, Adaptive IPv4 Address Space (draft-chen-ati-adaptive-ipv4-address-space-09.txt)</font> <font color="#ff0000">sugere usodo 240/4 para IoT.
Mas desenvolver um novo protocolo com foco em IoT e restrito a 256M devices</font> quando se fala em 5 Bilhoes de IoT
previstos em 2022 nao parece que vai atrair a atenção de muita gente. A ultima atualizacao dessa draft foi em 2021.
Olhando pra esse histórico todo, acho que a proposta do Schoen (<a href="https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html" class="moz-txt-link-freetext" moz-do-not-send="true">https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html</a>)
(assunto desse email) também não vá adiante. Propor alterar a máscara de interface de Loopback em todos
os equipamento que falam IP para resgatar menos de um /8. Não creio que será bem aceita!
Legal a discussão Fernando, me serviu pra dar uma atualizada em como anda esse assunto… ;-)
Abraço a todos.
Leandro Bertholdo
><i> On 29 Nov 2021, at 04:31, Fernando Frediani <<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" moz-do-not-send="true">fhfrediani en gmail.com</a>> wrote:
</i>><i>
</i>><i> Olá Leandro
</i></pre>
<p><font size="4">***************<br>
</font></p>
<p><br>
</p>
</div>
<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>