idnits 2.17.1 draft-ietf-behave-nat-udp-02.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 1159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1149. ** 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 (June 27, 2005) is 6877 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') == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-04 == Outdated reference: A later version (-04) exists of draft-jennings-behave-test-results-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE F. Audet, Ed. 3 Internet-Draft Nortel Networks 4 Expires: December 29, 2005 C. Jennings 5 Cisco Systems 6 June 27, 2005 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-udp-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 29, 2005. 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 defines a set of 44 requirements that would allow many applications, such as multimedia 45 communications or on-line gaming, to work consistently. Developing 46 NATs that meet this set of requirements will greatly increase the 47 likelihood that these applications will function properly. 49 Table of Contents 51 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Network Address and Port Translation Behavior . . . . . . . . 5 55 4.1 Address and Port Mapping . . . . . . . . . . . . . . . . . 5 56 4.2 Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 57 4.2.1 Port Assignment Behavior . . . . . . . . . . . . . . . 8 58 4.2.2 Port Parity . . . . . . . . . . . . . . . . . . . . . 10 59 4.2.3 Port Contiguity . . . . . . . . . . . . . . . . . . . 10 60 4.3 Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 61 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 12 62 5.1 Filtering of Unsolicited Packets . . . . . . . . . . . . . 12 63 5.2 NAT Filter Refresh . . . . . . . . . . . . . . . . . . . . 13 64 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 14 65 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 15 66 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 15 67 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 16 68 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . 17 69 10.1 Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 17 70 10.2 Smaller Network MTU . . . . . . . . . . . . . . . . . . . 18 71 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . 18 72 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 19 73 13. Security Considerations . . . . . . . . . . . . . . . . . . 20 74 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 75 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 77 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 17.1 Normative References . . . . . . . . . . . . . . . . . . . 23 79 17.2 Informational References . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 81 Intellectual Property and Copyright Statements . . . . . . . . 25 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 generally to all NAT 92 variations, including the ones described in RFC 2663 [3] (Traditional 93 NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed 94 NATs). However, it is not within the scope of this specification to 95 address all issues specific to all possible NAT variations. 97 This document is meant to cover NATs of any size, from small 98 residential NATs to large Enterprise NATs. However, it should be 99 understood that Enterprise NATs normally provide much more than just 100 NAT capabilities: for example, they typically provide Firewall 101 capabilities. Firewalls is specifically out-of-scope of this 102 specification: however, this specification does cover the inherent 103 filtering aspects of NAT. 105 Approaches using directly signaled control of middle boxes such as 106 Midcom, UPnP, or in-path signaling are out of scope. 108 UDP Relays are out of the scope of this document. 110 Application aspects are out of scope as the focus is strictly on the 111 NAT itself. 113 This document only covers the UDP Unicast aspects of NAT traversal 114 and does not cover TCP, IPSEC, or other protocols. Since the 115 document is for UDP only, packet inspection above the UDP layer 116 (including RTP) is also out-of-scope. 118 2. Introduction 120 Network Address Translators (NAT) are well known to cause very 121 significant problems with applications that carry IP addresses in the 122 payload RFC 3027 [5]. Applications that suffer from this problem 123 include Voice Over IP and Multimedia Over IP (e.g., SIP [6] and H.323 124 [20]), as well as online gaming. 126 Many techniques are used to attempt to make realtime multimedia 127 applications, online games, and other applications work across NATs. 128 Application Level Gateways [3] are one such mechanism. STUN [7] 129 describes a UNilateral Self-Address Translation (UNSAF) mechanism 130 [2]. UDP Relays have also been used to enable applications across 131 NATs, but these are generally seen as a solution of last resort. ICE 132 [16] describes a methodology for using many of these techniques and 133 avoiding a UDP Relay unless the type of NAT is such that it forces 134 the use of such a UDP Relay. This specification defines requirements 135 for improving NATs. Meeting these requirements ensures that 136 applications will not be forced to use UDP media relay. 138 As pointed out in UNSAF [2], "From observations of deployed networks, 139 it is clear that different NAT boxes' implementation vary widely in 140 terms of how they handle different traffic and addressing cases." 141 This wide degree of variability is one part of what contributes to 142 the overall brittleness introduced by NATs and makes it extremely 143 difficult to predict how any given protocol will behave on a network 144 traversing NATs. Discussions with many of the major NAT vendors have 145 made it clear that they would prefer to deploy NATs that were 146 deterministic and caused the least harm to applications while still 147 meeting the requirements that caused their customers to deploy NATs 148 in the first place. The problem the NAT vendors face is they are not 149 sure how best to do that or how to document how their NATs behave. 151 The goals of this document are to define a set of common terminology 152 for describing the behavior of NATs and to produce a set of 153 requirements on a specific set of behaviors for NATs. The 154 requirements represent what many vendors are already doing, and it is 155 not expected that it should be any more difficult to build a NAT that 156 meets these requirements or that these requirements should affect 157 performance. 159 This document forms a common set of requirements that are simple and 160 useful for voice, video, and games, which can be implemented by NAT 161 vendors. This document will simplify the analysis of protocols for 162 deciding whether or not they work in this environment and will allow 163 providers of services that have NAT traversal issues to make 164 statements about where their applications will work and where they 165 will not, as well as to specify their own NAT requirements. 167 3. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [1]. 173 Readers are urged to refer to RFC 2263 [3] for information on NAT 174 taxonomy and terminology. Traditional NAT is the most common type of 175 NAT device deployed. Readers may refer to RFC 3022 [4] for detailed 176 information on traditional NAT. Traditional NAT has two main 177 varieties - Basic NAT and Network Address/Port Translator (NAPT). 179 NAPT is by far the most commonly deployed NAT device. NAPT allows 180 multiple internal hosts to share a single public IP address 181 simultaneously. When an internal host opens an outgoing TCP or UDP 182 session through a NAPT, the NAPT assigns the session a public IP 183 address and port number so that subsequent response packets from the 184 external endpoint can be received by the NAPT, translated, and 185 forwarded to the internal host. The effect is that the NAPT 186 establishes a NAT session to translate the (private IP address, 187 private port number) tuple to (public IP address, public port number) 188 tuple and vice versa for the duration of the session. An issue of 189 relevance to peer-to-peer applications is how the NAT behaves when an 190 internal host initiates multiple simultaneous sessions from a single 191 (private IP, private port) endpoint to multiple distinct endpoints on 192 the external network. In this specification, the term "NAT" refers 193 to both "Basic NAT" and "Network Address/Port Translator (NAPT)". 195 This document uses the term "session" as defined in RFC 2663: "TCP/ 196 UDP sessions are uniquely identified by the tuple of (source IP 197 address, source TCP/UDP ports, target IP address, target TCP/UDP 198 Port)." 200 This document uses the term "address and port mapping" as the 201 translation between an external address and port and an internal 202 address and port. Note that this is not the same as an "address 203 binding" as defined in RFC 2663. 205 Earlier documents used the terms "Full Cone", "Restricted Cone", 206 "Port Restricted Cone" and "Symmetric" to refer to different 207 variations of NATs applicable to UDP only. Unfortunately, this 208 terminology has been the source of much confusion as it proved 209 inadequate at describing real-life NAT behavior. This specification 210 therefore refers to specific individual NAT behaviors instead of 211 using the Cone/Symmetric terminology. 213 4. Network Address and Port Translation Behavior 215 This section describes the various NAT behaviors applicable to NAT. 217 4.1 Address and Port Mapping 219 When an internal endpoint opens an outgoing session through a NAT, 220 the NAT assigns the session an external IP address and port number so 221 that subsequent response packets from the external endpoint can be 222 received by the NAT, translated and forwarded to the internal 223 endpoint. This is a mapping between an internal IP address and port 224 IP:port and external IP:port tuple. It establishes the translation 225 that will be performed by the NAT for the duration of the session. 226 For many applications, it is important to distinguish the behavior of 227 the NAT when there are multiple simultaneous sessions established to 228 different external endpoints. 230 The key behavior to describe is the criteria for re-use of a mapping 231 for new sessions to external endpoints, after establishing a first 232 mapping between an internal X:x address and port and an external 233 Y1:y1 address tuple. Let's assume that the internal IP address and 234 port X:x is mapped to X1':x1' for this first session. The endpoint 235 then sends from X:x to an external address Y2:y2 and gets a mapping 236 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 237 for various combinations of the relationship between Y1:y1 and Y2:y2 238 is critical for describing the NAT behavior. This arrangement is 239 illustrated in the following diagram: 241 E 242 +------+ +------+ x 243 | Y1 | | Y2 | t 244 +--+---+ +---+--+ e 245 | Y1:y1 Y2:y2 | r 246 +----------+ +----------+ n 247 | | a 248 X1':x1' | | X2':x2' l 249 +--+---+-+ 250 ...........| NAT |............... 251 +--+---+-+ I 252 | | n 253 X:x | | X:x t 254 ++---++ e 255 | X | r 256 +-----+ n 257 a 258 l 260 The following address and port mapping behavior are defined: 262 Endpoint Independent Mapping: 263 The NAT reuses the port mapping for subsequent packets sent 264 from the same internal IP address and port (X:x) to any 265 external IP address and port. Specifically, X1':x1' equals 266 X2':x2' for all values of Y2:y2. 268 Address Dependent Mapping: 269 The NAT reuses the port mapping for subsequent packets sent 270 from the same internal IP address and port (X:x) to the same 271 external IP address, regardless of the external port. 272 Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals 273 Y1. 275 Address and Port Dependent Mapping: 276 The NAT reuses the port mapping for subsequent packets sent 277 from the same internal IP address and port (X:x) to the same 278 external and port while the mapping is still active. 279 Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 280 equals Y1:y1. 282 It is important to note that these three possible choices make no 283 difference to the security properties of the NAT. The security 284 properties are fully determined by which packets the NAT allows in 285 and which it does not. This is determined by the filtering behavior 286 in the filtering portions of the NAT. 288 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 289 independent" behavior. 291 Justification for REQ-1: In order for UNSAF methods to work, REQ-1 292 needs to be met. Failure to meet REQ-1 will force the use of a 293 Media Relay which is very often impractical. 295 Some NATs are capable of assigning IP addresses from a pool of IP 296 addresses on the external side of the NAT, as opposed to just a 297 single IP address. This is especially common with larger NATs. Some 298 NATs use the external IP address mapping in an arbitrary fashion 299 (i.e. randomly): one internal IP address could have multiple external 300 IP address mappings active at the same time for different sessions. 301 These NATs have an "IP address pooling" behavior of "Arbitrary". 302 Some large Enterprise NATs use an IP address pooling behavior of 303 "Arbitrary" as a means of hiding the IP address assigned to specific 304 endpoints by making their assignment less predictable. Other NATs 305 use the same external IP address mapping for all sessions associated 306 with the same internal IP address. These NATs have an "IP address 307 pooling" behavior of "Paired." NATs that use an "IP address pooling" 308 behavior of "arbitrary" can cause issues for applications that use 309 multiple ports from the same endpoint but do not negotiate IP 310 addresses individually (e.g., some applications using RTP and RTCP). 312 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 313 behavior of "Paired". Note that this requirement is not 314 applicable to NATs that do not support IP address pooling. 316 Justification for REQ-2: This will allow applications that use 317 multiple ports originating from the same internal IP address to 318 also have the same external IP address. This is to avoid breaking 319 peer-to-peer applications which are not capable of negotiating the 320 IP address for RTP and the IP address for RTCP separately. As 321 such it is envisioned that this requirement will become less 322 important as applications become NAT-friendlier with time. The 323 main reason why this requirement is here is because in a peer-to- 324 peer application, you are subject to the other peer's mistake. In 325 particular, in the context of SIP, if my application supports the 326 extensions defined in RFC 3605 [9] for indicating RTP and RTCP 327 addresses and ports separately, but the other peer does not, there 328 may still be breakage in the form of lost of the RTP stream. This 329 requirements will avoid the loss of RTP in this context, although 330 the loss of RTCP may be inevitable in this particular example. It 331 is also worth noting that RFC 3605 is unfortunately not a 332 mandatory part of SIP (i.e., RFC 3261). This requirement will 333 therefore address a particularly nasty problem that will prevail 334 for a significant amount of time. 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 "dynamic/ 398 private" from 49152 through 65535. For most protocols, these are 399 destination ports and not source ports, so mapping a source port to a 400 source port that is already registered is unlikely to have any bad 401 effects. Some NATs may choose to use only the ports in the dynamic 402 range; the only down side of this practice is that it limits the 403 number of ports available. Other NAT devices may use everything but 404 the well-known range and may prefer to use the dynamics range first 405 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 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 411 overloading". 412 a) If the host's source port was in the range 1-1023, it is 413 RECOMMENDED the NAT's source port also be in the same range. 414 If the host's source port was in the range 1024-65535, it is 415 RECOMMENDED that the NAT's source port also be in that range. 417 Justification for REQ-3: This requirement must be met in order to 418 enable two applications on the internal side of the NAT both to 419 use the same port to try to communicate with the same destination. 420 NATs that implement port preservation have to deal with conflicts 421 on ports, and the multiple code paths this introduces often result 422 in nondeterministic behavior. However, it should be understood 423 that when a port is randomly assigned, it may just randomly happen 424 to be assigned the same port. Applications must therefore be able 425 to deal with both port preservation, and no port preservation. 426 a) Certain applications expect the source UDP port to be in the 427 well-known range. See RFC 2623 for an example. 429 4.2.2 Port Parity 431 Some NATs preserve the parity of the UDP port, i.e., an even port 432 will be mapped to an even port, and an odd port will be mapped to an 433 odd port. This behavior respects the RFC 3550 [8] rule that RTP use 434 even ports, and RTCP use odd ports. RFC 3550 allows any port numbers 435 to be used for RTP and RTCP if the two numbers are specified 436 separately, for example using RFC 3605 [9]. However, some 437 implementations do not include RFC 3605 and do not recognize when the 438 peer has specified the RTCP port separately using RFC 3605. If such 439 an implementation receives an odd RTP port number from the peer 440 (perhaps after having been translated by a NAT), and then follows the 441 RFC 3550 rule to change the RTP port to the next lower even number, 442 this would obviously result in the loss of RTP. NAT-friendly 443 application aspects are outside the scope of this document. It is 444 expected that this issue will fade away with time, as implementations 445 improve. Preserving the port parity allows for supporting 446 communication with peers that do not support explicit specification 447 of both RTP and RTCP port numbers. 449 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 450 behavior of "Yes". 452 Justification for REQ-4: This is to avoid breaking peer-to-peer 453 applications which do not explicity and separately specify RTP and 454 RTCP port numbers and which follow the RFC 3550 rule to decrement 455 an odd RTP port to make it even. The same considerations as per 456 the IP address pooling requirement apply. 458 4.2.3 Port Contiguity 460 Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. 461 These NATs do things like sequential assignment or port reservation. 462 Sequential port assignment assumes that the application will open a 463 mapping for RTP first and then open a mapping for RTCP. It is not 464 practical to enforce this requirement on all applications. 466 Furthermore, there is a glaring problem if many applications (or 467 endpoints) are trying to open mapping simultaneously. Port 468 reservation is also problematic since it is wasteful, especially 469 considering that a NAT can not reliably distinguish between RTP over 470 UDP and other UDP packets where there is no contiguity rule. For 471 those reasons, it would be too complex to attempt to preserve the 472 contiguity rule by suggesting specific NAT behavior, and it would 473 certainly break the deterministic behavior rule. 475 In order to support both RTP and RTCP, it will therefore be necessary 476 that applications follows rules to negotiate both RTP and RTCP 477 separately, and account for the very real possibility that the 478 RTCP=RTP+1 rule will be broken. As this is an application 479 requirement, it is outside of the scope of this document. 481 4.3 Mapping Refresh 483 NAT mapping timeout implementations vary but include the timer's 484 value and the way the mapping timer is refreshed to keep the mapping 485 alive. 487 The mapping timer is defined as the time a mapping will stay active 488 without packets traversing the NAT. There is great variation in the 489 values used by different NATs. 491 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 492 minutes. 493 a) The value of the NAT UDP mapping timer MAY be configurable. 494 b) A default value of 5 minutes for the NAT UDP mapping timer is 495 RECOMMENDED. 497 Justification for REQ-5: This requirement is to ensure that the 498 timeout is long enough to avoid too frequent timer refresh 499 packets. 500 a) Configuration is desirable for adapting to specific networks 501 and troubleshooting. 502 b) This default is to avoid too frequent timer refresh packets. 504 Some NATs keep the mapping active (i.e., refresh the timer value) 505 when a packet goes from the internal side of the NAT to the external 506 side of the NAT. This is referred to as having a NAT Outbound 507 refresh behavior of "True". 509 Some NATs keep the mapping active when a packet goes from the 510 external side of the NAT to the internal side of the NAT. This is 511 referred to as having a NAT Inbound Refresh Behavior of "True". 513 Some NATs keep the mapping active on both, in which case both 514 properties are "True". 516 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 517 refresh behavior" of "True". 518 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 519 refresh behavior" of "True". 521 Justification for REQ-6: Outbound refresh is necessary for allowing 522 the client to keep the mapping alive. 523 a) Inbound refresh may be useful for applications where there is 524 no outgoing UDP traffic. 526 5. Filtering Behavior 528 This section describes various filtering behaviors observed in NATs. 530 5.1 Filtering of Unsolicited Packets 532 When an internal endpoint opens an outgoing session through a NAT, 533 the NAT assigns a filtering rule for the mapping between an internal 534 IP:port (X:x) and external IP:port (Y:y) tuple. 536 The key behavior to describe is what criteria are used by the NAT to 537 filter packets originating from specific external endpoints. 539 Endpoint Independent Filtering: 540 The NAT filters out only packets not destined to the internal 541 address and port X:x, regardless of the external IP address and 542 port source (Z:z). The NAT forwards any packets destined to 543 X:x. In other words, sending packets from the internal side of 544 the NAT to any external IP address is sufficient to allow any 545 packets back to the internal endpoint. 547 Address Dependent Filtering: 548 The NAT filters out packets not destined to the internal 549 address X:x. Additionally, the NAT will filter out packets 550 from Y:y destined for the internal endpoint X:x if X:x has not 551 sent packets to Y:any previously (independently of the port 552 used by Y). In other words, for receiving packets from a 553 specific external endpoint, it is necessary for the internal 554 endpoint to send packets first to that specific external 555 endpoint's IP address. 557 Address and Port Dependent Filtering: 558 This is similar to the previous behavior, except that the 559 external port is also relevant. The NAT filters out packets 560 not destined for the internal address X:x. Additionally, the 561 NAT will filter out packets from Y:y destined for the internal 562 endpoint X:x if X:x has not sent packets to Y:y previously. In 563 other words, for receiving packets from a specific external 564 endpoint, it is necessary for the internal endpoint to send 565 packets first to that external endpoint's IP address and port. 567 REQ-7: If application transparency is most important, it is 568 RECOMMENDED that a NAT have an "Endpoint independent filtering" 569 behavior. If a more stringent filtering behavior is most 570 important, it is RECOMMENDED that a NAT have an "Address dependent 571 filtering" behavior. 572 a) The filtering behavior MAY be an option configurable by the 573 administrator of the NAT. 575 OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY? 577 Justification for REQ-7: The recommendation to use Endpoint 578 Independent Filtering is aimed at maximizing application 579 transparency, in particular for applications that receive media 580 simultaneously from multiple locations (e.g., gaming), or 581 applications that use rendezvous techniques. However, it is also 582 possible that in some circumstances, it may be preferable to have 583 a more stringent filtering behavior. Filtering independently of 584 the external endpoint is not as secure: an unauthorized packet 585 could get a specific port while the port was kept open if it was 586 lucky enough to find the port open. In theory, filtering based on 587 both IP address and port is more secure than filtering based only 588 on the IP address (because the external endpoint could in reality 589 be two endpoints behind another NAT, where one of the two 590 endpoints is an attacker): however, such a policy could interfere 591 with applications that expect to receive UDP packets on more than 592 one UDP port. Using Endpoint Independent Filtering or Address 593 Dependent Filetering instead of Address and Port Dependent 594 Filtering on a NAT (say NAT-A) also has benefits when the other 595 enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which 596 doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses 597 Address and Port Dependent Filtering, connectivity will require a 598 Media Relay. However, if NAT-A uses Endpoint Indepent Filtering 599 or Address Dependent Filtering, ICE will ultimately find 600 connectivity without requiring a Media Relay. Having the 601 filtering behavior being an option configurable by the 602 administrator of the NAT ensures that a NAT can be used in the 603 widest variety of deployment scenarios. 605 5.2 NAT Filter Refresh 607 The time for which a NAT filter is valid can be refreshed based on 608 packets that are inbound, outbound, or going either direction. 610 6. Hairpinning Behavior 612 If two hosts (called X1 and X2) are behind the same NAT and 613 exchanging traffic, the NAT may allocate an address on the outside of 614 the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it 615 goes to the NAT, which must relay the traffic from X1 to X2. This is 616 referred to as hairpinning and is illustrated below. 618 NAT 619 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 620 | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 621 +----+ | v | 622 | v | 623 | v | 624 | v | 625 +----+ from X1':x1' to X2:x2 | v | X2':x2' 626 | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 627 +----+ +-----+ 629 Hairpinning allows two endpoints on the internal side of the NAT to 630 communicate even if they only use each other's external IP addresses 631 and ports. 633 More formally, a NAT that supports hairpinning forwards packets 634 originating from an internal address, X1:x1, destined for an external 635 address X2':x2' that has an active mapping to an internal address 636 X2:x2, back to that internal address X2:x2. Note that typically X1' 637 is the same as X2'. 639 Furthermore, the NAT may present the hairpinned packet with either an 640 internal or an external source IP address and port. The hairpinning 641 NAT behavior can therefore be either "External source IP address and 642 port" or "Internal source IP address and port". "Internal source IP 643 address and port" may cause problems by confusing an implementation 644 that is expecting an external IP address and port. 646 REQ-8: A NAT MUST support "Hairpinning". 647 a) A NAT Hairpinning behavior MUST be "External source IP address 648 and port". 650 Justification for REQ-8: This requirement is to allow communications 651 between two endpoints behind the same NAT when they are trying 652 each other's external IP addresses. 654 a) Using the external IP address is necessary for applications 655 with a restrictive policy of not accepting packets from IP 656 addresses that differ from what is expected. 658 7. Application Level Gateways 660 Certain NATs have implemented Application Level Gateways (ALGs) for 661 various protocols, including protocols for negotiating peer-to-peer 662 sessions such as SIP. 664 Certain NATs have these ALGs turned on permanently, others have them 665 turned on by default but let them be be turned off, and others have 666 them turned off by default but let them be turned on. 668 NAT ALGs may interfere with UNSAF methods or protocols that try to be 669 NAT-aware and must therefore be used with extreme caution. 671 REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those 672 ALGs (except for DNS [19] and FTP [18]) be disabled by default. 673 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 674 the NAT administrator to enable or disable each ALG separately. 676 Justification for REQ-9: NAT ALGs may interfere with UNSAF methods. 677 a) This requirement allows the user to enable ALGs which are 678 necessary to aid operation of some applications without 679 enabling ALGs which interfere with operation of other 680 applications. 682 8. Deterministic Properties 684 The classification of NATs is further complicated by the fact that 685 under some conditions the same NAT will exhibit different behaviors. 686 This has been seen on NATs that preserve ports or have specific 687 algorithms for selecting a port other than a free one. If the 688 external port that the NAT wishes to use is already in use by another 689 session, the NAT must select a different port. This results in 690 different code paths for this conflict case, which results in 691 different behavior. 693 For example, if three hosts X1, X2, and X3 all send from the same 694 port x, through a port preserving NAT with only one external IP 695 address, called X1', the first one to send (i.e., X1) will get an 696 external port of x but the next two will get x2' and x3' (where these 697 are not equal to x). There are NATs where the External NAT mapping 698 characteristics and the External Filter characteristics change 699 between the X1:x and the X2:x mapping. To make matters worse, there 700 are NATs where the behavior may be the same on the X1:x and X2:x 701 mappings but different on the third X3:x mapping. 703 Some NATs that try to reuse external ports flow from two internal IP 704 addresses to two different external IP addresses. For example, X1:x 705 is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not 706 equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x 707 to X1':x. This works in the case where the NAT mapping is address 708 port dependent. However some NATs change their behavior when this 709 type of port reuse is happening. The NAT may look like it has NAT 710 mappings that are independent when this type of reuse is not 711 happening but may change to Address Port Dependent when this reuse 712 happens. 714 Any NAT that changes the NAT mapping or the External Filtering 715 without configuration changes, at any point in time under any 716 particular conditions is referred to as a "non-deterministic" NAT. 717 NATs that don't are called "deterministic". 719 Non-deterministic NATs generally change behavior when a conflict of 720 some sort happens, i.e. when the port that would normally be used is 721 already in use by another mapping. The NAT mapping and External 722 Filtering in the absence of conflict is referred to as the Primary 723 behavior. The behavior after the first conflict is referred to as 724 Secondary and after the second conflict is referred to as Tertiary. 725 No NATs have been observed that change on further conflicts but it is 726 certainly possible that they exist. 728 REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT 729 change the NAT mapping or the External External Filtering Behavior 730 at any point in time or under any particular conditions. 732 Justification for REQ-10: Non-deterministic NATs are very difficult 733 to troubleshoot because they require more intensive testing. This 734 non-deterministic behavior is the root cause of much of the 735 uncertainty that NATs introduce about whether or not applications 736 will work. 738 9. ICMP Destination Unreachable Behavior 740 When a NAT sends a packet towards a host on the other side of the 741 NAT, an ICMP message may be sent in response to that packet. That 742 ICMP message may be sent by the destination host or by any router 743 along the network path. The NAT's default configuration SHOULD NOT 744 filter ICMP messages based on their source IP address. Such ICMP 745 messages SHOULD be rewritten by the NAT (specifically the IP headers 746 and the ICMP payload) and forwarded to the appropriate internal or 747 external host. The NAT needs to perform this function for as long as 748 the UDP mapping is active. Receipt of any sort of ICMP message MUST 749 NOT destroy the NAT mapping. A NAT which performs the functions 750 described in the paragraph above is referred to as "UDP Support 751 Destination Unreachable". 753 There is no significant security advantage to blocking ICMP 754 Destination Unreachable packets. 756 Additionally, blocking ICMP Destination Unreachable packets can 757 interfere with application failover, UDP Path MTU Discovery (see 758 RFC1191 [10] and RFC1435 [15]), and with traceroute. Blocking any 759 ICMP message is discouraged, and blocking ICMP Destination 760 Unreachable is strongly discouraged. 762 REQ-11: It is RECOMMENDED that a NAT support ICMP Destination 763 Unreachable. 764 a) The ICMP timeout SHOULD be greater than 2 seconds. 766 Justification for REQ-11: This is easy to do, is used for many things 767 including MTU discovery and rapid detection of error conditions, 768 and has no negative consequences. 769 a) The ICMP timeout SHOULD be greater than 2 seconds. 771 10. Fragmentation of Outgoing Packets 773 When sending a packet, there are two situations that may cause IP 774 fragmentation for packets from the inside to the outside. It is 775 worth noting that many IP stacks do not use Path MTU Discovery with 776 UDP packets. 778 10.1 Smaller Adjacent MTU 780 The first situation is when the MTU of the adjacent link is too 781 small. This can occur if the NAT is doing PPPoE, or if the NAT has 782 been configured with a small MTU to reduce serialization delay when 783 sending large packets and small higher-priority packets, or for other 784 reasons. 786 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 787 (DF=0). 789 If the packet has DF=1, the NAT SHOULD send back an ICMP message 790 "fragmentation needed and DF set" message to the host as described in 791 RFC 792 [13]. 793 If the packet has DF=0, the NAT SHOULD fragment the packet and send 794 the fragments, in order. This is the same function a router performs 795 in a similar situation RFC 1812 [14]. 797 NATs that operate as described in this section are described as 798 "Supports Fragmentation" (abbreviated SF). 800 10.2 Smaller Network MTU 802 The second situation is when the MTU on some link in the middle of 803 the network that is not the adjacent link is too small. If DF=0, the 804 router adjacent to the small-MTU segment will fragment the packet and 805 forward the fragments as specified in RFC 1812 [14]. 807 If DF=1, the router adjacent to the small-MTU segment will send the 808 ICMP message "fragmentation needed and DF set" back towards the NAT. 809 The NAT needs to forward this ICMP message to the inside host. 811 The classification of NATs that perform this behavior is covered in 812 the ICMP section of this document. 814 REQ-12: A NAT MUST support fragmentation of packets larger than link 815 MTU. 817 Justification for REQ-12: Fragmented packets become more common with 818 large video packets and should continue to work. Applications can 819 use MTU discovery to work around this problem. 821 11. Receiving Fragmented Packets 823 For a variety of reasons, a NAT may receive a fragmented packet. The 824 IP packet containing the header could arrive in any fragment 825 depending on network conditions, packet ordering, and the 826 implementation of the IP stack that generated the fragments. 828 A NAT that is capable only of receiving fragments in order (that is, 829 with the header in the first packet) and forwarding each of the 830 fragments to the internal host is described as "Received Fragments 831 Ordered". 833 A NAT that is capable of receiving fragments in or out of order and 834 forwarding the individual packets (or a reassembled packet) to the 835 internal host is referred to as "Receive Fragments Out of Order". 836 See the Security Considerations section of this document for a 837 discussion of this behavior. 839 A NAT that is neither of these is referred to as "Receive Fragments 840 None". 842 REQ-13: A NAT MUST support receiving in order fragments, so it MUST 843 be "Received Fragment Ordered" or "Received Fragment Out of 844 Order". 846 a) A NAT MAY support receiving fragmented packets that are out of 847 order and be of type "Received Fragment Out of Order". 849 Justification for REQ-13: See Security Considerations. 851 12. Requirements 853 The requirements in this section are aimed at minimizing the 854 complications caused by NATs to applications such as realtime 855 communications and online gaming. The requirements listed earlier in 856 the document are consolidated here into a single section. 858 It should be understood, however, that applications normally do not 859 know in advance if the NAT conforms to the recommendations defined in 860 this section. Peer-to-peer media applications still need to use 861 normal procedures such as ICE [16]. 863 A NAT that supports all of the mandatory requirements of this 864 specification (i.e., the "MUST"), is "compliant with this 865 specification." A NAT that supports all of the requirements of this 866 specification (i.e., included the "RECOMMENDED") is "fully compliant 867 with all the mandatory and recommended requirements of this 868 specification." 870 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 871 independent" behavior. 872 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 873 behavior of "Paired". Note that this requirement is not 874 applicable to NATs that do not support IP address pooling. 875 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 876 overloading". 877 a) If the host's source port was in the range 1-1023, it is 878 RECOMMENDED the NAT's source port also be in the same range. 879 If the host's source port was in the range 1024-65535, it is 880 RECOMMENDED that the NAT's source port also be in that range. 881 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 882 behavior of "Yes". 883 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 884 minutes. 885 a) The value of the NAT UDP mapping timer MAY be configurable. 886 b) A default value of 5 minutes for the NAT UDP mapping timer is 887 RECOMMENDED. 888 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 889 refresh behavior" of "True". 891 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 892 refresh behavior" of "True". 893 REQ-7: If application transparency is most important, it is 894 RECOMMENDED that a NAT have an "Endpoint independent filtering" 895 behavior. If a more stringent filtering behavior is most 896 important, it is RECOMMENDED that a NAT have an "Address dependent 897 filtering" behavior. 898 a) The filtering behavior MAY be an option configurable by the 899 administrator of the NAT. 900 OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY? 901 REQ-8: A NAT MUST support "Hairpinning". 902 a) A NAT Hairpinning behavior MUST be "External source IP address 903 and port". 904 REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those 905 ALGs (except for DNS [19] and FTP [18]) be disabled by default. 906 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 907 the NAT administrator to enable or disable each ALG separately. 908 REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT 909 change the NAT mapping or the External External Filtering Behavior 910 at any point in time or under any particular conditions. 911 REQ-11: It is RECOMMENDED that a NAT support ICMP Destination 912 Unreachable. 913 a) The ICMP timeout SHOULD be greater than 2 seconds. 914 REQ-12: A NAT MUST support fragmentation of packets larger than link 915 MTU. 916 REQ-13: A NAT MUST support receiving in order fragments, so it MUST 917 be "Received Fragment Ordered" or "Received Fragment Out of 918 Order". 919 a) A NAT MAY support receiving fragmented packets that are out of 920 order and be of type "Received Fragment Out of Order". 922 13. Security Considerations 924 NATs are often deployed to achieve security goals. Most of the 925 recommendations and requirements in this document do not affect the 926 security properties of these devices, but a few of them do have 927 security implications and are discussed in this section. 929 This work recommends that the timers for mapping be refreshed only on 930 outgoing packets and does not make recommendations about whether or 931 not inbound packets should update the timers. If inbound packets 932 update the timers, an external attacker can keep the mapping alive 933 forever and attack future devices that may end up with the same 934 internal address. A device that was also the DHCP server for the 935 private address space could mitigate this by cleaning any mappings 936 when a DHCP lease expired. For unicast UDP traffic (the scope of 937 this document), it may not seem relevant to support inbound timer 938 refresh; however, for multicast UDP, the question is harder. It is 939 expected that future documents discussing NAT behavior with multicast 940 traffic will refine the requirements around handling of the inbound 941 refresh timer. Some devices today do update the timers on inbound 942 packets. 944 This work recommends that the NAT filters be specific to the external 945 IP only and not the external IP and port. It can be argued that this 946 is less secure than using the IP and port. Devices that wish to 947 filter on IP and port do still comply with these requirements. 949 Non-deterministic NATs are risky from a security point of view. They 950 are very difficult to test because they are, well, non-deterministic. 951 Testing by a person configuring one may result in the person thinking 952 it is behaving as desired, yet under different conditions, which an 953 attacker can create, the NAT may behave differently. These 954 requirements recommend that devices be deterministic. 956 The work requires that NATs have an "external NAT mapping is endpoint 957 independent" behavior. This does not reduce the security of devices. 958 Which packets are allowed to flow across the device is determined by 959 the external filtering behavior, which is independent of the mapping 960 behavior. 962 When a fragmented packet is received from the external side and the 963 packets are out of order so that the initial fragment does not arrive 964 first, many systems simply discard the out of order packets. 965 Moreover, since some networks deliver small packets ahead of large 966 ones, there can be many out of order fragments. NATs that are 967 capable of delivering these out of order packets are possible but 968 they need to store the out of order fragments, which can open up a 969 DoS opportunity if done incorrectly. Fragmentation has been a tool 970 used in many attacks, some involving passing fragmented packets 971 through NATs and others involving DoS attacks based on the state 972 needed to reassemble the fragments. NAT implementers should be aware 973 of RFC 3128 [12] and RFC 1858 [11]. 975 14. IANA Considerations 977 There are no IANA considerations. 979 15. IAB Considerations 981 The IAB has studied the problem of "Unilateral Self Address Fixing", 982 which is the general process by which a client attempts to determine 983 its address in another realm on the other side of a NAT through a 984 collaborative protocol reflection mechanism [2]. 986 This specification does not in itself constitute an UNSAF 987 application. It consists of a series of requirements for NATs aimed 988 at minimizing the negative impact that those devices have on peer-to- 989 peer media applications, especially when those applications are using 990 UNSAF methods. 992 Section 3 of UNSAF lists several practical issues with solutions to 993 NAT problems. This document makes recommendations to reduce the 994 uncertainty and problems introduced by these practical issues with 995 NATs. In addition, UNSAF lists five architectural considerations. 996 Although this is not an UNSAF proposal, it is interesting to consider 997 the impact of this work on these architectural considerations. 999 Arch-1: The scope of this is limited to UDP packets in NATs like the 1000 ones widely deployed today. The "fix" helps constrain the 1001 variability of NATs for true UNSAF solutions such as STUN. 1002 Arch-2: This will exit at the same rate that NATs exit. It does not 1003 imply any protocol machinery that would continue to live 1004 after NATs were gone or make it more difficult to remove 1005 them. 1006 Arch-3: This does not reduce the overall brittleness of NATs but will 1007 hopefully reduce some of the more outrageous NAT behaviors 1008 and make it easer to discuss and predict NAT behavior in 1009 given situations. 1010 Arch-4: This work and the results [17] of various NATs represent the 1011 most comprehensive work at IETF on what the real issues are 1012 with NATs for applications like VoIP. This work and STUN 1013 have pointed out more than anything else the brittleness NATs 1014 introduce and the difficulty of addressing these issues. 1015 Arch-5: This work and the test results [17] provide a reference model 1016 for what any UNSAF proposal might encounter in deployed NATs. 1018 16. Acknowledgments 1020 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 1021 Dan Kegel for the their multiple contributions on peer-to-peer 1022 communications accross a NAT. 1024 Dan Wing contributed substantial text on IP fragmentation and ICMP 1025 behavior. 1027 Thanks to Rohan Mahy, Jonathan Rosenberg, Mary Barnes, Melinda Shore, 1028 Lyndsay Campbell, Geoff Huston, Jiri Kuthan, Harald Welte, Steve 1029 Casner, Robert Sanders, Spencer Dawkins, Saikat Guha, Christian 1030 Huitema, Yutaka Takeda and Paul Hoffman for their important 1031 contributions. 1033 17. References 1034 17.1 Normative References 1036 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1037 Levels", BCP 14, RFC 2119, March 1997. 1039 [2] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1040 Address Fixing (UNSAF) Across Network Address Translation", 1041 RFC 3424, November 2002. 1043 17.2 Informational References 1045 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1046 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1048 [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1049 Translator (Traditional NAT)", RFC 3022, January 2001. 1051 [5] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 1052 IP Network Address Translator", RFC 3027, January 2001. 1054 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1055 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1056 Session Initiation Protocol", RFC 3261, June 2002. 1058 [7] Rosenberg, J., Huitema, C., and R. Mahy, "STUN - Simple 1059 Traversal of User Datagram Protocol (UDP) Through Network 1060 Address Translators (NATs)", draft-ietf-behave-rfc3489bis (work 1061 in progress), February 2003. 1063 [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1064 "RTP: A Transport Protocol for Real-Time Applications", 1065 RFC 3550, July 2003. 1067 [9] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1068 Session Description Protocol (SDP)", RFC 3605, October 2003. 1070 [10] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1071 November 1990. 1073 [11] Ziemba, G., Reed, D., and P. Traina, "Security Considerations 1074 for IP Fragment Filtering", RFC 1858, October 1995. 1076 [12] Miller, I., "Protection Against a Variant of the Tiny Fragment 1077 Attack (RFC 1858)", RFC 3128, June 2001. 1079 [13] Postel, J., "Internet Control Message Protocol", STD 5, 1080 RFC 792, September 1981. 1082 [14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1083 June 1995. 1085 [15] Knowles, S., "IESG Advice from Experience with Path MTU 1086 Discovery", March 1993. 1088 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1089 Methodology for Network Address Translator (NAT) Traversal for 1090 the Session Initiation Protocol (SIP)", 1091 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 1093 [17] Jennings, C., "NAT Classification Results using STUN", 1094 draft-jennings-behave-test-results-00 (work in progress), 1095 February 2005. 1097 [18] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 1098 RFC 959, October 1985. 1100 [19] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 1101 SPECIFICATION", RFC 1035, November 1987. 1103 [20] "Packet-based Multimedia Communications Systems", ITU- 1104 T Recommendation H.323, July 2003. 1106 Authors' Addresses 1108 Francois Audet (editor) 1109 Nortel Networks 1110 4655 Great America Parkway 1111 Santa Clara, CA 95054 1112 US 1114 Phone: +1 408 495 3756 1115 Email: audet@nortel.com 1117 Cullen Jennings 1118 Cisco Systems 1119 170 West Tasman Drive 1120 MS: SJC-21/2 1121 San Jose, CA 95134 1122 US 1124 Phone: +1 408 902 3341 1125 Email: fluffy@cisco.com 1127 Intellectual Property Statement 1129 The IETF takes no position regarding the validity or scope of any 1130 Intellectual Property Rights or other rights that might be claimed to 1131 pertain to the implementation or use of the technology described in 1132 this document or the extent to which any license under such rights 1133 might or might not be available; nor does it represent that it has 1134 made any independent effort to identify any such rights. Information 1135 on the procedures with respect to rights in RFC documents can be 1136 found in BCP 78 and BCP 79. 1138 Copies of IPR disclosures made to the IETF Secretariat and any 1139 assurances of licenses to be made available, or the result of an 1140 attempt made to obtain a general license or permission for the use of 1141 such proprietary rights by implementers or users of this 1142 specification can be obtained from the IETF on-line IPR repository at 1143 http://www.ietf.org/ipr. 1145 The IETF invites any interested party to bring to its attention any 1146 copyrights, patents or patent applications, or other proprietary 1147 rights that may cover technology that may be required to implement 1148 this standard. Please address the information to the IETF at 1149 ietf-ipr@ietf.org. 1151 Disclaimer of Validity 1153 This document and the information contained herein are provided on an 1154 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1155 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1156 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1157 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1158 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1159 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1161 Copyright Statement 1163 Copyright (C) The Internet Society (2005). This document is subject 1164 to the rights, licenses and restrictions contained in BCP 78, and 1165 except as set forth therein, the authors retain all their rights. 1167 Acknowledgment 1169 Funding for the RFC Editor function is currently provided by the 1170 Internet Society.