For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
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.
You are wrong because you are being overly pedantic.
NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
Your definition of security is too narrow.
And saying that NAT is broken all the time, implying that NAT is not security, is ridiculous. SSH is 'broken' all the time. TLS is broken all the time.
Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
This goes against Hyrum's law. NAT provides the behavior 99.9% of users want, usually by default, out of the box. True firewalls can do the same thing, but not necessarily by default, the firewall might not even by on by default, and there's more room for misconfiguration. IPv6 is a security regression for most people, regardless of its architectural merits or semantics of what's a firewall.
I wouldn’t put the number so high. I’ve on several occasions seen not very technical people unnecessarily burn money on VPSes or dedicated hosting providers because they couldn’t expose a game server for a evening session with their friends with the spare capacity on their gaming machine, because of their ISPs NAT setup. 90% would be fairer. However we still shouldn’t be sacrificing securing agency of individual consumers for securing smoother revenue for corporations.
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
NAT implementations get broken all the time (NAT slipstreaming attacks). If a manufacturer is incompetent enough not to have a firewall on by default, they are probably also shipping a vulnerable NAT.
When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.
There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.
Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.
Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.
But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
It's scary how much of this thread comes from people who can't imagine a use for keeping internal traffic internal. in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms. in ipv6, if my laptop tries to use a printer with an ipv6 address...
its not about the firewall. there's just a lot of extra attack vectors without a nat.
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
> NAT is not for security, it does not provide security.
It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.
I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devices unsolicited, just like a stateful v4 firewall would provide.
I suspect the author was trying to put into words why their technically correct world view is better, but he spends his opening arguing semantics (ineffectually, as apparent) instead of meeting the 'wrong' people where they are and explaining why his semantics are an improvement.
Competency crisis is not limited to just the audience.
If the end effect of security is dropping packets NAT and Firewalls both in effect drop packets.
Its kind of just silly pedantry to say NATs aren't security because sure you can't do things like block specific ranges of IPs spamming you (or make outbound rules to control local devices) but 99% of people don't need.
I understand ipv4 networks pretty well. And I would say that any device doing NAT is acting as a basic firewall. Do “true” firewalls do more? Sure. But saying NAT doesn’t provide security is flat out wrong.
I think the confusion stems from the fact that my mom's laptop with its 192.168.0.43/24 v4 address is not routable except via NAT, and people believe (rightly or wrongly) that that confers a degree of security.
UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s. NAT translates addresses. Thinking a non-routable range is safe because it's behind NAT is at this point grossly ignorant of how modern network equipment works. It's kind of like port-knocking; yes it makes the attack slightly harder, but doesn't prevent it.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
It doesn't confer much since it COULD be only NAT and no firewall.
It's INCREDIBLY unlikely to find a case of that in the wild, but possible.
A common example of a host that might have such an address but lacks that sort of security is anything as the default route for inbound packets, E.G. like you'd want your _own_ router / firewall rather than the ISP's modem.
NAT causes security issues too. Reflection attacks are much harder to stop if the endpoint and its network address are decoupled.
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.
> Unfortunately, NAT reduces the number of options for providing security [1]
Somehow, everyone forgot that, and it morphed into a cargo-culting security practice, even going so far as to propagate 1990s network limitations into the cloud(!)
Fun fact I have actually had an sbc get hacked because I didn’t change the default password. I thought it would be reasonably safe for a few days because I knew the VLAN it was on had NAT and the associated firewall rules that deny inbound packets without outbound. But it turned out ipv6 was also enabled on that VLAN with no firewall. Left a bad taste in my mouth over a decade later even if it was a misconfigured firewall rather than an inherent issue with ipv6.
…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.
I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.
In my defense I was in college at the time, and I did actually run some tests to ensure my understanding of the firewall was correct. I just didn’t even think to account for ipv6 or especially for that range having different firewall rules.
I'd argue not about security, but transparency - when having your mac address partially included in the IPv6, you would basically allow browsers and other systems identify you without additional steps.
Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface ID
Sure, but your MAC address is easily spoofed. In fact, all major operating systems do it nowadays for public WiFi systems and you have to explicitly opt-out of randomising your MAC Address when connecting.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
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:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.
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
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.
For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
Hard to attack: FDC2:1045:3216:0001:0013:50FF:FE12:3456
Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
Yup, by default a Linux based router won’t forward any traffic to a IPv6 host unless you explicitly have a program running which keeps on telling the kernel you want that.
This is going to depend on the router and on IP distribution.
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.
> 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.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
That's an entirely different attack scenario. To succeed at that attack, my computer would already need to be running malware. At that point, they've already won.
Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4. Really the only difference is you can have multiple devices on your network allowed to receive on the same port if you want.
> Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4.
A few years back my ISP didn't properly support prefix delegation, and the only way to get IPv6 to work was in "Passthrough" mode. My router (Asus ax86u) was really unclear about what passthrough mode meant, but I think that it might also disable the IPv6 firewall (I have read conflicting reports, and was never able to find an authoritative answer). The setting is buried pretty deep in the router and off by default, so I don't think most people would enable it by accident, but a quick google search does show lots of people on forums enabling Passthrough mode to get IPv6 working. So seems pretty dangerous and there is no warning or anything [1] that you are potentially exposing every device on your network to the internet (if that is indeed what it does).
Fortunately, my ISP has since implemented proper support for prefix delegation.
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
With NAT your device does not have a publicly routable address. Attackers have no way of contacting you at all. Without NAT you have a publicly routable address and attackers can try reaching out to your device. You rely entirely on your device's and your router's firewall.
So it's not really about NAT although it ends up being a consequence—it's about having a truly private network "air gapped" from the public internet.
What ISP gives you a single IPv6 address? That's incredibly comical. An ISP would have at least 79 billion billion billion addresses and they are giving you one?!
If I run a webserver on my network I know it's unreachable from the internet unless I specifically allow inbound traffic to it at my firewall. I get to use the actual security features with sensible terminology instead of silly things like "port forward".
> my ISP still gives me only a single IPv6 address
This is criminal, and also incredibly uncommon. You should talk to your ISP, it's most definitely a misconfiguration of some kind, if not deliberate torture. Normally you get a /56 at least because there are so many and they cost nothing.
Datapoint of 1: With Cox as my ISP, I can get a /64 just by configuring my DHCPv6 client to request it, but if I wanted a /56 or /48 I would have to contact someone at my ISP.
NAT is just one slice of IPv4. Granted your private IP is not routable (with CGNAT now your gateway is also no longer routable), but think of other features of IPv6 that are congruent:
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.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
NAT isn't security at all, good or otherwise. If it was sold as such, then the people selling it were giving out inaccurate info. But just because some people wrongly said that NAT provides security back in the beginning doesn't somehow make those claims true today.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
I find the discussion about whether or not NAT is a security feature or not interesting. To my mind NAT was intended to make ipv4 last longer in a clever way as address space dried up. A happy accident of this solution is a basic security feature.
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.
Why would you do that when a regular default-deny firewall is and has always been the security feature you need, without the complications and problems of NAT?
Like I said I'm not expert, and was likely talking shit. I was just speculating based on the discussion in this thread.
I think the complications and problems of NAT seem to add a default layer of security to the whole thing. I know next to nothing about firewalls though, which might be the point here, but would a default deny present any problems for me that NAT would allow? That is is there a situation where as a layman I might run into problems receiving data for a valid process that wouldn't happen if it was just NAT?
Invoking NAT "security" as a reason against IPv6 is a surefire indicator the person invoking it has absolutely no idea what they're talking about and should not be allowed within typing distance of any network infrastructure
As a reason not to IPv6? I guess. As a thing, not scare-quoted, but really security? No. Be careful with things like "absolutely no idea what they're talking about".
Please. _I_ invoked that argument, and I bet I know more about IPv6 than you do.
All my services and networks have IPv6. And my first operational issues with IPv6 were in 2008, when my Asterisk SIP server started failing after ~12 hours.
Culprit? Privacy addresses kept accumulating until they overflowed the SIP UDP packet size because it listed all the combinations of supported codecs/endpoints.
No one's complaining that IPV6 is insecure. It may as well be very secure, but no one bothers to understand it if they're not paid to do that.
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.
I've seen plenty of discussions here on HN where people have made that claim. Even more elsewhere on the discussion side of other news websites by sysadmins that disable IPv6 because one of their industrial routers didn't come with a default deny rule that one time which made them think that's normal.
The people who are supposed to know IPv6 never seemed to have learned it and many of them don't seem to be open to the idea of learning something new. Of course half the world runs on IPv6 now so they'll have to get with the times eventually, but the prevalence of statements like these is quite depressing.
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
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.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
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.
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
From my understanding, the "IPv4 NAT" equivalent for IPv6 is generally referred to as NAT66 (NPTv6 for Prefix-Translation). For example, Fortinet offers this on their firewalls, and I believe most firewall vendors have this option.
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
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.
No, the reality is that every modern network device running NAT for a user device network is also already a fully stateful firewall, because the software required to do one is virtually identical to the other.
You can't buy a home router with NAT and no firewall, and no home routers ship that don't also have a default deny rule on that firewall. The same is true for SOHO routers and effectively every consumer network gateway device you might buy.
You literally have to go well out of your way to find a network device capable of NAT that can't function as a stateful firewall, and when you find it, it's likely to be carrier-grade. In other words, not intended to be capable of any security at all. The amount of NAT processing it's intended to handle will challenge the hardware enough as it is.
NAT isn't protecting them. Not being on the public internet at all is protecting them.
NAT is then unprotecting them a little by letting them punch out again. It's super easy for routers to implement this behaviour by default if your LAN is publicly addressable, and removes a whole class of exploits caused by applications making NAT hacks.
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
Yes, it is the case. In the real world, there are malfunctioning ALGs, permissive defaults, and connectionless protocols that are poorly tracked by these sloppy, underpowered "SPI" devices.
"Collectively, our results show that NAT has indeed acted as the de facto firewall of the Internet, and the v4-to-v6 transition of residential networks is opening up new devices to attack."
I think two things can be true here: the article's assertion that "IPv6 is not insecure because it lacks NAT" is correct, and other peoples' assertions that NAT provides an extra layer of security are also correct.
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 also creates real world problems that NAT solves -- multi upstream WAN with path selection for example
Dual stack introduces security problems (you now have two things to secure). There are still devices which will fail to run on an ipv6 network -- even with a 64 gateway (software which communicates to a specific IP address for example - e.g. a device which "checks internet connectivity" by pinging 1.1.1.1 and 8.8.8.8, yes it's terrible, and yes it happens)
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 IPv6.
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".
NAT is not inherently a security feature, however where NAT happens is somewhat important.
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.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
So with IPv4 with NAT you definitely have this security. According to this article with IPv6 you MIGHT have that security -we don't know. That's not secure.
I disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.
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.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>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.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
IPv6 without NAT is not insecure; I can and do have a stateful firewall that denies unwanted inbound connections. But it does not matter if my auditors think otherwise and the whole Internet tells me that arguing with them will end my career.
nitpick on the title, the way it's worded makes it sound like "IPv6 is not insecure because it lacks a NAT, (but it's insecure because of other reasons)".
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it lacks NAT”.
Defence in depth is a valid security approach, and NAT provides another defence in depth
If you have a vulnerable ipv4 machine on 192.168.0.24 port 2345 which is hidden behind a public IP of 1.2.3.4, and you set your firewall rule to allow any inbound traffic, with no nat rules then it will be exceedingly difficult for a remote attacker to reach that vulnerable port (they have to trick your router's connection table into routing it)
If the same machine is on 2100:1234:5678:a::24 then that port is exposed.
Now sure your firewall could block the traffic, and that's great. But having multiple layers of active configuration to allow the traffic through is more secure than having a single layer as it means you need to screw up twice.
Worse than that with dual stack you may think you have set your firewall to block non-established connections at the ipv4 stage, but your device is sat there on an open ipv6 address you didn't even consider. Dual stack is certainly less secure than single stack as there are two opportunities to screw up.
With IPv6 you might have to use a hack to make firewall allow incoming packets (like sending a dummy UDP packet to the peer first). The firewall only read, allow or deny these packets. While NAT must mess with the message IP//TCP//UDP headers to work.
NAT is a trivial feature on top of a connection tracking firewall. It also provides a large number of benefits - the ability to route traffic via different routes with PBR, without having BGP upstream, to keep routing decisions in the router rather than on each device, to not have to renumber internal IP addessing when the ISP changes, to have consistent view of what happens at a network level
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.
Disabled protection does not protect. This is UI/UX thing, not something in Internet-scale protocols.
I can "curl https://somethingshady | bash -" but won't blame RFC1738.
I have yet to see a "NAT is not security" rebuttal that does not make either one or both of these points:
- 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.
You should read my other comments on this post. I've attempted, multiple times (but apparently without much success) to make the point that NAT is not a security feature because it does not, without a firewall, protect against an attacker.
You don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.
I think you're not technically wrong, but you're defining NAT differently than the majority of people you're arguing with (those who assume NAT also implies a firewall blocking inbound connections), and the remaining minority (the "on the WAN subnet" crowd) are dismissing outright the idea as a reasonable attack vector that an attacker close enough to be able to send packets destined for non-internet routable addresses to your router.
Is the latter something that was/is actively exploited?
I wrote that comment, and you can write to yourself how many times you want that NAT is not a firewall.
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.
If you don't have RPF enabled on your router in theory your upstream peer can send traffic to 192.168.80.26 and it would pass through. Reply traffic may or may not be natted depending on how it's entered in the connection tracking table.
There may be situations where your router can be tricked too, I can't think of one off the top of my head which wouldn't also apply to a stateful firewall sitting on a routed network segment with no nat, and it would typically be a vulnerability to patch
But your principal is right -- it's far harder to exploit than just connecting to an ip of say 2001:172:56:107:111::192.168.80.25 on port 80
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet".
It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
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.
I actually wanted to write this article myself but every time I started writing it up I thought "fuck, this is too obvious, I'm being condescending". But then I read these comments and I'm sad again.
Makes sense. But I’d argue NAT is still more secure because it physically breaks the connection between your internal host and the outside world. Without an existing routing table there’s no destination to route the packet to.
I basically disable all ipv6 on my routers & firewalls completely. Waiting for the day we can disable ipv4 completely instead and use only ipv6 without NAT. But then each device will need its own firewall. NAT basically forces you to use some kind of firewall, which applies to all devices behind the NAT. But if we go all-in on IPv6, the firewall-by-default becomes much harder to implement in practice. Then we will need some kind of distributed/federated firewall config to constantly keep devices usable but safe, but then that will introduce a new set attack vectors. So we are kinda screwed for now. We need that new internet, maybe one where you unify static ipv6, dhcp6, dns, firewalls, nat and a few other friends into a single thing. Or perhaps we can use ipv6 only to get a static ip address for each home/building, which then has a small vlan/vpn to group all your devices together using ipv4 internally for ease of use.. which is close to what we currently have with cgnat+ipv4+wireguard+vlans. All round we have a big mess but it works well, if you know what you are doing that is. This is all to say we can even keep net-neutrality for a while longer, we are okay for now but the american/uk/china/india govs plus entities like cloudflare will actually destroy net-neutrality in the long run. Much like email delivery has already been ruined & captured. Sorry for the rant.
You seem to have misunderstood how IPv6 works. In a home setup, all the traffic still goes through a single router which typically has a restrictive firewall enabled by default.
Only if enabled for a specific interface/network/zone/grouping... easy to misconfigure. You can easily misconfigure it to work fine for ipv4 but forgot about ipv6. Depending on what router software you use, this will either be easy or hard to spot. Sometimes the router software won't tell you explicitly that a certain interface is not included or that you have a gaping hole in your network somewhere.
If you use a consumer-grade device at home that you don't have full access to (meaning root via ssh and can update packages, cute web ui's alone don't count), you are screwed in other ways either way (hello open CVE's on unpatched routers....). I literally have a brand new Asus router sitting in a box at home, cause it has 3 open CVE's and asus basically dropped support for it, but they still sell them. Oh and I have root ssh access on it - it is running ubuntu 12 underneath it all (disgusting that asus haven't bumped it). Just all garbage. So I built my own x86 dual-nic/Wifi 6E router box that runs openwrt + adguard home + unbound + wireguard (all on proxmox) and all 4 systems update nightly. This setup absolutely crushes the performance versus top spec consumer-grade routers and I get to monitor it properly and update packages daily.
For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
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.
It's scary how much of this thread of supposed hackers comes from people who clearly don't understand the difference between a NAT and a firewall.
NAT is not for security, it does not provide security. It is often bundled with a firewall. The firewall provides security. Firewall=\=NAT
You are wrong because you are being overly pedantic.
NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
Your definition of security is too narrow.
And saying that NAT is broken all the time, implying that NAT is not security, is ridiculous. SSH is 'broken' all the time. TLS is broken all the time.
Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
This goes against Hyrum's law. NAT provides the behavior 99.9% of users want, usually by default, out of the box. True firewalls can do the same thing, but not necessarily by default, the firewall might not even by on by default, and there's more room for misconfiguration. IPv6 is a security regression for most people, regardless of its architectural merits or semantics of what's a firewall.
I wouldn’t put the number so high. I’ve on several occasions seen not very technical people unnecessarily burn money on VPSes or dedicated hosting providers because they couldn’t expose a game server for a evening session with their friends with the spare capacity on their gaming machine, because of their ISPs NAT setup. 90% would be fairer. However we still shouldn’t be sacrificing securing agency of individual consumers for securing smoother revenue for corporations.
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
2 replies →
It’s still conflating things. You can have a stateless NAT: device x.x.x.y will get outbound source ports rewritten to (orignal port) << 8 + y.
This is a (dumb) NAT but has no state so it cannot possibly implement a default deny or any firewall adjacent features.
NAT implementations get broken all the time (NAT slipstreaming attacks). If a manufacturer is incompetent enough not to have a firewall on by default, they are probably also shipping a vulnerable NAT.
1 reply →
When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.
There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.
Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.
Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.
But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
It's scary how much of this thread comes from people who can't imagine a use for keeping internal traffic internal. in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms. in ipv6, if my laptop tries to use a printer with an ipv6 address...
its not about the firewall. there's just a lot of extra attack vectors without a nat.
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
Just like a load balancer is a kind of NAT, but I don’t think people would conflate this with a security measure / FW.
It's scary how somebody posting on hackernews thinks that this site is about hackers in the sense of security.
It quacks like a duck though.
RFC 4787 is useful in distinguishing NAT mapping vs filtering. Surprisingly symmetric NAT actually seems quite rare today.
> NAT is not for security, it does not provide security.
It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.
I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devices unsolicited, just like a stateful v4 firewall would provide.
If you really don't have a stateful v4 firewall, your ISP can happily connect to all of your devices.
The competency crisis is very real.
I suspect the author was trying to put into words why their technically correct world view is better, but he spends his opening arguing semantics (ineffectually, as apparent) instead of meeting the 'wrong' people where they are and explaining why his semantics are an improvement.
Competency crisis is not limited to just the audience.
If the end effect of security is dropping packets NAT and Firewalls both in effect drop packets.
Its kind of just silly pedantry to say NATs aren't security because sure you can't do things like block specific ranges of IPs spamming you (or make outbound rules to control local devices) but 99% of people don't need.
I understand ipv4 networks pretty well. And I would say that any device doing NAT is acting as a basic firewall. Do “true” firewalls do more? Sure. But saying NAT doesn’t provide security is flat out wrong.
4 replies →
I think the confusion stems from the fact that my mom's laptop with its 192.168.0.43/24 v4 address is not routable except via NAT, and people believe (rightly or wrongly) that that confers a degree of security.
UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s. NAT translates addresses. Thinking a non-routable range is safe because it's behind NAT is at this point grossly ignorant of how modern network equipment works. It's kind of like port-knocking; yes it makes the attack slightly harder, but doesn't prevent it.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
1 reply →
It doesn't confer much since it COULD be only NAT and no firewall.
It's INCREDIBLY unlikely to find a case of that in the wild, but possible.
A common example of a host that might have such an address but lacks that sort of security is anything as the default route for inbound packets, E.G. like you'd want your _own_ router / firewall rather than the ISP's modem.
rightly
NAT causes security issues too. Reflection attacks are much harder to stop if the endpoint and its network address are decoupled.
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.
The RFC introducing NAT -- RFC 1631 -- says:
> Unfortunately, NAT reduces the number of options for providing security [1]
Somehow, everyone forgot that, and it morphed into a cargo-culting security practice, even going so far as to propagate 1990s network limitations into the cloud(!)
[1] https://www.rfc-editor.org/rfc/rfc1631.html
Fun fact I have actually had an sbc get hacked because I didn’t change the default password. I thought it would be reasonably safe for a few days because I knew the VLAN it was on had NAT and the associated firewall rules that deny inbound packets without outbound. But it turned out ipv6 was also enabled on that VLAN with no firewall. Left a bad taste in my mouth over a decade later even if it was a misconfigured firewall rather than an inherent issue with ipv6.
…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.
2 replies →
I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.
4 replies →
There was a report a few years back about people running NTP servers to harvest IPv6 addresses.
Security via obscurity will only get you so far.
3 replies →
That's pretty embarrassing lol
Nah, happened frequently at ipv6 early days. Some devices shipped with ipv6 enabled but no firewall out of the box.
In my defense I was in college at the time, and I did actually run some tests to ensure my understanding of the firewall was correct. I just didn’t even think to account for ipv6 or especially for that range having different firewall rules.
4 replies →
I'd argue not about security, but transparency - when having your mac address partially included in the IPv6, you would basically allow browsers and other systems identify you without additional steps.
Sure, but your MAC address is easily spoofed. In fact, all major operating systems do it nowadays for public WiFi systems and you have to explicitly opt-out of randomising your MAC Address when connecting.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
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:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.
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:
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.
For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
No, that's the whole point.
Imagine I've shared output of "ifconfig" on my machine, or "netstat" output, or logs for some network service which listed local addresses.
For IPv4, this will is totally fine and leaks minimal information. For IPv6, it'll be a global, routable address.
3 replies →
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
2 replies →
It took me less than 1 second to access that 192.168.0.1 address! It wasn't that hard to find.
(;-)
Deeply ironic that Cisco would teach this, because it's the opposite of what they said when they introduced NAT.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
2 replies →
If the IP address was leaked, wouldn't it be the address of the unit doing the NAT translation instead of the standard-gateway?
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
> You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
TIL that IPv6 is a cryptosystem
Yup, by default a Linux based router won’t forward any traffic to a IPv6 host unless you explicitly have a program running which keeps on telling the kernel you want that.
This is going to depend on the router and on IP distribution.
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.
> 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.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
[0]: https://openconnectivity.org/developer/specifications/upnp-r...
That's an entirely different attack scenario. To succeed at that attack, my computer would already need to be running malware. At that point, they've already won.
3 replies →
Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4. Really the only difference is you can have multiple devices on your network allowed to receive on the same port if you want.
> Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4.
A few years back my ISP didn't properly support prefix delegation, and the only way to get IPv6 to work was in "Passthrough" mode. My router (Asus ax86u) was really unclear about what passthrough mode meant, but I think that it might also disable the IPv6 firewall (I have read conflicting reports, and was never able to find an authoritative answer). The setting is buried pretty deep in the router and off by default, so I don't think most people would enable it by accident, but a quick google search does show lots of people on forums enabling Passthrough mode to get IPv6 working. So seems pretty dangerous and there is no warning or anything [1] that you are potentially exposing every device on your network to the internet (if that is indeed what it does).
Fortunately, my ISP has since implemented proper support for prefix delegation.
[1] https://www.asus.com/support/faq/113990/
1 reply →
The Apple AirPort Extreme didn't by default until recently: https://support.apple.com/en-nz/103996
1 reply →
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
With NAT your device does not have a publicly routable address. Attackers have no way of contacting you at all. Without NAT you have a publicly routable address and attackers can try reaching out to your device. You rely entirely on your device's and your router's firewall.
So it's not really about NAT although it ends up being a consequence—it's about having a truly private network "air gapped" from the public internet.
2 replies →
> My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
Interesting how that works in your case. Is your router gives your devices IPv6 from fc00::/7 and then NAT them? It would be a rather rare case.
What ISP gives you a single IPv6 address? That's incredibly comical. An ISP would have at least 79 billion billion billion addresses and they are giving you one?!
If I run a webserver on my network I know it's unreachable from the internet unless I specifically allow inbound traffic to it at my firewall. I get to use the actual security features with sensible terminology instead of silly things like "port forward".
> my ISP still gives me only a single IPv6 address
This is criminal, and also incredibly uncommon. You should talk to your ISP, it's most definitely a misconfiguration of some kind, if not deliberate torture. Normally you get a /56 at least because there are so many and they cost nothing.
Datapoint of 1: With Cox as my ISP, I can get a /64 just by configuring my DHCPv6 client to request it, but if I wanted a /56 or /48 I would have to contact someone at my ISP.
NAT is just one slice of IPv4. Granted your private IP is not routable (with CGNAT now your gateway is also no longer routable), but think of other features of IPv6 that are congruent:
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.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
17 replies →
The principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
NAT isn't security at all, good or otherwise. If it was sold as such, then the people selling it were giving out inaccurate info. But just because some people wrongly said that NAT provides security back in the beginning doesn't somehow make those claims true today.
NAT absolutely does provide good security. It denies all incoming traffic that is not part of an established connection.
Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.
So there is nothing about a lack of NAT in IPv6 that makes it less secure.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
5 replies →
[dead]
Of course it's not insecure because of NAT.
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.
I find the discussion about whether or not NAT is a security feature or not interesting. To my mind NAT was intended to make ipv4 last longer in a clever way as address space dried up. A happy accident of this solution is a basic security feature.
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.
Why would you do that when a regular default-deny firewall is and has always been the security feature you need, without the complications and problems of NAT?
Like I said I'm not expert, and was likely talking shit. I was just speculating based on the discussion in this thread.
I think the complications and problems of NAT seem to add a default layer of security to the whole thing. I know next to nothing about firewalls though, which might be the point here, but would a default deny present any problems for me that NAT would allow? That is is there a situation where as a layman I might run into problems receiving data for a valid process that wouldn't happen if it was just NAT?
Invoking NAT "security" as a reason against IPv6 is a surefire indicator the person invoking it has absolutely no idea what they're talking about and should not be allowed within typing distance of any network infrastructure
As a reason not to IPv6? I guess. As a thing, not scare-quoted, but really security? No. Be careful with things like "absolutely no idea what they're talking about".
I don't think that the inherent security of NATs is a _good_ reason to not do IPv6.
But it _is_ a reason, and it _is_ true.
Please. _I_ invoked that argument, and I bet I know more about IPv6 than you do.
All my services and networks have IPv6. And my first operational issues with IPv6 were in 2008, when my Asterisk SIP server started failing after ~12 hours.
Culprit? Privacy addresses kept accumulating until they overflowed the SIP UDP packet size because it listed all the combinations of supported codecs/endpoints.
Oh, btw, do try to answer this message: https://www.reddit.com/r/VOIP/comments/131ex1x/ipv6_sip_trun... - it's still relevant to this day.
Having read and considered your position I see no reason to update my opinion.
No one's complaining that IPV6 is insecure. It may as well be very secure, but no one bothers to understand it if they're not paid to do that.
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.
I've seen plenty of discussions here on HN where people have made that claim. Even more elsewhere on the discussion side of other news websites by sysadmins that disable IPv6 because one of their industrial routers didn't come with a default deny rule that one time which made them think that's normal.
The people who are supposed to know IPv6 never seemed to have learned it and many of them don't seem to be open to the idea of learning something new. Of course half the world runs on IPv6 now so they'll have to get with the times eventually, but the prevalence of statements like these is quite depressing.
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
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.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
NAT doesn't protect you from either of these.
2 replies →
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
1 reply →
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
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
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
You can do the many-to-few (or one) NAT behavior with port rewrites in IPv6 if you want to, there are just few circumstances it makes any sense.
FWIW the broad IPv6 network-prefix NAT behavior ALSO EXISTS in IPv4, it's just less applicable.
From my understanding, the "IPv4 NAT" equivalent for IPv6 is generally referred to as NAT66 (NPTv6 for Prefix-Translation). For example, Fortinet offers this on their firewalls, and I believe most firewall vendors have this option.
1 reply →
Why would you not use ULA if you have a network with multiple machines?
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
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.
No, the reality is that every modern network device running NAT for a user device network is also already a fully stateful firewall, because the software required to do one is virtually identical to the other.
You can't buy a home router with NAT and no firewall, and no home routers ship that don't also have a default deny rule on that firewall. The same is true for SOHO routers and effectively every consumer network gateway device you might buy.
You literally have to go well out of your way to find a network device capable of NAT that can't function as a stateful firewall, and when you find it, it's likely to be carrier-grade. In other words, not intended to be capable of any security at all. The amount of NAT processing it's intended to handle will challenge the hardware enough as it is.
Nope, I agree with the findings here:
https://arxiv.org/abs/2509.04792?
NAT isn't protecting them. Not being on the public internet at all is protecting them.
NAT is then unprotecting them a little by letting them punch out again. It's super easy for routers to implement this behaviour by default if your LAN is publicly addressable, and removes a whole class of exploits caused by applications making NAT hacks.
This is splitting hairs. The point stands that PAT is the de facto firewall for most soho users.
1 reply →
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
3 replies →
That's not the case at all. You could disable their NAT and they wouldn't lose any protection whatsoever.
Yes, it is the case. In the real world, there are malfunctioning ALGs, permissive defaults, and connectionless protocols that are poorly tracked by these sloppy, underpowered "SPI" devices.
3 replies →
France with >85% IPv6 adoption mostly made of grandmothers driving a motorcycles across the town manually delivering packets like in their youth.
https://arxiv.org/abs/2509.04792?
"Collectively, our results show that NAT has indeed acted as the de facto firewall of the Internet, and the v4-to-v6 transition of residential networks is opening up new devices to attack."
1 reply →
I think two things can be true here: the article's assertion that "IPv6 is not insecure because it lacks NAT" is correct, and other peoples' assertions that NAT provides an extra layer of security are also correct.
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 also creates real world problems that NAT solves -- multi upstream WAN with path selection for example
Dual stack introduces security problems (you now have two things to secure). There are still devices which will fail to run on an ipv6 network -- even with a 64 gateway (software which communicates to a specific IP address for example - e.g. a device which "checks internet connectivity" by pinging 1.1.1.1 and 8.8.8.8, yes it's terrible, and yes it happens)
I'm on ipv6 since 2 years and I am very happy.
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 IPv6.
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".
NAT is not inherently a security feature, however where NAT happens is somewhat important.
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.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
1 reply →
So with IPv4 with NAT you definitely have this security. According to this article with IPv6 you MIGHT have that security -we don't know. That's not secure.
I disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.
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.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>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.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
IPv6 without NAT is not insecure; I can and do have a stateful firewall that denies unwanted inbound connections. But it does not matter if my auditors think otherwise and the whole Internet tells me that arguing with them will end my career.
nitpick on the title, the way it's worded makes it sound like "IPv6 is not insecure because it lacks a NAT, (but it's insecure because of other reasons)".
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it lacks NAT”.
The lack of NAT has no bearing on security. Despite an old mistaken belief.
Defence in depth is a valid security approach, and NAT provides another defence in depth
If you have a vulnerable ipv4 machine on 192.168.0.24 port 2345 which is hidden behind a public IP of 1.2.3.4, and you set your firewall rule to allow any inbound traffic, with no nat rules then it will be exceedingly difficult for a remote attacker to reach that vulnerable port (they have to trick your router's connection table into routing it)
If the same machine is on 2100:1234:5678:a::24 then that port is exposed.
Now sure your firewall could block the traffic, and that's great. But having multiple layers of active configuration to allow the traffic through is more secure than having a single layer as it means you need to screw up twice.
Worse than that with dual stack you may think you have set your firewall to block non-established connections at the ipv4 stage, but your device is sat there on an open ipv6 address you didn't even consider. Dual stack is certainly less secure than single stack as there are two opportunities to screw up.
If IPv6 is behind firewall, apps can't use it for P2P connections, so the major point of IPv6 network becomes moot.
And IPv4 NAT is actually possible to penetrate sometimes. So for some networks, IPv4 provides better P2P connectivity, than IPv6.
Not really, look at a great post on Tailscale blog how such P2P connection can be established: https://tailscale.com/blog/how-nat-traversal-works
With IPv6 you might have to use a hack to make firewall allow incoming packets (like sending a dummy UDP packet to the peer first). The firewall only read, allow or deny these packets. While NAT must mess with the message IP//TCP//UDP headers to work.
Security is not a binary. NAT is (slightly?) more secure.
NAT is a trivial feature on top of a connection tracking firewall. It also provides a large number of benefits - the ability to route traffic via different routes with PBR, without having BGP upstream, to keep routing decisions in the router rather than on each device, to not have to renumber internal IP addessing when the ISP changes, to have consistent view of what happens at a network level
Agreed with the main message.
... 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.
Disabled protection does not protect. This is UI/UX thing, not something in Internet-scale protocols. I can "curl https://somethingshady | bash -" but won't blame RFC1738.
I have yet to see a "NAT is not security" rebuttal that does not make either one or both of these points:
- 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.
You should read my other comments on this post. I've attempted, multiple times (but apparently without much success) to make the point that NAT is not a security feature because it does not, without a firewall, protect against an attacker.
You don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.
I think you're not technically wrong, but you're defining NAT differently than the majority of people you're arguing with (those who assume NAT also implies a firewall blocking inbound connections), and the remaining minority (the "on the WAN subnet" crowd) are dismissing outright the idea as a reasonable attack vector that an attacker close enough to be able to send packets destined for non-internet routable addresses to your router.
Is the latter something that was/is actively exploited?
I wrote that comment, and you can write to yourself how many times you want that NAT is not a firewall.
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.
> The truth of the matter is that NAT absolutely _is_ a firewall in _practice_.
No it's not. NAT is not ever a firewall. By definition it is not.
If you don't have RPF enabled on your router in theory your upstream peer can send traffic to 192.168.80.26 and it would pass through. Reply traffic may or may not be natted depending on how it's entered in the connection tracking table.
There may be situations where your router can be tricked too, I can't think of one off the top of my head which wouldn't also apply to a stateful firewall sitting on a routed network segment with no nat, and it would typically be a vulnerability to patch
But your principal is right -- it's far harder to exploit than just connecting to an ip of say 2001:172:56:107:111::192.168.80.25 on port 80
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet". It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
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.
I actually wanted to write this article myself but every time I started writing it up I thought "fuck, this is too obvious, I'm being condescending". But then I read these comments and I'm sad again.
Makes sense. But I’d argue NAT is still more secure because it physically breaks the connection between your internal host and the outside world. Without an existing routing table there’s no destination to route the packet to.
I basically disable all ipv6 on my routers & firewalls completely. Waiting for the day we can disable ipv4 completely instead and use only ipv6 without NAT. But then each device will need its own firewall. NAT basically forces you to use some kind of firewall, which applies to all devices behind the NAT. But if we go all-in on IPv6, the firewall-by-default becomes much harder to implement in practice. Then we will need some kind of distributed/federated firewall config to constantly keep devices usable but safe, but then that will introduce a new set attack vectors. So we are kinda screwed for now. We need that new internet, maybe one where you unify static ipv6, dhcp6, dns, firewalls, nat and a few other friends into a single thing. Or perhaps we can use ipv6 only to get a static ip address for each home/building, which then has a small vlan/vpn to group all your devices together using ipv4 internally for ease of use.. which is close to what we currently have with cgnat+ipv4+wireguard+vlans. All round we have a big mess but it works well, if you know what you are doing that is. This is all to say we can even keep net-neutrality for a while longer, we are okay for now but the american/uk/china/india govs plus entities like cloudflare will actually destroy net-neutrality in the long run. Much like email delivery has already been ruined & captured. Sorry for the rant.
The article says:
> Modern routers ship with firewall policies that deny inbound traffic by default, even when a NAT is not being used.
So no, not every device needs its own firewall. You can have a single firewall at the entrance of your network.
Though just like with IPv4 most of the time you shouldn't build on assumed-secure internal networks.
Not always the case and differs by router software.
1 reply →
You seem to have misunderstood how IPv6 works. In a home setup, all the traffic still goes through a single router which typically has a restrictive firewall enabled by default.
Only if enabled for a specific interface/network/zone/grouping... easy to misconfigure. You can easily misconfigure it to work fine for ipv4 but forgot about ipv6. Depending on what router software you use, this will either be easy or hard to spot. Sometimes the router software won't tell you explicitly that a certain interface is not included or that you have a gaping hole in your network somewhere.
If you use a consumer-grade device at home that you don't have full access to (meaning root via ssh and can update packages, cute web ui's alone don't count), you are screwed in other ways either way (hello open CVE's on unpatched routers....). I literally have a brand new Asus router sitting in a box at home, cause it has 3 open CVE's and asus basically dropped support for it, but they still sell them. Oh and I have root ssh access on it - it is running ubuntu 12 underneath it all (disgusting that asus haven't bumped it). Just all garbage. So I built my own x86 dual-nic/Wifi 6E router box that runs openwrt + adguard home + unbound + wireguard (all on proxmox) and all 4 systems update nightly. This setup absolutely crushes the performance versus top spec consumer-grade routers and I get to monitor it properly and update packages daily.
1 reply →