<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Fernando</p>
<p>I would respectfully disagree on some points.<br>
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.</p>
<p>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.</p>
<p>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 ?</p>
<p>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.</p>
<p>Best regards<br>
Fernando</p>
<div class="moz-cite-prefix">On 6/5/2026 4:53 PM, Fernando Gont
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:21eb323a-1d5f-4d43-92d9-b470ab65c2fa@si6networks.com">Hello,
Fernando,
<br>
<br>
On 05/06/2026 11:14, Fernando Frediani wrote:
<br>
<blockquote type="cite">Hello all
<br>
<br>
I believe some have seen these news:
<a class="moz-txt-link-freetext" href="https://weberblog.net/fortigate">https://weberblog.net/fortigate</a>-
enables-nat-for-ipv6-by-default-%F0%9F%A4%A6/
<br>
<br>
This looks a real disaster for IPv6. </blockquote>
<br>
It does not. -- maybe, even quite the opposite:
<br>
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.
<br>
<br>
And, e.g., let's folks focus on way more important and interesting
stuff that, e.g., dealing with things such as these:
<a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc8978.html">https://www.rfc-editor.org/rfc/rfc8978.html</a>
<br>
<br>
Then if you do know better and need something else, you can
override the default, and move on.
<br>
<br>
<br>
<br>
<blockquote type="cite">Something that was created to restore
end-to-end connectivity, </blockquote>
<br>
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.
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">with a thoughtless decision has to the
potential do change a lot in long term, given the context where
Fortinet devices are used.
<br>
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.
<br>
</blockquote>
<br>
That has been the rethoric/story of IPv6 "evangelizers" (whatever
that means), that has had very bad track record.
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Fact of life. If folks don't solve problems at the protocol level,
people will solve problems their own way.
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
IETF has been pretty bad at addressing things like this:
<a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc8978.html">https://www.rfc-editor.org/rfc/rfc8978.html</a> . Or multihoming. so
one can easily make the case that their approach solves an actual
problem.
<br>
<br>
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).
<br>
<br>
Obrigado,
<br>
</blockquote>
</body>
</html>