idnits 2.17.1 draft-ietf-behave-nat-udp-04.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 1232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1222. ** 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 (September 6, 2005) is 6807 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) == Unused Reference: '13' is defined on line 1148, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '13') (Obsoleted by RFC 5389) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-05 == Outdated reference: A later version (-04) exists of draft-jennings-behave-test-results-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: March 10, 2006 C. Jennings 5 Cisco Systems 6 September 6, 2005 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-udp-04 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 March 10, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . . 13 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 10.1. Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 19 70 10.2. Smaller Network MTU . . . . . . . . . . . . . . . . . . . 19 71 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20 72 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 74 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 75 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24 76 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 77 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 79 17.2. Informational References . . . . . . . . . . . . . . . . . 25 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 81 Intellectual Property and Copyright Statements . . . . . . . . . . 28 83 1. Applicability Statement 85 The purpose of this specification is to define a set of requirements 86 for NATs that would allow many applications, such as multimedia 87 communications or on-line gaming, to work consistently. Developing 88 NATs that meet this set of requirements will greatly increase the 89 likelihood that these applications will function properly. 91 The requirements of this specification apply to Traditional NATs as 92 described in RFC 2663 [8]. 94 This document is meant to cover NATs of any size, from small 95 residential NATs to large Enterprise NATs. However, it should be 96 understood that Enterprise NATs normally provide much more than just 97 NAT capabilities: for example, they typically provide firewall 98 functionalities. Firewalls are specifically out-of-scope for this 99 specification; however, this specification does cover the inherent 100 filtering aspects of NATs. 102 Approaches using directly signaled control of middle boxes such as 103 Midcom, UPnP, or in-path signaling are out of scope. 105 UDP Relays are out-of-scope. 107 Application aspects are out-of-scope, as the focus here is strictly 108 on the NAT itself. 110 This document only covers the UDP Unicast aspects of NAT traversal 111 and does not cover TCP, IPSEC, or other protocols. Since the 112 document is for UDP only, packet inspection above the UDP layer 113 (including RTP) is also out-of-scope. 115 2. Introduction 117 Network Address Translators (NATs) are well known to cause very 118 significant problems with applications that carry IP addresses in the 119 payload RFC 3027 [10]. Applications that suffer from this problem 120 include Voice Over IP and Multimedia Over IP (e.g., SIP [12] and 121 H.323 [20]), as well as online gaming. 123 Many techniques are used to attempt to make realtime multimedia 124 applications, online games, and other applications work across NATs. 125 Application Level Gateways [8] are one such mechanism. STUN [17] 126 describes a UNilateral Self-Address Translation (UNSAF) mechanism 127 [15]. UDP Relays have also been used to enable applications across 128 NATs, but these are generally seen as a solution of last resort. ICE 129 [18] describes a methodology for using many of these techniques and 130 avoiding a UDP Relay unless the type of NAT is such that it forces 131 the use of such a UDP Relay. This specification defines requirements 132 for improving NATs. Meeting these requirements ensures that 133 applications will not be forced to use UDP media relay. 135 As pointed out in UNSAF [15], "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. The 151 requirements represent what many vendors are already doing, and it is 152 not expected that it should be any more difficult to build a NAT that 153 meets these requirements or that these requirements should affect 154 performance. 156 This document forms a common set of requirements that are simple and 157 useful for voice, video, and games, which can be implemented by NAT 158 vendors. This document will simplify the analysis of protocols for 159 deciding whether or not they work in this environment and will allow 160 providers of services that have NAT traversal issues to make 161 statements about where their applications will work and where they 162 will not, as well as to specify their own NAT requirements. 164 3. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [1]. 170 Readers are urged to refer to RFC 2263 [8] for information on NAT 171 taxonomy and terminology. Traditional NAT is the most common type of 172 NAT device deployed. Readers may refer to RFC 3022 [9] for detailed 173 information on traditional NAT. Traditional NAT has two main 174 varieties - Basic NAT and Network Address/Port Translator (NAPT). 176 NAPT is by far the most commonly deployed NAT device. NAPT allows 177 multiple internal hosts to share a single public IP address 178 simultaneously. When an internal host opens an outgoing TCP or UDP 179 session through a NAPT, the NAPT assigns the session a public IP 180 address and port number, so that subsequent response packets from the 181 external endpoint can be received by the NAPT, translated, and 182 forwarded to the internal host. The effect is that the NAPT 183 establishes a NAT session to translate the (private IP address, 184 private port number) tuple to (public IP address, public port number) 185 tuple and vice versa for the duration of the session. An issue of 186 relevance to peer-to-peer applications is how the NAT behaves when an 187 internal host initiates multiple simultaneous sessions from a single 188 (private IP, private port) endpoint to multiple distinct endpoints on 189 the external network. In this specification, the term "NAT" refers 190 to both "Basic NAT" and "Network Address/Port Translator (NAPT)". 192 This document uses the term "session" as defined in RFC 2663: "TCP/ 193 UDP sessions are uniquely identified by the tuple of (source IP 194 address, source TCP/UDP ports, target IP address, target TCP/UDP 195 Port)." 197 This document uses the term "address and port mapping" as the 198 translation between an external address and port and an internal 199 address and port. Note that this is not the same as an "address 200 binding" as defined in RFC 2663. 202 RFC 3489 [8] used the terms "Full Cone", "Restricted Cone", "Port 203 Restricted Cone" and "Symmetric" to refer to different variations of 204 NATs applicable to UDP only. Unfortunately, this terminology has 205 been the source of much confusion as it has proven inadequate at 206 describing real-life NAT behavior. This specification therefore 207 refers to specific individual NAT behaviors instead of using the 208 Cone/Symmetric terminology. 210 4. Network Address and Port Translation Behavior 212 This section describes the various NAT behaviors applicable to NATs. 214 4.1. Address and Port Mapping 216 When an internal endpoint opens an outgoing session through a NAT, 217 the NAT assigns the session an external IP address and port number so 218 that subsequent response packets from the external endpoint can be 219 received by the NAT, translated, and forwarded to the internal 220 endpoint. This is a mapping between an internal IP address and port 221 IP:port and external IP:port tuple. It establishes the translation 222 that will be performed by the NAT for the duration of the session. 223 For many applications, it is important to distinguish the behavior of 224 the NAT when there are multiple simultaneous sessions established to 225 different external endpoints. 227 The key behavior to describe is the criteria for re-use of a mapping 228 for new sessions to external endpoints, after establishing a first 229 mapping between an internal X:x address and port and an external 230 Y1:y1 address tuple. Let's assume that the internal IP address and 231 port X:x is mapped to X1':x1' for this first session. The endpoint 232 then sends from X:x to an external address Y2:y2 and gets a mapping 233 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 234 for various combinations of the relationship between Y1:y1 and Y2:y2 235 is critical for describing the NAT behavior. This arrangement is 236 illustrated in the following diagram: 238 E 239 +------+ +------+ x 240 | Y1 | | Y2 | t 241 +--+---+ +---+--+ e 242 | Y1:y1 Y2:y2 | r 243 +----------+ +----------+ n 244 | | a 245 X1':x1' | | X2':x2' l 246 +--+---+-+ 247 ...........| NAT |............... 248 +--+---+-+ I 249 | | n 250 X:x | | X:x t 251 ++---++ e 252 | X | r 253 +-----+ n 254 a 255 l 257 The following address and port mapping behavior are defined: 259 Endpoint Independent Mapping: 260 The NAT reuses the port mapping for subsequent packets sent 261 from the same internal IP address and port (X:x) to any 262 external IP address and port. Specifically, X1':x1' equals 263 X2':x2' for all values of Y2:y2. 265 Address Dependent Mapping: 266 The NAT reuses the port mapping for subsequent packets sent 267 from the same internal IP address and port (X:x) to the same 268 external IP address, regardless of the external port. 269 Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals 270 Y1. 272 Address and Port Dependent Mapping: 273 The NAT reuses the port mapping for subsequent packets sent 274 from the same internal IP address and port (X:x) to the same 275 external and port while the mapping is still active. 276 Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 277 equals Y1:y1. 279 It is important to note that these three possible choices make no 280 difference to the security properties of the NAT. The security 281 properties are fully determined by which packets the NAT allows in 282 and which it does not. This is determined by the filtering behavior 283 in the filtering portions of the NAT. 285 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 286 independent" 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 Media 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 RFC 3605 [16] 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 RTP 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 server used by both endpoints such 390 as a SIP proxy, or a web server, etc. 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. 404 It should be noted that port 0 is reserved and must not be used. 406 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 407 overloading". 408 a) If the host's source port was in the range 1-1023, it is 409 RECOMMENDED the NAT's source port be in the same range. If the 410 host's source port was in the range 1024-65535, it is 411 RECOMMENDED that the NAT's source port be in that range. 413 Justification: This requirement must be met in order to enable two 414 applications on the internal side of the NAT both to use the same 415 port to try to communicate with the same destination. NATs that 416 implement port preservation have to deal with conflicts on ports, 417 and the multiple code paths this introduces often result in 418 nondeterministic behavior. However, it should be understood that 419 when a port is randomly assigned, it may just randomly happen to 420 be assigned the same port. Applications must therefore be able to 421 deal with both port preservation and no port preservation. 422 a) Certain applications expect the source UDP port to be in the 423 well-known range. See RFC 2623 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 RFC 3550 [14] 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 RFC 3605 [16]. 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. 462 Furthermore, there is a glaring problem if many applications (or 463 endpoints) are trying to open mapping simultaneously. Port 464 preservation is also problematic since it is wasteful, especially 465 considering that a NAT cannot reliably distinguish between RTP over 466 UDP and other UDP packets where there is no contiguity rule. For 467 those reasons, it would be too complex to attempt to preserve the 468 contiguity rule by suggesting specific NAT behavior, and it would 469 certainly break the deterministic behavior rule. 471 In order to support both RTP and RTCP, it will therefore be necessary 472 that applications follow rules to negotiate RTP and RTCP separately, 473 and account for the very real possibility that the RTCP=RTP+1 rule 474 will be broken. As this is an application requirement, it is outside 475 of the scope of this document. 477 4.3. Mapping Refresh 479 NAT mapping timeout implementations vary but include the timer's 480 value and the way the mapping timer is refreshed to keep the mapping 481 alive. 483 The mapping timer is defined as the time a mapping will stay active 484 without packets traversing the NAT. There is great variation in the 485 values used by different NATs. 487 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 488 minutes. 489 a) The value of the NAT UDP mapping timer MAY be configurable. 490 b) A default value of 5 minutes for the NAT UDP mapping timer is 491 RECOMMENDED. 493 Justification: This requirement is to ensure that the timeout is long 494 enough to avoid too frequent timer refresh packets. 495 a) Configuration is desirable for adapting to specific networks 496 and troubleshooting. 497 b) This default is to avoid too frequent timer refresh packets. 499 Some NATs keep the mapping active (i.e., refresh the timer value) 500 when a packet goes from the internal side of the NAT to the external 501 side of the NAT. This is referred to as having a NAT Outbound 502 refresh behavior of "True". 504 Some NATs keep the mapping active when a packet goes from the 505 external side of the NAT to the internal side of the NAT. This is 506 referred to as having a NAT Inbound Refresh Behavior of "True". 508 Some NATs keep the mapping active on both, in which case both 509 properties are "True". 511 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 512 refresh behavior" of "True". 513 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 514 refresh behavior" of "True". 516 Justification: Outbound refresh is necessary for allowing the client 517 to keep the mapping alive. 518 a) Inbound refresh may be useful for applications with no outgoing 519 UDP traffic. However, allowing inbound refresh may allow an 520 application to keep a mapping alive indefinitely. This may be 521 a security risk. Also, if the process is repeated with 522 different ports, over time it could use up all the ports on the 523 NAT. 525 4.4. Conflicting Internal and External IP Address Spaces 527 Many NATs, particularly consumer-level devices designed to be 528 deployed by nontechnical users, routinely obtain their external IP 529 address, default router, and other IP configuration information for 530 their external interface dynamically from an external network such as 531 an upstream ISP. The NAT in turn automatically sets up its own 532 internal subnet in one of the private IP address spaces assigned to 533 this purpose in RFC 1918 [7], typically providing dynamic IP 534 configuration services for hosts on this internal network. 536 Auto-configuration of NATs and private networks can be problematic, 537 however, if the NAT's external network is also in RFC 1918 private 538 address space. In a common scenario, an ISP places its customers 539 behind a NAT and hands out private RFC 1918 addresses to them. Some 540 of these customers in turn deploy consumer-level NATs, which in 541 effect act as "second-level" NATs, multiplexing their own private RFC 542 1918 IP subnets onto the single RFC 1918 IP address provided by the 543 ISP. There is no inherent guarantee in this case that the ISP's 544 "intermediate" privately-addressed network and the customer's 545 internal privately-addressed network will not use numerically 546 identical or overlapping RFC 1918 IP subnets. Customers of consumer- 547 level NATs further cannot be expected to have the technical knowledge 548 to prevent this scenario from occurring by manually configuring their 549 internal network with non-conflicting RFC 1918 subnets. 551 NAT vendors need to design their NATs to ensure that they function 552 correctly and robustly even in such problematic scenarios. One 553 possible solution is for the NAT to ensure that whenever its external 554 link is configured with an RFC 1918 private IP address, the NAT 555 automatically selects a different, non-conflicting RFC 1918 IP subnet 556 for its internal network. A disadvantage of this solution is that if 557 the NAT's external interface is dynamically configured or re- 558 configured after its internal network is already in use, then the NAT 559 may have to renumber its entire internal network dynamically if it 560 detects a conflict. 562 An alternative solution is for the NAT to be designed so that it can 563 translate and forward traffic correctly even when its external and 564 internal interfaces are configured with numerically overlapping IP 565 subnets. In this scenario, for example, if the NAT's external 566 interface has been assigned an IP address P in RFC 1918 space, then 567 there might also be an internal node I having the same RFC 1918 568 private IP address P. An IP packet with destination address P on the 569 external network is directed at the NAT, whereas an IP packet with 570 the same destination address P on the internal network is directed at 571 node I. The NAT therefore needs to maintain a clear operational 572 distinction between "external IP addresses" and "internal IP 573 addresses" to avoid confusing internal node I with its own external 574 interface. In general, the NAT needs to allow all internal nodes 575 (including I) to communicate with all external nodes having public 576 (non-RFC 1918) IP addresses or having private IP addresses that do 577 not conflict with the addresses used by its internal network. 579 REQ-7: A NAT device whose external IP interface can be configured 580 dynamically MUST either (1) automatically ensure that its internal 581 network uses IP addresses that do not conflict with its external 582 network, or (2) be able to translate and forward traffic between 583 all internal nodes and all external nodes whose IP addresses do 584 not numerically conflict with the internal network. 586 Justification: If a NAT's external and internal interfaces are 587 configured with overlapping IP subnets, then there is of course no 588 way for an internal host with RFC 1918 IP address Q to initiate a 589 direct communication session to an external node having the same 590 RFC 1918 address Q, or to other external nodes with IP addresses 591 that numerically conflict with the internal subnet. Such nodes 592 can still open communication sessions indirectly via NAT traversal 593 techniques, however, with the help of a third-party server such as 594 a STUN server having a public, non-RFC 1918 IP address. In this 595 case, nodes with conflicting private RFC 1918 addresses on 596 opposite sides of the second-level NAT can communicate with each 597 other via their respective temporary public endpoints on the main 598 Internet, as long as their common first-level NAT (e.g., the 599 upstream ISP's NAT) supports hairpinning behavior as described in 600 Section 6. 602 5. Filtering Behavior 604 This section describes various filtering behaviors observed in NATs. 606 When an internal endpoint opens an outgoing session through a NAT, 607 the NAT assigns a filtering rule for the mapping between an internal 608 IP:port (X:x) and external IP:port (Y:y) tuple. 610 The key behavior to describe is what criteria are used by the NAT to 611 filter packets originating from specific external endpoints. 613 Endpoint Independent Filtering: 614 The NAT filters out only packets not destined to the internal 615 address and port X:x, regardless of the external IP address and 616 port source (Z:z). The NAT forwards any packets destined to 617 X:x. In other words, sending packets from the internal side of 618 the NAT to any external IP address is sufficient to allow any 619 packets back to the internal endpoint. 621 Address Dependent Filtering: 622 The NAT filters out packets not destined to the internal 623 address X:x. Additionally, the NAT will filter out packets 624 from Y:y destined for the internal endpoint X:x if X:x has not 625 sent packets to Y:any previously (independently of the port 626 used by Y). In other words, for receiving packets from a 627 specific external endpoint, it is necessary for the internal 628 endpoint to send packets first to that specific external 629 endpoint's IP address. 631 Address and Port Dependent Filtering: 632 This is similar to the previous behavior, except that the 633 external port is also relevant. The NAT filters out packets 634 not destined for the internal address X:x. Additionally, the 635 NAT will filter out packets from Y:y destined for the internal 636 endpoint X:x if X:x has not sent packets to Y:y previously. In 637 other words, for receiving packets from a specific external 638 endpoint, it is necessary for the internal endpoint to send 639 packets first to that external endpoint's IP address and port. 641 REQ-8: If application transparency is most important, it is 642 RECOMMENDED that a NAT have an "Endpoint independent filtering" 643 behavior. If a more stringent filtering behavior is most 644 important, it is RECOMMENDED that a NAT have an "Address dependent 645 filtering" behavior. 646 a) The filtering behavior MAY be an option configurable by the 647 administrator of the NAT. 649 Justification: The recommendation to use Endpoint Independent 650 Filtering is aimed at maximizing application transparency, in 651 particular for applications that receive media simultaneously from 652 multiple locations (e.g., gaming), or applications that use 653 rendezvous techniques. However, it is also possible that in some 654 circumstances, it may be preferable to have a more stringent 655 filtering behavior. Filtering independently of the external 656 endpoint is not as secure: an unauthorized packet could get 657 through a specific port while the port was kept open if it was 658 lucky enough to find the port open. In theory, filtering based on 659 both IP address and port is more secure than filtering based only 660 on the IP address (because the external endpoint could in reality 661 be two endpoints behind another NAT, where one of the two 662 endpoints is an attacker): however, such a policy could interfere 663 with applications that expect to receive UDP packets on more than 664 one UDP port. Using Endpoint Independent Filtering or Address 665 Dependent Filtering instead of Address and Port Dependent 666 Filtering on a NAT (say NAT-A) also has benefits when the other 667 endpoint is behind a non-BEHAVE compliant NAT (say NAT-B) that 668 does not support REQ-1. When the endpoints use ICE, if NAT-A uses 669 Address and Port Dependent Filtering, connectivity will require a 670 Media Relay. However, if NAT-A uses Endpoint Independent 671 Filtering or Address Dependent Filtering, ICE will ultimately find 672 connectivity without requiring a Media Relay. Having the 673 filtering behavior being an option configurable by the 674 administrator of the NAT ensures that a NAT can be used in the 675 widest variety of deployment scenarios. 677 6. Hairpinning Behavior 679 If two hosts (called X1 and X2) are behind the same NAT and 680 exchanging traffic, the NAT may allocate an address on the outside of 681 the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it 682 goes to the NAT, which must relay the traffic from X1 to X2. This is 683 referred to as hairpinning and is illustrated below. 685 NAT 686 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 687 | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 688 +----+ | v | 689 | v | 690 | v | 691 | v | 692 +----+ from X1':x1' to X2:x2 | v | X2':x2' 693 | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 694 +----+ +-----+ 696 Hairpinning allows two endpoints on the internal side of the NAT to 697 communicate even if they only use each other's external IP addresses 698 and ports. 700 More formally, a NAT that supports hairpinning forwards packets 701 originating from an internal address, X1:x1, destined for an external 702 address X2':x2' that has an active mapping to an internal address 703 X2:x2, back to that internal address X2:x2. Note that typically X1' 704 is the same as X2'. 706 Furthermore, the NAT may present the hairpinned packet with either an 707 internal or an external source IP address and port. The hairpinning 708 NAT behavior can therefore be either "External source IP address and 709 port" or "Internal source IP address and port". "Internal source IP 710 address and port" may cause problems by confusing implementations 711 that expect an external IP address and port. 713 REQ-9: A NAT MUST support "Hairpinning". 714 a) A NAT Hairpinning behavior MUST be "External source IP address 715 and port". 717 Justification: This requirement is to allow communications between 718 two endpoints behind the same NAT when they are trying each 719 other's external IP addresses. 720 a) Using the external IP address is necessary for applications 721 with a restrictive policy of not accepting packets from IP 722 addresses that differ from what is expected. 724 7. Application Level Gateways 726 Certain NATs have implemented Application Level Gateways (ALGs) for 727 various protocols, including protocols for negotiating peer-to-peer 728 sessions such as SIP. 730 Certain NATs have these ALGs turned on permanently, others have them 731 turned on by default but let them be be turned off, and others have 732 them turned off by default but let them be turned on. 734 NAT ALGs may interfere with UNSAF methods or protocols that try to be 735 NAT-aware and must therefore be used with extreme caution. 737 REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED 738 that all of those ALGs be disabled by default. 739 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 740 the NAT administrator to enable or disable each ALG separately. 742 Justification: NAT ALGs may interfere with UNSAF methods. 743 a) This requirement allows the user to enable those ALGs that are 744 necessary to aid in the operation of some applications without 745 enabling ALGs which interfere with the operation of other 746 applications. 748 8. Deterministic Properties 750 The classification of NATs is further complicated by the fact that 751 under some conditions the same NAT will exhibit different behaviors. 752 This has been seen on NATs that preserve ports or have specific 753 algorithms for selecting a port other than a free one. If the 754 external port that the NAT wishes to use is already in use by another 755 session, the NAT must select a different port. This results in 756 different code paths for this conflict case, which results in 757 different behavior. 759 For example, if three hosts X1, X2, and X3 all send from the same 760 port x, through a port preserving NAT with only one external IP 761 address, called X1', the first one to send (i.e., X1) will get an 762 external port of x but the next two will get x2' and x3' (where these 763 are not equal to x). There are NATs where the External NAT mapping 764 characteristics and the External Filter characteristics change 765 between the X1:x and the X2:x mapping. To make matters worse, there 766 are NATs where the behavior may be the same on the X1:x and X2:x 767 mappings but different on the third X3:x mapping. 769 Some NATs that try to reuse external ports flow from two internal IP 770 addresses to two different external IP addresses. For example, X1:x 771 is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not 772 equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x 773 to X1':x. This works if the NAT mapping is address port dependent. 774 However some NATs change their behavior when this type of port reuse 775 is happening. The NAT may look like it has NAT mappings that are 776 independent when this type of reuse is not happening but may change 777 to Address Port Dependent when this reuse happens. 779 Any NAT that changes the NAT mapping or the External Filtering 780 without configuration changes, at any point in time under any 781 particular conditions is referred to as a "non-deterministic" NAT. 782 NATs that don't are called "deterministic". 784 Non-deterministic NATs generally change behavior when a conflict of 785 some sort happens, i.e. when the port that would normally be used is 786 already in use by another mapping. The NAT mapping and External 787 Filtering in the absence of conflict is referred to as the Primary 788 behavior. The behavior after the first conflict is referred to as 789 Secondary and after the second conflict is referred to as Tertiary. 790 No NATs have been observed that change on further conflicts but it is 791 certainly possible that they exist. 793 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 794 change the NAT mapping or the External Filtering Behavior at any 795 point in time or under any particular conditions. 797 Justification: Non-deterministic NATs are very difficult to 798 troubleshoot because they require more intensive testing. This 799 non-deterministic behavior is the root cause of much of the 800 uncertainty that NATs introduce about whether or not applications 801 will work. 803 9. ICMP Destination Unreachable Behavior 805 When a NAT sends a packet towards a host on the other side of the 806 NAT, an ICMP message may be sent in response to that packet. That 807 ICMP message may be sent by the destination host or by any router 808 along the network path. The NAT's default configuration SHOULD NOT 809 filter ICMP messages based on their source IP address. Such ICMP 810 messages SHOULD be rewritten by the NAT (specifically the IP headers 811 and the ICMP payload) and forwarded to the appropriate internal or 812 external host. The NAT needs to perform this function for as long as 813 the UDP mapping is active. Receipt of any sort of ICMP message MUST 814 NOT destroy the NAT mapping. A NAT which performs the functions 815 described in the paragraph above is referred to as "support ICMP 816 Processing". 818 There is no significant security advantage to blocking ICMP 819 Destination Unreachable packets. Additionally, blocking ICMP 820 Destination Unreachable packets can interfere with application 821 failover, UDP Path MTU Discovery (see RFC1191 [3] and RFC1435 [4]), 822 and traceroute. Blocking any ICMP message is discouraged, and 823 blocking ICMP Destination Unreachable is strongly discouraged. 825 REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT 826 mapping. 827 a) The NAT's default configuration SHOULD NOT filter ICMP messages 828 based on their source IP address. 829 b) It is RECOMMENDED that a NAT support ICMP Destination 830 Unreachable messages. 832 Justification: This is easy to do, is used for many things including 833 MTU discovery and rapid detection of error conditions, and has no 834 negative consequences. 836 10. Fragmentation of Outgoing Packets 838 When sending a packet, there are two situations that may cause IP 839 fragmentation for packets from the inside to the outside. It is 840 worth noting that many IP stacks do not use Path MTU Discovery with 841 UDP packets. 843 10.1. Smaller Adjacent MTU 845 The first situation is when the MTU of the adjacent link is too 846 small. This can occur if the NAT is doing PPPoE, or if the NAT has 847 been configured with a small MTU to reduce serialization delay when 848 sending large packets and small higher-priority packets, or for other 849 reasons. 851 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 852 (DF=0). 854 If the packet has DF=1, the NAT SHOULD send back an ICMP message 855 "fragmentation needed and DF set" message to the host as described in 856 RFC 792 [2]. 858 If the packet has DF=0, the NAT SHOULD fragment the packet and send 859 the fragments, in order. This is the same function a router performs 860 in a similar situation RFC 1812 [5]. 862 NATs that operate as described in this section are described as 863 "Supports Fragmentation" (abbreviated SF). 865 10.2. Smaller Network MTU 867 The second situation is when the MTU on some link in the middle of 868 the network that is not the adjacent link is too small. If DF=0, the 869 router adjacent to the small-MTU segment will fragment the packet and 870 forward the fragments as specified in RFC 1812 [5]. 872 If DF=1, the router adjacent to the small-MTU segment will send the 873 ICMP message "fragmentation needed and DF set" back towards the NAT. 874 The NAT needs to forward this ICMP message to the inside host. 876 The classification of NATs that perform this behavior is covered in 877 Section 9. 879 REQ-13: A NAT MUST support fragmentation of packets larger than link 880 MTU. 882 Justification: Fragmented packets become more common with large video 883 packets and should continue to work. Applications can use MTU 884 discovery to work around this problem. 886 11. Receiving Fragmented Packets 888 For a variety of reasons, a NAT may receive a fragmented packet. The 889 IP packet containing the header could arrive in any fragment 890 depending on network conditions, packet ordering, and the 891 implementation of the IP stack that generated the fragments. 893 A NAT that is capable only of receiving fragments in order (that is, 894 with the header in the first packet) and forwarding each of the 895 fragments to the internal host is described as "Received Fragments 896 Ordered". 898 A NAT that is capable of receiving fragments in or out of order and 899 forwarding the individual packets (or a reassembled packet) to the 900 internal host is referred to as "Receive Fragments Out of Order". 901 See the Security Considerations section of this document for a 902 discussion of this behavior. 904 A NAT that is neither of these is referred to as "Receive Fragments 905 None". 907 REQ-14: A NAT MUST support receiving in order and out of order 908 fragments, so it MUST have "Received Fragment Out of Order" 909 behavior. 910 a) A NAT's out of order fragment processing mechanism MUST be 911 designed so that fragmentation-based DoS attacks do not 912 compromise the NAT's ability to process in-order and 913 unfragmented IP packets. 915 Justification: See Security Considerations. 917 12. Requirements 919 The requirements in this section are aimed at minimizing the 920 complications caused by NATs to applications such as realtime 921 communications and online gaming. The requirements listed earlier in 922 the document are consolidated here into a single section. 924 It should be understood, however, that applications normally do not 925 know in advance if the NAT conforms to the recommendations defined in 926 this section. Peer-to-peer media applications still need to use 927 normal procedures such as ICE [18]. 929 A NAT that supports all of the mandatory requirements of this 930 specification (i.e., the "MUST"), is "compliant with this 931 specification." A NAT that supports all of the requirements of this 932 specification (i.e., including the "RECOMMENDED") is "fully compliant 933 with all the mandatory and recommended requirements of this 934 specification." 936 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 937 independent" behavior. 938 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 939 behavior of "Paired". Note that this requirement is not 940 applicable to NATs that do not support IP address pooling. 941 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 942 overloading". 943 a) If the host's source port was in the range 1-1023, it is 944 RECOMMENDED the NAT's source port be in the same range. If the 945 host's source port was in the range 1024-65535, it is 946 RECOMMENDED that the NAT's source port be in that range. 947 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 948 behavior of "Yes". 949 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 950 minutes. 951 a) The value of the NAT UDP mapping timer MAY be configurable. 952 b) A default value of 5 minutes for the NAT UDP mapping timer is 953 RECOMMENDED. 954 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 955 refresh behavior" of "True". 956 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 957 refresh behavior" of "True". 959 REQ-7 A NAT device whose external IP interface can be configured 960 dynamically MUST either (1) Automatically ensure that its internal 961 network uses IP addresses that do not conflict with its external 962 network, or (2) Be able to translate and forward traffic between 963 all internal nodes and all external nodes whose IP addresses do 964 not numerically conflict with the internal network. 965 REQ-8: If application transparency is most important, it is 966 RECOMMENDED that a NAT have "Endpoint independent filtering" 967 behavior. If a more stringent filtering behavior is most 968 important, it is RECOMMENDED that a NAT have "Address dependent 969 filtering" behavior. 970 a) The filtering behavior MAY be an option configurable by the 971 administrator of the NAT. 972 REQ-9: A NAT MUST support "Hairpinning". 973 a) A NAT Hairpinning behavior MUST be "External source IP address 974 and port". 975 REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED 976 that all of those ALGs be disabled by default. 977 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 978 the NAT administrator to enable or disable each ALG separately. 979 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 980 change the NAT mapping or the External External Filtering Behavior 981 at any point in time or under any particular conditions. 982 REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT 983 mapping. 984 a) The NAT's default configuration SHOULD NOT filter ICMP messages 985 based on their source IP address. 986 b) It is RECOMMENDED that a NAT support ICMP Destination 987 Unreachable messages. 988 REQ-13: A NAT MUST support fragmentation of packets larger than link 989 MTU. 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 work recommends that the timers for mapping be refreshed only on 1006 outgoing packets and does not make recommendations about whether or 1007 not inbound packets should update the timers. If inbound packets 1008 update the timers, an external attacker can keep the mapping alive 1009 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 work recommends that the NAT filters be specific to the external 1021 IP only and not to the external IP and port. It can be argued that 1022 this is less secure than using the IP and port. Devices that wish to 1023 filter on IP and port do still comply with these requirements. 1025 Non-deterministic NATs are risky from a security point of view. They 1026 are very difficult to test because they are, well, non-deterministic. 1027 Testing by a person configuring one may result in the person thinking 1028 it is behaving as desired, yet under different conditions, which an 1029 attacker can create, the NAT may behave differently. These 1030 requirements recommend that devices be deterministic. 1032 The work requires that NATs have an "external NAT mapping is endpoint 1033 independent" behavior. This does not reduce the security of devices. 1034 Which packets are allowed to flow across the device is determined by 1035 the external filtering behavior, which is independent of the mapping 1036 behavior. 1038 When a fragmented packet is received from the external side and the 1039 packets are out of order so that the initial fragment does not arrive 1040 first, many systems simply discard the out of order packets. 1041 Moreover, since some networks deliver small packets ahead of large 1042 ones, there can be many out of order fragments. NATs that are 1043 capable of delivering these out of order packets are possible but 1044 they need to store the out of order fragments, which can open up a 1045 DoS opportunity if done incorrectly. Fragmentation has been a tool 1046 used in many attacks, some involving passing fragmented packets 1047 through NATs and others involving DoS attacks based on the state 1048 needed to reassemble the fragments. NAT implementers should be aware 1049 of RFC 3128 [11] and RFC 1858 [6]. 1051 14. IANA Considerations 1052 There are no IANA considerations. 1054 15. IAB Considerations 1056 The IAB has studied the problem of "Unilateral Self Address Fixing", 1057 which is the general process by which a client attempts to determine 1058 its address in another realm on the other side of a NAT through a 1059 collaborative protocol reflection mechanism [15]. 1061 This specification does not in itself constitute an UNSAF 1062 application. It consists of a series of requirements for NATs aimed 1063 at minimizing the negative impact that those devices have on peer-to- 1064 peer media applications, especially when those applications are using 1065 UNSAF methods. 1067 Section 3 of UNSAF lists several practical issues with solutions to 1068 NAT problems. This document makes recommendations to reduce the 1069 uncertainty and problems introduced by these practical issues with 1070 NATs. In addition, UNSAF lists five architectural considerations. 1071 Although this is not an UNSAF proposal, it is interesting to consider 1072 the impact of this work on these architectural considerations. 1074 Arch-1: The scope of this is limited to UDP packets in NATs like the 1075 ones widely deployed today. The "fix" helps constrain the 1076 variability of NATs for true UNSAF solutions such as STUN. 1077 Arch-2: This will exit at the same rate that NATs exit. It does not 1078 imply any protocol machinery that would continue to live 1079 after NATs were gone or make it more difficult to remove 1080 them. 1081 Arch-3: This does not reduce the overall brittleness of NATs but will 1082 hopefully reduce some of the more outrageous NAT behaviors 1083 and make it easer to discuss and predict NAT behavior in 1084 given situations. 1085 Arch-4: This work and the results [19] of various NATs represent the 1086 most comprehensive work at IETF on what the real issues are 1087 with NATs for applications like VoIP. This work and STUN 1088 have pointed out more than anything else the brittleness NATs 1089 introduce and the difficulty of addressing these issues. 1090 Arch-5: This work and the test results [19] provide a reference model 1091 for what any UNSAF proposal might encounter in deployed NATs. 1093 16. Acknowledgments 1095 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 1096 Dan Kegel for the their multiple contributions on peer-to-peer 1097 communications across a NAT. Dan Wing contributed substantial text 1098 on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, 1099 Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, 1100 Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert 1101 Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka 1102 Takeda and Paul Hoffman for their contributions. 1104 17. References 1106 17.1. Normative References 1108 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1109 Levels", BCP 14, RFC 2119, March 1997. 1111 17.2. Informational References 1113 [2] Postel, J., "Internet Control Message Protocol", STD 5, 1114 RFC 792, September 1981. 1116 [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1117 November 1990. 1119 [4] Knowles, S., "IESG Advice from Experience with Path MTU 1120 Discovery", RFC 1435, March 1993. 1122 [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1123 June 1995. 1125 [6] Ziemba, G., Reed, D., and P. Traina, "Security Considerations 1126 for IP Fragment Filtering", RFC 1858, October 1995. 1128 [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 1129 Lear, "Address Allocation for Private Internets", BCP 5, 1130 RFC 1918, February 1996. 1132 [8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1133 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1135 [9] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1136 Translator (Traditional NAT)", RFC 3022, January 2001. 1138 [10] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 1139 IP Network Address Translator", RFC 3027, January 2001. 1141 [11] Miller, I., "Protection Against a Variant of the Tiny Fragment 1142 Attack (RFC 1858)", RFC 3128, June 2001. 1144 [12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1145 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1146 Session Initiation Protocol", RFC 3261, June 2002. 1148 [13] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1149 - Simple Traversal of User Datagram Protocol (UDP) Through 1150 Network Address Translators (NATs)", RFC 3489, March 2003. 1152 [14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1153 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1154 RFC 3550, July 2003. 1156 [15] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1157 Address Fixing (UNSAF) Across Network Address Translation", 1158 RFC 3424, November 2002. 1160 [16] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1161 Session Description Protocol (SDP)", RFC 3605, October 2003. 1163 [17] Rosenberg, J., "Simple Traversal of UDP Through Network Address 1164 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 1165 (work in progress), July 2005. 1167 [18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1168 Methodology for Network Address Translator (NAT) Traversal for 1169 Offer/Answer Protocols", draft-ietf-mmusic-ice-05 (work in 1170 progress), July 2005. 1172 [19] Jennings, C., "NAT Classification Test Results", 1173 draft-jennings-behave-test-results-01 (work in progress), 1174 July 2005. 1176 [20] "Packet-based Multimedia Communications Systems", ITU- 1177 T Recommendation H.323, July 2003. 1179 Authors' Addresses 1181 Francois Audet (editor) 1182 Nortel Networks 1183 4655 Great America Parkway 1184 Santa Clara, CA 95054 1185 US 1187 Phone: +1 408 495 3756 1188 Email: audet@nortel.com 1190 Cullen Jennings 1191 Cisco Systems 1192 170 West Tasman Drive 1193 MS: SJC-21/2 1194 San Jose, CA 95134 1195 US 1197 Phone: +1 408 902 3341 1198 Email: fluffy@cisco.com 1200 Intellectual Property Statement 1202 The IETF takes no position regarding the validity or scope of any 1203 Intellectual Property Rights or other rights that might be claimed to 1204 pertain to the implementation or use of the technology described in 1205 this document or the extent to which any license under such rights 1206 might or might not be available; nor does it represent that it has 1207 made any independent effort to identify any such rights. Information 1208 on the procedures with respect to rights in RFC documents can be 1209 found in BCP 78 and BCP 79. 1211 Copies of IPR disclosures made to the IETF Secretariat and any 1212 assurances of licenses to be made available, or the result of an 1213 attempt made to obtain a general license or permission for the use of 1214 such proprietary rights by implementers or users of this 1215 specification can be obtained from the IETF on-line IPR repository at 1216 http://www.ietf.org/ipr. 1218 The IETF invites any interested party to bring to its attention any 1219 copyrights, patents or patent applications, or other proprietary 1220 rights that may cover technology that may be required to implement 1221 this standard. Please address the information to the IETF at 1222 ietf-ipr@ietf.org. 1224 Disclaimer of Validity 1226 This document and the information contained herein are provided on an 1227 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1228 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1229 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1230 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1231 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1232 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1234 Copyright Statement 1236 Copyright (C) The Internet Society (2005). This document is subject 1237 to the rights, licenses and restrictions contained in BCP 78, and 1238 except as set forth therein, the authors retain all their rights. 1240 Acknowledgment 1242 Funding for the RFC Editor function is currently provided by the 1243 Internet Society.