draft-ietf-behave-nat-udp-02.txt   draft-ietf-behave-nat-udp-03.txt 
BEHAVE F. Audet, Ed. BEHAVE F. Audet, Ed.
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: December 29, 2005 C. Jennings Expires: January 16, 2006 C. Jennings
Cisco Systems Cisco Systems
June 27, 2005 July 15, 2005
NAT Behavioral Requirements for Unicast UDP NAT Behavioral Requirements for Unicast UDP
draft-ietf-behave-nat-udp-02 draft-ietf-behave-nat-udp-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2005. This Internet-Draft will expire on January 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines basic terminology for describing different This document defines basic terminology for describing different
types of NAT behavior when handling Unicast UDP, and defines a set of types of NAT behavior when handling Unicast UDP and also defines a
requirements that would allow many applications, such as multimedia set of requirements that would allow many applications, such as
communications or on-line gaming, to work consistently. Developing multimedia communications or on-line gaming, to work consistently.
NATs that meet this set of requirements will greatly increase the Developing NATs that meet this set of requirements will greatly
likelihood that these applications will function properly. increase the likelihood that these applications will function
properly.
Table of Contents Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Address and Port Translation Behavior . . . . . . . . 5 4. Network Address and Port Translation Behavior . . . . . . . . 5
4.1 Address and Port Mapping . . . . . . . . . . . . . . . . . 5 4.1 Address and Port Mapping . . . . . . . . . . . . . . . . . 5
4.2 Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 4.2 Port Assignment . . . . . . . . . . . . . . . . . . . . . 8
4.2.1 Port Assignment Behavior . . . . . . . . . . . . . . . 8 4.2.1 Port Assignment Behavior . . . . . . . . . . . . . . . 8
4.2.2 Port Parity . . . . . . . . . . . . . . . . . . . . . 10 4.2.2 Port Parity . . . . . . . . . . . . . . . . . . . . . 10
4.2.3 Port Contiguity . . . . . . . . . . . . . . . . . . . 10 4.2.3 Port Contiguity . . . . . . . . . . . . . . . . . . . 10
4.3 Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 4.3 Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11
5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 12 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Filtering of Unsolicited Packets . . . . . . . . . . . . . 12 5.1 Filtering of Unsolicited Packets . . . . . . . . . . . . . 12
5.2 NAT Filter Refresh . . . . . . . . . . . . . . . . . . . . 13 5.2 NAT Filter Refresh . . . . . . . . . . . . . . . . . . . . 14
6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 14 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 14
7. Application Level Gateways . . . . . . . . . . . . . . . . . . 15 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 15
8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 15 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 15
9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 16 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 16
10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . 17 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . 17
10.1 Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 17 10.1 Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 17
10.2 Smaller Network MTU . . . . . . . . . . . . . . . . . . . 18 10.2 Smaller Network MTU . . . . . . . . . . . . . . . . . . . 18
11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . 18 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . 18
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . 20 13. Security Considerations . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 13 skipping to change at page 3, line 13
Intellectual Property and Copyright Statements . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 25
1. Applicability Statement 1. Applicability Statement
The purpose of this specification is to define a set of requirements The purpose of this specification is to define a set of requirements
for NATs that would allow many applications, such as multimedia for NATs that would allow many applications, such as multimedia
communications or on-line gaming, to work consistently. Developing communications or on-line gaming, to work consistently. Developing
NATs that meet this set of requirements will greatly increase the NATs that meet this set of requirements will greatly increase the
likelihood that these applications will function properly. likelihood that these applications will function properly.
The requirements of this specification apply generally to all NAT The requirements of this specification apply to Traditional NATs as
variations, including the ones described in RFC 2663 [3] (Traditional described in RFC 2663 [3].
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.
This document is meant to cover NATs of any size, from small This document is meant to cover NATs of any size, from small
residential NATs to large Enterprise NATs. However, it should be residential NATs to large Enterprise NATs. However, it should be
understood that Enterprise NATs normally provide much more than just understood that Enterprise NATs normally provide much more than just
NAT capabilities: for example, they typically provide Firewall NAT capabilities: for example, they typically provide firewall
capabilities. Firewalls is specifically out-of-scope of this functionalities. Firewalls are specifically out-of-scope for this
specification: however, this specification does cover the inherent specification; however, this specification does cover the inherent
filtering aspects of NAT. filtering aspects of NATs.
Approaches using directly signaled control of middle boxes such as Approaches using directly signaled control of middle boxes such as
Midcom, UPnP, or in-path signaling are out of scope. Midcom, UPnP, or in-path signaling are out of scope.
UDP Relays are out of the scope of this document. UDP Relays are out-of-scope.
Application aspects are out of scope as the focus is strictly on the Application aspects are out-of-scope, as the focus here is strictly
NAT itself. on the NAT itself.
This document only covers the UDP Unicast aspects of NAT traversal This document only covers the UDP Unicast aspects of NAT traversal
and does not cover TCP, IPSEC, or other protocols. Since the and does not cover TCP, IPSEC, or other protocols. Since the
document is for UDP only, packet inspection above the UDP layer document is for UDP only, packet inspection above the UDP layer
(including RTP) is also out-of-scope. (including RTP) is also out-of-scope.
2. Introduction 2. Introduction
Network Address Translators (NAT) are well known to cause very Network Address Translators (NATs) are well known to cause very
significant problems with applications that carry IP addresses in the significant problems with applications that carry IP addresses in the
payload RFC 3027 [5]. Applications that suffer from this problem payload RFC 3027 [5]. Applications that suffer from this problem
include Voice Over IP and Multimedia Over IP (e.g., SIP [6] and H.323 include Voice Over IP and Multimedia Over IP (e.g., SIP [6] and H.323
[20]), as well as online gaming. [20]), as well as online gaming.
Many techniques are used to attempt to make realtime multimedia Many techniques are used to attempt to make realtime multimedia
applications, online games, and other applications work across NATs. applications, online games, and other applications work across NATs.
Application Level Gateways [3] are one such mechanism. STUN [7] Application Level Gateways [3] are one such mechanism. STUN [7]
describes a UNilateral Self-Address Translation (UNSAF) mechanism describes a UNilateral Self-Address Translation (UNSAF) mechanism
[2]. UDP Relays have also been used to enable applications across [2]. UDP Relays have also been used to enable applications across
NATs, but these are generally seen as a solution of last resort. ICE NATs, but these are generally seen as a solution of last resort. ICE
[16] describes a methodology for using many of these techniques and [16] describes a methodology for using many of these techniques and
avoiding a UDP Relay unless the type of NAT is such that it forces avoiding a UDP Relay unless the type of NAT is such that it forces
the use of such a UDP Relay. This specification defines requirements the use of such a UDP Relay. This specification defines requirements
for improving NATs. Meeting these requirements ensures that for improving NATs. Meeting these requirements ensures that
applications will not be forced to use UDP media relay. applications will not be forced to use UDP media relay.
As pointed out in UNSAF [2], "From observations of deployed networks, As pointed out in UNSAF [2], "From observations of deployed networks,
it is clear that different NAT boxes' implementation vary widely in it is clear that different NAT boxes' implementation vary widely in
terms of how they handle different traffic and addressing cases." terms of how they handle different traffic and addressing cases."
This wide degree of variability is one part of what contributes to This wide degree of variability is one factor in the overall
the overall brittleness introduced by NATs and makes it extremely brittleness introduced by NATs and makes it extremely difficult to
difficult to predict how any given protocol will behave on a network predict how any given protocol will behave on a network traversing
traversing NATs. Discussions with many of the major NAT vendors have NAT. Discussions with many of the major NAT vendors have made it
made it clear that they would prefer to deploy NATs that were clear that they would prefer to deploy NATs that were deterministic
deterministic and caused the least harm to applications while still and caused the least harm to applications while still meeting the
meeting the requirements that caused their customers to deploy NATs requirements that caused their customers to deploy NATs in the first
in the first place. The problem the NAT vendors face is they are not place. The problem NAT vendors face is that they are not sure how
sure how best to do that or how to document how their NATs behave. best to do that or how to document how their NATs behave.
The goals of this document are to define a set of common terminology The goals of this document are to define a set of common terminology
for describing the behavior of NATs and to produce a set of for describing the behavior of NATs and to produce a set of
requirements on a specific set of behaviors for NATs. The requirements on a specific set of behaviors for NATs. The
requirements represent what many vendors are already doing, and it is requirements represent what many vendors are already doing, and it is
not expected that it should be any more difficult to build a NAT that not expected that it should be any more difficult to build a NAT that
meets these requirements or that these requirements should affect meets these requirements or that these requirements should affect
performance. performance.
This document forms a common set of requirements that are simple and This document forms a common set of requirements that are simple and
skipping to change at page 5, line 31 skipping to change at page 5, line 27
This document uses the term "session" as defined in RFC 2663: "TCP/ This document uses the term "session" as defined in RFC 2663: "TCP/
UDP sessions are uniquely identified by the tuple of (source IP UDP sessions are uniquely identified by the tuple of (source IP
address, source TCP/UDP ports, target IP address, target TCP/UDP address, source TCP/UDP ports, target IP address, target TCP/UDP
Port)." Port)."
This document uses the term "address and port mapping" as the This document uses the term "address and port mapping" as the
translation between an external address and port and an internal translation between an external address and port and an internal
address and port. Note that this is not the same as an "address address and port. Note that this is not the same as an "address
binding" as defined in RFC 2663. binding" as defined in RFC 2663.
Earlier documents used the terms "Full Cone", "Restricted Cone", RFC 3489 used the terms "Full Cone", "Restricted Cone", "Port
"Port Restricted Cone" and "Symmetric" to refer to different Restricted Cone" and "Symmetric" to refer to different variations of
variations of NATs applicable to UDP only. Unfortunately, this NATs applicable to UDP only. Unfortunately, this terminology has
terminology has been the source of much confusion as it proved been the source of much confusion as it has proven inadequate at
inadequate at describing real-life NAT behavior. This specification describing real-life NAT behavior. This specification therefore
therefore refers to specific individual NAT behaviors instead of refers to specific individual NAT behaviors instead of using the
using the Cone/Symmetric terminology. Cone/Symmetric terminology.
4. Network Address and Port Translation Behavior 4. Network Address and Port Translation Behavior
This section describes the various NAT behaviors applicable to NAT. This section describes the various NAT behaviors applicable to NATs.
4.1 Address and Port Mapping 4.1 Address and Port Mapping
When an internal endpoint opens an outgoing session through a NAT, When an internal endpoint opens an outgoing session through a NAT,
the NAT assigns the session an external IP address and port number so the NAT assigns the session an external IP address and port number so
that subsequent response packets from the external endpoint can be that subsequent response packets from the external endpoint can be
received by the NAT, translated and forwarded to the internal received by the NAT, translated, and forwarded to the internal
endpoint. This is a mapping between an internal IP address and port endpoint. This is a mapping between an internal IP address and port
IP:port and external IP:port tuple. It establishes the translation IP:port and external IP:port tuple. It establishes the translation
that will be performed by the NAT for the duration of the session. that will be performed by the NAT for the duration of the session.
For many applications, it is important to distinguish the behavior of For many applications, it is important to distinguish the behavior of
the NAT when there are multiple simultaneous sessions established to the NAT when there are multiple simultaneous sessions established to
different external endpoints. different external endpoints.
The key behavior to describe is the criteria for re-use of a mapping The key behavior to describe is the criteria for re-use of a mapping
for new sessions to external endpoints, after establishing a first for new sessions to external endpoints, after establishing a first
mapping between an internal X:x address and port and an external mapping between an internal X:x address and port and an external
skipping to change at page 8, line 5 skipping to change at page 7, line 52
behavior of "Paired". Note that this requirement is not behavior of "Paired". Note that this requirement is not
applicable to NATs that do not support IP address pooling. applicable to NATs that do not support IP address pooling.
Justification for REQ-2: This will allow applications that use Justification for REQ-2: This will allow applications that use
multiple ports originating from the same internal IP address to multiple ports originating from the same internal IP address to
also have the same external IP address. This is to avoid breaking also have the same external IP address. This is to avoid breaking
peer-to-peer applications which are not capable of negotiating the peer-to-peer applications which are not capable of negotiating the
IP address for RTP and the IP address for RTCP separately. As IP address for RTP and the IP address for RTCP separately. As
such it is envisioned that this requirement will become less such it is envisioned that this requirement will become less
important as applications become NAT-friendlier with time. The important as applications become NAT-friendlier with time. The
main reason why this requirement is here is because in a peer-to- main reason why this requirement is here is that in a peer-to-peer
peer application, you are subject to the other peer's mistake. In application, you are subject to the other peer's mistake. In
particular, in the context of SIP, if my application supports the particular, in the context of SIP, if my application supports the
extensions defined in RFC 3605 [9] for indicating RTP and RTCP extensions defined in RFC 3605 [9] for indicating RTP and RTCP
addresses and ports separately, but the other peer does not, there addresses and ports separately, but the other peer does not, there
may still be breakage in the form of lost of the RTP stream. This may still be breakage in the form of letting the stream loose the
requirements will avoid the loss of RTP in this context, although RTP packets. This requirement will avoid the loss of RTP in this
the loss of RTCP may be inevitable in this particular example. It context, although the loss of RTCP may be inevitable in this
is also worth noting that RFC 3605 is unfortunately not a particular example. It is also worth noting that RFC 3605 is
mandatory part of SIP (i.e., RFC 3261). This requirement will unfortunately not a mandatory part of SIP (RFC 3261). This
therefore address a particularly nasty problem that will prevail requirement will therefore address a particularly nasty problem
for a significant amount of time. that will prevail for a significant amount of time.
4.2 Port Assignment 4.2 Port Assignment
4.2.1 Port Assignment Behavior 4.2.1 Port Assignment Behavior
This section uses the following diagram for reference. This section uses the following diagram for reference.
E E
+-------+ +-------+ x +-------+ +-------+ x
| Y1 | | Y2 | t | Y1 | | Y2 | t
skipping to change at page 8, line 51 skipping to change at page 8, line 49
l l
Some NATs attempt to preserve the port number used internally when Some NATs attempt to preserve the port number used internally when
assigning a mapping to an external IP address and port (e.g., assigning a mapping to an external IP address and port (e.g.,
x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A
basic NAT, for example, will preserve the same port and will assign a basic NAT, for example, will preserve the same port and will assign a
different IP address from a pool of external IP addresses in case of different IP address from a pool of external IP addresses in case of
port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only
possible as long as the NAT has enough external IP addresses. If the possible as long as the NAT has enough external IP addresses. If the
port x is already in use on all available external IP addresses, then port x is already in use on all available external IP addresses, then
the NAT needs to switch from Basic NAT to a Network Address and Port the NAT needs to switch from Basic NAT to Network Address and Port
Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or
a mapping of X1:x to X':x1' and X2:x to X':x2'). This port a mapping of X1:x to X':x1' and X2:x to X':x2'). This port
assignment behavior is referred to as "port preservation". It does assignment behavior is referred to as "port preservation". It does
not guarantee that the external port x' will always be the same as not guarantee that the external port x' will always be the same as
the internal port x but only that the NAT will preserve the port if the internal port x but only that the NAT will preserve the port if
possible. possible.
A NAT that does not attempt to make the external port numbers match A NAT that does not attempt to make the external port numbers match
the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to
X':x2') is referred to as "No port preservation". X':x2') is referred to as "No port preservation".
skipping to change at page 9, line 38 skipping to change at page 9, line 36
When NATs do allocate a new source port, there is the issue of which When NATs do allocate a new source port, there is the issue of which
IANA-defined range of port to choose. The ranges are "well-known" IANA-defined range of port to choose. The ranges are "well-known"
from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/
private" from 49152 through 65535. For most protocols, these are private" from 49152 through 65535. For most protocols, these are
destination ports and not source ports, so mapping a source port to a destination ports and not source ports, so mapping a source port to a
source port that is already registered is unlikely to have any bad source port that is already registered is unlikely to have any bad
effects. Some NATs may choose to use only the ports in the dynamic effects. Some NATs may choose to use only the ports in the dynamic
range; the only down side of this practice is that it limits the range; the only down side of this practice is that it limits the
number of ports available. Other NAT devices may use everything but number of ports available. Other NAT devices may use everything but
the well-known range and may prefer to use the dynamics range first the well-known range and may prefer to use the dynamic range first or
or possibly avoid the actual registered ports in the registered possibly avoid the actual registered ports in the registered range.
range. Other NATs preserve the port range if it is in the well-known Other NATs preserve the port range if it is in the well-known range.
range. It should be noted that port 0 is reserved and must not be It should be noted that port 0 is reserved and must not be used.
used.
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading". overloading".
a) If the host's source port was in the range 1-1023, it is a) If the host's source port was in the range 1-1023, it is
RECOMMENDED the NAT's source port also be in the same range. RECOMMENDED the NAT's source port be in the same range. If the
If the host's source port was in the range 1024-65535, it is host's source port was in the range 1024-65535, it is
RECOMMENDED that the NAT's source port also be in that range. RECOMMENDED that the NAT's source port be in that range.
Justification for REQ-3: This requirement must be met in order to Justification for REQ-3: This requirement must be met in order to
enable two applications on the internal side of the NAT both to enable two applications on the internal side of the NAT both to
use the same port to try to communicate with the same destination. use the same port to try to communicate with the same destination.
NATs that implement port preservation have to deal with conflicts NATs that implement port preservation have to deal with conflicts
on ports, and the multiple code paths this introduces often result on ports, and the multiple code paths this introduces often result
in nondeterministic behavior. However, it should be understood in nondeterministic behavior. However, it should be understood
that when a port is randomly assigned, it may just randomly happen that when a port is randomly assigned, it may just randomly happen
to be assigned the same port. Applications must therefore be able to be assigned the same port. Applications must therefore be able
to deal with both port preservation, and no port preservation. to deal with both port preservation, and no port preservation.
skipping to change at page 10, line 41 skipping to change at page 10, line 41
application aspects are outside the scope of this document. It is application aspects are outside the scope of this document. It is
expected that this issue will fade away with time, as implementations expected that this issue will fade away with time, as implementations
improve. Preserving the port parity allows for supporting improve. Preserving the port parity allows for supporting
communication with peers that do not support explicit specification communication with peers that do not support explicit specification
of both RTP and RTCP port numbers. of both RTP and RTCP port numbers.
REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation"
behavior of "Yes". behavior of "Yes".
Justification for REQ-4: This is to avoid breaking peer-to-peer Justification for REQ-4: This is to avoid breaking peer-to-peer
applications which do not explicity and separately specify RTP and applications which do not explicitly and separately specify RTP
RTCP port numbers and which follow the RFC 3550 rule to decrement and RTCP port numbers and which follow the RFC 3550 rule to
an odd RTP port to make it even. The same considerations as per decrement an odd RTP port to make it even. The same
the IP address pooling requirement apply. considerations as per the IP address pooling requirement apply.
4.2.3 Port Contiguity 4.2.3 Port Contiguity
Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1.
These NATs do things like sequential assignment or port reservation. These NATs do things like sequential assignment or port reservation.
Sequential port assignment assumes that the application will open a Sequential port assignment assumes that the application will open a
mapping for RTP first and then open a mapping for RTCP. It is not mapping for RTP first and then open a mapping for RTCP. It is not
practical to enforce this requirement on all applications. practical to enforce this requirement on all applications.
Furthermore, there is a glaring problem if many applications (or Furthermore, there is a glaring problem if many applications (or
endpoints) are trying to open mapping simultaneously. Port endpoints) are trying to open mapping simultaneously. Port
reservation is also problematic since it is wasteful, especially preservation is also problematic since it is wasteful, especially
considering that a NAT can not reliably distinguish between RTP over considering that a NAT can not reliably distinguish between RTP over
UDP and other UDP packets where there is no contiguity rule. For UDP and other UDP packets where there is no contiguity rule. For
those reasons, it would be too complex to attempt to preserve the those reasons, it would be too complex to attempt to preserve the
contiguity rule by suggesting specific NAT behavior, and it would contiguity rule by suggesting specific NAT behavior, and it would
certainly break the deterministic behavior rule. certainly break the deterministic behavior rule.
In order to support both RTP and RTCP, it will therefore be necessary In order to support both RTP and RTCP, it will therefore be necessary
that applications follows rules to negotiate both RTP and RTCP that applications follow rules to negotiate RTP and RTCP separately,
separately, and account for the very real possibility that the and account for the very real possibility that the RTCP=RTP+1 rule
RTCP=RTP+1 rule will be broken. As this is an application will be broken. As this is an application requirement, it is outside
requirement, it is outside of the scope of this document. of the scope of this document.
4.3 Mapping Refresh 4.3 Mapping Refresh
NAT mapping timeout implementations vary but include the timer's NAT mapping timeout implementations vary but include the timer's
value and the way the mapping timer is refreshed to keep the mapping value and the way the mapping timer is refreshed to keep the mapping
alive. alive.
The mapping timer is defined as the time a mapping will stay active The mapping timer is defined as the time a mapping will stay active
without packets traversing the NAT. There is great variation in the without packets traversing the NAT. There is great variation in the
values used by different NATs. values used by different NATs.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
Some NATs keep the mapping active on both, in which case both Some NATs keep the mapping active on both, in which case both
properties are "True". properties are "True".
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
refresh behavior" of "True". refresh behavior" of "True".
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
refresh behavior" of "True". refresh behavior" of "True".
Justification for REQ-6: Outbound refresh is necessary for allowing Justification for REQ-6: Outbound refresh is necessary for allowing
the client to keep the mapping alive. the client to keep the mapping alive.
a) Inbound refresh may be useful for applications where there is a) Inbound refresh may be useful for applications with no outgoing
no outgoing UDP traffic. UDP traffic. However, allowing inbound refresh may allow an
application to keep a mapping alive indefinitely. This may be
a security risk. Also, if the process is repeated with
different ports, over time, it could use up all the ports on
the NAT.
5. Filtering Behavior 5. Filtering Behavior
This section describes various filtering behaviors observed in NATs. This section describes various filtering behaviors observed in NATs.
5.1 Filtering of Unsolicited Packets 5.1 Filtering of Unsolicited Packets
When an internal endpoint opens an outgoing session through a NAT, When an internal endpoint opens an outgoing session through a NAT,
the NAT assigns a filtering rule for the mapping between an internal the NAT assigns a filtering rule for the mapping between an internal
IP:port (X:x) and external IP:port (Y:y) tuple. IP:port (X:x) and external IP:port (Y:y) tuple.
skipping to change at page 13, line 27 skipping to change at page 13, line 33
OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY? OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY?
Justification for REQ-7: The recommendation to use Endpoint Justification for REQ-7: The recommendation to use Endpoint
Independent Filtering is aimed at maximizing application Independent Filtering is aimed at maximizing application
transparency, in particular for applications that receive media transparency, in particular for applications that receive media
simultaneously from multiple locations (e.g., gaming), or simultaneously from multiple locations (e.g., gaming), or
applications that use rendezvous techniques. However, it is also applications that use rendezvous techniques. However, it is also
possible that in some circumstances, it may be preferable to have possible that in some circumstances, it may be preferable to have
a more stringent filtering behavior. Filtering independently of a more stringent filtering behavior. Filtering independently of
the external endpoint is not as secure: an unauthorized packet the external endpoint is not as secure: an unauthorized packet
could get a specific port while the port was kept open if it was could get through a specific port while the port was kept open if
lucky enough to find the port open. In theory, filtering based on it was lucky enough to find the port open. In theory, filtering
both IP address and port is more secure than filtering based only based on both IP address and port is more secure than filtering
on the IP address (because the external endpoint could in reality based only on the IP address (because the external endpoint could
be two endpoints behind another NAT, where one of the two in reality be two endpoints behind another NAT, where one of the
endpoints is an attacker): however, such a policy could interfere two endpoints is an attacker): however, such a policy could
with applications that expect to receive UDP packets on more than interfere with applications that expect to receive UDP packets on
one UDP port. Using Endpoint Independent Filtering or Address more than one UDP port. Using Endpoint Independent Filtering or
Dependent Filetering instead of Address and Port Dependent Address Dependent Filtering instead of Address and Port Dependent
Filtering on a NAT (say NAT-A) also has benefits when the other Filtering on a NAT (say NAT-A) also has benefits when the other
enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which endpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which
doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses
Address and Port Dependent Filtering, connectivity will require a Address and Port Dependent Filtering, connectivity will require a
Media Relay. However, if NAT-A uses Endpoint Indepent Filtering Media Relay. However, if NAT-A uses Endpoint Independent
or Address Dependent Filtering, ICE will ultimately find Filtering or Address Dependent Filtering, ICE will ultimately find
connectivity without requiring a Media Relay. Having the connectivity without requiring a Media Relay. Having the
filtering behavior being an option configurable by the filtering behavior being an option configurable by the
administrator of the NAT ensures that a NAT can be used in the administrator of the NAT ensures that a NAT can be used in the
widest variety of deployment scenarios. widest variety of deployment scenarios.
5.2 NAT Filter Refresh 5.2 NAT Filter Refresh
The time for which a NAT filter is valid can be refreshed based on The time for which a NAT filter is valid can be refreshed based on
packets that are inbound, outbound, or going either direction. packets that are inbound, outbound, or going either direction.
skipping to change at page 15, line 28 skipping to change at page 15, line 31
NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT ALGs may interfere with UNSAF methods or protocols that try to be
NAT-aware and must therefore be used with extreme caution. NAT-aware and must therefore be used with extreme caution.
REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those
ALGs (except for DNS [19] and FTP [18]) be disabled by default. ALGs (except for DNS [19] and FTP [18]) be disabled by default.
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
the NAT administrator to enable or disable each ALG separately. the NAT administrator to enable or disable each ALG separately.
Justification for REQ-9: NAT ALGs may interfere with UNSAF methods. Justification for REQ-9: NAT ALGs may interfere with UNSAF methods.
a) This requirement allows the user to enable ALGs which are a) This requirement allows the user to enable those ALGs that are
necessary to aid operation of some applications without necessary to aid in the operation of some applications without
enabling ALGs which interfere with operation of other enabling ALGs which interfere with the operation of other
applications. applications.
8. Deterministic Properties 8. Deterministic Properties
The classification of NATs is further complicated by the fact that The classification of NATs is further complicated by the fact that
under some conditions the same NAT will exhibit different behaviors. under some conditions the same NAT will exhibit different behaviors.
This has been seen on NATs that preserve ports or have specific This has been seen on NATs that preserve ports or have specific
algorithms for selecting a port other than a free one. If the algorithms for selecting a port other than a free one. If the
external port that the NAT wishes to use is already in use by another external port that the NAT wishes to use is already in use by another
session, the NAT must select a different port. This results in session, the NAT must select a different port. This results in
skipping to change at page 16, line 9 skipping to change at page 16, line 12
are not equal to x). There are NATs where the External NAT mapping are not equal to x). There are NATs where the External NAT mapping
characteristics and the External Filter characteristics change characteristics and the External Filter characteristics change
between the X1:x and the X2:x mapping. To make matters worse, there between the X1:x and the X2:x mapping. To make matters worse, there
are NATs where the behavior may be the same on the X1:x and X2:x are NATs where the behavior may be the same on the X1:x and X2:x
mappings but different on the third X3:x mapping. mappings but different on the third X3:x mapping.
Some NATs that try to reuse external ports flow from two internal IP Some NATs that try to reuse external ports flow from two internal IP
addresses to two different external IP addresses. For example, X1:x addresses to two different external IP addresses. For example, X1:x
is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not
equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x
to X1':x. This works in the case where the NAT mapping is address to X1':x. This works if the NAT mapping is address port dependent.
port dependent. However some NATs change their behavior when this However some NATs change their behavior when this type of port reuse
type of port reuse is happening. The NAT may look like it has NAT is happening. The NAT may look like it has NAT mappings that are
mappings that are independent when this type of reuse is not independent when this type of reuse is not happening but may change
happening but may change to Address Port Dependent when this reuse to Address Port Dependent when this reuse happens.
happens.
Any NAT that changes the NAT mapping or the External Filtering Any NAT that changes the NAT mapping or the External Filtering
without configuration changes, at any point in time under any without configuration changes, at any point in time under any
particular conditions is referred to as a "non-deterministic" NAT. particular conditions is referred to as a "non-deterministic" NAT.
NATs that don't are called "deterministic". NATs that don't are called "deterministic".
Non-deterministic NATs generally change behavior when a conflict of Non-deterministic NATs generally change behavior when a conflict of
some sort happens, i.e. when the port that would normally be used is some sort happens, i.e. when the port that would normally be used is
already in use by another mapping. The NAT mapping and External already in use by another mapping. The NAT mapping and External
Filtering in the absence of conflict is referred to as the Primary Filtering in the absence of conflict is referred to as the Primary
behavior. The behavior after the first conflict is referred to as behavior. The behavior after the first conflict is referred to as
Secondary and after the second conflict is referred to as Tertiary. Secondary and after the second conflict is referred to as Tertiary.
No NATs have been observed that change on further conflicts but it is No NATs have been observed that change on further conflicts but it is
certainly possible that they exist. certainly possible that they exist.
REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT mapping or the External External Filtering Behavior change the NAT mapping or the External Filtering Behavior at any
at any point in time or under any particular conditions. point in time or under any particular conditions.
Justification for REQ-10: Non-deterministic NATs are very difficult Justification for REQ-10: Non-deterministic NATs are very difficult
to troubleshoot because they require more intensive testing. This to troubleshoot because they require more intensive testing. This
non-deterministic behavior is the root cause of much of the non-deterministic behavior is the root cause of much of the
uncertainty that NATs introduce about whether or not applications uncertainty that NATs introduce about whether or not applications
will work. will work.
9. ICMP Destination Unreachable Behavior 9. ICMP Destination Unreachable Behavior
When a NAT sends a packet towards a host on the other side of the When a NAT sends a packet towards a host on the other side of the
NAT, an ICMP message may be sent in response to that packet. That NAT, an ICMP message may be sent in response to that packet. That
ICMP message may be sent by the destination host or by any router ICMP message may be sent by the destination host or by any router
along the network path. The NAT's default configuration SHOULD NOT along the network path. The NAT's default configuration SHOULD NOT
filter ICMP messages based on their source IP address. Such ICMP filter ICMP messages based on their source IP address. Such ICMP
messages SHOULD be rewritten by the NAT (specifically the IP headers messages SHOULD be rewritten by the NAT (specifically the IP headers
and the ICMP payload) and forwarded to the appropriate internal or and the ICMP payload) and forwarded to the appropriate internal or
external host. The NAT needs to perform this function for as long as external host. The NAT needs to perform this function for as long as
the UDP mapping is active. Receipt of any sort of ICMP message MUST the UDP mapping is active. Receipt of any sort of ICMP message MUST
NOT destroy the NAT mapping. A NAT which performs the functions NOT destroy the NAT mapping. A NAT which performs the functions
described in the paragraph above is referred to as "UDP Support described in the paragraph above is referred to as "support ICMP
Destination Unreachable". Processing".
There is no significant security advantage to blocking ICMP There is no significant security advantage to blocking ICMP
Destination Unreachable packets. Destination Unreachable packets. Additionally, blocking ICMP
Destination Unreachable packets can interfere with application
Additionally, blocking ICMP Destination Unreachable packets can failover, UDP Path MTU Discovery (see RFC1191 [10] and RFC1435 [15]),
interfere with application failover, UDP Path MTU Discovery (see and traceroute. Blocking any ICMP message is discouraged, and
RFC1191 [10] and RFC1435 [15]), and with traceroute. Blocking any blocking ICMP Destination Unreachable is strongly discouraged.
ICMP message is discouraged, and blocking ICMP Destination
Unreachable is strongly discouraged.
REQ-11: It is RECOMMENDED that a NAT support ICMP Destination REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT
Unreachable. mapping.
a) The ICMP timeout SHOULD be greater than 2 seconds. a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address.
b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages.
Justification for REQ-11: This is easy to do, is used for many things Justification for REQ-11: This is easy to do, is used for many things
including MTU discovery and rapid detection of error conditions, including MTU discovery and rapid detection of error conditions,
and has no negative consequences. and has no negative consequences.
a) The ICMP timeout SHOULD be greater than 2 seconds.
10. Fragmentation of Outgoing Packets 10. Fragmentation of Outgoing Packets
When sending a packet, there are two situations that may cause IP When sending a packet, there are two situations that may cause IP
fragmentation for packets from the inside to the outside. It is fragmentation for packets from the inside to the outside. It is
worth noting that many IP stacks do not use Path MTU Discovery with worth noting that many IP stacks do not use Path MTU Discovery with
UDP packets. UDP packets.
10.1 Smaller Adjacent MTU 10.1 Smaller Adjacent MTU
skipping to change at page 18, line 17 skipping to change at page 18, line 20
The second situation is when the MTU on some link in the middle of The second situation is when the MTU on some link in the middle of
the network that is not the adjacent link is too small. If DF=0, the the network that is not the adjacent link is too small. If DF=0, the
router adjacent to the small-MTU segment will fragment the packet and router adjacent to the small-MTU segment will fragment the packet and
forward the fragments as specified in RFC 1812 [14]. forward the fragments as specified in RFC 1812 [14].
If DF=1, the router adjacent to the small-MTU segment will send the If DF=1, the router adjacent to the small-MTU segment will send the
ICMP message "fragmentation needed and DF set" back towards the NAT. ICMP message "fragmentation needed and DF set" back towards the NAT.
The NAT needs to forward this ICMP message to the inside host. The NAT needs to forward this ICMP message to the inside host.
The classification of NATs that perform this behavior is covered in The classification of NATs that perform this behavior is covered in
the ICMP section of this document. Section 9.
REQ-12: A NAT MUST support fragmentation of packets larger than link REQ-12: A NAT MUST support fragmentation of packets larger than link
MTU. MTU.
Justification for REQ-12: Fragmented packets become more common with Justification for REQ-12: Fragmented packets become more common with
large video packets and should continue to work. Applications can large video packets and should continue to work. Applications can
use MTU discovery to work around this problem. use MTU discovery to work around this problem.
11. Receiving Fragmented Packets 11. Receiving Fragmented Packets
skipping to change at page 19, line 37 skipping to change at page 19, line 40
specification." specification."
REQ-1: A NAT MUST have an "External NAT mapping is endpoint REQ-1: A NAT MUST have an "External NAT mapping is endpoint
independent" behavior. independent" behavior.
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"
behavior of "Paired". Note that this requirement is not behavior of "Paired". Note that this requirement is not
applicable to NATs that do not support IP address pooling. applicable to NATs that do not support IP address pooling.
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading". overloading".
a) If the host's source port was in the range 1-1023, it is a) If the host's source port was in the range 1-1023, it is
RECOMMENDED the NAT's source port also be in the same range. RECOMMENDED the NAT's source port be in the same range. If the
If the host's source port was in the range 1024-65535, it is host's source port was in the range 1024-65535, it is
RECOMMENDED that the NAT's source port also be in that range. RECOMMENDED that the NAT's source port be in that range.
REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation"
behavior of "Yes". behavior of "Yes".
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
minutes. minutes.
a) The value of the NAT UDP mapping timer MAY be configurable. a) The value of the NAT UDP mapping timer MAY be configurable.
b) A default value of 5 minutes for the NAT UDP mapping timer is b) A default value of 5 minutes for the NAT UDP mapping timer is
RECOMMENDED. RECOMMENDED.
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
refresh behavior" of "True". refresh behavior" of "True".
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
refresh behavior" of "True". refresh behavior" of "True".
REQ-7: If application transparency is most important, it is REQ-7: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint independent filtering" RECOMMENDED that a NAT have "Endpoint independent filtering"
behavior. If a more stringent filtering behavior is most behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address dependent important, it is RECOMMENDED that a NAT have "Address dependent
filtering" behavior. filtering" behavior.
a) The filtering behavior MAY be an option configurable by the a) The filtering behavior MAY be an option configurable by the
administrator of the NAT. administrator of the NAT.
OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY? OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY?
REQ-8: A NAT MUST support "Hairpinning". REQ-8: A NAT MUST support "Hairpinning".
a) A NAT Hairpinning behavior MUST be "External source IP address a) A NAT Hairpinning behavior MUST be "External source IP address
and port". and port".
REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those
ALGs (except for DNS [19] and FTP [18]) be disabled by default. ALGs (except for DNS [19] and FTP [18]) be disabled by default.
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
the NAT administrator to enable or disable each ALG separately. the NAT administrator to enable or disable each ALG separately.
REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT mapping or the External External Filtering Behavior change the NAT mapping or the External External Filtering Behavior
at any point in time or under any particular conditions. at any point in time or under any particular conditions.
REQ-11: It is RECOMMENDED that a NAT support ICMP Destination REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT
Unreachable. mapping.
a) The ICMP timeout SHOULD be greater than 2 seconds. a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address.
b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages.
REQ-12: A NAT MUST support fragmentation of packets larger than link REQ-12: A NAT MUST support fragmentation of packets larger than link
MTU. MTU.
REQ-13: A NAT MUST support receiving in order fragments, so it MUST REQ-13: A NAT MUST support receiving in order fragments, so it MUST
be "Received Fragment Ordered" or "Received Fragment Out of be "Received Fragment Ordered" or "Received Fragment Out of
Order". Order".
a) A NAT MAY support receiving fragmented packets that are out of a) A NAT MAY support receiving fragmented packets that are out of
order and be of type "Received Fragment Out of Order". order and be of type "Received Fragment Out of Order".
13. Security Considerations 13. Security Considerations
skipping to change at page 22, line 39 skipping to change at page 22, line 44
with NATs for applications like VoIP. This work and STUN with NATs for applications like VoIP. This work and STUN
have pointed out more than anything else the brittleness NATs have pointed out more than anything else the brittleness NATs
introduce and the difficulty of addressing these issues. introduce and the difficulty of addressing these issues.
Arch-5: This work and the test results [17] provide a reference model Arch-5: This work and the test results [17] provide a reference model
for what any UNSAF proposal might encounter in deployed NATs. for what any UNSAF proposal might encounter in deployed NATs.
16. Acknowledgments 16. Acknowledgments
The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and
Dan Kegel for the their multiple contributions on peer-to-peer Dan Kegel for the their multiple contributions on peer-to-peer
communications accross a NAT. communications across a NAT. Dan Wing contributed substantial text
on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy,
Dan Wing contributed substantial text on IP fragmentation and ICMP Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell,
behavior. Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert
Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka
Thanks to Rohan Mahy, Jonathan Rosenberg, Mary Barnes, Melinda Shore, Takeda and Paul Hoffman for their contributions.
Lyndsay Campbell, Geoff Huston, Jiri Kuthan, Harald Welte, Steve
Casner, Robert Sanders, Spencer Dawkins, Saikat Guha, Christian
Huitema, Yutaka Takeda and Paul Hoffman for their important
contributions.
17. References 17. References
17.1 Normative References 17.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [2] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/