summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3022.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3022.txt')
-rw-r--r--doc/rfc/rfc3022.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3022.txt b/doc/rfc/rfc3022.txt
new file mode 100644
index 0000000..0af1c1f
--- /dev/null
+++ b/doc/rfc/rfc3022.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group P. Srisuresh
+Request for Comments: 3022 Jasmine Networks
+Obsoletes: 1631 K. Egevang
+Category: Informational Intel Corporation
+ January 2001
+
+
+ Traditional IP Network Address Translator (Traditional NAT)
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Preface
+
+ The NAT operation described in this document extends address
+ translation introduced in RFC 1631 and includes a new type of network
+ address and TCP/UDP port translation. In addition, this document
+ corrects the Checksum adjustment algorithm published in RFC 1631 and
+ attempts to discuss NAT operation and limitations in detail.
+
+Abstract
+
+ Basic Network Address Translation or Basic NAT is a method by which
+ IP addresses are mapped from one group to another, transparent to end
+ users. Network Address Port Translation, or NAPT is a method by
+ which many network addresses and their TCP/UDP (Transmission Control
+ Protocol/User Datagram Protocol) ports are translated into a single
+ network address and its TCP/UDP ports. Together, these two
+ operations, referred to as traditional NAT, provide a mechanism to
+ connect a realm with private addresses to an external realm with
+ globally unique registered addresses.
+
+1. Introduction
+
+ The need for IP Address translation arises when a network's internal
+ IP addresses cannot be used outside the network either for privacy
+ reasons or because they are invalid for use outside the network.
+
+ Network topology outside a local domain can change in many ways.
+ Customers may change providers, company backbones may be reorganized,
+ or providers may merge or split. Whenever external topology changes
+
+
+
+Srisuresh & Egevang Informational [Page 1]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ with time, address assignment for nodes within the local domain must
+ also change to reflect the external changes. Changes of this type
+ can be hidden from users within the domain by centralizing changes to
+ a single address translation router.
+
+ Basic Address translation would (in many cases, except as noted in
+ [NAT-TERM] and section 6 of this document) allow hosts in a private
+ network to transparently access the external network and enable
+ access to selective local hosts from the outside. Organizations with
+ a network setup predominantly for internal use, with a need for
+ occasional external access are good candidates for this scheme.
+
+ Many Small Office, Home Office (SOHO) users and telecommuting
+ employees have multiple Network nodes in their office, running
+ TCP/UDP applications, but have a single IP address assigned to their
+ remote access router by their service provider to access remote
+ networks. This ever increasing community of remote access users
+ would be benefited by NAPT, which would permit multiple nodes in a
+ local network to simultaneously access remote networks using the
+ single IP address assigned to their router.
+
+ There are limitations to using the translation method. It is
+ mandatory that all requests and responses pertaining to a session be
+ routed via the same NAT router. One way to ascertain this would be
+ to have NAT based on a border router that is unique to a stub domain,
+ where all IP packets are either originated from the domain or
+ destined to the domain. There are other ways to ensure this with
+ multiple NAT devices. For example, a private domain could have two
+ distinct exit points to different providers and the session flow from
+ the hosts in a private network could traverse through whichever NAT
+ device has the best metric for an external host. When one of the NAT
+ routers fail, the other could route traffic for all the connections.
+ There is however a caveat with this approach, in that, rerouted flows
+ could fail at the time of switchover to the new NAT router. A way to
+ overcome this potential problem is that the routers share the same
+ NAT configuration and exchange state information to ensure a fail-
+ safe backup for each other.
+
+ Address translation is application independent and often accompanied
+ by application specific gateways (ALGs) to perform payload monitoring
+ and alterations. FTP is the most popular ALG resident on NAT
+ devices. Applications requiring ALG intervention must not have their
+ payload encoded, as doing that would effectively disables the ALG,
+ unless the ALG has the key to decrypt the payload.
+
+ This solution has the disadvantage of taking away the end-to-end
+ significance of an IP address, and making up for it with increased
+ state in the network. As a result, end-to-end IP network level
+
+
+
+Srisuresh & Egevang Informational [Page 2]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ security assured by IPSec cannot be assumed to end hosts, with a NAT
+ device enroute. The advantage of this approach however is that it
+ can be installed without changes to hosts or routers.
+
+ Definition of terms such as "Address Realm", "Transparent Routing",
+ "TU Ports", "ALG" and others, used throughout the document, may be
+ found in [NAT-TERM].
+
+2. Overview of traditional NAT
+
+ The Address Translation operation presented in this document is
+ referred to as "Traditional NAT". There are other variations of NAT
+ that will not be explored in this document. Traditional NAT would
+ allow hosts within a private network to transparently access hosts in
+ the external network, in most cases. In a traditional NAT, sessions
+ are uni-directional, outbound from the private network. Sessions in
+ the opposite direction may be allowed on an exceptional basis using
+ static address maps for pre-selected hosts. Basic NAT and NAPT are
+ two variations of traditional NAT, in that translation in Basic NAT
+ is limited to IP addresses alone, whereas translation in NAPT is
+ extended to include IP address and Transport identifier (such as
+ TCP/UDP port or ICMP query ID).
+
+ Unless mentioned otherwise, Address Translation or NAT throughout
+ this document will pertain to traditional NAT, namely Basic NAT as
+ well as NAPT. Only the stub border routers as described in figure 1
+ below may be configured to perform address translation.
+
+ \ | / . /
+ +---------------+ WAN . +-----------------+/
+ |Regional Router|----------------------|Stub Router w/NAT|---
+ +---------------+ . +-----------------+\
+ . | \
+ . | LAN
+ . ---------------
+ Stub border
+
+ Figure 1: Traditional NAT Configuration
+
+2.1 Overview of Basic NAT
+
+ Basic NAT operation is as follows. A stub domain with a set of
+ private network addresses could be enabled to communicate with
+ external network by dynamically mapping the set of private addresses
+ to a set of globally valid network addresses. If the number of local
+ nodes are less than or equal to addresses in the global set, each
+ local address is guaranteed a global address to map to. Otherwise,
+ nodes allowed to have simultaneous access to external network are
+
+
+
+Srisuresh & Egevang Informational [Page 3]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ limited by the number of addresses in global set. Individual local
+ addresses may be statically mapped to specific global addresses to
+ ensure guaranteed access to the outside or to allow access to the
+ local host from external hosts via a fixed public address. Multiple
+ simultaneous sessions may be initiated from a local node, using the
+ same address mapping.
+
+ Addresses inside a stub domain are local to that domain and not valid
+ outside the domain. Thus, addresses inside a stub domain can be
+ reused by any other stub domain. For instance, a single Class A
+ address could be used by many stub domains. At each exit point
+ between a stub domain and backbone, NAT is installed. If there is
+ more than one exit point it is of great importance that each NAT has
+ the same translation table.
+
+ For instance, in the example of figure 2, both stubs A and B
+ internally use class A private address block 10.0.0.0/8 [RFC 1918].
+ 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 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.22
+
+ Figure 2: Basic NAT Operation
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 4]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ When stub A host 10.33.96.5 wishes to send a packet to stub B host
+ 10.81.13.22, it uses the globally unique address 198.76.28.4 as
+ destination, and sends the packet to its primary router. The stub
+ router has a static route for net 198.76.0.0 so the packet is
+ forwarded to the WAN-link. However, NAT translates the source
+ address 10.33.96.5 of the IP header to the globally unique
+ 198.76.29.7 before the packet is forwarded. Likewise, IP packets on
+ the return path go through similar address translations.
+
+ Notice that this requires no changes to hosts or routers. For
+ instance, as far as the stub A host is concerned, 198.76.28.4 is the
+ address used by the host in stub B. The address translations are
+ transparent to end hosts in most cases. Of course, this is just a
+ simple example. There are numerous issues to be explored.
+
+2.2. Overview of NAPT
+
+ Say, an organization has a private IP network and a WAN link to a
+ service provider. The private network's stub router is assigned a
+ globally valid address on the WAN link and the remaining nodes in the
+ organization have IP addresses that have only local significance. In
+ such a case, nodes on the private network could be allowed
+ simultaneous access to the external network, using the single
+ registered IP address with the aid of NAPT. NAPT would allow mapping
+ of tuples of the type (local IP addresses, local TU port number) to
+ tuples of the type (registered IP address, assigned TU port number).
+
+ This model fits the requirements of most Small Office Home Office
+ (SOHO) groups to access external network using a single service
+ provider assigned IP address. This model could be extended to allow
+ inbound access by statically mapping a local node per each service TU
+ port of the registered IP address.
+
+ In the example of figure 3 below, stub A internally uses class A
+ address block 10.0.0.0/8. The stub router's WAN interface is
+ assigned an IP address 138.76.28.4 by the service provider.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 5]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ \ | /
+ +-----------------------+
+ |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) Operation
+
+ When 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 destination, and
+ sends the packet to it's 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. However, 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 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 wishes to allow inbound session access. It is possible
+ to statically configure a well known TU port service [RFC 1700] on
+ the stub router to be directed to a specific node in the private
+ network.
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 6]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ In addition to TCP/UDP sessions, ICMP messages, with the exception of
+ REDIRECT message type may also be monitored by NAPT router. ICMP
+ query type packets are translated similar to that of TCP/UDP packets,
+ in that the identifier field in ICMP message header will be uniquely
+ mapped to a query identifier of the registered IP address. The
+ identifier field in ICMP query messages is set by Query sender and
+ returned unchanged in 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 to uniquely identify ICMP queries of
+ all types from any of the local hosts. Modifications to ICMP error
+ messages are discussed in a later section, as that involves
+ modifications to ICMP payload as well as the IP and ICMP headers.
+
+ In 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 distinction between TCP, UDP or ICMP query sessions
+ originated from itself versus those originated from the nodes on
+ 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, serviced by a NAPT router.
+
+3.0. Translation phases of a session.
+
+ The translation phases with traditional NAT are 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.
+ Subsequent to that, all other outgoing sessions originating from the
+ same private address will 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 would be 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 private
+ host establish multiple simultaneous sessions originating from the
+
+
+
+Srisuresh & Egevang Informational [Page 7]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ 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 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 will be subject to session lookup for translation purposes.
+ The exact nature of 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 Basic NAT model, the IP header of every packet must be modified.
+ This modification includes 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
+ update of checksum in the TCP/UDP headers. This is because TCP/UDP
+ checksum also covers a pseudo header which contains the source and
+ destination IP addresses. As an exception, UDP headers with 0
+ checksum should not be modified. As for ICMP Query packets ([ICMP]),
+ no further changes in ICMP header are required as the checksum in
+ ICMP header does not cover IP addresses.
+
+ In NAPT model, modifications to IP header are similar to that of
+ Basic NAT. For TCP/UDP sessions, modifications must be extended to
+ include translation of TU port (source TU port for outbound packets
+ and destination TU port for inbound packets) in the TCP/UDP header.
+ ICMP header in ICMP Query packets must also be modified to replace
+ the query ID and ICMP header checksum. Private host query ID must be
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 8]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ translated into assigned ID on the outbound and the exact reverse on
+ the inbound. ICMP header checksum must be corrected to account for
+ Query ID translation.
+
+4.2. Checksum Adjustment
+
+ NAT modifications are per packet based and can be very compute
+ intensive, as they involve one or more checksum modifications in
+ addition to simple field translations. Luckily, we have an algorithm
+ below, which 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 start of header) and even lengths (i.e., olen and nlen
+ below must be even). Sample code (in C) for this 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;
+ }
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 9]
+
+RFC 3022 Traditional NAT January 2001
+
+
+4.3. ICMP error packet modifications
+
+ Changes to ICMP error message ([ICMP]) will include changes to IP and
+ ICMP headers on the outer layer as well as changes to headers of the
+ packet embedded within the ICMP-error message payload.
+
+ In order for NAT to be transparent to end-host, the IP address of the
+ IP header embedded within the payload of 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 changes to payload.
+
+ In a NAPT setup, if the IP message embedded within 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
+
+ One of the most popular applications, "FTP" ([FTP]) would require an
+ ALG to monitor the control session payload to determine the ensuing
+ data session parameters. FTP ALG is an integral part of most NAT
+ implementations.
+
+ The FTP ALG would require a special table to correct the TCP sequence
+ and acknowledge numbers with source port FTP or destination port FTP.
+ The table entries should have source address, destination address,
+ source port, destination port, delta for sequence numbers and a
+ timestamp. New entries are 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 are incremented on the outbound and acknowledge numbers are
+ decremented on the inbound by this delta.
+
+ 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, however, the translations must be
+ extended to include the TCP port octets (in ASCII) following the
+ address octets.
+
+4.5 DNS support
+
+ Considering that sessions in a traditional NAT are predominantly
+ outbound from a private domain, 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
+
+
+
+Srisuresh & Egevang Informational [Page 10]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ 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 external DNS
+ server to find address mapping for the external hosts.
+
+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. The result of leaving the
+ addresses untranslated would be that private addresses along the
+ source route are exposed end to end. This should not jeopardize the
+ traversal path of the packet, per se, as 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 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 the following. 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 addressees of stub A. In this case,
+ the routers in stub A would not be able to distinguish the global
+ address of stub B from its own private addresses.
+
+5.2. Private address space recommendation
+
+ [RFC 1918] has recommendations on address space allocation for
+ private networks. 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, while 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
+
+
+
+
+Srisuresh & Egevang Informational [Page 11]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ 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 service provider router over WAN
+ link, and the service provider router will have a static route
+ configured to forward NAT packets (i.e., those whose destination IP
+ address fall within the range of NAT managed global address list) to
+ NAT router over WAN link.
+
+5.4. Switch-over from Basic NAT to NAPT
+
+ In Basic NAT setup, when private network nodes outnumber 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 will
+ ensure that hosts on private network will have continued,
+ uninterrupted access to the external nodes and services for most
+ applications. Note, however, 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 sub-sections 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 private network is abusing the Internet in some way (such
+
+
+
+Srisuresh & Egevang Informational [Page 12]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ 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 external router (i.e.,
+ service provider router) from 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 to
+ these addresses and hence 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 to optionally support 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 are doomed to fail. The reason is
+ as follows. Only the first fragment contains the TCP/UDP header that
+ would be necessary to associate the packet to 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 same
+ fragmentation id, and 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.
+
+
+
+Srisuresh & Egevang Informational [Page 13]
+
+RFC 3022 Traditional NAT January 2001
+
+
+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 of "IP
+ masquerade". FreeBSD public domain software has 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 on-line 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.
+
+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.
+
+
+
+Srisuresh & Egevang Informational [Page 14]
+
+RFC 3022 Traditional NAT January 2001
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 15]
+
+RFC 3022 Traditional NAT January 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srisuresh & Egevang Informational [Page 16]
+