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.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The 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.
> 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
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> 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.
> And what about hosts that should be recognizable from the Internet, such as mail servers?
> 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.
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 https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
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 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.
The point is that NAT was introduced as a kind of firewall. 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.
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 principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
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.
Yes, but we've just successfully rewritten the article in the comment section as this is the exact clarification that it's not having NAT that provides the security, just other configuration any sane person would have on a device doing NAT.
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.
This is going to depend on the router and on IP distribution.
My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.
But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.
> If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
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.
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.
Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
FDC2:1045:3216:0001:0013:50FF:FE12:3456
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.
For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
Hard to attack: FDC2:1045:3216:0001:0013:50FF:FE12:3456
Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
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.
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".
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
As I keep trying to explain each time this comes up: no, it doesn't and it won't.
When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.
Of course, this just strengthens your point that NAT isn't security.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across town, she would not survive it.
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.
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
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.
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.
NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
From my understanding, the "IPv4 NAT" equivalent for IPv6 is generally referred to as NAT66 (NPTv6 for Prefix-Translation). For example, Fortinet offers this on their firewalls, and I believe most firewall vendors have this option.
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.
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.
NAT is not inherently a security feature, however where NAT happens is somewhat important.
A local router that I can control deals with how to map from my public IP to my private IPs.
This is not security but is obfuscation of the traffic.
Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator.
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.
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.
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”.
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.
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.
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet".
It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>".
What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification
Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.
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.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The 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.
Here's an ad for it from Jan 1995 https://www.jma.com/The_History_of_the_PIX_Firewall/NTI_file.... Note by the 3rd paragraph it's saying
> 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
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> 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.
> And what about hosts that should be recognizable from the Internet, such as mail servers?
> 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.
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 https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
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 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.
The point is that NAT was introduced as a kind of firewall. 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.
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 principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
NAT absolutely does provide good security. It denies all incoming traffic that is not part of an established connection.
Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.
So there is nothing about a lack of NAT in IPv6 that makes it less secure.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
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.
Yes, but we've just successfully rewritten the article in the comment section as this is the exact clarification that it's not having NAT that provides the security, just other configuration any sane person would have on a device doing NAT.
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.
[dead]
This is going to depend on the router and on IP distribution.
My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.
But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.
> If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
[0]: https://openconnectivity.org/developer/specifications/upnp-r...
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.
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
> My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
Interesting how that works in your case. Is your router gives your devices IPv6 from fc00::/7 and then NAT them? It would be a rather rare case.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
It took me less than 1 second to access that 192.168.0.1 address! It wasn't that hard to find.
(;-)
Deeply ironic that Cisco would teach this, because it's the opposite of what they said when they introduced NAT.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
[dead]
If the IP address was leaked, wouldn't it be the address of the unit doing the NAT translation instead of the standard-gateway?
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
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.
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".
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
As I keep trying to explain each time this comes up: no, it doesn't and it won't.
When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.
Of course, this just strengthens your point that NAT isn't security.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
NAT doesn't protect you from either of these.
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across town, she would not survive it.
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.
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
With NAT turned on nana's computer is still protected by the same Arris gateway.
If IPv6 is behind firewall, apps can't use it for P2P connections, so the major point of IPv6 network becomes moot.
And IPv4 NAT is actually possible to penetrate sometimes. So for some networks, IPv4 provides better P2P connectivity, than IPv6.
Not really, look at a great post on Tailscale blog how such P2P connection can be established: https://tailscale.com/blog/how-nat-traversal-works
With IPv6 you might have to use a hack to make firewall allow incoming packets (like sending a dummy UDP packet to the peer first). The firewall only read, allow or deny these packets. While NAT must mess with the message IP//TCP//UDP headers to work.
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.
NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.
https://datatracker.ietf.org/doc/html/rfc6296
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
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.
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.
NAT is not inherently a security feature, however where NAT happens is somewhat important.
A local router that I can control deals with how to map from my public IP to my private IPs.
This is not security but is obfuscation of the traffic.
Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator.
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.
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.
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it lacks NAT”.
The lack of NAT has no bearing on security. Despite an old mistaken belief.
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.
Agreed with the main message.
... but
An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.
For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.
In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet". It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>". What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.