[lacnog] A Disaster for IPv6 - Brought by Fortinet

[Douglas Fischer]

Existe um ponto mais importante!
(Que talvez eu não tenha conseguido cobrir em minhas falas anteriores.)

Eu sempre repito, e sempre vou repetir.
"A Internet foi feita para sem FIM-A-FIM."
Essa frase traz como primeira interpretação o fim do NAT, que é o tema que
estamos debatendo aqui há um tempo.

Mas tem um ponto mais importante que essa questão do NÃO-NAT.
A Internet NÃO NASCEU para ser Server Centric, ou melhor dizendo: A
Internet NÃO NASCEU PARA SER CLOUD CENTRIC.
E é isso que devemos defender com unhas e dentes mais do que lutar contra o
NAT.

Isso é tão importante que abrange diversas outras áreas muito mais
debatidas no mundo de rede.
Privacidade é um exemplo disso.
Protocolos de P2P, ou até protocolos de end-2-end com intermediários como o
próprio SIP dependem de que o Fim-a-Fim sem tradução esteja plenamente
funcional e confiável.
Sem isso, vai todo mundo continuar se pendurando em serviços
full-cloud-based operados e definidos por empresas que ditaram como as
pessoas e os computadores deverão se comunicar, sempre passando por um
ponto sob o controle deles.

Sim.Contextos específicos(como ambiente corporativo) demandam soluções para
isso.
Mas acredito que as soluções para isso estejam mais perto do que a RFC que
o próprio Gont comentou https://www.rfc-editor.org/rfc/rfc8978.html do que
atrás de emporcalhar o mundo estéril do IPv6 com esse câncer chamado NAT.

Em seg., 8 de jun. de 2026 às 17:15, Carlos Martinez - Cagnazzo <
carlos en cagnazzo.uy> escreveu:

> Hi,
>
> I think we should make a distinction between actual "NAT"  --that is,
> hiding a bunch of things behind a single IPv4/IPv6-- and "NPT" where you
> actually make a stateless translation where the host section of the
> address is kept as-is.
>
> I don't like NAT w/port translation, not in IPv4 and much less in IPv6.
> I think it gives a false sense of security and hides behavior in ways
> that probably can be exploited.
>
> Someone mentioned the ability of protocols like UPnP to punch holes in
> NAT as a "good thing". I honestly believe it is a terrible idea, and
> that it always has been, a a sad example of the things we've been forced
> to accept in this IPv4 port-translated Internet. There goes your
> supposed security layer brought by NAT. Any 10 usd piece of **** you buy
> at the supermarket can happily punch holes in your "nat security".
>
> Rant aside, I can live with something like NPT, specially in Enterprise
> scenarios. I even believe it could in some situations actually be useful
> (multihoming without BGP, some renumbering scenarios).
>
> "Live Long and Deploy IPv6" (most of you are too young to remember where
> this come from :-))) )
>
> /Carlos
>
> On 6/8/26 4:18 PM, Fernando Gont wrote:
> > Hello, Henri,
> >
> > On 08/06/2026 12:30, Henri Alves de Godoy wrote:
> >> Bom dia,
> >>
> >> Particularmente, não considero desejável ver NAT66 habilitado por
> >> padrão em dispositivos IPv6
> >
> > The idea of defaulting to a "conservative, known, and well understood"
> > setting is a good one. -- at the end of the day, if you know what
> > you're doing, you can always override.  And if you don't know what
> > you're doing, you shouldn't be doing it in the first place... so...
> > who cares?
> >
> >
> >
> >> (aliás o NAT66 é uma maneira de entendimento que se herdou seguindo a
> >> ideia do NAT44).
> >
> > There's probably nothing that has hurted IPv6 deployment more than the
> > argument of "forget everything you know about IPv4".
> >
> >
> >
> >
> >> Se houver necessidade de algum mecanismo de tradução para lidar com
> >> cenários de multihoming ou renumeração, vejo soluções como NPTv6 como
> >> um mal menor, mas ainda bem feio e deselegante,
> >
> > How many of the folks in this discussion have participated in
> > discussions where some of us have tried to address some of the
> > associated issues?   Answer: 0.
> >
> >
> >
> >
> >>  (diferente no que chamamos de NAT66), por preservar melhor as
> >> características originais do IPv6 e evitar a complexidade operacional
> >> associada à tradução de portas e ao compartilhamento de endereços.
> >
> > Human factor: whatever is well and best understood trumps everything
> > else.
> >
> >
> >
> >
> >> Há alguns bons anos e mais agora, discutimos os desafios de
> >> multihoming, remuneração e estabilidade de endereçamento em IPv6.
> >> Apesar de diversos esforços até citados em alguns drafts iniciais,
> >> ainda não conseguimos oferecer soluções simples e amplamente adotadas
> >> para esses problemas.
> >
> > Oh, that one is simple: I've tried to mitigate some of such issues.
> > Sent heads up on this list for all such drafts, and seen 0 support
> > from folks on this list on the relevant wgs.
> >
> > Ironically, the more pro-ipv6 folks tend to be the least involved in
> > solving the underlying problems, and vice-versa.  (as much as I flag
> > issues, I've devoted a lot of time to address them, where they can
> > actually be addressed).
> >
> >
> >
> >
> >> Como consequência, empresas e fabricantes acabam implementando aquilo
> >> que resolve a necessidade imediata de seus clientes, mesmo que não
> >> represente a melhor escolha arquitetural.
> >
> > Let's not pretend that IPv6 has a great and clean architecture.
> >
> > In fact, the very first and core idea of not messing up with IPv6
> > packets as they traverse the entwork was messed up by the IETF itself,
> > by companies with big pockets well invested in SRv6.
> >
> > A few of us fought that one:
> > https://datatracker.ietf.org/group/iesg/appeals/artifact/46
> >
> > We were mostly alone.
> >
> >
> >
> >
> >> Talvez a principal mensagem desta thread que podemos aprender, é que
> >> o mercado continua sinalizando a existência de problemas operacionais
> >> ainda não resolvidos de forma satisfatória. Se não conseguirmos
> >> oferecer alternativas simples para multihoming, renumeração e
> >> persistência de endereçamento, é natural que fabricantes procurem
> >> suas próprias soluções, infelizmente.
> >
> > Same thing applies to a number of other areas, such as the dumb debate
> > over slaac vs. dhcp6.
> >
> > It shouldn't be surprising that when presented with these things,
> > ipv6-outsides decide to spend their time elsewhere.
> >
> >
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260609/8217284d/attachment.htm>