[lacnog] A Disaster for IPv6 - Brought by Fortinet

[Fernando Gont]

On 09/06/2026 10:20, Carlos Martinez-Cagnazzo wrote:

>> On 08/06/2026 17:15, Carlos Martinez - Cagnazzo wrote:
>>>
>> The argument of "NAT is not a security technology" is an old one -- 
>> and, IMO, a discussion that never made sense.
> An old one, but still a relevant one. And yes it makes a lot sense since 
> it sends a message to less technical folk. Not you or me, but the wider 
> public live under a false sense of security.

That's exactly the point. It is not "a false sense of security".

Or, otherwise, what is "a real sense of security"? -- there's no such a 
thing.

You have tools, each of which may contribute to secure a resource. -- 
but there's no silver bullet.



>> At the end of the day, NAT is a technology that does make the life of 
>> an attacker harder. Network topology information is typically of use 
>> to an attacker -- and NATs do hide it.  OTOH, a NAT results, as a side 
>> effect, in a diode-like firewall -- a policy that also makes the life 
>> of an attacker harder.
> It depends on which side of the NAT the attacker is on. If he/she is on 
> the public side, my opinion would be a qualified "maybe". 

It's not "maybe". It actually makes the task harder in a lot of cases: I 
have no easy way to map the network, and communication to such systems 
is blocked by the address space itself.



>> Discussions of the kind of "Oh! But the resulting filtering policy 
>> doesn't have to do with NAT itself, but is actually a side effect" 
>> seem more like the kind of philosophical debates one would have over a 
>> glass of one (for the sake of debating), than one of any practical 
>> implication. :-)
> 
> No, it is not a philosophical debate. It's an actual operational 
> consideration. Public addresses on both sides of a firewall do not mean 
> there is no stateful firewall in operation. 

Agreed. That's why I've argued that IPv6 doesn't buy you, per se, e2e 
connectivity.



> This is also true for IPv4. 
> During the ramp up to a few LACNIC meetings we have met people who 
> actually believe _it was not possible_ to have public IPv4 addresses  on 
> both sides of a stateful firewall.
> 
> This is the kind of damage NAT does, not only technically, but to the 
> operational ability of well intentioned folk.

Why would you possibly blame NATs, rather than education, for that?



>> Again, it's tool/mechanism. In some scenarios it might be a good 
>> thing, in other it might not. In an Enterprise or managed network, 
>> it's possible a bad idea. In an unmanaged network, it's definitely 
>> orders of magnitude better than simlpy assigning global addresses to 
>> all devices and simply allowing all incoming conenctions.
>>
> It seems to be that there is a significant cognitive disonance here. On 
> one hand we are afraid of some yet-to-be found issues with IPv6 but we 
> are ok with a 10 usd camera punching holes through a firewall. I think 
> our collective risk perception here is not right.

Not sure what you mean. I'll repeat once more: it always depends on the 
context.

* I do have networks where I may use upnp from a e.g. raspberry pi (not 
a 10 USD camera) to allow incoming connections to a device device -- and 
I simply can't get incoming connections via IPv6 (because a CPE (which I 
do not control) has a diode-like firewall enabled by default).

* I also have networks where I have VPN connections doing NAT for both 
IPv4 and IPv6, because I don't want the support teams to figure out 
ipv6-specific details.

* I also have networks where endpoints get private address space + nat, 
and ipv6 GUAs from the ISP -- where I use very agressive lifetimes for 
prefixes, to deal with slaac-renum.

* I do have networks where I have incoming connections allowed on both 
ipv4 and ipv6.

* And I also have networks where I don't strictly *need* IPv6, but have 
deployed it anyway.

(and a bunch of other combinations too).


There's no reason why I should use the same approach in quite different 
contexts. -- And that is the point I was trying to convey: there's no 
"one right way of doing things".   There's a toolset -- and how you use 
that toolset depends on the context, both technical and human.


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