[lacnog] A Disaster for IPv6 - Brought by Fortinet

Lun Jun 8 14:42:50 -03 2026

Em seg., 8 de jun. de 2026 às 14:24, Douglas Fischer <
fischerdouglas en gmail.com> escreveu:

> 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.
>

Sim, isso que tento falar, que essa cultura de empregar para o IPv6 o mesmo
que o IPv4 foi, essa mudança , talvez seja o ponto crucial da transição que
desejamos.  Vejo direto essa transferência de hábito.

>
> 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!
>

E ainda falar que esses endereços podem não ser mais iguais nunca mais,
hehehehe  aí que o pessoal dá aquela "tela azul " mesmo.

Talvez tenhamos que criar um Selo do Bom Operador de Rede.  ;-)

>
>
> 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.
>

Já foi superado, sério ?   Que bom , ufas.   Estamos evoluindo então !!

[ ]´s
Henri

> 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/ed57d49b/attachment.htm>