idnits 2.17.1 draft-ietf-behave-nat-udp-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1255. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (January 10, 2005) is 7046 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) ** Downref: Normative reference to an Informational RFC: RFC 3424 (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '7') (Obsoleted by RFC 5389) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-03 == Outdated reference: A later version (-04) exists of draft-srisuresh-behave-p2p-state-00 Summary: 6 errors (**), 0 flaws (~~), 4 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: July 11, 2005 C. Jennings 5 Cisco Systems 6 January 10, 2005 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-udp-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 11, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document defines basic terminology for describing different 45 types of NAT behavior when handling Unicast UDP, and defines a set of 46 requirements that would allow many applications, such as multimedia 47 communications or on-line gaming, to work consistently. Developing 48 NATs that meet this set of requirements will greatly increase the 49 likelihood that these applications will function properly. 51 Table of Contents 53 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Network Address and Port Translation Behavior . . . . . . . . 6 57 4.1 Address and Port Mapping . . . . . . . . . . . . . . . . . 6 58 4.2 Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 59 4.2.1 Port Assignment Behavior . . . . . . . . . . . . . . . 8 60 4.2.2 Port Parity . . . . . . . . . . . . . . . . . . . . . 10 61 4.2.3 Port Contiguity . . . . . . . . . . . . . . . . . . . 10 62 4.3 Mapping Refresh Direction . . . . . . . . . . . . . . . . 11 63 4.4 Mapping Refresh Scope . . . . . . . . . . . . . . . . . . 11 64 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 12 65 5.1 Filtering of Unsolicited Packets . . . . . . . . . . . . . 12 66 5.2 NAT Filter Refresh . . . . . . . . . . . . . . . . . . . . 13 67 6. Relationship with Cone and Symmetric NAT Terminology . . . . . 13 68 7. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16 69 8. Application Level Gateways . . . . . . . . . . . . . . . . . . 16 70 9. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17 71 10. ICMP Behavior . . . . . . . . . . . . . . . . . . . . . . . 18 72 11. Fragmentation of Packets . . . . . . . . . . . . . . . . . . 18 73 11.1 Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 18 74 11.2 Smaller Network MTU . . . . . . . . . . . . . . . . . . . 19 75 12. Receiving Fragmented Packets . . . . . . . . . . . . . . . . 19 76 13. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 19 77 13.1 Requirement Discussion . . . . . . . . . . . . . . . . . . 21 78 14. Security Considerations . . . . . . . . . . . . . . . . . . 23 79 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 80 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 82 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 18.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 84 18.2 Informational References . . . . . . . . . . . . . . . . . . 25 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 86 Intellectual Property and Copyright Statements . . . . . . . . 28 88 1. Applicability Statement 90 The purpose of this specification is to define a set of requirements 91 for NATs that would allow many applications, such as multimedia 92 communications or on-line gaming, to work consistently. Developing 93 NATs that meet this set of requirements will greatly increase the 94 likelihood that these applications will function properly. 96 The requirements of this specification apply generally to all NAT 97 variations, including the ones described in RFC 2663 [3] (Traditional 98 NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed 99 NATs). However, it is not within the scope of this specification to 100 address all issues specific to all possible NAT variations. 102 This document is meant to cover NATs of any size, from small 103 residential NATs to large Enterprise NATs. However, it should be 104 understood that Enterprise NATs normally provide much more than just 105 NAT capabilities: for example, they typically provide Firewall 106 capabilities. Firewalls is specifically out-of-scope of this 107 specification. However, this specification does cover the inherent 108 filtering aspects of NAT. Many large Enterprise NATs also have 109 additional requirements on security, multihoming and so forth, which 110 may impose further restrictions on the NAT capabilities. These extra 111 requirements specifically targeted at large Enterprise NATs are 112 outside the scope of this document. Furthermore, it is understood 113 that certain NATs, especially NATs that have to satisfy additional 114 requirements such as Firewall, may choose to be compliant to only 115 certain requirements from this specification. 117 Approaches using directly signaled control off the middle boxes such 118 as Midcom, UPnP, or in-path signaling are out of scope. 120 UDP Relays are out of the scope of this document. 122 Application aspects are out of scope as the focus is strictly on the 123 NAT itself. 125 This document only covers the UDP Unicast aspects of NAT traversal 126 and does not cover TCP, IPSEC, or other protocols. Since the 127 document is for UDP only, packet inspection below the UDP layer 128 (including RTP) is also out-of-scope. 130 2. Introduction 132 Network Address Translators (NAT) are well known to cause very 133 significant problems with applications that carry IP addresses in the 134 payload RFC 3027 [5]. Applications that suffer from this problem 135 include Voice Over IP and Multimedia Over IP (e.g., SIP [6] and H.323 137 [19]), as well as online gaming. 139 Many techniques are used to attempt to make realtime multimedia 140 applications, online games, and other applications work across NATs. 141 Application Level Gateways [3] are one such mechanism. STUN [7] 142 describes a UNilateral Self-Address Translation (UNSAF) mechanism 143 [2]. UDP Relays have also been used to enable applications across 144 NATs, but these are generally seen as a solution of last resort. ICE 145 [16] describes a methodology for using many of these techniques and 146 avoiding a UDP Relay unless the type of NAT is such that it forces 147 the use of such a UDP Relay. This specification defines requirements 148 for improving NATs. Meeting these requirements ensures that 149 applications will not be forced to use UDP media relay. 151 Several recommendations regarding NATs for Peer-to-Peer media were 152 made in [17] and this specification derives some of its requirements 153 from that draft. 155 As pointed out in UNSAF [2], "From observations of deployed networks, 156 it is clear that different NAT boxes' implementation vary widely in 157 terms of how they handle different traffic and addressing cases." 158 This wide degree of variability is one part of what contributes to 159 the overall brittleness introduced by NATs and makes it extremely 160 difficult to predict how any given protocol will behave on a network 161 traversing NATs. Discussions with many of the major NAT vendors have 162 made it clear that they would prefer to deploy NATs that were 163 deterministic and caused the least harm to applications while still 164 meeting the requirements that caused their customers to deploy NATs 165 in the first place. The problem the NAT vendors face is they are not 166 sure how best to do that or how to document how their NATs behave. 168 The goals of this document are to define a set of common terminology 169 for describing the behavior of NATs and to produce a set of 170 requirements on a specific set of behaviors for NATs. The 171 requirements represent what many vendors are already doing, and it is 172 not expected that it should be any more difficult to build a NAT that 173 meets these requirements or that these requirements should affect 174 performance. 176 This document forms a common set of requirements that are simple and 177 useful for voice, video, and games, which can be implemented by NAT 178 vendors. This document will simplify the analysis of protocols for 179 deciding whether or not they work in this environment and will allow 180 providers of services that have NAT traversal issues to make 181 statements about where their applications will work and where they 182 will not, as well as to specify their own NAT requirements. 184 3. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [1]. 190 A NAT that complies with all of the mandatory requirements of this 191 specification (i.e., the "MUST"), is "compliant with this 192 specification." A NAT that complies with all of the requirements of 193 this specification (i.e., including the "RECOMMENDED" and SHOULD) is 194 "fully compliant with all the mandatory and recommended requirements 195 of this specification." 197 Readers are urged to refer to RFC 2263 [3] for information on NAT 198 taxonomy and terminology. Traditional NAT is the most common type of 199 NAT device deployed. Readers may refer to RFC 3022 [4] for detailed 200 information on traditional NAT. Traditional NAT has two main 201 varieties - Basic NAT and Network Address/Port Translator (NAPT). 203 NAPT is by far the most commonly deployed NAT device. NAPT allows 204 multiple internal hosts to share a single public IP address 205 simultaneously. When an internal host opens an outgoing TCP or UDP 206 session through a NAPT, the NAPT assigns the session a public IP 207 address and port number so that subsequent response packets from the 208 external endpoint can be received by the NAPT, translated, and 209 forwarded to the internal host. The effect is that the NAPT 210 establishes a NAT session to translate the (private IP address, 211 private port number) tuple to (public IP address, public port number) 212 tuple and vice versa for the duration of the session. An issue of 213 relevance to peer-to-peer applications is how the NAT behaves when an 214 internal host initiates multiple simultaneous sessions from a single 215 (private IP, private port) endpoint to multiple distinct endpoints on 216 the external network. In this specification, the term "NAT" refers 217 to both "Basic NAT" and "Network Address/Port Translator (NAPT)". 219 This document uses the term "session" as defined in RFC 2663: 220 "TCP/UDP sessions are uniquely identified by the tuple of (source IP 221 address, source TCP/UDP ports, target IP address, target TCP/UDP 222 Port)." 224 This document uses the term "address and port mapping" as the 225 translation between an external address and port and an internal 226 address and port. Note that this is not the same as an "address 227 binding" as defined in RFC 2663. 229 RFC 3489 [7] defines a terminology for different NAT variations. In 230 particular, it uses the terms "Full Cone", "Restricted Cone", "Port 231 Restricted Cone" and "Symmetric" to refer to different variations of 232 NATs applicable to UDP only. This specification refers to specific 233 individual NAT behaviors instead of using the Cone/Symmetric 234 terminology. The relationship between the Cone/Symmetric terminology 235 and the individual behaviors defined in this specification is 236 described. 238 4. Network Address and Port Translation Behavior 240 This section describes the various NAT behaviors applicable to NAT. 242 4.1 Address and Port Mapping 244 When an internal endpoint opens an outgoing UDP session through a 245 NAT, the NAT assigns the session an external IP address and port 246 number so that subsequent response packets from the external endpoint 247 can be received by the NAT, translated and forwarded to the internal 248 endpoint. This is a mapping between an internal IP address and port 249 IP:port and external IP:port tuple. It establishes the translation 250 that will be performed by the NAT for the duration of the session. 251 For many applications, it is important to distinguish the behavior of 252 the NAT when there are multiple simultaneous sessions established to 253 different external endpoints. 255 The key behavior to describe is the criteria for re-use of a mapping 256 for new sessions to external endpoints, after establishing a first 257 mapping between an internal X:x address and port and an external 258 Y1:y1 address tuple. Let's assume that the internal IP address and 259 port X:x is mapped to X1':x1' for this first session. The endpoint 260 then sends from X:x to an external address Y2:y2 and gets a mapping 261 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 262 for various combinations of the relationship between Y1:y1 and Y2:y2 263 is critical for describing the NAT behavior. This arrangement is 264 illustrated in the following diagram: 266 E 267 +------+ +------+ x 268 | Y1 | | Y2 | t 269 +--+---+ +---+--+ e 270 | Y1:y1 Y2:y2 | r 271 +----------+ +----------+ n 272 | | a 273 X1':x1' | | X2':x2' l 274 +--+---+-+ 275 ...........| NAT |............... 276 +--+---+-+ I 277 | | n 278 X:x | | X:x t 279 ++---++ e 280 | X | r 281 +-----+ n 282 a 283 l 285 The following address and port mapping behavior are defined: 287 External NAT mapping is endpoint independent: 288 The NAT reuses the port mapping for subsequent sessions 289 initiated from the same internal IP address and port (X:x) to 290 any external IP address and port. Specifically, X1':x1' equals 291 X2':x2' for all values of Y2:y2. From an RFC 3489 NAT 292 perspective, this is a "Cone NAT" where the sub-type is really 293 based on the filtering behavior. 295 External NAT mapping is endpoint address dependent: 296 The NAT reuses the port mapping for subsequent sessions 297 initiated from the same internal IP address and port (X:x) only 298 for sessions to the same external IP address, regardless of the 299 external port. Specifically, X1':x1' equals X2':x2' if, and 300 only if, Y2 equals Y1. From an RFC 3489 NAT perspective, but 301 not necessarily a filtering perspective, this is a "Symmetric 302 NAT". 304 External NAT mapping is endpoint address and port dependent: 305 The NAT reuses the port mapping for subsequent sessions 306 initiated from the same internal IP address and port (X:x) only 307 for sessions to the same external and port. Specifically, 308 X1':x1' equals X2':x2' if, and only if, Y2:y2 equals Y1:y1. 309 From an RFC 3489 NAT perspective, but not necessarily a 310 filtering perspective, this is a "Symmetric NAT". 312 It is important to note that these three possible choices make no 313 difference to the security properties of the NAT. The security 314 properties are fully determined by which packets the NAT allows in 315 and which it does not. This is determined by the filtering behavior 316 in the filtering portions of the NAT. 318 Some NATs are capable of assigning IP addresses from a pool of IP 319 addresses on the external side of the NAT, as opposed to just a 320 single IP address. This is especially common with larger NATs. Some 321 NATs use the external IP address mapping in an arbitrary fashion 322 (i.e. randomly): one internal IP address could have multiple 323 external IP address mappings active at the same time for different 324 sessions. These NATs have an "IP address pooling" behavior of 325 "Arbitrary". Some large Enterprise NATs use an IP address pooling 326 behavior of "Arbitrary" as a means of hiding the IP address assigned 327 to specific endpoints by making their assignment less predictable. 328 Other NATs use the same external IP address mapping for all sessions 329 associated with the same internal IP address. These NATs have an "IP 330 address pooling" behavior of "Paired." NATs that use an "IP address 331 pooling" behavior of "arbitrary" can cause issues for applications 332 that use multiple ports from the same endpoint but do not negotiate 333 IP addresses individually (e.g., some applications using RTP and 334 RTCP). 336 4.2 Port Assignment 338 4.2.1 Port Assignment Behavior 340 This section uses the following diagram for reference. 342 E 343 +-------+ +-------+ x 344 | Y1 | | Y2 | t 345 +---+---+ +---+---+ e 346 | Y1:y1 Y2:y2 | r 347 +---------+ +---------+ n 348 | | a 349 X1':x1' | | X2':x2' l 350 +--+---+--+ 351 ...........| NAT |............... 352 +--+---+--+ I 353 | | n 354 +---------+ +---------+ t 355 | X1:x1 X2':x2 | e 356 +---+---+ +---+---+ r 357 | X1 | | X2 | n 358 +-------+ +-------+ a 359 l 361 Some NATs attempt to preserve the port number used internally when 362 assigning a mapping to an external IP address and port (e.g., 363 x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A 364 basic NAT, for example, will preserve the same port and will assign a 365 different IP address from a pool of external IP addresses in case of 366 port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only 367 possible as long as the NAT has enough external IP addresses. If the 368 port x is already in use on all available external IP addresses, then 369 the NAT needs to switch from Basic NAT to a Network Address and Port 370 Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or 371 a mapping of X1:x to X':x1' and X2:x to X':x2'). This port 372 assignment behavior is referred to as "port preservation". It does 373 not guarantee that the external port x' will always be the same as 374 the internal port x but only that the NAT will preserve the port if 375 possible. 377 A NAT that does not attempt to make the external port numbers match 378 the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to 379 X':x2') is referred to as "no port preservation". 381 Some NATs use "Port overloading", i.e. they always use port 382 preservation even in the case of collision (i.e., X'=X1'=X2' and 383 x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x). 384 These NATs rely on the source of the response from the external 385 endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal 386 endpoint (X1 or X2). Port overloading fails if the two internal 387 endpoints are establishing sessions to the same external destination. 389 Most applications fail in some cases with "Port Overloading". It is 390 clear that "Port Overloading" behavior will result in many problems. 391 For example it will fail if two internal endpoints try to reach the 392 same external destination, e.g., a server used by both endpoints such 393 as a SIP proxy, or a web server, etc.) 395 When NATs do allocate a new source port, there is the issue of which 396 IANA-defined range of port to choose. The ranges are "well-known" 397 from 0 to 1023, "registered" from 1024 to 49151, and 398 "dynamic/private" from 49152 through 65535. For most protocols, 399 these are destination ports and not source ports, so mapping a source 400 port to a source port that is already registered is unlikely to have 401 any bad effects. Some NATs may choose to use only the ports in the 402 dynamic range; the only down side of this practice is that it limits 403 the number of ports available. Other NAT devices may use everything 404 but the well-known range and may prefer to use the dynamics range 405 first or possibly avoid the actual registered ports in the registered 406 range. Other NATs preserve the port range if it is in the well-known 407 range. It should be noted that port 0 is reserved and must not be 408 used. 410 4.2.2 Port Parity 412 Some NATs preserve the parity of the UDP port, i.e., an even port 413 will be mapped to an even port, and an odd port will be mapped to an 414 odd port. This behavior respects the RFC 3550 [8] rule that RTP use 415 even ports, and RTCP use odd ports. Some NATs preserve the parity of 416 the UDP port, i.e., an even port will be mapped to an even port, and 417 an odd port will be mapped to an odd port. This behavior respects 418 the RFC 3550 rule that RTP use even ports and RTCP use odd ports when 419 the application takes a single port number as a parameter and derives 420 the RTP and RTCP port pair from that number. RFC 3550 allows any 421 port numbers to be used for RTP and RTCP if the two numbers are 422 specified separately, for example using RFC 3605 [9]. However, some 423 implementations do not include RFC 3605 and do not recognize when the 424 peer has specified the RTCP port separately using RFC 3605. If such 425 an implementation receives an odd RTP port number from the peer 426 (perhaps after having been translated by a NAT), and then follows the 427 RFC 3550 rule to change the RTP port to the next lower even number, 428 this would obviously result in the loss of RTP. NAT-friendly 429 application aspects are outside the scope of this document. It is 430 expected that this issue will fade away with time, as implementations 431 improve. Preserving the port parity allows for supporting 432 communication with peers that do not support explicit specification 433 of both RTP and RTCP port numbers. 435 4.2.3 Port Contiguity 437 Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. 439 These NATs do things like sequential assignment, port reservation and 440 so forth. Sequential port assignment assumes that the application 441 will open a mapping for RTP first and then open a mapping for RTCP. 442 It is not practical to enforce this requirement on all applications. 443 Furthermore, there is a glare problem if many applications (or 444 endpoints) are trying to open mapping simultaneously. Port 445 reservation is also problematic since it is wasteful, especially 446 considering that a NAT can not reliably distinguish between RTP over 447 UDP and other UDP packets where there is no contiguity rule. For 448 those reasons, it would be too complex to attempt to preserve the 449 contiguity rule by suggesting specific NAT behavior, and it would 450 certainly break the deterministic behavior rule. 452 In order to support both RTP and RTCP, it will therefore be necessary 453 that applications follows rules to negotiate both RTP and RTCP 454 separately, and account for the very real possibility that the 455 RTCP=RTP+1 rule will be broken. As this is an application 456 requirement, it is outside of the scope of this document. 458 4.3 Mapping Refresh Direction 460 NAT UDP mapping timeout implementations vary but include the timer's 461 value and the way the mapping timer is refreshed to keep the mapping 462 alive. 464 The mapping timer is defined as the time a mapping will stay active 465 without packets traversing the NAT. There is great variation in the 466 values used by different NATs. 468 Some NATs keep the mapping active (i.e., refresh the timer value) 469 when a packet goes from the internal side of the NAT to the external 470 side of the NAT. This is referred to as having a NAT Outbound 471 refresh behavior of "True". 473 Some NATs keep the mapping active when a packet goes from the 474 external side of the NAT to the internal side of the NAT. This is 475 referred to as having a NAT Inbound Refresh Behavior of "True". 477 Some NATs keep the mapping active on both, in which case both 478 properties are "True". 480 4.4 Mapping Refresh Scope 482 If the mapping is refreshed for all sessions on that mapping by any 483 outbound traffic, the NAT is said to have a NAT Mapping Refresh Scope 484 of "Per mapping". If the mapping is refreshed only on a specific 485 session on that particular mapping by any outbound traffic, the NAT 486 is said to have a "Per session" NAT mapping Refresh Scope. 488 5. Filtering Behavior 490 This section describes various filtering behaviors observed in NATs. 492 5.1 Filtering of Unsolicited Packets 494 When an internal endpoint opens an outgoing UDP session through a 495 NAT, the NAT assigns a filtering rule for the mapping between an 496 internal IP:port (X:x) and external IP:port (Y:y) tuple. 498 The key behavior to describe is what criteria are used by the NAT to 499 filter packets originating from specific external endpoints. 501 External filtering is endpoint independent: 502 The NAT filters out only packets not destined to the internal 503 address and port X:x, regardless of the external IP address and 504 port source (Z:z). The NAT forwards any packets destined to 505 X:x. In other words, sending packets from the internal side of 506 the NAT to any external IP address is sufficient to allow any 507 packets back to the internal endpoint. From an RFC 3489 508 filtering perspective, this is a "Full Cone NAT". 510 External filtering is endpoint address dependent: 511 The NAT filters out packets not destined to the internal 512 address X:x. Additionally, the NAT will filter out packets 513 from Y:y destined for the internal endpoint X:x if X:x has not 514 sent packets to Y previously (independently of the port used by 515 Y). In other words, for receiving packets from a specific 516 external endpoint, it is necessary for the internal endpoint to 517 send packets first to that specific external endpoint's IP 518 address. From an RFC 3489 filtering perspective, this is a 519 "Restricted Cone NAT". 521 External filtering is endpoint address and port dependent: 522 This is similar to the previous behavior, except that the 523 external port is also relevant. The NAT filters out packets 524 not destined for the internal address X:x. Additionally, the 525 NAT will filter out packets from Y:y destined for the internal 526 endpoint X:x if X:x has not sent packets to Y:y previously. In 527 other words, for receiving packets from a specific external 528 endpoint, it is necessary for the internal endpoint to send 529 packets first to that external endpoint's IP address and port. 530 From an RFC 3489 filtering perspective, this is either a "Port 531 Restricted Cone NAT" or a "Symmetric NAT" as they both have the 532 same filtering behavior. 534 5.2 NAT Filter Refresh 536 The time for which a NAT filter is valid can be refreshed based on 537 packets that are inbound, outbound, or going either direction. In 538 the case of "External Filtering" of "Address dependent" or "Address 539 and port dependent" NATs, the scope of the refresh could include the 540 filters for just the particular port and destination or for all the 541 ports and destinations sharing the same external address and port on 542 the NAT. 544 6. Relationship with Cone and Symmetric NAT Terminology 546 This section describes the relationship between the Network Address 547 and Port and Filtering behaviors defined in this document, and the 548 Cone/Symmetric NAT terminology described in RFC 3489. 550 RFC 3489 defines the following variations. They have been slightly 551 paraphrased for emphasizing the mapping behavior and the filtering 552 behavior. 554 Full Cone: 555 1. A full cone NAT is one where all requests from the same 556 internal IP address and port are mapped to the same external 557 IP address and port. 558 2. Furthermore, any external host can send a packet to the 559 internal host, by sending a packet to the mapped external 560 address. 562 Restricted Cone: 563 1. A restricted cone NAT is one where all requests from the same 564 internal IP address and port are mapped to the same external 565 IP address and port. 566 2. Unlike a full cone NAT, an external host (with IP address X) 567 can send a packet to the internal host only if the internal 568 host had previously sent a packet to IP address X. 570 Port Restricted Cone: 571 1. A port restricted cone NAT is one where all requests from the 572 same internal IP address and port are mapped to the same 573 external IP address and port. 574 2. The restriction includes port numbers. Specifically, an 575 external host can send a packet, with source IP address X and 576 source port P, to the internal host only if the internal host 577 had previously sent a packet to IP address X and port P. 579 Symmetric: 580 1. A symmetric NAT is one where all requests from the same 581 internal IP address and port, to a specific destination IP 582 address and port, are mapped to the same external IP address 583 and port. If the same host sends a packet with the same 584 source address and port, but to a different destination, a 585 different mapping is used. 586 2. Furthermore, only the external host that receives a packet can 587 send a UDP packet back to the internal host. 589 Unfortunately, this terminology defined in RFC 3489 has been the 590 source of much confusion. This terminology does not distinguish 591 between the mapping behavior (conditions 1 above) and the filtering 592 behavior (conditions 2 above). 594 The inferred definition of "Cone NAT" is quite clear since the same 595 definition is used for all variations of Cone NAT: 596 o A cone NAT is one where all requests from the same internal IP 597 address and port are mapped to the same address and port. 599 A "Cone NAT" therefore only refers to the Network Address and Port 600 mapping behavior. This maps to the "External NAT mapping is endpoint 601 independent" defined in this specification. 603 The terms "Full", "Restricted", "Port Restricted" refers to their 604 filtering behavior. They map respectively to the "External filtering 605 is endpoint independent", "External filtering is endpoint address 606 dependent" and "External filtering is address and port dependent" 607 behaviors. 609 However, the Symmetric NAT definition is more troublesome as it 610 bundles together the mapping and the filtering definitions. 611 Condition 1 of the Symmetric NAT definition is the NAT behavior and 612 condition 2 is the filtering behavior. However, they are not 613 necessarily dependent: we have observed NATs that will conform to 614 condition (1) but not to (2). Using RFC 3489, this type of NAT would 615 be detected as a "Cone NAT" since it uses condition (2). Using a 616 different algorithm such as the one described in NATCHECK [20] which 617 uses condition (1), the same NAT would be detected as a "Symmetric 618 NAT". If the endpoint receiving the media has a permissive policy on 619 accepting media, condition (2) is more appropriate, but if it has a 620 restrictive policy, condition (1) is more appropriate. Some view the 621 "real" definition of Symmetric NAT to be condition 1 while others 622 believes it is condition 2. 624 It was found that many devices' behaviors do not exactly fit into the 625 described variations. For example, a device could be symmetric from 626 a filtering point of view and Cone from a NAT point of view. Other 627 aspects of NATs are not covered by this terminology: for example, 628 many NATs will switch over from basic NAT (preserving ports) to NAPT 629 (mapping ports) in order to preserve ports when possible. 631 The relationship between the RFC 3489 and the behaviors described in 632 this document is easier to describe in a table: 634 ------------------------------------------------ 635 || External Filtering Behavior | 636 -------------------++---------------------------------------------| 637 | External NAT || Endpoint | Endpoint | Endpoint | 638 | Mapping Behavior || Independent | Address | Address/Port | 639 | || | Dependent | Dependent | 640 |=================================================================| 641 | Endpoint || Full | Restricted | Port Restricted | 642 | Independent || Cone | Cone | Cone | 643 |------------------++-------------+-------------+-----------------| 644 | Endpoint Address || Symmetric~ | Symmetric~ | Symmetric~ | 645 | Dependent || (a) | (a, 2) | (a, b) | 646 |------------------++-------------+-------------+-----------------| 647 | Endpoint Address || Symmetric~ | Symmetric | Symmetric~ | 648 | /Port Dependent || (1) | (1, 2) | (1, b) | 649 ------------------------------------------------------------------- 651 Where: 652 1. Satisfies condition 1 for Symmetric NAT: "All requests from the 653 same internal IP address and port to a specific destination 654 address and port are mapped to the same external IP address and 655 port. If a host sends a packet with the same source address and 656 port to different destination addresses or ports, a different 657 mapping is used for each." 658 2. Satisfies condition 2 for Symmetric NAT: "Furthermore, only the 659 external host that receives a packet can send a UDP packet back 660 to the internal host." 662 And: 663 a) This is a variation on condition (1), but where the destination 664 port is not of any consequence. 665 b) This one is a variation on condition (2) which is more restrictive 666 and not covered in the definition of Symmetric: "Furthermore, only 667 packets originating from a port of the external host that has 668 received packets already on that port will be forwarded." 670 If conditions (1) and (2), but not (b) are met, this is a Symmetric 671 NAT as per the definition of RFC 3489. This is denoted as 672 "Symmetric" in the table. Otherwise, the NAT is not quite Symmetric 673 and is denoted as "Symmetric~". In some cases these Symmetric~ NATs 674 are slightly more restrictive than a real Symmetric NAT, and in other 675 cases they are more permissive. 677 7. 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 an implementation 711 that is expecting an external IP address and port. 713 8. Application Level Gateways 715 Certain NATs have implemented Application Level Gateways (ALGs) for 716 various protocols, including protocols for negotiating peer-to-peer 717 UDP sessions. 719 Certain NATs have these ALGs turned on permanently, others have them 720 turned on by default but let them be be turned off, and others have 721 them turned off by default but let them be turned on. 723 NAT ALGs may interfere with UNSAF methods and must therefore be used 724 with extreme caution. 726 9. Deterministic Properties 728 The classification of NATs is further complicated by the fact that 729 under some conditions the same NAT will exhibit different behaviors. 730 This has been seen on NATs that preserve ports or have specific 731 algorithms for selecting a port other than a free one. If the 732 external port that the NAT wishes to use is already in use by another 733 session, the NAT must select a different port. This results in 734 different code paths for this conflict case, which results in 735 different behavior. 737 For example, if three hosts X1, X2, and X3 all send from the same 738 port x, through a port preserving NAT with only one external IP 739 address, called X1', the first one to send (i.e., X1) will get an 740 external port of x but the next two will get x2' and x3' (where these 741 are not equal to x). There are NATs where the External NAT mapping 742 characteristics and the External Filter characteristics change 743 between the X1:x and the X2:x mapping. To make matters worse, there 744 are NATs where the behavior may be the same on the X1:x and X2:x 745 mappings but different on the third X3:x mapping. 747 Some NATs that try to reuse external ports flow from two internal IP 748 addresses to two different external IP addresses. For example, X1:x 749 is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not 750 equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x 751 to X1':x. This works in the case where the NAT mapping is address 752 port dependent. However some NATs change their behavior when this 753 type of port reuse is happening. The NAT may look like it has NAT 754 mappings that are independent when this type of reuse is not 755 happening but may change to Address Port Dependent when this reuse 756 happens. 758 Any NAT that changes the NAT mapping or the External Filtering at any 759 point in time under any particular conditions is referred to as a 760 "non-deterministic" NAT. NATs that don't are called "deterministic". 762 Non-deterministic NATs generally change behavior when a conflict of 763 some sort happens, i.e. when the port that would normally be used is 764 already in use by another mapping. The NAT mapping and External 765 Filtering in the absence of conflict is referred to as the Primary 766 behavior. The behavior after the first conflict is referred to as 767 Secondary and after the second conflict is referred to as Tertiary. 768 No NATs have been observed that change on further conflicts but it is 769 certainly possible that they exist. 771 10. ICMP Behavior 773 When a NAT sends a UDP packet towards a host on the other side of the 774 NAT, an ICMP message may be sent in response to that packet. That 775 ICMP message may be sent by the destination host or by any router 776 along the network path. The NAT's default configuration SHOULD NOT 777 filter ICMP messages based on their source IP address. Such ICMP 778 messages SHOULD be rewritten by the NAT (specifically the IP headers 779 and the ICMP payload) and forwarded to the appropriate internal or 780 external host. The NAT needs to perform this function for as long as 781 the UDP mapping is active. Receipt of any sort of ICMP message MUST 782 NOT destroy the NAT binding. A NAT which performs the functions 783 described in the paragraph above is referred to as "UDP Support 784 Destination Unreachable". 786 There is no significant security advantage to blocking ICMP 787 Destination Unreachable packets. 789 Additionally, blocking ICMP Destination Unreachable packets can 790 interfere with application failover, UDP Path MTU Discovery (see 791 RFC1191 [10] and RFC1435 [15]), and with traceroute. Blocking any 792 ICMP message is discouraged, and blocking ICMP Destination 793 Unreachable is strongly discouraged. 795 11. Fragmentation of Packets 797 When sending a packet, there are two situations that may cause IP 798 fragmentation for packets from the inside to the outside. It is 799 worth noting that many IP stacks do not use Path MTU Discovery with 800 UDP packets. 802 11.1 Smaller Adjacent MTU 804 The first situation is when the MTU of the adjacent link is too 805 small. This can occur if the NAT is doing PPPoE, or if the NAT has 806 been configured with a small MTU to reduce serialization delay when 807 sending large packets and small, higher-priority packets. 809 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 810 (DF=0). 812 If the packet has DF=1, the NAT should send back an ICMP message 813 "fragmentation needed and DF set" message to the host as described in 814 RFC 792 [13]. 816 If the packet has DF=0, the NAT should fragment the packet and send 817 the fragments, in order. This is the same function a router performs 818 in a similar situation RFC 1812 [14]. 820 NATs that operate as described in this section are described as 821 "Supports Fragmentation" (abbreviated SF). 823 11.2 Smaller Network MTU 825 The second situation is when the MTU on some link in the middle of 826 the network that is not the adjacent link is too small. If DF=0, the 827 router adjacent to the small-MTU segment will fragment the packet and 828 forward the fragments RFC 1812. 830 If DF=1, the router adjacent to the small-MTU segment will send the 831 ICMP message "fragmentation needed and DF set" back towards the NAT. 832 The NAT needs to forward this ICMP message to the inside host. 834 The classification of NATs that perform this behavior is covered in 835 the ICMP section of this document. 837 12. Receiving Fragmented Packets 839 For a variety of reasons, a NAT may receive a fragmented UDP packet. 840 The IP packet containing the UDP header could arrive first or last 841 depending on network conditions, packet ordering, and the 842 implementation of the IP stack that generated the fragments. 844 A NAT that is capable only of receiving UDP fragments in order (that 845 is, with the UDP header in the first packet) and forwarding each of 846 the fragments to the internal host is described as "Received 847 Fragments Ordered". 849 A NAT that is capable of receiving UDP fragments in or out of order 850 and forwarding the individual packets (or a reassembled packet) to 851 the internal host is referred to as "Receive Fragments Out of Order". 852 See the Security Considerations section of this document for a 853 discussion of this behavior. 855 A NAT that is neither of these is referred to as "Receive Fragments 856 None". 858 13. Requirements 860 The requirements in this section are aimed at minimizing the 861 complications caused by NATs to applications such as realtime 862 communications and online gaming. 864 It should be understood, however, that applications normally do not 865 know in advance if the NAT conforms to the recommendations defined in 866 this section. Peer-to-peer media applications still need to use 867 normal procedures such as ICE [16] . 869 A NAT that supports all of the mandatory requirements of this 870 specification (i.e., the "MUST"), is "compliant with this 871 specification." A NAT that supports all of the requirements of this 872 specification (i.e., included the "RECOMMENDED") is "fully compliant 873 with all the mandatory and recommended requirements of this 874 specification." 876 REQ-1 A NAT MUST have an "External NAT mapping is endpoint 877 independent" behavior. 878 REQ-2 It is RECOMMENDED that a NAT have an "IP address pooling" 879 behavior of "Paired". Note that this requirement is not 880 applicable to NATs that do not support IP address pooling. 881 REQ-3 It is RECOMMENDED that a NAT have a "Port assignment" behavior 882 of "No port preservation". 883 a) NAT MAY use a "Port assignment" behavior of "Port 884 preservation". 885 b) A NAT MUST NOT have a "Port assignment" behavior of "Port 886 overloading". 887 c) If the host's source port was in the range 1-1023, it is 888 RECOMMENDED the NAT's source port also be in the same 889 range. If the host's source port was in the range 890 1024-65535, it is RECOMMENDED that the NAT's source port 891 also be in that range. 892 REQ-4 It is RECOMMENDED that a NAT have a "Port parity preservation" 893 behavior of "Yes". 894 REQ-5 A NAT UDP mapping timer MUST NOT expire in less than 2 895 minutes. 896 a) The value of the NAT UDP mapping timer MAY be configurable. 897 b) A default value of 5 minutes for the NAT UDP mapping timer 898 is RECOMMENDED. 899 REQ-6 The NAT mapping Refresh Direction MUST have a "NAT Outbound 900 refresh behavior" of "True". 901 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 902 refresh behavior" of "True". 903 b) The NAT mapping Refresh Direction MUST have a "NAT refresh 904 method behavior" of "Per mapping" (i.e. refresh all 905 sessions active on a particular mapping). 906 REQ-7 It is RECOMMENDED that a NAT have an "External filtering is 907 endpoint address dependent" behavior. 908 REQ-8 A NAT MUST support "Hairpinning". 909 a) A NAT Hairpinning behavior MUST be "External source IP 910 address and port". 911 REQ-9 If a NAT includes ALGs, it is RECOMMENDED that all of those 912 ALGs be disabled by default. 913 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT 914 allow the user to enable or disable each ALG separately. 916 REQ-10 A NAT MUST have deterministic behavior, i.e., it MUST NOT 917 change the NAT mapping or the External External Filtering 918 Behavior at any point in time or under any particular 919 conditions. 920 REQ-11 It is RECOMMENDED that a NAT support ICMP Destination 921 Unreachable. 922 a) The ICMP timeout SHOULD be greater than 2 seconds. 923 REQ-12 A NAT MUST support fragmentation of packets larger than link 924 MTU. 925 REQ-13 A NAT MUST support receiving in order fragments, so it MUST be 926 "Received Fragment Ordered" or "Received Fragment Out of 927 Order". 928 a) A NAT MAY support receiving fragmented packets that are out 929 of order and be of type "Received Fragment Out of Order". 931 13.1 Requirement Discussion 933 This section describes why each of these requirements was chosen and 934 the consequences of violating any of them: 936 REQ-1 In order for UNSAF methods to work, REQ-1 needs to be met. 937 Failure to meet REQ-1 will force the use of a Media Relay 938 which is very often impractical. 939 REQ-2 This will allow applications that use multiple ports 940 originating from the same internal IP address to also have the 941 same external IP address. This is to avoid breaking 942 peer-to-peer applications which are not capable of negotiating 943 the IP address for RTP and the IP address for RTCP separately. 944 As such it is envisioned that this requirement will become 945 less important as applications become NAT-friendlier with 946 time. The main reason why this requirement is here is because 947 in a peer-to-peer application, you are subject to the other 948 peer's mistake. In particular, in the context of SIP, if my 949 application supports the extensions defined in RFC 3605 [9] 950 for indicating RTP and RTCP addresses and ports separately, 951 but the other peer does not, there may still be breakage in 952 the form of lost of the RTP stream. This requirements will 953 avoid the loss of RTP in this context, although the loss of 954 RTCP may be inevitable in this particular example. It is also 955 worth noting that RFC 3605 is unfortunately not a mandatory 956 part of SIP (i.e., RFC 3261). This requirement will therefore 957 address a particularly nasty problem that will prevail for a 958 significant amount of time. 959 REQ-3 NATs that implement port preservation have to deal with 960 conflicts on ports, and the multiple code paths this 961 introduces often result in nondeterministic behavior. 963 c) Port preservation can work, but the NAT implementors need 964 to be very careful that it does not become a 965 nondeterministic NAT. 966 d) REQ-2b must be met in order to enable two applications on 967 the internal side of the NAT both to use the same port to 968 try to communicate with the same destination. 969 e) Certain applications expect the source UDP port to be in 970 the well-known range. See RFC 2623 for an example. 971 REQ-4 This is to avoid breaking peer-to-peer applications which do 972 not explicity and separately specify RTP and RTCP port numbers 973 and which follow the RFC 3550 rule to decrement an odd RTP 974 port to make it even. The same considerations as per the IP 975 address pooling requirement apply. 976 REQ-5 This requirement is to ensure that the timeout is long enough 977 to avoid too frequent timer refresh packets. 978 a) Configuration is desirable for adapting to specific 979 networks and troubleshooting. 980 b) This default is to avoid too frequent timer refresh 981 packets. 982 REQ-6 Outbound refresh is necessary for allowing the client to keep 983 the mapping alive. 984 a) Inbound refresh may be useful for applications where there 985 is no outgoing UDP traffic. 986 b) Using the refresh on a per mapping basis avoids the need 987 for separate keep alive packets for all the available 988 sessions. 989 REQ-7 Filtering based on the IP address is felt to have the maximum 990 balance between security and usefulness. Filtering 991 independently of the external IP address and port is not as 992 secure: an unauthorized packet could get at a specific port 993 while the port was kept open if it was lucky enough to find 994 the port open. In theory, filtering based on both IP address 995 and port is more secure than filtering based only on the IP 996 address (because the external endpoint could in reality be two 997 endpoints behind another NAT, where one of the two endpoints 998 is an attacker). However, such a restrictive policy could 999 interfere with certain applications that use more than one 1000 port. 1001 REQ-8 This requirement is to allow communications between two 1002 endpoints behind the same NAT when they are trying each 1003 other's external IP addresses. 1004 a) Using the external IP address is necessary for applications 1005 with a restrictive policy of not accepting packets from IP 1006 addresses that differ from what is expected. 1007 REQ-9 NAT ALGs may interfere with UNSAF methods. 1009 a) This requirement allows the user to enable ALGs which are 1010 necessary to aid operation of some applications without 1011 enabling ALGs which interfere with operation of other 1012 applications. 1013 REQ-10 Non-deterministic NATs are very difficult to troubleshoot 1014 because they require more intensive testing. This 1015 non-deterministic behavior is the root cause of much of the 1016 uncertainty that NATs introduce about whether or not 1017 applications will work. 1018 REQ-11 This is easy to do, is used for many things including MTU 1019 discovery and rapid detection of error conditions, and has no 1020 negative consequences. 1021 REQ-12 Fragmented packets become more common with large video packets 1022 and should continue to work. Applications can use MTU 1023 discovery to work around this problem. 1024 REQ-13 See Security Considerations. 1026 14. Security Considerations 1028 NATs are often deployed to achieve security goals. Most of the 1029 recommendations and requirements in this document do not affect the 1030 security properties of these devices, but a few of them do have 1031 security implications and are discussed in this section. 1033 This work recommends that the timers for mapping be refreshed only on 1034 outgoing packets and does not make recommendations about whether or 1035 not inbound packets should update the timers. If inbound packets 1036 update the timers, an external attacker can keep the mapping alive 1037 forever and attack future devices that may end up with the same 1038 internal address. A device that was also the DHCP server for the 1039 private address space could mitigate this by cleaning any mappings 1040 when a DHCP lease expired. For unicast UDP traffic (the scope of 1041 this document), it may not seem relevant to support inbound timer 1042 refresh; however, for multicast UDP, the question is harder. It is 1043 expected that future documents discussing NAT behavior with multicast 1044 traffic will refine the requirements around handling of the inbound 1045 refresh timer. Some devices today do update the timers on inbound 1046 packets. 1048 This work recommends that the NAT filters be specific to the external 1049 IP only and not the external IP and port. It can be argued that this 1050 is less secure than using the IP and port. Devices that wish to 1051 filter on IP and port do still comply with these requirements. 1053 Non-deterministic NATs are risky from a security point of view. They 1054 are very difficult to test because they are, well, non-deterministic. 1055 Testing by a person configuring one may result in the person thinking 1056 it is behaving as desired, yet under different conditions, which an 1057 attacker can create, the NAT may behave differently. These 1058 requirements recommend that devices be deterministic. 1060 The work requires that NATs have an "external NAT mapping is endpoint 1061 independent" behavior. This does not reduce the security of devices. 1062 Which packets are allowed to flow across the device is determined by 1063 the external filtering behavior, which is independent of the mapping 1064 behavior. 1066 When a fragmented packet is received from the external side and the 1067 packets are out of order so that the initial fragment does not arrive 1068 first, many systems simply discard the out of order packets. 1069 Moreover, since some networks deliver small packets ahead of large 1070 ones, there can be many out of order fragments. NATs that are 1071 capable of delivering these out of order packets are possible but 1072 they need to store the out of order fragments, which can open up a 1073 DoS opportunity. Fragmentation has been a tool used in many attacks, 1074 some involving passing fragmented packets through NATs and others 1075 involving DoS attacks based on the state needed to reassemble the 1076 fragments. NAT implementers should be aware of RFC 3128 [12] and RFC 1077 1858 [11]. 1079 15. IANA Considerations 1081 There are no IANA considerations. 1083 16. IAB Considerations 1085 The IAB has studied the problem of "Unilateral Self Address Fixing", 1086 which is the general process by which a client attempts to determine 1087 its address in another realm on the other side of a NAT through a 1088 collaborative protocol reflection mechanism [2]. 1090 This specification does not in itself constitute an UNSAF 1091 application. It consists of a series of requirements for NATs aimed 1092 at minimizing the negative impact that those devices have on 1093 peer-to-peer media applications, especially when those applications 1094 are using UNSAF methods. 1096 Section 3 of UNSAF lists several practical issues with solutions to 1097 NAT problems. This document makes recommendations to reduce the 1098 uncertainty and problems introduced by these practical issues with 1099 NATs. In addition, UNSAF lists five architectural considerations. 1100 Although this is not an UNSAF proposal, it is interesting to consider 1101 the impact of this work on these architectural considerations. 1103 Arch-1: The scope of this is limited to UDP packets in NATs like the 1104 ones widely deployed today. The "fix" helps constrain the 1105 variability of NATs for true UNSAF solutions such as STUN. 1106 Arch-2: This will exit at the same rate that NATs exit. It does not 1107 imply any protocol machinery that would continue to live 1108 after NATs were gone or make it more difficult to remove 1109 them. 1110 Arch-3: This does not reduce the overall brittleness of NATs but will 1111 hopefully reduce some of the more outrageous NAT behaviors 1112 and make it easer to discuss and predict NAT behavior in 1113 given situations. 1114 Arch-4: This work and the results [18] of various NATs represent the 1115 most comprehensive work at IETF on what the real issues are 1116 with NATs for applications like VoIP. This work and STUN 1117 have pointed out more than anything else the brittleness NATs 1118 introduce and the difficulty of addressing these issues. 1119 Arch-5: This work and the test results [18] provide a reference model 1120 for what any UNSAF proposal might encounter in deployed NATs. 1122 17. Acknowledgments 1124 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 1125 Dan Kegel for the their draft [17] on peer-to-peer communications 1126 accross a NAT, from which a lot of the material in this specification 1127 is derived. 1129 Dan Wing contributed substantial text on IP fragmentation and ICMP 1130 behavior. 1132 Thanks to Rohan Mahy, Jonathan Rosenberg, Mary Barnes, Melinda Shore, 1133 Lyndsay Campbell, Geoff Huston, Jiri Kuthan, Harald Welte, Steve 1134 Casner, Robert Sanders and Spencer Dawkins for their important 1135 contributions. 1137 18. References 1139 18.1 Normative References 1141 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1142 Levels", BCP 14, RFC 2119, March 1997. 1144 [2] Daigle, L. and IAB, "IAB Considerations for UNilateral 1145 Self-Address Fixing (UNSAF) Across Network Address Translation", 1146 RFC 3424, November 2002. 1148 18.2 Informational References 1150 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1151 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1153 [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1154 Translator (Traditional NAT)", RFC 3022, January 2001. 1156 [5] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 1157 IP Network Address Translator", RFC 3027, January 2001. 1159 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1160 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1161 Session Initiation Protocol", RFC 3261, June 2002. 1163 [7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1164 Simple Traversal of User Datagram Protocol (UDP) Through 1165 Network Address Translators (NATs)", RFC 3489, March 2003. 1167 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1168 "RTP: A Transport Protocol for Real-Time Applications", RFC 1169 3550, July 2003. 1171 [9] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1172 Session Description Protocol (SDP)", RFC 3605, October 2003. 1174 [10] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1175 November 1990. 1177 [11] Ziemba, G., Reed, D. and P. Traina, "Security Considerations 1178 for IP Fragment Filtering", RFC 1858, October 1995. 1180 [12] Miller, I., "Protection Against a Variant of the Tiny Fragment 1181 Attack (RFC 1858)", RFC 3128, June 2001. 1183 [13] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1184 792, September 1981. 1186 [14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1187 June 1995. 1189 [15] Knowles, S., "IESG Advice from Experience with Path MTU 1190 Discovery", March 1993. 1192 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1193 Methodology for Network Address Translator (NAT) Traversal for 1194 the Session Initiation Protocol (SIP)", 1195 draft-ietf-mmusic-ice-03 (work in progress), October 2004. 1197 [17] Ford, B., Srisuresh, P. and D. Kegel, "State of 1198 Peer-to-Peer(P2P) communication across Network Address 1199 Translators(NATs)", draft-srisuresh-behave-p2p-state-00 (work 1200 in progress), December 2004. 1202 [18] Jennings, C., "NAT Classification Results using STUN", 1203 draft-jennings-midcom-stun-results-02 (work in progress), 1204 October 2004. 1206 [19] "Packet-based Multimedia Communications Systems", ITU-T 1207 Recommendation H.323, July 2003. 1209 [20] Ford, B. and D. Andersen, "Nat Check Web Site: 1210 http://midcom-p2p.sourceforge.net", June 2004. 1212 Authors' Addresses 1214 Francois Audet (editor) 1215 Nortel Networks 1216 4655 Great America Parkway 1217 Santa Clara, CA 95054 1218 US 1220 Phone: +1 408 495 3756 1221 EMail: audet@nortel.com 1223 Cullen Jennings 1224 Cisco Systems 1225 170 West Tasman Drive 1226 MS: SJC-21/2 1227 San Jose, CA 95134 1228 US 1230 Phone: +1 408 902 3341 1231 EMail: fluffy@cisco.com 1233 Intellectual Property Statement 1235 The IETF takes no position regarding the validity or scope of any 1236 Intellectual Property Rights or other rights that might be claimed to 1237 pertain to the implementation or use of the technology described in 1238 this document or the extent to which any license under such rights 1239 might or might not be available; nor does it represent that it has 1240 made any independent effort to identify any such rights. Information 1241 on the procedures with respect to rights in RFC documents can be 1242 found in BCP 78 and BCP 79. 1244 Copies of IPR disclosures made to the IETF Secretariat and any 1245 assurances of licenses to be made available, or the result of an 1246 attempt made to obtain a general license or permission for the use of 1247 such proprietary rights by implementers or users of this 1248 specification can be obtained from the IETF on-line IPR repository at 1249 http://www.ietf.org/ipr. 1251 The IETF invites any interested party to bring to its attention any 1252 copyrights, patents or patent applications, or other proprietary 1253 rights that may cover technology that may be required to implement 1254 this standard. Please address the information to the IETF at 1255 ietf-ipr@ietf.org. 1257 Disclaimer of Validity 1259 This document and the information contained herein are provided on an 1260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1262 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1263 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1264 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1267 Copyright Statement 1269 Copyright (C) The Internet Society (2005). This document is subject 1270 to the rights, licenses and restrictions contained in BCP 78, and 1271 except as set forth therein, the authors retain all their rights. 1273 Acknowledgment 1275 Funding for the RFC Editor function is currently provided by the 1276 Internet Society.