Before you engage in discussions, may I suggest to look into RFC 4787, especially section 5 about filtering behaviors of NAT: <a href="https://datatracker.ietf.org/doc/html/rfc4787#section-5" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc4787#section-5</a><p>Several things can be correct at the same time:<p>* NAT is not a firewall<p>* NAT can still filter traffic (and practically always does)<p>* NAT can hence still provide security features<p>* The real world often does not care about original definitions of a term. NAT was originally meant to just do address translation, but it has evolved.<p>* Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.
RFC 4787 does not really describe how real world implementations behave. As almost all SOHO routers are Linux-based, i prefer to discuss Linux netfilter-based NAT behavior than some hypothetical RFC 4787 NAT. There are clear differences. For example, RFC 4787 says:<p>> REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior<p>While Linux netfilter behavior is "Address and Port-Dependent Mapping".<p>As Linux netfilter implements both NAT and firewall behavior, it is relevant for the discussion which parts of overall netfilter behavior falls into 'NAT part' and which into 'firewall part'. There is clear distinction - DNAT/SNAT rules in nat table represent NAT behavior, while REJECT/DROP rules in filter table represent firewall behavior.<p>As Linux-based SOHO routers are usually configured with both NAT and firewall netfilter rules to implement both NAT and firewall behavior, one cannot answer question 'Does NAT filter traffic?' based on external behavior of such SOHO routers, but has to analyze which part of the network stack is responsible for such behavior, or how the same network stack configured with just NAT rules and no firewall rules would behave. And here the answer is no, it would pass traffic (that do not match existing connections) unmodified.
The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior. When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advantage of ipv6 with firewall: filtering is explicit rather than implicit). However, if someone tells me "Well actually, NAT does not do filtering, the firewall does", then I would assume this is also someone who argues with staff in a supermarket that the tomato belongs in the berries section.
John, your post opens saying it's addressing the point: “the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy.”<p>Your title is "IPv6 is not insecure because it lacks NAT"<p>I'm sure anyone who understands how NAT offers the equivalent of a default block rule also understands that the absence of NAT alone doesn't make IPv6 insecure. This makes the title feel a little clickbaity-strawmanny, sorry.<p>Your response seems to be: "most firewalls have a default block rule too meaning they're no worse than IPv4 w/ NAT."<p>There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)<p>That doesn't make IPv6 insecure because no NAT. But it does mean - IMO - that the intrinsic block that comes with IPv4 NAT is a better security measure for making devices inaccessible than relying on default firewall rules.<p>What point are you trying to make here, and is it actually more useful than the point you say you're addressing?
> There's more security to be had in an intrinsic architectural feature<p>No, there is not. Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense, this claim doesn't make sense. If the invariant is that incoming connections are blocked by default, an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant. If the claim is that a misconfiguration of the gateway can make the system vulnerable, again, the two kinds of firewall configuration are equivalent: you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.<p>There's no basis for claiming the two schemes differ in the level of security provided.
You talked right past the key point which is valid:<p>> There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)<p>One security property is architectural, one isn’t. They’re not the same.
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.<p>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.
> These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.<p>FWIW, I was interested so I tested this on my phone here in Finland (Elisa, the largest carrier here): IPv6 inbound TCP connections work just fine, unlike IPv4 which is behind CGNAT.<p>On mobile broadband (no calls) plans they also offer optional free public IPv4 address, but not on the regular phone plans.<p>(I did the test by installing Termux from Play Store, then in it running "pkg install netcat-openbsd" and "nc -6 -l 9956" and then connecting to that port from internet using telnet, while phone was not connected to WiFi.)
What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)
High concentration of technically inept users with hardware that no longer receives security updates and has plenty of well known easily exploitable vulnerabilities. Which naturally is used to run banking apps and travels with users close to 24/7 while tracking their location.<p>From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use. The internet APs the carriers sell get deprioritized relative to phones when necessary and the fine print generally forbids hosting any services (in noticeably stronger language than the wired ISPs I've had).
> From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use<p>Isn't that already the case with limited plans?<p>For example, mine has 40 GBs and I'm pretty sure it counts both upload and download, because I generally consume very little, except for one week when I was on holiday with no other internet access and wanted to upload my pictures to my home server and didn't otherwise use the phone more than usual.
The phone providers oversell bandwidth. They also limit the use of already purchased bandwidth when it gets legitimately used.<p>Similar to many industries, their business model is selling monthly usage, while simultaneously restricting the actual usage. They are not in the business of being an ISP for people running software on their phones.
The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.
However for that having the phone's IP not reachable has at best marginal benefits. The DDoS itself is an outgoing connection, and for command and control having the compromised phone periodically fetch instructions from a server is simpler to implement than the phone offering a port where it is reachable to receive instructions
Facebook would start listening on port X and and then their embedded SDK in other websites or app would query that IP and port, get their unique id, and track users much better.<p>Sounds farfetched? <a href="https://www.theregister.com/2025/06/03/meta_pauses_android_tracking_tech/" rel="nofollow">https://www.theregister.com/2025/06/03/meta_pauses_android_t...</a>
Mobile phones are also heavily sandboxed.
> <i>NAT isn’t actually a security feature—it’s an address conservation mechanism that became necessary because we ran out of IPv4 addresses.</i><p>> <i>But the security benefits people attribute to NAT actually come from the stateful firewall that’s typically bundled with NAT routers.</i><p>1. It <i>requires</i> a stateful firewall.<p>2. It isn't possible to accidentally a default-allow rule on that firewall.<p>It may not be <i>intended</i> as a security feature, but it can't not act as one in practice.
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.<p>NAT is not for security, it does not provide security. It is often bundled with a firewall. The firewall provides security. Firewall=\=NAT
It's sad how much of this thread of supposed hackers comes from people who are simply parroting this dogma because it has been drilled into them. People were even preaching this before IPv6 privacy extensions came into use, either downplaying the privacy issues or outright telling people they were bad for wanting privacy because IPv6 is more important.<p>I understand the difference between NAT and firewall perfectly well. I have deployed and configured both for many years. The strawman of "NAT without firewall" is pretty much irrelevant, because that's not what people run IRL.<p>Firewalls are policy-based security, NAT is namespacing. In other fields, we consider namespacing an important security mechanism. If an attacker can't even <i>name</i> a resource they're not allowed to access, that's quite a strong security property.
And of course, anyone can spoof IP and try to send traffic to 192.168.0.6 or whatever. But if you're anywhere in the world other than right inside my ISP's access network, you can't actually get the internet to route this to my local 192.68.0.6. On the other hand, an IPv6 firewall is one misconfigured rule away from giving anybody on the planet access.
Except in the real world everyone is also running UPnP, so NAT is also one misconfiguration away from exposing something publicly. In the real world your ISP might enable IPv6 one day and suddenly you <i>do</i> have a public address. Relying on NAT is a bad idea because it's less explicit, a firewall is saying you only want to allow these things through, of course nothing is perfect, you can mess up, but NAT is just less clear, the expectation is not "nothing behind NAT should ever be exposed", it's "we don't have enough addresses and need to share".
UPnP is not tied to NAT, where do you have this from? UPnP is used to request direct connections, a firewall can implement UPnP just as well as a NAT.
> Except in the real world everyone<p>...and goes on to ignore enterprise businesses, which consume most of the v4 space and are among the biggest resisters of v6.
It's not "relying on NAT" to have it as a layer in the swiss cheese. Relying on any one thing is a bad strategy.
>Except in the real world everyone is also running UPnP<p>Definitely not. I've been disabling that for years.
No, not everyone is running UPnP. Maybe on most home networks, but that’s not the audience that even knows or cares about NAT.
You are wrong because you are being overly pedantic.<p>NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.<p>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).<p>Your definition of security is too narrow.<p>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.<p>Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
<i>> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.</i><p>Any good firewall does the same, by having a default “no” rule for incoming connections.<p><i>> A firewall is not required for NAT to work</i><p>Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?<p><i>> NAT effectively reduces the attack surface for a home network to the router.</i><p>While true, this doesn't add to the argument for/against IPv6. That is just security provided by default configuration, which can be provided many other ways and could be before the subset of NAT you are talking about was common.
Busses aren't for safety. Seatbelts and airbags and etc are. Busses are just for moving large numbers of people around efficiently.<p>And yet statistically I'm safer on a bus. Therefore it's reasonable to ride the bus "for safety".
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.
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.
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.
For "most people" the router/gateway has a firewall by default. And there isn't any reason why you can't have a NAT for ipv6, it just isn't necessary.
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.<p>This is a (dumb) NAT but has no state so it cannot possibly implement a default deny or any firewall adjacent features.
This is a terrible argument. First, NAT <i>doesn't</i> 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.
The firewall on your typical IPv4 router does basically nothing. It just drops all packets that aren’t a response to an active NAT session.<p>If the firewall somehow didn’t exist (not really possible, because NAT and the firewall are implemented by the same code) incoming packets wouldn’t be dropped, but they wouldn’t make it through to any of the NATed machines. From the prospective any machine behind the router, nothing changes, they get the same level of protection they always got.<p>So for those machines, the NAT is inherently acting as a firewall.<p>The only difference is the incoming packets would reach the router itself (which really shouldn’t have any ports open on the external IP) reach a closed port, and the kernel responds with a NAK. Sure, dropping is slightly more secure, but bouncing off a closed port really isn’t that problematic.
NAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO.<p>Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
Instead of all my devices being behind one IP and using an internal IP subnet, now each device has a globally routable ip address that will be used... Cool great opsec.
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.<p>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.<p>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.<p>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.<p>But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
Difference between NAT and firewall? You can punch a hole in one of them <a href="https://en.wikipedia.org/wiki/Hole_punching_(networking)" rel="nofollow">https://en.wikipedia.org/wiki/Hole_punching_(networking)</a>
Just like a load balancer is a kind of NAT, but I don’t think people would conflate this with a security measure / FW.
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.
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...<p>its not about the firewall. there's just a lot of extra attack vectors without a nat.
I agree with the majority of your point, but hopefully your printer hasn't been assigned IPv6 IPs that are global in nature and is instead limited to site-local.<p>For anyone who is reading this but hasn't use IPv6, IPv6 addresses are a large flat 128-bit contiguous address space, but they are not universally routable. The prefix of any specific address determines what group of other IPs can get to it.<p>We often think of a computer as having an IP address, but with IPv6, computers will have several addresses, all with different prefixes to handle different types of traffic.<p>This site does a decent job of explaining - <a href="https://networklessons.com/ipv6/ipv6-address-types" rel="nofollow">https://networklessons.com/ipv6/ipv6-address-types</a>
If you plug your printer into your home network, and if the local DHCP server is configured to hand out globally routable addresses from your ISP provided /64, then your printer will also be globally routable (as well as your "smart" fridge, "smart" TV, "smart" thermostat, etc). In my personal experience this is the default situation with consumer ISP IPv6 setups.<p>This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.<p>That said, I expect (hope?) that all ISP gear should default to enabling a stateful firewall. Hopefully there's no difference between the default security of an IPv4 and an IPv6 setup in practice. But given the history I'm not entirely optimistic.
>This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.<p>I mean, I agree with them. I think people who say 'NAT is not security' are only correct in the absolute most pendantic way and that the way NAT is commonly configured is literally the only reason the internet doesn't consist mostly of botnets.<p>But I also suspect that if IPv6 were more common, we as a society would be better at it, and not do dumb things like hand out globally routable IPs via DHCP6
It's scary how many supposed hackers have never even looked up an RFC before making grandiose statements. There is such a thing as "NAT filtering", see RFC 4787, section 5: <a href="https://datatracker.ietf.org/doc/html/rfc4787#section-5" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc4787#section-5</a><p>A NAT is not a firewall, yes. At the same time, the NAT boxes out there in the wild absolutely do filter traffic, and yes, it is the NAT that does it, not a separate firewall. Practically all NAT boxes in the wild do stateful filtering. It is not really standardized how they do it, but this is how the real world often works. People argue that the filtering part of NAT is "actually a firewall", but what's the point? From the outside, you will not be able to tell if there's a firewall that filters traffic for which no established connection can be found, or if this is done by a NAT.<p>Many people are so fixated on the definition that NAT is only address translation and nothing else, they refuse to interact with the real world out there.
It quacks like a duck though.
It's scary how somebody posting on hackernews thinks that this site is about hackers in the sense of security.
RFC 4787 is useful in distinguishing NAT mapping vs filtering. Surprisingly symmetric NAT actually seems quite rare today.
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.<p>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.<p>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.
> NAT is not for security, it does not provide security.<p>It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.<p>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 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.<p>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.
>UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s.<p>I know that, and you know that, but squillions of people think that turning the UPnP setting off (if they even know what that is) is sufficient, which is why the myth persists.
UPnP is only relevant for software that's already running on your machine locally. People here aren't generally talking about outbound connections and I think you both know that. The practical effect of NAT as commonly encountered in a residential setting is to drop inbound unsolicited connection attempts.<p>And yes, everyone is aware that you could <i>also</i> do that with a stateful firewall. And no, none of us care about arguments of definition that attempt to frame NAT as technically being a firewall based on how it operates in practice. Being intentionally obtuse by refusing to acknowledge the obvious isn't going to convince anyone.
It doesn't confer much since it COULD be only NAT and no firewall.<p>It's INCREDIBLY unlikely to find a case of that in the wild, but possible.<p>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
I think there's a philosophical difference between IPv4 and IPv6.<p>IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged. The IP address is just a technicality and outside of local networks, just a part of the routing strategy.<p>IPv6 on the other hand is like an URL - an address you can use to find any device from anywhere on the planet. It makes no distinction between client and server. Which is why its pushed in places like IoT and smartphones - a voip call has no conceptual client and server.<p>One could make ones smartphones Ipv6 address openly available, and anyone could initiate a voip call to their phones. Would this be wise? I'd argue there's no scenario under which this doesn't cause an unacceptable level of risk, as even if the software is perfect, they'd be still vulnerable to DDOS attacks.<p>This means that NAT-equivalent firewall rules are necessary, which makes the whole discussion kind of moot, but it's not a good portent for Ipv6 that it makes previously unfeasible kinds of attacks potentially practical.<p>NAT also allows for other neat tricks, like IP level load balancing.<p>I'd say one huge and unambiguous advantage of IPv6 is that it makes UDP trivial.
> <i>IPv4 is from the era of local computer networks, which feature clients and servers.</i><p>IPv4 on the ARPANET 'went live' in January 1983,[1] but the concept of a firewall didn't really happen until about a decade later (with some protocols having to be altered[2]):<p>* <a href="https://en.wikipedia.org/wiki/Firewalls_and_Internet_Security" rel="nofollow">https://en.wikipedia.org/wiki/Firewalls_and_Internet_Securit...</a><p>Some of us still remember open (SMTP) relays and the openness of the early Internet:<p>* <a href="https://en.wikipedia.org/wiki/Open_mail_relay" rel="nofollow">https://en.wikipedia.org/wiki/Open_mail_relay</a><p>IPv4 has always <i>not</i> been only about local computer networks: end-to-end connectivity was there at the start and only got choked off later.<p>[1] <a href="https://en.wikipedia.org/wiki/Flag_day_(computing)" rel="nofollow">https://en.wikipedia.org/wiki/Flag_day_(computing)</a><p>[2] <a href="https://datatracker.ietf.org/doc/html/rfc1579" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc1579</a>
> <i>IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged.</i><p>No, it was meant to be a global address space where anything could talk to anything. That became unworkable due to scale and the limit inherent in using only 32 bits for the address space.<p>Some older protocols (ftp) don't play nice with NAT and need special handling, because address multiplexing was never intended to be a thing.
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.<p>I believe the common knowledge is somewhat more nuanced than people would have you believe<p>I present to you two separate high-value targets whose IP address has leaked:<p><pre><code> IPv4 Target: 192.168.0.1
IPv6 Target: 2001:1868:209:FFFD:0013:50FF:FE12:3456
</code></pre>
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.<p>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)<p>Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:<p>Here is a real world target:<p><pre><code> FDC2:1045:3216:0001:0013:50FF:FE12:3456
</code></pre>
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),<p>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?<p>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 <i>massive</i> IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.<p>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.<p>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 <i>want</i> 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.<p>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.<p>Imagine I've shared output of "ifconfig" on my machine, or "netstat" output, or logs for some network service which listed local addresses.<p>For IPv4, this will is totally fine and leaks minimal information. For IPv6, it'll be a global, routable address.
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.<p>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.<p>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.<p>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.<p>Put another way - to do an apples to apples comparison:<p><pre><code> Hard to attack: FDC2:1045:3216:0001:0013:50FF:FE12:3456
Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456</code></pre>
It took me less than 1 second to access that 192.168.0.1 address! It wasn't that hard to find.<p>(;-)
Deeply ironic that Cisco would teach this, because it's the opposite of what they said when they introduced NAT.
If the IP address was leaked, wouldn't it be the address of the unit doing the NAT translation instead of the standard-gateway?
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.
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.
NAT causes security issues too. Reflection attacks are much harder to stop if the endpoint and its network address are decoupled.<p>You can provoke loops and tangles of many sorts, some at the same protocol level and others going up and down.<p>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.<p>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:<p>> Unfortunately, NAT <i>reduces the number of options for providing security</i> [1]<p>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(!)<p>[1] <a href="https://www.rfc-editor.org/rfc/rfc1631.html" rel="nofollow">https://www.rfc-editor.org/rfc/rfc1631.html</a>
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?<p>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 have any idea how they got the ip,<p>You might've been using DHCPv6 assigning sequential addresses starting at 1?<p>Remember: friends don't let friends use DHCPv6[*]. Help out, uninstall DHCPv6 today.<p>[*] in IA_NA mode (address assignment). PD and stateless info-only are fine.
Another possible explanation is that the IP was not random enough. For example: network_prefix::1
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.
You're gonna need to scan 2^64 addresses once you've located the IPv6 network assigned to my connection before you find my phone. 2^56 if you don't get lucky guessing the network prefix it happens to be on at that moment.<p>Assuming a scan with a minimum 4 byte ICMP packet, that's about 73786 petabytes of network traffic for that /64. You'll need to shove it down the pipe within a day because IPv6 privacy extensions means the IPv6 address used changes after 24 hours. With only 1gbps fiber, I don't think the deanonimysation is the problem at that kind of traffic level.
I'm also not sure how much it helps, but a friend and I were just talking about how big the numbers get today.<p>My ISP provides my house a /56 allocation. There are 4,722,366,482,869,645,213,696 addresses. I should have enough for a couple of years, at least.<p>I guess you could scan it. The IPs for most devices are chosen randomly within a /64 subnet, or they're based on MAC address, but they're not sequential by any means. A /64 is still 18,446,744,073,709,551,616 possible IPs.
Most of the time it's going to be a /64, so even if you know the prefix you're still never going to guess a random address. But a lot of older clients will use a deterministic address based on their MAC, searching the space of MACs for known sbcs would be a lot more tractable.
There was a report a few years back about people running NTP servers to harvest IPv6 addresses.<p>Security via obscurity will only get you so far.
In theory, IPv6 Privacy Extensions (<a href="https://datatracker.ietf.org/doc/html/rfc4941" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc4941</a>) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.<p>That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
That's pretty embarrassing lol
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.
Unlike the other poster, I'm not going to blame you for getting things wrong. It happens, we all were learning at one point. But I do think it's incredibly unreasonable to use a mistake you made as an argument against IPv6. This would be like if I rm -rf'ed my Linux box into oblivion when I was first learning and then avoided Linux after that because I had bad vibes about it. Sometimes you need to accept the L and not blame the tools.
Have you tried setting up an IPv6-only LAN?
Nah, happened frequently at ipv6 early days. Some devices shipped with ipv6 enabled but no firewall out of the box.
This is going to depend on the router and on IP distribution.<p>My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.<p>NAT is not intended to be a security feature, for sure, but it creates security as a <i>side effect</i>. 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.<p>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 <i>hope</i> that any routers would ship with that.<p>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.<p>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!<p>[0]: <a href="https://openconnectivity.org/developer/specifications/upnp-resources/upnp/" rel="nofollow">https://openconnectivity.org/developer/specifications/upnp-r...</a>
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.<p>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 <i>might</i> 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).<p>Fortunately, my ISP has since implemented proper support for prefix delegation.<p>[1] <a href="https://www.asus.com/support/faq/113990/" rel="nofollow">https://www.asus.com/support/faq/113990/</a>
I got curious about what "passthrough" might be doing and found this assertion [0], which reminded me of the existence of '6relayd' [1]. So I assume that that mode relays the RAs & etc, but replaces the link-local address in the RA & etc with that of the relaying interface.<p>[0] <<a href="https://www.snbforums.com/threads/ipv6-passthrough-disadvantages.81668/#post-800033" rel="nofollow">https://www.snbforums.com/threads/ipv6-passthrough-disadvant...</a>><p>[1] <<a href="https://github.com/Yamatohimemiya/6relayd" rel="nofollow">https://github.com/Yamatohimemiya/6relayd</a>>
The Apple AirPort Extreme didn't by default until recently: <a href="https://support.apple.com/en-nz/103996" rel="nofollow">https://support.apple.com/en-nz/103996</a>
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.<p>(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.)
> My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.<p>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.
> my ISP still gives me only a single IPv6 address<p>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.
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?!<p>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".
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.<p>(IPv6 is still good for lots of other reasons, and NAT isn't <i>good</i> 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. <a href="https://www.rfc-editor.org/rfc/rfc1631" rel="nofollow">https://www.rfc-editor.org/rfc/rfc1631</a> 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.<p>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 first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims.<p>Here's an ad for it from Jan 1995 <a href="https://www.jma.com/The_History_of_the_PIX_Firewall/NTI_files/DataComm_Jan_1995.pdf" rel="nofollow">https://www.jma.com/The_History_of_the_PIX_Firewall/NTI_file...</a>. Note by the 3rd paragraph it's saying<p>> corporate networkers are free to expand and reconfigure their TCP/IP networks without agonizing over the much publicized IP addressing crunch. It also spares them from having to upgrade all of their host and router software to run IP version 6<p>It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:<p>> PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.<p>> And what about hosts that should be recognizable from the Internet, such as mail servers?<p>> These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is configured to map one of these external addresses to the device not just for the duration of the application session but on a permanent basis.<p>Looking past the marketing line and reading the manual, the reality was the PIX was always acting as a full stateful firewall and did not just rely on NAT itself to provide the inbound filtering. See the "PIX Firewall Adaptive Security" section on page 2 of this 1996 manual I managed to dig up as reference <a href="https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/hardware/pix/pix_v2.pdf" rel="nofollow">https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/...</a>. Rule hits that missed a state match were even loggable (what a box for the time!)<p>Whether people saw the marketing and assumed it was NAT that provided security is precisely the bad assumption the article talks to, but at no point in history was NAT prevalent without being paired with a normal stateful firewall to provide the security - since the intent of NAT was not to fill that role, even in the beginning, as sourced by 3 references now vs your personal claims.
The distinction you're trying to draw here, between <i>exclusively</i> using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.<p>The point is that NAT was introduced <i>as a kind of firewall</i>. The PIX firewall was named by Network Translation, Inc., which was acquired as a security device --- and, indeed, the PIX was for many years the flagship security brand at Cisco.<p>I don't dispute that NAT is dispensable (though: dispensing with it in millions of residential prem deployments is another story altogether!), only that it's "not a security tool" --- it clearly is one, and a meaningful one (whether network snoots like it or not) in a huge number of networks.
> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.<p>That's not the distinction I, or TFA, set out to make.<p>It's not that NAT is a component of controls that could be replaced by others, it's that whether NAT was put in place for security or if it was always assumed you need an actual stateful firewall precisely because NAT was never intended or believed to provide meaningful security, even in the days of classful networking.<p>Not one of the references above makes claim that NAT was intended to provide security on its own. That the PIX launched with actual firewalling capabilities does not bolster that NAT=security, it actually bolsters that NAT was never believed or intended to provide security even further.<p>To turn this back around at you: The distinction you're drawing that NAT could have provided "something better than nothing" in terms of security if appliances like the PIX hadn't always shipped firewalling from day 1 isn't meaningful.
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 <i>think</i> that it does, but if so there is no visible evidence that it does.
This is one of those occasions where people are arguing semantics, and you're like "but -- I was there!"<p>My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)<p>As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.<p>Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
NAT isn't security <i>at all</i>, 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.<p>Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.<p>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.<p>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.
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 <i>didn't</i> have that.
Yes, but we've just successfully rewritten the article in the comment section as "it's not having NAT that provides the security itself, but other configuration any sane person would expect on a device doing NAT to prevent unexpected inbound connections" is exactly what the article set out to separate.
Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do that precisely because NAT doesn't do that itself.
That makes no sense. If a packet comes into a public IP to a session that doesn’t exist, there is nowhere to forward the packet onto. The public IP belongs to the router.<p>If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
[dead]
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.<p>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.<p>Culprit? Privacy addresses kept accumulating until they overflowed the SIP UDP packet size because it listed all the combinations of supported codecs/endpoints.<p>Oh, btw, do try to answer this message: <a href="https://www.reddit.com/r/VOIP/comments/131ex1x/ipv6_sip_trunks/" rel="nofollow">https://www.reddit.com/r/VOIP/comments/131ex1x/ipv6_sip_trun...</a> - it's still relevant to this day.
You should have just disabled temporary addresses, they don't make a lot of sense on a server.
Having read and considered your position I see no reason to update my opinion.
> 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.<p>As I keep trying to explain each time this comes up: no, it doesn't and it won't.<p>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.<p>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 <i>might</i> 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.<p>NAT doesn't protect you from either of these.
Repeating the same wrong points doesnt make you right.<p>Every NAT based product will have a firewall built in also by default. And it'll be deny-all except for conn-tracked.<p>And that L2 attack is a martian packet. Why are you allowing reserved IPs talk on public network interfaces (hello, spoofing and obvious at that)? These are always blocked due to the reasons you describe.<p><a href="https://en.wikipedia.org/wiki/Martian_packet" rel="nofollow">https://en.wikipedia.org/wiki/Martian_packet</a>
So, if you have NAT but a grossly misconfigured router, it might not be secure?<p>Quick question - do you think that "security by obscurity is not security"? And, as a follow-up, when you park your car do you ensure your laptop bag is out of sight, maybe locked away in the boot?<p>Because here's a mindblowing concept that'll change the way you see the world - you can have a door lock but it won't make you secure. You need to actually fit the lock to some sort of door.
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.<p>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.
With IPv4, if NAT isn't working right then I simply cannot get online and I need to fix it. Fail safe. With IPv6, when my computers being globally addressable is the norm, if my firewall is misconfigured my computers will probably still be online. Fail unsafe.<p>Arguing this is pointless anyway because it's not even my decision, it's my ISP. I am however quite happy with my ISP's choices in this regard.
Right, IPv6 is annoying because it lacks NAT. There's a big difference between something being a huge pain to deal with (IPv6) and being insecure.
Ok, I'll bite: why do you say that IPv6 lacking NAT (which is not true by the way) would be annoying? We can finally get rid of an ugly workaround from 30 years ago that broke one core principle of the Internet (end-to-end connectivity) and a ton of protocols that required even uglier hacks (FTP and SIP ALGs, TURN/STUN, etc.) to barely work. Why would this be annoying?
IPv6 doesn't "lack" NAT. There is nothing preventing you from using ULA addresses inside your network (IPv6's version of RFC-1918) and then running NAT for those addresses on your router. IPv6 just doesn't _need_ NAT, but it is still an option.
I’m not using any networking implementation that’s less tested and ipv6 is less tested. Network routing means there are dozens of TCPIP implementations touching traffic. The benefit of ipv6 for my case isn’t worth the risk. If you’ve never run into an ipv6 specific bug good for you.
>NAT isn’t actually a security feature<p>Perhaps not in the high brow network security world, but in practice it really is used that way.<p>Who here has never launched an unauthenticated server on their LAN?
When I was about 12 I was working on a PHP3 application, I had some issues with a MySQL query, and I pasted my code to pastebin (or whatever we used back then) and shared the link on IRC, the code included my database credentials.<p>Back then our ISP gave every computer a public IP.<p>The next thing that happened was that someone changed my MySQL password, and me being 12, I didn’t know how to change it back.<p>They made me beg for the password, to much amusement to the whole channel, and then they helped me secure it and taught me how to reset the password.<p>NAT would have saved me, but I wouldn’t have received a free, though a bit embarrassing, security lesson.
That's what the firewall on your router is for. NAT <i>might</i> also stop someone connecting, but it's not a guarantee. You can get given a public address and be exposed, you can find out your server actually does UPNP automatically and so is exposed, etc... a firewall is more explicit and a better defence.
That's a strange example. An unauthenticated server on a LAN wouldn't be exposed to the Internet any more than a network using NAT would be. You would need to explicitly configure your routers firewall to expose a local node, the same way you would need to explicitly configure port forwarding with a NAT based network.<p>I've see some argue that a hypothetically buggy router would somehow be less likely to fail if NAT was used but really, that could be equally said about bad port formatting defaults, which have in fact happened. Complexity is what increases the likelihood of bugs at the end of the day.<p>NAT is just an addressing hack, a weirdly complex way of indirectly routing to local addresses. It only influences what is written on the envelope, not how that envelope is processed at the post office.
What does NAT do for security that a firewall doesn't?
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.<p>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.<p>NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.<p><a href="https://datatracker.ietf.org/doc/html/rfc6296" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc6296</a>
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.<p>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.<p>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.<p>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.
What they're saying is NAT66 on Fortigates is 1:1 NAT, i.e. prefix translation, not n:1 NAPT, i.e. address+port translation.<p>I can't imagine why one would ever intend to use NAPT over NAT when the addresses were available though (e.g. on IPv4 where having a minimum of 2^64 public addresses per connection is not assumed), which is the only reason I wouldn't expect anyone to have bothered implementing it. So sure, it's what people refer to on IPv4, but it's not materially different from 1:1 NAT or necessarily adding any additional value.
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.<p>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 <i>is also already a fully stateful firewall</i>, because the software required to do one is virtually identical to the other.<p>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 <i>every</i> consumer network gateway device you might buy.<p>You literally have to go well out of your way to find a network device capable of NAT that <i>can't</i> 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 <i>any</i> 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.<p>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.<p>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?
Telstra, one of Australia's massive telcos who are the "go to" telco for nannas who don't know anything about this internet thingy, have IPv6 enabled by default on their CPE routers. Without NAT. With a stateful firewall. Works perfectly fine for their millions of customers.
It would work out just fine, because NAT was never providing any actual security to your nana. It was only ever the firewall which made her secure, not NAT.
With NAT turned on nana's computer is still protected by the same Arris gateway.
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.
It's not, because in the real world NAT only affects your outbound connections. That means that turning it off only changes the behavior of outbound connections, not inbound ones.<p>Any inbound connection that would have worked before you turned it off will still work afterwards, and any that wouldn't have worked before will still not work afterwards.
France with >85% IPv6 adoption mostly made of grandmothers driving a motorcycles across the town manually delivering packets like in their youth.
<a href="https://arxiv.org/abs/2509.04792" rel="nofollow">https://arxiv.org/abs/2509.04792</a>?<p>"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."
Security is a state of mind. So, whatever makes you feel secure, it's your security tool. NAT can be used for security, like VLANs gets a lot used for LAN security. And BTW, NAT can alter destination of IPv4 packet, but also the source. Which is not necessarily only masquerading, and it's seen a lot as embedded security, especially for home Internet. A firewall does not provide security by itself, it has to be configured in the specific way for the situation. I've seen a lot of firewalls with 100s of rules, but the first one was accept all forward, forgotten there by an admin after a test several days/months/years ago.<p>We are trying too much to put things in unique and well defined boxex. Universe does'n work like this. Security is just a state of mind.
The is a huge difference between: I assume my crappy router's firewall works and is configured safe by default. And I assume my crappy router's doesn't forward ports by default.
As someone with limited networking knowledge, I’m not really getting smarter here. Some say it adds security; others disagree. Let me ask this: does IPv6 benefit me in any way if I have multiple devices at home behind a router and I'm not running any servers or similar services?
Smart home and lighting standard Matter over Thread requires it. Discovered this after i bought some Ikea smart lights. Though you don't need a public IP6, a local static IP6 with SLAAC is enough.
No idea what you're doing on a daily basis, but let's grab a not-exactly random example. You and your friends are at your house trying to play an online game of King's Court (it's super checkers!) with some friends in Denmark. For whatever reason the developers decided all clients will use port 12345 to communicate. In ipv4 with NAT, local connections will be possible but only the first one to try to communicate out will ever possibly succeed. You and your friend are thwarted and have to find some NAT-defeating means or just give up on doing 10-jump moves to ruin each other's evenings and have an internet drinking game. With IPv6, all of it works fine.<p>Most casual users have lived with NAT so long they assume its limitations are natural. But they are not. You can achieve the same result with a firewall or ACLs or whatever on ipv6, but that's a choice and not a limitation.
Do you play video games with P2P networking? Then your choices are to pick one of the following:<p>- the hosting player enables upnp<p>- use ipv6<p>- the hosting player manually sets up port forwarding (consumer routers often talk about a DMZ option which takes an IP address - really this is just forwarding all ports not matched by any other rule)
No
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.<p>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?<p>Admittedly I'm not expert so I might be talking shit.
You said it yourself. NAT was introduced to solve the address space issue. At that point firewall were already a thing.<p>You also acknowledged correctly that IPv6 Will botnrun into the same address space limitations.<p>You said NAT is not a good thing Security-wise. Then you follow up the question, why we shouldn't add that to IPv6 as a security feature. It's hard to understand the train of thought.<p>So let me answer this. While NAT incidently does something similar to a firewall, it is not a security feature. NAT must track any outgoing network connection in order to understand where to route incoming packets. If a packet it not a reply to an established connection, it is dropped. Otherwise the NAT must look up who opened the connection. A NAT can only work if stateful.<p>In a routable connection, ALL of that can be based on the static routing table.<p>Imagine a university with 10,000 computer, all of them having opened maybe 100 concurrent connections. The NAT must track every single connection and do a lookup for every packet.<p>In a routable network, it just looks up the destination IP in the packet and sends it to the next hop for the destination IP.<p>All while hopefully a firewall is in front of it.<p>So why would you want to reintroduce NAT to IPv6, when both issues are efficiently solved already?
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.<p>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?
A firewall is the security feature you want. With a default-deny rule, which most will come configured out of the box with, it does exactly what you expect: block all unsolicited incoming traffic.<p>Most people are probably actually running a firewall with NAT anyway, they just don't know it because an appliance with default-deny is pretty much install and forget for most people. So, no, it doesn't cause any additional problems.<p>The only difference with IPv6 is you don't need to NAT any more, but you keep the firewall.<p>It's important to remember NAT is part of the IP routing layer. In its regular form, a router just forwards packets to where they should be going. So it's plugged in to one or more networks, receives packets on one interface and forwards them, unmolested (well, mostly), to another interface. It's almost completely analogous to letters going through the postal system. The postal service just forwards letters around by looking at the address. It doesn't modify them in any way.<p>NAT is a bastardisation and is like your postie scribbles out the "return to sender" address and replaces it with his own. If you were to reply to that address, your postie would remember he did that, and replace the address you wrote with the original address he scribbled out earlier. It's not how IP routing is supposed to work at all and, in fact, a device doing NAT cannot strictly be considered a router at all.<p>Something you can add to any device is a packet filter. A router must not filter packets as it then wouldn't be considered a router (similar to molesting the packets with NAT). But you can insert a packet filter before things get to the router. If you glue those two things together and bundle it in one device then, voila, you have a firewall. A stateful firewall is conceptually like a packet filter and router glued together and working closely together. But you can just think of it like telling your postie "I only want to receive letters from mum" and he just burns all the rest before they get to you front door. (In reality you also want to allow correspondence so it's more like "only allow letters that are replying to letters I sent, which you'll know because you're my postie, or if mum sends a letter first, allow that too").<p>Writing this up makes me think... why don't we just teach this stuff using the postal system as an analogy? It's an almost perfect analogy and surely even today anyone understands this concept.
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:<p>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.<p>And we are assuming here that there is no firewall.<p>Note : macOS firewall on a new install is disabled iirc.
I don't understand, after all this time, why ipv4 still dominates
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.<p>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.<p>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.
> many of them don't seem to be open to the idea of learning something new<p>To the idea of learning something designed by commitee, over complex and stinking of enterprise and that you simply can't deploy "by hand".<p>One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
The "inside" is your /56 or /48. You can add more local-only "inside"s if you'd like, which is useful for terrible ISPs with rotating network prefixes. The "outside" is everything on the internet.<p>If you can make your way through the absolute slog that is ARP+DHCP, you can get through NDP+SLAAC. Or even NDP+DHCPv6 if you're a control freak.<p>> One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.<p>If you want NAT, then set up NAT. Your fdb6:fc49:f5ae::/48 ULA is your 192.168.x.y address. Set up DHCPv6 if you'd like to pretend you control your address space. You could even just ignore the spec and use fdfd::/48 as your ULA so you can memorize addresses (fdfd::1, fdfd::2, that's even shorter than 192.168.1.2!). Use fe80::1 (a perfectly valid address) on your router as a standard gateway and have it do NAT to the outside world.<p>Even though it's heavily discouraged (because NAT is a massive hack after all), you can do NAT on IPv6 without any special tooling.
> The "inside" is your /56 or /48.<p>No it's not mine. It's the ISPs.<p>> which is useful for terrible ISPs with rotating network prefixes<p>... which is what you said :)<p>> If you can make your way through the absolute slog that is ARP+DHCP, you can get through NDP+SLAAC. Or even NDP+DHCPv6 if you're a control freak.<p>Oo enterprise. I believe you missed another 5 or 6 acronyms that are also required for having ipv6 internally.
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.<p>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.<p>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.<p>"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<p>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)
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.
Of course it's not insecure because of NAT.<p>NAT (in all its forms) is just a very convenient technology for many people and niche situations.<p>And adoption of IPv6 will be hindered as long as NAT is not a first class citizen.<p>And of course, mostly NAT should not be used as "firewall replacement". But what many firewall proponents forget here:<p>NON-IT People at home cannot run and manage a firewall (and proxies). For them, NAT is a convenient and mostly okayish replacements.<p>Another niche would be IP Packet Handling of VMs.
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.<p><pre><code> Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface ID</code></pre>
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.
[dead]
NAT is not inherently a security feature, however where NAT happens is somewhat important.<p>A local router that I can control deals with how to map from my public IP to my private IPs.<p>This is not security but is obfuscation of the traffic.<p>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.
I hate NAT with a passion. It's a terrible technology, whose disruptive nature has probably prevented any novelty on the transport layer. But this article is oversimplifying things.<p>It is well known that NAT is not meant for security and that NAT is not a firewall. But one cannot deny that it implicitly brings some "default" security to the table. With NAT it's basically impossible to screw you over because there is no meaningful practical way to allow inbound connections without the client explicitly defining them (port forwarding). With IPv6, you could have a lazy vendor that does not do any firewalling or a has a default allow policy or maybe buggy firewall. With NAT that is not possible. There is no lazy/buggy NAT implementation that allows inbound connections for your entire network, because it is technically not possible. When a NATting device receives a packet with a destination port that has not previously been opened by a client, it does not decide to drop this packet because of a decision by the vendor. It drops the packet because there is simply no other option due to the nature of NAT. That is what people mean when they talk about the inherent "security" of NAT.<p>Again, NAT is terrible. We need to finally get rid globally of IPv4 and all the NATting that comes with it. But let's keep it to the facts.
It's wild because saying that NAT is required kind of admits your machines are vulnerable on the LAN! You should have good firewall rules no matter what.
This article may have been prompted by my (or similar) response to John's comment on [1] yesterday.<p>He stated:<p>> NAT is not a firewall: all it does is rewrite packets, it does not drop them.<p>I noted (without quoting at the time) that the article actually mentions this aspect of NAT, here is a quote from yesterday's article:<p>> Time and time again we are lectured that NATs are not a good security device, but in practice NATs offer a reasonable front-line defence against network side malware scanning and injection, so there may be a larger story behind the use of NATs and device-based networks than just a simple conservative preference to continue to use an IPv4 protocol stack.<p>Since I didn't state it before, I don't see any need to add NAT to IPv6 and certainly not for security reasons when a firewall is the correct way to secure networks. I don't feel that IPv6 is inherently more or less secure than IPv4, regardless of NAT. I also agree that even for IPv4, firewalls should be used and that NAT should not be relied on as a security measure for any remotely high stakes situation.<p>The reason I made my comment though is because I seem to share the same opinion as yesterday's article's author that people stating "NATs are not a good security device" are missing the point that in regard to IPv4, NAT may not be a "fully proper" security measure, but in practice it is "plenty good enough" for the vast majority of internet users.<p>People proclaiming how NAT is not a security measure seem to me to be ignoring our reality where 100s of millions of consumer routers, incidentally but nevertheless effectively, use it as one. Even without a firewall to drop packets on these devices doing NAT, they effectively block a whole class of automated malicious activity.<p>Is it safe to have unprotected network devices shielded only by NAT without a firewall? No, not really.<p>Should you use a proper firewall even if you have NAT? Yes, absolutely, but a lot of people don't and are nevertheless adequately protected considering they probably have no "open" devices on their network and have no particular reason to be targeted by a truly determined malicious actor.<p>[1] <a href="https://news.ycombinator.com/item?id=46691835">https://news.ycombinator.com/item?id=46691835</a>
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”.
If IPv6 is behind firewall, apps can't use it for P2P connections, so the major point of IPv6 network becomes moot.<p>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:
<a href="https://tailscale.com/blog/how-nat-traversal-works" rel="nofollow">https://tailscale.com/blog/how-nat-traversal-works</a><p>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.
[dead]
IPv4 is not secure because it requires a NAT in order to be?<p>Big centralized online services does not want IPv6 because it "unlocks" internet as intended, full p2p at scale. They won't let that happen easily.<p>And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
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)".<p>would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
Agreed with the main message.<p>... but<p>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.<p>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.<p>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.
Security is not a binary. NAT is (slightly?) more secure.
I'm on ipv6 since 2 years and I am very happy.<p>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.<p>We really should move on from IPv4.<p>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".
Networking folks love to write this article. “NAT isn’t a security layer.” I’ve been hearing it for 20 years. But while that’s not its purpose and while there are other layers that can provide the same features, it’s still a very useful piece of a larger puzzle of defining borders in a network architecture. Sometimes it helps if those borders are obvious to the eye, via the use of a private address zone, or if opening a port on the server can never “just work”, regardless of your external firewall rules. All sorts of trivial mistakes can be avoided with This One Weird Trick. So sure, it’s not technically required, and doesn’t solve every problem. But the constant harping about “NAT isn’t security” is sorta pointless.
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.<p>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: <a href="https://en.wikipedia.org/wiki/Protocol_ossification" rel="nofollow">https://en.wikipedia.org/wiki/Protocol_ossification</a>
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.
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 have yet to see a "NAT is not security" rebuttal that does not make either one or both of these points:<p>- NAT is not a security feature because it wasn't designed as one (this post), and/or<p>- 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.<p>And yet making LAN devices unroutable from the Internet <i>does</i> 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.<p>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.<p>Is the latter something that was/is actively exploited?
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
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.
It s true. That s not the reason it is insecure. The reason it is insecure is people who infiltrated the committee made sure to make data exfiltration possible through mandatory ICMP for everything.<p>Good luck setting up proper firewallimg rules for IPv6 while both respecting its specs and preventing hard-to-detect exfil through ICMPv6.<p>It's a rube-goldberg of a protocol and it s hard to believe it s all incompetence and there ain't t some malice involved.<p>NAT for IPv4 was an accidental godsend, especially useful in an era where you d hack your neighbors' computers when they where on the same subnet as yours. Don t tell me it didn't t happen for I was doing that on dial-up back in the days.<p>Thankfully the point is mostly moot because people are still free to use IPv4 at home/companies while having their router using IPv6.<p>IPv4 shall thankfully outlive me. And I don't t care if it means more work for people working in the "punch the monkey" ads industry.
I wrote that comment, and you can write to yourself how many times you want that NAT is not a firewall.<p>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.<p>It effectively protects most networks from most attackers without ANY additional configuration, making it inherently foolproof.<p>Here, I put a private key for a wallet with 0.01 bitcoin at this address: <a href="http://192.168.80.26/" rel="nofollow">http://192.168.80.26/</a> 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<p>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_.<p>No it's not. NAT is not <i>ever</i> 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.<p>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<p>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
For 99%+ of residential users, the upstream peer is the router owner/operator, so they can just direct the router to hack you if they wished. So this NAT "vulnerability" is not useful in practice, since it can only be used by your upstream which already "owns" you.
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 disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.<p>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.<p>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.<p>The important bit here is not NAT or firewalls, but layer 3 network segments!!!<p>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!<p>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.<p>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.<p>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.<p>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.<p>><i>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.</i><p>This is typically handled by the <i>firewall</i>, 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<p>(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)
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:<p>> Modern routers ship with firewall policies that deny inbound traffic by default, even when a NAT is not being used.<p>So no, not every device needs its own firewall. You can have a single firewall at the entrance of your network.
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.<p>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.
It is not at all "easy to misconfigure". First of all, the manufacturer is going to configure it for you in 99% of cases, just as they do for IPv4. Second, even if you want to roll your own firewall rules, it's trivial to set up a default deny on all incoming traffic.