<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em sex., 5 de jun. de 2026 às 16:53, Fernando Gont <<a href="mailto:fgont@si6networks.com">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"><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></blockquote><div class="gmail_quote gmail_quote_container"><br></div>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).<br>Eles geralmente estão lá (nos casos de PCP) com a finalizde de sinalizar para os controles stateless do firewall, e não reescrever cabeçalhos.<br><br>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.<br>Ou seja, praticamente qualquer aplicação que não queria ser server-centric vai quebrar com NAT66.<br><br><div>Fomentar NAT66 é um deserviço!<br>Um câncer que deve ser extirpado logo no começo.</div></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></div>