[lacnog] Draft: Unicast Use of the Formerly Reserved 127/8

Lun Nov 29 07:15:28 -03 2021

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> wrote:
> 
> Olá Leandro
> 
> O problema quando se fala desse assunto parece ser sempre o mesmo.
> Muitas pessoas só conseguem enxergar que qualquer coisa feita à respeito para tornar o uso desses endereços globalmente roteáveis é desperdício de tempo devido ao que você citou - e que é verdadeiro como citei na minha mensagem anterior - e de que seria necessário ajustar configurações e realizar atualizações em equipamentos para que seja possível utilizar esses endereços. Geralmente vejo as pessoas repetindo isso como um mantra e sequer se dão ao trabalho de ler as propostas ou tentar discutir o assunto para para ir além disso e tentarem encontrar algum meio termo onde não necessário fazer tudo aquilo que é impossível e também que se dê algum uso à esses endereços. Em alguns poucos minutos de leitura já retornam com a certeza de quem aquilo que está colocado não pode ser feito.
> 
> Veja, é importante ter a paciência necessária de entender a questão antes de descartá-la de imediato sob o medo de estar gastando energia atoa.
> Eu mesmo quando comecei a me debruçar sobre esse assunto pensava que era possível mas depois de gastar algum tempo estudando e entrando em contato com pessoas que já haviam discutido isso antes me convenci que realmente não é possível fazer com que esses endereços sejam utilizados de maneira globalmente roteavel.
> 
> Porém como disse em minha mensagem existem alternativas que podem sim dar uso a esses endereços desperdiçados devidos à erros históricos de fabricantes de hardware.
> Pode-se utilizá-los para endereçamento de backbone, liberando assim milhares de endereços globalmente roteáveis para uso na DFZ. Pode ser utilizar para outros cenários onde esses endereços existem em um ambiente mais restrito. Veja por exemplo a quantidade de endereços IPv4 que algumas CDNs ainda solicitam para hospedar um cluster de servidores dentro de um backbone. Alguns ainda continuam solicitando quantidades grandes de endereços como até mesmo um /26
> 
> Portanto todos os pontos que você citou a abaixo que teriam que ser feitos não seriam necessários se os interessados em discutir esse assunto estiverem dispostos a abrir mão do uso desses endereços como globalmente roteáveis e encontrar um meio termo que dê alguma utilidade à deles.
> 
> Acho que o segundo mantra que repetem os que são contrários a sequer discutir esse assunto é que "Esses endereços não dariam para nada na atual realidade". Mas quem disse que esse seria o intuito deles, esticar a vida do IPv4 ou até mesmo postergar a implantação de IPv6 ?
> O intuito é apenas e tão somente dar uso à esses endereços totalmente desperdiçados onde podem ser utilizados sem maiores problemas, independente de quantos sejam. Reparar um erro histórico, mesmo que parcialmente enquanto se aguarda a boa vontade das pessoas implementarem IPv6 e tornar essa transição menos problemática para aqueles que sofrem mais com a escassez.
> É fazer justiça quanto se diz que "o IPv4 acabou" ? Acabou mesmo com esse erro histórico e centenas de milhões de endereços desperdiçados dessa maneira ?
> 
> É ingênuo no meu ponto de vista acreditar que qualquer coisa que seja feita nesse sentido de dar uso à esses endereços irá atrasar ainda mais a implantação de IPv6 por quem quer que seja. Não muda absolutamente nada.
> Aqueles que não fazem por livre a espontânea vontade implantam IPv6 quando se sentem obrigadas e dando destinação à esses endereços, independente da quantidade que seja, não irá alterar em nada nas motivações daqueles que ainda não implantaram IPv6.
> 
> Abraços
> Fernando Frediani
> 
> On 28/11/2021 14:34, Leandro Bertholdo wrote:
>> Olá Fernando, 
>> 
>> Eu corroboro com o posicionamento do “não vale a pena”. 
>> No inicio dos anos 2000 pensava que valeria o esforço para recuperar, mas mudei de opinião depois de olhar os números mais de perto.
>> 
>> Na época foram feitas várias projeções para avaliar também essa situação (algumas em 
>> https://ipv4.potaroo.net/
>> ) . 
>> Se voce olhar o histórico, vai ver que um único RIR (APNIC)  consumiria sozinho esses 16 x /8 em um ano. 
>> 
>> Se essas projeções fossem realizadas novamente, e considerando que hoje existe uma  demanda reprimida, muito provavelmente esse espaço de endereçamento seria consumido em 1-3 meses por todos os RIRs. 
>> (talvez algum operador do RIR queira comentar e dar uma informação mais precisa e atual)
>> 
>> Se, por outro lado, olharmos para o esforço necessário para tornar esse bloco viável:
>> - Normas teriam que ser discutidas e aprovadas (normalmente o IETF leva anos pra discutir e aprovar uma - 5-10 anos)
>> - Milhões de firewalls e ACLs em routers teriam que ser atualizados com novas regras para permitir esses blocos.
>> - Aplicações teriam que ser revisadas para interpretar esses IPs como válidos
>> - Sistemas operacionais teriam que ser revisados
>> - Bibliotecas de software teriam que ser revisadas
>> - Testes e “limpeza” desses blocos (na época do uso do 1.0.0.0/8 se descobriu vários softwares tinham o 1.1.1.1 hardcoded)
>> - Corrigir todos os bugs antes de colocar os blocos em produção
>> 
>> Digo por mim mesmo: todos os softwares, scripts, firewalls e routers que por ventura eu tenha programado/configurado no passado teriam que ser revisados.
>> Em suma, tudo teria que ser testado antes para validar. Um esforço similar foi realizado no "Bug do Milênio”.
>> 
>> Como resultado, todos trabalharíamos por vários anos para consumir o resultado do trabalho em poucos meses. 
>> E depois voltaríamos exatamente onde estamos hoje. 
>> Esse foram os motivos que me convenceram a não perder tempo com essa reserva:
>> - "Era jogar 16 bifes pra uma matilha de 5 lobos famintos"
>>  
>> Meus 2 centavos sobre o assunto.
>> Abraço
>> Leandro Bertholdo
>> 
>> 
>>> On 24 Nov 2021, at 19:10, Fernando Frediani <fhfrediani en gmail.com>
>>>  wrote:
>>> 
>>> Todas as vezes que tentei discutir esse assunto justamente para se tentar encontrar algum meio-termo a resposta imediata é que "não vale a pena - e fim" sem se nenhum esforço de querer entrar muito em detalhes e também alguns argumentam que o esforço poderia ser utilizado para implantar IPv6.
>>> 
>> _______________________________________________
>> 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/20211129/ea67a677/attachment-0001.htm>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : Screen Shot 2021-11-29 at 09.03.51.jpg
Tipo       : image/jpeg
Tamaño     : 30832 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20211129/ea67a677/attachment-0004.jpg>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : Screen Shot 2021-11-29 at 09.06.17.jpg
Tipo       : image/jpeg
Tamaño     : 16797 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20211129/ea67a677/attachment-0005.jpg>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : Screen Shot 2021-11-29 at 09.40.15.jpg
Tipo       : image/jpeg
Tamaño     : 18878 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20211129/ea67a677/attachment-0006.jpg>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : Screen Shot 2021-11-29 at 09.38.02.jpg
Tipo       : image/jpeg
Tamaño     : 18636 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20211129/ea67a677/attachment-0007.jpg>