One document matched: draft-ford-behave-gen-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 04:12:28 |