As I keep trying to explain each time this comes up: no, it doesn't and it won't.
When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.
Of course, this just strengthens your point that NAT isn't security.
NAT doesn't protect you from either of these.
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.
My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.
But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.
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.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
[0]: https://openconnectivity.org/developer/specifications/upnp-r...
(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.)
A local router that I can control deals with how to map from my public IP to my private IPs.
This is not security but is obfuscation of the traffic.
Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
There's generally no reason to be enabling NAT when you have enough address space to not need it. It can be a useful tool in your toolbox sometimes, but it's not something to be enabling by default.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
IPv4 Target: 192.168.0.1
IPv6 Target: 2001:1868:209:FFFD:0013:50FF:FE12:3456
Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
FDC2:1045:3216:0001:0013:50FF:FE12:3456
(;-)
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
Hard to attack: FDC2:1045:3216:0001:0013:50FF:FE12:3456
Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
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.
... but
An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.
For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.
In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
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.
Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.
So there is nothing about a lack of NAT in IPv6 that makes it less secure.
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.
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.
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?
To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>". What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.
And IPv4 NAT is actually possible to penetrate sometimes. So for some networks, IPv4 provides better P2P connectivity, than IPv6.
ggm•7h ago
NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.
NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.
https://datatracker.ietf.org/doc/html/rfc6296
ghshephard•1h ago
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
endmon•37m ago
zamadatix•35m ago
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.