Several things can be correct at the same time:

* NAT is not a firewall

* NAT can still filter traffic (and practically always does)

* NAT can hence still provide security features

* The real world often does not care about original definitions of a term. NAT was originally meant to just do address translation, but it has evolved.

* Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.

This is all to underscore the author's point: NAT may necessitate stateful tracking, but firewalls without translation has been deployed at massive scale for one of the most numerous types of device in existence.

I believe the common knowledge is somewhat more nuanced than people would have you believe

I present to you two separate high-value targets whose IP address has leaked:

  IPv4 Target: 192.168.0.1
  IPv6 Target: 2001:1868:209:FFFD:0013:50FF:FE12:3456

Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)

Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:

Here is a real world target:

  FDC2:1045:3216:0001:0013:50FF:FE12:3456

NAT is not for security, it does not provide security. It is often bundled with a firewall. The firewall provides security. Firewall=\=NAT

My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.

NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.

But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.

But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.

You can provoke loops and tangles of many sorts, some at the same protocol level and others going up and down.

My memory is fading but I vaguely recall a time when all of AOL shared something like a dozen egress addresses for certain traffic -- might have been proxies as opposed to NAT/"PAT" as we know it today. Iow, you couldn't block one without blocking 1/12 of AOL users.

Stronger memories of a time when your IP address (some were nat, some were not, varied by ISP) depended on which modem bank you dialed into, which was strongly influenced by what phone number you dialed. Which diluted the identity value of a given IP for a computer or user.

Your title is "IPv6 is not insecure because it lacks NAT"

I'm sure anyone who understands how NAT offers the equivalent of a default block rule also understands that the absence of NAT alone doesn't make IPv6 insecure. This makes the title feel a little clickbaity-strawmanny, sorry.

Your response seems to be: "most firewalls have a default block rule too meaning they're no worse than IPv4 w/ NAT."

There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)

That doesn't make IPv6 insecure because no NAT. But it does mean - IMO - that the intrinsic block that comes with IPv4 NAT is a better security measure for making devices inaccessible than relying on default firewall rules.

What point are you trying to make here, and is it actually more useful than the point you say you're addressing?

As I keep trying to explain each time this comes up: no, it doesn't and it won't.

When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.

Of course, this just strengthens your point that NAT isn't security.

(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)

NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.

NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.

https://datatracker.ietf.org/doc/html/rfc6296

This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across town, she would not survive it.

A correctly configured IPv6 firewall provides equivalent protection to a correctly configured IPv4 firewall and NAT. Either way, connections that do not originate from within the local network are going to be rejected.

But if the firewall is misconfigured, then NAT will make it more difficult for an attacker on the internet to discover and exploit vulnerabilities on the local network.

"Defense in depth" is a valid security principle. But NAT also creates real-world problems that IPv6 solves. As with all things, there are tradeoffs, and whether or not you should enable IPv6 on your local network depends on your use case.

Ipv6 doesn't (currently, will it ever?) have the same address space problem so each device anywhere could be globally routable. But we know that's not really a good thing security-wise. But why couldn't we implement NAT for it as a security mechanism, instead of an address space solution?

Admittedly I'm not expert so I might be talking shit.

SLAAC basically means your routable IPv6 address changes so many times in a day (and there are multiple of those at any given instant) that even if the attackers know your prefix, its going to be very difficult to do anything meaningful. the address space is too big.

And we are assuming here that there is no firewall.

Note : macOS firewall on a new install is disabled iirc.

A local router that I can control deals with how to map from my public IP to my private IPs.

This is not security but is obfuscation of the traffic.

Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.

> But the security benefits people attribute to NAT actually come from the stateful firewall that’s typically bundled with NAT routers.

1. It requires a stateful firewall.

2. It isn't possible to accidentally a default-allow rule on that firewall.

It may not be intended as a security feature, but it can't not act as one in practice.

As far as I can tell, this is just pedantry, until those features are implemented in most ISP gateways. Akamai has been warning that IPv6 scanning attacks are on the rise.

Maybe someone knows better than I about this.

Perhaps not in the high brow network security world, but in practice it really is used that way.

Who here has never launched an unauthenticated server on their LAN?

Arguing this is pointless anyway because it's not even my decision, it's my ISP. I am however quite happy with my ISP's choices in this regard.

IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged. The IP address is just a technicality and outside of local networks, just a part of the routing strategy.

IPv6 on the other hand is like an URL - an address you can use to find any device from anywhere on the planet. It makes no distinction between client and server. Which is why its pushed in places like IoT and smartphones - a voip call has no conceptual client and server.

One could make ones smartphones Ipv6 address openly available, and anyone could initiate a voip call to their phones. Would this be wise? I'd argue there's no scenario under which this doesn't cause an unacceptable level of risk, as even if the software is perfect, they'd be still vulnerable to DDOS attacks.

This means that NAT-equivalent firewall rules are necessary, which makes the whole discussion kind of moot, but it's not a good portent for Ipv6 that it makes previously unfeasible kinds of attacks potentially practical.

NAT also allows for other neat tricks, like IP level load balancing.

I'd say one huge and unambiguous advantage of IPv6 is that it makes UDP trivial.

NAT (in all its forms) is just a very convenient technology for many people and niche situations.

And adoption of IPv6 will be hindered as long as NAT is not a first class citizen.

And of course, mostly NAT should not be used as "firewall replacement". But what many firewall proponents forget here:

NON-IT People at home cannot run and manage a firewall (and proxies). For them, NAT is a convenient and mostly okayish replacements.

Another niche would be IP Packet Handling of VMs.

  Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface ID

Of course you can have default drop in your IPV6 firewall, but it's far easier to keep in your head that internal NATed IPs aren't accessible and "real" IPs are.

It is well known that NAT is not meant for security and that NAT is not a firewall. But one cannot deny that it implicitly brings some "default" security to the table. With NAT it's basically impossible to screw you over because there is no meaningful practical way to allow inbound connections without the client explicitly defining them (port forwarding). With IPv6, you could have a lazy vendor that does not do any firewalling or a has a default allow policy or maybe buggy firewall. With NAT that is not possible. There is no lazy/buggy NAT implementation that allows inbound connections for your entire network, because it is technically not possible. When a NATting device receives a packet with a destination port that has not previously been opened by a client, it does not decide to drop this packet because of a decision by the vendor. It drops the packet because there is simply no other option due to the nature of NAT. That is what people mean when they talk about the inherent "security" of NAT.

Again, NAT is terrible. We need to finally get rid globally of IPv4 and all the NATting that comes with it. But let's keep it to the facts.

And IPv4 NAT is actually possible to penetrate sometimes. So for some networks, IPv4 provides better P2P connectivity, than IPv6.

We are trying too much to put things in unique and well defined boxex. Universe does'n work like this. Security is just a state of mind.

... but

An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.

For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.

In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.

would be better if it was "Lacking a NAT doesn't make IPv6 insecure".

To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>". What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.

- share a precious IP address at the NAT gateway border

- hide your internal LAN from external network mapper

Last point becomes moot when internal mapping software kicks in, legitimately or not, JavaScript or disingenuous application/daemon/app.

Welcome to Cybersecurity SecOP.

Now this is where Carrier-Grade NAT really shines: added functionality of handling mobile devices' changing IP addresses as it hops from one subnet to another (switching between G5/CSM/WiFi/personal-hotspot)

- NAT is not a security feature because it wasn't designed as one (this post), and/or

- NAT is not a security feature because it does not, without a firewall, protect against an attacker on the WAN subnet, or another difficult-to-exploit scenario.

And yet making LAN devices unroutable from the Internet does on its own makes exploitation much more difficult. It's admittedly not a perfect measure, but it's one that IPv6 deployments with routable addresses for LAN devices lack. I would wager this does make a difference in the proliferation of botnets, especially given the lackluster standards of consumer network equipment security.

He stated:

> NAT is not a firewall: all it does is rewrite packets, it does not drop them.

I noted (without quoting at the time) that the article actually mentions this aspect of NAT, here is a quote from yesterday's article:

> Time and time again we are lectured that NATs are not a good security device, but in practice NATs offer a reasonable front-line defence against network side malware scanning and injection, so there may be a larger story behind the use of NATs and device-based networks than just a simple conservative preference to continue to use an IPv4 protocol stack.

Since I didn't state it before, I don't see any need to add NAT to IPv6 and certainly not for security reasons when a firewall is the correct way to secure networks. I don't feel that IPv6 is inherently more or less secure than IPv4, regardless of NAT. I also agree that even for IPv4, firewalls should be used and that NAT should not be relied on as a security measure for any remotely high stakes situation.

