RFC 2993
Architectural Implications of NAT
RFC 2993: Architectural Implications of NAT 🦋
(part 1 of 7, more coming bestie 🧚)
The title block, bestie:
- Series: Network Working Group 🌸
- Number: RFC 2993
- Author: T. Hain, from Microsoft 💜
- Category: Informational (it's for the Internet community to learn from, not a standard 🎀)
- Date: November 2000
- Obsoletes / Updates: nothing listed here, so it doesn't replace or change any other RFC 🫶
Status of this Memo ✨
okay so this memo is just information for the Internet community 📖 It is NOT a standard of any kind, and it doesn't specify one. You can share it as much as you want because distribution is unlimited 💅
Copyright Notice 🎀
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🌸
Okay, so NAT (network address translation, RFC-1631) is getting really popular 🔥 This paper is going to dig into some of the architectural implications of it and give some guidelines for implementers 💖 It assumes you already know the address translation concepts from RFC-1631, so if you're confused, go reread that first 🙈
Table of Contents 📋
1. Introduction................................................... 2
2. Terminology.................................................... 4
3. Scope.......................................................... 6
4. End-to-End Model............................................... 7
5. Advantages of NATs............................................. 8
6. Problems with NATs............................................ 10
7. Illustrations................................................. 13
7.1 Single point of failure...................................... 13
7.2. ALG complexity............................................. 14
7.3. TCP state violations........................................ 15
7.4. Symmetric state management................................. 16
7.5. Need for a globally unique FQDN when advertising public
services................................................... 18
7.6. L2TP tunnels increase frequency of address collisions...... 19
7.7. Centralized data collection system report correlation...... 20
8. IPv6.......................................................... 21
9. Security Considerations....................................... 22
10. Deployment Guidelines........................................ 23
11. Summary...................................................... 24
12. References................................................... 27
13. Acknowledgments.............................................. 28
14. Author's Address............................................. 28
15. Full Copyright Statement..................................... 291. Introduction ✨
Okay so this one's a throwback 🕰️ RFC-1631 [2] was published in May 1994, written by K. Egevang and P. Francis, and it defined NAT as one way to slow down how fast IPv4 addresses were getting used up 💅 But the authors were already worried about it 😬 They pointed out, in several places, that we needed to experiment and figure out which applications might get messed up by NAT's header manipulations, even before there was real operational experience. Their conclusion literally says it: 'NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.' Not gonna lie, that's a major plot twist 💀
Now it's six years later, and despite the warning, NATs are everywhere on the Internet 🌈 Some people are calling NAT the short-term and long-term fix for address availability and asking whether we even need to keep developing IPv6 🤨 People also say NAT 'just works' with no serious effects, except on a few legacy applications. Meanwhile, others are seeing a whole bunch of difficulties caused by all this NAT-ing 😭
The pro and con arguments honestly get kinda religious, with each side super passionate about their take 🔥
- Proponents are enthusiastic 💖 They love pointing to the most popular apps, like Mail and Web services, as shining examples of NAT being transparent ✨ They also say NAT is the feature that finally breaks the semantic overload of the IP address, which is being used as both a locator and the global endpoint identifier (EID) 🧚
- Opponents see NAT as a malicious technology, a weed destined to choke out continued Internet development 🥀 They admit there are perceived address shortages, but they think NAT is operationally inadequate at best, and bordering on a sham as an Internet access solution 💀 Reality lies somewhere in between these extreme viewpoints 🫶
Anyway, it's clear that NAT affects the transparency of end-to-end connectivity 🦋 This matters for transports that rely on the IP header staying consistent, and for protocols that carry address information somewhere other than the IP header 👀 People have tried patching things up with a patchwork of consistently configured application specific gateways (ALG's), and that can help endpoints work around some of the operational challenges of NAT 🔧 But those challenges vary a lot depending on the network and application topologies and the specific applications in use 🎀
The simplest case is pretty easy to handle: traffic between two endpoints running over a network with no parallel redundant NAT devices 🌸 Things get complicated fast, though, when there are parallel redundant NAT devices, or when you have more distributed, multi-point applications, like multi-party document sharing 😵💫 Coordinating the updates needed to work around NAT grows geometrically with the number of endpoints 📈 In a big environment, that might take serious, concerted effort to update all the endpoints of a given application or service at the same time 🏃♀️
Here's the architectural intent of NAT: it divides the Internet into independent address administrations (see also "address realms", RFC-2663 [3]) 🗺️ It specifically makes casual use of private address assignments (RFC-1918 [4]) easy 🎀 As Carpenter, et al pointed out in RFC-2101 [5], once private use addresses were deployed in the network, addresses were guaranteed to be ambiguous 🌀 For example, when simple NATs get inserted into the network, resolving names to or from addresses starts to depend on where the question was asked 🤯 Overall, this division enforces a client/server architecture (instead of peer/peer), where the servers need to live in the public address realm 🖥️
A big reason the Internet has been so successful is the flexibility that comes from a few basic tenets 👑 The most important is the End-to-End principle (we'll dig into it more below) ✨ It says certain functions can only be performed in the endpoints, so the endpoints are the ones in control of the communication, and the network should just be a simple datagram service that moves bits between those points 💅 Put another way, the endpoint applications are often the only place that can correctly manage the data stream 🫶 Taking that concern away from the lower layer packet-forwarding devices streamlines the forwarding process, which helps the whole system be more efficient 🚀
Another perk: the network doesn't keep per-connection state information 🧠 That's what allows fast rerouting around failures through alternate paths, and helps the overall network scale better 📶 Not having state also means network nodes don't have to tell each other whenever endpoint connections get formed or dropped 🙌 And the endpoints don't need to be aware of any network components besides the destination, the first hop router(s), and an optional name resolution service 💜 (Endpoints are also not required to know about those other components, so, yeah, they really don't need to.) Packet integrity is preserved through the network, and transport checksums and any address-dependent security functions are valid end-to-end 🔐
Here's the tea ☕ NAT devices (especially the NAPT variety) undermine most of these basic advantages of the end-to-end model 💔 That means less flexibility, often more operational complexity, and harder diagnostics 🙈 NAT variants like RSIP [6] have been proposed recently to address some of the end-to-end concerns 🎀 They might be effective at giving the private node a public address (if ports are available) 🌸 But they don't eliminate several issues, like network state management, upper layer constraints like TCP_TIME_WAIT state, or well-known-port sharing 😬 Their port multiplexing variants also have the same DNS limitations as NAPT, and every host needs significant stack modifications to enable the technology (more on that below) 🛠️
Firewalls also break the end-to-end model, and they raise several of the same issues that NAT devices do, plus a few of their own 🧱 One operational upside to firewalls, though, is that they're usually installed on networks with the explicit intent to interfere with traffic flow 🕵️♀️ So if mysterious problems pop up, people are more likely to understand the issues or at least look at them 👀 The same issues with NAT devices can get overlooked, since NAT devices are often presented as transparent to applications 🥹
One thing that should be clearly stated up front: trying to use a variant of NAT as a simple router replacement may create several significant issues that should be addressed before deployment 🚨 The goal of this document is to discuss these with the intent to raise awareness 💖
2. Terminology 📖✨
Okay bestie, a lot of these terms are properly defined in RFC 2663 [3], so these are the quick summaries we're using in this doc 💅
- NAT 🌸: Network Address Translation, in its simple form, is how IP addresses get mapped from one address administration to another. The NAT function doesn't know anything about the applications going through it, because it only looks at the IP headers 👀
- ALG 🧚: Application Layer Gateway. It gets slotted in between application peers to fake a direct connection when some other protocol or device is blocking direct access. It terminates the transport protocol, and it may change the data stream before forwarding it 🔁
- NAT/ALG 💖: this combines ALG functions with plain NAT. It's usually more useful than pure NAT, because it has built-in pieces for specific applications that would otherwise break going through a pure NAT 🫶
- DNS/ALG 🎀: a special case of NAT/ALG, where an ALG for the DNS service works with the NAT component to change the contents of a DNS response 😭
- Firewall 🛡️: an access control point that might be a special case of an ALG, or it might just be a packet filter 💅
- Proxy 🦋: a relay service that's designed into a protocol, instead of being shoved in arbitrarily. The big difference from an ALG is that the application on at least one end has to know the proxy is there 👑
- Static NAT 💜: gives you a stable one-to-one mapping between address spaces. Very reliable, very predictable, very "I know exactly where you live" 🏠
- Dynamic NAT 🌈: gives you a dynamic mapping between address spaces. It's usually used when there are a relatively large number of addresses on one side (private space) and only a few addresses on the other side (public space) ✨
- NAPT 🍓: Network Address Port Translation gets the job done by multiplexing the transport level identifiers of multiple addresses from one side, all at the same time, into the transport identifiers of a single address on the other side. See 4.1.2 of RFC-2663. This lets multiple endpoints share a single IP address and look like one 🙈
- RSIP 🧚♀️: Realm Specific IP lets endpoints acquire and use the public address and port number at the source. It has mechanisms that let the private node ask for multiple resources at once. RSIP clients have to be aware of the address administration boundaries, which specific administrative area their peer lives in for each application, and the topology for reaching that peer. To finish a connection, the private node client requests one or more addresses and/or ports from the right RSIP server, then starts a connection through that RSIP server using the public resources it got. Hosts must be updated with specific RSIP software to support the tunneling functions ⚠️
- VPN 🔐: for the purposes of this document, Virtual Private Networks basically treat an IP infrastructure as a multiplexing substrate. That means the endpoints can build virtual transit pathways and run another instance of IP over them. The second instance of IP often uses a totally different set of IP addresses 🤯
- AH 🛡️: the IP Authentication Header, from RFC-2401 [7]. It gives you data integrity, data origin authentication, and an optional anti-replay service 💜
- ESP 🔒: the Encapsulating Security Payload protocol, from RFC 2401. It may provide data confidentiality (encryption) and limited traffic flow confidentiality. It also may provide data integrity, data origin authentication, and an anti-replay service 🥰
- Address administration 📋: the coordinator of an address pool that's assigned to a collection of routers and end systems 🗂️
- Addressing realm 🌍: a collection of routers and end systems that exchange locally unique location knowledge. (It's further defined in RFC-2663 NAT Terminology, so go check that out 🤓) NAT is used as a means to distribute address allocation authority, and it gives us a mechanism to map addresses from one address administration into those of another administration 🦋
3. Scope 🔭
Okay so, if we want to talk about how NATs affect the architecture of the Internet, the first thing we have to do is decide what the scope of the Internet even is 🤔 The most basic definition is: a concatenation of networks built using IETF defined technologies. But that doesn't tell apart the public network we all call the Internet from the private networks built with the same technologies (including the ones connected via NAT) 🙃 Rekhter, et al in RFC-1918 defined hosts as public when they need network layer access outside the enterprise, using a globally unambiguous address. Hosts that need limited or no access are defined as private. Another way to look at it is by the transparency of the connection between any given node and the rest of the Internet 👀✨
The ultimate answer to "public or private?" comes down to the intent of the network in question 💅 Generally, networks that don't intend to be part of the greater Internet will use some screening technology to insert a barrier. Historically, barrier devices between the public and private networks were known as Firewalls or Application Gateways, and they were managed to allow approved traffic while blocking everything else 🧱 These days, part of the screening technology is increasingly a NAT, which manages the network locator between the public and private-use address spaces. Then, using ALGs, it adds support for protocols that are incompatible with NAT 🎀 (Using NAT within a private network is possible too, but it's only addressed here in the context where some component of the private network is used as a common transit service between the NAT attached stubs 🌸)
RFC-1631 limited the scope of NAT discussions to stub appendages of a public Internet. In other words, networks with a single connection to the rest of the Internet 🌿 Using NAT in a situation where a network has multiple connections to the rest of the Internet is way more complex than having just one connection, because the NATs have to be coordinated so they have a consistent understanding of the address mapping for each individual device 😵💫 It's giving "everyone has to be on the same page or everything collapses" 📚
4. End-to-End Model 🔁💖
Okay, the End-to-End model is reviewed by Carpenter in Internet Transparency [8], and honestly it's such a good read 📖 One of the key points is "state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks." This is called "fate-sharing" 🫶 The goal behind fate-sharing is robustness. As networks grow, the likelihood of component failures affecting a connection gets more and more frequent. If failures lead to loss of communication because key state is lost, then the network becomes increasingly brittle and its utility degrades 📉 But if an endpoint itself fails, there's no hope of subsequent communication anyway 💀 So the End-to-End model argues that, as much as possible, only the endpoints should hold critical state ✨
Now for NATs, this part of the End-to-End model means the NAT becomes a critical infrastructure element 😭 If it fails, all communication through it fails. And unless great care is taken to make sure its state is consistent and stored stably, even after it recovers, the communication that was passing through it will still fail, because the NAT no longer translates it using the same mappings 🙅♀️ This type of failure is way more severe than a router failing. When a router recovers, any communication it had been forwarding previous can keep being successfully forwarded through it 🌷
There are other important facets to the End-to-End model too 👑
- when state is held in the interior of the network, traffic that depends on that state can't be routed around failures unless the state is somehow replicated to the fail-over points, which can be super difficult to do in a consistent yet efficient and timely way 🥴
- a key principle for scaling networks to large size is pushing state-holding out to the edges of the network. If state is held by elements in the core of the network, then as the network grows, the amount of state those elements must hold grows right along with it. The capacities of those elements can become severe chokepoints, and the number of connections affected by a failure also grows 📈🚨
- if security state must be held inside the network (see the discussion below), then the possible trust models the network can support become restricted 🔐
A network where endpoints don't need to trust network service providers has a ton more security flexibility than one that does 🦋 (Picture a business traveler connecting from their hotel room back to their home office. Should they have to trust the hotel's networking staff with their security keys? Or the staff of the ISP that supplies the hotel with its networking service? What about when the traveler connects over a wireless connection at an airport? ✈️😬)
Related to this, RFC-2101 notes:
Since IP Security authentication headers assume that the addresses in the network header are preserved end-to-end, it is not clear how one could support IP Security-based authentication between a pair of hosts communicating through either an ALG or a NAT.
Plus, there are distributed applications that assume IP addresses are globally scoped, globally routable, and that all hosts and applications have the same view of those addresses 🌍 A standard technique for these applications to manage their additional control and data connections is for one host to send another host the address and port the second host should connect to. NATs break these applications 💔 Similarly, other applications assume that all upper layer ports from a given IP address map to the same endpoint, and port multiplexing technologies like NAPT and RSIP break these. For example, a web server may want to associate a connection to port 80 with one to port 443, but due to the possible presence of a NATPT, the same IP address no longer ensures the same host 🙈
Limiting these applications is not a minor issue 🚫 Much of the Internet's success today is due to how easily new applications can run on endpoints without first requiring upgrades to infrastructure elements 🚀 If new applications must have NATs upgraded in order to achieve widespread deployment, then rapid deployment is hindered and the pace of innovation slows down 🐢💅
5. Advantages of NATs ✨
okay so before we get into the drama, let's look at why NAT is so popular 💅 It's basically the go-to fix for real problems when you use it at the border of a stub domain 🎀
- By masking the address changes that take place, whether from dial-access or provider changes, it minimizes the impact on the local network by avoiding renumbering 🦋
- Globally routable addresses can be reused for intermittent access customers 🌸 This pushes the demand for addresses towards the number of active nodes rather than the total number of nodes 🔥
- There is a potential that ISP provided and managed NATs would lower the support burden 🫶 since there could be a consistent, simple device with a known configuration at the customer end of an access interface ✨
- Breaking the Internet into a collection of address authorities limits the need for continual justification of allocations 💜 and allows network managers to avoid the use of more advanced routing techniques, such as variable length subnets 🧚
- Changes in the hosts may not be necessary for applications that don't rely on the integrity of the packet header, or that carry IP addresses in the payload 🌈
- Like packet filtering firewalls, NAPT, & RSIP block inbound connections to all ports until they are administratively mapped 🛡️💖
Taken together, these explain some of the strong motivations for moving quickly with NAT deployment 😭 Traditional NAT [2] provides a relatively simple function that is easily understood 🍓
Removing hosts that are not currently active lowers address demands on the public Internet, and that's iconic 👑 In cases where providers would otherwise end up with address allocations that could not be aggregated, this improves the load on the routing system and lengthens the lifetime of the IPv4 address space ⭐ Reclaiming idle addresses is a natural byproduct of the existing dynamic allocation of dial-access devices. In the dedicated connection case, though, this service could be provided through a NAT 🔥 And with NAPT, the aggregation potential is even greater, because multiple end systems share a single public address 💅✨
By reducing the potential customer connection options and minimizing the support matrix, it is possible that ISP provided NATs would lower support costs 💸🎀
Part of the motivation for NAT is to avoid the high cost of renumbering that's inherent in the current IPv4 Internet 😩 Guidelines for the assignment of IPv4 addresses, RFC-2050 [9], mean that ISP customers are currently required to renumber their networks if they want to switch to a new ISP 🙈 Using a NAT (or a firewall with NAT functions) means that only the Internet facing IP addresses must be changed, and internal network nodes do not need to be reconfigured 🫶 Localizing address administration to the NAT minimizes renumbering costs, and simultaneously provides a much larger local pool of addresses than is available under current allocation guidelines 🌸 (The registry guidelines are intended to prolong the lifetime of the IPv4 address space and manage routing table growth, until IPv6 is ready or new routing technology reduces the pressure on the routing table 🧚 They do this by managing allocations to match actual demand and by enforcing hierarchical addressing. An unfortunate byproduct of the current guidelines is that they may end up hampering growth in areas where it is difficult to sort out real need from potential hoarding 🥺) NAT is effective at masking provider switching or other requirements to change addresses, and thus mitigates some of the growth issues 💜
NAT deployments have been raising the awareness of protocol designers who are interested in ensuring that their protocols work end-to-end 🧠✨ Breaking the semantic overload of the IP address will force applications to find a more appropriate mechanism for endpoint identification, and it discourages carrying the locator in the data stream 🦋 Since this won't work for legacy applications, RFC-1631 discusses how to look into the packet and make NAT transparent to the application (i.e.: create an application gateway) 🎀 This may not be possible for all applications, such as IP based authentication in SNMP. Even with application gateways in the path, it may be necessary to modify each end host so it's aware when there are intermediaries modifying the data 😭
Another popular practice is hiding a collection of hosts that provide a combined service behind a single IP address (i.e.: web host load sharing) 🌈 In many implementations this is architecturally a NAT, since the addresses are mapped to the real destination on the fly 💅 When packet header integrity is not an issue, this type of virtual host requires no modifications to the remote applications, since the end client is unaware of the mapping activity 🫶 While the virtual host has the CPU performance characteristics of the total set of machines, the processing and I/O capabilities of the NAT/ALG device bound the overall performance, because it funnels the packets back and forth 🚦💀
6. Problems with NATs 💔
Okay bestie, this is the part where NATs get their villain era 😤 Here's the list of everything that goes wrong:
- NATs break the flexible end-to-end model of the Internet. 💔
- NATs create a single point where fates are shared, in the device maintaining connection state and dynamic mapping information. 🫠
- NATs complicate the use of multi-homing by a site in order to increase the reliability of their Internet connectivity. (While single routers are a point of fate sharing, the lack of state in a router makes creating redundancy trivial. Indeed, this is on of the reasons why the Internet protocol suite developed using a connectionless datagram service as its network layer.) 🛣️
- NATs inhibit implementation of security at the IP level. 🔐
- NATs enable casual use of private addresses. These uncoordinated addresses are subject to collisions when companies using these addresses merge or want to directly interconnect using VPNs. 💥
- NATs facilitate concatenating existing private name spaces with the public DNS. 🧵
- Port versions (NAPT and RSIP) increase operational complexity when publicly published services reside on the private side. 😩
- NATs complicate or may even invalidate the authentication mechanism of SNMPv3. 🙈
- Products may embed a NAT function without identifying it as such. 🕵️♀️
Okay so, by design, NATs limit flexibility, which means you really have to sit down and think hard about all the complications they bring 🧠 This is especially true for products where the NAT function is a hidden service, like load balancing routers that rewrite the IP address to other public addresses. Since those addresses can all be in publicly administered space, these are rarely recognized as NATs, but they break the integrity of the end-to-end model just the same. It's giving sneaky 👀
NATs put constraints on applications that carry IP addresses (or address derivatives) in the data stream, and they operate on the assumption that each session is independent. But there are applications like FTP and H.323 that use one or more control sessions to set the characteristics of the follow-on sessions inside their control session payload. Other examples include SNMP MIBs for configuration, and COPS policy messages. These applications assume end-to-end integrity of addresses, so they will fail when traversing a NAT. (TCP was specifically designed to take advantage of, and reuse, the IP address in combination with its ports for use as a transport address. 🧩) To fix how NATs break these applications, an Application Level Gateway needs to exist within or alongside each NAT. Every application that may embed an address in the data stream needs its own extra gateway service. The NAT may also need to assemble fragmented datagrams to enable translation of the application stream, and then adjust TCP sequence numbers, prior to forwarding. That's a LOT of extra work 😭
As noted earlier, NATs break the basic tenet of the Internet that the endpoints are in control of the communication. The original design put state control in the endpoints so there would be no other inherent points of failure. Moving the state from the endpoints to specific nodes in the network reduces flexibility, and it increases the impact of a single point failure. See further discussion in Illustration 1 below. 🎯
Also, NATs are not transparent to all applications, and managing simultaneous updates to a large array of ALGs may cost more than acquiring additional globally routable addresses. See further discussion in Illustration 2 below. 💸
While RSIP addresses the transparency and ALG issues, for the specific case of an individual private host needing public access, there is still a node with state required to maintain the connection. 🫤
Dynamic NAT and RSIP will eventually violate higher layer assumptions about address/port number reuse as defined in RFC-793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is specifically designed to prevent replay of packets between the 4-tuple of IP and port for a given IP address pair. Since the TCP state machine of a node is unaware of any previous use of RSIP, its attempt to connect to the same remote service that its neighbor just released (which is still in TCP_TIME_WAIT) may fail, or with a larger sequence number may open the prior connection directly from TCP_TIME_WAIT state, at the loss of the protection afforded by the TCP_TIME_WAIT state (further discussion in 2.6 of RFC-2663 [3]). ⏳💀
For address translators (which do not translate ports) to comply with the TCP_TIME_WAIT requirements, they must refrain from assigning the same address to a different host until a period of 2*MSL has elapsed since the last use of the address, where MSL is the Maximum Segment Lifetime defined in RFC-793 as two minutes. For address-and-port translators to comply with this requirement, they similarly must refrain from assigning the same host/port pair until 2*MSL has elapsed since the end of its first use. These requirements are simple to state, but they can put a great deal of pressure on the NAT, because they temporarily reduce the pool of available addresses and ports. So it will be tempting for NAT implementers to ignore or shorten the TCP_TIME_WAIT requirements, at the cost of some of TCP's strong reliability. Note that in the case where the strong reliability is in fact compromised by the appearance of an old packet, the failure can show up as the receiver accepting incorrect data. Yikes 😱 See further discussion in Illustration 3 below.
It is sometimes argued that NATs simply function to facilitate "routing realms", where each domain is responsible for finding addresses within its boundaries. That viewpoint clouds the limitations created by NAT with the better-understood need for routing management. Compartmentalization of routing information is correctly a function of routing protocols and their scope of application. NAT is simply a means to distribute address allocation authority, and it provides a mechanism to map addresses from one address realm into those of another realm. 🗺️
In particular, it is sometimes wrongly believed that NATs serve to provide routing isolation. In fact, if someone were to define an OSPF ALG, it would actually be possible to route across a NAT boundary. Rather than NAT providing the boundary, it is the experienced operators who know how to limit network topology that avoid leaking addresses across a NAT. This is an operational necessity, given the potential for leaked addresses to introduce inconsistencies into the public infrastructure. 🧑💻
One of the biggest concerns from the explosion of NATs is the impact on the fledgling efforts at deploying network layer end-to-end IP security. One fundamental issue for IPSec is that with both AH and ESP, the authentication check covers the TCP/UDP checksum (which in turn covers the IP address). When a NAT changes the IP address, the checksum calculation will fail, and therefore authentication is guaranteed to fail. Trying to use the NAT as a security boundary fails when the requirement is end-to-end network layer encryption, since only the endpoints have access to the keys. See further discussion in Illustration 4 below. 🔒
Finally, while the port multiplexing variants of NAT (popular because they allow Internet access through a single address) work modestly well for connecting private hosts to public services, they create management problems for applications connecting from public toward private. The concept of a well-known port is undermined, because only one private side system can be mapped through the single public-side port number. This will affect home networks, when applications like multi-player Internet games can only be played on one system at a time. It will also affect small businesses, when only one system at a time can be operated on the standard port to provide web services. These may sound like only medium-grade restrictions for now, but as a basic property of the Internet, not to change years into the future, it is highly undesirable. The issue is that public-toward-private usage requires administrative mapping for each target prior to connection. If the ISP chooses to provide a standardized version of these to lower configuration options, they may find the support costs of managing the ALGs will exceed the cost of additional address space. See further discussion in Illustration 6 below. 📉
7. Illustrations 🎨
7.1 Single point of failure 💥
A characteristic of stateful devices like NATs is that they create a single point of failure. Trying to avoid this by setting up redundant NATs creates a new set of problems, related to timely communication of the state and to routing-related failures. This covers several issues, such as update frequency, the performance impact of frequent updates, the reliability of the state update transaction, a-priori knowledge of all nodes needing this state information, and notification to end nodes of alternatives. (This notification could be accomplished with a routing protocol, which might require modifications to the hosts so they will listen.) 📡
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet\
----------
--------
Illustration 1In the traditional case, where Access Device (AD) 1 & 2 are routers, the single point of failure is the end Host, and the only effort needed to maintain the connections through a router or link failure is a simple routing update from the surviving router. 🛤️ In the case where the ADs are a NAT variant, there will be connection state maintained in the active path that would need to be shared with alternative NATs. When the Hosts have open connections through either NAT, and it fails, the application connections will drop unless the state had been previously moved to the surviving NAT. The hosts will still need to acquire a routing redirect. In the case of RSIP, the public side address pool would also need to be shared between the ADs to allow movement. This sharing creates another real-time operational complexity, to prevent conflicting assignments at connection setup. NAT as a technology creates a point of fate sharing outside the endpoints, which is in direct contradiction to the original Internet design goals. 😤
7.2. ALG complexity 🧩
In the following example of a proposed corporate network, each NAT/ALG was to be one or more devices at each physical location, and there were to be multiple physical locations per diagrammed connection. Simply updating software at this scale is cumbersome, even when all the devices are the same manufacturer and model. 🥴 While this would also be true with routers, it would be unnecessary for all devices to run a consistent version for an application to work across an arbitrary path. 🛣️
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner Networks
------------------ -------------- ----------------
--------
Illustration 27.3. TCP state violations ✨
Okay so the full range of upper layer architectural assumptions that NAT technologies break might not be well understood without a very large-scale deployment 🌈. Sometimes you need that wild diversity of large-scale use to uncover the unusual failure modes, bestie 🙈. Here's an example of the problem from section 6 💖.
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP|
--------
|
--------
|Internet|
--------
|
---------
| Web |
| Server |
---------
--------
Illustration 3So Host A finishes its transaction and closes the web service on TCP port 80, and the RSIP releases the public side address that Host A was using 🦋. Then Host B tries to open a connection to that same web service. The NAT hands out the next free public side address, which is the exact one A just released 😭. Host B's source port selection rules also happen to land on the same choice A used. The connect request from Host B gets rejected, because the web server is following the TCP specs and keeps that 4-tuple in TIME WAIT for 4 minutes 💀. By the time Host B's complaint about no access reaches the helpdesk, the retry works. The ticket gets marked as resolved, even though it's actually an ongoing but intermittent problem 🙃.
7.4. Symmetric state management 🎀
Operating a network that has a stateful packet modifying device in it is way easier if inbound and outbound packets take the same path 💅. If they don't, it's a total headache to keep the state for both directions in sync 😩. That sounds simple, but even with careful planning it can be hard to manage when you're using a connectionless protocol like IP 🌸. Creating redundant connections comes down to making sure the routes advertised to the private side reach the end nodes and map to the same device as the route advertisements on the public side 👑. This state has to persist for the whole lifetime of every session traversing the NAT, even when internal and external topology keeps churning, whether that churn is frequent or happening all at once 🌪️. Let's look at the case where the X links are broken, or flapping.
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr|
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS|
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
--------
Illustration 4Here's the tea ☕. To keep a consistent view of routing, the best path to the Internet for Routers 1 & 2 goes via NAT1, while the Internet is told that the path to the address pool managed by the NATs is best found through NAT1 🫶. When path X1 breaks, Router 2 would try to switch over to NAT2, but the external return path still runs through NAT1 😤. That's because the NAT1 device is advertising that it has a pool of addresses available. Directly connected routers in this same situation would advertise the specific routes that existed after the loss. So in this case, redundancy was totally useless 💔.
Now let's say the path between Router 1 & 2 is up, but some remote link X2 in the Internet is down. It's also assumed that DNS returns addresses for both NATs when someone queries for Host A or B 🔍. When Host D tries to contact Host B, the request goes through NAT2, but because of the internal routing, the reply comes back through NAT1 🌀. Since the state information for that connection lives in NAT2, NAT1 creates a new mapping instead. Even after the remote path comes back, the connection still won't get made, because the requests go to the public IP of NAT2 while the replies come from the public IP of NAT1 🥲.
In a third case, both Host A & B want to contact Host D while the remote link X2 in the Internet breaks 🫠. As long as path X1 is down, Host B can connect, but Host A is cut off 😭. Unless you have a thorough understanding of the remote topology (which is unlikely, since Internet providers tend to treat that as sensitive proprietary information 🤐), the administrator of Hosts A & B would have no clue why one worked and the other didn't 🤷♀️. As far as they can tell, the redundant paths through the NATs are up, yet only one connection works. Again, this comes down to the lack of visibility into the topology that's built in when a stateful device advertises availability of a pool instead of the networks it's actually connected to 🧠.
In any network topology, failures of individual routers or links can cause problems with insufficient redundancy. But the state maintenance requirements of NAT add an extra burden that is not as easy to understand or fix 💅✨.
7.5. Need for a globally unique FQDN when advertising public services 🌍
The main thing NATs do is give you the 'simple' ability to connect private networks to the public Internet 💖. When the private network already exists before the NAT is installed, its name resolver is unlikely, and unnecessary, to use a registered domain 🙅♀️. As noted in RFC 1123 [12], DNS queries may be resolved via local multicast 📡. Connect the NAT device and reconfigure its resolver to proxy all external requests, and hosts on the private network get access to the public network 🌐. Setting up public DNS for the set of private hosts that need inbound connections, though, would require a registered domain (either private, or from the connecting ISP) and a unique name 🎫. At that point the partitioned name space gets concatenated, and hosts end up with different names depending on whether the query comes from inside or outside 👯.
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS|
--- ---
|NAT|
---
|
-------- ---
|Internet|----|DNS|
-------- ---
|
---
|NAT|
--- ---
|-------------|DNS|
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
--------
Illustration 5Everything in this simple example works fine until an application embeds a name 🙈. For example, a Web service running on Host D might present embedded URLs of the form http://D/bar.html. That would work from Host C, but it would totally confuse Host A 😵. If the embedded name resolved to the public address, Host A would be happy, but Host C would end up looking for some remote machine 🛸. Using public FQDN resolution to set up a connection from Host C to D means the NAT has to look at the destination, rather than just forwarding the packet out to the router 🔀. (Normal operating mode for a NAT is to translate and forward out the other interface, while routers don't send packets back out the interface they came from.) The NAT didn't create the name space fragmentation in the first place, but it does make it easier to attempt to merge networks that have independent name administrations 🧩.
7.6. L2TP tunnels increase frequency of address collisions 🦄
The recent mass growth of the Internet has been driven by support for low cost publishing via the web 🕸️. The next big push seems to be support for Virtual Private Networks (VPNs), which are frequently built using L2TP 🔐. Technically, VPN tunnels treat an IP infrastructure as a multiplexing substrate, which lets the endpoints build what look like clear pathways from end-to-end ✨. These tunnels redefine network visibility, and they increase the likelihood of address collisions when traffic crosses multiple NATs 💥. Managing addresses in the private space behind NATs is going to become a significant burden, since there's no central body that is capable of, or willing to, do it 😮💨. The lower burden for the ISP is really a transfer of burden to the local level, because managing addresses and names becomes both distributed and more complicated 🌈💜.
Okay so RFC-1918 already warned us that merging private address spaces can cause an overlap in address use, and that's a whole problem 😭. L2TP tunnels make that merging happen more often, and more frequently too, because they're so easy to set up 🫶. There are several overlap setups that end in failure, but in the simple example below, Host B's private use address matches the private use address of the VPN pool Host A uses for inbound connections. When Host B tries to bring up the VPN interface, Host A hands it an address from that inbound pool and tells it which gateway to use. Host B then can't tell Host A's remote VPN gateway address apart from its own private address on the physical interface, so the connection fails 💀. Private use addresses are by definition not publicly coordinated, so as the VPN mesh gets more complex, a collision that can't be resolved gets more and more likely 🌪️.
--------------- ----------------
| 10.10.10.10 |--------L2TP-------| Assigned by A |
| Host A | --- --- | Host B |
| 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 |
--------------- --- --- ----------------
--------
Illustration 67.7. Centralized data collection system report correlation ✨
It has been reported that NAT adds extra challenges when intrusion detection systems try to correlate reports between sensors inside and outside the NAT. The details of individual systems are out of scope for this document, but it's clear that a centralized system with monitoring agents on both sides of the NAT would also need access to the current NAT mappings to get this right 🧐. It would also be critical that the resulting data be indexed properly if there were agents behind multiple NATs using the same address range for the private side 📇.
This also applies to management data collected via SNMP. Any time the data stream carries an IP address, the central collector or ALG will need to manipulate the data based on the current mappings in the NAT 🔁.
8. IPv6 ✨
It has been argued that IPv6 is no longer necessary because NATs relieve the address space constraints and allow the Internet to keep growing. ngl, the reality is they point out the need for IPv6 more clearly than ever 🚨. People are trying to connect multiple machines through a single access line to their ISP, and they've been willing to give up some functionality to get that at minimum cost 💸.
Frequently the reason for cost increases is the perceived scarcity (therefore increased value) of IPv4 addresses, which would be eliminated through deployment of IPv6. This crisis mentality is creating a market for a solution to a problem that IPv6 already solved with greater flexibility 🙃.
If NAT had never been defined, the motivation to resolve the dwindling IPv4 address space would be a much greater 😤. Given that NATs are enabling untold numbers of new hosts to attach to the Internet daily, it's hard to figure out the actual impact on the lifetime of IPv4, but NAT has certainly extended it ⏳. It's also hard to determine how much delay NAT is causing for IPv6, both by relieving the pressure and by redirecting the intellectual cycles away from the longer-term solution 🧠.
But at the same time, NAT functionality may be a critical facilitator in the deployment of IPv6 🦋. There are already 100 million or more computers running IPv4 on data networks. Some of these networks are connected to, and thus part of, the Internet, and some are on private isolated networks. It is inconceivable that we could have a "flag day" and convert all of the existing IPv4 nodes to IPv6 at the same time 🙅♀️. There will be a very long period of coexistence while both IPv4 and IPv6 are being used in the Internet and in private networks. The original IPv6 transition plan relied heavily on having new IPv6 nodes also be able to run IPv4, a "dual stack" approach. When a dual stack node looks up another node in the DNS, it will get back an IPv4 or an IPv6 address in response. If the response is an IPv4 address, then the node uses IPv4 to contact the other node. And if the response is an IPv6 address, then IPv6 can be used to make the contact 📞. Turning the NAT into a 6to4 [13]router enables widespread deployment of IPv6 while providing an IPv4 path if IPv6 is unavailable 🌈. While this maintains the current set of issues for IPv4 connections, it reestablishes the end-to-end principle for IPv6 connections 💜.
An alternative methodology would be to translate the packets between IPv6 and IPv4 at the borders between IPv4 supporting networks and IPv6 supporting networks. The need for this functionality was recognized in [RFC 1752], the document that recommended to the IETF that IPv6 be developed and recommended that a set of working groups be established to work on a number of specific problems. Header translation (i.e, NAT) was one of those problems 🧩.
Of course, NATs in an IPv6 to IPv4 translation environment encounter all of the same problems that NATs encounter in a pure IPv4 environment, and the environment and cautions in this document apply to both situations 💅.
9. Security Considerations ✨
Okay, this part is serious bestie 😭🔒. NAT (particularly NAPT) actually has the potential to lower overall security, because it creates the illusion of a security barrier without the managed intent of a firewall 🫠. Appropriate security mechanisms are implemented in the end host, without relying on assumptions about routing hacks, firewall filters, or missing NAT translations, which may change over time to enable a service to a neighboring host 🚫. In general, defined security barriers assume that any threats are external, and that leads to practices that make internal breaches much easier 💀.
IPsec RFC-2401 [7] defines a set of mechanisms to support packet-level authentication and encryption for use in IP networks. While this may be less efficient than application-level security, in the words of RFC-1752 [14], "support for basic packet-level authentication will provide for the adoption of a much needed, widespread, security infrastructure throughout the Internet" 🔐✨.
NATs break IPsec's authentication and encryption technologies, because these technologies depend on an end-to-end consistency of the IP addresses in the IP headers. That means NATs may stall further deployment of enhanced security across the Internet 😩. NATs raise a number of specific issues with IPsec. For example:
- Use of AH is not possible via NAT, as the hash protects the IP address in the header 🙅.
- Authenticated certificates may contain the IP address as part of the subject name for authentication purposes 📜.
- Encrypted Quick Mode structures may contain IP addresses and ports for policy verifications 🔍.
- The Revised Mode of public key encryption includes the peer identity in the encrypted payload 🫣.
It may be possible to engineer and work around NATs for IPsec on a case-by-case basis, but that comes at the cost of restricting the trust model, as discussed in section 4 above 🧱. With all of the restrictions placed on deployment flexibility, NATs present a significant obstacle to security integration being deployed in the Internet today 🚧.
As noted in RFC-2694 [15], the DNS/ALG cannot support secure DNS name servers in the private domain. Zone transfers between DNSsec servers will be rejected when necessary modifications are attempted 🙅♀️. It is also the case that DNS/ALG will break any modified, signed responses. This would be true for all public side queries of private nodes when the DNS server is on the private side. It would also be true for any private side queries for private nodes when the DNS server is on the public side 🌀. Digitally signed records could be modified by the DNS/ALG if it had access to the source authentication key. DNSsec has been specifically designed to avoid distribution of this key, in order to maintain source authenticity 🔑. So NATs that use DNS/ALG to repair the namespace resolutions will either break the security when modifying the record, or will require access to all source keys to requested resolutions. Not it. 🙈
Security mechanisms that do not protect or rely on IP addresses as identifiers, such as TLS [16], SSL [17], or SSH [18], may operate in environments containing NATs 🥰. For applications that can establish and make use of this type of transport connection, NATs do not create any additional complications. These technologies may not provide sufficient protection for all applications, though, because the header is exposed, which allows subversive acts like TCP resets 😬. RFC-2385 [19] discusses the issues in more detail 📖.
Arguments that NATs may operate in a secure mode preclude true End-to-End security, because the NAT becomes the security endpoint 🛑. Operationally, the NAT must be managed as part of the security domain, and in this mode the packets on the unsecured side of the NAT are fully exposed 👀.
10. Deployment Guidelines 🎀
okay bestie, NAT devices are getting deployed super fast right now, so we need some ground rules 🦋 most of these are cautionary, basically making sure you really get what using NATs does to your setup 💅
- figure out how name resolution works and make sure the right answer comes back for each address administration 🧚 honestly, putting the DNS server or a DNS ALG inside the NAT device will probably be way easier to manage than trying to keep separate DNS systems in sync across administrations 🫶
- is the NAT set up with static one to one mappings, or does it manage them dynamically? if it's dynamic, set the TTL of the DNS responses to
0and make sure clients pay attention to the don't cache notification 🙈 - will there be a single NAT device, or multiple parallel paths? if it's just one, think about what happens when that device fails 💀 if there are multiple, think about how routing on both sides keeps packets going through the same box for the whole life of the connection 🌸
- look at the applications that need to get through the NAT and check whether they're okay with their addresses changing 👑 if they aren't, add an appropriate ALG or set up a VPN to isolate the application from the NAT 🔥
- check whether you need public to private connections, how much the destinations on the private side vary, and whether public side port numbers might get used at the same time 🍓 if any of that applies, NAPTs mean more admin work 😭
- check whether the applications going through the NAPT or RSIP expect every port on the public IP address to be the same endpoint 🌈 if so, you'll need administrative controls to stop multiple private hosts from accessing at the same time 🔒
- if the payloads are encrypted, the contents can't be modified unless the NAT is a security endpoint acting as a gateway between security realms ✨ and that means no end-to-end confidentiality, because the path between the NAT and the endpoint is exposed 🙀
- figure out the path for name resolutions 🗺️ if hosts on the private side of a NAPT or RSIP server need to see each other, you might need a private side DNS server 🫶
- if the environment uses secure DNS records, the DNS/ALG will need access to the source authentication keys for every record it has to translate 🔑
- when you're running VPNs over NATs, pick a clearinghouse for the private side addresses so you don't get collisions 💜
- make sure applications used both inside and outside avoid embedding names, or use globally unique ones 🌷
- with RSIP, remember the scope is limited to one private network connecting to the public Internet 🎯 if other NATs are in the path (including web-server load-balancing devices), the big RSIP perk of end-to-end address/port pair use is gone 💔
- for RSIP, check how likely
TCP_Time_Waitcollisions are when private side hosts later try to reach a public side service that just disconnected 🌙
11. Summary 📝
okay so, over the 6 years since RFC-1631, we've gotten a lot more real-world experience, and that exposed more of the concerns the original authors raised 👀 NAT breaks a basic assumption of Internet design, which is that the endpoints are in control 🙅♀️ and the "keep-it-simple" principle is getting ignored as more features get piled onto the network to work around NAT problems 😩 overall flexibility and manageability go down, and support costs go up to deal with the issues NATs cause 💸
everyone's got opinions, and both the fans and the haters present their case like they're totally righteous while brushing off the rebuttals 💅
- NATs are a 'fact of life' 🌍 and they'll keep spreading as an enhancement that keeps existing IPv4 infrastructure going ✨
- NATs are a 'necessary evil' 😤 they create an admin burden that isn't easy to fix, and more importantly, they get in the way of rolling out IPsec, which then slows down growth for applications that need a secure infrastructure 🔐
either way, NATs need strong applicability statements that clearly say what works and what doesn't 📋
here's the tea on the pluses and minuses 🍵
NAT advantages NAT disadvantages
-------------------------------- --------------------------------
Masks global address changes Breaks end-to-end model
Eases renumbering when providers Facilitates concatenation of
change multiple name spaces
Breaks IPsec
Stateful points of failure
Address administrations avoid Requires source specific DNS reply
justifications to registries or DNS/ALG
DNS/ALG breaks DNSsec replies
Lowers address utilization Enables end-to-end address
conflicts
Lowers ISP support burden Increases local support burden and
complexity
Transparent to end systems in some Unique development for each app
cases
Load sharing as virtual host Performance limitations with scale
Delays need for IPv4 replacement May complicate integration of IPv6there have been a ton of conversations lately about whether it's still worth developing IPv6 when the market is widely deploying IPv4 NATs 🤔 a shortsighted take would miss the point that both have a role 🦋 NATs solve some real-world problems today, while IPv6 is aimed at fundamental problems and moving things forward 🚀 we should expect a long coexistence while applications and services develop for IPv6, since existing IPv4 systems will probably stick around for decades 🕰️ NATs are a detour from forward motion, but they do let more people participate right now 🫶 they also break a class of applications, which creates the need for complicated workaround setups 😵💫
efforts to boost general security on the Internet include IPsec and DNSsec 🔐 these technologies offer a bunch of services to authenticate and protect information in transit ✨ by breaking them, NAT and the DNS/ALG workaround get in the way of deploying stronger security across the whole Internet 🙅♀️
people also keep asking how likely it is that VPNs get set up in ways that raise some of the concerns above 👀 it's hard to predict, but one way to skip ALGs for each application is to run an L2TP over the NATs 🧁 this limits the NAT's visibility to the headers of the tunnel packets, so its effects are removed from all applications 🌸 that solves the ALG issues, but it makes address collisions more likely, since arbitrary connections get set up between uncoordinated address spaces 😬 it also raises a side question about how an application sets up the tunnel it needs 🤷♀️
the original IP architecture is powerful because it gives a general mechanism that other things, including ones nobody's imagined yet, can be built on 🧚 sure, you can build a house of cards, but time and experience have led to standards with way more structural integrity 🏰 IPv6 is the long-term solution that keeps end-to-end transparency as a principle 💖 NAT is a technological detour that keeps IPv4 alive 🫠
12. References 📚
- Bradner, S., " The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- Egevang, K. and P. Francis, "The IP Network Address Translator", RFC 1631, May 1994.
- Srisuresh, P. and M. Holdrege, "NAT Terminology and Considerations", RFC 2663, August 1999.
- Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
- M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress, March 2000.
- Kent, S. and R. Atkinson, "Security Architecture for IP", RFC 2401, November 1998.
- Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
- Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
- Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
- Jacobson, V., Braden, R. and L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, October 1990.
- Braden, R., "Requirements for Internet Hosts", STD 3, RFC 1123, October 1989.
- Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", Work in Progress.
- Bradner, S. and A. Mankin, "Recommendation for IPng", RFC 1752, January 1995.
- Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to NAT", RFC 2694, September 1999.
- Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.- T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress, August 1998.
- Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
13. Acknowledgments 🫶
huge thanks to the IAB, Vern Paxson (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas Narten (ibm), Yakov Rekhter (cisco), Pyda Srisuresh, Matt Holdrege (lucent), and Eliot Lear (cisco) 💜 they all made real contributions to this document 🌟
14. Author's Address 🖋️
Tony Hain Microsoft One Microsoft Way Redmond, Wa. USA
Phone: 1-425-703-6619 EMail: tonyhain@microsoft.com
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society ✨
📦 where this page comes from
- ietf: rfc2993 2000-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms