RFC 3235

Network Address Translator (NAT)-Friendly Application Design Guidelines

📅 published January 2002, from ietf

RFC 3235: Network Address Translator (NAT)-Friendly Application Design Guidelines ✨

okay bestie, RFC 3235 is literally a whole guide for app designers who want their stuff to work with NAT 🎀. It came out in January 2002 from the Network Working Group, written by D. Senie at Amaranth Networks Inc. Its category is Informational, so it's giving "here's some info for the Internet community" and NOT an actual standard 📚. The title block doesn't list anything it obsoletes or updates, so it's a solo main character 💅.

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌸

okay so this doc is about the stuff application designers might want to think about when they're building new protocols 🧚. A lot of popular Internet apps work totally fine with NAT, but others run into all kinds of problems when they cross these boxes 😭. The guidelines here are meant to help new protocols and apps stay compatible with NAT (Network Address Translation) as much as possible ✨.

1. Introduction 🎀

other docs cover NAT too: the terminology and considerations are in [RFC2663], the protocol issues are in [RFC3022] and [RFC3027], and the implications of NAT are in [RFC2993]. All of those are about different NAT issues, how it affects protocols, and how it affects the Internet's general architecture 🧠.

this doc is focused on giving protocol authors advice about what to consider when designing new protocols, so that special handling isn't needed at NAT gateway points 💖.

when a protocol can't get through a NAT cleanly, an Application Level Gateway (ALG) may still let it work 🦋. depending on how a protocol is encoded, an ALG can be hard or easy to build, and in some cases it might not be possible at all 🙈. even though it's an add-on to NAT, protocols that can't go straight through NAT should still be designed so the ALG can be simple and automated ✨. ALGs usually run inside small routers alongside the NAT component 🍓. ideally the ALG should be simple and shouldn't need excessive computation or state storage 💅.

a lot of the same app design issues that cause problems for NAT (and can therefore need ALG support) also cause problems for firewalls 🔥. designers should keep that in mind, because any protocol that needs special handling by NAT or firewall products will be harder to deploy than one that needs none 😭.

2. Discussion 💜

NAT is a real challenge for some existing apps 😤. in lots of cases, though, new app developers can avoid problems if they understand the issues 🧚. this doc wants to give app designers info on what they can do and what they should avoid if they want apps that can work across NAT 🌈.

the spread of NAT, especially in homes and small offices, is a big deal and can't be ignored 👑. the way these technologies are marketed to homes and small businesses often centres on a single-computer setup, so providers tend to give each user only a single IP address 💀. NAT has become a popular choice for connecting more than one system per location 🫶.

the most common problem with NAT implementations is passing addressing data between stations 😭. where possible, applications should look for alternatives to schemes that do this 🦋. studying a few existing protocols will show the different approaches that are possible ✨.

there are two common forms of Traditional NAT 🎀. with Basic NAT, only the IP addresses of packets get altered by the NAT implementation, and many apps will work correctly with Basic NAT 💖. the other common form is Network Address Port Translation 💅. with NAPT, both the IP addresses and the source and destination ports (for TCP and UDP) can potentially be altered by the gateway 🙈. so apps that only pass port number information will work with Basic NAT, but NOT with NAPT 💀.

app designers should aim for compatibility with NAPT, since it's the most widely deployed form of NAT 👑. it's also the form of NAT that will most likely take over homes and small offices 🌸. not every app is a good fit for the architectural model that NAPT imposes 🙃.

3. Recommendations and Examples 🧚

app designers who work within the limits of NAT, and who don't rely on ALGs being around, will generally find it easier to get accepted in user communities where NAT is common 🫶. when you design a new app or service, needing an ALG will hold back deployment until the extra code is added to the many devices that implement NAT 😭.

each of the areas below is an example of an issue to consider when building an app 📝. this list probably isn't comprehensive, but it covers a bunch of important issues and considerations 💖.

3.1 Issues and Recommendations affecting all types of Network Address Translators 🌈

3.1.1. Peer-to-Peer Applications Limitations 👯

