RFC 4787
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP ✨
Network Working Group, Request for Comments 4787 🎀 (part 1 of 7, so more is coming bestie 🫶)
BCP: 127 💖 Category: Best Current Practice 🌸 Date: January 2007 📅 Authors: F. Audet, Ed. from Nortel Networks, and C. Jennings from Cisco Systems 👑 Obsoletes / Updates: The title block doesn't list anything for either field, so this one doesn't obsolete or update any other RFC 🦋
Status of This Memo
This document specifies an Internet Best Current Practices for the Internet Community, and asks for discussion and suggestions for improvements. You can distribute this memo freely, with no limits 🌈
Copyright Notice
Copyright (C) The IETF Trust (2007). 💜
Abstract
Okay so this document sets up the basic vocab for describing the different kinds of Network Address Translation (NAT) behavior when it's handling Unicast UDP 🦋 It also lays out a list of requirements that would let lots of apps, like multimedia calls or online gaming, just work consistently 🎮 Build NATs that meet these requirements and you'll make it way more likely those apps actually function properly. Main character energy for the internet 💅
Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Address and Port Translation Behavior . . . . . . . . 5
4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5
4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 9
4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 11
4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 12
4.4. Conflicting Internal and External IP Address Spaces . . . 13
5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 15
6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16
7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17
8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 18
9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19
10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 20
11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Security Considerations . . . . . . . . . . . . . . . . . . . 24
14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . . 261. Applicability Statement 🧚
So the goal here is to define a set of requirements for NATs that lets lots of apps, like multimedia calls or online gaming, work consistently 🎮 Build NATs that meet these requirements and you'll make it way more likely those apps function properly.
The requirements in this specification apply to Traditional NATs as described in [RFC2663].
This document covers NATs of every size, from tiny home NATs all the way up to big Enterprise NATs 🏢 That said, Enterprise NATs usually do way more than just NAT stuff. For example, they typically handle firewall functionality too 🔥 A full description of firewall behaviors and their requirements is specifically out of scope here. This spec does cover the basic firewall parts that show up in NATs though (see Section 5) ✨
Approaches that use directly signaled control of middle boxes are out of scope 🚫
UDP Relays (e.g., Traversal Using Relay NAT [TURN]) are out of scope 🚫
Application aspects are out of scope too, since the focus is strictly on the NAT itself 💅
This document only covers aspects of NAT traversal related to Unicast UDP [RFC0768] over IP [RFC0791], and their dependencies on other protocols 🦋
2. Introduction 🌸
Okay so Network Address Translators (NATs) are famously chaotic with applications that carry IP addresses inside the payload (see [RFC3027]) 😭 This includes Voice Over IP and Multimedia Over IP, like SIP [RFC3261] and H.323 [ITU.H323], plus online gaming.
There are a bunch of techniques people use to try to get realtime multimedia apps, online games, and other stuff working across NATs. Application Level Gateways [RFC2663] are one of them. STUN [RFC3489bis] describes a UNilateral Self-Address Fixing (UNSAF) mechanism [RFC3424]. Teredo [RFC4380] describes an UNSAF mechanism that tunnels IPv6 [RFC2460] over UDP/IPv4. UDP Relays have also been used to get apps across NATs, but they're generally seen as a solution of last resort 🥲 Interactive Connectivity Establishment [ICE] describes a way to use many of these techniques while avoiding a UDP relay, unless the type of NAT forces the use of one. This specification defines requirements for improving NATs. Meeting these requirements means applications won't be forced to use a UDP relay 🙌
As UNSAF [RFC3424] points out, "From observations of deployed networks, it is clear that different NAT box implementations vary widely in terms of how they handle different traffic and addressing cases". 🙈 That huge amount of variability is a big reason NATs are so brittle, and it makes it super hard to predict how any given protocol will act when it crosses a NAT. Lots of the major NAT vendors have said they'd rather deploy NATs that were deterministic and caused the least harm to applications, while still meeting the requirements that made their customers deploy NATs in the first place 💖 The problem is that vendors aren't sure how to do that, or how to document how their NATs behave.
The goals of this document are to define common terminology for describing NAT behavior, and to produce a set of requirements on a specific set of NAT behaviors ✨
This document forms a common set of requirements that are simple and useful for voice, video, and games, and that NAT vendors can implement 🎀 It will simplify analyzing whether protocols work in this environment, and it lets providers of services with NAT traversal issues say where their apps will and won't work, plus specify their own NAT requirements 🧁
3. Terminology 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🫶
Go read [RFC2663] for NAT taxonomy and terminology 📖 Traditional NAT is the most commonly deployed type of NAT device. You can check out [RFC3022] for detailed info on traditional NAT. Traditional NAT comes in two main flavors: Basic NAT and Network Address/Port Translator (NAPT).
NAPT is by far the most commonly deployed NAT device 👑 NAPT lets multiple internal hosts share a single public IP address at the same time. When an internal host opens an outgoing TCP or UDP session through a NAPT, the NAPT gives that session a public IP address and port number. That way, response packets from the external endpoint can get received by the NAPT, translated, and forwarded to the internal host 🦋 So basically, the NAPT sets up a NAT session that translates the (private IP address, private port number) tuple to a (public IP address, public port number) tuple, and vice versa, for as long as the session lasts. Something that matters a lot for peer-to-peer apps is how the NAT behaves when one internal host starts multiple simultaneous sessions from a single (private IP, private port) endpoint to multiple distinct endpoints on the external network 👀 In this specification, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)" 💅
This document uses the term "session" as defined in RFC 2663: "TCP/ UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP ports, target IP address, target TCP/UDP Port)" 🔥
This document uses the term "address and port mapping" for the translation between an external address and port and an internal address and port. Heads up that this is NOT the same thing as an "address binding" as defined in RFC 2663 ⚠️
This document uses IANA terminology for port ranges. So "Well Known Ports" is 0-1023, "Registered" is 1024-49151, and "Dynamic and/or Private" is 49152-65535, as defined at http://www.iana.org/assignments/port-numbers 🌈
STUN [RFC3489] used the terms "Full Cone", "Restricted Cone", "Port Restricted Cone", and "Symmetric" to refer to different variations of NATs that apply to UDP only. Honestly, this terminology has caused a LOT of confusion, because it turned out to be inadequate at describing real-life NAT behavior 😩 So this specification refers to specific individual NAT behaviors instead of using the Cone/Symmetric terminology ✨
4. Network Address and Port Translation Behavior 💖
This section describes the various NAT behaviors that apply to NATs. 🧚
More parts are coming, so stay tuned bestie 💜
4.1. Address and Port Mapping ✨
okay so bestie, when an internal endpoint opens an outgoing session through a NAT, the NAT gives that session an external IP address and port number 🦋. That way, when replies come back from the external endpoint, the NAT can catch them, translate them, and forward them to the right internal endpoint 💖. This pairing of an internal IP:port with an external IP:port is called a mapping, and it's the translation the NAT keeps using for as long as the session lasts 🎀. For a lot of apps, it really matters how the NAT acts when you've got several sessions going to different external endpoints at once 💅.
So the big question is when a NAT is allowed to reuse a mapping for a new session to a different external endpoint 👀. Say the internal X:x gets mapped to X1':x1' for the first session. Then X:x sends to some other external address Y2:y2 and gets X2':x2' on the NAT. How X1':x1' and X2':x2' relate to each other, depending on how Y1:y1 and Y2:y2 relate, is the thing that defines how the NAT behaves 🌸. Here's the picture:
E
+------+ +------+ x
| Y1 | | Y2 | t
+--+---+ +---+--+ e
| Y1:y1 Y2:y2 | r
+----------+ +----------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+-+
...........| NAT |...............
+--+---+-+ I
| | n
X:x | | X:x t
++---++ e
| X | r
+-----+ n
a
l
Address and Port MappingThere are three possible mapping behaviors, and they go like this 🧚:
Endpoint-Independent Mapping:
The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. 🌈
Address-Dependent Mapping:
The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port. Specifically, X1':x1' equals X2':x2' if and only if, Y2 equals Y1. 🍓
Address and Port-Dependent Mapping:
The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address and port while the mapping is still active. Specifically, X1':x1' equals X2':x2' if and only if, Y2:y2 equals Y1:y1. 💜
Now the plot twist 🙈: these three choices make no difference to the NAT's security properties. The security properties come down entirely to which packets the NAT lets in and which it blocks, and that's decided by the filtering behavior in the filtering portions of the NAT 🔥.
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
Justification: For UNSAF methods to work, REQ-1 has to be met 🫶. If REQ-1 isn't met, you're forced into using a UDP relay, and those are very often impractical 💀.
Some NATs can pull IP addresses from a pool on the external side, instead of just using one single IP address 🌟. This is super common with bigger NATs. Some NATs use the external IP address mapping in an arbitrary (aka random) way, so one internal IP address could have several external IP address mappings active at the same time for different sessions 😭. These NATs have an "IP address pooling" behavior of "Arbitrary". Some big Enterprise NATs use "Arbitrary" pooling on purpose to hide which IP address belongs to which endpoint, by making the assignment harder to predict 🕵️♀️. Other NATs use the same external IP address for every session tied to the same internal IP address. These NATs have an "IP address pooling" behavior of "Paired". Now, NATs with "Arbitrary" pooling can cause problems for apps that use several ports from the same endpoint without negotiating IP addresses for each one separately (for example, some apps using RTP and RTCP) 😬.
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling.
Justification: Paired pooling lets apps that use multiple ports from the same internal IP address also end up with the same external IP address 💖. This keeps peer-to-peer apps from breaking when they can't negotiate the IP address for RTP and the IP address for RTCP separately 🎀. It's expected that this requirement will matter less over time, as apps get more NAT-friendly 🌷. The main reason it's here is that in a peer-to-peer app, you're at the mercy of the other peer's mistakes 😤. For example, in the context of SIP, if my app supports the extensions defined in [RFC3605] for signaling RTP and RTCP addresses and ports separately, but the other peer doesn't, you can still get breakage, like the stream losing RTCP packets 💔. This requirement stops RTP from getting lost in that situation, although losing RTCP may be unavoidable in this particular example ✨. Also, RFC 3605 is unfortunately not a mandatory part of SIP [RFC3261], so this requirement is tackling a seriously nasty problem that's going to stick around for a good while 💀🫠.
4.2. Port Assignment 🎀
4.2.1. Port Assignment Behavior 🦋
This section uses the following diagram as a reference 👀:
E
+-------+ +-------+ x
| Y1 | | Y2 | t
+---+---+ +---+---+ e
| Y1:y1 Y2:y2 | r
+---------+ +---------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+--+
...........| NAT |...............
+--+---+--+ I
| | n
+---------+ +---------+ t
| X1:x1 X2:x2 | e
+---+---+ +---+---+ r
| X1 | | X2 | n
+-------+ +-------+ a
l
Port AssignmentSome NATs try to keep the port number that was used internally when they assign a mapping to an external IP address and port (for example, x1=x1', x2=x2') 🧚. This port assignment behavior is called "port preservation". When there's a port collision, these NATs try a bunch of different tricks to cope 🤹♀️. For example, some NATs will overridden the previous mapping to keep the same port 😳. Other NATs will assign a different IP address from a pool of external IP addresses, but that only works as long as the NAT has enough external IP addresses. If the port is already in use on every available external IP address, these NATs will pick a different port instead (aka they stop doing port preservation) 🙃.
Some NATs use "Port overloading", which means they always do port preservation, even when there's a collision (so X1'=X2' and x1=x2=x1'=x2') 🔥. Most applications will fail if the NAT uses "Port overloading" 💀.
A NAT that doesn't try to make the external port numbers match the internal port numbers in any case is called "no port preservation" 🌸.
When NATs allocate a new source port, there's the question of which IANA-defined port range to pick 🌈. The ranges are "well-known" from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/private" from 49152 through 65535 🍓. For most protocols these are destination ports and not source ports, so mapping a source port onto a source port that's already registered is unlikely to cause any bad effects 💜. Some NATs might only use ports in the dynamic range, and the only downside of that is it limits how many ports are available ⭐. Other NAT devices might use everything except the well-known range, and they might prefer the dynamic range first, or maybe avoid the actual registered ports in the registered range 🫶. Other NATs keep the port range if it's in the well-known range 🎀. [RFC0768] specifies that the source port is set to zero if no reply packets are expected 👀. In that case, it doesn't matter what the NAT maps it to, since the source port won't be used 🤷♀️. However, many common OS APIs don't let a user send from port zero, applications don't use port zero, and how various existing NATs handle a packet with a source port of zero is unknown 😭. This document doesn't specify any normative behavior for a NAT handling a packet with a source port of zero, which means applications can't count on any kind of deterministic behavior for these packets 🙈.
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading".
a) If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range. ✨
Justification: This requirement has to be met so that two applications on the internal side of the NAT can both use the same port to try to talk to the same destination 💖. NATs that do port preservation have to deal with port conflicts, and the multiple code paths that creates often lead to nondeterministic behavior 🌀. However, you should understand that when a port is randomly assigned, it may just randomly end up being the same port 🎲. So applications must be able to deal with both port preservation and no port preservation 💅.
a) Certain applications expect the source UDP port to be in the well-known range. See the discussion of Network File System port expectations in [RFC2623] for an example. 🦋
4.2.2. Port Parity 🎀
Some NATs keep the parity of the UDP port, so an even port gets mapped to an even port and an odd port gets mapped to an odd port. ✨ This is bestie behavior, because it respects the [RFC3550] rule that RTP uses even ports and RTCP uses odd ports. RFC 3550 does allow any port numbers for RTP and RTCP as long as the two are specified separately, for example using [RFC3605]. 💅 But some implementations don't include RFC 3605, so they can't tell when the peer has specified the RTCP port separately. 🙈 Say one of these implementations gets an odd RTP port from its peer (maybe after a NAT translated it) and then follows the RFC 3550 rule to change the RTP port to the next lower even number. That would obviously lose RTP. 💀 NAT-friendly application aspects are outside the scope of this document. The hope is that this issue fades away as implementations improve. 🌈 Preserving port parity also lets you talk to peers that don't support explicitly specifying both the RTP and RTCP port numbers, which is iconic.
REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes". 🫶
Justification: This is to avoid breaking peer-to-peer applications that don't explicitly and separately specify the RTP and RTCP port numbers, and that follow the RFC 3550 rule to decrement an odd RTP port to make it even. The same considerations apply as for the IP address pooling requirement. 🍓
4.2.3. Port Contiguity 🦋
Some NATs try to keep the port contiguity rule of RTCP=RTP+1 working. 🧚 They do things like sequential assignment or port reservation. Sequential port assignment assumes the application opens a mapping for RTP first and then opens a mapping for RTCP, and it is not practical to enforce that on all applications. 😭 There's also a glare problem if lots of applications (or endpoints) try to open mappings at the same time. Port preservation is also problematic because it's wasteful, especially since a NAT can't reliably tell RTP over UDP apart from other UDP packets that have no contiguity rule. For those reasons, it would be too complex to try preserving the contiguity rule by suggesting specific NAT behavior, and it would definitely break the deterministic behavior rule. 🔥
So, to support both RTP and RTCP, applications will need to follow rules to negotiate RTP and RTCP separately, and they have to account for the very real possibility that the RTCP=RTP+1 rule gets broken. ✨ Since this is an application requirement, it's outside the scope of this document. 🎀
4.3. Mapping Refresh ⏰
NAT mapping timeout implementations vary, but they include the timer's value and the way the mapping timer gets refreshed to keep the mapping alive. 💖
The mapping timer is defined as the time a mapping stays active without packets traversing the NAT. There's a huge amount of variation in the values different NATs use. 🌸
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies. 🫶
a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port.
b) The value of the NAT UDP mapping timer MAY be configurable.
c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED. ⭐
Justification: This requirement makes sure the timeout is long enough to avoid too-frequent timer refresh packets. 🧁
a) Some UDP protocols use very short-lived connections. There can be loads of these, and keeping them all in a connections table could put considerable load on the NAT. So having shorter timers for these specific applications is an optimization technique. 🦄 It's important that the shorter timers for specific protocols get used sparingly, and only for protocols on well-known destination ports that are known to have a shorter timer and known not to be used by any applications for other purposes. 🙅♀️
b) Configuration is desirable for adapting to specific networks and for troubleshooting. 🔧
c) This default is there to avoid too-frequent timer refresh packets. 🫧
Some NATs keep the mapping active (meaning they refresh the timer value) when a packet goes from the internal side of the NAT to the external side. This is referred to as having a NAT Outbound refresh behavior of "True". 🌷
Some NATs keep the mapping active when a packet goes from the external side of the NAT to the internal side. This is referred to as having a NAT Inbound Refresh Behavior of "True". 🦋
Some NATs keep the mapping active on both, and in that case both properties are "True". 👑
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True". 💅
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound refresh behavior" of "True".
Justification: Outbound refresh is necessary so the client can keep the mapping alive. 🌈
a) Inbound refresh may be useful for applications with no outgoing UDP traffic. BUT allowing inbound refresh may let an external attacker or a misbehaving application keep a mapping alive forever. 🚨 That's a security risk, periodt. Also, if the process is repeated with different ports over time, it could use up all the ports on the NAT. 😱
4.4. Conflicting Internal and External IP Address Spaces 🌍
Lots of NATs, especially consumer-level devices that nontechnical people are supposed to just plug in, routinely get their external IP address, default router, and other IP configuration info for their external interface dynamically from an external network, like an upstream ISP. 🛜 The NAT then automatically sets up its own internal subnet in one of the private IP address spaces set aside for this in [RFC1918], and usually it hands out dynamic IP configuration to hosts on that internal network. 🏠
Auto-configuration of NATs and private networks can get messy, though, if the NAT's external network is also in RFC 1918 private address space. 🥴 A common scenario is an ISP putting its customers behind a NAT and handing them private RFC 1918 addresses. Some of those customers then deploy consumer-level NATs, which effectively act as "second-level" NATs, multiplexing their own private RFC 1918 IP subnets onto the single RFC 1918 IP address the ISP gave them. 🤯 In that case there's no inherent guarantee that the ISP's "intermediate" privately-addressed network and the customer's internal privately-addressed network won't use numerically identical or overlapping RFC 1918 IP subnets. And customers of consumer-level NATs can't be expected to have the technical knowledge to prevent this by manually configuring their internal network with non-conflicting RFC 1918 subnets. 😩
NAT vendors need to design their NATs so they keep working correctly and robustly even in these problematic scenarios. 🛠️ One possible solution is for the NAT to make sure that whenever its external link is configured with an RFC 1918 private IP address, it automatically selects a different, non-conflicting RFC 1918 IP subnet for its internal network. The downside is that if the NAT's external interface gets dynamically configured or reconfigured after the internal network is already in use, the NAT may have to renumber its entire internal network on the fly if it detects a conflict. 😵💫
An alternative solution is for the NAT to be designed so it can translate and forward traffic correctly even when its external and internal interfaces are configured with numerically overlapping IP subnets. 🧩 For example, if the NAT's external interface has been assigned an IP address P in RFC 1918 space, there might also be an internal node I with that same RFC 1918 private IP address P. An IP packet with destination address P on the external network is directed at the NAT, but an IP packet with the same destination address P on the internal network is directed at node I. So the NAT needs to keep a clear operational distinction between "external IP addresses" and "internal IP addresses," so it doesn't confuse internal node I with its own external interface. 🫣 In general, the NAT needs to let all internal nodes (including I) communicate with all external nodes that have public (non-RFC 1918) IP addresses, or that have private IP addresses that don't conflict with the addresses used by its internal network. 🌟
REQ-7: A NAT device whose external IP interface can be configured dynamically MUST either (1) automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or (2) be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses numerically conflict with the internal network. 🙌
Justification: If a NAT's external and internal interfaces are configured with overlapping IP subnets, there's of course no way for an internal host with RFC 1918 IP address Q to start a direct session with an external node that has the same RFC 1918 address Q, or with other external nodes whose IP addresses numerically conflict with the internal subnet. 😭 Those nodes can still open sessions indirectly via NAT traversal techniques, with the help of a third-party server such as a STUN server that has a public, non-RFC 1918 IP address. 🛰️ In that case, nodes with conflicting private RFC 1918 addresses on opposite sides of the second-level NAT can talk to each other through their respective temporary public endpoints on the main Internet, as long as their common first-level NAT (for example, the upstream ISP's NAT) supports hairpinning behavior, as described in Section 6. 💜
5. Filtering Behavior ✨
okay bestie, this section is all about the filtering behaviors NATs show off 💅 when packets come knocking from outside 🚪
When an internal endpoint opens an outgoing session through a NAT, the NAT assigns a filtering rule for the mapping between an internal IP:port (X:x) and external IP:port (Y:y) tuple. 🎀
The big question is what criteria the NAT uses to filter packets coming from specific external endpoints. 🤔
Endpoint-Independent Filtering
this one is giving open door policy 🚪✨ The NAT filters out only the packets that aren't destined for the internal address and port X:x, no matter what external IP address and port source (Z:z) they came from. Any packets destined for X:x get forwarded. So basically, sending packets from the internal side of the NAT to any external IP address is enough to let any packets come back to the internal endpoint 🦋
Address-Dependent Filtering
this one is a little pickier 👀 The NAT filters out packets that aren't destined for the internal address X:x. On top of that, it will also filter out packets from Y:y headed to X:x if X:x hasn't sent packets to Y:any before (independently of the port used by Y). So to receive packets from a specific external endpoint, the internal endpoint has to send packets to that endpoint's IP address first 💌
Address and Port-Dependent Filtering
this is basically the same energy as the last one, except now the external port matters too 🧚 The NAT filters out packets that aren't destined for the internal address X:x. It also filters out packets from Y:y headed to X:x if X:x hasn't sent packets to Y:y before. So to receive packets from a specific external endpoint, the internal endpoint has to send packets first to that external endpoint's IP address and port 🌸
REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior.
- a) The filtering behavior MAY be an option configurable by the administrator of the NAT.
Justification: okay so the whole reason we push Endpoint-Independent Filtering is to keep apps as transparent as possible 🫶 That matters most for apps that get media from several places at once (think gaming 🎮) or apps that use rendezvous techniques. Still, sometimes a stricter filtering behavior is the better move 🔒 Filtering that doesn't depend on the external endpoint is less secure: an unauthorized packet could sneak through a specific port while that port is open, if it happens to find that port open. In theory, filtering on both IP address and port is more secure than filtering on IP address alone, because the external endpoint could actually be two endpoints behind another NAT, where one of them is an attacker 😈 The catch is that this kind of policy can interfere with applications that expect to receive UDP packets on more than one UDP port 😬
There's also a benefit to using Endpoint-Independent Filtering or Address-Dependent Filtering instead of Address and Port-Dependent Filtering on a NAT (let's call it NAT-A) 💖 That's true when the other endpoint is behind a non-BEHAVE compliant NAT (NAT-B) that doesn't support REQ-1. When the endpoints use ICE and NAT-A uses Address and Port-Dependent Filtering, connectivity will require a UDP relay. But if NAT-A uses Endpoint-Independent Filtering or Address-Dependent Filtering, ICE will ultimately find connectivity without needing a UDP relay ✨ Making the filtering behavior an option the NAT administrator can configure means a NAT can be used in the widest variety of deployment scenarios 🌈
6. Hairpinning Behavior 🧷
so picture this 👯 If two hosts (X1 and X2) are behind the same NAT and talking to each other, the NAT may allocate an address on the outside of the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it goes to the NAT, which must relay the traffic from X1 to X2. This is called hairpinning, and it's drawn out below 🎀
NAT
+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
+----+ | v |
| v |
| v |
| v |
+----+ from X1':x1' to X2:x2 | v | X2':x2'
| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
+----+ +-----+
Hairpinning BehaviorHairpinning lets two endpoints on the internal side of the NAT talk to each other even if they only use each other's external IP addresses and ports 🥰
Here's the more formal version 🤓 A NAT that supports hairpinning forwards packets that come from an internal address, X1:x1, and are destined for an external address X2':x2' with an active mapping to an internal address X2:x2, back to that internal address, X2:x2. Note that X1' is typically the same as X2' 💜
The NAT may also show the hairpinned packet with either an internal (X1:x1) or an external (X1':x1') source IP address and port. So the hairpinning NAT behavior can be either "External source IP address and port" or "Internal source IP address and port". Heads up, though: "Internal source IP address and port" may cause problems by confusing implementations that expect an external IP address and port 🙈
REQ-9: A NAT MUST support "Hairpinning".
- a) A NAT Hairpinning behavior MUST be "External source IP address and port".
Justification: this requirement exists so that two endpoints behind the same NAT can communicate when they're trying each other's external IP addresses 🫂
- a) Using the external source IP address is necessary for applications with a restrictive policy of not accepting packets from IP addresses that differ from what they expect 🔐
7. Application Level Gateways 🧚♀️
Certain NATs have implemented Application Level Gateways (ALGs) for various protocols, including protocols for negotiating peer-to-peer sessions, such as SIP 📞
Some NATs have these ALGs turned on permanently 🔒, some have them turned on by default but let you turn them off, and others have them turned off by default but let you turn them on 🔛
NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware, so they have to be used with extreme caution 😱
REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off. Future standards track specifications that define ALGs can update this to recommend the defaults for the ALGs that they define.
- a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately.
Justification: NAT ALGs may interfere with UNSAF methods 🙃
- a) This requirement lets the user turn on the ALGs that some applications need to work, without turning on ALGs that would break other applications 🧩
8. Deterministic Properties 🎲
ngl this section is where it gets messy 🌀 Classifying NATs is complicated by the fact that, under some conditions, the same NAT will show different behaviors. This has been seen on NATs that preserve ports, or that have specific algorithms for picking a port other than a free one. If the external port the NAT wants to use is already in use by another session, the NAT must pick a different port. That creates different code paths for this conflict case, and those paths lead to different behavior 😭
For example, say three hosts X1, X2, and X3 all send from the same port x through a port preserving NAT with only one external IP address, called X1'. The first one to send (X1) gets an external port of x, but the next two get x2' and x3' (neither of which is equal to x). Some NATs change their External NAT mapping characteristics and their External Filter characteristics between the X1:x and X2:x mappings. To make things worse, some NATs behave the same on the X1:x and X2:x mappings but differently on the third X3:x mapping 🤯
Here's another one 💀 Some NATs have "Endpoint-Independent Mapping" combined with "Port Overloading", as long as two endpoints aren't establishing sessions to the same external direction. But once they detect those conflicting session establishments, they switch to "Address and Port-Dependent Mapping" without "Port Preservation".
Any NAT that changes its NAT Mapping or Filtering behavior without configuration changes, at any point in time, under any particular conditions, is called a "non-deterministic" NAT. NATs that don't do this are called "deterministic" ✅
Non-deterministic NATs usually change behavior when some kind of conflict happens, that is, when the port that would normally be used is already in use by another mapping. The NAT mapping and External Filtering when there's no conflict is called the Primary behavior. The behavior after the first conflict is called Secondary, and the behavior after the second conflict is called Tertiary. No NATs have been observed that change on further conflicts, but it's certainly possible that they exist 👀
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT translation (Section 4) or the Filtering (Section 5) Behavior at any point in time, or under any particular conditions.
Justification: Non-deterministic NATs are really hard to troubleshoot because they need more intensive testing 🥲 This non-deterministic behavior is the root cause of a lot of the uncertainty NATs introduce about whether or not applications will work 🫠
9. ICMP Destination Unreachable Behavior 🧚
okay so when a NAT sends a packet toward a host on the other side, an ICMP message can come back in response to it 📨. That ICMP message might be sent by the destination host, or by any router along the network path 🛣️. The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. Such ICMP messages SHOULD be rewritten by the NAT (specifically, the IP headers and the ICMP payload) and forwarded to the right internal or external host 💌. The NAT needs to keep doing this for as long as the UDP mapping is active ⏰. Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping 🙅♀️. A NAT that does everything in the paragraph above is called "support ICMP Processing" 💅.
There is no real security advantage to blocking ICMP Destination Unreachable packets 🔒. Blocking them can also mess things up for application failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and traceroute 😬. Blocking any ICMP message is discouraged, and blocking ICMP Destination Unreachable is strongly discouraged 🚫.
- REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping.
- a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address.
- b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages.
Justification: This is easy to do, it's used for a bunch of stuff (MTU discovery and quickly spotting error conditions, to name a couple), and it has no downsides 🙌.
10. Fragmentation of Outgoing Packets 🧩
When the MTU of the adjacent link is too small, packets going from the internal side to the external side of the NAT might get fragmented 🪓. This can happen if the NAT is doing Point-to-Point over Ethernet (PPPoE), or if the NAT was configured with a small MTU so large packets don't hold up small high-priority ones, or for other reasons 🤷♀️.
Worth knowing: a lot of IP stacks don't use Path MTU Discovery with UDP packets 👀.
The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 (DF=0) 🎀.
- REQ-13: If the packet received on an internal IP address has DF=1, the NAT MUST send back an ICMP message "Fragmentation needed and DF set" to the host, as described in [RFC0792].
- a) If the packet has DF=0, the NAT MUST fragment the packet and SHOULD send the fragments in order.
Justification: This is as per RFC 792 📜.
- a) This is the same function a router performs in a similar situation [RFC1812] 🛤️.
11. Receiving Fragmented Packets 📦
For a bunch of reasons, a NAT might receive a fragmented packet 🧃. The IP packet containing the header could show up in any fragment, depending on network conditions, packet ordering, and how the IP stack that made the fragments works 🌀.
A NAT that can only receive fragments in order (meaning the header is in the first packet) and forward each fragment to the internal host is described as "Received Fragments Ordered" 🧾.
A NAT that can receive fragments in or out of order and forward the individual fragments (or a reassembled packet) to the internal host is referred to as "Receive Fragments Out of Order" 🔀. Check the Security Considerations section of this document for the full scoop on this behavior 🕵️♀️.
A NAT that is neither of these is referred to as "Receive Fragments None" 🫥.
- REQ-14: A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior.
- a) A NAT's out-of-order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets.
Justification: See Security Considerations 🔐.
12. Requirements 📋
The requirements in this section are all about cutting down the headaches NATs cause for apps, like realtime communications and online gaming 🎮. The requirements listed earlier in the document are gathered up here into one section, so you don't have to hunt 🫶.
It should be understood, though, that applications normally don't know in advance whether the NAT follows the recommendations in this section 🤞. Peer-to-peer media apps still need to use normal procedures, such as ICE [ICE] 🧊.
A NAT that supports all the mandatory requirements of this specification (i.e., the "MUST") is "compliant with this specification" ✅. A NAT that supports all the requirements of this specification (i.e., including the "RECOMMENDED") is "fully compliant with all the mandatory and recommended requirements of this specification" 👑.
- REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
- REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling.
- REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading".
- a) If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range.
- REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes".
- REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies.
- a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port.
- b) The value of the NAT UDP mapping timer MAY be configurable.
- c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED.
- REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True".
- a) The NAT mapping Refresh Direction MAY have a "NAT Inbound refresh behavior" of "True".
- REQ-7: A NAT device whose external IP interface can be configured dynamically MUST either (1) Automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or (2) Be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses numerically conflict with the internal network.
- REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have "Address-Dependent Filtering" behavior.
- a) The filtering behavior MAY be an option configurable by the administrator of the NAT.
- REQ-9: A NAT MUST support "Hairpinning".
- a) A NAT Hairpinning behavior MUST be "External source IP address and port".
- REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off. Future standards track specifications that define an ALG can update this to recommend the ALGs on which they define default.
- a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately.
- REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT translation (Section 4) or the Filtering (Section 5) Behavior at any point in time, or under any particular conditions.
- REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping.
- a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address.
- b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages.
- REQ-13: If the packet received on an internal IP address has DF=1, the NAT MUST send back an ICMP message "Fragmentation needed and DF set" to the host, as described in [RFC0792].
- a) If the packet has DF=0, the NAT MUST fragment the packet and SHOULD send the fragments in order.
- REQ-14: A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior.
- a) A NAT's out-of-order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets.
13. Security Considerations ✨
okay bestie, NATs get deployed to hit security goals 🔐, and most of what this doc recommends doesn't mess with their security at all. a few things DO, though, so we're spilling the tea on those right here 🫶
the big one is timers 💅. this doc says mapping timers get refreshed on outgoing packets (see REQ-6) and says nothing about whether inbound packets should refresh them too. if inbound packets DO refresh them, an external attacker can keep a mapping alive forever 🙈 and then hit future devices that end up with the same internal address. the lowkey fix: a device that's also the DHCP server for the private address space can clean up mappings when a DHCP lease expires. for unicast UDP (the scope of this doc) inbound refresh might not even feel relevant, but for multicast UDP it's a harder question ✨. future docs are expected to refine the inbound refresh timer rules for multicast. and yes, some devices today already refresh on inbound packets, so it's not hypothetical 👀
next, filters 🎀. this doc recommends that NAT filters be specific to the external IP address only (see REQ-8), not the external IP address and UDP port. people can argue that's less secure than using IP and port, and fair, it's a valid debate 🤷♀️. devices that want to filter on IP and port still comply with these requirements, so no drama there 🦋
now non-deterministic NATs 💀. they're risky from a security point of view, and they're honestly so hard to test because... they're non-deterministic 😭. someone testing one might think it's behaving perfectly, but under different conditions (the kind an attacker can deliberately create) it could act totally different. so these requirements recommend that devices be deterministic. periodt 💜
this doc requires that NATs have an "external NAT mapping is endpoint independent" behavior. the good news is this does NOT lower device security 🙌. what packets are allowed to flow across the device is decided by the external filtering behavior, which is independent of the mapping behavior. separate lanes, no cap 🧚
and then fragments 🧩. when a fragmented packet comes in from the external side and the packets arrive out of order (the initial fragment doesn't show up first), lots of systems just toss the out-of-order packets 🗑️. and since some networks deliver small packets ahead of big ones, you can get a LOT of out-of-order fragments. NATs can deliver these out-of-order packets, but they have to store the out-of-order fragments, which can open a Denial-of-Service (DoS) opportunity if it's done wrong 😬. fragmentation has been a tool in plenty of attacks: some pushed fragmented packets through NATs, others went after the state needed to reassemble fragments. NAT implementers should be aware of [RFC3128] and [RFC1858] 📚 (read them, bestie, they're iconic).
14. IAB Considerations 🌸
the IAB studied "Unilateral Self Address Fixing" (UNSAF). that's the general process where a client tries to figure out its address in another realm on the far side of a NAT, using a collaborative protocol reflection mechanism [RFC3424] 🪞.
this spec is NOT an UNSAF application on its own 🙅♀️. it's a series of requirements for NATs that aim to cut down the negative impact those devices have on peer-to-peer media apps, especially when those apps use UNSAF methods.
Section 3 of UNSAF lists several practical issues with solutions to NAT problems. this doc makes recommendations to reduce the uncertainty and problems caused by those practical issues ✨. UNSAF also lists five architectural considerations. this isn't an UNSAF proposal, but it's still interesting to think about how this work lines up with those five, so here we go 🔍:
- Arch-1: The scope of this is limited to UDP packets in NATs like the ones widely deployed today. The "fix" helps constrain the variability of NATs for true UNSAF solutions such as STUN. 🎯
- Arch-2: This will exit at the same rate that NATs exit. It does not imply any protocol machinery that would continue to live after NATs were gone, or make it more difficult to remove them. 👋
- Arch-3: This does not reduce the overall brittleness of NATs, but will hopefully reduce some of the more outrageous NAT behaviors and make it easer to discuss and predict NAT behavior in given situations. 🙃
- Arch-4: This work and the results [RESULTS] of various NATs represent the most comprehensive work at IETF on what the real issues are with NATs for applications like VoIP. This work and STUN have pointed out, more than anything else, the brittleness NATs introduce and the difficulty of addressing these issues. 📞
- Arch-5: This work and the test results [RESULTS] provide a reference model for what any UNSAF proposal might encounter in deployed NATs. 🧭
15. Acknowledgments 🫶
the editor wants to give a shoutout to Bryan Ford, Pyda Srisuresh, and Dan Kegel for their many contributions on peer-to-peer communications across a NAT 🙌. Dan Wing contributed a ton of text on IP fragmentation and ICMP behavior 🧁. thank you also to Rohan Mahy, Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola, Peter Koch, Jari Arkko, and Alfred Hoenes for their contributions 💖. literally the whole squad 👑
16. References ✨
16.1. Normative References 📌
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.16.2. Informative References 🗂️
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security
Issues and the NFS Protocol's Use of RPCSEC_GSS and
Kerberos V5", RFC 2623, June 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R.
Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", RFC 3489, March 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP)
attribute in Session Description Protocol (SDP)",
RFC 3605, October 2003.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC3489bis] Rosenberg, J., "Simple Traversal Underneath Network
Address Translators (NAT) (STUN)", Work in Progress,
October 2006.
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator
(NAT) Traversal for Offer/Answer Protocols", Work
in Progress, October 2006.
[RESULTS] Jennings, C., "NAT Classification Test Results", Work
in Progress, October 2006.
[TURN] Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal Underneath NAT (STUN)", Work in Progress,
October 2006.
[ITU.H323] "Packet-based Multimedia Communications Systems", ITU-
T Recommendation H.323, July 2003.Authors' Addresses 🎀
Francois Audet (editor)
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 408 495 2456
EMail: audet@nortel.com
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA 95134
US
Phone: +1 408 902 3341
EMail: fluffy@cisco.comFull Copyright Statement 📜
Copyright (C) The IETF Trust (2007).
this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 🔒.
this document and the information contained herein are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 💀.
Intellectual Property
Okay bestie, let's talk about who owns what 💅 The IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) someone might claim over the tech in this doc are valid or how far they reach. It also doesn't say whether any license for them is available 🙈 and it hasn't gone digging to find any such rights, so no promises there. If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📚.
Copies of IPR disclosures made to the IETF Secretariat, any licence assurances that are offered, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr ✨.
The IETF also invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 💌 this is the part where you spill the tea if you spot something 🍓.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society 🫶 thank you, Internet Society, you're the real MVP 👑
📦 where this page comes from
- ietf: rfc4787 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms