Plain talk about the Advantages and Disadvantages of NAT
By Owen DeLong and Scott Hogg
Synopsis:
Dual stack is the most preferred IPv6 transition strategy and tunneling IPv6 packets within IPv4 packets is considered less optimal.
Of all the IPv6 transition techniques that exist, “Translation” is considered the least attractive.
IPv6 purists and protocol designers have long resisted the idea of allowing NAT for IPv6.
Yet today there is a function called Network Prefix Translation (NPT) which is similar to NAT, but different.
This article goes into detail about the reasons to use NAT, the disadvantages NAT brings, and seeks to help the reader make an informed decision about what is right for their particular environment.
Introduction:
You may have seen this popular and amusing video on this subject: http://www.youtube.com/watch?v=v26BAlfWBm8 hits remarkably close to the mark. IPv6 proponents have significantly resisted allowing NAT to be used with IPv6. The fear is that there would be demand for a system similar to what is used for IPv4 where many private IPv4 addresses are hidden behind a single public IPv4 address (Technically known as NAPT (Network Address and Port Translation, or PAT (Port Address Translation) for short). The concern is that PAT would ruin the end-to-end model that IPv6 has so long hoped to restore. The original intent of IP communications was that hosts would communicate directly using their assigned IP addresses. Since translation changes the source address of the packet on its way to the destination, the destination is not communicating with the original source address. This type of PAT system is not needed for IPv6 because there is no scarcity of IPv6 addresses.
Are there Private addresses for IPv6?
IPv4 has RFC-1918 addresses that can be used in private networks isolated from the Internet. IPv6 also provides for a type of “private” addressing. Unique Local Addresses (ULA) are addresses that an organization can use for non-Internet communications on private networks.
Unique Local Addresses (ULA) are documented here: http://tools.ietf.org/html/rfc4193. This FC00::/7 address block has been allocated by the Internet Assigned Number Authority (IANA) and is broken into FC00::/8 which is reserved and FD00::/8 which organizations can use internal to their organizations. The RFC stipulates that organizations must generate a 40-bit random number to fill in the bits after the “FD” hex digits. The first 8 bits for “FD” (1111 1101) combined with the 40-bit random number provide for a /48 prefix that can be sub-netted and used inside an organization’s internal networks.
The generation of the random number should prevent any possible conflicts between organizations who are also using ULA space internally. The random number gives the “unique” aspect of unique-local. Therefore, two organizations can collaborate or merge and there probably won’t be any address overlap situations like occur today with RFC-1918 IPv4 addresses.
Limitations/restrictions of ULA space are similar to the usage limitations of RFC-1918 addresses. They can be routed between organizations by agreement, but should not generally be leaked into internet routing tables. As noted above, they do not suffer from the limitation on uniqueness that RFC-1918 addresses have. These ULA addresses are only intended to be used internally and never used for Internet communications. Hence the word “Local” in the ULA name.
When might NAT be useful for IPv6?
IPv6 was originally intended to use a completely hierarchical addressing system where organizations received their IPv6 addresses from their service providers. However, that didn’t easily allow for multi-homing to multiple ISPs. Many enterprise organizations use BGP today to advertize their own public IPv4 addresses to multiple ISPs and have independence. That hierarchical addressing requirement has been lifted and organizations may be granted Provider Independent (PI) IPv6 address blocks if they meet the requirements by the Regional Internet Registry (RIR). PI IPv6 addresses used with BGP for multi-homing just like an organization’s public IPv4 addresses. Each RIR has their own specific requirements. As an example, to qualify in the ARIN region, you must meet one of the following criteria:
- Operate critical Infrastructure (Root nameservers, Exchange points, etc.)
- Be multi-homed or immediately becoming multi-homed. (Hold an ASN and 2 or more peering or transit contracts)
- Have a network that makes active use of at least 2000 IPv6 addresses within 12 months
- Have a network that makes active use of at least 200 /64 subnets within 12 months
- Provide a reasonable technical justification indicating why provider assigned addresses would be unsuitable to your application.
However, smaller organizations that only have a single ISP today will likely be granted only Provider Assigned (PA) IPv6 addresses from that ISP’s block. These smaller organizations will be forced with IPv6 re-addressing if they chose to switch service providers. Customers may need to quickly switch service providers and may not have ample time to renumber. However, IPv6 does make it relatively easy to run multiple sets of addresses in parallel, so if you have any warning of an ISP change and can deploy the new addresses early in the process, there are very good tools for managing the deprecation of the old addresses in an orderly fashion. In other words, readdressing an IPv6 environment is easier than readdressing an IPv4 environment.
Some organizations today use multiple upstream ISPs and obtain IPv4 address blocks from each of those ISPs. They use these public IPv4 addresses on the external interfaces of their firewalls to PAT outbound connections. Their internal network systems use private IPv4 addresses and exit to the Internet through one of these Internet egress points using PAT. Their IPv4 address comes back symmetrically due to the use of public IPv4 addresses from the ISPs. These organizations are multi-homed, but are not using BGP, do not have their own IPv4 addresses, and are relying on NAT as a somewhat limited substitute for BGP routing. These organizations will not have the same functionality with IPv6 because there is no PAT-like function defined for IPv6. However, any such organization would easily qualify for IPv6 Provider Independent (PI) addresses and setting up a minimal BGP connection is no longer very difficult. Any organization in this situation should seriously consider moving to BGP routing as it is the most flexible solution and does not have to be expensive or difficult, contrary to popular belief.
However, if address translation is required in your environment, the IPv6 version is known as “Network Prefix Translation” (NPT) and is documented here: http://tools.ietf.org/html/rfc6296
In NPT, only the prefix (e.g. The /48) is translated and not the subnet or interface identifier. For example, if you have an internal range of fd20:010d:08b5::/48 and an external prefix from your first provider of 2001:db8:beef::/48 and your second provider gives you 2001:db8:cafe::/48 and you have a host which internally is numbered fd20:010d:08b5:babe::8:beef, the external presentation of that host to provider 1 would be 2001:db8:beef:babe::8:beef and to provider 2 would be 2001:db8:cafe:babe::8:beef. Notice only the first 48 bits changed from the internal representation. The remaining digits remained identical.
NPT is not called NAT66, in an effort to avoid confusion with PAT-based NAT44, since NPT operates significantly differently from PAT. NPT performs a one-to-one mapping of IPv6 addresses. It does not provide overloading like IPv4 PAT and it does not use a “pool” of public addresses. NPT can provide increases security and forensics because of the one-to-one mapping due to the large amount of available IPv6 addresses. IPv4 could not use a system like this because IPv4 addresses are becoming increasingly more scarce.
The challenge today is that many network devices do not yet support NPT for IPv6. Manufacturers of routers and firewalls have many IPv6 features, but they have yet to include NPT as one of their default options. However, it is likely that in the next year, manufacturers of routers and firewalls will integrate NPT into their software.
What about the security I get from NAT?
Many people who learn about how IPv6 will be deployed to residential broadband CPE devices are concerned about the fact that their internal systems will receive public IPv6 addresses. They are concerned that this is leaving them open to attack from the Internet. NAT has been used in IPv4 environments for “topology hiding” of the internal IPv4 addressing because the systems on the Internet only see the source address of the NAT pool or the PAT system’s single public IPv4 address. IPv6 makes this irrelevant, topology hiding is not a necessity. IPv6 address space is so immense that tracking one system’s source address, particularly if it changes periodically, is a difficult task. Just like the IPv6 nodes are sparsely scattered within a single /64 subnet, IPv6 subnets are also sparsely allocated.
More general information on Local Network Protection for IPv6 RFC 4864 is documented here: http://tools.ietf.org/html/rfc4864
In reality, it is important to develop a better understanding of how “NAT Security” actually works in a home gateway. There are two components to PAT. One (the component that provides security) is a stateful correlation of inbound packets to existing outbound flows. The second component is the one that rewrites parts of the header based on the contents of those state tables (which doesn’t actually provide any security at all). The first part is technically known as “stateful inspection”. Technically NAT or PAT refers only to the second component (the rewriting of the packet header), but because NAT/PAT requires stateful inspection to operate, the terms are often used to refer to the combined process. Unfortunately, this has created the false perception that NAT/PAT provide security.
Stateful Inspection (the part that provides the security) is readily available in most IPv6 Customer Premise devices, but you should make sure that your device has it. With stateful inspection, your public addresses are every bit as safe as your private addresses were in IPv4.
The reality is that the CPE, local gateway will still perform stateful filtering and prevent inbound Internet connections. The Cable Modem with embedded router (eRouter) or Linksys/D-Link/NetGEAR device that the subscriber purchased will allow upstream connections that were initiated from the internal home network but it would prevent unsolicited inbound connections from the Internet. The CPE router will still act as a “stateful” firewall even though the IPv6 addresses allocated to the home use global unicast addresses. Following are two RFCs that govern how CPE devices do not use NAT/PAT for IPv6 in the same way NAT/PAT is used for IPv4.
Basic Requirements for IPv6 Customer Edge Routers, RFC 6204, http://tools.ietf.org/html/rfc6204
Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service, RFC 6092, http://tools.ietf.org/html/rfc6092
How do ISP’s assign addresses to customers?
For dedicated Internet connectivity customers, an ISP may elect to allocate the customer with a /48 Provider Assigned (PA) IPv6 block from the ISP’s /32-or-larger IPv6 block. DHCPv6 Prefix Delegation (PD) is used as the method to allocate global unicast IPv6 prefixes to the subscriber’s CPE device for use internal to that subscriber’s location. The prefix delegated to the customer could be as large as a /48, which provides for significant flexibility and future-proofing on the end-user side, or any longer value up to a single /64 which would be the most restrictive (only one subnet) value that can be given to an end-user. Service providers could elect to allocate a single /64 for residential broadband subscribers and allocate larger prefixes up to and including a /48 for their business-class customers. The challenge today is that may consumer-grade CPE devices only support receiving a single /64 prefix which restricts the number of subnets a customer can have within their location. Consumer electronics manufacturers are continuing to educating themselves about IPv6 and will be producing products capable of IPv6 subneting.
What about cross-protocol Translation?
Running IPv4 and IPv6 simultaneously (dual-stack) is the preferred transition strategy. However, it is not always feasible to deploy IPv6 this way. Tunneling IPv6 packets over through an IPv4 cloud is less optimal, but can be used as a last resort method. Translating IPv6 and IPv4 packets is considered undesirable but it is ironic that there is so much effort being put into translation techniques.
There are many forms of translation intended for “transition”. Most of them do more to hinder transition than help in most circumstances. A detailed discussion of these is out of scope for this document, but if you want to find more information, search for one or more of the following terms:
Summary
Even though Network Prefix Translation (NPT) exists, your organization should be using global IPv6 addresses and relying on stateful packet filtering and other diverse approaches for security. NAT66 does not exist and you do not need PAT for IPv6 because there is no scarcity of IPv6 addresses. You will be able to provide the same security for IPv6 Internet communications as you do today for IPv4 and you will have a simpler environment to maintain with the use of NAT. Without NAT for IPv6, end-to-end communications will be much easier to troubleshoot using public addresses for the source and destination systems.
Owen DeLong and Scott Hogg
