<div dir="ltr">Então Henri...<br>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.<br><br>Falando pra geral agora:<br>Hey Você Operador de Rede!<br>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...<br>Você NÃO VAI poder se considerar um bom operador de rede IPv6.<br><br>Essa coisa de "um host = um IP" acabou!<br><br><br>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.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em seg., 8 de jun. de 2026 às 12:30, Henri Alves de Godoy <<a href="mailto:henri.godoy@fca.unicamp.br">henri.godoy@fca.unicamp.br</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>Bom dia, </p><p>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.</p><p>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.  </p><p>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.</p><p>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.</p><p>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.</p><p>Abraços,<br>Henri</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 8 de jun. de 2026 às 03:24, Fernando Gont <<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello, Douglas,<br>
<br>
On 07/06/2026 10:13, Douglas Fischer wrote:<br>
> <br>
>     I will argue the other way around: I have implemented IPv6 in some<br>
>     scenarios where I explicitly decided to do NAT for IPv6. -- because<br>
>     doing so in the orthodox manner would have been a no go.<br>
> <br>
>     IPv6+NAT, in those scenarios, has boild down to "same thing as IPv4,<br>
>     just this longer and awkward addresses", and move one.  There's usually<br>
>     larger fish to fry.<br>
> <br>
> Cabe dizer aqui que os "nat-helpers"(ou ALGs) não estão ativos em IPv6 <br>
> em praticamente nenhum firewall do mercado(open source ou não).<br>
<br>
Tampoco el soporte IPv6 para UPnP.  -- Por lo tanto, inclusive si <br>
asignas direcciones globales a tus hosts, pero el CPE tiene un firewall <br>
stateful, probablemente tengas mejor conectividad con IPv4 que con IPv6. <br>
  (Con IPv4 podras abrir agujeros en el firewall, mientras que con IPv6 no).<br>
<br>
Ver: <br>
<a href="https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-address-reachability" rel="noreferrer" target="_blank">https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-address-reachability</a><br>
<br>
<br>
> Então apesar de o NAT66 "funcionar", ele quebra qualquer outra aplicação <br>
> que trabalhe com conexões auxiliares sinalizadas a partir de uma <br>
> primeira conexão.<br>
<br>
Lo que en todo caso "quiebra" algo es la politica del firewall, y/o la <br>
imposibilidad de no crear agujeros en el mismo -- no el NAT66 en si.<br>
<br>
<br>
(Nota: En muchos casos, los problemas para lidiar con NATs hablan mas de <br>
los problemas de diseño de aplicaciones/protocolos, que de los NATs en si)<br>
<br>
<br>
<br>
> Ou seja, praticamente qualquer aplicação que não queria ser server- <br>
> centric vai quebrar com NAT66.<br>
<br>
El NAT66 no es peor que el NAT multicapa de IPv4. Y dado que todas las <br>
aplicaciones  que utilizamos hoy en dia, apra bien o para mal, estan <br>
acostumbradas a lidiar con IPv4, todo esto es terreno ya conocido.<br>
<br>
<br>
<br>
> Fomentar NAT66 é um deserviço!<br>
<br>
Desconozco quien "fomenta" NAT66.<br>
<br>
-- En realidad, es bastante curiosa la idea de "fomentar" cosas con los <br>
recursos de otros. :-)  -- sea el uso de NAT, el despliegue de IPv6, o <br>
lo que fuera.<br>
<br>
Las organizaciones toman sus propias decisiones, con su propio criterio, <br>
considerando sus propias realidades, problemas, y prioridades. -- y esta <br>
bien que asi sea.<br>
<br>
<br>
-- <br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a><br>
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><img width="420" height="127" src="https://ci3.googleusercontent.com/mail-sig/AIorK4y46kkRvCpAMdinHijHNmlXWyL4L3BEzwJmxsbtJANj-VtOAqdNz0cIvzYqkHx9ILVpq1N04LB7TzsT"><br></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>