Internet Draft B. Ford
Document: draft-ford-behave-gen-01.txt M.I.T.
Expires: November 8, 2005 P. Srisuresh
Caymas Systems
S. Sivakumar
Cisco Systems
May 2005
Operating 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 the operating principles of Network Address
Translator (NAT) devices and the behavioral properties required to
Ford, Srisuresh & Sivakumar [Page 1]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
make NAT more predictable and compatible with diverse application
protocols. First, this document presents an architectural model for
NAT devices and defines important terms used in conjunction with
NAT operation. The architectural model sets the stage for a set of
concrete recommendations for NAT implementers. 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 & Scope .........................................
2. Operating principles and terminology .........................
2.1. Address/Port Maps .......................................
2.2. Address/Port Bindings ...................................
2.3. NAT Session .............................................
2.4. Cone/Symmetric NAT behaviors ............................
2.4.1. Symmetric NAT .........................................
2.4.2. Port Restricted Cone NAT ..............................
2.4.3. Address Restricted Cone NAT ...........................
2.4.4. Full Cone NAT .........................................
2.5. Multi Level NAT topology ................................
2.6. Hairpin NAT Session & Hairpin NAT translation ...........
3. General Behavioral Requirements for NATs .....................
3.1. Transport Protocol support ..............................
3.2. Address Binding and/or Port Binding support .............
3.3. Fragment support for inbound IP packets .................
3.4. Fragment processing on the outbound .....................
3.5. Hairpin NAT translation .................................
3.6. DHCP-Configured NATs ....................................
3.7. Honor the DF bit in IP header ...........................
3.8. ICMP Error packet handling ..............................
3.9. Rejection of IP packets not permitted by NAT ............
3.10. ALG support ............................................
3.11 Denial-of-Service Protection ............................
4. Hints to implementers .........................................
4.1. Inbound fragmented packet processing ....................
4.2. Port reservation ........................................
4.3. DHCP Configured NATs ....................................
5. Summary of Requirements ......................................
6. Security Considerations ......................................
1. Introduction & Scope
Due to various technical and market pressures, Network Address
Translators (NATs) have become a ubiquitous part of today's
Ford, Srisuresh & Sivakumar [Page 2]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
Internet. NATs cause well-known problems for applications,
especially those that carry IP addresses in their message payloads
[NAT-PROT]. RFC 3235 [NAT-APPL] provides some recommendations for
making application protocols compatible with NAT. But, these
recommendations do not adequately address applications with
"peer-to-peer" (P2P) communication patterns, which by their nature
carry IP addresses in message payloads. Peer-to-peer 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 adapted by peer-to-peer applications.
As stated in RFC 3424 [UNSAF], there is wide degree of variability in
how NAT devices behave. This document defines a set of requirements
for NAT behavior that will reduce the unpredictability and
brittleness of the NAT devices and enable applications to traverse
them reliably. The requirements specified here apply generally to all
NAT variations described in RFC 2663 [NAT-TERM], including
Traditional NAT (i.e., Basic NAT and NAPT), Bi-directional NAT, and
Twice NAT. However, the primary focus of this document is NAPT, a
variant of Traditional NAT that is most widely deployed today.
Traditional NAT inherently mandates a certain level of firewall-like
functionality. However, firewall functionality in general is out of
the scope of this specification.
NAT traversal strategies that involve explicit signaling between the
application and the NAT [SOCKS, RSIP, MIDCOM, UPNP] are out of the
scope of this document.
This document focuses strictly on the behavior of the NAT itself,
and not on the behavior of applications that 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 and the
companion Behave documents.
The following section is devoted to describing the principles of
NAT operation and the various terms used throughout the behave
working group documents. This section serves to provide a technical
perspective behind the recommendations made in the next section.
Section 3 lists the general recommendations to NAT vendors,
independent of the transport protocol specific recommendations.
Section 4 provides some hints on how to implement some of the
requirements listed in section 3. Lastly, section 5 summarizes
all the requirements in one place.
Ford, Srisuresh & Sivakumar [Page 3]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
2. Operating principles and 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].
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 a detailed description on
traditional NAT.
This section uses the combination of RFC 2663 [NAT-TERM] and RFC 4008
[NAT-MIB] to outline the basic principles of NAT operation, and
defining technical terms used throughout. Newer terms not found in
either of the documents may also be found defined in this section.
The following diagram presents a general architectural model
describing NAT operation. The model does not provide a method of
implementing NAT, but serves as a framework for understanding the
rationale behind behavioral requirements described later in the
document.
Ford, Srisuresh & Sivakumar [Page 4]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
NAT Device
+------------------------------------------------+
| |
| +------------+ +----------+ +----------+ |
| | Address/ | | Address/ | | | |
| | Port |==>| Port |==>| NAT | |
| | Maps | | Bindings | | Sessions | |
| | (Admin | | (Static &| | (Dynamic)| |
| | Configured)| | Dynamic) | | | |
| +------------+ +----------+ +----------+ |
| ^ |
| | |
| +----------------------+ |
| | |
Incoming | +-------+------+ +-------------+ |Outgoing
Packets | | NAT Packet | | IP routing/ | |Packets
-------->+ ---->| Translation |---->| Forwarding |----> |------->
| | | | | |
| +--------------+ +-------------+ |
| |
+------------------------------------------------+
Figure 1: Architectural model describing NAT operation
Figure-1 above is a pictorial overview of how a NAT operates and
encompasses the building blocks of a NAT device. Central to the
NAT operation is three tables comprised of "Address/Port Maps",
"Address/Port Bindings", and "NAT Sessions". The tables are
described in detail in the following subsections. Implementation
of these tables vary across different vendors. All vendors
implement Address/port maps and NAT Sessions in some form.
Vendors supporting Symmetric NAT behavior do not
implement Address/Port Bindings, but derive the NAT Sessions
directly from the address/port maps.
Packet processing within a NAT device works roughly as follows.
The NAT device first looks up the incoming packet against the
known set of NAT Sessions. If a match is not found and this is
likely the first packet of a new session, a new NAT session may
be created based on either the existing bindings or the address
maps. NAT translates the packet as specified by the matching NAT
Session. The translated packet is looked up in the routing
table for forwarding to the next hop.
2.1. Address/Port Maps
This document used the term Address Map as defined in RFC 4008
Ford, Srisuresh & Sivakumar [Page 5]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
[NAT-MIB]. The Address/Port Map table represents the
configuration database set up by the NAT administrator. The
entries of the table determine the type of NAT the device
implements. For example, Basic NAT, NAPT, Bidirectional NAT,
Twice-NAT, or a combination thereof. The Address Map table may
also contain static (i.e., permanent) mappings between IP
addresses and/or port endpoints. Say, a mapping between port
80 on the NAT's public IP address and a particular Web server
located on the internal network.
2.2. Address/Port Bindings
This document uses the term "Address Binding" as defined in RFC 3022
and "port binding" as defined in RFC 4008. A NAT device may
implement both Address and Port Bindings.
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
"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 targeted 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 setup NAT Sessions directly from the Address/Port maps without
creating any Bindings. The notion of address/port binding is crucial
to making NATs behave in a predictable fashion for a number of
application communication patterns.
A Binding represents the association between internal and external
entities (addresses or endpoints) the NAT has set up. The NAT can
create Bindings in the Binding table either statically, to reflect
the static one-to-one configuration entries in the NAT Address Map
table, or dynamically prior to setting up NAT session flows across
the NAT. A Binding can be between a pair of IP addresses or a pair
of end points representing the same entity across two realms.
Binding between a pair of addresses is called Address Binding.
Binding between a pair of TCP/UDP endpoints is called TCP/UDP Port
Binding, or simply, Port Binding, for short. Bindings are
Ford, Srisuresh & Sivakumar [Page 6]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
directional.
2.3. NAT Session
The term "NAT Session" was first defined in RFC 4008[NAT-MIB]
to represent the dynamic state the NAT uses to translate the
individual packets comprising a particular communication session
flowing across the NAT.
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
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 targeted 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 targeted.
2.4. Cone/Symmetric NAT behaviors
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.
Unfortunately, besides being historically attached to the UDP
transport protocol, these categories have proven insufficient to
Ford, Srisuresh & Sivakumar [Page 7]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
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 may be defined as below.
2.4.1. Symmetric NAT
Symmetric NAT behavior is one exhibited by a NAT device that does NOT
use Address Binding or Port Binding for TCP/UDP based NAT sessions.
If a TCP/UDP endpoint on a private host, denoted by the tuple of
(IP address, port no), originated multiple sessions, a new public
TCP/UDP port is assigned to translate the private endpoint in each
new session.
2.4.2. Port Restricted Cone NAT
Port Restricted Cone NAT behavior is one exhibited by a NAT device
that uses Address/Port Binding and behaves as follows. If the TCP/UDP
endpoint on a private host, denoted by the tuple of (IP address,
port no), originated multiple sessions, the same public TCP/UDP port
is assigned to translate the private endpoint in each new session.
Further, only the packets that belong to the sessions initiated by
the private host are permitted on the inbound.
2.4.3. Address Restricted Cone NAT
Address Restricted Cone NAT behavior is one exhibited by a NAT
device that uses Address/Port Binding and behaves as follows. Once
a UDP endpoint on a private host, denoted by the tuple of
(IP address, port no), originated a UDP session, Address-restricted
Cone NAT will accept incoming UDP packets to the corresponding
public port from only those external endpoints whose IP address
match the address of external endpoint to which the private endpoint
had initiated outgoing sessions.
2.4.4. Full Cone NAT
Full Cone NAT behavior is one exhibited by a NAT device
that uses Address/Port Binding and behaves as follows. Once a UDP
endpoint on a private host, denoted by the tuple of (IP address,
port no), originated a UDP session, Full Cone NAT will accept
incoming UDP packets to the corresponding public port from any
external endpoint.
2.5. Multi Level NAT topology
The term "Multi Level NAT" is not defined in any earlier documents.
Ford, Srisuresh & Sivakumar [Page 8]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
The term is being defined for the first time in this document.
Multi Level NAT topology is a network topology in which NAT devices
can be found at two or more levels between communicating endpoints.
NATs are increasingly, and often unintentionally, used to create
hierarchically interconnected clusters of private networks in which
some hosts are separated from the Internet by more than one level of
Traditional NAT. The following diagram illustrates this situation.
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
Figure 2. Multi Level NAT topology
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
customers, an increasingly common situation especially in developing
countries. NAT-2 and NAT-3 are 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.
Ford, Srisuresh & Sivakumar [Page 9]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
Neither the ISP nor the customers necessarily intend to create this
hierarchical Multi Level NAT topology. Multi Level NAT topologies
arise merely as a consequence of the same technical and economic
factors that drove the wide deployment of NATs in the first place.
2.6. Hairpin NAT Session & Hairpin NAT translation
The terms "Hairpin NAT Session" and "Hairpin NAT translation" are
not defined in any earlier documents. The terms are being defined
for the first time in this document.
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. The translation of packets subject to a Hairpin
NAT Session is called Hairpin NAT translation, or simply Hairpin NAT.
Packets subject to Hairpin NAT translation would undergo translation
for both source and destination endpoints within the same NAT device.
The need for Hairpin NAT arises out of the necessity to support
application traversal through Multi Level NATs. Hairpin NAT
translation refers to the ability of a NAT device to allow multiple
private endpoints behind the NAT to communicate with each other
using each other's *public* (translated) endpoints.
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, Srisuresh & Sivakumar [Page 10]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
Server S
(S:s)
|
^ Session A-S ^ | ^ Session B-S ^
| (A1:a1,S:s) | | | (B1:b1,S:s) |
|
+-------------+
| NAT-1 |
+-------------+
|
| Private Network 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 |
+-------------+ +-------------+
| |
| Private Network 2 Private Network 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)
Figure 3. Hairpin NAT translation in a Multi Level NAT scenario
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 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 traverses through NAT-1, which creates a new
NAT session mapping the session tuple (A2:a2, S:s) on Private
Ford, Srisuresh & Sivakumar [Page 11]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
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 Internet.
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
targeting 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!
In order to handle this communication attempt properly, NAT-1 needs
to set up a Hairpin NAT session for packets traveling from A to B.
Subsequent to that, NAT-1 would translate 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, NAT-1 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.
3. General Behavioral Requirements for NATs
This section lists the general behavioral requirements for a NAT
device when processing IP packets. Even though ICMP is a transport
protocol on top of IP, ICMP packet processing is considered an
integral of IP processing itself. With the exception of ICMP,
the behavioral requirements laid out below are independent of the
transport protocol. Associated with each requirement, the
rationale behind the requirement is discussed in detail.
Ford, Srisuresh & Sivakumar [Page 12]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
3.1. Transport Protocol support
TCP and UDP are by far the most common and widely deployed IP
transport protocols, although other transports exist as well.
Of the various NAT types, NAPT is the most restrictive in terms of
the transport protocol support. For widespread application
compatibility, therefore, it is crucial that any NAT support at least
the TCP and UDP transports, and NATs are encouraged to support other
transport protocols as well as they become standardized and deployed.
REQ-1: A NAT MUST support the traversal of TCP based applications
and unicast UDP based applications.
3.2. Address Binding and/or Port Binding support
Several applications use the same endpoint within a realm to
establish multiple simultaneous sessions. Many peer-to-peer
applications use the public endpoint registration of peering hosts
to initiate sessions into.
In order to support peer-to-peer applications and applications
that entertain multiple simultaneous session using the same TCP/UDP
endpoint, NAT MUST retain the association it assigned to an endpoint
between realms and reuse the same endpoint association when
multiple sessions using the same endpoint are routed through the
NAT device. This issue is of general relevance for any transport
protocol that use port numbers to represent communication endpoints,
including TCP and UDP. Such a binding between endpoints can
occur when a NAT device maintains Address Bindings or Port
Bindings.
REQ-2: A NAT device MUST support Address and/or Port Bindings.
Specifically, Symmetric NAT type behavior MUST be deprecated.
3.3. Fragment support for inbound IP packets
Routers in the network are able to forward fragmented IP packets
just as they do any other non-fragmented IP packets because packet
forwarding is based solely on looking up the destination IP
address in the routing table and finding the largest prefix match
to identify the next-hop to forward to. Routers do not need to
retain any state pertaining to fragmented packets traversing them.
A NAT device operates differently from a router in that the NAT
device must find the matching NAT Session for an IP packet and
perform NAT translation on the packet, prior to forwarding. NAT
Session lookup requires the full 5-tuple of the IP datagram. Only
Ford, Srisuresh & Sivakumar [Page 13]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
the first fragment of the IP datagram contains the full-tuple.
Subsequent fragmented packets contain the fragment Id, but do not
contain transport protocol specific details such as source and
destination port numbers. The NAT device must be able to associate
the same session tuple for all fragments by virtue of the fragment
ID and use that information to locate the NAT Session the packets
belong to. Note however, the IP fragments cannot be assumed to
arrive in order. Some operating systems transmit the fragments of
an IP datagram out of their logical order as a matter of course.
In addition, network conditions can also cause dynamic packet
reordering in transit.
A NAT device MUST be capable of processing all fragments of an
IP datagram inbound to the NAT device. The NAT device MUST retain
the assembly state pertaining to a fragmentation ID until all
fragments of the IP datagram are processed. By doing this, NAT is
able to process all fragments pertaining to an IP datagram using
the same NAT Session the IP datagram belongs to.
Applications such as NFSv2 over UDP assume a default read/write
buffer size of 8192 bytes and rely on IP fragmentation support
in the network. A fully assembled IP datagram will be about
8300 bytes long. NAT devices MUST support the traversal of
common applications such as this.
REQ-3: A NAT device MUST be able to process (i.e., receive,
translate, and forward) all fragments of an IP datagram, whether
they arrive in order or out of order. A NAT device MUST process
IP fragments that assemble to a maximum of 8300 byte IP
datagrams.
3.4. Fragment processing on the outbound
Say, two private hosts originated TCP/UDP packets (fragmented
or not) to the same destination host and both packets transit
the same NAPT device and use the same fragmentation identifier.
Say, the NAPT device assembled the IP packets (in the case they
were fragmented) and translated the same using the appropriate
NAT Sessions. When NAPT translates IP datagrams, it would assign
all outbound IP datagrams the same Public IP, but different
TCP/UDP numbers. While forwarding, an IP datagram may be
fragmented on the way out. Only the first fragment contains the
TCP/UDP header that would be necessary to associate the packet to
a specific session. Subsequent fragments do not contain TCP/UDP
port information, but simply carry the same fragmentation
identifier specified in the first fragment.
When the target host receives the two unrelated datagrams, carrying
Ford, Srisuresh & Sivakumar [Page 14]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
same fragmentation id, and from the same assigned host address, the
target host is unable to determine which of the two sessions the
datagrams belong to and might corrupt both sessions.
In order to avoid problems of this kind, the NAPT device SHOULD
further translate fragment ID in the outgoing packets such
that the tuples of (SrcIP, DestIP, fragment Id, Protocol) are
unique and distinguishable across all outgoing packets from the
NAT device.
REQ-4: When fragmenting packets on the outbound, a NAT device SHOULD
ensure that the tuples of (SrcIP, DestIP, fragment Id, Protocol)
are unique across all outgoing packets. This requirement pertains
specifically to NAPT devices.
3.5. Hairpin NAT translation
Multi Level NATs are commonly deployed. Private hosts behind the
Multi Level NATs use their public endpoint identity to communicate
with each other. Hairpin NAT translation MUST be supported in the
NAT devices to allow applications on the private hosts to
communicate with each other.
REQ-5: All NATs MUST support hairpin NAT translation.
3.6. 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 Multi Level NAT scenario described in section
2.5, 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
Ford, Srisuresh & Sivakumar [Page 15]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
RFC 1918 address regions, and may even use numerically overlapping
IP addresses.
DHCP configured NAT vendors must carefully design their NATs to
ensure that they function correctly and robustly even in such
problematic scenarios.
REQ-6: A NAT device 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).
3.7. Honor the DF bit in IP header
A NAT device MUST honor the DF (Don't Fragment) bit in the IP header
of the packets that transit the NAT device. Majority of the TCP
sessions have the DF bit set and will expect the devices enroute to
not fragment the TCP segments. If the MTU on the forwarding interface
of the NAT device is such that the IP datagram cannot be forwarded
without fragmentation, NAT MUST send a destination unreachable ICMP
message (ICMP type 3, Code 4) with a suggested MTU back to the sender
and drop the IP packet. The sender will resend after taking an
appropriate corrective action.
REQ-7: If DF bit is set on an inbound IP packet and the NAT device
cannot forward the packet without fragmentation, the NAT device
MUST send a destination unreachable ICMP message (ICMP
type 3, Code 4) with a suggested MTU back to the sender prior to
dropping the IP packet.
3.8. ICMP Error packet handling
A NAT device MUST transparently forward ICMP error messages ([ICMP])
it receives from intermediate or end nodes in either realm to the
intended endnode. Unlike other IP packets, the basis for translation
of an ICMP error packet is the NAT Session to which the packet
embedded within the ICMP error message payload belongs to, not the IP
and ICMP headers in the outer layer.
Consider the following scenario in figure 4. Say, NAT-xy is a
traditional NAT device connecting hosts in private and external
networks. Router-x and Host-x are in the external network. Router-y
and Host-y are in the private network. The subnets in the external
network are routable from the private as well as the external
domains. Whereas, the subnets in the private network are only
routable within the private domain. When Host-y initiated a session
to Host-x, let us say that the NAT device assigned an IP address of
Ford, Srisuresh & Sivakumar [Page 16]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
Host-y' to associate with Host-y in the external network.
Host-x
|
|
---------------+-------------------
|
|
+-------------+
| Router-x |
+-------------+
|
External Network |
--------------------+--------+-------------------
|
| ^ |
| | (Host-y', Host-x) |
| | v
|
+-------------+
| NAT-xy |
+-------------+
|
| Private Network
----------------+------------+----------------
|
|
|
+-------------+
| Router-y |
+-------------+
|
|
----------------+-------+--------
|
| ^ |
| | (Host-y, Host-x) |
| | v
|
Host-y
Figure 4. NAT topology with intermediate routers in both realms
Say, a packet from Host-y to Host-x triggered an ICMP error message
from one of Router-x or Host-x (both of which are in the external
Ford, Srisuresh & Sivakumar [Page 17]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
domain). Such an ICMP error packet will have one of Router-x or
Host-x as the source IP address and Host-y' as the destination IP
address. When the NAT device receives the ICMP error packet, the
NAT device must use the packet embedded within the ICMP error
message (i.e., the IP packet from Host-y to Host-x) to look up the
NAT Session the embedded packet belongs to and use the NAT Session
to translate the embedded payload. The NAT device must also use the
NAT Session to translate the outer IP header. In the outer header,
the source IP address will remain unchanged because the originator
of the ICMP error message (Host-x or Router-x) is in external
domain and routable from the private domain. The destination IP
address Host-y' must however be translated to Host-y using the NAT
Session parameters.
Now, say, a packet from Host-x to Host-y triggered an ICMP error
message from one of Router-y or Host-y (both of which are in the
private domain). Such an ICMP error packet will have one of
Router-y or Host-y as the source IP address and Host-x as the
destination IP address. When the NAT device receives the ICMP error
packet, the NAT device must use the packet embedded within the ICMP
error message (i.e., the IP packet from Host-x to Host-y) to look up
the NAT Session the embedded packet belongs to and use the NAT
Session to translate the embedded payload. The NAT device must also
use the NAT Session to translate the outer IP header. In the outer
header, the destination IP address will remain unchanged, as the IP
addresses for Host-x is already in the external domain. If the ICMP
error message is generated by Host-y, the NAT device must simply
use the NAT Session to translate the source IP address Host-y to
Host-y'. However, if the ICMP error message is generated by the
intermediate node Router-y, the NAT device will not have had a
translation entry for Router-y within the NAT Session. The NAT may
also not have an Address Binding in place for Router-y. In such a
case, the NAT device must simply use its own IP address in the
external domain to translate the source IP address.
Changes to ICMP error message ([ICMP]) MUST include changes to IP and
ICMP headers on the outer layer as well as changes to the relevant
IP and transport headers of the packet embedded within the ICMP-error
message payload. Section 4.3 of the RFC 3022 describes the various
items within the ICMP error message that MUST be translated by the
NAT device.
REQ-8: A NAT device MUST transparently forward the ICMP error
messages it receives from the intermediate or end nodes in either
realm to the intended endnode. The NAT device MUST use the packet
embedded within the ICMP error message payload as the basis to
translate not only the embedded payload, but also the IP and ICMP
headers in the outer layer. In the case the ICMP error packet is
Ford, Srisuresh & Sivakumar [Page 18]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
generated by an intermediate node for which the NAT has no Binding
translation, the NAT device MUST use its own IP address in the realm
of the recipient node to translate the intermediate node IP address.
3.9 Rejection of IP packets not permitted by NAT
Unlike a router, a NAT device is session oriented and permits
sessions from/to specific endpoints in either the external or
internal realm based on how the NAT device is configured with
Address/Port Maps. For example, a TCP packet is not permitted across
a NAT device unless the specific TCP session is already in progress
and known to the NAT device. Further, inbound sessions are not
permitted into a traditional NAT device by default. In addition, a
new session may not be able to transit a NAT device due to the
NAT device running of addresses in the address pool or ports in the
TCP/UDP port pool or because of an administrative policy.
In each of these scenarios, where an inbound packet is prohibited by
a NAT device to traverse through it for resource/authorization
considerations, the NAT device SHOULD not simply drop the packet
silently. Instead, the NAT device SHOULD send ICMP destination
unreachable message, with a code of 10 (Communication with
destination host administratively prohibited) to the sender prior to
dropping the packet. Unfortunately, there is not another ICMP code
currently defined to indicate "Communication with destination host
port administratively prohibited". So, the same code should be used
for host as well as port filtering. Lastly, it is also advisable for
the NAT device to log the error or record the event in a statistic
counter.
REQ-9: When an inbound packet is prohibited by a NAT device due to
resource/authorization considerations, the NAT device SHOULD send
ICMP destination unreachable message, with a code of 10
(Communication with destination host administratively prohibited)
to the sender prior to dropping the packet.
3.10. ALG support
Strictly speaking, NAT devices are not required to include ALGs.
However, vast majority of the NAT devices in deployment do support
Application Level Gateways (ALGs) for FTP and DNS applications.
The ALG for FTP is discussed briefly in RFC 3022 and RFC 2766. The
ALG for DNS is described in detail in [DNS-ALG]. Given that majority
of the applications assume this to be part of NAT devices, and
majority of the NAT devices support these ALGs anyway as an integral
part, we recommend the NAT devices to support the ALGs for these two
applications by default.
Ford, Srisuresh & Sivakumar [Page 19]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
REQ-10: A NAT device SHOULD support ALGs for FTP and DNS, so as to
enable traversal of these applications across NAT. In addition, NAT
devices SHOULD explicitly identify the ALGs supported, and make ALG
support configurable (enable/disable).
3.11 Denial-of-Service Protection
Since NAT devices are Internet hosts they can be the target of a
number of different attacks. NAT devices should employ the same sort
of protection techniques as Internet-based servers do.
For example, storing incomplete IP packet fragments unfortunately
creates a well-known vulnerability to denial-of-service attacks,
against which NATs should protect themselves. NATs typically do so
by limiting the length of time they retain an incomplete IP packet
before discarding it, or alternatively by limiting the amount of
internal buffer space such incomplete IP packets may consume before
the oldest fragments are discarded. The appropriate values of these
limits vary depending on the size and purpose of the NAT, however,
and therefore are left to be determined by the NAT designer or
network administrator.
Further, the NAT device should impose a rate limit on the ICMP
error messages it generates for whatever reason.
REQ-11: A NAT device SHOULD protect itself against Denial of Service
attacks arising out of fragment processing and generating ICMP error
responses to unauthorized packets.
4. Hints to implementers
The following subsections provides hints to implementers on how to go
about the requirements outlined in the previous section. Note, these
are merely hints, not requirements. Implementers may choose to ignore
the hints.
4.1. Inbound fragmented packet processing
Large IP datagrams (sometimes, even the small IP datagrams) may
arrive as fragmented IP packets into a NAT device. The tuples of
(SrcIP, DestIP, Fragment Id, Protocol) will be unique for these
packets. However, the fragments pertaining to any of the tuples
may not arrive in order (i.e., first fragment, followed
by subsequent fragments in the increasing offset). Further, due
to a problem in some host Operating System IP stacks, the
fragments originating from the host may have overlapping payload
segments. In order to meet Req-4 in all of these scenarios, NAT
Ford, Srisuresh & Sivakumar [Page 20]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
devices often fully re-assemble the incoming fragments into a
complete IP datagram first and use the assembled datagram to look
up the NAT Session table.
However, there often are limitations on how long a state can be
retained, the size of the largest assembled IP datagram it can
support and how many simultaneous states a NAT device can retain
at once. Implementers adapting the fragment reassembly approach
should refer Section 3.3.2 of RFC 1122 for the various design
options they might need to consider.
4.2. Port reservation
A NAPT device often shares the source ports for its public IP
address with nodes in the private realm. In order for the NAT
device to do any of its own TCP/UDP session initiations, it MUST
ensure that the ports it uses for itself are not shared with
private nodes. This may be accomplished either through explicit
address/port mapping for NAT use during config time (or) reserve
a block of ports explicitly within the device for local use vs.
NAT use.
Reserving port blocks explicitly for local use vs. NAT use is
valuable for several reasons. Consider the following scenario.
Say, an application on the NAPT runs on port 5060 (SIP Server), but
not enabled. A host in the private domain uses 5060 at this time and
say, gets the port 5060 from the NAT device. While this Port Binding
is active, say, the application running on NAT is activated. Several
things can go wrong now depending on the implementation.
1. The application is totally unaware of NAT's existence, (maybe
because NAT never does a bind on the ports it is using). So it starts
using 5060 and the subsequent packets directed to this server could
end up in the end host within the private domain or the packets meant
for the application on the end host could end up in the NAT box's
TCP/UDP stack. Both are bad and can cause unpredictable behavior.
2. The application on the NAT box is aware that someone is using 5060
so the Bind fails and the app fails to come up. The administrator
would have to clear the NAT session and restart the application.
3. The application on the NAT box is intelligent enough to tell NAT
to clean up any sessions that it plans to use and NAT cleans up its
session(s). The application on the end host is effected as a result.
Clearly, there can be unpredictable behavior when ports are not
reserved explicitly for local use vs NAT use.
Ford, Srisuresh & Sivakumar [Page 21]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
4.3. DHCP Configured NATs
Many of the residential NAT devices acts as a DHCP client on the
external interface and as DHCP server on the internal interface. When
doing so, there is a possibility that the IP subnet on the external
and internal interfaces could overlap, especially in the case of a
Multi-level NAT setup.
One way to 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.
5. 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 support the traversal of TCP based applications
and unicast UDP based applications.
REQ-2 A NAT device MUST support Address and/or Port Bindings.
Specifically, Symmetric NAT type behavior MUST be deprecated.
REQ-3: A NAT device MUST be able to process (i.e., receive,
translate, and forward) all fragments of an IP datagram,
whether they arrive in order or out of order. A NAT device
MUST process IP fragments that assemble to a maximum of 8300
byte IP datagrams.
REQ-4 When fragmenting packets on the outbound, a NAT device SHOULD
ensure that the tuples of (SrcIP, DestIP, fragment Id,
Protocol) are unique across all outgoing packets. This
requirement pertains specifically to NAPT devices.
REQ-5 All NATs MUST support hairpin NAT translation.
REQ-6 A NAT device whose external IP interface can be configured
Ford, Srisuresh & Sivakumar [Page 22]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
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-7: If DF bit is set on an inbound IP packet and the NAT device
cannot forward the packet without fragmentation, the NAT
device MUST send a destination unreachable ICMP message
(ICMP type 3, Code 4) with a suggested MTU back to the
sender prior to dropping the IP packet.
REQ-8: A NAT device MUST transparently forward the ICMP error
messages it receives from the intermediate or end nodes in
either realm to the intended endnode. The NAT device MUST
use the packet embedded within the ICMP error message payload
as the basis to translate not only the embedded payload, but
also the IP and ICMP headers in the outer layer. In the case
the ICMP error packet is generated by an intermediate node for
which the NAT has no Binding translation, the NAT device MUST
use its own IP address in the realm of the recipient node to
translate the intermediate node IP address.
REQ-9 When an inbound packet is prohibited by a NAT device due to
resource/authorization considerations, the NAT device SHOULD
send ICMP destination unreachable message, with a code of 10
(Communication with destination host administratively
prohibited) to the sender prior to dropping the packet.
REQ-10 A NAT device SHOULD support ALGs for FTP and DNS, so as to
enable traversal of these applications across NAT. In
addition, NAT devices SHOULD explicitly identify the ALGs
supported, and make ALG support configurable (enable/disable).
REQ-11 A NAT device SHOULD protect itself against Denial of Service
attacks arising out of fragment processing and generating ICMP
error responses to unauthorized packets.
6. Security Considerations
None yet.
Normative References
[ARP] David C. Plummer, "An Ethernet Address Resolution Protocol",
RFC 826, November 1982.
Ford, Srisuresh & Sivakumar [Page 23]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[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.
[PRIV-ADDR] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and
E. Lear, "Address Allocation for Private Internets", RFC
1918, February 1996.
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, October 1989.
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)",
STD 9, RFC 959, October 1985.
[ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP)
SPECIFICATION", STD 5, RFC 792, September 1981.
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan,
"DNS extensions to Network Address Translators (DNS_ALG)",
RFC 2694, September 1999.
[FTP-EXT] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for
IPv6 and NATs", RFC 2428, September 1998.
Ford, Srisuresh & Sivakumar [Page 24]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
Informative References
[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
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] P. Srisuresh, 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.
[MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A.
Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[H.323] "Packet-based Multimedia Communications Systems", ITU-T
Recommendation H.323, July 2003.
[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.
Ford, Srisuresh & Sivakumar [Page 25]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
[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
Authors' Addresses:
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
E-mail: srisuresh@yahoo.com
Senthil Sivakumar
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
U.S.A.
Phone:
Email: ssenthil@cisco.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.
Ford, Srisuresh & Sivakumar [Page 26]
Internet-Draft NAT Behavioral requirements for IP & ICMP May 2005
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, Srisuresh & Sivakumar [Page 27]