The number one complaint I hear (and have myself) is that maybe I don’t _want_ all devices on my LAN to have public IP addresses. NAT makes security a lot easier to reason about.
This isn't a goal in itself. The formerly problematic and unwanted side effects of NAT, namely a broken peer to peer relationship of hosts on the internet, are now understood as a feature. Machines were forced by this technology to be clients and the initiators of all connections to the internet. Historically this has interfered greatly with several internet protocols (ftp, IRC DCC, p2p file sharing, ...) all mostly dead now or reworked to operate in a world full of NAT gateways.
IPv6 would reverse this state of affairs. If machines need to be denied the server role, this can be enforced by a firewall. As far as tracking of clients by IP goes, dynamic address assignment via DHCP or IPv6 privacy extension take care of that.
You’ll lose weight in a famine but nobody would suggest it as a diet plan.
What overhead does NAT add compared to a L4 firewall?
> plus losing functionality that cannot operate through NAT.
What functionality does NAT prevent that a L4 firewall doesn't?
NAT, on its own, doesn't provide security. At best, it provides obscurity. At worst, it breaks security [2]. NAT needs a properly configured firewall to provide security [1]. In this sense, NAT vs a Firewall is a false dichotomy.
[1] https://tailscale.com/blog/how-nat-traversal-works/
[2] https://www.computerworld.com/article/2556611/nat-traversal-...
edit: formatting
Also, GP claimed that certain services that don't work because of NAT would work on an IPv6 network. I was curious which services those might be, that don't work because of NAT but wouldn't be affected by a firewall.
You need a defense at depth, not a crunchy perimeter with a squishy inside.
A feature? I’ve never heard that. If you want to break the end to end nature of the net you can do that in your router, easily and more powerfully, without all the overhead of NAT.
The net has turned back to the old mainframe days, and things like NAT make it hard to go the other way.
It was in the parent comment!
If you wanna block inbound connections, just drop them with your firewall. Most home routers already do this by default and if yours doesn’t, you better enable it for IPv4 too.
I’ve never accidentally let something through NAT.
But accidentally not configuring a firewall? Everyone does that and has done that and will forever do it.
At that point having a default drop on the external interface and different rules for traffic traversing VLAN's is entirely possible, in fact that is what it is designed and built to do.
Sysadmins/server engineering/DevOps/SRE, Networks, and Security are usually hard silos at big companies.
"DevOps" gets a request from an app team to open a port between subnet A and subnet B.
DevOps asks Networks to do it. Security needs to approve it before Networks can do it (usually). A cohort of VPs somewhere need to approve it if those subnets are "production" (i.e. subject to serious fines if the data therein fails audit).
Networks outsources the request to their global services team in India/Phillippines/China/Brazil since it's literally a single command, but they are done in bulk. These changes are only done afterhours, partly because of outsourcing latency, partly because of regulations.
The firewall person types in the wrong port. Emergency change request gets filed to fix. Fixed in 1-3 days after the CTO/CIO and some SVPs approve it (and maybe yells at people for wasting their time).
The requester asks for the wrong port. Too bad, so sad, you're waiting another week.
The app team asked for the wrong port. Same outcome as the DevOps person.
From a quick search, UPnP seems capable of automating this for user convenience, especially with stateless addressing.
Odds are that there weren't many people in a position to connect to you, and probably nobody actually did so, but it would certainly have been possible without a firewall in place.
If I want to open up a device with a single port, I should open that in the firewall. But wait, my IPv6 addresses aren’t stateful, so they can change any time.
And then suddenly someone decides to just open port 80 and 443 on the main router, and bam! I’ve just opened up those ports for _all_ IPv6 clients in my LAN.
You think all those IP cameras and ring doorbells were vulnerable when they are behind a NAT? Just wait what happens when they all get assigned public IPv6 addresses.
I’m not saying that these problems are unsolvable. But I think it’s important to at least recognize that, yes, this is different than how we did things with NAT, and you now have more tools to shoot yourself in the foot with.
And the tools for managing IPv6 firewall rules suck on "SMB grade" stuff like ubiquiti and are virtually non-existant on any consumer grade router. If I have to SSH into the router and treat it like a "real" router to set up IPv6 firewall rules... it is never gonna fly for anybody who isn't proficient with "real" routers (i.e. >99% of the world).
Hell I'm pretty sure comcast's cable modem doesn't even have IPv6 firewall capabilities and if they do it is default wide open. Thats not what I want. I have no interest in outsiders being able to ping hosts on my network or even know of their existence. I have no interest in letting random IoT devices expose open ports to the entire world (by default).
IPv6 is cool and all, but no consumer gear sets it up even remotely secure. At least with NAT a "script kiddy" grade attacker won't see what is behind your router. NAT isn't perfect but it solves a lot of problems. Not so with IPv6.
Honestly I just don't really see IPv6 replacing IPv4. It introduces too many problems and offers too little benefit. Whatever actually replaces IPv4 will either need to be 10x better than IPv4 in every way or be a completely transparent migration that works with IPv4 "but with more addresses".
Comcasts cable modem also doesn't have any firewall for IPv4... it's a cable modem, it passes packets.
Your CPE (customer premises endpoint) is where the firewall lives.
> IPv6 is cool and all, but no consumer gear sets it up even remotely secure. At least with NAT a "script kiddy" grade attacker won't see what is behind your router. NAT isn't perfect but it solves a lot of problems. Not so with IPv6.
Most newer consumer gear that does IPv6 blocks all in-bound traffic on IPv6, just like it does on IPv4.
Most of the new stuff comcast ships is an "all in one" device that acts as an access point, a router and a cable modem. You can buy third party cable modems that do what you describe but what comcast gives you is much more fancy.
That said, the relevant part is the router (which may be part of the same physical device these days), and that part certainly does have both a v4 and a v6 firewall, configured securely for both.
Umm, the IPv6 firewall interface is exactly the same as the IPv4 firewall interface on UniFi[1].
For the more general user case ("I want to host a game session with my friend") I'm not sure if there is something like UPnP for dynamically registering allowed ports without needing to actually do any NAT work but that would certainly seem useful.
From that article written in 2014, these OSes have privacy extensions enabled by default:
- All versions of Windows after Windows XP
- All versions of Mac OS X from 10.7 onward
- All versions of iOS since iOS 4.3
- All versions of Android since 4.0 (ICS)
- Some versions of Linux (and for others it can be easily configured)
Mine at home is configured to change every 30 minutes.
With the amount of legacy applications and systems populating the typical internal network that idea won't be going far.
Where IPv6 actually can be used and should be deployed in addition to v4 is in the perimeter networks. Offering or being able to use services on the internet over v6 (via proxy) overcomes the real shortage of ipv4 addresses in the internet at large.
I expect internal networks to be last places to be moved to IPv6 only.
Edge Firewalls -- source natting to allow access to IPv4 networks
Edge Firewalls -- destination natting to allow access from IPv4 to a service hosted on IPv6
Doesn't seem to widely adopted. It's all dual stack stuff, which means more work and more things to go wrong for no benefit.
Of course there's then the renumbering of your entire internal network every time you change ISP because you're using public IPs rather than private ones
For example, did you know that NAT doesn't prevent inbound connections? At least in v6 people are more likely to realize that, yes, they do need a firewall.