<div dir="ltr"><div>Existe um ponto mais importante!<br>(Que talvez eu não tenha conseguido cobrir em minhas falas anteriores.)</div><br>Eu sempre repito, e sempre vou repetir.<br>"A Internet foi feita para sem FIM-A-FIM."<br>Essa frase traz como primeira interpretação o fim do NAT, que é o tema que estamos debatendo aqui há um tempo.<br><br>Mas tem um ponto mais importante que essa questão do NÃO-NAT.<br>A Internet NÃO NASCEU para ser Server Centric, ou melhor dizendo: A Internet NÃO NASCEU PARA SER CLOUD CENTRIC.<br>E é isso que devemos defender com unhas e dentes mais do que lutar contra o NAT.<br><br>Isso é tão importante que abrange diversas outras áreas muito mais debatidas no mundo de rede.<br>Privacidade é um exemplo disso.<br><div>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.<br>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.</div><div><br></div><div>Sim.Contextos específicos(como ambiente corporativo) demandam soluções para isso.<br>Mas acredito que as soluções para isso estejam mais perto do que a RFC que o próprio Gont comentou <a href="https://www.rfc-editor.org/rfc/rfc8978.html">https://www.rfc-editor.org/rfc/rfc8978.html</a> do que atrás de emporcalhar o mundo estéril do IPv6 com esse câncer chamado NAT.<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em seg., 8 de jun. de 2026 às 17:15, Carlos Martinez - Cagnazzo <<a href="mailto:carlos@cagnazzo.uy">carlos@cagnazzo.uy</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">Hi,<br>
<br>
I think we should make a distinction between actual "NAT"  --that is, <br>
hiding a bunch of things behind a single IPv4/IPv6-- and "NPT" where you <br>
actually make a stateless translation where the host section of the <br>
address is kept as-is.<br>
<br>
I don't like NAT w/port translation, not in IPv4 and much less in IPv6. <br>
I think it gives a false sense of security and hides behavior in ways <br>
that probably can be exploited.<br>
<br>
Someone mentioned the ability of protocols like UPnP to punch holes in <br>
NAT as a "good thing". I honestly believe it is a terrible idea, and <br>
that it always has been, a a sad example of the things we've been forced <br>
to accept in this IPv4 port-translated Internet. There goes your <br>
supposed security layer brought by NAT. Any 10 usd piece of **** you buy <br>
at the supermarket can happily punch holes in your "nat security".<br>
<br>
Rant aside, I can live with something like NPT, specially in Enterprise <br>
scenarios. I even believe it could in some situations actually be useful <br>
(multihoming without BGP, some renumbering scenarios).<br>
<br>
"Live Long and Deploy IPv6" (most of you are too young to remember where <br>
this come from :-))) )<br>
<br>
/Carlos<br>
<br>
On 6/8/26 4:18 PM, Fernando Gont wrote:<br>
> Hello, Henri,<br>
><br>
> On 08/06/2026 12:30, Henri Alves de Godoy wrote:<br>
>> Bom dia,<br>
>><br>
>> Particularmente, não considero desejável ver NAT66 habilitado por <br>
>> padrão em dispositivos IPv6 <br>
><br>
> The idea of defaulting to a "conservative, known, and well understood" <br>
> setting is a good one. -- at the end of the day, if you know what <br>
> you're doing, you can always override.  And if you don't know what <br>
> you're doing, you shouldn't be doing it in the first place... so... <br>
> who cares?<br>
><br>
><br>
><br>
>> (aliás o NAT66 é uma maneira de entendimento que se herdou seguindo a <br>
>> ideia do NAT44).<br>
><br>
> There's probably nothing that has hurted IPv6 deployment more than the <br>
> argument of "forget everything you know about IPv4".<br>
><br>
><br>
><br>
><br>
>> Se houver necessidade de algum mecanismo de tradução para lidar com <br>
>> cenários de multihoming ou renumeração, vejo soluções como NPTv6 como <br>
>> um mal menor, mas ainda bem feio e deselegante,<br>
><br>
> How many of the folks in this discussion have participated in <br>
> discussions where some of us have tried to address some of the <br>
> associated issues?   Answer: 0.<br>
><br>
><br>
><br>
><br>
>>  (diferente no que chamamos de NAT66), por preservar melhor as <br>
>> características originais do IPv6 e evitar a complexidade operacional <br>
>> associada à tradução de portas e ao compartilhamento de endereços.<br>
><br>
> Human factor: whatever is well and best understood trumps everything <br>
> else.<br>
><br>
><br>
><br>
><br>
>> Há alguns bons anos e mais agora, discutimos os desafios de <br>
>> multihoming, remuneração e estabilidade de endereçamento em IPv6. <br>
>> Apesar de diversos esforços até citados em alguns drafts iniciais, <br>
>> ainda não conseguimos oferecer soluções simples e amplamente adotadas <br>
>> para esses problemas. <br>
><br>
> Oh, that one is simple: I've tried to mitigate some of such issues. <br>
> Sent heads up on this list for all such drafts, and seen 0 support <br>
> from folks on this list on the relevant wgs.<br>
><br>
> Ironically, the more pro-ipv6 folks tend to be the least involved in <br>
> solving the underlying problems, and vice-versa.  (as much as I flag <br>
> issues, I've devoted a lot of time to address them, where they can <br>
> actually be addressed).<br>
><br>
><br>
><br>
><br>
>> Como consequência, empresas e fabricantes acabam implementando aquilo <br>
>> que resolve a necessidade imediata de seus clientes, mesmo que não <br>
>> represente a melhor escolha arquitetural.<br>
><br>
> Let's not pretend that IPv6 has a great and clean architecture.<br>
><br>
> In fact, the very first and core idea of not messing up with IPv6 <br>
> packets as they traverse the entwork was messed up by the IETF itself, <br>
> by companies with big pockets well invested in SRv6.<br>
><br>
> A few of us fought that one: <br>
> <a href="https://datatracker.ietf.org/group/iesg/appeals/artifact/46" rel="noreferrer" target="_blank">https://datatracker.ietf.org/group/iesg/appeals/artifact/46</a><br>
><br>
> We were mostly alone.<br>
><br>
><br>
><br>
><br>
>> Talvez a principal mensagem desta thread que podemos aprender, é que <br>
>> o mercado continua sinalizando a existência de problemas operacionais <br>
>> ainda não resolvidos de forma satisfatória. Se não conseguirmos <br>
>> oferecer alternativas simples para multihoming, renumeração e <br>
>> persistência de endereçamento, é natural que fabricantes procurem <br>
>> suas próprias soluções, infelizmente.<br>
><br>
> Same thing applies to a number of other areas, such as the dumb debate <br>
> over slaac vs. dhcp6.<br>
><br>
> It shouldn't be surprising that when presented with these things, <br>
> ipv6-outsides decide to spend their time elsewhere.<br>
><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">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>