You are here: Home > Publications > RIPE Labs > Mirjam Kühne > The Trouble with NAT - Part 3
Content by this author

The Trouble with NAT - Part 3

Mirjam Kühne — 27 Oct 2016
This is the final post in a series on Network Address Translation (NAT), provided by Mark Smith. In this post, Mark discusses the fundamental constraints of NAT and addresses some FAQs about IPv6 without NAT.

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.

1 Comment

Ágoston Horváth says:
15 Dec, 2016 10:55 AM
There are still a few topics you did not mention.

- load balancing/virtual IP. In ipv6, two hosts on the same subnet can not have the same IP; if they do, neighbor discovery would disable it on all but one. You need a whole different approach to low-cost/masterless load balancing.

- NAT hiding the IPs behind does have a valuable boost on privacy. Indeed, you can still distinguish unique clients via other means, but it does remove the most glaring way to do so.

- Re-assigning IPs all the time makes firewall more complex, as anything can change.

- Generally, I consider the semi-intelligent nature of the IPv6 network a disadvantage. It makes configuration more complex compared to v4, with a steep learning curve, and all for something that is prone to change. Ipv4 being static did have an advantage of better control and overview by sysadmins. E.g. even a simple packet monitoring is now disrupted by ipv6 traffic and reconfiguration.

Overall I think that injecting _a lot_ more than just extended address space into ipv6 was a mistake, that has an effect is very slow transition that is observed right now. Effectively, people would hold out migrating to ipv6 unless absolutely necessary. That alone is a feedback that it is not considered a distant advantage.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.