draft-ietf-behave-nat-udp-05.txt   draft-ietf-behave-nat-udp-06.txt 
BEHAVE F. Audet, Ed. BEHAVE F. Audet, Ed.
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: October 9, 2006 C. Jennings Expires: November 7, 2006 C. Jennings
Cisco Systems Cisco Systems
April 7, 2006 May 6, 2006
NAT Behavioral Requirements for Unicast UDP NAT Behavioral Requirements for Unicast UDP
draft-ietf-behave-nat-udp-05 draft-ietf-behave-nat-udp-06
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 October 9, 2006. This Internet-Draft will expire on November 7, 2006.
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 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . . 14 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 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 19
10.2. Smaller Network MTU . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 23
15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 17.1. Normative References . . . . . . . . . . . . . . . . . . . 24
17.2. Informational References . . . . . . . . . . . . . . . . . 25 17.2. Informational References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 28
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.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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 RFC 3605 [16] for indicating RTP and RTCP addresses and defined in RFC 3605 [16] for indicating RTP and RTCP addresses and
ports separately, but the other peer does not, there may still be ports separately, but the other peer does not, there may still be
breakage in the form of the stream losing RTP packets. This breakage in the form of the stream losing RTCP packets. This
requirement will avoid the loss of RTP in this context, although requirement will avoid the loss of RTP in this context, although
the loss of RTCP may be inevitable in this particular example. It the loss of RTCP may be inevitable in this particular example. It
is also worth noting that RFC 3605 is unfortunately not a is also worth noting that RFC 3605 is unfortunately not a
mandatory part of SIP (RFC 3261). This requirement will therefore mandatory part of SIP (RFC 3261). This requirement will therefore
address a particularly nasty problem that will prevail for a address a particularly nasty problem that will prevail for a
significant period of time. significant period of time.
4.2. Port Assignment 4.2. Port Assignment
4.2.1. Port Assignment Behavior 4.2.1. Port Assignment Behavior
skipping to change at page 9, line 25 skipping to change at page 9, line 25
preservation even in the case of collision (i.e., X'=X1'=X2' and preservation even in the case of collision (i.e., X'=X1'=X2' and
x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x). x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x).
These NATs rely on the source of the response from the external These NATs rely on the source of the response from the external
endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal
endpoint (X1 or X2). Port overloading fails if the two internal endpoint (X1 or X2). Port overloading fails if the two internal
endpoints are establishing sessions to the same external destination. endpoints are establishing sessions to the same external destination.
Most applications fail in some cases with "Port overloading". It is Most applications fail in some cases with "Port overloading". It is
clear that "Port overloading" behavior will result in many problems. clear that "Port overloading" behavior will result in many problems.
For example it will fail if two internal endpoints try to reach the For example it will fail if two internal endpoints try to reach the
same external destination, e.g., a server used by both endpoints such same external destination, e.g., a SIP proxy server used by both
as a SIP proxy, or a web server, etc. endpoints.
When NATs do allocate a new source port, there is the issue of which When NATs do allocate a new source port, there is the issue of which
IANA-defined range of port to choose. The ranges are "well-known" IANA-defined range of port to choose. The ranges are "well-known"
from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/
private" from 49152 through 65535. For most protocols, these are private" from 49152 through 65535. For most protocols, these are
destination ports and not source ports, so mapping a source port to a destination ports and not source ports, so mapping a source port to a
source port that is already registered is unlikely to have any bad source port that is already registered is unlikely to have any bad
effects. Some NATs may choose to use only the ports in the dynamic effects. Some NATs may choose to use only the ports in the dynamic
range; the only down side of this practice is that it limits the range; the only down side of this practice is that it limits the
number of ports available. Other NAT devices may use everything but number of ports available. Other NAT devices may use everything but
the well-known range and may prefer to use the 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.
It should be noted that port 0 is reserved and must not be used.
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading". overloading".
a) If the host's source port was in the range 1-1023, it is a) If the host's source port was in the range 1-1023, it is
RECOMMENDED the NAT's source port 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
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 1 minute, REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
unless REQ-5a applies. minutes, unless REQ-5a applies.
a) A NAT MAY have UDP mapping timers that have much shorter a) A NAT MAY have UDP mapping timers that have much shorter
timers, but only for specific ports in the well-known port timers, but only for specific ports in the well-known port
range (i.e., ports 0-1023) where the IANA- registered protocol range (i.e., ports 0-1023) where the IANA- registered protocol
is strictly a request/response protocol, such as for example is strictly a request/response protocol, such as for example
DNS over UDP/53. DNS over UDP/53.
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 for the NAT UDP mapping timer is 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
skipping to change at page 18, line 17 skipping to change at page 18, line 17
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 mapping or the External Filtering Behavior at any change the NAT translation (Section 4) or the Filtering
point in time or under any particular conditions. (Section 5) Behavior at any point in time or under any particular
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
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 [3] and RFC1435 [4]), failover, UDP Path MTU Discovery (see RFC1191 [3] and RFC1435 [4]),
and traceroute. Blocking any ICMP message is discouraged, and and traceroute. Blocking any ICMP message is discouraged, and
blocking ICMP Destination Unreachable is strongly discouraged. blocking ICMP Destination Unreachable is strongly discouraged.
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 terminate the
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 sending a packet, there are two situations that may cause IP When the MTU of the adjacent link is too small, fragmentation of
fragmentation for packets from the inside to the outside. It is packets going from the internal side to the external side of the NAT
worth noting that many IP stacks do not use Path MTU Discovery with may occur. This can occur if the NAT is doing PPPoE, or if the NAT
UDP packets. has been configured with a small MTU to reduce serialization delay
when sending large packets and small higher-priority packets, or for
10.1. Smaller Adjacent MTU other reasons.
The first situation is when the MTU of the adjacent link is too It is worth nothing that many IP stacks do not use Path MTU Discovery
small. This can occur if the NAT is doing PPPoE, or if the NAT has with UDP packets.
been configured with a small MTU to reduce serialization delay when
sending large packets and small higher-priority packets, or for other
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).
REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP REQ-13: If the packet received on an internal IP address has DF=1,
message "fragmentation needed and DF set" message to the host as the NAT SHOULD send back an ICMP message "fragmentation needed and
described in RFC 792 [2]. 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 a) If the packet has DF=0, the NAT SHOULD fragment the packet and
send the fragments, in order. 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 RFC 1812 [5]. situation RFC 1812 [5].
10.2. Smaller Network MTU
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
router adjacent to the small-MTU segment will fragment the packet and
forward the fragments as specified in RFC 1812 [5].
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.
The NAT needs to forward this ICMP message to the inside host.
The classification of NATs that perform this behavior is covered in
Section 9.
REQ-14: A NAT MUST support fragmentation of packets larger than link
MTU.
Justification: Fragmented packets become more common with large video
packets and should continue to work. Applications can use MTU
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
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.
A NAT that is capable only of receiving fragments in order (that is, A NAT that is capable only of receiving fragments in order (that is,
with the header in the first packet) and forwarding each of the with the header in the first packet) and forwarding each of the
fragments to the internal host is described as "Received Fragments fragments to the internal host is described as "Received Fragments
skipping to change at page 20, line 38 skipping to change at page 20, line 15
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-15: 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
skipping to change at page 21, line 24 skipping to change at page 21, line 4
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 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 1 minute, REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
unless REQ-5a applies. minutes, unless REQ-5a applies.
a) A NAT MAY have UDP mapping timers that have much shorter a) A NAT MAY have UDP mapping timers that have much shorter
timers, but only for specific ports in the well-known port timers, but only for specific ports in the well-known port
range (i.e., ports 0-1023) where the IANA- registered protocol range (i.e., ports 0-1023) where the IANA- registered protocol
is strictly a request/response protocol, such as for example is strictly a request/response protocol, such as for example
DNS over UDP/53. DNS over UDP/53.
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 for the NAT UDP mapping timer is 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".
skipping to change at page 22, line 20 skipping to change at page 21, line 48
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: If a NAT includes ALGs that affect UDP, it is RECOMMENDED REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
that all of those ALGs be disabled by default. that all of those ALGs be disabled by default.
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
the NAT administrator to enable or disable each ALG separately. the NAT administrator to enable or disable each ALG separately.
REQ-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 translation (Section 4) or the Filtering
at any point in time or under any particular conditions. (Section 5) Behavior at any point in time or under any particular
REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT conditions.
mapping.
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
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 has DF=1, the NAT SHOULD send back an ICMP REQ-13 If the packet received on an internal IP address has DF=1, the
message "fragmentation needed and DF set" message to the host as NAT SHOULD send back an ICMP message "fragmentation needed and DF
described in RFC 792 [2]. 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 a) If the packet has DF=0, the NAT SHOULD fragment the packet and
send the fragments, in order. send the fragments, in order.
REQ-14: A NAT MUST support fragmentation of packets larger than link REQ-14: A NAT MUST support receiving in order and out of order
MTU.
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
 End of changes. 24 change blocks. 
70 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/