[lacnog] A Disaster for IPv6 - Brought by Fortinet

[Carlos Martinez - Cagnazzo]

Hi,

I think we should make a distinction between actual "NAT"  --that is, 
hiding a bunch of things behind a single IPv4/IPv6-- and "NPT" where you 
actually make a stateless translation where the host section of the 
address is kept as-is.

I don't like NAT w/port translation, not in IPv4 and much less in IPv6. 
I think it gives a false sense of security and hides behavior in ways 
that probably can be exploited.

Someone mentioned the ability of protocols like UPnP to punch holes in 
NAT as a "good thing". I honestly believe it is a terrible idea, and 
that it always has been, a a sad example of the things we've been forced 
to accept in this IPv4 port-translated Internet. There goes your 
supposed security layer brought by NAT. Any 10 usd piece of **** you buy 
at the supermarket can happily punch holes in your "nat security".

Rant aside, I can live with something like NPT, specially in Enterprise 
scenarios. I even believe it could in some situations actually be useful 
(multihoming without BGP, some renumbering scenarios).

"Live Long and Deploy IPv6" (most of you are too young to remember where 
this come from :-))) )

/Carlos

On 6/8/26 4:18 PM, Fernando Gont wrote:
> Hello, Henri,
>
> On 08/06/2026 12:30, Henri Alves de Godoy wrote:
>> Bom dia,
>>
>> Particularmente, não considero desejável ver NAT66 habilitado por 
>> padrão em dispositivos IPv6 
>
> The idea of defaulting to a "conservative, known, and well understood" 
> setting is a good one. -- at the end of the day, if you know what 
> you're doing, you can always override.  And if you don't know what 
> you're doing, you shouldn't be doing it in the first place... so... 
> who cares?
>
>
>
>> (aliás o NAT66 é uma maneira de entendimento que se herdou seguindo a 
>> ideia do NAT44).
>
> There's probably nothing that has hurted IPv6 deployment more than the 
> argument of "forget everything you know about IPv4".
>
>
>
>
>> 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,
>
> How many of the folks in this discussion have participated in 
> discussions where some of us have tried to address some of the 
> associated issues?   Answer: 0.
>
>
>
>
>>  (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.
>
> Human factor: whatever is well and best understood trumps everything 
> else.
>
>
>
>
>> 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. 
>
> Oh, that one is simple: I've tried to mitigate some of such issues. 
> Sent heads up on this list for all such drafts, and seen 0 support 
> from folks on this list on the relevant wgs.
>
> Ironically, the more pro-ipv6 folks tend to be the least involved in 
> solving the underlying problems, and vice-versa.  (as much as I flag 
> issues, I've devoted a lot of time to address them, where they can 
> actually be addressed).
>
>
>
>
>> 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.
>
> Let's not pretend that IPv6 has a great and clean architecture.
>
> In fact, the very first and core idea of not messing up with IPv6 
> packets as they traverse the entwork was messed up by the IETF itself, 
> by companies with big pockets well invested in SRv6.
>
> A few of us fought that one: 
> https://datatracker.ietf.org/group/iesg/appeals/artifact/46
>
> We were mostly alone.
>
>
>
>
>> 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.
>
> Same thing applies to a number of other areas, such as the dumb debate 
> over slaac vs. dhcp6.
>
> It shouldn't be surprising that when presented with these things, 
> ipv6-outsides decide to spend their time elsewhere.
>
>