peer-to-peer apps are a problem in a NAT world 😩. client-server apps are generally more workable 💅. peer-to-peer apps rely on each peer being reachable as a server (meaning bound to a listening port and able to accept connections) so the other one can connect to it 🔥. with NAPT there are likely to be many machines behind one address 🙈. with other types of NAT, like Basic NAT with Static Address Assignment (which gives one-to-one mappings), there's a better chance of making these apps work ✨.

some NAT implementations can be made to work for UDP-based peer-to-peer apps 🦋. this depends on how the UDP sessions are implemented in the NAT device 🧠. if the NAT device tracks the tuple (private address, private port, public port), then an outbound UDP packet can set up a channel that lets incoming traffic flow from a source other than the one the system originally contacted 🌸. in this case the source IP address is NOT used to match incoming packets to UDP sessions, so any source address using the UDP port number can be translated 👑.

NAT devices that track source and destination IP addresses, as well as port numbers, will NOT let third-party packets through 🛡️. NAT is often implemented together with stateful-inspection firewall functionality 💅. because of that, the latter way of tracking UDP associations would be considered more secure 🔐.

NAT/Firewall devices could be built with a software switch inside them, so the consumer can choose between greater security and a greater ability to run peer-to-peer applications 🎛️✨.

3.1.2. Applications Requiring End-to-End IPSec Will Fail 💀

using IPSec for end-to-end security won't work when there's a NAT implementation in the way 😭. app designers may want to explore Transport Layer Security (TLS) [RFC2246] as a transport mode that can traverse NAT cleanly 🦋. see [RFC2709] for more discussion on combining NAT with Tunnel-mode IPSec security on the same device 🧚.

3.1.3. Use DNS Names, Not IP Addresses In Payload 🏷️

apps should, where possible, use fully qualified domain names instead of IP addresses when they refer to IP endpoints 💖. when endpoints are across a NAT gateway, private addresses must not be allowed to leak to the other endpoint 🙅. an example of where this happens today is with the HTTP and HTML protocols 🌐. web pages can be specified with numeric IP addresses instead of names, so http://192.168.1.10/index.html could be used as a URL, but that would likely cause a problem if the address is on a server behind a NAT gateway 😬. users outside the gateway wouldn't be able to reach the address 192.168.1.10, so they wouldn't see the page 💔.

it gets worse with the chance of duplicate addresses between realms 😱. if a server offers a link with a private address space IP address embedded in it, like 192.168.1.10, the page being referenced may resolve to a system on the local network that the browser is on, which would be a completely different server 🤯. the confusion for end-users would be significant 😵. sessions involving multiple NAT implementations would be exceptionally vulnerable to address reuse issues like this 🚨.

3.1.4. Multicast Considerations 📡

not all NAT devices implement multicast routing protocols 🙃. application designers should check whether the devices in the networks where their apps will be deployed can process multicast traffic, if their apps rely on that capability 🔍.

3.1.5. Retention Of Address Mapping 🧩

with the exception of statically configured NAT bindings, apps should NOT assume address mapping will be kept from one session (an association between machines, for whatever protocol, for a period of time) to another 🙅‍♀️. an example is RSVP, which forms one connection to reserve resources, and then the actual session the resources were reserved for is started 🎫. those sessions don't necessarily overlap 😬. there's no guarantee the NAT implementation will keep the binding association 💀. so apps that rely on later sessions being mapped to the same host IP address may not work without an ALG 🫠.

another thing to think about is the number of addressing realms 🌀. it's totally possible to have multiple levels of NAT implementations between the two endpoints involved 🪆. so you have to think about how long mappings last at all of those levels ⏳.

load balancers and other devices may use a single IP address and port to map to multiple actual endpoints 🎰. lots of products do variations on this, sometimes using NAT and sometimes using other technologies 🛠️. the lack of a mapping guarantee is important to understand, because the mapping from one actual system to another may not survive across these intermediate boxes 🙈.

don't assume systems know their own IP addresses 🙅. a system behind a NAT may be reachable via a particular IP address, but that address may not be recognized by the system itself 🤔. take the case of Static, one-to-one mapping using Basic NAT. a server in this context will have an IP address from the private realm, and may not know the public address that maps to it 🫣. similarly, some of these systems may not know their own DNS names, while others may 📛. this mostly depends on how the servers and the network inside the private realm are configured ⚙️.

3.2 Recommendations for NAPT 🧁

since many of the issues specifically address NAPT issues, this section groups them together 🫶. NAPT is the most common form of NAT in actual deployment in routers, especially in smaller offices and home offices 🏠✨.

3.2.1 IP Addresses Specific To A Realm ✨

Okay bestie, first rule of NAPT club: keep IP addresses and port numbers OUT of the payload 🙅‍♀️. Yes, some ALGs can make those protocols work anyway, but that assumes every single NAT device gets updated in time to support the new protocol, and literally when does that ever happen? 💀 So application writers are strongly urged to skip putting addressing info in payloads altogether 🫶.

Also, don't assume an (address, port) tuple is unique outside the current session. Load balancing devices that do NAT might send your next session to a totally different system inside the private realm 🙈.

3.2.2 Avoid Session Bundles 🎀

Independent sessions, like the ones POP and SMTP use, are the preferred vibe over protocols that try to juggle a whole bundle of related sessions, like FTP 💅. When we say "session" here, we mean any association between end systems, and it can run over any transport or combo of transports (UDP, TCP, SCTP) 🦋.

So FTP passes port info over one TCP connection, then uses that info to build a second TCP connection for the actual data 🌸. Using a separate connection for the file data makes it super easy to tell where the file ends. That said, other schemes could be dreamed up that use a single connection instead ✨.

HTTP is giving single-connection energy 👑. It uses a header with a content length to pass data, so all the data goes over one TCP connection, and the header says how much data is coming. HTTP has also evolved to let multiple objects ride one connection, which cuts down on connection setup overhead 🔥. Honestly, a brand new file transfer function could be built that does most of what FTP does without needing extra TCP connections 💖.

The goal is to stick with single connections wherever possible, because that means we never have to pass addressing info of any kind across the network 🧚. Just know that multiplexing traffic over one connection can cause problems too 😭.

3.2.3. Session Bundles Originate From Same End 💜

Who starts the connection really matters 💅. Wherever possible, the client should be the one that originates all connections. FTP is the most obvious example of the opposite: by default, the server opens the data connection to a port on the client, and the client told it which port by sending a PORT command over the control TCP session 🙈.

As [RFC1579] points out, FTP's passive open option (PASV) fixes this, because now the client is the one responsible for opening the connection ✨. With client-opened connections, the standard NAPT functions can handle the request just like any other simple TCP connection, so an ALG isn't required 🫶.

If session bundles are unavoidable, then each session in the bundle should originate from the same end station 🌈.

3.2.4. Choice of Transport Protocol 🦋

NAPT gateways must keep track of which sessions are still alive, and flush the old ones 🧹. TCP has clear advantages here, because its packets have specific beginning and end markers (SYN and FIN packets) 💖. UDP works for some kinds of apps behind NAT, but it can get messy when the data comes in infrequently 😬. There's no clean way to know when an end station is done with a UDP session, so NAT implementations use timeouts to guess when a UDP session is over. If an app doesn't send data for a long time, the NAT translation might time out and vanish 💀.

NAT implementations also use timers to guess when TCP sessions have disappeared 🕰️. TCP sessions should only go away after FIN packets get exchanged, but those packets might never show up, like if both end stations just die 😵. So the NAT implementation must use a timer to clean up its resources, no exceptions 🧼.

A lot of NAT implementers give you several timeouts: one for live TCP sessions, one for TCP sessions where a FIN has been seen, and one for UDP sessions. Having that flexibility is the best, but some implementations just slap one timer on all traffic, which is a little sus 🙃.

Protocols other than TCP and UDP can work with Traditional NAT in many cases, as long as they aren't carrying addressing information 🌸. For NAPT, though, using any protocol besides TCP and UDP is going to be a problem unless or until those protocols get programmed into the implementations 🚧.

It's important to remember that NAPT deployments assume a client-server model, with the clients living in the private realm 👑.

3.2.5. IP Fragmentation 🌀

Applications should attempt to avoid fragmentation when packets pass over NAPT devices 💅. It's not always practical or possible, but failures can happen with NAPT. Specifically, if two stations in the private realm pick matching fragmentation identifiers and both talk to the same remote host, it might be impossible to tell which fragments belong to which session 😭. A clever NAPT implementation could track fragmentation identifiers and map them into a unique space, but it's not clear how many actually do that 🤷‍♀️.

Ideally, applications should limit their packet size, use Path MTU Discovery, or both 🫶. Unfortunately, at least some firewall/NAT devices block Path MTU Discovery, apparently believing all ICMP packets are evil 💀.

Some NAT implementations may do fragment reassembly before Forwarding, but many don't. So application designers are advised to design as if the devices do not reassemble fragments 🧚.

3.3 Issues and recommendations for Basic NAT 🦋

If only Basic NAT implementations are involved, and not NAPT, then many of the issues above don't apply 🎉. That's not saying this form of NAT is better or worse than NAPT, though 🙅‍♀️. Application designers might think they could just specify that users must use Basic NAT, and then a ton of app issues would disappear. Sadly, that's unrealistic, because many users have no real alternative to NAPT, thanks to the way their providers sell service 😤.

Plenty of the issues raised earlier still apply to Basic NAT, and many protocols won't function correctly without some assistance 🙈.

3.3.1. Use IP and TCP/UDP Headers Alone 💖

