[Arch-TK]

The article seems to perpetuate one of those age old myths that NAT has something to do with protection.

Yes, in a very superficial sense, you can't literally route a packet over the internet backwards to a host behind NAT without matching a state entry or explicit port forwarding. But implementing NAT on it's own says nothing about the behavior of your router firewall with regards to receiving Martians, or with regards to whether the router firewall itself accepts connections and if the router firewall itself isn't running some service which causes exposure.

To actually protect things behind NAT you still need firewall rules and you can keep those rules even when you are not using NAT. Thus those rules, and by extension the protection, are separable from the concept of NAT.

This is the kind of weird argument that has caused a lot of people who hadn't ever used IPv6 to avoid trying it.

[globular-toast]

Yeah, I keep meaning to write something about this. I've definitely noticed people wary of IPv6 because their machines get "real" IP addresses rather than the "safe" RFC1918 ones. Of course, having a real IP address is precisely the point of IPv6.

It's like we've been collectively trained to think of RFC1918 as "safe" and forgotten what a firewall is. It's one of those "a little knowledge is a dangerous thing" things.

[sshine]

In a world where people think NAT addresses are safe because you don’t need to know anything else about firewalls, IPv6 _is_ fundamentally less secure.

[throw0101a]

> In a world where people think NAT addresses are safe because […]

The vast, vast majority of people do not know what NAT is: ask your mom, aunt, uncle, grandma, cousin(s), etc. They simply have a 'magic box' (often from the ISP) that "connects to Internet". People connect to it (now mostly via Wifi) and they are "on the Internet".

They do not know about IPv4 or IPv6 (or ARP, or DHCP, or SLAAC).

As long as the magic box is statefully inspecting traffic, which is done for IPv4-NAT, and for IPv6 firewalls, it makes no practical difference which address family you are using from a security perspective.

The rending of garments over having a globally routable IPv6 address (but not globally reachable, because of SPI) on your home is just silliness.

If you think NAT addresses are safe because… of any reason whatsoever really… simply shows a lack of network understanding. You might as well be talking to a Flat Earther about orbital mechanics.

[mqus]

> which is done for IPv4-NAT, and for IPv6 firewalls

Are internet routers that do ipv4 NAT usually also doing an IPv6 firewall (meaning they only let incoming connections in if they are explicitly allowed by some configuration)? Maybe thats the point where the insecurity comes from. A Home NAT cannot work any other way(it fails "safely"), a firewall being absent usually means everything just gets through.

[globular-toast]

All the ones I've had have had a firewall by default for IPv4 and IPv6, yes. If ISPs are shipping stuff without a firewall by default I'd consider that incompetence given people don't understand this stuff and shitty IoT devices exist.

I do wonder how real the problem is, though. How are people going to discover a random IPv6 device on the internet? Even if you knew some /64 is residential it's still impractical to scan and find anything there (18 quintillion possible addresses). If you scanned an address per millisecond it would take 10^8 years, or about 1/8 the age of the earth, to scan a /64.

Are we just not able to think in such big numbers?

[throw0101a]

> Are internet routers that do ipv4 NAT usually also doing an IPv6 firewall (meaning they only let incoming connections in if they are explicitly allowed by some configuration)?

Consider the counter-factual: can you list any home routers/CPEs that do not do SPI, regardless of protocol? If someone found such a thing, IMHO there would be a CVE issued quite quickly for it.

And not just residential stuff: $WORK upgraded firewalls earlier in 2025, and in the rules table of the device(s) there is an entry at the bottom that says "Implicit deny all" (for all protocols).

So my question to NAT/IPv6 Truthers is: what are the devices that allow IPv6 connections without SPI?

And even if such a thing exists, a single IPv6 /64 subnet is as large as four billion (2^32) IPv4 Internets (2^32 addresses): good luck trying to find a host to hit in that space (RFC 7721).

[thayne]

There is one practical difference. IPv6 without a NAT exposes information about different devices inside the private network. A NAT (whether ipv4 or ipv6) will obfuscate how many devices are on the network. Whether that is desirable depends on the circumstances.

[throw0101a]

> A NAT (whether ipv4 or ipv6) will obfuscate how many devices are on the network. Whether that is desirable depends on the circumstances.

"Revisiting IoT Fingerprinting behind a NAT":

* https://par.nsf.gov/servlets/purl/10332218

"Study on OS Fingerprinting and NAT/Tethering based on DNS Log Analysis":

* https://www.irtf.org/raim-2015-papers/raim-2015-paper21.pdf

