[lacnog] A Disaster for IPv6 - Brought by Fortinet

[Fernando Frediani]

Hi Fernando

I would respectfully disagree on some points.
It is a firewall/router device which should still be conceived to work 
as expected, according to RFCs and Best Practices well established. If 
they don't understand, then it doesn't seem to be the best way throw it 
under the carpet doing an automatic NAT66 out-of-the-box to make it work.

Behavior should not be to do the right thing and have the device working 
as expected only if you know better. Vendor needs to have responsibility 
to push to it to market as well, not just try to resolve a problem at 
short term and risk causing a misconception in long term, specially to 
those who still need to know better.

Doing NAT66 using the WAN addresses will generate more "native" IPv6 
traffic towards the Internet, but at what cost ? Getting thousands of IT 
administrators to set the believe that is the right way of doing it and 
not having to worry about each device having its Global Unicast Address ?

I understand the point of something is better than nothing, but in the 
other hand I think we all, including vendors, need to endeavor to get 
the things in the correct way and even if you have to do something far 
from ideal, at least use that opportunity to bring knowledge to whoever 
needs it.

Best regards
Fernando

On 6/5/2026 4:53 PM, Fernando Gont wrote:
> 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,
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260608/f87c2f3b/attachment.htm>