[lacnog] Making Use of 240/4 NetBlock Re: 202203112350.AYC
Fernando Frediani
fhfrediani en gmail.com
Sab Mar 12 14:06:48 -03 2022
I don't think even the authors of any of the proposals really believe
this type of thing would be possible, upgrade every major legacy router
in the world. And if 240/4 would make it to a state it can be used it
could still well be used for example inside a backbone in a regional way
that allow many organizations to move those more 'noble addresses' to be
used as Global ones, IXs, Interconections, etc.
I also don't see if that would happen one day people would just "stop
deploying IPv6" until the issue of IPv4 exhaustion "comes back again".
That just doesn't make any sense.
Fernando
On 12/03/2022 13:41, Jorge Villa vía LACNOG wrote:
>
> Hi, just adding a few words to the Tomas Lynch comment.
>
> Please, don’t forget that the Internet infrastructure is not only the
> part created by a few big operators and Tier I or II ISPs. The
> Internet is really bigger than that. If you make a real-time inventory
> now, you'll find that there are a lot of working devices on the
> Internet that have reached their end of support from their respective
> manufacturers. Of course, those devices won’t be upgraded to scale to
> the new ExIP but they'll keep up and running. It will be an unwanted
> situation for the operation and the stability of the Internet
> infrastructure.
>
> Doing this kind of “fix”, you’ll have to make almost the same effort
> (inventory, software patching, hardware upgrade and replace, routing,
> security, and so on ) that deploying IPv6. Recovering this /4 block
> might allow a 2-4 years of “peace” but after that we'll be in the same
> situation of IPv4 exhausting that we have nowadays. Definitely, to
> adopt ExIP, we’ll have to invest a lot of efforts and money in a
> temporary solution instead of a definitive solution for the same price
> (or less, because even when a lot of operators haven’t deployed IPv6
> now, they have been acquiring IPv6 capable hardware and software as
> part of their usual business process). Deploying IPv6 is the
> definitive answer.
>
> Regards,
>
> Jorge
>
> *De: *LACNOG <lacnog-bounces en lacnic.net> en nombre de Tomas Lynch
> <tomas.lynch en gmail.com>
> *Responder a: *Latin America and Caribbean Region Network Operators
> Group <lacnog en lacnic.net>
> *Fecha: *sábado, 12 de marzo de 2022, 10:34 a. m.
> *Para: *Latin America and Caribbean Region Network Operators Group
> <lacnog en lacnic.net>
> *Asunto: *Re: [lacnog] Making Use of 240/4 NetBlock Re: 202203112350.AYC
>
> This part of the proposal doesn't have in mind the operations of a
> network:
>
> > 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.
>
> Yes, let's say that the cost for Vendor A could be minimal: they will
> remove some lines in the code for version X.Y and release version
> X.Y-EzIP without bugs triggered by removing those lines. Then, we, the
> operators, would have to plan the upgrade of all of our routers, spend
> days programming the upgrade, spend nights in maintenance windows,
> maybe pay for remote hands, etc., just to extend for a few more days
> the inevitable agony of IPv4.
>
> Thus, the cost of the so-called EzIP is not minimal.
>
> On Sat, Mar 12, 2022 at 3:32 AM Fernando Frediani
> <fhfrediani en gmail.com> wrote:
>
> Hello
>
> I do not and never accepted the easy justification that working
> towards making any usage of a huge amount of wasted IPv4 addresses
> due to an historical mistake from some network vendor is something
> that would compete with IPv6 deployment. Both things can work in
> parallel without prejudice to each other.
>
> However I think the best proposal I have seen was the one put but
> Seth and his partners
> (https://github.com/dtaht/unicast-extensions/blob/master/rfcs/draft-gilmore-taht-v4uniext.txt)
> and even though these addresses may not be used globally they will
> have usage that can help making this transition smoother as it is
> not reasonable to think we will turn the key to IPv6 in the next
> few years for more effort and dedication we put into it.
>
> Fernando
>
> On 12/03/2022 04:47, JORDI PALET MARTINEZ vía LACNOG wrote:
>
> Personally, I don’t think it is worth and I’m not going to
> invest more time in discussing this, just a short note for
> others to consider:
>
> The effort to “reinvent” any part of IPv4 or patches to it,
> then test that everything keeps working as expected, versus
> the benefits and gained time, it is much best invested in
> continue the IPv6 deployment which is already going on in LAC
> and the rest of the world.
>
> It would not make sense, for a region like LAC to trow away
> all the efforts that have been already done with IPv6 and we
> should avoid confusing people.
>
> IPv6 is the only viable long-term solution, and this is the
> reason why what you are proposing and similar approaches have
> been rejected several times by IETF.
>
> Saludos,
>
> Jordi
>
> @jordipalet
>
> El 12/3/22 5:56, "LACNOG en nombre de Abraham Y. Chen"
> <lacnog-bounces en lacnic.net en nombre de aychen en avinta.com>
> escribió:
>
> Dear Colleagues:
>
> 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.)
>
> 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:
>
> English:
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> Spanish:
> https://www.avinta.com/phoenix-1/home/RevampTheInternet_ES.pdf
>
> Portuguese:
> https://www.avinta.com/phoenix-1/home/RevampTheInternet_PT.pdf
>
> In a nutshell, EzIP proposes:
>
> 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.
>
> 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.
>
> There is an online setup description called RAN (Regional
> Area Network), (Reference II), that demonstrates the
> feasibility of this approach.
>
> 2) There are additional consequential benefits by deploying
> EzIP, such as those mentioned by our comment to Reference III
> in the above whitepaper.
>
> I look forward to addressing your thoughts.
>
>
> Regards,
>
> Abe (2022-03-08 09:22 EST)
> VP Engineering
> Avinta Communications, Inc.
> Milpitas, CA 95035 USA
> +1(408)942-1485
> Skype: Abraham.Y.Chen
> eMail: AYChen en Avinta.com
> WebSite: www.Avinta.com <http://www.Avinta.com>
>
> *****************
>
> https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html
>
>
> [lacnog] Draft: Unicast Use of the Formerly Reserved 127/8
>
> *Leandro Bertholdo* berthold en penta.ufrgs.br
> <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>
> /Lun Nov 29 07:15:28 -03 2021/
>
> ·Mensaje anterior: [lacnog] Draft: Unicast Use of the Formerly
> Reserved 127/8
> <https://mail.lacnic.net/pipermail/lacnog/2021-November/008894.html>
>
> ·Próximo mensaje: [lacnog] Draft: Unicast Use of the Formerly
> Reserved 127/8
> <https://mail.lacnic.net/pipermail/lacnog/2021-November/008888.html>
>
> ·*Mensajes ordenados por:* [ fecha ]
> <https://mail.lacnic.net/pipermail/lacnog/2021-November/date.html#8895>
> [ hilo ]
> <https://mail.lacnic.net/pipermail/lacnog/2021-November/thread.html#8895>
> [ asunto ]
> <https://mail.lacnic.net/pipermail/lacnog/2021-November/subject.html#8895>
> [ autor ]
> <https://mail.lacnic.net/pipermail/lacnog/2021-November/author.html#8895>
>
>
> ------------------------------------------------------------------------
>
> 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
>
> https://datatracker.ietf.org/doc/html/draft-wilson-class-e-00
>
>
>
> * March 2, 2008 - Reclassifying 240/4 as usable unicast address space
>
> https://datatracker.ietf.org/doc/html/draft-fuller-240space-00
>
>
>
> * September 13, 2008 - Reclassifying 240/4 as usable unicast address space
>
> https://datatracker.ietf.org/doc/html/draft-fuller-240space-01
>
>
>
> 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.
>
>
>
> A proposta do Chen, Adaptive IPv4 Address Space
> (draft-chen-ati-adaptive-ipv4-address-space-09.txt) sugere usodo 240/4 para IoT.
>
> Mas desenvolver um novo protocolo com foco em IoT e restrito a
> 256M devices 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 (https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html)
>
> (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
>
>
>
> >/On 29 Nov 2021, at 04:31, Fernando Frediani <fhfrediani en
> gmail.com <https://mail.lacnic.net/mailman/listinfo/lacnog>>
> wrote:/
>
> >//
>
> >/Olá Leandro/
>
> ***************
>
> Imagen quitada por el remitente.
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>
>
>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>
>
> _______________________________________________ LACNOG mailing
> list LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar
> suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be
> privileged or confidential. The information is intended to be
> for the exclusive use of the individual(s) named above and
> further non-explicilty authorized disclosure, copying,
> distribution or use of the contents of this information, even
> if partially, including attached files, is strictly prohibited
> and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even
> if partially, including attached files, is strictly
> prohibited, will be considered a criminal offense, so you must
> reply to the original sender to inform about this
> communication and delete it.
>
>
>
> _______________________________________________
>
> LACNOG mailing list
>
> LACNOG en lacnic.net
>
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________ LACNOG mailing list
> LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20220312/58ed638a/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG