draft-ietf-behave-nat-udp-07.txt   draft-ietf-behave-nat-udp-08.txt 
BEHAVE F. Audet, Ed. BEHAVE F. Audet, Ed.
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: December 2, 2006 C. Jennings Intended status: Standards Track C. Jennings
Cisco Systems Expires: April 13, 2007 Cisco Systems
May 31, 2006 October 10, 2006
NAT Behavioral Requirements for Unicast UDP NAT Behavioral Requirements for Unicast UDP
draft-ietf-behave-nat-udp-07 draft-ietf-behave-nat-udp-08
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 2, 2006. This Internet-Draft will expire on April 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 also defines a types of NAT behavior when handling Unicast UDP and also defines a
set of requirements that would allow many applications, such as set of requirements that would allow many applications, such as
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . 11
4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11
4.4. Conflicting Internal and External IP Address Spaces . . . 12 4.4. Conflicting Internal and External IP Address Spaces . . . 13
5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14
6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16
7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17
8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17
9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19
10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19
11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 19 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . . 24 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25
17.2. Informational References . . . . . . . . . . . . . . . . . 25 17.2. Informational References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 29
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 to Traditional NATs as The requirements of this specification apply to Traditional NATs as
described in [RFC2663]. described in [RFC2663].
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
functionalities. Firewalls are specifically out-of-scope for this functionalities. A comprehensive description of firewall behaviors
specification; however, this specification does cover the inherent and associated requirements is specifically out-of-scope for this
filtering aspects of NATs which may resemble firewall operation. specification. However, this specification does cover basic firewall
aspects present in NATs (see Section 5).
Approaches using directly signaled control of middle boxes are out of Approaches using directly signaled control of middle boxes are out of
scope. scope.
UDP Relays (e.g., TURN [I-D.ietf-behave-turn]) are out-of-scope. UDP Relays (e.g., TURN [I-D.ietf-behave-turn]) are out-of-scope.
Application aspects are out-of-scope, as the focus here is strictly Application aspects are out-of-scope, as the focus here is strictly
on the NAT itself. on the NAT itself.
This document only covers aspects of NAT traversal related to Unicast This document only covers aspects of NAT traversal related to Unicast
skipping to change at page 6, line 39 skipping to change at page 6, line 40
...........| NAT |............... ...........| NAT |...............
+--+---+-+ I +--+---+-+ I
| | n | | n
X:x | | X:x t X:x | | X:x t
++---++ e ++---++ e
| X | r | X | r
+-----+ n +-----+ n
a a
l l
Address and Port Mapping
The following address and port mapping behavior are defined: The following address and port mapping behavior are defined:
Endpoint Independent Mapping: Endpoint Independent Mapping:
The NAT reuses the port mapping for subsequent packets sent The NAT reuses the port mapping for subsequent packets sent
from the same internal IP address and port (X:x) to any from the same internal IP address and port (X:x) to any
external IP address and port. Specifically, X1':x1' equals external IP address and port. Specifically, X1':x1' equals
X2':x2' for all values of Y2:y2. X2':x2' for all values of Y2:y2.
Address Dependent Mapping: Address Dependent Mapping:
The NAT reuses the port mapping for subsequent packets sent The NAT reuses the port mapping for subsequent packets sent
skipping to change at page 8, line 43 skipping to change at page 8, line 50
...........| NAT |............... ...........| NAT |...............
+--+---+--+ I +--+---+--+ I
| | n | | n
+---------+ +---------+ t +---------+ +---------+ t
| X1:x1 X2':x2 | e | X1:x1 X2':x2 | e
+---+---+ +---+---+ r +---+---+ +---+---+ r
| X1 | | X2 | n | X1 | | X2 | n
+-------+ +-------+ a +-------+ +-------+ a
l l
Port Assignment
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 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
skipping to change at page 9, line 41 skipping to change at page 9, line 49
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 dynamic range first or the well-known range and may prefer to use the dynamic range first or
possibly avoid the actual registered ports in the registered range. possibly avoid the actual registered ports in the registered range.
Other NATs preserve the port range if it is in the well-known range. Other NATs preserve the port range if it is in the well-known range.
[RFC0768] specifies that the source port is set to zero if no reply
packet are expected. In this case it does not matter what the NAT
maps it to as the source port will not be used. However, many common
OS APIs do not allow a user to send from port zero, applications do
not use port zero, and the behavior of various existing NATs with
regards to a packet with a source of port zero is unknown. This
document does not specify any normative behavior for a NAT when
handling a packet with a source port of zero which means that
applications can not count on any sort of deterministic behavior for
these packets.
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 0-1023, it is
RECOMMENDED the NAT's source port be in the same range. If the RECOMMENDED the NAT's source port be in the same range. 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 be in that range. RECOMMENDED that the NAT's source port be in that range.
Justification: This requirement must be met in order to enable two Justification: This requirement must be met in order to enable two
applications on the internal side of the NAT both to use the same applications on the internal side of the NAT both to use the same
port to try to communicate with the same destination. NATs that port to try to communicate with the same destination. NATs that
implement port preservation have to deal with conflicts on ports, implement port preservation have to deal with conflicts on ports,
and the multiple code paths this introduces often result in and the multiple code paths this introduces often result in
nondeterministic behavior. However, it should be understood that nondeterministic behavior. However, it should be understood that
skipping to change at page 10, line 38 skipping to change at page 11, line 5
an implementation receives an odd RTP port number from the peer an implementation receives an odd RTP port number from the peer
(perhaps after having been translated by a NAT), and then follows the (perhaps after having been translated by a NAT), and then follows the
RFC 3550 rule to change the RTP port to the next lower even number, RFC 3550 rule to change the RTP port to the next lower even number,
this would obviously result in the loss of RTP. NAT-friendly this would obviously result in the loss of RTP. NAT-friendly
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
behavior of "Yes". preservation" behavior of "Yes".
Justification: This is to avoid breaking peer-to-peer applications Justification: This is to avoid breaking peer-to-peer applications
which do not explicitly and separately specify RTP and RTCP port which do not explicitly and separately specify RTP and RTCP port
numbers and which follow the RFC 3550 rule to decrement an odd RTP numbers and which follow the RFC 3550 rule to decrement an odd RTP
port to make it even. The same considerations as per the IP port to make it even. The same considerations as per the IP
address pooling requirement apply. 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.
skipping to change at page 11, line 36 skipping to change at page 12, line 4
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.
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, unless REQ-5a applies. minutes, unless REQ-5a applies.
a) For specific destination ports in the well-known port range a) For specific destination ports in the well-known port range
(ports 0-1023), a NAT MAY have shorter UDP mapping timers that (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
are specific to the IANA-registered application running over are specific to the IANA-registered application running over
that specific destination port. that specific destination port.
b) The value of the NAT UDP mapping timer MAY be configurable. b) The value of the NAT UDP mapping timer MAY be configurable.
c) A default value of 5 minutes or more for the NAT UDP mapping c) A default value of 5 minutes or more for the NAT UDP mapping
timer is RECOMMENDED. timer is RECOMMENDED.
Justification: This requirement is to ensure that the timeout is long Justification: This requirement is to ensure that the timeout is
enough to avoid too frequent timer refresh packets. long enough to avoid too frequent timer refresh packets.
a) Some UDP protocols using UDP use very short-lived connections. a) Some UDP protocols using UDP use very short-lived connections.
There can be very many such connections; keeping them all in a There can be very many such connections; keeping them all in a
connections table could cause considerable load on the NAT. connections table could cause considerable load on the NAT.
Having shorter timers for these specific applications is Having shorter timers for these specific applications is
therefore an optimization technique. It is important that the therefore an optimization technique. It is important that the
shorter timers applied to specific protocols be used sparingly, shorter timers applied to specific protocols be used sparingly,
and only for protocols using well-known destination port that and only for protocols using well-known destination port that
are known to have a shorter timer, and that are known not to be are known to have a shorter timer, and that are known not to be
used by any applications for other purposes. used by any applications for other purposes.
b) Configuration is desirable for adapting to specific networks b) Configuration is desirable for adapting to specific networks
and troubleshooting. and troubleshooting.
c) This default is to avoid too frequent timer refresh packets. c) This default is to avoid too frequent timer refresh packets.
Some NATs keep the mapping active (i.e., refresh the timer value) Some NATs keep the mapping active (i.e., refresh the timer value)
when a packet goes from the internal side of the NAT to the external when a packet goes from the internal side of the NAT to the external
side of the NAT. This is referred to as having a NAT Outbound side of the NAT. This is referred to as having a NAT Outbound
refresh behavior of "True". refresh behavior of "True".
Some NATs keep the mapping active when a packet goes from the Some NATs keep the mapping active when a packet goes from the
skipping to change at page 16, line 16 skipping to change at page 16, line 33
+----+ from X1:x1 to X2':x2' +-----+ X1':x1' +----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
+----+ | v | +----+ | v |
| v | | v |
| v | | v |
| v | | v |
+----+ from X1':x1' to X2:x2 | v | X2':x2' +----+ from X1':x1' to X2:x2 | v | X2':x2'
| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
+----+ +-----+ +----+ +-----+
Hairpinning Behavior
Hairpinning allows two endpoints on the internal side of the NAT to Hairpinning allows two endpoints on the internal side of the NAT to
communicate even if they only use each other's external IP addresses communicate even if they only use each other's external IP addresses
and ports. and ports.
More formally, a NAT that supports hairpinning forwards packets More formally, a NAT that supports hairpinning forwards packets
originating from an internal address, X1:x1, destined for an external originating from an internal address, X1:x1, destined for an external
address X2':x2' that has an active mapping to an internal address address X2':x2' that has an active mapping to an internal address
X2:x2, back to that internal address X2:x2. Note that typically X1' X2:x2, back to that internal address X2:x2. Note that typically X1'
is the same as X2'. is the same as X2'.
skipping to change at page 17, line 9 skipping to change at page 17, line 30
various protocols, including protocols for negotiating peer-to-peer various protocols, including protocols for negotiating peer-to-peer
sessions such as SIP. sessions such as SIP.
Certain NATs have these ALGs turned on permanently, others have them Certain NATs have these ALGs turned on permanently, others have them
turned on by default but let them be be turned off, and others have turned on by default but let them be be turned off, and others have
them turned off by default but let them be turned on. them turned off by default but let them be turned on.
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-10: To eliminate interference with UNSAF NAT traversal mechanisms REQ-10: To eliminate interference with UNSAF NAT traversal
and allow integrity protection of UDP communications, NAT ALGs for mechanisms and allow integrity protection of UDP communications,
UDP-based protocols SHOULD be turned off. Future standards track NAT ALGs for UDP-based protocols SHOULD be turned off. Future
specifications that define an ALG can update this to recommend standards track specifications that define an ALG can update this
that the ALGs they define default on. to recommend that the ALGs they define default on.
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: NAT ALGs may interfere with UNSAF methods. Justification: NAT ALGs may interfere with UNSAF methods.
a) This requirement allows the user to enable those ALGs that are a) This requirement allows the user to enable those ALGs that are
necessary to aid in the operation of some applications without necessary to aid in the operation of some applications without
enabling ALGs which interfere with the operation of other enabling ALGs which interfere with the operation of other
applications. applications.
8. Deterministic Properties 8. Deterministic Properties
skipping to change at page 19, line 25 skipping to change at page 19, line 47
10. Fragmentation of Outgoing Packets 10. Fragmentation of Outgoing Packets
When the MTU of the adjacent link is too small, fragmentation of When the MTU of the adjacent link is too small, fragmentation of
packets going from the internal side to the external side of the NAT packets going from the internal side to the external side of the NAT
may occur. This can occur if the NAT is doing PPPoE, or if the NAT may occur. This can occur if the NAT is doing PPPoE, or if the NAT
has been configured with a small MTU to reduce serialization delay has been configured with a small MTU to reduce serialization delay
when sending large packets and small higher-priority packets, or for when sending large packets and small higher-priority packets, or for
other reasons. other reasons.
It is worth nothing that many IP stacks do not use Path MTU Discovery It is worth noting that many IP stacks do not use Path MTU Discovery
with UDP packets. with UDP packets.
The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0
(DF=0). (DF=0).
REQ-13: If the packet received on an internal IP address has DF=1, REQ-13: If the packet received on an internal IP address has DF=1,
the NAT MUST send back an ICMP message "fragmentation needed and the NAT MUST send back an ICMP message "fragmentation needed and
DF set" message to the host as described in [RFC0792]. DF set" message to the host as described in [RFC0792].
a) If the packet has DF=0, the NAT MUST fragment the packet and a) If the packet has DF=0, the NAT MUST fragment the packet and
SHOULD send the fragments in order. SHOULD send the fragments in order.
skipping to change at page 21, line 4 skipping to change at page 21, line 22
specification (i.e., the "MUST"), is "compliant with this specification (i.e., the "MUST"), is "compliant with this
specification." A NAT that supports all of the requirements of this specification." A NAT that supports all of the requirements of this
specification (i.e., including the "RECOMMENDED") is "fully compliant specification (i.e., including the "RECOMMENDED") is "fully compliant
with all the mandatory and recommended requirements of this with all the mandatory and recommended requirements of this
specification." specification."
REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior. REQ-1: A NAT MUST have an "Endpoint Independent Mapping" 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 0-1023, it is
RECOMMENDED the NAT's source port be in the same range. If the RECOMMENDED the NAT's source port be in the same range. 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 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
behavior of "Yes". preservation" 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, unless REQ-5a applies. minutes, unless REQ-5a applies.
a) For specific destination ports in the well-known port range a) For specific destination ports in the well-known port range
(ports 0-1023), a NAT MAY have shorter UDP mapping timers that (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
are specific to the IANA-registered application running over are specific to the IANA-registered application running over
that specific destination port. that specific destination port.
b) The value of the NAT UDP mapping timer MAY be configurable. b) The value of the NAT UDP mapping timer MAY be configurable.
c) A default value of 5 minutes or more for the NAT UDP mapping c) A default value of 5 minutes or more for the NAT UDP mapping
timer is RECOMMENDED. timer is 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
skipping to change at page 21, line 42 skipping to change at page 22, line 15
REQ-8: If application transparency is most important, it is REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have "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 "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.
REQ-9: A NAT MUST support "Hairpinning". REQ-9: 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-10: To eliminate interference with UNSAF NAT traversal mechanisms REQ-10: To eliminate interference with UNSAF NAT traversal
and allow integrity protection of UDP communications, NAT ALGs for mechanisms and allow integrity protection of UDP communications,
UDP-based protocols SHOULD be turned off. Future standards track NAT ALGs for UDP-based protocols SHOULD be turned off. Future
specifications that define an ALG can update this to recommend standards track specifications that define an ALG can update this
that the ALGs they define default on. to recommend that the ALGs they define default on.
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-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT translation (Section 4) or the Filtering change the NAT translation (Section 4) or the Filtering
(Section 5) Behavior at any point in time or under any particular (Section 5) Behavior at any point in time or under any particular
conditions. conditions.
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping. NAT mapping.
a) The NAT's default configuration SHOULD NOT filter ICMP messages a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address. based on their source IP address.
b) It is RECOMMENDED that a NAT support ICMP Destination b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages. Unreachable messages.
skipping to change at page 22, line 15 skipping to change at page 22, line 32
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT translation (Section 4) or the Filtering change the NAT translation (Section 4) or the Filtering
(Section 5) Behavior at any point in time or under any particular (Section 5) Behavior at any point in time or under any particular
conditions. conditions.
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping. NAT mapping.
a) The NAT's default configuration SHOULD NOT filter ICMP messages a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address. based on their source IP address.
b) It is RECOMMENDED that a NAT support ICMP Destination b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages. Unreachable messages.
REQ-13 If the packet received on an internal IP address has DF=1, the REQ-13 If the packet received on an internal IP address has DF=1,
NAT MUST send back an ICMP message "fragmentation needed and DF the NAT MUST send back an ICMP message "fragmentation needed and
set" message to the host as described in [RFC0792]. DF set" message to the host as described in [RFC0792].
a) If the packet has DF=0, the NAT MUST fragment the packet and a) If the packet has DF=0, the NAT MUST fragment the packet and
SHOULD send the fragments in order. SHOULD send the fragments in order.
REQ-14: A NAT MUST support receiving in order and out of order REQ-14: A NAT MUST support receiving in order and out of order
fragments, so it MUST have "Received Fragment Out of Order" fragments, so it MUST have "Received Fragment Out of Order"
behavior. behavior.
a) A NAT's out of order fragment processing mechanism MUST be a) A NAT's out of order fragment processing mechanism MUST be
designed so that fragmentation-based DoS attacks do not designed so that fragmentation-based DoS attacks do not
compromise the NAT's ability to process in-order and compromise the NAT's ability to process in-order and
unfragmented IP packets. unfragmented IP packets.
13. Security Considerations 13. Security Considerations
NATs are often deployed to achieve security goals. Most of the NATs are often deployed to achieve security goals. Most of the
recommendations and requirements in this document do not affect the recommendations and requirements in this document do not affect the
security properties of these devices, but a few of them do have security properties of these devices, but a few of them do have
security implications and are discussed in this section. security implications and are discussed in this section.
This document recommends that the timers for mapping be refreshed This document recommends that the timers for mapping be refreshed
only on outgoing packets and does not make recommendations about only on outgoing packets (see REQ-6) and does not make
whether or not inbound packets should update the timers. If inbound recommendations about whether or not inbound packets should update
packets update the timers, an external attacker can keep the mapping the timers. If inbound packets update the timers, an external
alive forever and attack future devices that may end up with the same attacker can keep the mapping alive forever and attack future devices
internal address. A device that was also the DHCP server for the that may end up with the same internal address. A device that was
private address space could mitigate this by cleaning any mappings also the DHCP server for the private address space could mitigate
when a DHCP lease expired. For unicast UDP traffic (the scope of this by cleaning any mappings when a DHCP lease expired. For unicast
this document), it may not seem relevant to support inbound timer UDP traffic (the scope of this document), it may not seem relevant to
refresh; however, for multicast UDP, the question is harder. It is support inbound timer refresh; however, for multicast UDP, the
expected that future documents discussing NAT behavior with multicast question is harder. It is expected that future documents discussing
traffic will refine the requirements around handling of the inbound NAT behavior with multicast traffic will refine the requirements
refresh timer. Some devices today do update the timers on inbound around handling of the inbound refresh timer. Some devices today do
packets. update the timers on inbound packets.
This document recommends that the NAT filters be specific to the This document recommends that the NAT filters be specific to the
external IP address only and not to the external IP and port. It can external IP address only (see REQ-8) and not to the external IP
be argued that this is less secure than using the IP and port. address and UDP port. It can be argued that this is less secure than
Devices that wish to filter on IP and port do still comply with these using the IP and port. Devices that wish to filter on IP and port do
requirements. still comply with these requirements.
Non-deterministic NATs are risky from a security point of view. They Non-deterministic NATs are risky from a security point of view. They
are very difficult to test because they are, well, non-deterministic. are very difficult to test because they are, well, non-deterministic.
Testing by a person configuring one may result in the person thinking Testing by a person configuring one may result in the person thinking
it is behaving as desired, yet under different conditions, which an it is behaving as desired, yet under different conditions, which an
attacker can create, the NAT may behave differently. These attacker can create, the NAT may behave differently. These
requirements recommend that devices be deterministic. requirements recommend that devices be deterministic.
This document requires that NATs have an "external NAT mapping is This document requires that NATs have an "external NAT mapping is
endpoint independent" behavior. This does not reduce the security of endpoint independent" behavior. This does not reduce the security of
skipping to change at page 24, line 19 skipping to change at page 24, line 36
Although this is not an UNSAF proposal, it is interesting to consider Although this is not an UNSAF proposal, it is interesting to consider
the impact of this work on these architectural considerations. the impact of this work on these architectural considerations.
Arch-1: The scope of this is limited to UDP packets in NATs like the Arch-1: The scope of this is limited to UDP packets in NATs like the
ones widely deployed today. The "fix" helps constrain the ones widely deployed today. The "fix" helps constrain the
variability of NATs for true UNSAF solutions such as STUN. variability of NATs for true UNSAF solutions such as STUN.
Arch-2: This will exit at the same rate that NATs exit. It does not Arch-2: This will exit at the same rate that NATs exit. It does not
imply any protocol machinery that would continue to live imply any protocol machinery that would continue to live
after NATs were gone or make it more difficult to remove after NATs were gone or make it more difficult to remove
them. them.
Arch-3: This does not reduce the overall brittleness of NATs but will Arch-3: This does not reduce the overall brittleness of NATs but
hopefully reduce some of the more outrageous NAT behaviors will hopefully reduce some of the more outrageous NAT
and make it easer to discuss and predict NAT behavior in behaviors and make it easer to discuss and predict NAT
given situations. behavior in given situations.
Arch-4: This work and the results [I-D.jennings-behave-test-results] Arch-4: This work and the results [I-D.jennings-behave-test-results]
of various NATs represent the most comprehensive work at IETF of various NATs represent the most comprehensive work at
on what the real issues are with NATs for applications like IETF on what the real issues are with NATs for applications
VoIP. This work and STUN have pointed out more than anything like VoIP. This work and STUN have pointed out more than
else the brittleness NATs introduce and the difficulty of anything else the brittleness NATs introduce and the
addressing these issues. difficulty of addressing these issues.
Arch-5: This work and the test results [I-D.jennings-behave-test- Arch-5: This work and the test results
results] provide a reference model for what any UNSAF [I-D.jennings-behave-test-results] provide a reference model
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 across a NAT. Dan Wing contributed substantial text communications across a NAT. Dan Wing contributed substantial text
on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy,
Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell,
Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert
Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka
Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola and Jari Arkko for Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola, Peter Koch and
their contributions. Jari Arkko for their contributions.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
skipping to change at page 26, line 33 skipping to change at page 27, line 6
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
October 2003. October 2003.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Simple Traversal of UDP Through Network Rosenberg, J., "Simple Traversal Underneath Network
Address Translators (NAT) (STUN)", Address Translators (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-03 (work in progress), draft-ietf-behave-rfc3489bis-04 (work in progress),
March 2006. July 2006.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT) (ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-08 (work in progress), March 2006. draft-ietf-mmusic-ice-11 (work in progress), October 2006.
[I-D.jennings-behave-test-results] [I-D.jennings-behave-test-results]
Jennings, C., "NAT Classification Test Results", Jennings, C., "NAT Classification Test Results",
draft-jennings-behave-test-results-01 (work in progress), draft-jennings-behave-test-results-02 (work in progress),
July 2005. June 2006.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal of UDP Through NAT (STUN)", Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-00 (work in progress), March 2006. draft-ietf-behave-turn-02 (work in progress),
October 2006.
[ITU.H323] [ITU.H323]
"Packet-based Multimedia Communications Systems", ITU- "Packet-based Multimedia Communications Systems", ITU-
T Recommendation H.323, July 2003. T Recommendation H.323, July 2003.
Authors' Addresses Authors' Addresses
Francois Audet (editor) Francois Audet (editor)
Nortel Networks Nortel Networks
4655 Great America Parkway 4655 Great America Parkway
skipping to change at page 29, line 5 skipping to change at page 29, line 5
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408 902 3341 Phone: +1 408 902 3341
Email: fluffy@cisco.com Email: fluffy@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 29 skipping to change at page 29, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 41 change blocks. 
101 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/