[lacnog] A Disaster for IPv6 - Brought by Fortinet

Lun Jun 8 14:24:41 -03 2026

Então Henri...
Eu acho que as questões "porque eles fizeram isso?" ou "quais as lacunas?"
estão intrinsecamente ligadas a aquela maneira de pensar IPv4 que NÃO DEVE
SER EMPREGADA no IPv6.

Falando pra geral agora:
Hey Você Operador de Rede!
Enquanto você não entende que um único dispositivo final vai poder ter 1,
2, 3, 4, 10 ou até talvez muito mais que isso de endereeços IPv6 só pra
ele...
Você NÃO VAI poder se considerar um bom operador de rede IPv6.

Essa coisa de "um host = um IP" acabou!

Inevitavelmente isso me lembra a enfadonha briguinha idiota com a galera do
DOCKER-NAT-Adicted que não aceita que o NAT66 para docker é péssimo e é uma
fase superada.

Em seg., 8 de jun. de 2026 às 12:30, Henri Alves de Godoy <
henri.godoy en fca.unicamp.br> escreveu:

> Bom dia,
>
> Particularmente, não considero desejável ver NAT66 habilitado por padrão
> em dispositivos IPv6 (aliás o NAT66 é uma maneira de entendimento que se
> herdou seguindo a ideia do NAT44). Entretanto, me preocupa mais o motivo
> pelo qual fabricantes estão caminhando nessa direção, segundo a
> notícia inicial dos comentários sobre a Fortinet.
>
> 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,  (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.
>
> 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. 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.
>
> 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.
>
> A discussão, portanto, talvez não deva ser apenas sobre por que a Fortinet
> fez isso, mas também sobre quais lacunas ainda permanecem abertas para que
> esse tipo de decisão seja vista como necessária.
>
> Abraços,
> Henri
>
> Em seg., 8 de jun. de 2026 às 03:24, Fernando Gont <fgont en si6networks.com>
> escreveu:
>
>> Hello, Douglas,
>>
>> On 07/06/2026 10:13, Douglas Fischer wrote:
>> >
>> >     I will argue the other way around: I have implemented IPv6 in some
>> >     scenarios where I explicitly decided to do NAT for IPv6. -- because
>> >     doing so in the orthodox manner would have been a no go.
>> >
>> >     IPv6+NAT, in those scenarios, has boild down to "same thing as IPv4,
>> >     just this longer and awkward addresses", and move one.  There's
>> usually
>> >     larger fish to fry.
>> >
>> > Cabe dizer aqui que os "nat-helpers"(ou ALGs) não estão ativos em IPv6
>> > em praticamente nenhum firewall do mercado(open source ou não).
>>
>> Tampoco el soporte IPv6 para UPnP.  -- Por lo tanto, inclusive si
>> asignas direcciones globales a tus hosts, pero el CPE tiene un firewall
>> stateful, probablemente tengas mejor conectividad con IPv4 que con IPv6.
>>   (Con IPv4 podras abrir agujeros en el firewall, mientras que con IPv6
>> no).
>>
>> Ver:
>>
>> https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-address-reachability
>>
>>
>> > Então apesar de o NAT66 "funcionar", ele quebra qualquer outra
>> aplicação
>> > que trabalhe com conexões auxiliares sinalizadas a partir de uma
>> > primeira conexão.
>>
>> Lo que en todo caso "quiebra" algo es la politica del firewall, y/o la
>> imposibilidad de no crear agujeros en el mismo -- no el NAT66 en si.
>>
>>
>> (Nota: En muchos casos, los problemas para lidiar con NATs hablan mas de
>> los problemas de diseño de aplicaciones/protocolos, que de los NATs en si)
>>
>>
>>
>> > Ou seja, praticamente qualquer aplicação que não queria ser server-
>> > centric vai quebrar com NAT66.
>>
>> El NAT66 no es peor que el NAT multicapa de IPv4. Y dado que todas las
>> aplicaciones  que utilizamos hoy en dia, apra bien o para mal, estan
>> acostumbradas a lidiar con IPv4, todo esto es terreno ya conocido.
>>
>>
>>
>> > Fomentar NAT66 é um deserviço!
>>
>> Desconozco quien "fomenta" NAT66.
>>
>> -- En realidad, es bastante curiosa la idea de "fomentar" cosas con los
>> recursos de otros. :-)  -- sea el uso de NAT, el despliegue de IPv6, o
>> lo que fuera.
>>
>> Las organizaciones toman sus propias decisiones, con su propio criterio,
>> considerando sus propias realidades, problemas, y prioridades. -- y esta
>> bien que asi sea.
>>
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont en si6networks.com
>> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>>
>> _______________________________________________
>> 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/20260608/f25bb9c3/attachment-0001.htm>