< 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 7, line 19 skipping to change at page 7, line 25
external IP address and port while the mapping is still active. external IP address and port while the mapping is still active.
Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2
equals Y1:y1. equals Y1:y1.
It is important to note that these three possible choices make no It is important to note that these three possible choices make no
difference to the security properties of the NAT. The security difference to the security properties of the NAT. The security
properties are fully determined by which packets the NAT allows in properties are fully determined by which packets the NAT allows in
and which it does not. This is determined by the filtering behavior and which it does not. This is determined by the filtering behavior
in the filtering portions of the NAT. in the filtering portions of the NAT.
REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior. REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior.
Justification: In order for UNSAF methods to work, REQ-1 needs to be Justification: In order for UNSAF methods to work, REQ-1 needs to be
met. Failure to meet REQ-1 will force the use of a UDP relay met. Failure to meet REQ-1 will force the use of a UDP relay
which is very often impractical. which is very often impractical.
Some NATs are capable of assigning IP addresses from a pool of IP Some NATs are capable of assigning IP addresses from a pool of IP
addresses on the external side of the NAT, as opposed to just a addresses on the external side of the NAT, as opposed to just a
single IP address. This is especially common with larger NATs. Some single IP address. This is especially common with larger NATs. Some
NATs use the external IP address mapping in an arbitrary fashion NATs use the external IP address mapping in an arbitrary fashion
(i.e. randomly): one internal IP address could have multiple external (i.e. randomly): one internal IP address could have multiple external
IP address mappings active at the same time for different sessions. IP address mappings active at the same time for different sessions.
These NATs have an "IP address pooling" behavior of "Arbitrary". These NATs have an "IP address pooling" behavior of "Arbitrary".
Some large Enterprise NATs use an IP address pooling behavior of Some large Enterprise NATs use an IP address pooling behavior of
"Arbitrary" as a means of hiding the IP address assigned to specific "Arbitrary" as a means of hiding the IP address assigned to specific
endpoints by making their assignment less predictable. Other NATs endpoints by making their assignment less predictable. Other NATs
use the same external IP address mapping for all sessions associated use the same external IP address mapping for all sessions associated
with the same internal IP address. These NATs have an "IP address with the same internal IP address. These NATs have an "IP address
pooling" behavior of "Paired." NATs that use an "IP address pooling" pooling" behavior of "Paired." NATs that use an "IP address pooling"
behavior of "arbitrary" can cause issues for applications that use behavior of "arbitrary" can cause issues for applications that use
multiple ports from the same endpoint but do not negotiate IP multiple ports from the same endpoint but do not negotiate IP
addresses individually (e.g., some applications using RTP and RTCP). addresses individually (e.g., some applications using RTP and RTCP).
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.
Justification: This will allow applications that use multiple ports Justification: This will allow applications that use multiple ports
originating from the same internal IP address to also have the originating from the same internal IP address to also have the
same external IP address. This is to avoid breaking peer-to-peer same external IP address. This is to avoid breaking peer-to-peer
applications that are not capable of negotiating the IP address applications that are not capable of negotiating the IP address
for RTP and the IP address for RTCP separately. As such it is for RTP and the IP address for RTCP separately. As such it is
envisioned that this requirement will become less important as envisioned that this requirement will become less important as
applications become NAT-friendlier with time. The main reason why applications become NAT-friendlier with time. The main reason why
this requirement is here is that in a peer-to-peer application, this requirement is here is that in a peer-to-peer application,
you are subject to the other peer's mistake. In particular, in you are subject to the other peer's mistake. In particular, in
the context of SIP, if my application supports the extensions the context of SIP, if my application supports the extensions
defined in [RFC3605] for indicating RTP and RTCP addresses and defined in [RFC3605] for indicating RTP and RTCP addresses and
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
when a port is randomly assigned, it may just randomly happen to 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. deal with both port preservation and no port preservation.
a) Certain applications expect the source UDP port to be in the a) Certain applications expect the source UDP port to be in the
well-known range. See the discussion of Network File System well-known range. See the discussion of Network File System
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.
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
skipping to change at page 11, line 30 skipping to change at page 11, line 46
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.
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
external side of the NAT to the internal side of the NAT. This is external side of the NAT to the internal side of the NAT. This is
referred to as having a NAT Inbound Refresh Behavior of "True". referred to as having a NAT Inbound Refresh Behavior of "True".
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: Outbound refresh is necessary for allowing the client Justification: Outbound refresh is necessary for allowing the client
to keep the mapping alive. to keep the mapping alive.
a) Inbound refresh may be useful for applications with no outgoing a) Inbound refresh may be useful for applications with no outgoing
UDP traffic. However, allowing inbound refresh may allow an UDP traffic. However, allowing inbound refresh may allow an
external attacker or misbehaving application to keep a mapping external attacker or misbehaving application to keep a mapping
alive indefinitely. This may be a security risk. Also, if the alive indefinitely. This may be a security risk. Also, if the
process is repeated with different ports, over time it could process is repeated with different ports, over time it could
use up all the ports on the NAT. use up all the ports on the NAT.
4.4. Conflicting Internal and External IP Address Spaces 4.4. Conflicting Internal and External IP Address Spaces
skipping to change at page 13, line 40 skipping to change at page 14, line 10
external network is directed at the NAT, whereas an IP packet with external network is directed at the NAT, whereas an IP packet with
the same destination address P on the internal network is directed at the same destination address P on the internal network is directed at
node I. The NAT therefore needs to maintain a clear operational node I. The NAT therefore needs to maintain a clear operational
distinction between "external IP addresses" and "internal IP distinction between "external IP addresses" and "internal IP
addresses" to avoid confusing internal node I with its own external addresses" to avoid confusing internal node I with its own external
interface. In general, the NAT needs to allow all internal nodes interface. In general, the NAT needs to allow all internal nodes
(including I) to communicate with all external nodes having public (including I) to communicate with all external nodes having public
(non-RFC 1918) IP addresses or having private IP addresses that do (non-RFC 1918) IP addresses or having private IP addresses that do
not conflict with the addresses used by its internal network. not conflict with the addresses used by its internal network.
REQ-7: A NAT device whose external IP interface can be configured REQ-7: A NAT device whose external IP interface can be configured
dynamically MUST either (1) automatically ensure that its internal dynamically MUST either (1) automatically ensure that its internal
network uses IP addresses that do not conflict with its external network uses IP addresses that do not conflict with its external
network, or (2) be able to translate and forward traffic between network, or (2) be able to translate and forward traffic between
all internal nodes and all external nodes whose IP addresses all internal nodes and all external nodes whose IP addresses
numerically conflicts with the internal network. numerically conflicts with the internal network.
Justification: If a NAT's external and internal interfaces are Justification: If a NAT's external and internal interfaces are
configured with overlapping IP subnets, then there is of course no configured with overlapping IP subnets, then there is of course no
way for an internal host with RFC 1918 IP address Q to initiate a way for an internal host with RFC 1918 IP address Q to initiate a
direct communication session to an external node having the same direct communication session to an external node having the same
RFC 1918 address Q, or to other external nodes with IP addresses RFC 1918 address Q, or to other external nodes with IP addresses
that numerically conflict with the internal subnet. Such nodes that numerically conflict with the internal subnet. Such nodes
can still open communication sessions indirectly via NAT traversal can still open communication sessions indirectly via NAT traversal
techniques, however, with the help of a third-party server such as techniques, however, with the help of a third-party server such as
a STUN server having a public, non-RFC 1918 IP address. In this a STUN server having a public, non-RFC 1918 IP address. In this
case, nodes with conflicting private RFC 1918 addresses on case, nodes with conflicting private RFC 1918 addresses on
opposite sides of the second-level NAT can communicate with each opposite sides of the second-level NAT can communicate with each
skipping to change at page 15, line 7 skipping to change at page 15, line 25
Address and Port Dependent Filtering: Address and Port Dependent Filtering:
This is similar to the previous behavior, except that the This is similar to the previous behavior, except that the
external port is also relevant. The NAT filters out packets external port is also relevant. The NAT filters out packets
not destined for the internal address X:x. Additionally, the not destined for the internal address X:x. Additionally, the
NAT will filter out packets from Y:y destined for the internal NAT will filter out packets from Y:y destined for the internal
endpoint X:x if X:x has not sent packets to Y:y previously. In endpoint X:x if X:x has not sent packets to Y:y previously. In
other words, for receiving packets from a specific external other words, for receiving packets from a specific external
endpoint, it is necessary for the internal endpoint to send endpoint, it is necessary for the internal endpoint to send
packets first to that external endpoint's IP address and port. packets first to that external endpoint's IP address and port.
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 an "Endpoint independent filtering" RECOMMENDED that a NAT have an "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 an "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.
Justification: The recommendation to use Endpoint Independent Justification: The recommendation to use Endpoint Independent
Filtering is aimed at maximizing application transparency, in Filtering is aimed at maximizing application transparency, in
particular for applications that receive media simultaneously from particular for applications that receive media simultaneously from
multiple locations (e.g., gaming), or applications that use multiple locations (e.g., gaming), or applications that use
rendezvous techniques. However, it is also possible that in some rendezvous techniques. However, it is also possible that in some
circumstances, it may be preferable to have a more stringent circumstances, it may be preferable to have a more stringent
filtering behavior. Filtering independently of the external filtering behavior. Filtering independently of the external
endpoint is not as secure: an unauthorized packet could get endpoint is not as secure: an unauthorized packet could get
through a specific port while the port was kept open if it was through a specific port while the port was kept open if it was
lucky enough to find the port open. In theory, filtering based on lucky enough to find the port open. In theory, filtering based on
both IP address and port is more secure than filtering based only both IP address and port is more secure than filtering based only
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'.
Furthermore, the NAT may present the hairpinned packet with either an Furthermore, the NAT may present the hairpinned packet with either an
internal (X1:x1) or an external (X1':x1') source IP address and port. internal (X1:x1) or an external (X1':x1') source IP address and port.
The hairpinning NAT behavior can therefore be either "External source The hairpinning NAT behavior can therefore be either "External source
IP address and port" or "Internal source IP address and port". IP address and port" or "Internal source IP address and port".
"Internal source IP address and port" may cause problems by confusing "Internal source IP address and port" may cause problems by confusing
implementations that expect an external IP address and port. implementations that expect an external IP address and port.
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".
Justification: This requirement is to allow communications between Justification: This requirement is to allow communications between
two endpoints behind the same NAT when they are trying each two endpoints behind the same NAT when they are trying each
other's external IP addresses. other's external IP addresses.
a) Using the external source IP address is necessary for a) Using the external source IP address is necessary for
applications with a restrictive policy of not accepting packets applications with a restrictive policy of not accepting packets
from IP addresses that differ from what is expected. from IP addresses that differ from what is expected.
7. Application Level Gateways 7. Application Level Gateways
Certain NATs have implemented Application Level Gateways (ALGs) for Certain NATs have implemented Application Level Gateways (ALGs) for
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
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
skipping to change at page 18, line 19 skipping to change at page 18, line 40
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-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.
Justification: Non-deterministic NATs are very difficult to Justification: Non-deterministic NATs are very difficult to
troubleshoot because they require more intensive testing. This 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
skipping to change at page 19, line 5 skipping to change at page 19, line 27
described in the paragraph above is referred to as "support ICMP described in the paragraph above is referred to as "support ICMP
Processing". Processing".
There is no significant security advantage to blocking ICMP There is no significant security advantage to blocking ICMP
Destination Unreachable packets. Additionally, blocking ICMP Destination Unreachable packets. Additionally, blocking ICMP
Destination Unreachable packets can interfere with application Destination Unreachable packets can interfere with application
failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and
traceroute. Blocking any ICMP message is discouraged, and blocking traceroute. Blocking any ICMP message is discouraged, and blocking
ICMP Destination Unreachable is strongly discouraged. ICMP Destination Unreachable is strongly discouraged.
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.
Justification: This is easy to do, is used for many things including Justification: This is easy to do, is used for many things including
MTU discovery and rapid detection of error conditions, and has no MTU discovery and rapid detection of error conditions, and has no
negative consequences. negative consequences.
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.
Justification: This is as per RFC 792. Justification: This is as per RFC 792.
a) This is the same function a router performs in a similar a) This is the same function a router performs in a similar
situation [RFC1812]. situation [RFC1812].
11. Receiving Fragmented Packets 11. Receiving Fragmented Packets
For a variety of reasons, a NAT may receive a fragmented packet. The For a variety of reasons, a NAT may receive a fragmented packet. The
IP packet containing the header could arrive in any fragment IP packet containing the header could arrive in any fragment
depending on network conditions, packet ordering, and the depending on network conditions, packet ordering, and the
implementation of the IP stack that generated the fragments. implementation of the IP stack that generated the fragments.
skipping to change at page 20, line 15 skipping to change at page 20, line 36
A NAT that is capable of receiving fragments in or out of order and A NAT that is capable of receiving fragments in or out of order and
forwarding the individual fragments (or a reassembled packet) to the forwarding the individual fragments (or a reassembled packet) to the
internal host is referred to as "Receive Fragments Out of Order". internal host is referred to as "Receive Fragments Out of Order".
See the Security Considerations section of this document for a See the Security Considerations section of this document for a
discussion of this behavior. discussion of this behavior.
A NAT that is neither of these is referred to as "Receive Fragments A NAT that is neither of these is referred to as "Receive Fragments
None". None".
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.
Justification: See Security Considerations. Justification: See Security Considerations.
12. Requirements 12. Requirements
The requirements in this section are aimed at minimizing the The requirements in this section are aimed at minimizing the
complications caused by NATs to applications such as realtime complications caused by NATs to applications such as realtime
communications and online gaming. The requirements listed earlier in communications and online gaming. The requirements listed earlier in
the document are consolidated here into a single section. the document are consolidated here into a single section.
It should be understood, however, that applications normally do not It should be understood, however, that applications normally do not
know in advance if the NAT conforms to the recommendations defined in know in advance if the NAT conforms to the recommendations defined in
this section. Peer-to-peer media applications still need to use this section. Peer-to-peer media applications still need to use
normal procedures such as ICE [I-D.ietf-mmusic-ice]. normal procedures such as ICE [I-D.ietf-mmusic-ice].
A NAT that supports all of the mandatory requirements of this A NAT that supports all of the mandatory requirements of this
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
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 A NAT device whose external IP interface can be configured REQ-7 A NAT device whose external IP interface can be configured
dynamically MUST either (1) Automatically ensure that its internal dynamically MUST either (1) Automatically ensure that its internal
network uses IP addresses that do not conflict with its external network uses IP addresses that do not conflict with its external
network, or (2) Be able to translate and forward traffic between network, or (2) Be able to translate and forward traffic between
all internal nodes and all external nodes whose IP addresses all internal nodes and all external nodes whose IP addresses
numerically conflicts with the internal network. numerically conflicts with the internal network.
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.
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 12 skipping to change at page 24, line 29
peer media applications, especially when those applications are using peer media applications, especially when those applications are using
UNSAF methods. UNSAF methods.
Section 3 of UNSAF lists several practical issues with solutions to Section 3 of UNSAF lists several practical issues with solutions to
NAT problems. This document makes recommendations to reduce the NAT problems. This document makes recommendations to reduce the
uncertainty and problems introduced by these practical issues with uncertainty and problems introduced by these practical issues with
NATs. In addition, UNSAF lists five architectural considerations. NATs. In addition, UNSAF lists five architectural considerations.
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 28, line 15 skipping to change at page 28, line 4
Authors' Addresses Authors' Addresses
Francois Audet (editor) Francois Audet (editor)
Nortel Networks Nortel Networks
4655 Great America Parkway 4655 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
US US
Phone: +1 408 495 3756 Phone: +1 408 495 3756
Email: audet@nortel.com Email: audet@nortel.com
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. 73 change blocks. 
146 lines changed or deleted 163 lines changed or added

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