draft-ietf-behave-nat-udp-04.txt   draft-ietf-behave-nat-udp-05.txt 
BEHAVE F. Audet, Ed. BEHAVE F. Audet, Ed.
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: March 10, 2006 C. Jennings Expires: October 9, 2006 C. Jennings
Cisco Systems Cisco Systems
September 6, 2005 April 7, 2006
NAT Behavioral Requirements for Unicast UDP NAT Behavioral Requirements for Unicast UDP
draft-ietf-behave-nat-udp-04 draft-ietf-behave-nat-udp-05
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 March 10, 2006. This Internet-Draft will expire on October 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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
multimedia communications or on-line gaming, to work consistently. multimedia communications or on-line gaming, to work consistently.
Developing NATs that meet this set of requirements will greatly Developing NATs that meet this set of requirements will greatly
increase the likelihood that these applications will function increase the likelihood that these applications will function
properly. properly.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Address and Port Translation Behavior . . . . . . . . 5 4. Network Address and Port Translation Behavior . . . . . . . . 5
4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5 4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5
4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 8 4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 8
4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 10 4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 10
4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11
4.4. Conflicting Internal and External IP Address Spaces . . . 12 4.4. Conflicting Internal and External IP Address Spaces . . . 12
5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 13 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14
6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15
7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16
8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17
9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18
10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19
10.1. Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 19 10.1. Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 19
10.2. Smaller Network MTU . . . . . . . . . . . . . . . . . . . 19 10.2. Smaller Network MTU . . . . . . . . . . . . . . . . . . . 19
11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25
17.2. Informational References . . . . . . . . . . . . . . . . . 25 17.2. Informational References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 28
skipping to change at page 5, line 29 skipping to change at page 5, line 29
This document uses the term "session" as defined in RFC 2663: "TCP/ This document uses the term "session" as defined in RFC 2663: "TCP/
UDP sessions are uniquely identified by the tuple of (source IP UDP sessions are uniquely identified by the tuple of (source IP
address, source TCP/UDP ports, target IP address, target TCP/UDP address, source TCP/UDP ports, target IP address, target TCP/UDP
Port)." Port)."
This document uses the term "address and port mapping" as the This document uses the term "address and port mapping" as the
translation between an external address and port and an internal translation between an external address and port and an internal
address and port. Note that this is not the same as an "address address and port. Note that this is not the same as an "address
binding" as defined in RFC 2663. binding" as defined in RFC 2663.
RFC 3489 [8] used the terms "Full Cone", "Restricted Cone", "Port RFC 3489 [13] used the terms "Full Cone", "Restricted Cone", "Port
Restricted Cone" and "Symmetric" to refer to different variations of Restricted Cone" and "Symmetric" to refer to different variations of
NATs applicable to UDP only. Unfortunately, this terminology has NATs applicable to UDP only. Unfortunately, this terminology has
been the source of much confusion as it has proven inadequate at been the source of much confusion as it has proven inadequate at
describing real-life NAT behavior. This specification therefore describing real-life NAT behavior. This specification therefore
refers to specific individual NAT behaviors instead of using the refers to specific individual NAT behaviors instead of using the
Cone/Symmetric terminology. Cone/Symmetric terminology.
4. Network Address and Port Translation Behavior 4. Network Address and Port Translation Behavior
This section describes the various NAT behaviors applicable to NATs. This section describes the various NAT behaviors applicable to NATs.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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
from the same internal IP address and port (X:x) to the same from the same internal IP address and port (X:x) to the same
external IP address, regardless of the external port. external IP address, regardless of the external port.
Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals
Y1. Y1.
Address and Port Dependent Mapping: Address and Port Dependent 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 the same from the same internal IP address and port (X:x) to the same
external 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 "External NAT mapping is endpoint REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior.
independent" 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 Media Relay met. Failure to meet REQ-1 will force the use of a Media 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
skipping to change at page 11, line 30 skipping to change at page 11, line 30
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 1 minute,
minutes. unless REQ-5a applies.
a) The value of the NAT UDP mapping timer MAY be configurable. a) A NAT MAY have UDP mapping timers that have much shorter
b) A default value of 5 minutes for the NAT UDP mapping timer is timers, but only for specific ports in the well-known port
range (i.e., ports 0-1023) where the IANA- registered protocol
is strictly a request/response protocol, such as for example
DNS over UDP/53.
b) The value of the NAT UDP mapping timer MAY be configurable.
c) A default value of 5 minutes for the NAT UDP mapping timer is
RECOMMENDED. RECOMMENDED.
Justification: This requirement is to ensure that the timeout is long Justification: This requirement is to ensure that the timeout is long
enough to avoid too frequent timer refresh packets. enough to avoid too frequent timer refresh packets.
a) Configuration is desirable for adapting to specific networks a) Some UDP protocols using UDP use very short-lived connections.
There can be very many such connections; keeping them all in a
connections table could cause considerable load on the NAT.
Having shorter timers for these specific applications is
therefore an optimization technique. It is important that the
shorter timers applied to specific protocols be used sparingly,
and only for protocols using well-known destination port that
are known to have a shorter timer, and that are known not to be
used by any applications for other purposes.
b) Configuration is desirable for adapting to specific networks
and troubleshooting. and troubleshooting.
b) 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".
skipping to change at page 17, line 41 skipping to change at page 17, line 41
For example, if three hosts X1, X2, and X3 all send from the same For example, if three hosts X1, X2, and X3 all send from the same
port x, through a port preserving NAT with only one external IP port x, through a port preserving NAT with only one external IP
address, called X1', the first one to send (i.e., X1) will get an address, called X1', the first one to send (i.e., X1) will get an
external port of x but the next two will get x2' and x3' (where these external port of x but the next two will get x2' and x3' (where these
are not equal to x). There are NATs where the External NAT mapping are not equal to x). There are NATs where the External NAT mapping
characteristics and the External Filter characteristics change characteristics and the External Filter characteristics change
between the X1:x and the X2:x mapping. To make matters worse, there between the X1:x and the X2:x mapping. To make matters worse, there
are NATs where the behavior may be the same on the X1:x and X2:x are NATs where the behavior may be the same on the X1:x and X2:x
mappings but different on the third X3:x mapping. mappings but different on the third X3:x mapping.
Some NATs that try to reuse external ports flow from two internal IP Another example is that some NATs have an "Endpoint Independent
addresses to two different external IP addresses. For example, X1:x Mapping" combined with "Port Overloading" as long as two endpoints
is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not are not establishing sessions to the same external direction, but
equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x then switch their behavior to "Address and Port Dependent Mapping"
to X1':x. This works if the NAT mapping is address port dependent. without "Port Preservation" upon detection of these conflicting
However some NATs change their behavior when this type of port reuse sessions establishments.
is happening. The NAT may look like it has NAT mappings that are
independent when this type of reuse is not happening but may change
to Address Port Dependent when this reuse happens.
Any NAT that changes the NAT mapping or the External Filtering Any NAT that changes the NAT Mapping or the Filtering behavior
without configuration changes, at any point in time under any without configuration changes, at any point in time under any
particular conditions is referred to as a "non-deterministic" NAT. particular conditions is referred to as a "non-deterministic" NAT.
NATs that don't are called "deterministic". NATs that don't are called "deterministic".
Non-deterministic NATs generally change behavior when a conflict of Non-deterministic NATs generally change behavior when a conflict of
some sort happens, i.e. when the port that would normally be used is some sort happens, i.e. when the port that would normally be used is
already in use by another mapping. The NAT mapping and External already in use by another mapping. The NAT mapping and External
Filtering in the absence of conflict is referred to as the Primary Filtering in the absence of conflict is referred to as the Primary
behavior. The behavior after the first conflict is referred to as behavior. The behavior after the first conflict is referred to as
Secondary and after the second conflict is referred to as Tertiary. Secondary and after the second conflict is referred to as Tertiary.
No NATs have been observed that change on further conflicts but it is No NATs have been observed that change on further conflicts but it is
certainly possible that they exist. certainly possible that they exist.
skipping to change at page 19, line 34 skipping to change at page 19, line 34
The first situation is when the MTU of the adjacent link is too The first situation is when the MTU of the adjacent link is too
small. This can occur if the NAT is doing PPPoE, or if the NAT has small. This can occur if the NAT is doing PPPoE, or if the NAT has
been configured with a small MTU to reduce serialization delay when been configured with a small MTU to reduce serialization delay when
sending large packets and small higher-priority packets, or for other sending large packets and small higher-priority packets, or for other
reasons. reasons.
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).
If the packet has DF=1, the NAT SHOULD send back an ICMP message REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP
"fragmentation needed and DF set" message to the host as described in message "fragmentation needed and DF set" message to the host as
RFC 792 [2]. described in RFC 792 [2].
a) If the packet has DF=0, the NAT SHOULD fragment the packet and
If the packet has DF=0, the NAT SHOULD fragment the packet and send send the fragments, in order.
the fragments, in order. This is the same function a router performs Justification: This is as per RFC 792.
in a similar situation RFC 1812 [5]. a) This is the same function a router performs in a similar
situation RFC 1812 [5].
NATs that operate as described in this section are described as
"Supports Fragmentation" (abbreviated SF).
10.2. Smaller Network MTU 10.2. Smaller Network MTU
The second situation is when the MTU on some link in the middle of The second situation is when the MTU on some link in the middle of
the network that is not the adjacent link is too small. If DF=0, the the network that is not the adjacent link is too small. If DF=0, the
router adjacent to the small-MTU segment will fragment the packet and router adjacent to the small-MTU segment will fragment the packet and
forward the fragments as specified in RFC 1812 [5]. forward the fragments as specified in RFC 1812 [5].
If DF=1, the router adjacent to the small-MTU segment will send the If DF=1, the router adjacent to the small-MTU segment will send the
ICMP message "fragmentation needed and DF set" back towards the NAT. ICMP message "fragmentation needed and DF set" back towards the NAT.
skipping to change at page 20, line 7 skipping to change at page 20, line 4
10.2. Smaller Network MTU 10.2. Smaller Network MTU
The second situation is when the MTU on some link in the middle of The second situation is when the MTU on some link in the middle of
the network that is not the adjacent link is too small. If DF=0, the the network that is not the adjacent link is too small. If DF=0, the
router adjacent to the small-MTU segment will fragment the packet and router adjacent to the small-MTU segment will fragment the packet and
forward the fragments as specified in RFC 1812 [5]. forward the fragments as specified in RFC 1812 [5].
If DF=1, the router adjacent to the small-MTU segment will send the If DF=1, the router adjacent to the small-MTU segment will send the
ICMP message "fragmentation needed and DF set" back towards the NAT. ICMP message "fragmentation needed and DF set" back towards the NAT.
The NAT needs to forward this ICMP message to the inside host. The NAT needs to forward this ICMP message to the inside host.
The classification of NATs that perform this behavior is covered in The classification of NATs that perform this behavior is covered in
Section 9. Section 9.
REQ-13: A NAT MUST support fragmentation of packets larger than link REQ-14: A NAT MUST support fragmentation of packets larger than link
MTU. MTU.
Justification: Fragmented packets become more common with large video Justification: Fragmented packets become more common with large video
packets and should continue to work. Applications can use MTU packets and should continue to work. Applications can use MTU
discovery to work around this problem. discovery to work around this problem.
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
skipping to change at page 20, line 40 skipping to change at page 20, line 38
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 packets (or a reassembled packet) to the forwarding the individual packets (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-15: 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
skipping to change at page 21, line 26 skipping to change at page 21, line 20
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 [18]. normal procedures such as ICE [18].
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 "External NAT mapping is endpoint REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior.
independent" behavior.
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"
behavior of "Paired". Note that this requirement is not behavior of "Paired". Note that this requirement is not
applicable to NATs that do not support IP address pooling. applicable to NATs that do not support IP address pooling.
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading". overloading".
a) If the host's source port was in the range 1-1023, it is a) If the host's source port was in the range 1-1023, it is
RECOMMENDED the NAT's source port 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 preservation"
behavior of "Yes". behavior of "Yes".
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 1 minute,
minutes. unless REQ-5a applies.
a) The value of the NAT UDP mapping timer MAY be configurable. a) A NAT MAY have UDP mapping timers that have much shorter
b) A default value of 5 minutes for the NAT UDP mapping timer is timers, but only for specific ports in the well-known port
range (i.e., ports 0-1023) where the IANA- registered protocol
is strictly a request/response protocol, such as for example
DNS over UDP/53.
b) The value of the NAT UDP mapping timer MAY be configurable.
c) A default value of 5 minutes for the NAT UDP mapping timer is
RECOMMENDED. RECOMMENDED.
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
refresh behavior" of "True". refresh behavior" of "True".
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
refresh behavior" of "True". refresh behavior" of "True".
REQ-7 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 do all internal nodes and all external nodes whose IP addresses do
not numerically conflict with the internal network. not numerically conflict 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".
skipping to change at page 22, line 34 skipping to change at page 22, line 28
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 mapping or the External External Filtering Behavior change the NAT mapping or the External External Filtering Behavior
at any point in time or under any particular conditions. at any point in time or under any particular conditions.
REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT
mapping. 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: A NAT MUST support fragmentation of packets larger than link REQ-13 If the packet has DF=1, the NAT SHOULD send back an ICMP
message "fragmentation needed and DF set" message to the host as
described in RFC 792 [2].
a) If the packet has DF=0, the NAT SHOULD fragment the packet and
send the fragments, in order.
REQ-14: A NAT MUST support fragmentation of packets larger than link
MTU. MTU.
REQ-14: A NAT MUST support receiving in order and out of order REQ-15: 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
skipping to change at page 26, line 23 skipping to change at page 26, line 21
RFC 3550, July 2003. RFC 3550, July 2003.
[15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[16] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [16] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
[17] Rosenberg, J., "Simple Traversal of UDP Through Network Address [17] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03
(work in progress), July 2005. (work in progress), March 2006.
[18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-05 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in
progress), July 2005. progress), March 2006.
[19] Jennings, C., "NAT Classification Test Results", [19] Jennings, C., "NAT Classification Test Results",
draft-jennings-behave-test-results-01 (work in progress), draft-jennings-behave-test-results-01 (work in progress),
July 2005. July 2005.
[20] "Packet-based Multimedia Communications Systems", ITU- [20] "Packet-based Multimedia Communications Systems", ITU-
T Recommendation H.323, July 2003. T Recommendation H.323, July 2003.
Authors' Addresses Authors' Addresses
skipping to change at page 28, line 41 skipping to change at page 28, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 29 change blocks. 
53 lines changed or deleted 73 lines changed or added

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