[GTER] New IETF draft: IPv4 with 64 bit Address Space

Marcelo Akira Yamamoto y.marceloakira at gmail.com
Thu Dec 10 19:13:39 -02 2015


Se fosse totalmente compatível com o IPv6 seria uma solução inquestionável
pois resolvera 2 problemas: 1. A falha de segurança do IPv6; 2. Migração
dos EndUsers para IPv6.
Já  que isso permitiria trabalhar IPv6 nos BackBones e garantir o controle
quase que total sobre os usuários.

Em 10 de dezembro de 2015 11:20, Antonio M. Moreiras <moreiras at nic.br>
escreveu:

> Eu ouvi de algumas pessoas que na época do projeto do IPv6 havia uma
> espécie de clima de quase euforia entre o pessoal envolvido, na linha do
> "nós somos bons mesmo, temos tempo, podemos fazer algo independente do
> que já existe e bem melhor"... Não sei o quanto disso é verdade, mas se
> for, vai ao encontro do comentário do Douglas. Suponho que o ego de
> alguns provavelmente influenciou, ao menos em parte, más decisões.
>
> Acho que é meio tarde pra seguir outro caminho agora, em relação ao
> IPv6. Mas a situação ilustra algo interessante. A evolução dos
> protocolos e a criação de novos no IETF continua, e nós engenheiros
> continuamos tendo egos um tanto grandes. A participação e visão muito
> mais 'pés no chão' de quem opera as redes e conhece os problemas do dia
> a dia, nos grupos de trabalho do IETF, é importante pra que melhores
> decisões sejam tomadas.
>
> A primeira reunião do IETF na América Latina, no começo do próximo ano,
> em Buenos Aires, pode ser um facilitador pra mais gente que opera as
> redes dos provedores, universidades e empresas aqui do Brasil se envolver.
>
> []s
> Moreiras.
>
> Em 09/12/15 18:26, Douglas Fischer escreveu:
> > Porquê?
> >
> > Pura massagem no ego de projetista rato de laboratório...
> >
> > E não fui eu quem disse isso!
> > Ví numa apresentação em que o autor defendia a metodologia de transição
> em
> > que os 32 bits do IPv4 ficassem dentro dos 128 bits do IPv6, sendo
> > permitido o roteamento inter-protocolo.
> >
> > Isso eliminaria a necessidade do dual-stack e permitiria turnkey com
> > retrocompatibilidade.
> >
> > Agora sim minhas palavras:
> > - O mesmo tipo de frescura que permitiu aquela inversão idiota de bits em
> > relação ao MAC-Address no começo dos bits de host do IPv6.
> >
> > /*Android told-me that this text should be at bottom.*/
> > Em 09/12/2015 17:45, "Bruno Cabral" <bruno at openline.com.br> escreveu:
> >
> >> Eu sempre me perguntei por que nao pensaram em algo assim, mantendo a
> >> compatibilidade, como fizeram por ex com ASN de 32 bits face ao de 16
> >>
> >> Passar de NCP para TCP/IP foi fácil porque eram comparativamente muito
> >> menos hosts que os IPv4 atualmente ativos. A adoção de CGNAT já ameaçava
> >> dar mais fôlego pro IPv4, mas essa proposta, se adotada, pode
> simplesmente
> >> matar a vontade de quem está procrastinando a adoção do IPv6 vir a
> fazê-lo!
> >>
> >> Eu gostei especialmente da retrocompatibilidade e o uso inteligente do
> >> registro AAAA para não precisar mecher no codigo do DNS
> >>
> >> Agora se vai vingar, ai não me arrisco a prever
> >>
> >> !3runo Cabral
> >> --
> >> Cursos e Consultoria BGP e OSPF
> >>
> >>> From: humbertogaliza at gmail.com
> >>> Date: Wed, 9 Dec 2015 10:48:41 -0300
> >>> To: gter at eng.registro.br
> >>> Subject: [GTER] New IETF draft: IPv4 with 64 bit Address Space
> >>>
> >>> Abstract
> >>>
> >>>    This document describes a solution to the Internet address depletion
> >>>    problem through use of a clever IPv4 options mechanism as a
> solution.
> >>>    This IPv4 protocol extension is called enhanced IP (EnIP).  Because
> >>>    it is IPv4, it maximizes backward compatibility while increasing
> >>>    address space by a factor of 17.9 million.  Unlike other similar
> >>>    proposals, care was taken to avoid costly changes and requirements
> to
> >>>    the core network and border routers, with the exception that options
> >>>    be passed in that equipment as described below.  Because it is
> >>>    backward compatible, current IPv4 software, network equipment,
> >>>    firewalls, intrusion detection/protection, and layer 5 firewalls can
> >>>    be maintained until IPv6 system information security reaches
> >>>    acceptable maturity and availability.
> >>>
> >>> Link direto para o draft:
> >>> https://datatracker.ietf.org/doc/draft-chimiak-enhanced-ipv4/
> >>>
> >>> Comentários são apreciados.
> >>>
> >>> Abs,
> >>>
> >>> Humberto Galiza
> >>> --
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Akira.



More information about the gter mailing list