Also:

> […] In this paper, we design an efficient and scalable system via spatial-temporal traffic fingerprinting from an ISP’s perspective in consideration of practical issues like learning- testing asymmetry. Our system can accurately identify typical IoT devices in a network, with the additional capability of identifying what devices are hidden behind NAT and the number of each type of device that share the same IP address. […]

* https://www.thucloud.com/zhenhua/papers/TON'22%20Hidden_IoT....

Thinking you're hiding things because you're behind a NAT is security theatre.

[labcomputer]

> IPv6 without a NAT exposes information about different devices inside the private network.

In practice this has not been true for over 20 years.

IPv6 devices on SLAAC networks (which is to say, almost all of them) regularly rotate their IPv6 address. The protocol also explicitly encourages (actually, requires) hosts to have more than one IPv6 address active at any given time.

You are also making a wrong assumption that the externally visible address and port ranges chosen by the NAT device do not make the identity of internal devices easily guessable.

[zamadatix]

In both cases the only consumer security comes from "the home router defaults to being a stateful firewall". The only difference between the two is whether it also defaults to doing NAT with that state, which is not what was making IPv4 secure for people unaware either.

[mzhaase]

If you think about it, NAT offers pretty much the same protection as a default stateful firewall. Only allowing packets from the outside related to a connection initiated from the inside.

[lloeki]

> Only allowing packets from the outside related to a connection initiated from the inside.

NAT a.k.a IP masquerading does not do that, it only figures out that some ingress packets whose DST is the gateway actually map to previous packets coming from a LAN endpoint that have been masqueraded before, performs the reverse masquerading, and routes the new packet there.

But plop in a route to the network behind and unmatched ingress packets definitely get routed to the internal side. To have that not happen you need to drop those unmatched ingress packets, and that's the firewall doing that.

Fun fact: some decade ago an ISP where I lived screwed that up. A neighbour and I figured out the network was something like that:

    192.168.1.x --- 192.168.1.1 --
                                  \
                                   10.0.0.x ----> WAN
                                  /
    192.168.2.x --- 192.168.2.1 --

192.168.1 and 192.168.2 would be two ISP subscribers and 10.0.0.x some internal local haul. 192.168.x.1 would perform NAT but not firewall.

You'd never see that 10.0.0.x usually as things towards WAN would get NAT'd (twice). But 10.0.0.x would know about both of the 192, so you just had to add respective routes to each other in the 192.168.x.1 and bam you'd be able to have packets fly through both ways, NAT be damned.

Network Address Translation is not a firewall and provides no magically imbued protection.

[grosswait]

I have never seen a NAT implementation that forwarded every packet sent to it. As you stated in your first sentence, NAT forwards packets that match previous packets. Assuming it does that job well, that’s filtering right there.

[dijit]

its pretty common to have the NAT gateway also be a stateful firewall (you’re tracking state, after all) but they’re not the same and you can have one without the other.

Its just uncommon in consumer or prosumer devices.

A similar allegory is perhaps industrial washing machines vs consumer ones or that printer/scanner combos are common (even in offices) but print shops and people who actually need a lot of paper would have dedicated equipment that does either scanning or copying better.

It’s also like a leatherman, they all have some commonality (the need to be gripped) so theres a lot of combination; but a tradie would only use one as a last resort- often preferring a proper screwdriver.

[throw0101a]

> I have never seen a NAT implementation that forwarded every packet sent to it.

* https://kb.netgear.com/25891/What-is-the-De-Militarized-Zone...

* https://support.linksys.com/kb/article/312-en/

* https://www.asus.com/ca-en/support/faq/1011723/

[eqvinox]

> NAT offers pretty much the same protection as a default stateful firewall

Most NAT requires itself to include a stateful firewall; it's the same thing as the NAT flow table. This whole trope is mostly getting into people's heads to not forget about actually configuring that "free" firewall properly, since it'll just be a poor one otherwise.

[gldrk]

>Yes, in a very superficial sense, you can't literally route a packet over the internet backwards to a host behind NAT without matching a state entry or explicit port forwarding.

Don’t forget source routing. That said, depending on your threat model, it’s not entirely unreasonable to just rely on your ISP’s configuration to protect you from stuff like this, specifically behind an IANA private range.

[sedawkgrep]

I don't think source routing is a thing anymore. At least if you're talking about the ability of a source to specify a path to its destination.

The last time I heard about source routing actually being a useful feature or a vulnerability used by hackers was the 1990's.