Internet Draft B. Ford Document: draft-ford-behave-gen-00.txt M.I.T. Expires: August 2005 P. Srisuresh Caymas Systems February 2005 Design Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document discusses design principles and behavioral properties required to make Network Address Translators (NAT) more predictable and compatible with diverse application protocols. First, this document presents a concrete architectural model for NAT devices and Ford [Page 1] draft-ford-behave-gen-00.txt February 2005 defines important terms used in conjunction with NAT design. This architectural model sets the stage for a set of concrete recommendations for NAT implementors and vendors, as being contemplated by the BEHAVE working group. The recommendations made by this document are independent of transport protocol; a set of companion documents provide behavioral recommendations specific to particular transport protocols. Table of Contents 1. Introduction ................................................. 1.1. Applicability Statement ................................. 1.2. Terminology ............................................. 2. NAT Design Principles ........................................ 2.1. Types of NAT ............................................ 2.2. Static and Dynamic NAT State ............................ 2.3. "Sessions" and "NAT Sessions" ........................... 2.3.1. Types of NAT Sessions ................................. 2.4. Address/Port Binding .................................... 2.4.1. Cone/Symmetric NAT Terminology ........................ 3. Transport Protocol Compatibility ............................. 4. Address and Port Translation Behavior ........................ 4.1. Source Endpoint Translation ............................. 4.2. Source IP Address Translation ........................... 5. Filtering of Unsolicited Incoming Traffic .................... 6. Multi-Level NAT .............................................. 6.1. Hairpin Translation ..................................... 6.2. Scenarios Requiring Hairpin Translation ................. 6.3. Implementing Hairpin Translation ........................ 6.4. Partial Hairpin Translation ............................. 7. DHCP-Configured NATs ......................................... 7.1. Private Subnet Selection ................................ 7.2. The NAT as a Communication Endpoint ..................... 8. Summary of Requirements ...................................... 9. Security Considerations ...................................... 1. Introduction Due to various technical and market pressures, Network Address Translation (NAT) has become a ubiquitous part of today's Internet, though it violates many of the Internet's fundamental design principles. Even in moving toward IPv6 to eliminate IP address space pressure and thereby alleviate the need for NAT, NAT itself provides one of the most practical short-term transition mechanisms [NAT-PT]. NAT causes well-known problems for applications, however, especially those that carry IP addresses in their message payloads [NAT-PROT]. RFC 3235 [NAT-APPL] provides some recommendations for making Ford [Page 2] draft-ford-behave-gen-00.txt February 2005 application protocols compatible with NAT, but these recommendations do not adequately address applications with "peer-to-peer" (P2P) communication patterns, which must by their nature carry IP addresses in message payloads. Common applications that suffer from this problem include Voice Over IP and Multimedia Over IP [SIP, H.323], as well as online games. In the face of the prevalence of NAT, applications are forced to use ad-hoc techniques in an attempt to function reliably across NATs. A companion document [BEH-STATE] describes the current "state of the art" in NAT traversal techniques, summarizing existing methods that existing widely-deployed applications implement. Since there are presently no standards for NAT behavior, there is currently no way for applications to work reliably over all existing NATs, no matter how "intelligent" the application's NAT traversal techniques may be. As pointed out in RFC 3424 [UNSAF], "From observations of deployed networks, it is clear that different NAT boxes' implementation vary widely in terms of how they handle different traffic and addressing cases." This wide degree of variability is one part of what contributes to the overall brittleness introduced by NATs and makes it extremely difficult to predict how any given protocol will behave on a network traversing NATs. Discussions with many of the major NAT vendors have made it clear that they would prefer to deploy NATs that were deterministic and caused the least harm to applications while still meeting the requirements that caused their customers to deploy NATs in the first place. The problem the NAT vendors face is that they are not sure how best to do that or how to document how their NATs behave. The primary goal of this document is to define a specific set of requirements for NAT behavior that will reduce the unpredictability and brittleness they introduce and enable applications to traverse them reliably. The requirements defined here largely represent what many vendors are already doing. These requiresments are not expected to make NAT implementation significantly more difficult, or to affect NAT performance or security negatively. 1.1. Applicability Statement The requirements of this specification apply generally to all NAT variations, including those described in RFC 2663 [NAT-TERM]: Traditional NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed NATs. However, it is not within the scope of this specification to address all issues specific to all possible NAT variations. The primary focus of this document is on Traditional NAT with Network Address/Port Translation (NAPT), this being the most pervasively deployed variant today. This document is meant to cover NATs of any size, from small residential NATs to large enterprise Ford [Page 3] draft-ford-behave-gen-00.txt February 2005 NATs. Traditional NAT inherently incorporates a certain level of firewall functionality. Since hosts on a private network behind a NAT do not have globally routable IP addresses, they cannot be reached by external hosts except via temporary public endpoints the NAT sets up, either by explicit configuration or as a result of internal hosts initiating communication with external hosts. In effect, Traditional NAT inherently implements a "base" firewall policy of allowing outgoing sessions while rejecting "unsolicited" incoming communication attempts. Many NAT devices also provide a variety of additional configurable firewall capabilities on top of this base policy, often involving analysis of traffic at many protocol levels. Firewall functionality in general is out of the scope of this specification, but this specification does cover the "base" filtering policy of rejecting unsolicited incoming connection attempts. Many enterprise NATs have special requirements for security, multihoming and so forth, which may impose restrictions on the NAT's behavior. Such extra requirements are outside the scope of this document, and it is understood that satisfying these additional requirements may prevent enterprise NATs from being fully compliant to this specification. Nevertheless, NAT vendors should ensure that their NATs are compliant in their default configuration, and leave control over non-compliant, potentially interfering behaviors to the discretion of the NAT's administrator. NAT traversal strategies that involve explicit signalling between the application and the NAT [SOCKS, RSIP, MIDCOM, UPNP] are out of the scope of this document. This document, and its transport-specific companion documents [BEH- TCP, BEH-UDP] focus strictly on the behavior of the NAT itself, and not on the behavior of applications that may desire to traverse NATs. A separate companion document [BEH-APP] provides recommendations for application designers on how to make applications work robustly over NATs that follow the behavioral requirements specified here. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. A NAT that complies with all of the mandatory requirements of this specification (i.e., the "MUST"), is "compliant with this specification." A NAT that complies with all of the requirements of this specification (i.e., including the "RECOMMENDED" and SHOULD) is Ford [Page 4] draft-ford-behave-gen-00.txt February 2005 "fully compliant with all the mandatory and recommended requirements of this specification." 2. NAT Design Principles This section outlines a set of basic NAT design principles, and defines a number of technical terms, that are important in making NATs behave deterministically and in enabling them to support application protocols of all types. Not all existing NATs follow the principles outlined here exactly, but many of them do. In large, therefore, part this section merely represents a codification of existing, widely accepted but informal "best current practices" for NAT design. 2.1. Types of NAT Readers are urged to refer to RFC 2663 [NAT-TERM] for information on basic NAT taxonomy and terminology. Most NAT devices deployed today fall under the category of Traditional NAT, which implement an asymmetric translation scheme that multiplexes many hosts on a "private" network onto one or a few "public" IP addresses. Readers may refer to RFC 3022 [NAT-TRAD] for detailed information on traditional NAT. Traditional NAT in turn has two subcategories: Basic NAT and Network Address/Port Translator (NAPT). NAPT is by far the most common today as it allows multiple internal hosts to share a single public IP address. When an internal host opens an outgoing TCP or UDP session through a NAPT, the NAPT assigns the session a public IP address and port number so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. The effect is that the NAPT establishes a NAT session to translate the (private IP address, private port number) tuple to a (public IP address, public port number) tuple and vice versa for the duration of the session. This specification uses the term "NAT" to refer to both Basic NAT and Network Address/Port Translation (NAPT). The specification is written assuming the general case of NAPT, but all the same considerations apply (if sometimes trivially) for Basic NAT. 2.2. Static and Dynamic NAT State The following diagram presents a general architectural model of how a NAT functions. This model is not intended to prescribe a specific method of implementing NAT, but rather as a tool for understanding the important behavioral properties described later in this document. Some aspects of this model have already been documented in RFC 4008 Ford [Page 5] draft-ford-behave-gen-00.txt February 2005 [NAT-MIB]. NAT Device +--------------------------------------------------+ | | | +----------+ +----------+ +----------+ | | | Address | | Address/ | | NAT | | | | Maps |====>| Port |====>| Sessions | | | |(Conf. DB)| | Bindings | | | | | +----------+ +----------+ +----------+ | | ^ ^ ^ | | | | | | External | +----------------------------------+ | Internal Intf. | | | | Intf. ---------+ <---> | NAT Packet Translation | <---> +--------- | | | | | +----------------------------------+ | | | +---------------------------------------------- ---+ In this model, a NAT has exactly two logical network interfaces, labelled External and Internal, respectively. The NAT translates packets as they flow between the External and Internal interfaces, in the process using information from several different internal tables or databases to determine how each packet should be translated: Address Maps Table: The "Address Maps" table represents the NAT's static configuration database, which is controlled more-or-less directly by the user or network administrator. The Address Maps table determines the type of NAT functionality the device implements, for example, such as Basic NAT, NAPT, Bidirectional NAT, Twice-NAT, or a combination thereof. The Address Maps table also contains any permanent mappings the user may have configured between IP addresses or endpoints on the External and Internal realms: for example, a mapping between port 80 on the NAT's public IP address and a particular Web server located on the internal network. Address/Port Bindings Table: This table represents a portion of the NAT's dynamic state, which records associations between internal and external endpoints that the NAT has set up. The NAT can create bindings in this table either statically, to reflect configuration information in the Address Maps Table, or dynamically, as a side effect of setting up translation state for previous communication sessions flowing across the NAT. The NAT then uses the binding table to determine Ford [Page 6] draft-ford-behave-gen-00.txt February 2005 how to translate subsequent new sessions flowing across the NAT, as described in more detail below. NAT Session Table: Finally, the NAT Session Table represents the dynamic state that the NAT uses to translate the individual packets comprising a particular communication session flowing across the NAT, once the session has been initiated. This table thus contains the fine- grained (and usually performance-critical) control information that the NAT must refer to for each packet it translates. 2.3. "Sessions" and "NAT Sessions" This document uses the standalone term "session", as defined in RFC 2663, to refer to a logical flow of traffic between two endpoints within a single IP addressing realm. From RFC 2663: "TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP ports, target IP address, target TCP/UDP Port)." The logical direction of a session is the direction in which the session was initiated, not the direction in which particular packets flow along the session. For example, a session initiated by a host on the private network behind a NAT is permanently considered to be an "outgoing session", even though subsequent packets flow in both directions in that session. When a logical flow of traffic crosses a NAT, the session tuple that identifies that logical flow on one side of the NAT is different from the corresponding session tuple that identifies the same logical flow on the other side of the NAT, due to the translation of one or more IP addresses and port numbers. Although ordinary nodes in the IP address realms on either side of the NAT are only aware of one session tuple or the other, the NAT itself must of course be aware of the session tuples for both IP address realms corresponding to this logical flow. This document uses the term "NAT session" as defined in RFC 4008 [NAT-MIB], to refer to a logical communication session from the NAT's viewpoint. A NAT session is conceptually defined by a tuple of the following form: (origin session, origin side, target session, target side) The "origin side" and "target side" components of this tuple are simply the tags "Internal" or "External". An actual NAT implementation might use a one-bit flag, for example, or a physical network interface name or number, to represent these "side" tags. The "origin side" indicates which side of the NAT, and thus which IP Ford [Page 7] draft-ford-behave-gen-00.txt February 2005 address realm, the logical session originated from: that is, on which side the NAT received the packet that first initiated the session. The "target side" indicates which side of the NAT and which address realm the logical session is targetted toward. A NAT Session's origin and target endpoints are usually on opposite sides of the NAT, but not always. The "origin session" and "target session" components are ordinary session tuples as described above, describing the session's identity within the IP address realm indicated by the corresponding "side" component. For example, the "origin session" is the complete (source IP, source port, dest IP, dest port) tuple describing the session's identity on the side of the NAT from which the session was initiated, and the "target session" is the complete (source IP, source port, dest IP, dest port) tuple describing the session's identity as it appears on the side of the NAT to which the session was targetted. 2.3.1. Types of NAT Sessions There are three types of NAT sessions of particular relevance to Traditional NAT, which is the only basic variety of NAT directly within the scope of this document. Outgoing NAT Session: An "outgoing NAT session" is a NAT session having the form (origin session, Internal, target session, External), and represents a logical communication flow that was originated by a node on the internal ("private") IP address realm and is directed toward a node on the external ("public") IP address realm. In practice outgoing sessions are the most common, because they usually represent client/server communication sessions from a "client" host on the private network directed to a well-known "server" host on the public network, only the latter of which has a global IP address. In an outgoing session, the destination IP address and destination port number is usually unchanged between the origin session and the target session: the NAT only translates the source IP address and, in the case of NAPT, the source port. Incoming NAT Session: An "incoming NAT session" is a NAT session having the form (origin session, External, target session, Internal), and represents a logical communication flow that was initiated by a node on the external IP address realm and is targetted at a node on the internal network behind the NAT. Due to the filtering behavior to be described in detail later, incoming sessions are usually only permitted by the NAT on certain specific ports, and only by the Ford [Page 8] draft-ford-behave-gen-00.txt February 2005 explicit configuration of the administrator: a NAT usually rejects all incoming sessions by default. Since incoming NAT sessions are usually only allowed under specific conditions defined by the administrator, NAT behavior for incoming NAT sessions is largely outside the scope of this document. Hairpin NAT Session: Finally, a "hairpin NAT session" is a NAT session having the form (origin session, Internal, target session, Internal), and represents a logical communication session whose endpoints are both on the internal network, but which nevertheless flows "through" the NAT and requires address translation. Hairpin NAT sessions and hairpin translation, to be described in detail later, arise out of the necessity of supporting reliable application communication across multiple Traditional NATs arranged in increasingly common multi-level hierarchical configurations. In a hairpin session, both source and destination IP addresses and port numbers usually require translation. 2.4. Address/Port Binding This document uses the term "address binding" as defined in RFC 3022 in the context of Basic NAT, and uses the term "port binding" as defined in RFC 4008 for Network Address/Port Translation (NAPT). A NAPT may implement both Address and Port Bindings. An address binding is a persistent association between a particular IP address on the NAT's internal address realm, and an IP address on its external realm, which the NAT assigns as the internal node's temporary "public address" for the purpose of communicating across the NAT. A port binding similarly represents a persistent association between an internal (IP address, TCP/UDP port) endpoint and a corresponding external (IP address, TCP/UDP port) endpoint. A NAPT generally establishes a port binding while setting up the first outgoing NAT session originating from a particular internal (IP address, TCP/UDP port) endpoint. Once that binding has been established, the NAT re- uses the same port binding whenever it subsequently establishes a new outgoing NAT session originating from the same internal endpoint (but possibly targetted at a different external endpoint). Not all existing NATs use address or port bindings to determine their IP address and port translation behavior, however. Some existing NATs merely use their NAT Session Table or some equivalent thereof to determine how to translate a new session crossing the NAT. The architectural notion of address/port binding is crucial to making Ford [Page 9] draft-ford-behave-gen-00.txt February 2005 NATs behave in a predictable fashion that supports all application communication patterns, however. These specific required behaviors are defined in detail later, but the architectural model presented here provides the framework necessary to understand and implement these behaviors correctly. 2.4.1. Cone/Symmetric NAT Terminology RFC 3489 [STUN] defines terminology for several different NAT variations. In particular, it uses the terms "Full Cone", "Restricted Cone", "Port Restricted Cone" and "Symmetric" to refer to different variations of a NAT's IP address and port assignment behavior. These terms have historically been used only to describe a NAT's behavior with respect to the UDP transport, although the issues these terms were intended to address are also important for TCP. Historically, a NAT that uses address/port binding for UDP translation has been referred to as a "Cone" NAT, the Full/Restricted/Port-Restricted subtype referring to the NAT's packet filtering behavior for UDP sessions. Conversely, a NAT that does NOT use address/port bindings for UDP translation has commonly been referred to as a "Symmetric" NAT. Unfortunately, besides being historically attached to the UDP transport protocol, these categories have proven insufficient to represent the full range of NAT behaviors that have been observed to exist. This specification therefore defines specific NAT behaviors individually instead of using the broad Cone/Symmetric terminology. The specific relationship between the historical Cone/Symmetric terminology and the individual NAT behaviors will be defined as appropriate later in this document. 3. Basic NAT Requirements As a preliminary step, this section defines several basic requirements for NAT behavior that affect all types of application protocols that may traverse the NAT, not just protocols with peer-to- peer communication patterns. 3.1. Distinguishing External and Internal Packet Flows In the architectural model defined above in Section 2, a NAT has exactly two logical network interfaces, Internal and External. Actual NAT devices may have more than two physical interfaces, however. Consumer NAT routers, for example, often provide one External "uplink" port and several Internal ports forming a switched Ethernet segment. From the perspective of the IP-level NAT functionality embedded in the NAT router, however, the NAT still has Ford [Page 10] draft-ford-behave-gen-00.txt February 2005 exactly one "logical" External port and one "logical" Internal port. A particular NAT device might even have only one actual physical network interface, and use a link-level mechanism such as 802.1Q VLAN tags to distinguish between packets flowing across this interface that comprise the logically separate External and Internal network segments. Large enterprise routers often support address translation between separate VLAN-tagged network segments in this way, a feature known as "one-armed routing", and the "two logical interface" architectural model is not intended to preclude such an implementation. The key architectural requirement for such an implementation is that the NAT device have some precise way to distinguish between the logically separate External and Internal packet flows, using only information available below the IP layer. One possible design approach that is specifically forbidden, however, is to use IP-level or higher-level packet contents to distinguish between External and Internal packet flows. It may be tempting in some situations, for example, to design a NAT device so that it treats all of its physical network interfaces uniformly, but distinguishes between "public" and "private" packets by the source IP address in their IP headers. Such a design is NOT permissible for a NAT conforming to this document. In some increasingly common and pragmatically unavoidable network topologies involving NAT, the IP subnets on each side of the NAT may have numerically overlapping IP address ranges, making it impossible for the NAT to distinguish between "external" and "internal" packets by packet IP header contents alone. Such a design would also be highly inadvisable from a security perspective, since it is relatively easy for an attacker to spoof source IP addresses. REQ-1 A NAT MUST distinguish between packets comprising the logically separate Internal and External packet flows solely using information below the IP layer. 3.2. Transport Protocol Compatibility TCP and UDP have become by far the most common transports for widely deployed Internet protocols, although other transports exist as well. Basic NAT is normally compatible with most transport protocols automatically, because a Basic NAT does not need to examine or modify the transport-level headers in packets crossing the NAT in order to translate port numbers. A Network Address/Port Translator (NAPT), however, inherently must choose some particular set of transport protocols to support, since the port number portion of an Internet communication endpoint is located in the transport-layer rather than network-layer protocol headers. For widespread application compatibility, therefore, it is crucial that any NAT support at least Ford [Page 11] draft-ford-behave-gen-00.txt February 2005 the TCP and UDP transports, and NATs are encouraged to support other transport protocols as well as they become standardized and deployed. REQ-2 A NAT MUST support the TCP protocol, as described in [BEH- TCP], and MUST support the UDP protocol for unicast communication, as described in [BEH-UDP]. A NAT SHOULD also support receiving of UDP multicast packets using the IGMP protocol, and if it does so it MUST behave as described in [BEH-IGMP]. A NAT MAY support other transport protocols as deemed appropriate. 4. Address and Port Translation Behavior The single aspect of NAT behavior of greatest importance to applications with peer-to-peer communication patterns is how the NAT assigns a public source (IP address, port) endpoint to a new outgoing session crossing a NAT, given the private source (IP address, port) endpoint on the internal network from which the session originated. When an internal endpoint initiates a new communication session targetted at an endpoint on the external network, the NAT establishes a new outgoing NAT session so that subsequent response packets from the external endpoint can be received by the NAT, translated, and forwarded back to the original internal endpoint. To form this new outgoing NAT session, the NAT uses the source and destination endpoints from the original packet that initiated the session, in order to define the internal "origin session" component of the NAT session. The NAT must then compute a corresponding "target session" component in order to define the corresponding communication session as it will appear on the external network. For Traditional NAT, the destination address and port number is not translated in outgoing NAT sessions, so the NAT merely needs to assign an external source IP address and transport-level port number to form the new NAT session. If the NAT receives a packet from the internal network with a given (internal source IP, internal source port, external target IP, external target port) session tuple, for example, the NAT must translate the internal source endpoint to a corresponding external source endpoint that is valid in the external IP address realm, in order to form the new outgoing NAT session. We refer to the way the NAT translates an internal source endpoint into an external source endpoint, while establishing a new outgoing NAT session, as the NAT's "source endpoint translation behavior". This issue is of general relevance for any transport protocol that use port numbers to represent communication endpoints, including both TCP and UDP in particular. This section defines and provides transport-independent recommendations for NAT source endpoint Ford [Page 12] draft-ford-behave-gen-00.txt February 2005 translation behavior. Additional considerations apply to specific transport protocols; see the respective companion documents for more details. 4.1. Source Endpoint Translation For applications with peer-to-peer communication patterns, it is important to distinguish the behavior of the NAT when applications establish multiple simultaneous outgoing NAT sessions from a single internal source endpoint to distinct external target endpoints. For example, suppose a node X on the internal network has already initiated an outgoing NAT session from internal source endpoint X:x (address:port), to a particular external destination endpoint Y1:y1. The NAT has mapped the internal source endpoint, X:x, to an external source endpoint X1':x1' in the external IP address realm, to form the full NAT session tuple. Now suppose node X initiates a new session from the same internal source endpoint, X:x, to a new external destination endpoint Y2:y2, and in response the NAT maps the internal source endpoint X:x to an external source endpoint X2':x2' to form the NAT session tuple to translate this new session. The relationship between X1':x1' and X2':x2' for various combinations of the relationship between Y1:y1 and Y2:y2 is critical for describing the NAT behavior. This arrangement is illustrated in the following diagram: E +------+ +------+ x | Y1 | | Y2 | t +--+---+ +---+--+ e | Y1:y1 Y2:y2 | r +----------+ +----------+ n | | a X1':x1' | | X2':x2' l +--+---+-+ ...........| NAT |............... +--+---+-+ I | | n X:x | | X:x t ++---++ e | X | r +-----+ n a l We define the following source endpoint translation behaviors: Consistent Source Endpoint Translation: Ford [Page 13] draft-ford-behave-gen-00.txt February 2005 When the NAT establishes the first outgoing NAT session from an internal IP address and port X:x to any external target endpoint, choosing some corresponding external source IP address and port X1':x1' in the process, the NAT also establishes a persistent port binding between the internal endpoint X:x and X1':x1' in the process, and uses that port binding to determine the external source endpoint for any subsequent outgoing NAT sessions that originate from the same internal source endpoint X:x. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. In terms of the NAT terminology in RFC 3489, this translation behavior constitutes "Cone NAT", where the sub-type (Full Cone, Restricted Cone, or Port-Restructed Cone) is dependent on the filtering behavior to be discussed later. As a consequence of establishing a port binding from X:x to X1':x1' in response to the first outgoing session originating from X:x, the NAT also effectively "allocates" the external source endpoint X1':x1' exclusively to the use of this port binding, so that no other session originating from a different internal source endpoint may be translated so as to use the same external source endpoint X1':x1', while this port binding is active. This "exclusive port allocation" is crucial for a NAT to have consistent source endpoint translation behavior, because otherwise the NAT could "paint itself into a corner" and make it impossible to translate future sessions involving the original source endpoint X:x correctly. For example, suppose the NAT has established a NAT session that translates the internal session (X:x,Y1:y1) to an external session (X1':x1',Y1:y1). Suppose further that it has incorrectly established a second NAT session translating an unrelated internal session (X2:x2,Y2:y2) to the external session (X1':x1',Y2:y2), re-using the external source endpoint X1':x1' between these two unrelated sessions. If node X now initiates a new outgoing session from X:x to Y2:y2, then to preserve the "consistent source endpoint translation" property the NAT would have to translate the new internal session (X:x,Y2:y2) to the external session tuple (X1':x1',Y2:y2) - but this external session tuple is the same as the external session tuple the NAT has already assigned to the prior unrelated session originating from X2:x2, and the two sessions would hence be indistinguishable on the external network. In effect, therefore, a NAT MUST exclusively allocate an external source port to a single internal source port for the duration of the corresponding port binding, in order to have consistent source endpoint translation. Inconsistent Source Endpoint Translation: When setting up a new outgoing NAT session from an internal source endpoint X:x to an external target endpoint Y2:y2, the NAT may map Ford [Page 14] draft-ford-behave-gen-00.txt February 2005 the internal source endpoint X:x to any external source endpoint X2':x2' of its choosing, regardless of how it has previously translated any existing sessions originating from the same internal source endpoint X:x. From an RFC 3489 NAT perspective, but not necessarily a filtering perspective, this behavior constitues "Symmetric NAT". It is important to note that this aspect of NAT behavior makes no difference to the basic security properties of the NAT. The NAT's fundamental security properties are determined by which packets the NAT allows in and which it does not: namely, the NAT's filtering behavior, discussed below. REQ-3 A NAT MUST have "Consistent Source Endpoint Translation" behavior. 4.2. Source IP Address Translation Some NATs are capable of assigning public source IP addresses for NAT sessions from a pool of public IP addresses managed by the NAT, rather than just a single IP address. This "IP address pooling" feature is especially common with larger enterprise NATs. How such a NAT chooses a source public IP address from its pool for a new NAT session varies, however. We define the following categories of NAT behavior: Paired Source IP Address Translation: The NAT always chooses the same public source IP address for all NAT sessions originating from a given private source IP address on the internal network, regardless of the port numbers or destination IP address. Such a NAT in essence maintains the "IP address identity" of a given internal host as its communication sessions cross the NAT. Arbitrary Source IP Address Translation: The NAT may select a public source IP address for a new NAT session in an arbitrary fashion, possibly resulting in a single private IP address being translated to different public source IP addresses in different NAT sessions at the same time. Some large enterprise NATs deliberately use Arbitrary Source IP Address Translation behavior as a means of hiding the IP address assigned to specific private endpoints, by making their assignment less predictable. Such NATs can cause issues for applications that use multiple ports from the same endpoint but do not negotiate IP addresses individually: e.g., applications using RTP and RTCP over Ford [Page 15] draft-ford-behave-gen-00.txt February 2005 UDP. Note that this aspect of NAT behavior is related but ultimately orthogonal to the source endpoint translation behavior discussed in the last section. It is possible for a NAT to have "Consistent Source Endpoint Translation" behavior but "Arbitrary Source IP Address Translation" behavior, because consistent source endpoint translation only requires a source endpoint (including source IP address) to be translated consistently for a given source port: sessions originating from the same private IP address but different ports may be translated to entirely different public source IP address. Similarly, it is technically possible (though not recommended) for a NAT to have "Inconsistent Source Endpoint Translation" behavior but "Paired Source IP Address Translation" behavior. For the special case of Basic NAT, however, these two aspects of NAT behavior coincide because the NAT does not translate port numbers at all. REQ-4 It is RECOMMENDED that a NAT have "Paired Source IP Address Translation" behavior. This requirement is not applicable to NATs that do not support IP address pooling. 5. Filtering of Unsolicited Incoming Traffic Most NATs implement a packet filtering function that restricts communication between a private network and the public Internet for security purposes. NATs usually implement configurable filtering policies, but the most common filtering policy implemented by default in most "off-the-shelf" consumer NAT-routers is simply to permit a communication session to cross the NAT if and only if it was initiated from the private network. All packets arriving from the public Internet are dropped unless they are part of an existing communication session that was previously initiated by a host on the private network. When an internal host opens a new outgoing session through a NAT, the NAT establishes a filtering rule or "firewall hole" that enables subsequent incoming packets related to that session to be accepted by the NAT and forwarded to the appropriate internal host. NATs vary based on how "wide" a hole they create as a result of this new outgoing session, however: namely, whether this filtering rule only accepts traffic from the specific external endpoint to which the original outgoing session was targetted, or whether it accepts traffic from a wider range of external endpoints. We define the following specific filtering behaviors: External Endpoint Independent Filtering: Ford [Page 16] draft-ford-behave-gen-00.txt February 2005 When an internal host initiates a session from internal endpoint X:x to external endpoint Z:z, causing the NAT to map X:x to some public source endpoint X1:x1, the NAT also establishes a filtering rule that accepts ALL subsequent incoming traffic directed to X1:x1, and forwards it to X:x, regardless of the origin of this subsequent incoming traffic. In other words, sending packets from an internal host behind the NAT to any external IP address is sufficient to allow subsequent packets from all external endpoints back to the internal endpoint. From an RFC 3489 filtering perspective, this is a "Full Cone NAT". External IP Address Dependent Filtering: When an internal host initiates a session from internal endpoint X:x to external endpoint Z:z, causing the NAT to map X:x to X1:x1, the resulting filtering rule accepts a subsequent incoming packet directed at X1:x1 if and only if the source IP address in that packet matches the original destination IP address, Z. The NAT effectively filters out packets from any external endpoint Z':z' directed at X1:x1, unless the internal endpoint X:x has previously sent outgoing packets to external IP address Z' (independently of the port number z'). In other words, to receive packets from a specific external endpoint, it is first necessary for the internal endpoint to send packets to any port at that specific external endpoint's IP address. From an RFC 3489 filtering perspective, this is a "Restricted Cone NAT". External IP Address and Port Dependent Filtering: This behavior is similar to the previous behavior, except that the external port is also used in the filtering decision. When an internal host initiates a session from internal endpoint X:x to external endpoint Z:z, causing the NAT to map X:x to X1:x1, the resulting filtering rule accepts a subsequent incoming packet directed at X1:x1 only if that packet's source IP address is Z and its source port is z. The NAT effectively filters out packets from an external host Z':z' targetted at X1:x1, unless X:x has previously initiated a session specifically with the external endpoint Y:y. In other words, for receiving incoming traffic from a specific external endpoint, it is necessary for the internal endpoint first to send packets to that external endpoint's specific IP address and port number. From an RFC 3489 filtering perspective, this is behavior can represent either a "Port Restricted Cone NAT" or a "Symmetric NAT", as they both have the same filtering behavior. The filtering behavior implemented by a NAT affects the effective security provided by a NAT's firewall, because a "tighter" filtering Ford [Page 17] draft-ford-behave-gen-00.txt February 2005 rule limits the internal host's vulnerability to unsolicited traffic from external sources that the internal host has not contacted recently and may have no interest in. The security provided by such filtering behavior is limited, of course, since it is generally easy for an external to spoof source IP addresses and port numbers in packets they send, but at least it requires a malicious external host to know (or guess) the necessary source endpoint to spoof. REQ-5 It is RECOMMENDED that a NAT have "External IP Address Dependent Filtering" behavior. 6. Multi-Level NAT As discussed more thoroughly in [BEH-TOP], NATs are increasingly, and often unintentionally, used to create hierarchically interconnected clusters of private networks in which some hosts are separated from the main Internet by more than one level of Traditional NAT. The following diagram illustrates this situation: Main Internet (public IP addresses) ------------------+---------------+-- | | | | +-------------+ Host S | NAT 1 | +-------------+ | | Private Network 1 (private IP addresses) ----+---------------------------+---- | | | | +-------+ +-------+ | NAT 2 | | NAT 3 | +-------+ +-------+ | | | | Private Network 2 Private Network 3 (private IP addresses) (private IP addresses) ----+-----------+---- ----+-----------+---- | | | | | | | | Host A Host B Host C Host D NAT 1 may for example be a large enterprise NAT deployed by an ISP that does not have enough IP addresses to assign one to each of its Ford [Page 18] draft-ford-behave-gen-00.txt February 2005 customers, an increasingly common situation especially in developing countries. NATs 2 and 3, in turn, are standard consumer-level NATs deployed independently by the ISP's customers to multiplex their small home or business networks onto the single IP address their ISP gives them via DHCP. Neither the ISP nor the customers necessarily intend to create this hierachical multi-level NAT topology; in fact the majority of people who deploy consumer-level NATs probably know little or nothing about IP addresses and Internet protocols, let alone address translation. These multi-level NAT arrangements arise merely as a consequence of the same technical and economic factors that drove the widespread deployment of NAT in the first place. NAT vendors must therefore consider such multi-level NAT topologies and ensure that their NATs behave robustly in such situations. This section defines specific NAT requirements for this purpose. 6.1. Hairpin Translation Hairpin translation refers to the ability of a NAT to allow multiple private endpoints behind the NAT to communicate with each other using each other's *public* (translated) endpoints. In a hairpin translation session, The NAT must translate both the source and destination endpoints in all packets comprising the session, even though these packets do not actually "cross" the NAT but merely enter the NAT's private interface and leave via the same interface. When two hosts reside on different private networks but nevertheless have at least one NAT in common, it is not possible for the two hosts to establish direct peer-to-peer communication with each other unless the common NAT(s) support hairpin translation. The following diagram illustrates this situation. Ford [Page 19] draft-ford-behave-gen-00.txt February 2005 Server S (S:s) | ^ Session A-S ^ | ^ Session B-S ^ | (A1:a1,S:s) | | | (B1:b1,S:s) | | +-------------+ | NAT 1 | +-------------+ | +------------------------+------------------------+ | | | ^ Session A-S ^ ^ Session B-S ^ | | | (A2:a2,S:s) | | (B3:b3,S:s) | | | | | ^ Session A-B | ^ Session B-A ^ | | | (A2:a2,B1:b1) | | (B2:b2,A1:a1) | | | | +-------------+ +-------------+ | NAT 2 | | NAT 3 | +-------------+ +-------------+ | | | ^ Session A-S ^ ^ Session B-S ^ | | | (A:a,S:s) | | (B:b,S:s) | | | | | ^ Session A-B ^ ^ Session B-A ^ | | | (A:a,B1:b1) | | (B:b,A1:a1) | | | | Host A Host B (A:a) (B:b) 6.2. Scenarios Requiring Hairpin Translation Suppose Host A in the topology above initiates an outgoing session A- S from private endpoint A:a to public endpoint S:s on Host S, a "well-known" server on the main Internet. In setting up this outgoing session, NAT 2 first creates an outgoing NAT session that translates the session tuple (A:a, S:s) on Private Network 2 to a corresponding session tuple (A2:a2, S:s) on Private Network 1. This outgoing session then passes through NAT 1, which creates a new NAT session mapping the session tuple (A2:a2, S:s) on Private Network 1 to the session tuple (A1:a1, S:s) on the main Internet. Host B similarly initiates an outgoing session from B:b to S:s, causing NAT 3 to assign "intermediate" source endpoint B3:b3 to this session as it appears on Private Network 2, and in turn causing NAT 1 to assign public source endpoint B1:b1 to this session as it appears on the main Internet. Ford [Page 20] draft-ford-behave-gen-00.txt February 2005 Client hosts A and B now obtain from S each other's public source endpoints as known to S, namely B1:b1 and A1:a1, respectively. Each client then attempts to open a peer-to-peer communication session targetting the other host's public endpoint, as described fully in the companion document [BEH-APP]. To NAT 1, the common NAT, Host A's attempt to open a peer-to-peer connection to B appears as an attempt received from private endpoint A2:a2, and directed to "public" endpoint B1:a1. This "public" endpoint, however, is merely one of the temporary public endpoints that NAT 1 itself previously assigned to represent B's "intermediate" private endpoint B3:b3! 6.3. Implementing Hairpin Translation To handle this communication attempt properly, NAT 1 must set up a "hairpin NAT session", as defined in section 2.4. In this hairpin NAT session, for packets travelling from A to B, the NAT translates A's "intermediate" private source endpoint A2:a2 into A's corresponding public source endpoint A1:a1, and simultaneously translates B's public destination endpoint B1:b1 into B's corresponding "intermediate" private endpoint B3:b3, before forwarding the translated packet on to B3:b3 on its private network. This packet will then traverse NAT 3 and reach Host B with a destination endpoint of B:b and a source endpoint of A1:a1. Conversely, for packets flowing from B to A, the NAT translates B's intermediate private source endpoint B3:b3 into its corresponding public source endpoint B1:b1, and simultaneously translates A's public destination endpoint A1:a1 into A's intermediate private endpoint A2:a2, before forwarding the translated packet on to A2:a2 and eventually to A:a. REQ-6 All NATs MUST support hairpin translation as described above. 6.4. Partial Hairpin Translation NAT implementors may be tempted to implement "partial" hairpin translation, which differs from the hairpin translation described above in that the NAT translates only the destination endpoint and not the source endpoint in hairpinned packets. In a packet travelling from A and B in the above scenario, for example, when the packet arrives at NAT 1 with a source endpoint of A2:a2 and a destination of B1:b1, a NAT implementing only partial hairpin translation would translate the destination endpoint B1:b1 into the corresponding private endpoint B3:b3, while leaving the private source endpoint A2:a2 unchanged. The packet will thus eventually arrive at Host B with a source endpoint of A2:a2 and a destination Ford [Page 21] draft-ford-behave-gen-00.txt February 2005 endpoint of B:b. Such "partial hairpin translation" support is NOT acceptable for a BEHAVE-compliant NAT, because there is no way the NAT can guarantee that the private source andpoint. if left untranslated to the corresponding public endpoint, will still have any useful meaning once the packet arrives at its final destination. In the above example, the private source endpoint A2:a2 is probably within one of the private IP address ranges assigned in RFC 1918 [PRIV-ADDR], and is only known to be meaningful within Private Network 2. If NAT 1 leaves the source A2:a2 unchanged in a packet flowing from A to B, then B will interpret this source address in the domain of Private Network 3, in which the endpoint A2:a2 might refer to a completely different host. The only legitimate source endpoint for A that NAT 1 knows about and is guaranteed to have useful meaning for B is A's public endpoint on the main Internet, namely A1:a1. REQ-7 A NAT MUST translate both the source and destination endpoints of hairpinned packets, not just the destination endpoint. 7. DHCP-Configured NATs Many NATs, particularly consumer-level devices designed to be deployed by nontechnical users, also act as DHCP clients. In its default configuration, a consumer NAT typically obtains its public IP address, default router, and other IP configuration information via DHCP from an ISP or other "upstream" network. On its internal network side, the NAT then automatically sets up its own private "downstream" subnet in one of the private IP address regions assigned to this purpose in RFC 1918 [PRIV-ADDR]. The NAT typically acts as a DHCP server for its private downstream network, managing its pool of private IP addresses automatically and handing them out to the hosts (and perhaps other NATs) on the private network on demand. This auto-configuration of private networks can be problematic, however, if the NAT's upstream network is also in RFC 1918 private address space. In the two-level NAT scenario described in the previous section, for example, NAT 2 and NAT 3 are likely to be consumer-level NATs that obtain their "external" IP addresses on Private Network 2 from NAT 1's DHCP server. Thus, from the viewpoint of NAT 2 or NAT 3, both their "internal" and "external" networks are probably in the private RFC 1918 address regions, and may even use numerically overlapping IP addresses. Since such scenarios are typically unintended and unavoidable consequences of the way NATs are commonly configured and deployed, Ford [Page 22] draft-ford-behave-gen-00.txt February 2005 NAT vendors must carefully design their NATs to ensure that they still function correctly and robustly even in such problematic scenarios. For example, whenever the NAT implementation internally stores any IP addresses that could refer to nodes on either side of the NAT, the implementation must attach Internal or External "tags" to these IP addresses, in order to avoid confusing the possibly- conflicting internal and external IP address spaces. REQ-8 A NAT whose external IP interface can be configured via DHCP MUST operate correctly even if its external interface's IP address and subnet configuration numerically conflicts with the IP address and subnet configuration of the NAT's internal interface(s). The remainder of this section describes several specific behavioral recommendations that can minimize the likelihood of communication failures in situations involving multi-level auto-configured NATs. 7.1. Private Subnet Selection When a NAT acts as both a DHCP client and a DHCP server, one way it can avoid problems due to private IP address conflicts is by supporting multiple RFC 1918 address ranges for its private network. The NAT's DHCP server might for example hand out IP addresses in the 10.0.0.0/24 range to downstream hosts by default as long as its own DHCP-assigned "external" IP address is not in this region, and otherwise hand out addresses in the 172.16.0.0/12 private region. REQ-9 If a NAT in its default configuration obtains its external IP configuration via DHCP, and automatically sets up its internal network in private RFC 1918 address space, then in this default configuration the NAT SHOULD when possible hand out internal IP addresses that do not numerically conflict with the external subnet configuration it received via DHCP, even if the external subnet is also within RFC 1918 address space. Unfortunately, a NAT cannot in practice always assign internal IP addresses that do not conflict with its external IP configuration. The NAT may need to set up the private network and begin handing out private IP addresses to downstream hosts before it has obtained an external IP address on its external interface via DHCP, for example. This situation is common during the initial setup of consumer-level NATs, in which the user must typically log into the NAT from a downstream host in order to configure the NAT's upstream interface. Even after initial configuration, the NAT's external IP address may change, requiring the NAT to reconfigure its DHCP server and break existing leases. (It should be fairly uncommon for an ISP to change from one RFC 1918 address block to a completely different one, Ford [Page 23] draft-ford-behave-gen-00.txt February 2005 however.) Finally, the NAT may no longer be able to assign non- conflicting private IP addresses automatically as soon as the user configures any "fixed" private IP addresses or sets up firewall filtering rules or forwarding paths that refer to specific private hosts by IP address. For these reasons, it is still crucial that NAT designers ensure that their NATs behave predictably and robustly even if the NAT's internal and external IP subnets do numerically conflict. 7.2. The NAT as a Communication Endpoint Most devices that implement network address translation also contain a "host" protocol stack through which other devices on the network can communicate with the NAT device explicitly, for configuration purposes for example. Some NATs are implemented merely as a special feature of a general-purpose host operating system running on an ordinary computer. In this situation, the NAT implementor must ensure that the host protocol stack does not become confused or inoperable if IP address and subnet configurations of the NAT's external and internal interfaces numerically conflict. Suppose for example that a NAT's external and internal interfaces are both configured with numerically overlapping IP subnets in the private 192.168.0.0/16 address range, and there happen to be (different) hosts on both the external and internal networks having IP address 192.168.1.10. Suppose the internal host 192.168.1.10 opens a TCP connection to the NAT's IP address on the internal network (e.g., 192.168.1.1), in order to access the NAT's web-based configuration. If the NAT's configuration interface is designed to be accessible from both the external and internal networks, but the NAT's TCP stack does not properly keep track of which side of the NAT the incoming TCP connection was received on, the NAT's TCP stack might try to resolve the IP address 192.168.1.10 on *both* of its interfaces in the usual way for ordinary hosts with multiple interfaces [ARP]. In this case, the NAT will receive two different ARP replies, one on each of its interfaces, and if it "chooses wrong" it will send the response TCP packets to the external host numbered 192.168.1.10 rather than to the internal host that initiated the connection. There are several ways this problem can be solved in a NAT implementation. Three such possible solutions are described below, but they are not intended to exclude other possible solutions or to dictate particular implementation choices. This document makes no formal requirement on what specific approach is taken; the core requirement is embodied in REQ-8 above, namely that the NAT function correctly even when the internal and external IP configurations conflict. Ford [Page 24] draft-ford-behave-gen-00.txt February 2005 Treat the host protocol stack as a node on the internal network. In this solution, the NAT's host protocol stack is architecturally considered to be a "virtual node" on the NAT's internal network, as illustrated below: NAT Device +--------------------------------------------+ | | | +-----------------+ | | | Host Apps | | | +----------| (HTTP, SNMP) | | | | +-----------------+ | | Config/ | | | Control | | | | +-----------------+ | | | | TCP/UDP Stack | | | | +-----------------+ | | | | | | v | | External | +-------------+ +---------+ | Internal Intf. | | Network | | IP | | Intf. ---------+ <--> | Address | <--> | Routing | <--> +--------- | | Translation | | | | | +-------------+ +---------+ | | | +--------------------------------------------+ In this case, the IP addresses used directly by the device's TCP/UDP protocol stacks and by the host applications running on top of them are private IP addresses on the internal network. If the NAT's IP address on its internal network is 192.168.1.1, for example, then the device's TCP and UDP protocol stacks internally use only this IP address to refer to the "local host", and never directly use the NAT's DHCP-assigned external IP address. Since the NAT device's default "upstream" router is represented by an IP address on the external network, the device's IP routing code must be able to differentiate this external default route from any other internal network routes in the device's IP routing tables. Similarly, the device's DHCP client code, which the NAT uses to obtain its external network interface configuration, cannot be written as an "ordinary host application" operating on the internal network in this case, but must be specially coded to use the external rather than internal interface. If the device provides a DHCP server to pass out IP addresses on its internal network, however, then this DHCP server can be implemented as an "ordinary host application" running in the internal IP address Ford [Page 25] draft-ford-behave-gen-00.txt February 2005 realm. In this design, if the NAT's internal and external IP subnets conflict, the NAT's host applications will not be able to communicate with external network hosts having conflicting private IP addresses. The NAT's host applications, as well as other downstream nodes on the NAT's internal network, will still be able to communicate through the NAT with external hosts that have public (non-RFC 1918) IP addresses, ensuring that the NAT still functions correctly and enables communication to the extent that the network topology permits. Duplicate the NAT's host protocol stacks. In this solution, the NAT device logically has two independent sets of TCP/UDP protocol stacks and host applications, each of which logically operates on only one "side" of the NAT, and thus in only one IP address realm: NAT Device +-------------------------------------------+ | | | +-----------+ +-----------+ | | | External | | Internal | | | | Host Apps |<----------->| Host Apps | | | +-----------+ Control +-----------+ | | | | | | | | | | +---------+ +---------+ | | | TCP/UDP | | TCP/UDP | | | +---------+ +---------+ | | | | | | | | | External | +----+ +-----+ +----+ | Internal Intf. | | | | | | | | Intf. ---------+ <--> | IP | <--> | NAT | <--> | IP | <--> +--------- | | | | | | | | | +----+ +-----+ +----+ | | | +-------------------------------------------+ For example, the NAT's DHCP client might operate as an "external host app" running in the external IP address realm, while its DHCP server acts as an "internal host app" running in the internal address realm. If the device's SNMP- or HTTP-based configuration interfaces are intended to be accessible from either side of the NAT, then the NAT runs two logically separate instances of the appropriate servers, one in each IP address realm. If an external Ford [Page 26] draft-ford-behave-gen-00.txt February 2005 host with IP address 192.168.1.10 attempts to connect to the NAT at the NAT's external IP address, it will be serviced by the NAT's external protocol stack and application servers. Similarly, if an internal host with the same IP address, 192.168.1.10, connects to the NAT at the NAT's internal IP address, its request is serviced by the NAT's internal protocols and servers. This way, NAT device remains accessible by all hosts on both networks with no internal confusion of IP addresses from the two conflicting realms. The advantage of this solution over the previous one is that the NAT's host applications can communicate with endpoints on both the internal and external networks even if the two IP address spaces conflict. The disadvantage is that duplicating the protocol stacks may be inefficient, especially in embedded NAT routers, and it may require significant changes to existing protocol stack implementations. Tag all IP addresses in the NAT's protocols and applications. Finally, the NAT's IP protocol stacks and internal applications might be designed to attach Internal/External "side" tags to all IP addresses they store that could refer to either address realm, effectively keeping the realms logically separate as in the last example without actually duplicating the internal functionality. Such an implementation may require more invasive changes to standard IP protocol stacks and applications, however. 8. Summary of Requirements This section summarizes the requirements specified and discussed at length in the preceding sections. A NAT that supports all of the mandatory requirements of this specification (the "MUST" requirements), is "compliant with this specification." A NAT that supports all of the requirements of this specification including the optional, "RECOMMENDED" requirements, is "fully compliant with all the mandatory and recommended requirements of this specification." REQ-1 A NAT MUST distinguish between packets comprising the logically separate Internal and External packet flows solely using information below the IP layer. REQ-2 A NAT MUST support the TCP protocol, as described in [BEH- TCP], and MUST support the UDP protocol for unicast communication, as described in [BEH-UDP]. A NAT SHOULD also support receiving of UDP multicast packets using the IGMP protocol, and if it does so it MUST behave as described in [BEH-IGMP]. A NAT MAY support other transport protocols as deemed appropriate. Ford [Page 27] draft-ford-behave-gen-00.txt February 2005 REQ-3 A NAT MUST have "Consistent Source Endpoint Translation" behavior. REQ-4 It is RECOMMENDED that a NAT have "Paired Source IP Address Translation" behavior. This requirement is not applicable to NATs that do not support IP address pooling. REQ-5 It is RECOMMENDED that a NAT have "External IP Address Dependent Filtering" behavior. REQ-6 All NATs MUST support hairpin translation as described above. REQ-7 A NAT MUST translate both the source and destination endpoints of hairpinned packets, not just the destination endpoint. REQ-8 A NAT whose external IP interface can be configured via DHCP MUST operate correctly even if its external interface's IP address and subnet configuration numerically conflicts with the IP address and subnet configuration of the NAT's internal interface(s). REQ-9 If a NAT in its default configuration obtains a public IP address via DHCP, and automatically sets up its private network in RFC 1918 address space, then in this default configuration the NAT SHOULD whenever possible hand out private IP addresses that do not numerically overlap with the "public" subnet it received via DHCP, even if this "public" subnet is also within RFC 1918 address space. 9. Security Considerations None yet. Acknowledgments The text of this Internet-Draft is based in part on F. Audet and C. Jennings, draft-ietf-behave-nat-udp-00.txt [BEH-UDP]. Normative References [ARP] David C. Plummer, "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [BEH-APP] B. Ford, P. Srisuresh, and D. Kegel, "Application Design Guidelines for Traversal of Network Address Translators", Internet-Draft (Work In Progress), February 2005. [BEH-IGMP] D. Wing, "IGMP Proxy Behavior", Internet-Draft (Work In Ford [Page 28] draft-ford-behave-gen-00.txt February 2005 Progress), October 2004. [BEH-STATE] P. Srisuresh, B. Ford, and D. Kegel, "State of Peer-to-Peer (P2P) communication across Network Address Translators (NATs)", Internet-Draft (Work In Progress), December 2004. [BEH-TCP] S. Sivakumar, K. Biswas, and B. Ford, "NAT Behavioral Requirements for TCP", Internet-Draft (Work In Progress), January 2005. [BEH-TOP] B. Ford and P. Srisuresh, "Topological Complications from Network Address Translation (NAT-TOP)", Internet-Draft (Work In Progress), February 2005. [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", Internet-Draft (Work In Progress), January 2005. [H.323] "Packet-based Multimedia Communications Systems", ITU-T Recommendation H.323, July 2003. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [NAT-MIB] R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, February 2005. [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. Ford [Page 29] draft-ford-behave-gen-00.txt February 2005 [PRIV-ADDR] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001. [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema, "Traversal Using Relay NAT (TURN)", Internet-Draft (Work In Progress), March 2003. [UNSAF] L. Daigle and IAB, "IAB Considerations for UNilateral Self- Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. http://www.upnp.org/standardizeddcps/igd.asp Author's Address Bryan Ford Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 U.S.A. Phone: (617) 253-5261 E-mail: baford@mit.edu Web: http://www.brynosaurus.com/ Pyda Srisuresh Caymas Systems, Inc. 1179-A North McDowell Blvd. Petaluma, CA 94954 U.S.A. Phone: (707)283-5063 Ford [Page 30] draft-ford-behave-gen-00.txt February 2005 E-mail: srisuresh@yahoo.com Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Ford [Page 31]