RFC 3022
Traditional IP Network Address Translator (Traditional NAT)
RFC 3022: Traditional IP Network Address Translator (Traditional NAT) 🦋
- Who wrote it: P. Srisuresh (Jasmine Networks) and K. Egevang (Intel Corporation) 👑
- Category: Informational 📚
- Date: January 2001 🗓️
- Obsoletes: RFC 1631. This one is the upgraded version that replaces it 💅
- Updates: the header doesn't list any RFCs it updates 🙅
Status of this Memo ✨
Okay so this memo is here to give info to the Internet community 📖. It is not an Internet standard, not even close. Distribution of this memo is unlimited, so share it with everyone 💖.
Copyright Notice 🔒
Copyright (C) The Internet Society (2001). All Rights Reserved.
Preface 🌸
This NAT operation extends the address translation from RFC 1631 and adds a new kind of network address and TCP/UDP port translation. The doc also fixes the Checksum adjustment algorithm that RFC 1631 published, and it digs into how NAT works and what its limitations are, in detail 🤓.
Abstract 🎀
So Basic Network Address Translation, or Basic NAT, is when IP addresses get mapped from one group to another, and end users don't notice a thing ✨. Then there's Network Address Port Translation, or NAPT, where lots of network addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports get translated into a single network address and its TCP/UDP ports 💅. Put together, these two operations, called traditional NAT, let a realm with private addresses connect to an external realm with globally unique registered addresses 🌈.
1. Introduction 🌸
So when does a network even need IP address translation? 🤔 It's when the network's internal IP addresses can't be used outside the network, either for privacy reasons or because they're invalid for use outside the network 🙈.
Okay, the outside topology of a local domain can change in a bunch of ways. Customers switch providers, company backbones get reorganized, and providers merge or split up 😭. Every time the external topology changes, the address assignment for nodes in the local domain must also change to match. The good news is that these changes can be hidden from users in the domain by centralizing them in a single address translation router 🧚.
Basic address translation would (in lots of cases, except as noted in [NAT-TERM] and section 6 of this document) let hosts in a private network access the external network transparently, and let outsiders reach selected local hosts too 🦋. Organizations whose network is mostly for internal use, but that now and then need outside access, are the best candidates for this setup 💜.
Tbh, so many SOHO (Small Office, Home Office) users and telecommuting employees have multiple network nodes in their office running TCP/UDP apps, but only a single IP address from their service provider for their remote access router 💀. This ever-growing crowd of remote access users would really benefit from NAPT, which lets multiple nodes in a local network access remote networks at the same time using the one IP address on their router 🫶.
There are limitations though, bestie ⚠️. All requests and responses for a session must be routed via the same NAT router. One way to make sure of that is to base NAT on a border router that's unique to a stub domain, where every IP packet either comes from the domain or is headed to it. There are other ways to make this work with multiple NAT devices too 🔥. For example, a private domain could have two separate exit points to different providers, and session flows from the hosts in the private network could go through whichever NAT device has the best metric for an external host. When one of the NAT routers fails, the other one could route traffic for all the connections. The catch is that rerouted flows could fail during the switchover to the new NAT router 😬. A way to fix that potential problem is for the routers to share the same NAT configuration and exchange state information, so each one is a fail-safe backup for the other 👑.
Address translation doesn't care about the application, and it's often paired with application specific gateways (ALGs) that monitor and alter the payload 🔍. FTP is the most popular ALG on NAT devices 💖. Applications that need ALG intervention must not have their payload encoded, because that would effectively disable the ALG, unless the ALG has the key to decrypt the payload 🔐.
This solution has a downside: it takes away the end-to-end significance of an IP address and makes up for it with more state in the network 😤. So end-to-end IP network level security assured by IPSec can't be assumed to reach end hosts when a NAT device is enroute 🙅♀️. The upside, though, is that it can be installed without changing any hosts or routers 🌸.
Terms like "Address Realm", "Transparent Routing", "TU Ports", "ALG" and others get used all through the document. You can find their definitions in [NAT-TERM] 📚.
2. Overview of traditional NAT 🦋
The address translation in this document is called "Traditional NAT". There are other NAT variations, but this doc won't explore them 🙈. Traditional NAT lets hosts inside a private network access hosts on the external network transparently, in most cases ✨. In traditional NAT, sessions are uni-directional, going outbound from the private network. Sessions in the other direction might be allowed on an exceptional basis, using static address maps for pre-selected hosts 🔒. Basic NAT and NAPT are two versions of traditional NAT. Basic NAT only translates IP addresses, while NAPT goes further and translates the IP address and the transport identifier (like a TCP/UDP port or an ICMP query ID) 💅.
Unless it says otherwise, Address Translation or NAT in this document means traditional NAT, which covers both Basic NAT and NAPT 🌈. Only the stub border routers shown in figure 1 below may be configured to do address translation 🧚.
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub borderFigure 1: Traditional NAT Configuration 🎀
2.1 Overview of Basic NAT 💖
Okay so here's how Basic NAT works 👀. A stub domain with a set of private network addresses can talk to the external network by dynamically mapping those private addresses to a set of globally valid network addresses 🌍. If the number of local nodes is less than or equal to the number of addresses in the global set, every local address is guaranteed a global address to map to 💯. If not, the nodes allowed to access the external network at the same time are limited by how many addresses are in the global set 😬. Individual local addresses can be statically mapped to specific global addresses. That guarantees outside access, or lets outside hosts reach a local host through a fixed public address 🔒. A local node can start multiple simultaneous sessions, all using the same address mapping ✨.
Addresses inside a stub domain are local to that domain and aren't valid outside it. That means any other stub domain can reuse them 🔁. For instance, a single Class A address could be used by many stub domains 🦋. NAT gets installed at each exit point between a stub domain and the backbone. If there's more than one exit point, it's super important that each NAT has the same translation table 🫶.
For instance, in the example of figure 2, stubs A and B both use the class A private address block 10.0.0.0/8 [RFC 1918] internally 🧚. Stub A's NAT is assigned the class C address block 198.76.29.0/24, and Stub B's NAT is assigned the class C address block 198.76.28.0/24 🌸. The class C addresses are globally unique, so no other NAT boxes can use them 👑.
\ | /
+---------------+
|Regional Router|
+---------------+
WAN | | WAN
| |
Stub A .............|.... ....|............ Stub B
| |
{s=198.76.29.7,^ | | v{s=198.76.29.7,
d=198.76.28.4}^ | | v d=198.76.28.4}
+-----------------+ +-----------------+
|Stub Router w/NAT| |Stub Router w/NAT|
+-----------------+ +-----------------+
| |
| LAN LAN |
------------- -------------
| |
{s=10.33.96.5, ^ | | v{s=198.76.29.7,
d=198.76.28.4}^ +--+ +--+ v d=10.81.13.22}
|--| |--|
/____\ /____\
10.33.96.5 10.81.13.22Figure 2: Basic NAT Operation 💅
When stub A host 10.33.96.5 wants to send a packet to stub B host 10.81.13.22, it uses the globally unique address 198.76.28.4 as the destination, then sends the packet to its primary router 📦. The stub router has a static route for net 198.76.0.0, so the packet gets forwarded to the WAN-link 🚀. Before the packet goes out, though, NAT translates the source address 10.33.96.5 in the IP header to the globally unique 198.76.29.7 ✨. Packets on the return path go through similar address translations too 🔄.
Notice that none of this requires changes to hosts or routers 🙌. As far as the stub A host is concerned, 198.76.28.4 is just the address the host in stub B uses. In most cases the address translations are transparent to end hosts 💜. Of course, this is only a simple example, and there are plenty of other issues to explore 🌈.
2.2. Overview of NAPT 🎀
okay so picture this: an organization has a private IP network and a WAN link to a service provider 🌸 The private network's stub router gets one globally valid address on that WAN link, and everyone else in the org has IP addresses that only mean something locally. NAPT lets those nodes all access the external network at the same time using that single registered IP address 💅 It does this by mapping tuples of the type (local IP addresses, local TU port number) to tuples of the type (registered IP address, assigned TU port number). iykyk 🦋
This model is giving SOHO (Small Office Home Office) groups exactly what they need: external access using one service provider assigned IP address ✨ It could also be extended to allow inbound access, by statically mapping a local node to each service TU port of the registered IP address 🫶
In the example of figure 3 below, stub A internally uses the class A address block 10.0.0.0/8. The stub router's WAN interface is assigned the IP address 138.76.28.4 by the service provider 🧚
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
|
Stub A .............|....
|
^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23,
^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024}
+------------------+
|Stub Router w/NAPT|
+------------------+
|
| LAN
--------------------------------------------
| ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23,
| ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017}
| |
+--+ +--+ +--+
|--| |--| |--|
/____\ /____\ /____\
10.0.0.1 10.0.0.2 ..... 10.0.0.10
Figure 3: Network Address Port Translation (NAPT) OperationWhen stub A host 10.0.0.10 sends a telnet packet to host 138.76.29.7, it uses the globally unique address 138.76.29.7 as the destination and sends the packet to its primary router 📦 The stub router has a static route for the subnet 138.76.0.0/16, so the packet is forwarded to the WAN link. But here's the magic ✨: NAPT translates the tuple of source address 10.0.0.10 and source TCP port 3017 in the IP and TCP headers into the globally unique 138.76.28.4 and a uniquely assigned TCP port, say 1024, before the packet is forwarded. Packets on the return path go through similar address and TCP port translations for the target IP address and target TCP port. Once again, notice that this requires no changes to hosts or routers. The translation is completely transparent 🙈
In this setup, only TCP/UDP sessions are allowed, and they must originate from the local network. However, there are services such as DNS that demand inbound access 😭 There may be other services for which an organization wants to allow inbound session access too. It is possible to statically configure a well known TU port service [RFC 1700] on the stub router so that it is directed to a specific node in the private network 👑
In addition to TCP/UDP sessions, ICMP messages may also be monitored by the NAPT router, with the exception of the REDIRECT message type 🌈 ICMP query type packets are translated similarly to TCP/UDP packets, in that the identifier field in the ICMP message header is uniquely mapped to a query identifier of the registered IP address. The identifier field in ICMP query messages is set by the Query sender and returned unchanged in the response message from the Query responder. So the tuple of (Local IP address, local ICMP query identifier) is mapped to a tuple of (registered IP address, assigned ICMP query Identifier) by the NAPT router, which uniquely identifies ICMP queries of all types from any of the local hosts 💜 Modifications to ICMP error messages are discussed in a later section, since they involve changes to the ICMP payload as well as the IP and ICMP headers ⭐
In a NAPT setup where the registered IP address is the same as the IP address of the stub router WAN interface, the router has to be sure to make a distinction between TCP, UDP or ICMP query sessions originated from itself and those originated from the nodes on the local network. All inbound sessions (including TCP, UDP and ICMP query sessions) are assumed to be directed to the NAT router as the end node, unless the target service port is statically mapped to a different node in the local network. 💀
Sessions other than TCP, UDP and ICMP query type are simply not permitted from local nodes served by a NAPT router 🚫
3.0. Translation phases of a session ✨
The translation phases with traditional NAT are the same as described in [NAT-TERM]. The following sub-sections identify items that are specific to traditional NAT 🍓
3.1. Address binding: 🔗
With Basic NAT, a private address is bound to an external address when the first outgoing session is initiated from the private host. After that, all other outgoing sessions originating from the same private address use the same address binding for packet translation 💖
In the case of NAPT, where many private addresses are mapped to a single globally unique address, the binding goes from the tuple of (private address, private TU port) to the tuple of (assigned address, assigned TU port). As with Basic NAT, this binding is determined when the first outgoing session is initiated by the tuple of (private address, private TU port) on the private host. While not a common practice, it is possible to have an application on a private host establish multiple simultaneous sessions originating from the same tuple of (private address, private TU port). In such a case, a single binding for the tuple of (private address, private TU port) may be used for translation of packets pertaining to all sessions originating from the same tuple on a host 🧠
3.2. Address lookup and translation: 🔍
After an address binding, or (address, TU port) tuple binding in the case of NAPT, is established, a soft state may be maintained for each of the connections using the binding. Packets belonging to the same session are subject to session lookup for translation purposes. The exact nature of the translation is discussed in the follow-on section 🦋
3.3. Address unbinding: 🫧
When the last session based on an address or (address, TU port) tuple binding is terminated, the binding itself may be terminated 🌙
4.0. Packet Translations 🎀
Packets pertaining to NAT managed sessions undergo translation in either direction. Individual packet translation issues are covered in detail in the following sub-sections 💅
4.1. IP, TCP, UDP and ICMP Header Manipulations 🛠️
In the Basic NAT model, the IP header of every packet must be modified. This modification includes the IP address (source IP address for outbound packets and destination IP address for inbound packets) and the IP checksum 😤
For TCP ([TCP]) and UDP ([UDP]) sessions, modifications must include an update of the checksum in the TCP/UDP headers. This is because the TCP/UDP checksum also covers a pseudo header, which contains the source and destination IP addresses. As an exception, UDP headers with a 0 checksum should not be modified 🙅♀️ As for ICMP Query packets ([ICMP]), no further changes in the ICMP header are required, since the checksum in the ICMP header does not cover IP addresses ✨
In the NAPT model, modifications to the IP header are similar to those of Basic NAT. For TCP/UDP sessions, modifications must be extended to include translation of the TU port (source TU port for outbound packets and destination TU port for inbound packets) in the TCP/UDP header. The ICMP header in ICMP Query packets must also be modified to replace the query ID and the ICMP header checksum. The private host query ID must be translated into the assigned ID on the outbound, and the exact reverse on the inbound. The ICMP header checksum must be corrected to account for the Query ID translation 🔁
4.2. Checksum Adjustment 🧮
NAT modifications are per packet based and can be very compute intensive, since they involve one or more checksum modifications in addition to simple field translations. Luckily, there's an algorithm below that makes checksum adjustment to IP, TCP, UDP and ICMP headers very simple and efficient 🥹 Since all these headers use a one's complement sum, it is sufficient to calculate the arithmetic difference between the before-translation and after-translation addresses and add this to the checksum. The algorithm below is applicable only for even offsets (i.e., optr below must be at an even offset from the start of the header) and even lengths (i.e., olen and nlen below must be even). Sample code (in C) is as follows 👩💻
void checksumadjust(unsigned char *chksum, unsigned char *optr,
int olen, unsigned char *nptr, int nlen)
/* assuming: unsigned char is 8 bits, long is 32 bits.
- chksum points to the chksum in the packet
- optr points to the old data in the packet
- nptr points to the new data in the packet
*/
{
long x, old, new;
x=chksum[0]*256+chksum[1];
x=~x & 0xFFFF;
while (olen)
{
old=optr[0]*256+optr[1]; optr+=2;
x-=old & 0xffff;
if (x<=0) { x--; x&=0xffff; }
olen-=2;
}
while (nlen)
{
new=nptr[0]*256+nptr[1]; nptr+=2;
x+=new & 0xffff;
if (x & 0x10000) { x++; x&=0xffff; }
nlen-=2;
}
x=~x & 0xFFFF;
chksum[0]=x/256; chksum[1]=x & 0xff;
}4.3. ICMP error packet modifications 🚨
Changes to an ICMP error message ([ICMP]) include changes to the IP and ICMP headers on the outer layer, as well as changes to the headers of the packet embedded within the ICMP error message payload 😱
For NAT to be transparent to the end host, the IP address of the IP header embedded within the payload of the ICMP-Error message must be modified, the checksum field of the embedded IP header must be modified, and lastly, the ICMP header checksum must also be modified to reflect the changes to the payload 🫶
In a NAPT setup, if the IP message embedded within the ICMP happens to be a TCP, UDP or ICMP Query packet, you will also need to modify the appropriate TU port number within the TCP/UDP header, or the Query Identifier field in the ICMP Query header 🧩
Lastly, the IP header of the ICMP packet must also be modified 🎉
4.4. FTP support ✨
okay bestie, FTP ([FTP]) is one of the most popular applications, and it's lowkey a chaotic one 😭. It needs an ALG to peek at the control session payload so it can figure out what the data session parameters are going to be. An FTP ALG is an integral part of most NAT implementations, no cap 💅.
The FTP ALG needs a special table to fix up the TCP sequence and acknowledgement numbers for anything with source port FTP or destination port FTP. Each table entry should have a source address, destination address, source port, destination port, a delta for the sequence numbers, and a timestamp 🎀. New entries get created only when FTP PORT commands or PASV responses are seen. The sequence number delta may be increased or decreased for every FTP PORT command or PASV response 🦋. Sequence numbers get incremented on the outbound and acknowledgement numbers get decremented on the inbound by this delta. It's giving precise math, periodt 🧮✨.
FTP payload translations are limited to private addresses and their assigned external addresses (encoded as individual octets in ASCII) for Basic NAT 🌸. For NAPT setup, though, the translations must be extended to include the TCP port octets (in ASCII) following the address octets. Main character energy for the port octets 👑.
4.5 DNS support 🧚
Considering that sessions in a traditional NAT are predominantly outbound from a private domain, the DNS ALG may be obviated from use in conjunction with traditional NAT, as follows 💖. DNS server(s) internal to the private domain maintain mapping of names to IP addresses for internal hosts and possibly some external hosts. External DNS servers maintain name mapping for external hosts alone and not for any of the internal hosts 🙈. If the private network does not have an internal DNS server, all DNS requests may be directed to an external DNS server to find address mapping for the external hosts. Iykyk 😌.
4.6. IP option handling 🌈
An IP datagram with any of the IP options Record Route, Strict Source Route or Loose Source Route would involve recording or using IP addresses of intermediate routers 🛣️. A NAT intermediate router may choose not to support these options, or leave the addresses untranslated while processing the options. If it leaves them untranslated, private addresses along the source route get exposed end to end, which is kind of a lot 💀. This should not jeopardize the traversal path of the packet, per se, since each router is supposed to look at the next hop router only ✨.
5. Miscellaneous issues 🎀
5.1. Partitioning of Local and Global Addresses 🫶
For NAT to operate as described in this document, it is necessary to partition the IP address space into two parts: the private addresses used internal to a stub domain, and the globally unique addresses. Any given address must either be a private address or a global address. There is no overlap 💅.
The problem with overlap is this. Say a host in stub A wished to send packets to a host in stub B, but the global addresses of stub B overlapped the private addresses of stub A. In this case, the routers in stub A would not be able to distinguish the global address of stub B from their own private addresses 😭.
5.2. Private address space recommendation 🍓
[RFC 1918] has recommendations on address space allocation for private networks. The Internet Assigned Numbers Authority (IANA) has three blocks of IP address space, namely 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private internets. In pre-CIDR notation, the first block is nothing but a single class A network number, the second block is a set of 16 contiguous class B networks, and the third block is a set of 256 contiguous class C networks 🌈.
An organization that decides to use IP addresses in the address space defined above can do so without any coordination with IANA or an Internet registry. The address space can thus be used privately by many independent organizations at the same time, with NAT operation enabled on their border routers 🦋✨.
5.3. Routing Across NAT 🛣️
The router running NAT should not advertise the private networks to the backbone. Only the networks with global addresses may be known outside the stub. However, global information that NAT receives from the stub border router can be advertised in the stub the usual way 💜.
Typically, the NAT stub router will have a static route configured to forward all external traffic to the service provider router over the WAN link, and the service provider router will have a static route configured to forward NAT packets (i.e., those whose destination IP address falls within the range of the NAT managed global address list) to the NAT router over the WAN link 🔥.
5.4. Switch-over from Basic NAT to NAPT 🔄
In Basic NAT setup, when private network nodes outnumber the global addresses available for mapping (say, a class B private network mapped to a class C global address block), external network access to some of the local nodes is abruptly cut off after the last global address from the address list is used up. This is very inconvenient and constraining 😩. Such an incident can be safely avoided by optionally allowing the Basic NAT router to switch over to NAPT setup for the last global address in the address list. Doing this ensures that hosts on the private network will have continued, uninterrupted access to external nodes and services for most applications 🥹. Note, however, that it could be confusing if some of the applications that used to work with Basic NAT suddenly break due to the switch-over to NAPT 👀.
6.0. NAT limitations 🚧
[NAT-TERM] covers the limitations of all flavors of NAT, broadly speaking. The following subsections identify limitations specific to traditional NAT 💁.
6.1. Privacy and Security 🔐
Traditional NAT can be viewed as providing a privacy mechanism, as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts 🙈💜.
The same characteristic that enhances privacy potentially makes debugging problems (including security violations) more difficult. If a host in a private network is abusing the Internet in some way (such as trying to attack another machine or even sending large amounts of spam), it is more difficult to track the actual source of trouble because the IP address of the host is hidden in a NAT router 😤.
6.2. ARP responses to NAT mapped global addresses on a LAN interface 🫠
NAT must be enabled only on border routers of a stub domain. The examples provided in the document to illustrate Basic NAT and NAPT have maintained a WAN link for connection to the external router (i.e., the service provider router) from the NAT router. However, if the WAN link were to be replaced by a LAN connection, and if part or all of the global address space used for NAT mapping belongs to the same IP subnet as the LAN segment, the NAT router would be expected to provide ARP support for the address range that belongs to the same subnet. Responding to ARP requests for the NAT mapped global addresses with its own MAC address is a must in such a situation with Basic NAT setup. If the NAT router did not respond to these requests, there is no other node in the network that has ownership of these addresses, and hence the requests will go unresponded 📭.
This scenario is unlikely with NAPT setup, except when the single address used in NAPT mapping is not the interface address of the NAT router (as in the case of a switch-over from Basic NAT to NAPT explained in 5.4 above, for example) 🤓.
Using an address range from a directly connected subnet for NAT address mapping would obviate static route configuration on the service provider router 🙌.
It is the opinion of the authors that a LAN link to a service provider router is not very common. However, vendors may be interested in optionally supporting proxy ARP, just in case 🤷♀️.
6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup 💔
Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT setup is doomed to fail 😭. The reason is this. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet with a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say two private hosts originated fragmented TCP/UDP packets to the same destination host, and they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying the same fragmentation ID and coming from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted 🥀.
7.0. Current Implementations 🐧
Many commercial implementations are available in the industry that adhere to the NAT description provided in this document 🛍️. Linux public domain software contains NAT under the name "IP masquerade". FreeBSD public domain software has a NAPT implementation running as a daemon. Note, however, that Linux source is covered under the GNU license and FreeBSD software is covered under the UC Berkeley license 📜.
Both Linux and FreeBSD software are free, so you can buy CD-ROMs for these for little more than the cost of distribution. They are also available online from a lot of FTP sites with the latest patches 💿✨.
8.0. Security Considerations 🔒
The security considerations described in [NAT-TERM] for all variations of NATs are applicable to traditional NAT. Take these seriously, bestie, they are not a vibe to skip 🚨💀.
References 📚
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC 1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", STD 9, RFC 959, October 1985.
[TCP] Defense Advanced Research Projects Agency Information Processing Techniques Office, "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", STD 7, RFC 793, September 1981.
[ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION", STD 5, RFC 792, September 1981.
[UDP] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
Authors' Addresses 💌
Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A.
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
Kjeld Borch Egevang Intel Denmark ApS
Phone: +45 44886556 Fax: +45 44886051 EMail: kjeld.egevang@intel.com http: //www.freeyellow.com/members/kbe
Full Copyright Statement 💅
Copyright (C) The Internet Society (2001). All Rights Reserved. 🎀
Okay so, bestie, here's the legal stuff, and it's actually pretty chill. ✨ You're allowed to copy this document and share it with others, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and every derivative work. 🦋
The one catch: you can't modify this document itself in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. You can change it when you're developing Internet standards, but then the copyright procedures in the Internet Standards process have to be followed. You can also change it when you're translating it into languages other than English. 🌸
The permissions above are perpetual. The Internet Society and its successors or assigns will never revoke them. 🫶
The document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭 So no guarantees, obviously, but that's just how the internet works sometimes. 💀
Acknowledgement 🧚
Funding for the RFC Editor function is currently provided by the Internet Society. 💜 Honestly, this is the real MVP move, because somebody has to keep the RFC Editor running so all of us can keep building the internet. 👑🌈
📦 where this page comes from
- ietf: rfc3022 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms