RFC 2663
IP Network Address Translator (NAT) Terminology and Considerations
IP Network Address Translator (NAT) Terminology and Considerations ✨
okay bestie, this is part 1 of 7 of RFC 2663 💖 It's the NAT terminology doc, written by P. Srisuresh and M. Holdrege from Lucent Technologies, published in August 1999 as Request for Comments 2663 under the Network Working Group 🦋 It's Informational, so it's giving "here's some helpful info" and not a standard. Its header doesn't list any Obsoletes or Updates entries.
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 Notice 🎀
Copyright (C) The Internet Society (1999). All Rights Reserved.
Preface 🧚
okay so the whole point of this doc is clarity 💅 "Network Address Translator" means different things in different contexts, and that's exactly the mess this doc wants to clean up. The goal is to define the different flavors of NAT and standardize what the terms mean. The authors are just the editors. The actual content came from working group members 🫶 Big chunks of the older document "IP Network Address Translator (NAT)" were pulled out almost as is to form the starting base, so huge thanks to Pyda Srisuresh and Kjeld Egevang for that. Praveen Akkiraju gets a shoutout for describing NAT deployment scenarios, and the IESG members Scott Bradner, Vern Paxson and Thomas Narten get thanks for their detailed review and for making the text clearer 🙈
Abstract ✨
Network Address Translation is a method that maps IP addresses from one realm to another, so hosts can get transparent routing 🦋 Traditionally, NAT devices connect an isolated address realm that uses private unregistered addresses to an external realm that uses globally unique registered addresses. This document describes how NAT devices work and what to consider with them in general, and it defines the terms used for the different flavors of NAT 💜
1. Introduction and Overview 💖
So why do we even need IP address translation? 👀 It shows up when a network's internal IP addresses can't be used outside that network, either because they're invalid out there or because the internal addressing has to stay private from the outside world.
Address translation lets hosts in a private network talk to destinations on an external network, and the other way around, without anyone noticing. (In many cases, anyway, except as noted in sections 8 and 9 🙈) There are a bunch of NAT flavors and matching terms, and this doc defines those terms and identifies the flavors. It also covers other things that apply to NAT devices in general.
Quick heads up though: this document is not meant to explain how each individual NAT variation works, or where NAT devices are applicable. That's a different convo 💅
NAT devices try to give end hosts a transparent routing solution when they're talking across different address realms. They pull this off by rewriting end node addresses on the way through and keeping state about those rewrites, so the datagrams for a session still reach the right end node on either side 🔥 Here's the catch: this only works when applications don't use IP addresses as part of the protocol itself. For example, if endpoints are identified by DNS names instead of addresses, the application is less dependent on the actual addresses NAT picks. That also means you don't have to translate payload contents every time NAT changes an IP address. Iconic engineering, no cap ✨
NAT can't support every application transparently by itself, so it often has to work alongside application level gateways (ALGs) 👑 So anyone deploying NAT-based solutions needs to figure out their application requirements first, then check out the NAT extensions (aka ALGs) they'd need to keep the application transparent in their environment.
Last but definitely not least, IPsec techniques that are meant to preserve the endpoint addresses of an IP packet won't work with NAT along the way for most applications in practice 😭 AH and ESP protect the contents of the IP headers, including the source and destination addresses, from being modified. But NAT's whole job is to change the addresses in a packet's IP header. Not it 💀
2. Terminology and concepts used 🍓
These are the terms you'll see most often in the NAT world, all defined here so you can reference them whenever 💜
2.1. Address realm or realm 🌈
An address realm is a network domain where network addresses are uniquely assigned to entities, so datagrams can be routed to them. The routing protocols used inside that network domain are responsible for finding routes to entities based on their network addresses. Note that this document is limited to describing NAT in an IPv4 environment and doesn't cover NAT in other types of environment (e.g. IPv6 environments) 🙈
2.2. Transparent routing 🦋
"Transparent routing" is the term used throughout the document for the routing functionality a NAT device provides ✨ It's different from what a traditional router does, because a traditional router routes packets within a single address realm.
Transparent routing means routing a datagram between disparate address realms by modifying the address contents in the IP header so they're valid in the address realm the datagram is being routed into. Section 3.2 has a detailed description of transparent routing 💅
2.3. Session flow vs. Packet flow 🫶
Connection or session flows are different from packet flows 💅 A session flow is the direction a session was initiated in, relative to a network interface. A packet flow is the direction a packet traveled, relative to a network interface. Take an outbound telnet session as an example. It's made up of packet flows in both the inbound and outbound directions. Outbound telnet packets carry terminal keystrokes, and inbound telnet packets carry screen displays from the telnet server 🖥️✨
For the purposes of this document, a session is the set of traffic that is managed as a unit for translation. TCP/UDP sessions are uniquely identified by the tuple (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port). ICMP query sessions are identified by the tuple (source IP address, ICMP query ID, target IP address). Every other session is characterized by the tuple (source IP address, target IP address, IP protocol) 💖
NAT's address translations are session based, so they cover incoming as well as outgoing packets that belong to that session. A session's direction is identified by the direction of the session's first packet (see sec 2.5) 🔥
Heads up: NAT's idea of a session might not match the application's idea of a session. Like, an application might see a bundle of sessions (as NAT sees them) as one single session, or it might not think of its communication with peers as a session at all. And not every application is guaranteed to work across realms, even with an ALG (defined below in section 2.9) along the way 😭
2.4. TU ports, Server ports, Client ports 🎀
From here on out, we'll just call the TCP/UDP ports associated with an IP address "TU ports" 💜
For most TCP/IP hosts, TU port range 0-1023 is used by servers listening for incoming connections. Clients trying to start a connection usually pick a source TU port in the range 1024-65535. But this convention isn't universal and isn't always followed. Some client stations start connections with a source TU port number in the range 0-1023, and there are servers listening on TU port numbers in the range 1024-65535 🌸
A list of assigned TU port services can be found in RFC 1700 [Ref 2]. 📖
2.5. Start of session for TCP, UDP and others 🌈
The first packet of every TCP session tries to establish a session and contains connection startup information. You can spot the first packet of a TCP session by the presence of the SYN bit and the absence of the ACK bit in the TCP flags. All TCP packets, except that first packet, must have the ACK bit set ✨
Here's the tricky part: there's no deterministic way to recognize the start of a UDP-based session or any non-TCP session 😭 A heuristic approach would be to treat the first packet with session parameters that haven't existed before (as defined in section 2.3) as the start of a new session 🧚
2.6. End of session for TCP, UDP and others 🦋
A TCP session's end is detected when FIN is acknowledged by both halves of the session, or when either half receives a segment with the RST bit set in the TCP flags field. But here's the plot twist: a NAT device can't know whether the packets it sees will actually reach the destination, since they might get dropped between the NAT device and the destination. So the NAT device can't safely assume that the segments containing FINs or SYNs are the last packets of the session, because retransmissions could still happen 💀 That means a session can only be assumed terminated after a period of 4 minutes from that detection. RFC 793 [Ref 7] explains why we need this extended wait. It suggests a TIME-WAIT duration of 2 * MSL (Maximum Segment Lifetime), or 4 minutes ⏳
A TCP connection can also end without the NAT device ever finding out, for example when one or both peers reboot 🙈 So NAT devices need garbage collection to clean up unused state for TCP sessions that don't exist anymore. The problem is that, in the general case, there's no way to tell a connection that's just been idle for a long time apart from one that's gone for good. For UDP-based sessions, there's no single way to tell when a session ends, because UDP-based protocols are application specific 💅
Lots of heuristic approaches are used to end sessions. You can assume that TCP sessions unused for say, 24 hours, and non-TCP sessions unused for a couple of minutes, are terminated. Often this works, but sometimes it doesn't 😬 These idle-period timeouts vary a lot from application to application, and even between different sessions of the same application. So session timeouts must be configurable. Even then, there's no guarantee a satisfactory value can be found. And as section 2.3 said, there's no guarantee that NAT's view of session termination will match the application's view 🫠
Another option is to timestamp entries, keep them as long as possible, and retire the longest idle session when it becomes necessary 🌸
2.7. Public/Global/External network 💜
A Global or Public Network is an address realm with unique network addresses assigned by the Internet Assigned Numbers Authority (IANA) or an equivalent address registry. During NAT discussions, this network is also referred to as the External network 🌍✨
2.8. Private/Local network 🏠
okay so a private network is its own address realm, totally separate from the external network addresses 🫶 It can also be called a Local Network. When a host in the private realm needs to talk to the external realm (and back), a NAT router does the transparent routing for it ✨
RFC 1918 [Ref 1] has the recommendations for address space allocation in private networks 🎀 IANA set aside three blocks for private internets: 10/8, 172.16/12, and 192.168/16 🌸 In pre-CIDR notation, the first block is just one class A network number, the second block is 16 contiguous class B networks, and the third block is 256 contiguous class C networks. bestie that's a lot of addresses 😭
An organization can use addresses from that space without coordinating with IANA or any other Internet registry like APNIC, RIPE and ARIN 💅 So lots of independent organizations can use the same private space at the same time, no cap. BUT 🙈 if those orgs later want to talk to each other or the public Internet, they will either have to renumber their networks or enable NAT on their border routers. so it's not a free pass forever, periodt 💀
2.9. Application Level gateway (ALG) 🧚
not every application is easy for NAT devices to translate 🥺 especially the ones that put IP addresses and TCP/UDP ports inside the payload. that's where Application Level Gateways (ALGs) come in ✨ they're application specific translation agents that let an application on a host in one address realm connect to its counterpart on a host in a different realm, transparently 🦋 An ALG may work with NAT to set up state, use NAT state information, modify the application specific payload, and do whatever else is needed to get the application running across disparate address realms. it's giving full support team energy 👑
ALGs don't always use NAT state information though 🤷♀️ sometimes they just glean the application payload and simply notify NAT to add additional state information. ALGs are kind of like Proxies, since both facilitate application specific communication between clients and servers 💜 BUT the difference is that Proxies use a special protocol to talk to proxy clients and relay client data to servers and vice versa. Unlike Proxies, ALGs do not use a special protocol to communicate with application clients, and they do not require changes to application clients. ALGs are so iconic for that 🌈
3. What is NAT? 🎀
okay the main event 💖 Network Address Translation is a method where IP addresses get mapped from one address realm to another, giving transparent routing to end hosts ✨ there are lots of variations that suit different applications, but all flavors of NAT devices should share these characteristics:
- a) Transparent Address assignment. 🌸
- b) Transparent routing through address translation.
- (routing here refers to forwarding packets, and not exchanging routing information)
- c) ICMP error packet payload translation. 🫶
here's a diagram of NAT on a stub domain border router, connected to the Internet through a regional router that a service provider made available 🗺️
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub borderFigure 1: A typical NAT operation scenario 📸
3.1. Transparent Address Assignment 🦋
NAT binds addresses in the private network with addresses in the global network, and vice versa, to provide transparent routing for datagrams traveling between address realms 💅 In some cases the binding can extend to transport level identifiers (like TCP/UDP ports). Address binding happens at the start of a session. The next two subsections describe the two types of address assignment ✨
3.1.1. Static Address assignment 🧊
with static address assignment there's a one-to-one address mapping for hosts between a private network address and an external network address, for the whole lifetime of NAT operation 🔒 This means NAT doesn't have to administer address management with session flows. so chill, less work for NAT 😌
3.1.2. Dynamic Address assignment 🌀
here, external addresses are assigned to private network hosts, or vice versa, dynamically, based on usage requirements and session flow that NAT figures out heuristically 🧠 When the last session using an address binding is terminated, NAT frees the binding so the global address can be recycled for later use ♻️ The exact nature of address assignment depends on the individual NAT implementation, so it can vary, and that's okay 💖
3.2. Transparent routing 🚀
a NAT router sits at the border between two address realms and translates addresses in IP headers, so when a packet leaves one realm and enters another, it can be routed properly 🛣️ Since NAT devices connect to multiple address realms, they must be careful not to improperly propagate information (e.g., via routing protocols) about networks from one address realm into another, where such an advertisement would be deemed unacceptable 🙅♀️
there are three phases to Address translation 🎀 together they create, maintain, and terminate the state for sessions passing through NAT devices 🌈
3.2.1. Address binding 🔗
Address binding is the phase where a local node IP address is associated with an external address, or vice versa, for translation purposes 💜 Address binding is fixed with static address assignments and is dynamic at session startup time with dynamic address assignments. Once the binding between two addresses is in place, all subsequent sessions originating from or going to this host use the same binding for session based packet translation 🫶
New address bindings get made at the start of a new session, if one didn't already exist 🌸 Once a local address is bound to an external address, all later sessions from that same local address, or directed to it, use the same binding. The start of each new session creates state to help translate datagrams for that session ✨ and there can be many simultaneous sessions from the same host, all based on a single address binding. main character host behavior 👑
3.2.2. Address lookup and translation 🔍
once state is established for a session, every packet in that session gets address lookup (and transport identifier lookup, in some cases) and translation 🧩 Translating the address or transport identifier for a datagram results in it being forwarded from the origin address realm to the destination address realm, with the network addresses updated appropriately 🚀
3.2.3. Address unbinding 🧹
Address unbinding is the phase where a private address is no longer associated with a global address for translation purposes 💀 NAT does address unbinding when it believes the last session using an address binding has terminated. Refer section 2.6 for some heuristic ways to handle session terminations 📚
3.3. ICMP error packet translation 📨
all ICMP error messages (except the Redirect message type) need to be modified when they pass through NAT 🙈 The ICMP error message types that need NAT modification are Destination-Unreachable, Source-Quench, Time-Exceeded and Parameter-Problem. NAT should not attempt to modify a Redirect message type, so hands off Redirect 🚫
changes to an ICMP error message include changes to the original IP packet (or portions of it) embedded in the payload of the ICMP error message 🎁 For NAT to be completely transparent to end hosts, the IP address of the IP header embedded in the ICMP payload must be modified, and the checksum field of that same IP header must correspondingly be modified, and so must the accompanying transport header. The ICMP header checksum must also be modified to reflect the changes made to the IP and transport headers in the payload. Furthermore, the normal IP header must also be modified. it's a lot of moving parts, but that's the vibe 😭✨
4.0. Various flavors of NAT 💅
there are many variations of address translation that suit different applications 🌷 The NAT flavors in the following subsections are by no means exhaustive, but they do capture the significant differences out there 🧚
the diagram below is the base model we'll use to illustrate NAT flavors 🗺️ Host-A, with address Addr-A, lives in a private realm, represented by the network N-Pri. N-Pri is isolated from the external network through a NAT router. Host-X, with address Addr-X, lives in an external realm, represented by the network N-Ext. The NAT router has two interfaces, each attached to one of the realms, and it provides transparent routing between the two 🦋 The interface to the external realm is assigned Addr-Nx, and the interface to the private realm is assigned Addr-Np. Addresses Addr-A and Addr-Np correspond to the N-Pri network, and addresses Addr-X and Addr-Nx correspond to the N-Ext network 💖
________________
( )
( External ) +--+
( Address Realm )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| |
| NAT router |
| |
+--------------+
|(Addr-Np)
|
----------------
( )
+--+ ( Private )
|__|------( Address Realm )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)Figure 2: A base model to illustrate NAT terms. 🎀
4.1. Traditional NAT (or) Outbound NAT ✨
okay so traditional NAT lets hosts inside a private network reach hosts out on the external network, transparently, in most cases 🦋 The big thing is that sessions only go one way, outbound from the private side. That's the opposite of Bi-directional NAT, which allows sessions in both directions. We'll get to that in section 4.2 💅
Here's how the realms work with traditional NAT. Hosts on the external network have addresses that are unique and valid on both the external and private networks 🌍 But hosts on the private network only have addresses that are unique inside the private network, and those might not be valid on the external network at all 🙈 So NAT doesn't advertise private networks to the external realm. It does go the other way, though: networks from the external realm can be advertised inside the private network. The addresses used on the private side must not overlap with the external addresses. Any given address has to be either a private address or an external address, never both 🫶
In figure 2, a traditional NAT router lets Host-A start sessions to Host-X, but not the other way around. N-Ext is routable from inside N-Pri, but N-Pri may not be routable from N-Ext 💜
Traditional NAT is mostly used by sites that use private addresses and want to let their own hosts start outbound sessions 🌸
There are two flavours of traditional NAT: Basic NAT and NAPT (Network Address Port Translation). We'll dig into both in the next subsections 🎀
4.1.1. Basic NAT 🍓
okay so with Basic NAT, a block of external addresses is set aside to translate the addresses of private hosts when they start sessions out to the external domain 🧚 For packets leaving the private network, the source IP address and related fields get translated, along with the IP, TCP, UDP and ICMP header checksums. For inbound packets, the destination IP address and those same checksums get translated instead 💖
In figure 2, a Basic NAT router can be configured to translate N-Pri into a block of external addresses, say Addr-i through Addr-n, picked from the external network N-Ext ✨
4.1.2. Network Address Port Translation (NAPT) 👑
NAPT takes translation one step further, because it also translates transport identifiers (like TCP and UDP port numbers, and ICMP query identifiers) 🔥 This lets the transport identifiers of a bunch of private hosts get multiplexed into the transport identifiers of one external address. So a whole set of hosts can share a single external address, which is lowkey iconic 🦋 NAPT can also be combined with Basic NAT, so a pool of external addresses gets used together with port translation 🌈
For packets leaving the private network, NAPT translates the source IP address, the source transport identifier, and related fields like the IP, TCP, UDP and ICMP header checksums. The transport identifier can be either a TCP/UDP port or an ICMP query ID. For inbound packets, the destination IP address, the destination transport identifier, and the IP and transport header checksums get translated 💅
A NAPT router in figure 2 can be configured to translate sessions started from N-Pri into a single external address, say Addr-i 🌸
Very often, the external interface address Addr-Nx of the NAPT router is the address that N-Pri gets mapped to 🫶
4.2. Bi-directional NAT (or) Two-Way NAT 🦋
okay this one is giving two-way energy 😭 With Bi-directional NAT, sessions can start from hosts on the public network and from hosts on the private network 💖 Private network addresses get bound to globally unique addresses, either statically or dynamically, as connections are set up in either direction. The name space (meaning the Fully Qualified Domain Names) is assumed to be end-to-end unique between private and external hosts ✨ Hosts on the external realm reach private realm hosts by using DNS for address resolution. A DNS-ALG must be employed alongside Bi-Directional NAT to make the name-to-address mapping work 🔥 Specifically, the DNS-ALG has to be able to translate private realm addresses in DNS queries and responses into their external realm address bindings, and the other way around, as DNS packets cross between the private and external realms 👑
The address space requirements we just covered for traditional NAT routers apply here too 🌈
In figure 2, a Bi-directional NAT router lets Host-A start sessions to Host-X, and lets Host-X start sessions to Host-A. Just like with traditional NAT, N-Ext is routable from inside N-Pri, but N-Pri may not be routable from N-Ext 🧚
4.3. Twice NAT 💜
Twice NAT is a flavour of NAT where both the source and destination addresses get modified by NAT as a datagram crosses address realms 🎀 That's different from Traditional NAT and Bi-Directional NAT, where only one of the addresses (either source or destination) gets translated. Also, fun fact, there is no such term as 'Once-NAT' 🙈
Twice NAT is needed when the private and external realms have address collisions 💀 The most common case is when a site has (improperly) numbered its internal nodes using public addresses that were already assigned to another organization 😭 Another way it happens: a site switches from one provider to another but keeps the addresses it was originally assigned by the first provider internally. That first provider might later hand those addresses to someone else 🌸 The key problem is that a host in the external realm may have been assigned the same address as a host inside the local site. If that address showed up in a packet, it would get forwarded to the internal node instead of going through the NAT device out to the external realm 🫠 Twice NAT tries to bridge these realms by translating both the source and destination address of an IP packet as it moves between realms 💅
Here's how Twice NAT works. When Host-A wants to start a session to Host-X, it sends a DNS query for Host-X. A DNS-ALG intercepts that query, and in the response sent back to Host-A, the DNS-ALG swaps the address for Host-X with one that's properly routable in the local site (say Host-XPRIME) 🧚 Host A then starts communicating with Host-XPRIME. When the packets go through the NAT device, the source IP address gets translated (like in traditional NAT), and the destination address gets translated to Host-X. Return packets coming from Host-X get a similar translation 🦋
The realm properties for Twice NAT are a little messy, so bear with me 🫶 Network addresses of external hosts are unique within external networks, but not within the private network. Likewise, network addresses of private hosts are unique only within the private network. In other words, the address space the private network uses to locate hosts in both private and public networks has nothing to do with the address space the public network uses to locate hosts in both private and public networks 🌈 A Twice NAT is not allowed to advertise local networks to the external network, or vice versa 🌸
In figure 2, a Twice NAT router lets Host-A start sessions to Host-X, and lets Host-X start sessions to Host-A. However, N-Ext (or a subset of N-Ext) is not routable from inside N-Pri, and N-Pri is not routable from N-Ext 💀
Twice NAT is usually used when the address space in a private network overlaps with addresses used in public space 😭 For example, say a private site uses the 200.200.200.0/24 address space, which is officially assigned to another site on the public internet. Host_A (200.200.200.1) in the private space wants to connect to Host_X (200.200.200.100) in the public space. To make this connection work, Host_X's address gets mapped to a different address for Host_A, and the other way around. The twice NAT at the private site's border may be configured like this:
Private to Public : 200.200.200.0/24 -> 138.76.28.0/24
Public to Private : 200.200.200.0/24 -> 172.16.1.0/24
Datagram flow : Host_A(Private) -> Host_X(Public)
a) Within private network
DA: 172.16.1.100 SA: 200.200.200.1
b) After twice-NAT translation
DA: 200.200.200.100 SA: 138.76.28.1
Datagram flow Host_X (Public) -> Host_A (Private)
a) Within Public network
DA: 138.76.28.1 SA: 200.200.200.100
b) After twice-NAT translation, in private network
SA: 200.200.200.1 DA: 172.16.1.1004.4. Multihomed NAT 🌈
NAT has some limitations 🙃 For example, requests and responses for a session must be routed through the same NAT router, because a NAT router keeps state information for sessions that are set up through it. That's why it's often suggested to run NAT routers on a border router unique to a stub domain, where all IP packets either come from the domain or are headed to the domain. But that setup would make the NAT router a single point of failure 😱
To keep connectivity with external networks even when one of the NAT links fails, it's often a good idea to multihome the private network. That means having multiple connections from the private domain to the same or multiple service providers, coming from the same or different NAT boxes 💅
For example, a private network could have links to two different providers, and sessions from private hosts could flow through whichever NAT router has the best metric for a destination. When one NAT router fails, the other one can route traffic for all connections 🫶
Multiple NAT boxes, or multiple links on the same NAT box that share the same NAT configuration, can give each other fail-safe backup. In that case, the backup NAT device has to exchange state information so it can take over session load transparently when the primary NAT fails. NAT backup gets simpler when the configuration is based on static maps 🧚
5.0. Realm Specific IP (RSIP) 🔥
"Realm Specific IP" (RSIP) is the name for the functionality of a realm-aware host on a private realm. That host uses a realm-specific IP address to communicate with hosts on the private or external realm 👑
A "Realm Specific IP Client" (RSIP client) is a host on a private network that adopts an address from an external realm when it connects to hosts in that realm, so it can pursue end-to-end communication 🦋 Packets generated by hosts at either end of a setup like this are based on addresses that are end-to-end unique in the external realm, so they don't need translation by an intermediary process ✨
A "Realm Specific IP Server" (RSIP server) is a node that lives on both the private and external realms, and it can help route external realm packets within a private realm 🌸 Those packets might have been originated by an RSIP client, or be directed to an RSIP client. An RSIP-Server can also be the same node that assigns external realm addresses to RSIP-Clients 💖
There are two variations of RSIP: Realm-specific Address IP (RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP). We'll cover those in the following subsections 🎀
5.1. Realm Specific Address IP (RSA-IP) 🦋
okay so an RSA-IP client (bestie, this is the main character 💅) grabs an IP address from the external address space when it wants to talk to a host in the external realm ✨. Once it has taken that external address, no other host in the private or external domain can use the same address until the RSA-IP client lets it go. ngl that's a very exclusive address 👑
Now the routing tea ☕. For end-to-end RSA-IP packets inside the private realm, there are a couple of ways to go. Option one is to tunnel the packet to the destination. The outer header can get translated by NAT like normal, and the addresses in the inner header stay untouched 🎀. Option two is to set up a bi-directional tunnel between the RSA-IP client and the border router that straddles the two address realms. Packets to and from the client get tunneled, but packets just get forwarded as normal between the border router and the remote destination. Note, the tunnel from the client TO the border router may not be necessary 🙈 You might be able to just forward the packet directly. This should work as long as your internal network isn't filtering packets based on source addresses (which, in this case, would be external addresses). 💀
Here's the example. Host-A in figure 2 above could assume an address Addr-k from the external realm and act as an RSA-IP-Client, so it can have end-to-end sessions between Addr-k and Addr-X. The traversal of end-to-end packets inside the private realm looks like this 🧚
First method, using NAT router enroute to translate
Host-A NAT router Host-X
------ ----------- ------
<Outer IP header, with
src=Addr-A, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
----------------------------->
<Outer IP header, with
src=Addr-k, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
--------------------------->
.
.
.
<Outer IP header, with
src=Addr-X, Dest=Addr-k>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<---------------------------------
<Outer IP header, with
src=Addr-X, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<--------------------------------------Second method, using a tunnel within private realm
Host-A NAT router Host-X
------ ----------- ------
<Outer IP header, with
src=Addr-A, Dest=Addr-Np>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
----------------------------->
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
------------------------------->
.
.
.
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<--------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<----------------------------------There may be other approaches to pursue ✨
An RSA-IP-Client has the following characteristics. The whole set of operations an RSA-IP-Client performs can be called "RSA-IP" 💜
- Aware of the realm to which its peer nodes belong.
- Assumes an address from the external realm when communicating with hosts in that realm. Such an address may be assigned statically, or obtained dynamically (through a yet-to-be-defined protocol) from a node capable of assigning addresses from the external realm. An RSA-IP-Server could be the node coordinating external realm address assignment 🌸
- Routes packets to external hosts using an approach amenable to the RSA-IP-Server. In all cases, the RSA-IP-Client will likely need to act as a tunnel end-point, capable of encapsulating end-to-end packets while forwarding and decapsulating them on the return path 🫶
"Realm Specific Address IP Server" (RSA-IP server) is a node resident on both private and external realms, which facilitates routing of external realm packets specific to RSA-IP clients inside a private realm. An RSA-IP-Server may be described as having the following characteristics 🔥
- May be configured to assign addresses from the external realm to RSA-IP-Clients, either statically or dynamically.
- It must be a router resident on both the private and external address realms. 💅
- It must be able to provide a mechanism to route external realm packets within the private realm. Of the two approaches described, the first approach requires the RSA-IP-Server to be a NAT router providing transparent routing for the outer header. This approach requires the external peer to be a tunnel end-point.
With the second approach, an RSA-IP-Server could be any router (including a NAT router) that can be a tunnel end-point with RSA-IP-Clients. It would detunnel end-to-end packets outbound from RSA-IP-Clients and forward them to external hosts. On the return path, it would locate the RSA-IP-Client tunnel based on the destination address of the end-to-end packet, and encapsulate the packet in a tunnel to forward to the RSA-IP-Client 🧚
RSA-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode authentication and confidentiality using AH and ESP headers on the embedded packets. Any of the tunneling techniques may be adapted for encapsulation between the RSA-IP-Client and the RSA-IP-Server, or between the RSA-IP-Client and the external host. For example, IPsec tunnel mode encapsulation is a valid type of encapsulation that ensures IPsec authentication and confidentiality for the embedded end-to-end packets. that's the whole vibe, bestie 🌈
5.2. Realm Specific Address and port IP (RSAP-IP) ✨
Okay bestie, RSAP-IP is basically RSIP's glow-up 💅. Instead of every private host needing its own external address, a bunch of them share one external address and split it up using transport identifiers (TCP/UDP port numbers and ICMP Query IDs) 🦋.
"RSAP-IP-Client" is pretty much RSA-IP-Client's twin, with one big twist 🎀. An RSAP-IP-Client uses a tuple of (external address, transport Identifier) when it reaches out to hosts in the external realm. Because of that, an RSAP-IP-Client can only talk to external nodes over TCP, UDP and ICMP sessions. No other protocols allowed, sorry not sorry 💀.
"RSAP-IP-Server" is similar to RSA-IP-Server 🧚. It helps route external realm packets to the right RSAP-IP clients inside a private realm. Usually, the RSAP-IP-Server is also the one handing out transport tuples to the RSAP-IP-Clients 👑.
A NAPT router along the path can act as the RSAP-IP-Server 🌸. This works when the outer encapsulation is TCP/UDP based and is addressed between the RSAP-IP-Client and the external peer. It also means the external peer has to be the endpoint of that TCP/UDP based tunnel. With this setup, RSAP-IP-Clients can use IPsec techniques, namely transport or tunnel mode authentication and confidentiality using AH and ESP headers on the embedded packets 🔐. Ngl though, IPsec tunnel mode is NOT a valid encapsulation type here, because a NAPT router can't provide routing transparency to AH and ESP protocols 😭. (Careful: no key words in caps here, this one is just vibes!)
Alternatively, packets may be tunneled between the RSAP-IP-Client and the RSAP-IP-Server 🦋. The RSAP-IP-Server detunnels packets going outbound from the RSAP-IP-Clients and forwards them to external hosts. On the way back, the RSAP-IP-Server finds the right RSAP-IP-Client tunnel using the tuple of (destination address, transport Identifier), then encapsulates the original packet in a tunnel to send it to the RSAP-IP-Client 💜. With this approach there's no limit on the tunneling technique between the RSAP-IP-Client and the RSAP-IP-Server 🎉. BUT, IPsec security on end-to-end packets has limits. Transport mode authentication and integrity can be attained 🫶. Confidentiality, however, cannot be permitted, because the RSAP-IP-Server has to examine the destination transport Identifier to know which RSAP-IP tunnel to forward inbound packets to 🙈. So only transport mode TCP, UDP and ICMP packets protected by AH and ESP-authentication can traverse an RSAP-IP-Server using this approach.
Let's do an example 🍓. Say Host-A in figure 2 above gets a tuple of (Addr-Nx, TCP port T-Nx) from a NAPT router so it can act as an RSAP-IP-Client and start end-to-end TCP sessions with Host-X. Here's how the end-to-end packets move around the private realm.
In the first method, the outer layer of the outgoing packet from Host-A uses (private address Addr-A, source port T-Na) as its source tuple to talk to Host-X. The NAPT router along the way translates this tuple into (Addr-Nx, Port T-Nxa). Notice this translation doesn't depend on the RSAP-IP-Client tuple parameters in the embedded packet 👀.
First method, using NAPT router enroute to translate:
====================================================
Host-A NAPT router Host-X
------ ----------- ------
<Outer TCP/UDP packet, with
src=Addr-A, Src Port=T-Na,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
----------------------------->
<Outer TCP/UDP packet, with
src=Addr-Nx, Src Port=T-Nxa,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
--------------------------------------->
.
.
.
<Outer TCP/UDP packet with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nxa>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer TCP/UDP packet, with
src=Addr-X, Dest=Addr-A,
Dest Port=T-Na>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<-----------------------------------And the second method uses a tunnel inside the private realm 🌈.
Second method, using a tunnel within private realm:
==================================================
Host-A NAPT router Host-X
------ ----------- ------
<Outer IP header, with
src=Addr-A, Dest=Addr-Np>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
----------------------------->
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
-------------------------------->
.
.
.
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------6.0. Private Networks and Tunnels 🎀
Let's talk about what happens when your private network connects to the outside world through tunnels 🚇. In that case, the tunnel-encapsulated traffic may or may not contain translated packets, depending on the characteristics of the address realms the tunnel is bridging.
The next subsections cover two scenarios where tunnels show up: (a) together with address translation, and (b) without translation 🧚.
6.1. Tunneling translated packets 💖
Every variation of address translation from the previous section works on direct links, tunnels and virtual private networks (VPNs) alike 🌸.
For example, a private network connected to a business partner through a VPN could use traditional NAT to talk to the partner 🤝. Likewise, twice NAT is an option if the partner's address space overlaps with the private network 👯. There could be a NAT device on one end of the tunnel or on both ends. In every case, traffic across the VPN can be encrypted for security purposes 🔐. Security here refers to security for traffic across VPNs alone, though. End-to-end security requires trusting the NAT devices inside the private network 😬. Be careful who you trust, bestie 💅.
6.2. Backbone partitioned private Networks 🌍
There are lots of cases where a private network (like a corporate network) is spread across different locations and uses a public backbone to communicate between them 🏢. In those cases, address translation isn't desirable 🙅. Why? Because large numbers of hosts may want to talk across the backbone, which would mean needing huge address tables. Also, more applications depend on configured addresses rather than going through a name server 📖. We call this kind of private network a backbone-partitioned private network 🦋.
Backbone-partitioned stubs should behave as though they were non-partitioned stubs ✨. That means the routers in all partitions should keep routes to the local address spaces of every partition. Of course, the (public) backbones don't keep routes to any local addresses 😭. So the border routers must tunnel (using VPNs) through the backbones using encapsulation. To make that work, each NAT box sets aside a global address for tunneling 🫶.
When NAT box x in stub partition X wants to deliver a packet to stub partition Y, it encapsulates the packet in an IP header whose destination address is the global address of NAT box y that was reserved for encapsulation 📦. When NAT box y receives a packet with that destination address, it decapsulates the IP header and routes the packet internally 🎉. Note, there is no address translation in the process. It's merely the transfer of private network packets over an external network tunnel backbone 💜.
7.0. NAT operational characteristics ✨
okay so NAT devices are application unaware 🙈 bestie, their translations are literally limited to IP/TCP/UDP/ICMP headers and ICMP error messages only. they don't change the payload of packets, because payloads tend to be super app specific 💅
NAT devices (without the inclusion of ALGs) do not examine or modify transport payload 🫶 so NAT is transparent to apps in lots of cases. BUT there are two areas where NAT devices cause drama: 1) when an application payload includes an IP address, and 2) when end-to-end security is needed. note, this is NOT a comprehensive list 💀
application layer security techniques that don't make use of or depend on IP addresses work correctly with NAT (e.g., TLS, SSL and ssh) 🔐✨. in contrast, transport layer techniques like IPSec transport mode or the TCP MD5 Signature Option RFC 2385 [Ref 17] do not 😭
in IPSec transport mode, both AH and ESP have an integrity check covering the entire payload 🛡️. when the payload is TCP or UDP, the TCP/UDP checksum is covered by the integrity check. when a NAT device modifies an address, the checksum is no longer valid with respect to the new address. normally NAT also updates the checksum, but that's ineffective when AH and ESP are used 🥲. so receivers will discard a packet either because it fails the IPSec integrity check (if the NAT device updates the checksum), or because the checksum is invalid (if the NAT device leaves the checksum unmodified). no escape, periodt 💀
note that IPsec tunnel mode ESP is permissible so long as the embedded packet contents are unaffected by the outer IP header translation. although this technique does not work in traditional NAT deployments (i.e., where hosts are unaware that NATs are present), the technique is applicable to Realm-Specific IP as described in Section 5.0 🦋
note also that end-to-end ESP based transport mode authentication and confidentiality are permissible for packets such as ICMP, whose IP payload content is unaffected by the outer IP header translation 🌸
NAT devices also break fundamental assumptions made by public key distribution infrastructures, like Secure DNS RFC 2535 [Ref 18] and X.509 certificates with signed public keys 😩. with Secure DNS, each DNS RRset is signed with a key from within the zone. moreover, the authenticity of a specific key is verified by following a chain of trust that goes all the way to the DNS root. when a DNS-ALG modifies addresses (e.g., as in the case of Twice-NAT), verification of signatures fails 💔
it may be of interest to note that IKE (Session key negotiation protocol) is a UDP based session layer protocol and is not protected by network based IPsec security 👀. only a portion of the individual payloads within IKE are protected. as a result, IKE sessions are permissible across NAT, so long as the IKE payload does not contain addresses and/or transport IDs specific to one realm and not the other. given that IKE is used to set up IPSec associations, and there are at present no known ways of making IPSec work through a NAT function, it is a future work item to take advantage of IKE through a NAT box 🚧
one of the most popular internet applications, "FTP", would not work with the definition of NAT as described 😤. the following subsection is devoted to describing how FTP is supported on NAT devices. the FTP ALG is an integral part of most NAT implementations 🧚. some vendors may choose to include additional ALGs to custom support other applications on the NAT device ✨
7.1. FTP support
"PORT" command and "PASV" response in FTP control session payload identify the IP address and TCP port that must be used for the data session it supports 🎀. the arguments to the PORT command and PASV response are an IP address and a TCP port in ASCII. an FTP ALG is required to monitor and update the FTP control session payload so that the information contained in the payload is relevant to end nodes 👑. the ALG must also update NAT with appropriate data session tuples and session orientation so that NAT could set up state information for the FTP data sessions 🍓
because the address and TCP port are encoded in ASCII, this may result in a change in the size of the packet 📏. for instance, 10,18,177,42,64,87 is 18 ASCII characters, whereas 193,45,228,137,64,87 is 20 ASCII characters. if the new size is the same as the previous, only the TCP checksum needs adjustment as a result of the change of data 🧮. if the new size is less than or greater than the previous, TCP sequence numbers must also be changed to reflect the change in length of the FTP control data portion 🙃. a special table may be used by the ALG to correct the TCP sequence and acknowledgement numbers. the sequence number and acknowledgement correction will need to be performed on all future packets of the connection 🔁
8.0. NAT limitations 🥀
8.1. Applications with IP-address Content
not all applications lend themselves easily to address translation by NAT devices 😬. especially the applications that carry an IP address (and TU port, in case of NAPT) inside the payload. Application Level Gateways, or ALGs, must be used to perform translations on packets pertaining to such applications. ALGs may optionally utilize address (and TU port) assignments made by NAT and perform translations specific to the application. the combination of NAT functionality and ALGs will not provide end-to-end security assured by IPsec 🙅♀️. however, tunnel mode IPsec can be accomplished with a NAT router serving as the tunnel end point ✨
SNMP is one such application with address content in its payload 📡. NAT routers would not translate IP addresses within SNMP payloads. it is not uncommon for an SNMP specific ALG to reside on a NAT router to perform SNMP MIB translations proprietary to the private network 🧠
8.2. Applications with inter-dependent control and data sessions
NAT devices operate on the assumption that each session is independent 🦄. session characteristics like session orientation, source and destination IP addresses, session protocol, and source and destination transport level identifiers are determined independently at the start of each new session.
however, there are applications such as H.323 that use one or more control sessions to set the characteristics of the follow-on sessions in their control session payload 🎭. such applications require the use of application specific ALGs that can interpret and translate the payload, if necessary. payload interpretation would help NAT be prepared for the follow-on data sessions 💜
8.3. Debugging Considerations
NAT increases the probability of mis-addressing 🌀. for example, the same local address may be bound to different global addresses at different times, and vice versa. as a result, any traffic flow study based purely on global addresses and TU ports could be confused and might misinterpret the results 📉
if a host is abusing the Internet in some way (such as trying to attack another machine, or even sending large amounts of junk mail or something) it is more difficult to pinpoint the source of the trouble, because the IP address of the host is hidden in a NAT router 🕵️♀️ bestie, that's lowkey the whole point of the hiding, but it makes debugging a lot harder 😭
8.4. Translation of fragmented FTP control packets
translation of fragmented FTP control packets is tricky when the packets contain a "PORT" command or a response to a "PASV" command 🧩. clearly, this is a pathological case. the NAT router would need to assemble the fragments together first, and then translate prior to forwarding 🫠
yet another case would be when each character of packets containing a "PORT" command or a response to "PASV" is sent in a separate datagram, unfragmented 🔤. in this case, NAT would simply have to let the packets through, without translating the TCP payload. of course, the application will fail if the payload needed to be altered 💀. the application could still work in a few cases, where the payload contents can be valid in both realms without modifications en route. for example, FTP originated from a private host would still work while traversing a traditional NAT or bi-directional NAT device, so long as the FTP control session employed the PASV command to establish data sessions 🙌. the reason being that the address and port number specified by the FTP server in the PASV response (sent as multiple unfragmented packets) is valid to the private host, as is. the NAT device will simply view the ensuing data session (also originating from the private host) as an independent TCP session 🫶
8.5. Compute intensive
NAT is compute intensive, even with the help of a clever checksum adjustment algorithm, as each data packet is subject to NAT lookup and modifications 🏋️♀️. as a result, router forwarding throughput could be slowed considerably. however, so long as the processing capacity of the NAT device exceeds the line processing rate, this should not be a problem 🚀
9.0. Security Considerations 🔐
okay bestie, this section is SERIOUS, so buckle up 😭🫶. Lots of people see a traditional NAT router as a one-way session filter, kind of like a bouncer who only lets sessions in from outside if someone inside started them 💅. And when the NAT router assigns addresses dynamically, it gets way harder for an attacker to target one specific host in the NAT domain 🎯. NAT routers can also team up with firewalls to filter out unwanted traffic ✨.
If NAT devices and ALGs aren't inside a trusted boundary, that is a major security problem 💀, because ALGs could snoop on end-user traffic payloads. Session-level payloads can still be encrypted end to end, as long as the payload doesn't contain IP addresses and/or transport identifiers that are only valid in one of the realms 🔒. Except for RSIP, end-to-end IP network-level security from current IPsec techniques isn't attainable with NAT devices in between. One of the ends has to be a NAT box 📦. See section 7.0 for why end-to-end IPsec security can't be assured with NAT devices along the route 🧐.
The combo of NAT functionality, ALGs and firewalls gives a transparent working environment for a private networking domain 🌸. Except for RSIP (see section 5.0 for how RSIP works), end-to-end network security assured by IPsec can't be attained for end hosts inside the private network. In every other case, if you want end-to-end IPsec, there can't be a NAT device in the path 🙅♀️. If we assume NAT devices are part of a trusted boundary, tunnel mode IPsec can be done with a NAT router (or a NAT, ALG and firewall combo) acting as the tunnel end point 🎀.
NAT devices combined with ALGs can make sure the datagrams injected into the Internet have no private addresses in their headers or payloads 🧚. Applications that don't meet these requirements may get dropped by firewall filters 🚫. That's why it's super common to see NAT, ALG and firewall functions all hanging out together to protect the borders of a private network 👑. NAT gateways can also be used as tunnel end points to give secure VPN transport of packet data across an external network domain 🦋.
Here are some extra security considerations for NAT routers 👀:
- UDP sessions are inherently unsafe. Responses to a datagram could come from an address that's different from the target address the sender used ([Ref 4]) 😬. So an incoming UDP packet might only partly match the outbound session of a traditional NAT router. The destination address and UDP port number might match, but the source address and port number might not. In that case, the NAT device could be opening itself up to a potential security compromise by letting inbound packets with a partial match through 🚨. This UDP security issue is also inherent to firewalls, so it's not just a NAT thing 💅.
Traditional NAT implementations that don't track datagrams on a per-session basis, and instead lump the states of multiple UDP sessions using the same address binding into a single unified session, could make security even worse 😭. That's because the granularity of packet matching gets limited even further, down to just the destination address of the inbound UDP packets.
- Multicast sessions (UDP based) are another source of weakness for traditional NAT routers. Once again, firewalls face the same security dilemma as NAT routers 🤷♀️.
Say a host on the private network starts a multicast session. The datagram it sends could trigger responses in the reverse direction from multiple external hosts 📡. Traditional NAT implementations that use a single state to track a multicast session can't figure out for sure whether an incoming UDP packet is a response to an existing multicast session, or the start of a brand new UDP session started by an attacker 👻.
- NAT devices can be a target for attacks.
Since NAT devices are Internet hosts, they can be the target of a bunch of different attacks, like SYN flood and ping flood attacks 🌊. NAT devices should employ the same sort of protection techniques that Internet-based servers do 🛡️.
REFERENCES 📚
- [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October, 1994.
- [3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
- [4] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
- [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
- [6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
- [7] Postel, J., "Transmission Control Protocol (TCP) Specification", STD 7, RFC 793, September 1981.
- [8] Postel, J., "Internet Control Message Protocol Specification" STD 5, RFC 792, September 1981.
- [9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
- [10] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
- [11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
- [12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [16] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
- [17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
- [18] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
Authors' Addresses 💌
Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Phone: (925) 737-2153
Fax: (925) 737-2110
EMail: srisuresh@lucent.com
Matt Holdrege
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502
Phone: (510) 769-6001
EMail: holdrege@lucent.comFull Copyright Statement ©
Copyright (C) The Internet Society (1999). All Rights Reserved.
Anyone can copy and hand out this document and translations of it, and make derivative works that comment on or explain it or help with implementing it. You can publish and distribute those copies and derivative works, in whole or in part, with no restrictions at all 🌈. The one condition is that the copyright notice and this paragraph stay on all those copies and derivative works. The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then the Internet Standards process copyright procedures have to be followed), or when it's required to translate it into a language other than English 🌍.
The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️.
This document and the information in it are 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 ✨.
📦 where this page comes from
- ietf: rfc2663 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms