Please also see the two earlier posts in this series: The Trouble with NAT - Part 1 or Network Critical Success Factors (NCSFs) and The Trouble with NATs - Part 2.

The fundamental constraint of NAT

Hopefully, you’ve read my first two posts on NAT. Thanks for sticking with it!  The points raised in those posts lead to the question of the fundamental constraint of NAT. It can be stated simply as:

The fundamental constraint of NAT is that it prevents IP nodes attached to the same network from acting as peers of each other.

IPv6 without NAT

Many people, when they hear that IPv6 is not intended to be deployed with NAT, become quite concerned. NAT has provided some useful benefits when used in the IPv4 Internet, and as they may not have experienced an IPv4 Internet without NAT, cannot see how they can retain those benefits without deploying NAT when they also deploy IPv6.

The IETF v6ops working group realised this concern nearly a decade ago, and prepared and published an Informational RFC that enumerates the benefits that IPv4 NAT has provided and then describes IPv6 alternatives that do not rely on address translation of IPv6 addresses.

The observation is that while NAT provided those benefits in an IPv4 Internet, they aren’t intrinsic to NAT – they’re side effects of NAT that have been beneficial, however they do not require address translation to be performed to achieve them.

There are also a few FAQs (or perhaps Frequently Argued Disagreements!) about IPv6 without NAT that are worth covering here. RFC4864 covers them in detail.

FAQ: Renumbering

IPv4 NAT creates a separate internal addressing domain from the external, typically global Internet addressing domain. This separation allows the attachment to the external Internet addressing domain’s addressing to be changed without needing to renumber the internal addressing domain.

This can be facilitated in IPv6, without using NAT, using two of the key differences between IPv4 and IPv6 – an IPv6 host (or more specifically, an interface) formally supports multiple concurrent IPv6 addresses, and supports address ageing and expiry through address lifetimes.

For internal connectivity, the IPv6 Unique Local Address space (RFC4193) is used for local or internal connectivity. The ULA address space (FC00::/7) is fairly similar to IPv4’s RFC1918 address space, except that it incorporates a 41-bit pseudo random number, forming a /48, that is intended to be likely globally unique (if a single /48 isn’t large enough for the Network, multiple different ULA /48s can be generated and used). This global uniqueness allows multiple ULA domains to be merged, such as when two different companies merge, without requiring either renumbering or the use of NAT at the edge of the two different ULA domains.

For external connectivity to the Internet, Hosts’ interfaces will also have IPv6 Global Unicast Addresses (GUA) from within one or more prefixes supplied by one or more upstream ISPs or an RIR. If the attachment to the Internet needs to be changed, a new GUA prefix can be deployed in parallel to the existing one using a phased approach, over a time period of weeks or possibly months, rather than having a single large addressing cut-over event. The being-replaced GUA prefix will not be refreshed and will eventually expire.

Some future developments may further facilitate this sort of event, such as Multipath TCP (MPTCP) (RFC6824) and Source Address Dependent Routing (SADR) (ID:draft-bowbakova-rtgwg-enterprise-pa-multihoming).

FAQ: NAT Provides Stateful Firewalling

As discussed, performing NAT requires the creation of State in the NAT device. If a packet is received by the NAT device on the external interface and corresponding NAT State does not exist, the packet will be dropped. Inherently, this provides a firewalling capability to the network residing behind the NAT device.

It is not necessary to perform address translation to have a device perform stateful firewalling. The Linux kernel IPv6 netfilter/iptables implementation is an example of IPv6 stateful firewalling that doesn’t require performing address translation.

FAQ: NAT Hides Devices

I think what people are really saying is “NAT hides devices from unsolicited inbound address probes”. Devices aren’t hidden from other methods of discovery such as HTTP cookies or addresses and other identifiers that are leaked in other places in the protocols they are using.

Network and/or Host stateful or stateless inbound firewalls or packet filters can help “hide” IPv6 devices from unsolicited inbound address probes.

IPv6 addressing schemes such as privacy addressing (RFC4941) and stable opaque addressing (RFC7217) also make devices practically impossible to discover via unsolicited inbound probing.

FAQ: NAT Hides Internal Topology

Stateful or stateless firewalling/packet filtering can be used to block packets that are typically used to discovery internal topology, such as those used by traceroute.

RFC4864 mentions using host routes for small sites and Mobile IPv6 for larger ones.

Another option is various forms of tunnelling of IPv6 over IPv4, that make all of the IPv6 devices appear where the tunnelling concentrator is located. An example is ISATAP (Intra-Site Automatic Tunnel Addressing Protocol, RFC5214), which makes all of the IPv6 devices attached to an IPv4 network appear to come from the same single IPv6 /64.

Convinced?

Perhaps not?

I think picking the right technology to use to solve a problem involves being aware of not only the benefits of the technology but also its limitations, and the trade-offs you’ll have to make if you use it. NAT has a number of significant limitations which I hope I’ve explained well enough here, and, based on my experiences with NAT since 1996, I’d much rather not see it deployed in networks running IPv6.

Some Further Reading

Many RFCs directly or indirectly cover NAT, its limitations and related topics such as the consequences of duplicated address spaces attached to the same network. I think they’re worth a read.

• RFC1627, “Network 10 Considered Harmful (Some Practices Shouldn’t be Codified)”
• RFC1958, “Architectural Principles of the Internet”
• RFC2775, “Internet Transparency”
• RFC2993, “Architectural Implications of NAT”
• RFC3439, “Some Internet Architectural Guidelines and Philosophy”
• RFC3879, “Deprecating Site Local Addresses”
• RFC4924, “Reflections on Internet Transparency”
• RFC5902, “IAB Thoughts on IPv6 Network Address Translation”

Mark Smith is a network engineer. He has worked at a number of networked organisations since the early 1990s, including a number of residential and corporate ISPs. Most recently he has been working in the AMI/Smartgrid sector.

This article was originally published on the APNIC blog.