Applications that only use the information in the IP and TCP or UDP headers to communicate (aka they don't pass any extra addressing info in the payload) are clearly easier to support in a NAT environment 🌈. So application designers should try to limit themselves in this area whenever they can 💅.

This loops right back to the NAPT recommendation: use a single connection whenever possible 🫶.

The X windowing system is a good example 🖥️. It uses fixed port numbers to address X servers. The server (display) is addressed via ports 6000 through 6000 + n, which map to hostname:0 through hostname:n server displays. Since only the address and port are used, the NAT administrator could map these ports to one or more private addresses, and boom, you get a working solution ✨.

With NAPT, though, the X example needs the NAT implementation to be configured, and that means no more than one station inside the NAT gateway can use a protocol like this. So this approach is OK for NAT, but not recommended for NAPT environments 🙃.

3.3.2. Avoid Addressing In Payload 🧚

Same deal as with NAPT: sticking IP address and/or port number info in the payload is likely to cause trouble 😬. Like we said earlier, load balancers and similar platforms may map the same IP address and port number to a completely different system 🫠. So it's problematic to assume that an address or port number that's valid in the realm on one side of a NAT is also valid on the other side 🚫.

3.4 Bi-directional NAT 🔁

Bi-directional NAT uses DNS mapping of names to point sessions that start outside the private realm to servers inside it 🗺️. Through a DNS-ALG [RFC2694], lookups get performed to find the right host, and then packets are sent to that host 💌.

The requirements for applications are the same as for Basic NAT, and addresses are mapped one-to-one to servers 💅. Unlike Traditional NAT devices, Bi-directional NAT devices (paired with a DNS-ALG) are amenable to peer-to-peer applications 🎀. Main character energy 👑.

3.5 Twice NAT 🪞

Twice NAT is address translation where both the source and destination IP addresses get modified, because of addressing conflicts between two private realms 😵‍💫. Two bi-directional NAT boxes connected together would basically do the same job. A common address space that isn't otherwise used by either private realm would be required, though 🧩.

Applications need the same things to work in a Twice NAT environment as they do for Basic NAT, and addresses are mapped one to one 💖.

3.6 Multi-homed NAT 🏠

Multi-homed NAT means using multiple NAT implementations for redundancy 🛟. The multiple implementations share configuration information, so sessions might keep going if there's a fail-over 🌊. Unless the implementations share the same external addresses, though, sessions will have to restart regardless 😭.

Requirements for multi-homed NAT are the same as for Basic NAT or NAPT, depending on how the multi-homed NAT is implemented and configured 🎀.

3.7 Realm Specific IP (RSIP) 🦋

Realm Specific IP is described in [RFC2663] and defined in [RSIP] and related documents 📚. Clients inside a private realm using RSIP know exactly where the line is between private and public. They access a server to allocate address (and optionally port) info for talking to hosts in the public realm 🫶. Because of this, the packets clients create don't need to be altered by the RSIP server on their way to the remote host 💅. This technique can let IPSec function, and it potentially makes any application work as if no special processing is happening at all ✨.

RSIP assumes there are only two realms, private and public. That isn't always the case 🙃. Multiple levels of NAT implementations are becoming more common. For example, some ISPs are handing out [RFC1918] addresses to their dialup users, instead of getting real addresses 📞. Any user of one of those ISPs who also uses a NAT implementation will see two levels of NAT, and the advantages of RSIP will have gone to waste 💀.

3.8 Performance Implications of Address Translation Implementations 🚀

okay bestie, let's talk speed 💅 Resource utilization on the NAT gateway should be considered. An app that opens and closes a bunch of TCP connections, for example, will eat up more resources on the NAT router than an app doing all its transfers over one single TCP connection 😭 HTTP 1.0 opened a connection for each object on a web page, whereas HTTP 1.1 lets the TCP session stay open for additional objects that might need to be transferred. Clearly the latter is way less overhead for the NAT gateway, since it's only tracking state on one connection instead of many 🧚

New session establishment will typically remain a software function, even in implementations where the packet-by-packet translation work is handled by hardware forwarding engines 🔥 High-performance NAT boxes can be built, but protocols that open lots of sessions instead of multiplexing will be slower than those that don't 🐢

Apps with different types of data, like interactive conferencing, need separate streams for each type of data. In those cases, the protocol needs of each stream must be optimized ✨ Multiplexing over a single session is the goal, and it's preferred, but clearly there are cases where that's just impractical 🙈

The latency of NAT translation overhead is implementation dependent 💖 On a per-packet basis, for established sessions, only the source or destination IP address gets replaced. The source or destination port (for NAPT) gets replaced too, and the checksums for IP and TCP or UDP get recalculated 🦋

The functionality can be efficiently implemented in hardware or software 👑

4. Security Considerations ⚠️

okay this section is serious, so listen up 💀 Network Address Translators have implications for IPSec, as noted above. When application developers are figuring out whether their apps work with NAT implementations, they need to be really careful about picking their security methodology 😭 Transport Layer Security (TLS) [RFC2246] operates across translation boundaries, so it's the friendlier option here. End-to-end IPSec will prove problematic in many cases, so don't say I didn't warn you 🚨

5. References 📚

  • [RFC1579] Bellovin, S., "Firewall Friendly FTP", RFC 1579, February 1994.
  • [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
  • [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", RFC 3027, January 2001.
  • [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
  • [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
  • [RFC3102] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
  • [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
  • [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.

6. Acknowledgements 🫶

I'd like to thank Pyda Srisuresh for his invaluable input and feedback, and Keith Moore for his extensive comments. Icons, honestly 🥹

7. Author's Address 🖋️

Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740

Phone: (978) 779-6813
EMail: dts@senie.com

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Okay, the legal bit, but make it cute 🎀 You're totally allowed to copy and share this document, and to make derivative works that comment on or explain it or help with implementing it, and to publish and distribute those, in whole or in part, without any restriction of any kind. The one catch: the above copyright notice and this paragraph have to be included on all such copies and derivative works. The document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are developing Internet standards (then the procedures for copyrights defined in the Internet Standards process must be followed) or translating it into languages other than English 🌸

The limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 🔒

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society! 🌈✨

📦 where this page comes from