This is a Canonical Question about IPv6 and NAT
Related:
So our ISP has set up IPv6 recently, and I've been studying what the transition should entail before jumping into the fray.
I've noticed three very important issues:
Our office NAT router (an old Linksys BEFSR41) does not support IPv6. Nor does any newer router, AFAICT. The book I'm reading about IPv6 tells me that it makes NAT "unnecessary" anyway.
If we're supposed to just get rid of this router and plug everything directly to the Internet, I start to panic. There's no way in hell I'll put our billing database (With lots of credit card information!) on the internet for everyone to see. Even if I were to propose setting up Windows' firewall on it to allow only 6 addresses to have any access to it at all, I still break out in a cold sweat. I don't trust Windows, Windows' firewall, or the network at large enough to even be remotely comfortable with that.
There's a few old hardware devices (ie, printers) that have absolutely no IPv6 capability at all. And likely a laundry list of security issues that date back to around 1998. And likely no way to actually patch them in any way. And no funding for new printers.
I hear that IPv6 and IPSEC are supposed to make all this secure somehow, but without physically separated networks that make these devices invisible to the Internet, I really can't see how. I can likewise really see how any defences I create will be overrun in short order. I've been running servers on the Internet for years now and I'm quite familiar with the sort of things necessary to secure those, but putting something Private on the network like our billing database has always been completely out of the question.
What should I be replacing NAT with, if we don't have physically separate networks?
First and foremost, there is nothing to fear from being on a public IP allocation, so long as your security devices are configured right.
The same thing we've been physically separating them with since the 1980's, routers and firewalls. The one big security gain you get with NAT is that it forces you into a default-deny configuration. In order to get any service through it, you have to explicitly punch holes. The fancier devices even allow you to apply IP-based ACLs to those holes, just like a firewall. Probably because they have 'Firewall' on the box, actually.
A correctly configured firewall provides exactly the same service as a NAT gateway. NAT gateways are frequently used because they're easier to get into a secure config than most firewalls.
This is a misconception. I work for a University that has a /16 IPv4 allocation, and the vast, vast majority of our IP address consumption is on that public allocation. Certainly all of our end-user workstations and printers. Our RFC1918 consumption is limited to network devices and certain specific servers where such addresses are required. I would not be surprised if you just shivered just now, because I certainly did when I showed up on my first day and saw the post-it on my monitor with my IP address.
And yet, we survive. Why? Because we have an exterior firewall configured for default-deny with limited ICMP throughput. Just because 140.160.123.45 is theoretically routeable, does not mean you can get there from wherever you are on the public internet. This is what firewalls were designed to do.
Given the right router configs, and different subnets in our allocation can be completely unreachable from each other. You do can do this in router tables or firewalls. This is a separate network and has satisfied our security auditors in the past.
Our billing database is on a public IPv4 address, and has been for its entire existence, but we have proof you can't get there from here. Just because an address is on the public v4 routeable list does not mean it is guaranteed to be delivered. The two firewalls between the evils of the Internet and the actual database ports filter out the evil. Even from my desk, behind the first firewall, I can't get to that database.
Credit-card information is one special case. That's subject to the PCI-DSS standards, and the standards state directly that servers that contain such data have to be behind a NAT gateway1. Ours are, and these three servers represent our total server usage of RFC1918 addresses. It doesn't add any security, just a layer of complexity, but we need to get that checkbox checked for audits.
The original "IPv6 makes NAT a thing of the past" idea was put forward before the Internet boom really hit full mainstream. In 1995 NAT was a workaround for getting around a small IP allocation. In 2005 it was enshrined in many Security Best Practices document, and at least one major standard (PCI-DSS to be specific). The only concrete benefit NAT gives is that an external entity performing recon on the network doesn't know what the IP landscape looks like behind the NAT device (though thanks to RFC1918 they have a good guess), and on NAT-free IPv4 (such as my work) that isn't the case. It's a small step in defense-in-depth, not a big one.
The replacement for RFC1918 addresses are what are called Unique Local Addresses. Like RFC1918, they don't route unless peers specifically agree to let them route. Unlike RFC1918, they are (probably) globally unique. IPv6 address translators that translate a ULA to a Global IP do exist in the higher range perimeter gear, definitely not in the SOHO gear yet.
You can survive just fine with a public IP address. Just keep in mind that 'public' does not guarantee 'reachable', and you'll be fine.
2017 update
In the past few months, Amazon aws has been adding IPv6 support. It has just been added to their amazon-vpc offering, and their implementation gives some clues as to how large scale deployments are expected to be done.
To add one of the security benefits of NAT back in, they are now offering an Egress-only Internet Gateway. This offers one NAT-like benefit:
Which provides a layer of defense-in-depth, in case a misconfigred firewall rule accidentally allows inbound traffic.
This offering does not translate the internal address into a single address the way NAT does. Outbound traffic will still have the source IP of the instance that opened the connection. Firewall operators looking to whitelist resources in the VPC will be better off whitelisting netblocks, rather than specific IP addresses.
Routeable does not always mean reachable.
1: The PCI-DSS standards changed in October 2010, the statement mandating RFC1918 addresses was removed, and 'network isolation' replaced it.
IPv6 is supported by many routers. Just not that many of the cheap ones aimed at consumers and SOHO. Worst case, just use a Linux box or re-flash your router with dd-wrt or something to get IPv6 support. There are many options, you probably just have to look harder.
Nothing about a transition to IPv6 suggests you should get rid of perimeter security devices, like your router/firewall. Routers and firewalls will still be a required component of pretty much every network.
All NAT routers effectively act as a stateful firewall. There is nothing magic about the use of RFC1918 addresses that protect you all that much. It is the stateful bit that does the hard work. A properly configured firewall will protect you just as well if you are using real or private addresses.
The only protection you get from RFC1918 addresses is that allows people to get away with errors/laziness in your firewall config and still not be all that vulnerable.
So? It is hardly likely that you will need to make that available over the Internet, and on your internal network, you can continue to run IPv4, and IPv6 until all your devices are supported or replaced.
If running multiple protocols is not an option you may have to setup some kind of gateway/proxy.
IPSEC encrypted and authenticates packets. It has nothing to do with getting rid of your border device, and has more protecting the data in transit.
Yes. NAT is dead. There have been some attempts to ratify standards for NAT over IPv6 but none of them ever got off the ground.
This has actually caused issues for providers who are attempting to meet PCI-DSS standards, as the standard actually states that you must be behind a NAT.
For me, this is some of the most wonderful news I've ever heard. I hate NAT, and I hate carrier-grade NAT even more.
NAT was only ever meant to be a bandaid solution to get us through till IPv6 became standard, but it became ingrained into the internet society.
For the transition period, you have to remember that IPv4 and IPv6 are, apart from a similar name, are totally different 1. So devices that are Dual-Stack, your IPv4 will be NATted and your IPv6 will not. It's almost like having two totally seperate devices, just packaged into the one piece of plastic.
So, how does IPv6 internet access work? Well, the way the internet used to work before NAT was invented. Your ISP will assign you an IP range (same as they do now, but they generally assign you a /32, which means that you only get one IP address), but your range will now have millions of available IP addresses in it. You are free to populate these IP addresses as you chose (with auto-configuration or DHCPv6). Each one of these IP addresses will be visible from any other computer on the internet.
Sounds scary, right? Your domain controller, home media PC and your iPhone with your hidden stash of pornography are all going to be accessable from the internet?! Well, no. That's what a firewall is for. Another great feature of IPv6 is that it forces firewalls from an "Allow All" approach (as most home devices are) into a "Deny All" approach, where you open up services for particular IP addresses. 99.999% of home users will happily keep their firewalls default and totally locked down, which means that no un-solicited trafffic will be allowed in.
1Ok there's way more to it than that, but they are in no way compatible with each other, even though they both permit the same protocols running on top
The PCI-DSS requirement for NAT is well known to be security theater and not actual security.
The most recent PCI-DSS has backed off from calling NAT an absolute requirement. Many organizations have passed PCI-DSS audits with IPv4 without NAT showing stateful firewalls as "equivalent security implementations".
There are other security theater documents out there calling for NAT, but, because it destroys audit trails and makes incident investigation/mitigation more difficult, a more in-depth study of NAT (with or without PAT) to be a net security negative.
A good stateful firewall without NAT is a vastly superior solution to NAT in an IPv6 world. In IPv4, NAT is a necessary evil to be tolerated for the sake of address conservation.
There is a huge amount of confusion about this subject, as network administrators see NAT in one light, and small business and residential customers see it in another. Let me clarify.
Static NAT (sometimes called one-to-one NAT) offers absolutely no protection for your private network or an individual PC. Changing the IP address is meaningless as far as protection is concerned.
Dynamic Overloaded NAT/PAT like what most residential gateways and wifi AP's do absolutely helps protect your private network and/or your PC. By design the NAT table in these devices is a state table. It keeps track of outbound requests and maps them in the NAT table--the connections time out after a certain amount of time. Any unsolicited inbound frames that don't match what's in the NAT table are dropped by default--the NAT router doesn't know where to send them in the private network so it drops them. In this way, the only device you are leaving vulnerable to being hacked into is your router. Since most security exploits are Windows based--having a device like this between the internet and your Windows PC's really helps protect your network. It may not be the originally intended function, which was to save on public IP's, but it gets the job done. As a bonus, most of these devices also have firewall capabilities that many times block ICMP requests by default, which also helps protect the network.
Given the above information, disposing with NAT when moving to IPv6 could expose millions of consumer and small business devices to potential hacking. It will have little to no affect on corporate networks as they have professionally managed firewalls at their edge. Consumer and small business networks may possibly no longer have a *nix based NAT router between the internet and their PC's. There is no reason that a person couldn't switch to a firewall only solution--much safer if deployed correctly, but also beyond the scope of what 99% of consumers understand how to do. Dynamic Overloaded NAT gives a modicum of protection just by using it--plug in your residential router and you are protected. Easy.
That said, there is no reason that NAT couldn't be used in the exact same way it is being used in IPv4. In fact, a router could be designed to have one IPv6 address on the WAN port with an IPv4 private network behind it that NAT's onto it(for example). This would be a simple solution for consumer and residential people. Another option is to put all devices with public IPv6 IP's--- the intermediate device then could act as a L2 device, but provide a state table, packet inspection, and fully functioning firewall. Essentially, no NAT, but still blocking any unsolicited inbound frames. The important thing to remember is that you shouldn't plug your PC's directly into your WAN connection with no intermediary device. Unless of course you want to rely on the Windows firewall. . . and that's a different discussion. Every network, even home networks, need an edge device protecting the local network, in addition to using the Windows firewall.
There will be some growing pains moving to IPv6, but there isn't any problem that won't be able to be resolved fairly easily. Will you have to ditch your old IPv4 router or residential gateway? Maybe, but there will be inexpensive new solutions available when the time comes. Hopefully many devices will just need a firmware flash. Could IPv6 been designed to fit more seamlessly into the current architecture? Sure, but it is what it is and it's not going away--So you might as well learn it, live it, love it.
RFC 4864 describes IPv6 Local Network Protection, a set of approaches for providing the perceived benefits of NAT in an IPv6 environment, without actually having to resort to NAT.
It first lays out what the perceived benefits of NAT are (and debunks them when appropriate), then describes the features of IPv6 which can be used to provide those same benefits. It also provides implementation notes and case studies.
While it's too long to reprint here, the benefits discussed are:
This pretty much covers all the scenarios in which one might have wanted NAT and offers solutions for implementing them in IPv6 without NAT.
Some of the technologies you will use are:
(See the RFC for complete details; again, it's much too long to reprint or even take significant excerpts from.)
For a more general discussion of IPv6 transition security, see RFC 4942.
It will (sadly) be a while before you can get away with a single-stack IPv6-only network. Until then, dual-stack with preference for IPv6 when available is the way to run.
While most consumer routers don't support IPv6 with stock firmware today, many can support it with 3rd-party firmwares (eg, Linksys WRT54G with dd-wrt, etc.). Also, many business-class devices (Cisco, Juniper) support IPv6 out-of-the-box.
It's important not to confuse PAT (many-to-one NAT, as is common on consumer routers) with other forms of NAT, and with NAT-free firewalling; once the internet becomes IPv6-only, firewalls will still prevent exposure of internal services. Likewise, an IPv4 system with one-to-one NAT is not automatically protected; that's the job of a firewall policy.
If NAT survives in the IPv6 world, it'll most likely be 1:1 NAT. A form a NAT never seen in IPv4 space. What is 1:1 NAT? It's a 1:1 translation of a global address to a local address. The IPv4 equivalent would be translating all connections to 1.1.1.2 only to 10.1.1.2, and so on for the entire 1.0.0.0/8 space. The IPv6 version would be to translate a global address to a Unique Local Address.
Enhanced security could be provided by frequently rotating the mapping for addresses that you don't care about (like internal office users browsing Facebook). Internally, your ULA numbers would stay the same so your split-horizon DNS would continue to work just fine, but externally clients would never be on a predictable port.
But really, it's a small amount of improved security for the hassle it creates. Scanning IPv6 subnets is a really large task and is infeasible without some recon on how IP addresses are assigned on those subnets (MAC-generation method? Random method? Static assignment of human-readable addresses?).
In most cases, what'll happen is that clients behind the corporate firewall will get a global address, maybe a ULA, and the perimeter firewall will be set to deny all incoming connections of any kind to those addresses. For all intents and purposes, those addresses are unreachable from the outside. Once the internal client initiates a connection, packets will be allowed through along that connection. The need to change the IP address to something completely different is handled by forcing an attacker to thumb through 2^64 possible addresses on that subnet.
Kind of. There's actually different "types" of IPv6 addresses. The closest to RFC 1918 (10/8, 172.16/12, 192.168/16) is called "Unique local address" and is defined in RFC 4193:
http://en.wikipedia.org/wiki/Unique_local_address
So you begin with fd00::/8, then add a 40-bit string (using a pre-defined algorithm in the RFC!), and you end up with a pseudo-random /48 prefix that should be globally unique. You have the rest of the address space to assign however you want.
You should also block fd00::/7 (fc00::/8 and fd00::/8) at your (IPv6) router to outside of your organization—hence the "local" in the address name. These addresses, while in the global address space, should not be reachable to the world at large, just with-in your "organization".
If your PCI-DSS servers need an IPv6 for connectivity to other internal IPv6 hosts, you should generate an ULA prefix for your company and use it for this purpose. You can use IPv6's auto-config just like any other prefix if you wish.
Given that IPv6 was designed so that hosts can have multiple addresses, a machine can have—in addition to a ULA—a globally routable address as well. So a web server that needs to talk to both the outside world, and to internally machines, can have both an ISP-assigned prefex address and your ULA prefix.
If you want NAT-like functionality you can look at NAT66 as well, but in general I'd architect around ULA. If you have further questions you may want to check out the "ipv6-ops" mailing list.
IMHO: not.
There are still some places where SNAT/DNAT can be usefull. For expample some servers were moved to another network, but we don't want/we can't change IP of application.