[lacnog] A Disaster for IPv6 - Brought by Fortinet

[Fernando Gont]

Hello, Fernando,

On 05/06/2026 11:14, Fernando Frediani wrote:
> Hello all
> 
> I believe some have seen these news: https://weberblog.net/fortigate- 
> enables-nat-for-ipv6-by-default-%F0%9F%A4%A6/
> 
> This looks a real disaster for IPv6. 

It does not. -- maybe, even quite the opposite:
It's a firewall device that has a default mode that fails on the side 
what all users understand and know how to deal with.

And, e.g., let's folks focus on way more important and interesting stuff 
that, e.g., dealing with things such as these: 
https://www.rfc-editor.org/rfc/rfc8978.html

Then if you do know better and need something else, you can override the 
default, and move on.



> Something that was created to 
> restore end-to-end connectivity, 

Let's set expectations straight: IPv6 was "created" in the '90s, even 
before the vast majority of us were even allowed to legally drink beer. 
In a context that was totally different from now, 30 years later.


IPv6 will not restore end-to-end connectivity. -- Ironically, there's 
scenarios where such "end-to-end connectivity" is even worse than for 
IPv4, or where it's not even desirable.

IPv6 does give you the option so that, in those scenarios that do 
matter, you do not *have* to rely on network translation, and *can* 
connect from one peer to another without much of a hassle.




> with a thoughtless decision has to the 
> potential do change a lot in long term, given the context where Fortinet 
> devices are used.
> Hard to know what motivated Fortinet developers to do that, but you may 
> imagine that as many IT administrators that manage these boxes have 
> little clue about how to configure them for IPv6, they may have tried to 
> make it simpler, maybe at the pressure of some high level person to 
> "resolver the problem", came out with this very bad solution.

That has been the rethoric/story of IPv6 "evangelizers" (whatever that 
means), that has had very bad track record.


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.



> I wonder when such thing is decided internally if no one in the team 
> raised the seriousness of it or if did, if it was overruled. I can't 
> image this was a one person decision that went on unnoticed.

Kudos to them.  That said, Fortigate IPv6 support has been terrible on 
VPN fronts.. so not sure why *this* would be something one would 
particularly care.




> Although I NAT66 features may have a single usage now days which is to 
> have redundancy among 2 broadband ISPs (as Homenet never worked as 
> expected), such features, if they come embedded in the device's 
> firmware, there should be proper warnings when enabling it and what 
> should be used for.

Fact of life. If folks don't solve problems at the protocol level, 
people will solve problems their own way.





> Well, sad to see such thoughtless decisions from a vendor that is 
> supposed to be specialized in turning RFCs and Best Practices into 
> Enterprise Grade products with well informed technical and design 
> decisions.

IETF has been pretty bad at addressing things like this: 
https://www.rfc-editor.org/rfc/rfc8978.html .  Or multihoming.  so one 
can easily make the case that their approach solves an actual problem.

In most cases, except for companies in the business of moving packets 
around, IPv6 is not much of a thing: they are able to deploy and operate 
it quickly or hassle free, or they wouldn't botther (if at all in the 
first place).

Obrigado,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494