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