idnits 2.17.1 draft-ietf-behave-nat-udp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1261. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2006) is 6539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-03 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-08 == Outdated reference: A later version (-04) exists of draft-jennings-behave-test-results-01 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE F. Audet, Ed. 3 Internet-Draft Nortel Networks 4 Expires: December 2, 2006 C. Jennings 5 Cisco Systems 6 May 31, 2006 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-udp-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines basic terminology for describing different 43 types of NAT behavior when handling Unicast UDP and also defines a 44 set of requirements that would allow many applications, such as 45 multimedia communications or on-line gaming, to work consistently. 46 Developing NATs that meet this set of requirements will greatly 47 increase the likelihood that these applications will function 48 properly. 50 Table of Contents 52 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Network Address and Port Translation Behavior . . . . . . . . 5 56 4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5 57 4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 58 4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 8 59 4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10 60 4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 10 61 4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 62 4.4. Conflicting Internal and External IP Address Spaces . . . 12 63 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14 64 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15 65 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16 66 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17 67 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18 68 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19 69 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 19 70 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 72 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 73 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23 74 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 75 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 17.1. Normative References . . . . . . . . . . . . . . . . . . . 24 77 17.2. Informational References . . . . . . . . . . . . . . . . . 25 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 79 Intellectual Property and Copyright Statements . . . . . . . . . . 29 81 1. Applicability Statement 83 The purpose of this specification is to define a set of requirements 84 for NATs that would allow many applications, such as multimedia 85 communications or on-line gaming, to work consistently. Developing 86 NATs that meet this set of requirements will greatly increase the 87 likelihood that these applications will function properly. 89 The requirements of this specification apply to Traditional NATs as 90 described in [RFC2663]. 92 This document is meant to cover NATs of any size, from small 93 residential NATs to large Enterprise NATs. However, it should be 94 understood that Enterprise NATs normally provide much more than just 95 NAT capabilities: for example, they typically provide firewall 96 functionalities. Firewalls are specifically out-of-scope for this 97 specification; however, this specification does cover the inherent 98 filtering aspects of NATs which may resemble firewall operation. 100 Approaches using directly signaled control of middle boxes are out of 101 scope. 103 UDP Relays (e.g., TURN [I-D.ietf-behave-turn]) are out-of-scope. 105 Application aspects are out-of-scope, as the focus here is strictly 106 on the NAT itself. 108 This document only covers aspects of NAT traversal related to Unicast 109 UDP [RFC0768] over IP [RFC0791] and their dependencies on other 110 protocols. 112 2. Introduction 114 Network Address Translators (NATs) are well known to cause very 115 significant problems with applications that carry IP addresses in the 116 payload (see [RFC3027]). Applications that suffer from this problem 117 include Voice Over IP and Multimedia Over IP (e.g., SIP [RFC3261] and 118 H.323 [ITU.H323]), as well as online gaming. 120 Many techniques are used to attempt to make realtime multimedia 121 applications, online games, and other applications work across NATs. 122 Application Level Gateways [RFC2663] are one such mechanism. STUN 123 [I-D.ietf-behave-rfc3489bis] describes a UNilateral Self-Address 124 Fixing (UNSAF) mechanism [RFC3424]. Teredo [RFC4380] describes an 125 UNSAF mechanism consisting of tunnelling IPv6 [RFC2460] over UDP/ 126 IPv4. UDP Relays have also been used to enable applications across 127 NATs, but these are generally seen as a solution of last resort. ICE 129 [I-D.ietf-mmusic-ice] describes a methodology for using many of these 130 techniques and avoiding a UDP relay unless the type of NAT is such 131 that it forces the use of such a UDP relay. This specification 132 defines requirements for improving NATs. Meeting these requirements 133 ensures that applications will not be forced to use UDP relay. 135 As pointed out in UNSAF [RFC3424], "From observations of deployed 136 networks, it is clear that different NAT box implementations vary 137 widely in terms of how they handle different traffic and addressing 138 cases." This wide degree of variability is one factor in the overall 139 brittleness introduced by NATs and makes it extremely difficult to 140 predict how any given protocol will behave on a network traversing 141 NAT. Discussions with many of the major NAT vendors have made it 142 clear that they would prefer to deploy NATs that were deterministic 143 and caused the least harm to applications while still meeting the 144 requirements that caused their customers to deploy NATs in the first 145 place. The problem NAT vendors face is that they are not sure how 146 best to do that or how to document how their NATs behave. 148 The goals of this document are to define a set of common terminology 149 for describing the behavior of NATs and to produce a set of 150 requirements on a specific set of behaviors for NATs. 152 This document forms a common set of requirements that are simple and 153 useful for voice, video, and games, which can be implemented by NAT 154 vendors. This document will simplify the analysis of protocols for 155 deciding whether or not they work in this environment and will allow 156 providers of services that have NAT traversal issues to make 157 statements about where their applications will work and where they 158 will not, as well as to specify their own NAT requirements. 160 3. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 Readers are urged to refer to [RFC2663] for information on NAT 167 taxonomy and terminology. Traditional NAT is the most common type of 168 NAT device deployed. Readers may refer to [RFC3022] for detailed 169 information on traditional NAT. Traditional NAT has two main 170 varieties - Basic NAT and Network Address/Port Translator (NAPT). 172 NAPT is by far the most commonly deployed NAT device. NAPT allows 173 multiple internal hosts to share a single public IP address 174 simultaneously. When an internal host opens an outgoing TCP or UDP 175 session through a NAPT, the NAPT assigns the session a public IP 176 address and port number, so that subsequent response packets from the 177 external endpoint can be received by the NAPT, translated, and 178 forwarded to the internal host. The effect is that the NAPT 179 establishes a NAT session to translate the (private IP address, 180 private port number) tuple to (public IP address, public port number) 181 tuple and vice versa for the duration of the session. An issue of 182 relevance to peer-to-peer applications is how the NAT behaves when an 183 internal host initiates multiple simultaneous sessions from a single 184 (private IP, private port) endpoint to multiple distinct endpoints on 185 the external network. In this specification, the term "NAT" refers 186 to both "Basic NAT" and "Network Address/Port Translator (NAPT)". 188 This document uses the term "session" as defined in RFC 2663: "TCP/ 189 UDP sessions are uniquely identified by the tuple of (source IP 190 address, source TCP/UDP ports, target IP address, target TCP/UDP 191 Port)." 193 This document uses the term "address and port mapping" as the 194 translation between an external address and port and an internal 195 address and port. Note that this is not the same as an "address 196 binding" as defined in RFC 2663. 198 This document uses IANA terminology for port ranges, i.e., "Well 199 Known Ports" is 0-1023, "Registered" is 1024-49151, and "Dynamic 200 and/or Private" is 49152-65535, as defined in 201 http://www.iana.org/assignments/port-numbers. 203 STUN [RFC3489] used the terms "Full Cone", "Restricted Cone", "Port 204 Restricted Cone" and "Symmetric" to refer to different variations of 205 NATs applicable to UDP only. Unfortunately, this terminology has 206 been the source of much confusion as it has proven inadequate at 207 describing real-life NAT behavior. This specification therefore 208 refers to specific individual NAT behaviors instead of using the 209 Cone/Symmetric terminology. 211 4. Network Address and Port Translation Behavior 213 This section describes the various NAT behaviors applicable to NATs. 215 4.1. Address and Port Mapping 217 When an internal endpoint opens an outgoing session through a NAT, 218 the NAT assigns the session an external IP address and port number so 219 that subsequent response packets from the external endpoint can be 220 received by the NAT, translated, and forwarded to the internal 221 endpoint. This is a mapping between an internal IP address and port 222 IP:port and external IP:port tuple. It establishes the translation 223 that will be performed by the NAT for the duration of the session. 224 For many applications, it is important to distinguish the behavior of 225 the NAT when there are multiple simultaneous sessions established to 226 different external endpoints. 228 The key behavior to describe is the criteria for re-use of a mapping 229 for new sessions to external endpoints, after establishing a first 230 mapping between an internal X:x address and port and an external 231 Y1:y1 address tuple. Let's assume that the internal IP address and 232 port X:x is mapped to X1':x1' for this first session. The endpoint 233 then sends from X:x to an external address Y2:y2 and gets a mapping 234 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 235 for various combinations of the relationship between Y1:y1 and Y2:y2 236 is critical for describing the NAT behavior. This arrangement is 237 illustrated in the following diagram: 239 E 240 +------+ +------+ x 241 | Y1 | | Y2 | t 242 +--+---+ +---+--+ e 243 | Y1:y1 Y2:y2 | r 244 +----------+ +----------+ n 245 | | a 246 X1':x1' | | X2':x2' l 247 +--+---+-+ 248 ...........| NAT |............... 249 +--+---+-+ I 250 | | n 251 X:x | | X:x t 252 ++---++ e 253 | X | r 254 +-----+ n 255 a 256 l 258 The following address and port mapping behavior are defined: 260 Endpoint Independent Mapping: 261 The NAT reuses the port mapping for subsequent packets sent 262 from the same internal IP address and port (X:x) to any 263 external IP address and port. Specifically, X1':x1' equals 264 X2':x2' for all values of Y2:y2. 266 Address Dependent Mapping: 267 The NAT reuses the port mapping for subsequent packets sent 268 from the same internal IP address and port (X:x) to the same 269 external IP address, regardless of the external port. 270 Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals 271 Y1. 273 Address and Port Dependent Mapping: 274 The NAT reuses the port mapping for subsequent packets sent 275 from the same internal IP address and port (X:x) to the same 276 external IP address and port while the mapping is still active. 277 Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 278 equals Y1:y1. 280 It is important to note that these three possible choices make no 281 difference to the security properties of the NAT. The security 282 properties are fully determined by which packets the NAT allows in 283 and which it does not. This is determined by the filtering behavior 284 in the filtering portions of the NAT. 286 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior. 288 Justification: In order for UNSAF methods to work, REQ-1 needs to be 289 met. Failure to meet REQ-1 will force the use of a UDP relay 290 which is very often impractical. 292 Some NATs are capable of assigning IP addresses from a pool of IP 293 addresses on the external side of the NAT, as opposed to just a 294 single IP address. This is especially common with larger NATs. Some 295 NATs use the external IP address mapping in an arbitrary fashion 296 (i.e. randomly): one internal IP address could have multiple external 297 IP address mappings active at the same time for different sessions. 298 These NATs have an "IP address pooling" behavior of "Arbitrary". 299 Some large Enterprise NATs use an IP address pooling behavior of 300 "Arbitrary" as a means of hiding the IP address assigned to specific 301 endpoints by making their assignment less predictable. Other NATs 302 use the same external IP address mapping for all sessions associated 303 with the same internal IP address. These NATs have an "IP address 304 pooling" behavior of "Paired." NATs that use an "IP address pooling" 305 behavior of "arbitrary" can cause issues for applications that use 306 multiple ports from the same endpoint but do not negotiate IP 307 addresses individually (e.g., some applications using RTP and RTCP). 309 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 310 behavior of "Paired". Note that this requirement is not 311 applicable to NATs that do not support IP address pooling. 313 Justification: This will allow applications that use multiple ports 314 originating from the same internal IP address to also have the 315 same external IP address. This is to avoid breaking peer-to-peer 316 applications that are not capable of negotiating the IP address 317 for RTP and the IP address for RTCP separately. As such it is 318 envisioned that this requirement will become less important as 319 applications become NAT-friendlier with time. The main reason why 320 this requirement is here is that in a peer-to-peer application, 321 you are subject to the other peer's mistake. In particular, in 322 the context of SIP, if my application supports the extensions 323 defined in [RFC3605] for indicating RTP and RTCP addresses and 324 ports separately, but the other peer does not, there may still be 325 breakage in the form of the stream losing RTCP packets. This 326 requirement will avoid the loss of RTP in this context, although 327 the loss of RTCP may be inevitable in this particular example. It 328 is also worth noting that RFC 3605 is unfortunately not a 329 mandatory part of SIP (RFC 3261). This requirement will therefore 330 address a particularly nasty problem that will prevail for a 331 significant period of time. 333 4.2. Port Assignment 335 4.2.1. Port Assignment Behavior 337 This section uses the following diagram for reference. 339 E 340 +-------+ +-------+ x 341 | Y1 | | Y2 | t 342 +---+---+ +---+---+ e 343 | Y1:y1 Y2:y2 | r 344 +---------+ +---------+ n 345 | | a 346 X1':x1' | | X2':x2' l 347 +--+---+--+ 348 ...........| NAT |............... 349 +--+---+--+ I 350 | | n 351 +---------+ +---------+ t 352 | X1:x1 X2':x2 | e 353 +---+---+ +---+---+ r 354 | X1 | | X2 | n 355 +-------+ +-------+ a 356 l 358 Some NATs attempt to preserve the port number used internally when 359 assigning a mapping to an external IP address and port (e.g., 360 x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A 361 basic NAT, for example, will preserve the same port and will assign a 362 different IP address from a pool of external IP addresses in case of 363 port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only 364 possible as long as the NAT has enough external IP addresses. If the 365 port x is already in use on all available external IP addresses, then 366 the NAT needs to switch from Basic NAT to Network Address and Port 367 Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or 368 a mapping of X1:x to X':x1' and X2:x to X':x2'). This port 369 assignment behavior is referred to as "port preservation". It does 370 not guarantee that the external port x' will always be the same as 371 the internal port x but only that the NAT will preserve the port if 372 possible. 374 A NAT that does not attempt to make the external port numbers match 375 the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to 376 X':x2') is referred to as "No port preservation". 378 Some NATs use "Port overloading", i.e. they always use port 379 preservation even in the case of collision (i.e., X'=X1'=X2' and 380 x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x). 381 These NATs rely on the source of the response from the external 382 endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal 383 endpoint (X1 or X2). Port overloading fails if the two internal 384 endpoints are establishing sessions to the same external destination. 386 Most applications fail in some cases with "Port overloading". It is 387 clear that "Port overloading" behavior will result in many problems. 388 For example it will fail if two internal endpoints try to reach the 389 same external destination, e.g., a SIP proxy server used by both 390 endpoints. 392 When NATs do allocate a new source port, there is the issue of which 393 IANA-defined range of port to choose. The ranges are "well-known" 394 from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ 395 private" from 49152 through 65535. For most protocols, these are 396 destination ports and not source ports, so mapping a source port to a 397 source port that is already registered is unlikely to have any bad 398 effects. Some NATs may choose to use only the ports in the dynamic 399 range; the only down side of this practice is that it limits the 400 number of ports available. Other NAT devices may use everything but 401 the well-known range and may prefer to use the dynamic range first or 402 possibly avoid the actual registered ports in the registered range. 403 Other NATs preserve the port range if it is in the well-known range. 405 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 406 overloading". 407 a) If the host's source port was in the range 1-1023, it is 408 RECOMMENDED the NAT's source port be in the same range. If the 409 host's source port was in the range 1024-65535, it is 410 RECOMMENDED that the NAT's source port be in that range. 412 Justification: This requirement must be met in order to enable two 413 applications on the internal side of the NAT both to use the same 414 port to try to communicate with the same destination. NATs that 415 implement port preservation have to deal with conflicts on ports, 416 and the multiple code paths this introduces often result in 417 nondeterministic behavior. However, it should be understood that 418 when a port is randomly assigned, it may just randomly happen to 419 be assigned the same port. Applications must therefore be able to 420 deal with both port preservation and no port preservation. 421 a) Certain applications expect the source UDP port to be in the 422 well-known range. See the discussion of Network File System 423 port expectations in [RFC2623] for an example. 425 4.2.2. Port Parity 427 Some NATs preserve the parity of the UDP port, i.e., an even port 428 will be mapped to an even port, and an odd port will be mapped to an 429 odd port. This behavior respects the [RFC3550] rule that RTP use 430 even ports, and RTCP use odd ports. RFC 3550 allows any port numbers 431 to be used for RTP and RTCP if the two numbers are specified 432 separately, for example using [RFC3605]. However, some 433 implementations do not include RFC 3605 and do not recognize when the 434 peer has specified the RTCP port separately using RFC 3605. If such 435 an implementation receives an odd RTP port number from the peer 436 (perhaps after having been translated by a NAT), and then follows the 437 RFC 3550 rule to change the RTP port to the next lower even number, 438 this would obviously result in the loss of RTP. NAT-friendly 439 application aspects are outside the scope of this document. It is 440 expected that this issue will fade away with time, as implementations 441 improve. Preserving the port parity allows for supporting 442 communication with peers that do not support explicit specification 443 of both RTP and RTCP port numbers. 445 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 446 behavior of "Yes". 448 Justification: This is to avoid breaking peer-to-peer applications 449 which do not explicitly and separately specify RTP and RTCP port 450 numbers and which follow the RFC 3550 rule to decrement an odd RTP 451 port to make it even. The same considerations as per the IP 452 address pooling requirement apply. 454 4.2.3. Port Contiguity 456 Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. 457 These NATs do things like sequential assignment or port reservation. 458 Sequential port assignment assumes that the application will open a 459 mapping for RTP first and then open a mapping for RTCP. It is not 460 practical to enforce this requirement on all applications. 461 Furthermore, there is a problem with glare if many applications (or 462 endpoints) are trying to open mapping simultaneously. Port 463 preservation is also problematic since it is wasteful, especially 464 considering that a NAT cannot reliably distinguish between RTP over 465 UDP and other UDP packets where there is no contiguity rule. For 466 those reasons, it would be too complex to attempt to preserve the 467 contiguity rule by suggesting specific NAT behavior, and it would 468 certainly break the deterministic behavior rule. 470 In order to support both RTP and RTCP, it will therefore be necessary 471 that applications follow rules to negotiate RTP and RTCP separately, 472 and account for the very real possibility that the RTCP=RTP+1 rule 473 will be broken. As this is an application requirement, it is outside 474 of the scope of this document. 476 4.3. Mapping Refresh 478 NAT mapping timeout implementations vary but include the timer's 479 value and the way the mapping timer is refreshed to keep the mapping 480 alive. 482 The mapping timer is defined as the time a mapping will stay active 483 without packets traversing the NAT. There is great variation in the 484 values used by different NATs. 486 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 487 minutes, unless REQ-5a applies. 488 a) For specific destination ports in the well-known port range 489 (ports 0-1023), a NAT MAY have shorter UDP mapping timers that 490 are specific to the IANA-registered application running over 491 that specific destination port. 492 b) The value of the NAT UDP mapping timer MAY be configurable. 493 c) A default value of 5 minutes or more for the NAT UDP mapping 494 timer is RECOMMENDED. 496 Justification: This requirement is to ensure that the timeout is long 497 enough to avoid too frequent timer refresh packets. 498 a) Some UDP protocols using UDP use very short-lived connections. 499 There can be very many such connections; keeping them all in a 500 connections table could cause considerable load on the NAT. 501 Having shorter timers for these specific applications is 502 therefore an optimization technique. It is important that the 503 shorter timers applied to specific protocols be used sparingly, 504 and only for protocols using well-known destination port that 505 are known to have a shorter timer, and that are known not to be 506 used by any applications for other purposes. 508 b) Configuration is desirable for adapting to specific networks 509 and troubleshooting. 510 c) This default is to avoid too frequent timer refresh packets. 512 Some NATs keep the mapping active (i.e., refresh the timer value) 513 when a packet goes from the internal side of the NAT to the external 514 side of the NAT. This is referred to as having a NAT Outbound 515 refresh behavior of "True". 517 Some NATs keep the mapping active when a packet goes from the 518 external side of the NAT to the internal side of the NAT. This is 519 referred to as having a NAT Inbound Refresh Behavior of "True". 521 Some NATs keep the mapping active on both, in which case both 522 properties are "True". 524 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 525 refresh behavior" of "True". 526 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 527 refresh behavior" of "True". 529 Justification: Outbound refresh is necessary for allowing the client 530 to keep the mapping alive. 531 a) Inbound refresh may be useful for applications with no outgoing 532 UDP traffic. However, allowing inbound refresh may allow an 533 external attacker or misbehaving application to keep a mapping 534 alive indefinitely. This may be a security risk. Also, if the 535 process is repeated with different ports, over time it could 536 use up all the ports on the NAT. 538 4.4. Conflicting Internal and External IP Address Spaces 540 Many NATs, particularly consumer-level devices designed to be 541 deployed by nontechnical users, routinely obtain their external IP 542 address, default router, and other IP configuration information for 543 their external interface dynamically from an external network such as 544 an upstream ISP. The NAT in turn automatically sets up its own 545 internal subnet in one of the private IP address spaces assigned to 546 this purpose in [RFC1918], typically providing dynamic IP 547 configuration services for hosts on this internal network. 549 Auto-configuration of NATs and private networks can be problematic, 550 however, if the NAT's external network is also in RFC 1918 private 551 address space. In a common scenario, an ISP places its customers 552 behind a NAT and hands out private RFC 1918 addresses to them. Some 553 of these customers in turn deploy consumer-level NATs, which in 554 effect act as "second-level" NATs, multiplexing their own private RFC 555 1918 IP subnets onto the single RFC 1918 IP address provided by the 556 ISP. There is no inherent guarantee in this case that the ISP's 557 "intermediate" privately-addressed network and the customer's 558 internal privately-addressed network will not use numerically 559 identical or overlapping RFC 1918 IP subnets. Customers of consumer- 560 level NATs further cannot be expected to have the technical knowledge 561 to prevent this scenario from occurring by manually configuring their 562 internal network with non-conflicting RFC 1918 subnets. 564 NAT vendors need to design their NATs to ensure that they function 565 correctly and robustly even in such problematic scenarios. One 566 possible solution is for the NAT to ensure that whenever its external 567 link is configured with an RFC 1918 private IP address, the NAT 568 automatically selects a different, non-conflicting RFC 1918 IP subnet 569 for its internal network. A disadvantage of this solution is that if 570 the NAT's external interface is dynamically configured or re- 571 configured after its internal network is already in use, then the NAT 572 may have to renumber its entire internal network dynamically if it 573 detects a conflict. 575 An alternative solution is for the NAT to be designed so that it can 576 translate and forward traffic correctly even when its external and 577 internal interfaces are configured with numerically overlapping IP 578 subnets. In this scenario, for example, if the NAT's external 579 interface has been assigned an IP address P in RFC 1918 space, then 580 there might also be an internal node I having the same RFC 1918 581 private IP address P. An IP packet with destination address P on the 582 external network is directed at the NAT, whereas an IP packet with 583 the same destination address P on the internal network is directed at 584 node I. The NAT therefore needs to maintain a clear operational 585 distinction between "external IP addresses" and "internal IP 586 addresses" to avoid confusing internal node I with its own external 587 interface. In general, the NAT needs to allow all internal nodes 588 (including I) to communicate with all external nodes having public 589 (non-RFC 1918) IP addresses or having private IP addresses that do 590 not conflict with the addresses used by its internal network. 592 REQ-7: A NAT device whose external IP interface can be configured 593 dynamically MUST either (1) automatically ensure that its internal 594 network uses IP addresses that do not conflict with its external 595 network, or (2) be able to translate and forward traffic between 596 all internal nodes and all external nodes whose IP addresses 597 numerically conflicts with the internal network. 599 Justification: If a NAT's external and internal interfaces are 600 configured with overlapping IP subnets, then there is of course no 601 way for an internal host with RFC 1918 IP address Q to initiate a 602 direct communication session to an external node having the same 603 RFC 1918 address Q, or to other external nodes with IP addresses 604 that numerically conflict with the internal subnet. Such nodes 605 can still open communication sessions indirectly via NAT traversal 606 techniques, however, with the help of a third-party server such as 607 a STUN server having a public, non-RFC 1918 IP address. In this 608 case, nodes with conflicting private RFC 1918 addresses on 609 opposite sides of the second-level NAT can communicate with each 610 other via their respective temporary public endpoints on the main 611 Internet, as long as their common first-level NAT (e.g., the 612 upstream ISP's NAT) supports hairpinning behavior as described in 613 Section 6. 615 5. Filtering Behavior 617 This section describes various filtering behaviors observed in NATs. 619 When an internal endpoint opens an outgoing session through a NAT, 620 the NAT assigns a filtering rule for the mapping between an internal 621 IP:port (X:x) and external IP:port (Y:y) tuple. 623 The key behavior to describe is what criteria are used by the NAT to 624 filter packets originating from specific external endpoints. 626 Endpoint Independent Filtering: 627 The NAT filters out only packets not destined to the internal 628 address and port X:x, regardless of the external IP address and 629 port source (Z:z). The NAT forwards any packets destined to 630 X:x. In other words, sending packets from the internal side of 631 the NAT to any external IP address is sufficient to allow any 632 packets back to the internal endpoint. 634 Address Dependent Filtering: 635 The NAT filters out packets not destined to the internal 636 address X:x. Additionally, the NAT will filter out packets 637 from Y:y destined for the internal endpoint X:x if X:x has not 638 sent packets to Y:any previously (independently of the port 639 used by Y). In other words, for receiving packets from a 640 specific external endpoint, it is necessary for the internal 641 endpoint to send packets first to that specific external 642 endpoint's IP address. 644 Address and Port Dependent Filtering: 645 This is similar to the previous behavior, except that the 646 external port is also relevant. The NAT filters out packets 647 not destined for the internal address X:x. Additionally, the 648 NAT will filter out packets from Y:y destined for the internal 649 endpoint X:x if X:x has not sent packets to Y:y previously. In 650 other words, for receiving packets from a specific external 651 endpoint, it is necessary for the internal endpoint to send 652 packets first to that external endpoint's IP address and port. 654 REQ-8: If application transparency is most important, it is 655 RECOMMENDED that a NAT have an "Endpoint independent filtering" 656 behavior. If a more stringent filtering behavior is most 657 important, it is RECOMMENDED that a NAT have an "Address dependent 658 filtering" behavior. 659 a) The filtering behavior MAY be an option configurable by the 660 administrator of the NAT. 662 Justification: The recommendation to use Endpoint Independent 663 Filtering is aimed at maximizing application transparency, in 664 particular for applications that receive media simultaneously from 665 multiple locations (e.g., gaming), or applications that use 666 rendezvous techniques. However, it is also possible that in some 667 circumstances, it may be preferable to have a more stringent 668 filtering behavior. Filtering independently of the external 669 endpoint is not as secure: an unauthorized packet could get 670 through a specific port while the port was kept open if it was 671 lucky enough to find the port open. In theory, filtering based on 672 both IP address and port is more secure than filtering based only 673 on the IP address (because the external endpoint could in reality 674 be two endpoints behind another NAT, where one of the two 675 endpoints is an attacker): however, such a policy could interfere 676 with applications that expect to receive UDP packets on more than 677 one UDP port. Using Endpoint Independent Filtering or Address 678 Dependent Filtering instead of Address and Port Dependent 679 Filtering on a NAT (say NAT-A) also has benefits when the other 680 endpoint is behind a non-BEHAVE compliant NAT (say NAT-B) that 681 does not support REQ-1. When the endpoints use ICE, if NAT-A uses 682 Address and Port Dependent Filtering, connectivity will require a 683 UDP relay. However, if NAT-A uses Endpoint Independent Filtering 684 or Address Dependent Filtering, ICE will ultimately find 685 connectivity without requiring a UDP relay. Having the filtering 686 behavior being an option configurable by the administrator of the 687 NAT ensures that a NAT can be used in the widest variety of 688 deployment scenarios. 690 6. Hairpinning Behavior 692 If two hosts (called X1 and X2) are behind the same NAT and 693 exchanging traffic, the NAT may allocate an address on the outside of 694 the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it 695 goes to the NAT, which must relay the traffic from X1 to X2. This is 696 referred to as hairpinning and is illustrated below. 698 NAT 699 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 700 | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 701 +----+ | v | 702 | v | 703 | v | 704 | v | 705 +----+ from X1':x1' to X2:x2 | v | X2':x2' 706 | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 707 +----+ +-----+ 709 Hairpinning allows two endpoints on the internal side of the NAT to 710 communicate even if they only use each other's external IP addresses 711 and ports. 713 More formally, a NAT that supports hairpinning forwards packets 714 originating from an internal address, X1:x1, destined for an external 715 address X2':x2' that has an active mapping to an internal address 716 X2:x2, back to that internal address X2:x2. Note that typically X1' 717 is the same as X2'. 719 Furthermore, the NAT may present the hairpinned packet with either an 720 internal (X1:x1) or an external (X1':x1') source IP address and port. 721 The hairpinning NAT behavior can therefore be either "External source 722 IP address and port" or "Internal source IP address and port". 723 "Internal source IP address and port" may cause problems by confusing 724 implementations that expect an external IP address and port. 726 REQ-9: A NAT MUST support "Hairpinning". 727 a) A NAT Hairpinning behavior MUST be "External source IP address 728 and port". 730 Justification: This requirement is to allow communications between 731 two endpoints behind the same NAT when they are trying each 732 other's external IP addresses. 733 a) Using the external source IP address is necessary for 734 applications with a restrictive policy of not accepting packets 735 from IP addresses that differ from what is expected. 737 7. Application Level Gateways 739 Certain NATs have implemented Application Level Gateways (ALGs) for 740 various protocols, including protocols for negotiating peer-to-peer 741 sessions such as SIP. 743 Certain NATs have these ALGs turned on permanently, others have them 744 turned on by default but let them be be turned off, and others have 745 them turned off by default but let them be turned on. 747 NAT ALGs may interfere with UNSAF methods or protocols that try to be 748 NAT-aware and must therefore be used with extreme caution. 750 REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms 751 and allow integrity protection of UDP communications, NAT ALGs for 752 UDP-based protocols SHOULD be turned off. Future standards track 753 specifications that define an ALG can update this to recommend 754 that the ALGs they define default on. 755 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 756 the NAT administrator to enable or disable each ALG separately. 758 Justification: NAT ALGs may interfere with UNSAF methods. 759 a) This requirement allows the user to enable those ALGs that are 760 necessary to aid in the operation of some applications without 761 enabling ALGs which interfere with the operation of other 762 applications. 764 8. Deterministic Properties 766 The classification of NATs is further complicated by the fact that 767 under some conditions the same NAT will exhibit different behaviors. 768 This has been seen on NATs that preserve ports or have specific 769 algorithms for selecting a port other than a free one. If the 770 external port that the NAT wishes to use is already in use by another 771 session, the NAT must select a different port. This results in 772 different code paths for this conflict case, which results in 773 different behavior. 775 For example, if three hosts X1, X2, and X3 all send from the same 776 port x, through a port preserving NAT with only one external IP 777 address, called X1', the first one to send (i.e., X1) will get an 778 external port of x but the next two will get x2' and x3' (where these 779 are not equal to x). There are NATs where the External NAT mapping 780 characteristics and the External Filter characteristics change 781 between the X1:x and the X2:x mapping. To make matters worse, there 782 are NATs where the behavior may be the same on the X1:x and X2:x 783 mappings but different on the third X3:x mapping. 785 Another example is that some NATs have an "Endpoint Independent 786 Mapping" combined with "Port Overloading" as long as two endpoints 787 are not establishing sessions to the same external direction, but 788 then switch their behavior to "Address and Port Dependent Mapping" 789 without "Port Preservation" upon detection of these conflicting 790 sessions establishments. 792 Any NAT that changes the NAT Mapping or the Filtering behavior 793 without configuration changes, at any point in time under any 794 particular conditions is referred to as a "non-deterministic" NAT. 795 NATs that don't are called "deterministic". 797 Non-deterministic NATs generally change behavior when a conflict of 798 some sort happens, i.e. when the port that would normally be used is 799 already in use by another mapping. The NAT mapping and External 800 Filtering in the absence of conflict is referred to as the Primary 801 behavior. The behavior after the first conflict is referred to as 802 Secondary and after the second conflict is referred to as Tertiary. 803 No NATs have been observed that change on further conflicts but it is 804 certainly possible that they exist. 806 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 807 change the NAT translation (Section 4) or the Filtering 808 (Section 5) Behavior at any point in time or under any particular 809 conditions. 811 Justification: Non-deterministic NATs are very difficult to 812 troubleshoot because they require more intensive testing. This 813 non-deterministic behavior is the root cause of much of the 814 uncertainty that NATs introduce about whether or not applications 815 will work. 817 9. ICMP Destination Unreachable Behavior 819 When a NAT sends a packet towards a host on the other side of the 820 NAT, an ICMP message may be sent in response to that packet. That 821 ICMP message may be sent by the destination host or by any router 822 along the network path. The NAT's default configuration SHOULD NOT 823 filter ICMP messages based on their source IP address. Such ICMP 824 messages SHOULD be rewritten by the NAT (specifically the IP headers 825 and the ICMP payload) and forwarded to the appropriate internal or 826 external host. The NAT needs to perform this function for as long as 827 the UDP mapping is active. Receipt of any sort of ICMP message MUST 828 NOT destroy the NAT mapping. A NAT which performs the functions 829 described in the paragraph above is referred to as "support ICMP 830 Processing". 832 There is no significant security advantage to blocking ICMP 833 Destination Unreachable packets. Additionally, blocking ICMP 834 Destination Unreachable packets can interfere with application 835 failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and 836 traceroute. Blocking any ICMP message is discouraged, and blocking 837 ICMP Destination Unreachable is strongly discouraged. 839 REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the 840 NAT mapping. 841 a) The NAT's default configuration SHOULD NOT filter ICMP messages 842 based on their source IP address. 843 b) It is RECOMMENDED that a NAT support ICMP Destination 844 Unreachable messages. 846 Justification: This is easy to do, is used for many things including 847 MTU discovery and rapid detection of error conditions, and has no 848 negative consequences. 850 10. Fragmentation of Outgoing Packets 852 When the MTU of the adjacent link is too small, fragmentation of 853 packets going from the internal side to the external side of the NAT 854 may occur. This can occur if the NAT is doing PPPoE, or if the NAT 855 has been configured with a small MTU to reduce serialization delay 856 when sending large packets and small higher-priority packets, or for 857 other reasons. 859 It is worth nothing that many IP stacks do not use Path MTU Discovery 860 with UDP packets. 862 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 863 (DF=0). 865 REQ-13: If the packet received on an internal IP address has DF=1, 866 the NAT MUST send back an ICMP message "fragmentation needed and 867 DF set" message to the host as described in [RFC0792]. 868 a) If the packet has DF=0, the NAT MUST fragment the packet and 869 SHOULD send the fragments in order. 871 Justification: This is as per RFC 792. 872 a) This is the same function a router performs in a similar 873 situation [RFC1812]. 875 11. Receiving Fragmented Packets 877 For a variety of reasons, a NAT may receive a fragmented packet. The 878 IP packet containing the header could arrive in any fragment 879 depending on network conditions, packet ordering, and the 880 implementation of the IP stack that generated the fragments. 882 A NAT that is capable only of receiving fragments in order (that is, 883 with the header in the first packet) and forwarding each of the 884 fragments to the internal host is described as "Received Fragments 885 Ordered". 887 A NAT that is capable of receiving fragments in or out of order and 888 forwarding the individual fragments (or a reassembled packet) to the 889 internal host is referred to as "Receive Fragments Out of Order". 890 See the Security Considerations section of this document for a 891 discussion of this behavior. 893 A NAT that is neither of these is referred to as "Receive Fragments 894 None". 896 REQ-14: A NAT MUST support receiving in order and out of order 897 fragments, so it MUST have "Received Fragment Out of Order" 898 behavior. 899 a) A NAT's out of order fragment processing mechanism MUST be 900 designed so that fragmentation-based DoS attacks do not 901 compromise the NAT's ability to process in-order and 902 unfragmented IP packets. 904 Justification: See Security Considerations. 906 12. Requirements 908 The requirements in this section are aimed at minimizing the 909 complications caused by NATs to applications such as realtime 910 communications and online gaming. The requirements listed earlier in 911 the document are consolidated here into a single section. 913 It should be understood, however, that applications normally do not 914 know in advance if the NAT conforms to the recommendations defined in 915 this section. Peer-to-peer media applications still need to use 916 normal procedures such as ICE [I-D.ietf-mmusic-ice]. 918 A NAT that supports all of the mandatory requirements of this 919 specification (i.e., the "MUST"), is "compliant with this 920 specification." A NAT that supports all of the requirements of this 921 specification (i.e., including the "RECOMMENDED") is "fully compliant 922 with all the mandatory and recommended requirements of this 923 specification." 925 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior. 926 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 927 behavior of "Paired". Note that this requirement is not 928 applicable to NATs that do not support IP address pooling. 930 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 931 overloading". 932 a) If the host's source port was in the range 1-1023, it is 933 RECOMMENDED the NAT's source port be in the same range. If the 934 host's source port was in the range 1024-65535, it is 935 RECOMMENDED that the NAT's source port be in that range. 936 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 937 behavior of "Yes". 938 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 939 minutes, unless REQ-5a applies. 940 a) For specific destination ports in the well-known port range 941 (ports 0-1023), a NAT MAY have shorter UDP mapping timers that 942 are specific to the IANA-registered application running over 943 that specific destination port. 944 b) The value of the NAT UDP mapping timer MAY be configurable. 945 c) A default value of 5 minutes or more for the NAT UDP mapping 946 timer is RECOMMENDED. 947 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 948 refresh behavior" of "True". 949 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 950 refresh behavior" of "True". 951 REQ-7 A NAT device whose external IP interface can be configured 952 dynamically MUST either (1) Automatically ensure that its internal 953 network uses IP addresses that do not conflict with its external 954 network, or (2) Be able to translate and forward traffic between 955 all internal nodes and all external nodes whose IP addresses 956 numerically conflicts with the internal network. 957 REQ-8: If application transparency is most important, it is 958 RECOMMENDED that a NAT have "Endpoint independent filtering" 959 behavior. If a more stringent filtering behavior is most 960 important, it is RECOMMENDED that a NAT have "Address dependent 961 filtering" behavior. 962 a) The filtering behavior MAY be an option configurable by the 963 administrator of the NAT. 964 REQ-9: A NAT MUST support "Hairpinning". 965 a) A NAT Hairpinning behavior MUST be "External source IP address 966 and port". 967 REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms 968 and allow integrity protection of UDP communications, NAT ALGs for 969 UDP-based protocols SHOULD be turned off. Future standards track 970 specifications that define an ALG can update this to recommend 971 that the ALGs they define default on. 972 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 973 the NAT administrator to enable or disable each ALG separately. 975 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 976 change the NAT translation (Section 4) or the Filtering 977 (Section 5) Behavior at any point in time or under any particular 978 conditions. 979 REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the 980 NAT mapping. 981 a) The NAT's default configuration SHOULD NOT filter ICMP messages 982 based on their source IP address. 983 b) It is RECOMMENDED that a NAT support ICMP Destination 984 Unreachable messages. 985 REQ-13 If the packet received on an internal IP address has DF=1, the 986 NAT MUST send back an ICMP message "fragmentation needed and DF 987 set" message to the host as described in [RFC0792]. 988 a) If the packet has DF=0, the NAT MUST fragment the packet and 989 SHOULD send the fragments in order. 990 REQ-14: A NAT MUST support receiving in order and out of order 991 fragments, so it MUST have "Received Fragment Out of Order" 992 behavior. 993 a) A NAT's out of order fragment processing mechanism MUST be 994 designed so that fragmentation-based DoS attacks do not 995 compromise the NAT's ability to process in-order and 996 unfragmented IP packets. 998 13. Security Considerations 1000 NATs are often deployed to achieve security goals. Most of the 1001 recommendations and requirements in this document do not affect the 1002 security properties of these devices, but a few of them do have 1003 security implications and are discussed in this section. 1005 This document recommends that the timers for mapping be refreshed 1006 only on outgoing packets and does not make recommendations about 1007 whether or not inbound packets should update the timers. If inbound 1008 packets update the timers, an external attacker can keep the mapping 1009 alive forever and attack future devices that may end up with the same 1010 internal address. A device that was also the DHCP server for the 1011 private address space could mitigate this by cleaning any mappings 1012 when a DHCP lease expired. For unicast UDP traffic (the scope of 1013 this document), it may not seem relevant to support inbound timer 1014 refresh; however, for multicast UDP, the question is harder. It is 1015 expected that future documents discussing NAT behavior with multicast 1016 traffic will refine the requirements around handling of the inbound 1017 refresh timer. Some devices today do update the timers on inbound 1018 packets. 1020 This document recommends that the NAT filters be specific to the 1021 external IP address only and not to the external IP and port. It can 1022 be argued that this is less secure than using the IP and port. 1023 Devices that wish to filter on IP and port do still comply with these 1024 requirements. 1026 Non-deterministic NATs are risky from a security point of view. They 1027 are very difficult to test because they are, well, non-deterministic. 1028 Testing by a person configuring one may result in the person thinking 1029 it is behaving as desired, yet under different conditions, which an 1030 attacker can create, the NAT may behave differently. These 1031 requirements recommend that devices be deterministic. 1033 This document requires that NATs have an "external NAT mapping is 1034 endpoint independent" behavior. This does not reduce the security of 1035 devices. Which packets are allowed to flow across the device is 1036 determined by the external filtering behavior, which is independent 1037 of the mapping behavior. 1039 When a fragmented packet is received from the external side and the 1040 packets are out of order so that the initial fragment does not arrive 1041 first, many systems simply discard the out of order packets. 1042 Moreover, since some networks deliver small packets ahead of large 1043 ones, there can be many out of order fragments. NATs that are 1044 capable of delivering these out of order packets are possible but 1045 they need to store the out of order fragments, which can open up a 1046 DoS opportunity if done incorrectly. Fragmentation has been a tool 1047 used in many attacks, some involving passing fragmented packets 1048 through NATs and others involving DoS attacks based on the state 1049 needed to reassemble the fragments. NAT implementers should be aware 1050 of [RFC3128] and [RFC1858]. 1052 14. IANA Considerations 1054 There are no IANA considerations. 1056 15. IAB Considerations 1058 The IAB has studied the problem of "Unilateral Self Address Fixing", 1059 which is the general process by which a client attempts to determine 1060 its address in another realm on the other side of a NAT through a 1061 collaborative protocol reflection mechanism [RFC3424]. 1063 This specification does not in itself constitute an UNSAF 1064 application. It consists of a series of requirements for NATs aimed 1065 at minimizing the negative impact that those devices have on peer-to- 1066 peer media applications, especially when those applications are using 1067 UNSAF methods. 1069 Section 3 of UNSAF lists several practical issues with solutions to 1070 NAT problems. This document makes recommendations to reduce the 1071 uncertainty and problems introduced by these practical issues with 1072 NATs. In addition, UNSAF lists five architectural considerations. 1073 Although this is not an UNSAF proposal, it is interesting to consider 1074 the impact of this work on these architectural considerations. 1076 Arch-1: The scope of this is limited to UDP packets in NATs like the 1077 ones widely deployed today. The "fix" helps constrain the 1078 variability of NATs for true UNSAF solutions such as STUN. 1079 Arch-2: This will exit at the same rate that NATs exit. It does not 1080 imply any protocol machinery that would continue to live 1081 after NATs were gone or make it more difficult to remove 1082 them. 1083 Arch-3: This does not reduce the overall brittleness of NATs but will 1084 hopefully reduce some of the more outrageous NAT behaviors 1085 and make it easer to discuss and predict NAT behavior in 1086 given situations. 1087 Arch-4: This work and the results [I-D.jennings-behave-test-results] 1088 of various NATs represent the most comprehensive work at IETF 1089 on what the real issues are with NATs for applications like 1090 VoIP. This work and STUN have pointed out more than anything 1091 else the brittleness NATs introduce and the difficulty of 1092 addressing these issues. 1093 Arch-5: This work and the test results [I-D.jennings-behave-test- 1094 results] provide a reference model for what any UNSAF 1095 proposal might encounter in deployed NATs. 1097 16. Acknowledgments 1099 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 1100 Dan Kegel for the their multiple contributions on peer-to-peer 1101 communications across a NAT. Dan Wing contributed substantial text 1102 on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, 1103 Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, 1104 Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert 1105 Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka 1106 Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola and Jari Arkko for 1107 their contributions. 1109 17. References 1111 17.1. Normative References 1113 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1114 August 1980. 1116 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1117 September 1981. 1119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1120 Requirement Levels", BCP 14, RFC 2119, March 1997. 1122 17.2. Informational References 1124 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1125 RFC 792, September 1981. 1127 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1128 November 1990. 1130 [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU 1131 Discovery", RFC 1435, March 1993. 1133 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1134 RFC 1812, June 1995. 1136 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1137 Considerations for IP Fragment Filtering", RFC 1858, 1138 October 1995. 1140 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1141 E. Lear, "Address Allocation for Private Internets", 1142 BCP 5, RFC 1918, February 1996. 1144 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1145 (IPv6) Specification", RFC 2460, December 1998. 1147 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 1148 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 1149 RFC 2623, June 1999. 1151 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1152 Translator (NAT) Terminology and Considerations", 1153 RFC 2663, August 1999. 1155 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1156 Address Translator (Traditional NAT)", RFC 3022, 1157 January 2001. 1159 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 1160 with the IP Network Address Translator", RFC 3027, 1161 January 2001. 1163 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1164 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1166 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1167 A., Peterson, J., Sparks, R., Handley, M., and E. 1168 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1169 June 2002. 1171 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1172 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1173 Through Network Address Translators (NATs)", RFC 3489, 1174 March 2003. 1176 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1177 Jacobson, "RTP: A Transport Protocol for Real-Time 1178 Applications", STD 64, RFC 3550, July 2003. 1180 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1181 Self-Address Fixing (UNSAF) Across Network Address 1182 Translation", RFC 3424, November 2002. 1184 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1185 in Session Description Protocol (SDP)", RFC 3605, 1186 October 2003. 1188 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1189 Network Address Translations (NATs)", RFC 4380, 1190 February 2006. 1192 [I-D.ietf-behave-rfc3489bis] 1193 Rosenberg, J., "Simple Traversal of UDP Through Network 1194 Address Translators (NAT) (STUN)", 1195 draft-ietf-behave-rfc3489bis-03 (work in progress), 1196 March 2006. 1198 [I-D.ietf-mmusic-ice] 1199 Rosenberg, J., "Interactive Connectivity Establishment 1200 (ICE): A Methodology for Network Address Translator (NAT) 1201 Traversal for Offer/Answer Protocols", 1202 draft-ietf-mmusic-ice-08 (work in progress), March 2006. 1204 [I-D.jennings-behave-test-results] 1205 Jennings, C., "NAT Classification Test Results", 1206 draft-jennings-behave-test-results-01 (work in progress), 1207 July 2005. 1209 [I-D.ietf-behave-turn] 1210 Rosenberg, J., "Obtaining Relay Addresses from Simple 1211 Traversal of UDP Through NAT (STUN)", 1212 draft-ietf-behave-turn-00 (work in progress), March 2006. 1214 [ITU.H323] 1215 "Packet-based Multimedia Communications Systems", ITU- 1216 T Recommendation H.323, July 2003. 1218 Authors' Addresses 1220 Francois Audet (editor) 1221 Nortel Networks 1222 4655 Great America Parkway 1223 Santa Clara, CA 95054 1224 US 1226 Phone: +1 408 495 3756 1227 Email: audet@nortel.com 1229 Cullen Jennings 1230 Cisco Systems 1231 170 West Tasman Drive 1232 MS: SJC-21/2 1233 San Jose, CA 95134 1234 US 1236 Phone: +1 408 902 3341 1237 Email: fluffy@cisco.com 1239 Intellectual Property Statement 1241 The IETF takes no position regarding the validity or scope of any 1242 Intellectual Property Rights or other rights that might be claimed to 1243 pertain to the implementation or use of the technology described in 1244 this document or the extent to which any license under such rights 1245 might or might not be available; nor does it represent that it has 1246 made any independent effort to identify any such rights. Information 1247 on the procedures with respect to rights in RFC documents can be 1248 found in BCP 78 and BCP 79. 1250 Copies of IPR disclosures made to the IETF Secretariat and any 1251 assurances of licenses to be made available, or the result of an 1252 attempt made to obtain a general license or permission for the use of 1253 such proprietary rights by implementers or users of this 1254 specification can be obtained from the IETF on-line IPR repository at 1255 http://www.ietf.org/ipr. 1257 The IETF invites any interested party to bring to its attention any 1258 copyrights, patents or patent applications, or other proprietary 1259 rights that may cover technology that may be required to implement 1260 this standard. Please address the information to the IETF at 1261 ietf-ipr@ietf.org. 1263 Disclaimer of Validity 1265 This document and the information contained herein are provided on an 1266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1268 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1269 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1270 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1273 Copyright Statement 1275 Copyright (C) The Internet Society (2006). This document is subject 1276 to the rights, licenses and restrictions contained in BCP 78, and 1277 except as set forth therein, the authors retain all their rights. 1279 Acknowledgment 1281 Funding for the RFC Editor function is currently provided by the 1282 Internet Society.