The reason I made my comment though is because I seem to share the same opinion as yesterday's article's author that people stating "NATs are not a good security device" are missing the point that in regard to IPv4, NAT may not be a "fully proper" security measure, but in practice it is "plenty good enough" for the vast majority of internet users.

People proclaiming how NAT is not a security measure seem to me to be ignoring our reality where 100s of millions of consumer routers, incidentally but nevertheless effectively, use it as one. Even without a firewall to drop packets on these devices doing NAT, they effectively block a whole class of automated malicious activity.

Is it safe to have unprotected network devices shielded only by NAT without a firewall? No, not really.

Should you use a proper firewall even if you have NAT? Yes, absolutely, but a lot of people don't and are nevertheless adequately protected considering they probably have no "open" devices on their network and have no particular reason to be targeted by a truly determined malicious actor.

[1] https://news.ycombinator.com/item?id=46691835

I profit from NAT-less network, can connect to my home device from a VPS without thinking it's sitting behind 2 routers. No port forwarding needed, just connect and it works. Well, I guess I still need to enable connection to this device on a firewall, but that's obvious.

We really should move on from IPv4.

By the way, IPv6 also supports NAT if that's what you want. But using NAT in IPv6 is like saying "i want to have my own personal universe so I can put 2 Raspberry PIs in it".

Big centralized online services does not want IPv6 because it "unlocks" internet as intended, full p2p at scale. They won't let that happen easily.

And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.

The truth of the matter is that NAT absolutely _is_ a firewall in _practice_. Not in theory "because it doesn't drop packets" or "because it was not meant to be a security feature". But in the actual real-world practice.

It effectively protects most networks from most attackers without ANY additional configuration, making it inherently foolproof.

Here, I put a private key for a wallet with 0.01 bitcoin at this address: http://192.168.80.26/ Go on and take it. It's not protected by anything else I disabled everything but NAT. Heck, here's my real IPv4 even: 172.56.107.111

Is this a _good_ reason to not do IPv6? No. But it absolutely _is_ a reason and needs to be acknowledged.

Good luck setting up proper firewallimg rules for IPv6 while both respecting its specs and preventing hard-to-detect exfil through ICMPv6.

It's a rube-goldberg of a protocol and it s hard to believe it s all incompetence and there ain't t some malice involved.

NAT for IPv4 was an accidental godsend, especially useful in an era where you d hack your neighbors' computers when they where on the same subnet as yours. Don t tell me it didn't t happen for I was doing that on dial-up back in the days.

Thankfully the point is mostly moot because people are still free to use IPv4 at home/companies while having their router using IPv6.

IPv4 shall thankfully outlive me. And I don't t care if it means more work for people working in the "punch the monkey" ads industry.

For NAT, of course it isn't meant for security, but it has a side-effect of creating a network boundary, and that has positive security implications.

If your router doesn't have a firewall blocking any connections, NAT still has security implications as it is deployed typically on consumer networks, which is a one-way port-address-translation for outbound traffic.

The important bit here is not NAT or firewalls, but layer 3 network segments!!!

An RFC1918 private addrerss space is not internet routable. Furthermore, routers shouldn't "default route" traffic from arbitrary connected networks by default. But "should" aside, the typical default consumer router behavior is that they don't NAT translate inbound traffic, they can't!

If a random internet IP wanted to connect to port 80 on a device at 192.168.1.200 in your home network, it doesn't know how to tell your router what IP to translate it's request to the router's public IP to. That is the essential positive security implication. In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.

With IPv6, end devices in your network get a globally routed address, someone can try to connect to that same internal device as my earlier example and succeed with the same exact default behavior in place.

IPv6 is thus, by relative metrics, insecure by default. It does not mean it cannot be secured, but it is less secure than IPv4 in typical deployments where extra care isn't taken to secure it properly. If your answer to this is "well that's just because people who deploy networks are dumb" then save your self the effort or arguing that, it is irrelevant. That is how networks are deployed in the real world, period. People make mistakes in the real world. People don't know best practices in the real world. So out of the box, things need to consider real world hazards, and IPv6 does not do that.

You can support the adaption of IPv6 nonetheless and I would have no disagreement there.