idnits 2.17.1 draft-ietf-behave-nat-udp-03.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 1157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1147. ** 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 (July 15, 2005) is 6853 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: January 16, 2006 C. Jennings 5 Cisco Systems 6 July 15, 2005 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-udp-03 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 January 16, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines basic terminology for describing different 43 types of NAT behavior when handling Unicast UDP and also defines a 44 set of requirements that would allow many applications, such as 45 multimedia communications or on-line gaming, to work consistently. 46 Developing NATs that meet this set of requirements will greatly 47 increase the likelihood that these applications will function 48 properly. 50 Table of Contents 52 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Network Address and Port Translation Behavior . . . . . . . . 5 56 4.1 Address and Port Mapping . . . . . . . . . . . . . . . . . 5 57 4.2 Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 58 4.2.1 Port Assignment Behavior . . . . . . . . . . . . . . . 8 59 4.2.2 Port Parity . . . . . . . . . . . . . . . . . . . . . 10 60 4.2.3 Port Contiguity . . . . . . . . . . . . . . . . . . . 10 61 4.3 Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 62 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1 Filtering of Unsolicited Packets . . . . . . . . . . . . . 12 64 5.2 NAT Filter Refresh . . . . . . . . . . . . . . . . . . . . 14 65 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 14 66 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 15 67 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 15 68 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 16 69 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . 17 70 10.1 Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 17 71 10.2 Smaller Network MTU . . . . . . . . . . . . . . . . . . . 18 72 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . 18 73 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 19 74 13. Security Considerations . . . . . . . . . . . . . . . . . . 20 75 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 76 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 78 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 17.1 Normative References . . . . . . . . . . . . . . . . . . . 23 80 17.2 Informational References . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 82 Intellectual Property and Copyright Statements . . . . . . . . 25 84 1. Applicability Statement 86 The purpose of this specification is to define a set of requirements 87 for NATs that would allow many applications, such as multimedia 88 communications or on-line gaming, to work consistently. Developing 89 NATs that meet this set of requirements will greatly increase the 90 likelihood that these applications will function properly. 92 The requirements of this specification apply to Traditional NATs as 93 described in RFC 2663 [3]. 95 This document is meant to cover NATs of any size, from small 96 residential NATs to large Enterprise NATs. However, it should be 97 understood that Enterprise NATs normally provide much more than just 98 NAT capabilities: for example, they typically provide firewall 99 functionalities. Firewalls are specifically out-of-scope for this 100 specification; however, this specification does cover the inherent 101 filtering aspects of NATs. 103 Approaches using directly signaled control of middle boxes such as 104 Midcom, UPnP, or in-path signaling are out of scope. 106 UDP Relays are out-of-scope. 108 Application aspects are out-of-scope, as the focus here is strictly 109 on the NAT itself. 111 This document only covers the UDP Unicast aspects of NAT traversal 112 and does not cover TCP, IPSEC, or other protocols. Since the 113 document is for UDP only, packet inspection above the UDP layer 114 (including RTP) is also out-of-scope. 116 2. Introduction 118 Network Address Translators (NATs) are well known to cause very 119 significant problems with applications that carry IP addresses in the 120 payload RFC 3027 [5]. Applications that suffer from this problem 121 include Voice Over IP and Multimedia Over IP (e.g., SIP [6] and H.323 122 [20]), as well as online gaming. 124 Many techniques are used to attempt to make realtime multimedia 125 applications, online games, and other applications work across NATs. 126 Application Level Gateways [3] are one such mechanism. STUN [7] 127 describes a UNilateral Self-Address Translation (UNSAF) mechanism 128 [2]. UDP Relays have also been used to enable applications across 129 NATs, but these are generally seen as a solution of last resort. ICE 130 [16] describes a methodology for using many of these techniques and 131 avoiding a UDP Relay unless the type of NAT is such that it forces 132 the use of such a UDP Relay. This specification defines requirements 133 for improving NATs. Meeting these requirements ensures that 134 applications will not be forced to use UDP media relay. 136 As pointed out in UNSAF [2], "From observations of deployed networks, 137 it is clear that different NAT boxes' implementation vary widely in 138 terms of how they handle different traffic and addressing cases." 139 This wide degree of variability is one factor in the overall 140 brittleness introduced by NATs and makes it extremely difficult to 141 predict how any given protocol will behave on a network traversing 142 NAT. Discussions with many of the major NAT vendors have made it 143 clear that they would prefer to deploy NATs that were deterministic 144 and caused the least harm to applications while still meeting the 145 requirements that caused their customers to deploy NATs in the first 146 place. The problem NAT vendors face is that they are not sure how 147 best to do that or how to document how their NATs behave. 149 The goals of this document are to define a set of common terminology 150 for describing the behavior of NATs and to produce a set of 151 requirements on a specific set of behaviors for NATs. The 152 requirements represent what many vendors are already doing, and it is 153 not expected that it should be any more difficult to build a NAT that 154 meets these requirements or that these requirements should affect 155 performance. 157 This document forms a common set of requirements that are simple and 158 useful for voice, video, and games, which can be implemented by NAT 159 vendors. This document will simplify the analysis of protocols for 160 deciding whether or not they work in this environment and will allow 161 providers of services that have NAT traversal issues to make 162 statements about where their applications will work and where they 163 will not, as well as to specify their own NAT requirements. 165 3. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [1]. 171 Readers are urged to refer to RFC 2263 [3] for information on NAT 172 taxonomy and terminology. Traditional NAT is the most common type of 173 NAT device deployed. Readers may refer to RFC 3022 [4] for detailed 174 information on traditional NAT. Traditional NAT has two main 175 varieties - Basic NAT and Network Address/Port Translator (NAPT). 177 NAPT is by far the most commonly deployed NAT device. NAPT allows 178 multiple internal hosts to share a single public IP address 179 simultaneously. When an internal host opens an outgoing TCP or UDP 180 session through a NAPT, the NAPT assigns the session a public IP 181 address and port number so that subsequent response packets from the 182 external endpoint can be received by the NAPT, translated, and 183 forwarded to the internal host. The effect is that the NAPT 184 establishes a NAT session to translate the (private IP address, 185 private port number) tuple to (public IP address, public port number) 186 tuple and vice versa for the duration of the session. An issue of 187 relevance to peer-to-peer applications is how the NAT behaves when an 188 internal host initiates multiple simultaneous sessions from a single 189 (private IP, private port) endpoint to multiple distinct endpoints on 190 the external network. In this specification, the term "NAT" refers 191 to both "Basic NAT" and "Network Address/Port Translator (NAPT)". 193 This document uses the term "session" as defined in RFC 2663: "TCP/ 194 UDP sessions are uniquely identified by the tuple of (source IP 195 address, source TCP/UDP ports, target IP address, target TCP/UDP 196 Port)." 198 This document uses the term "address and port mapping" as the 199 translation between an external address and port and an internal 200 address and port. Note that this is not the same as an "address 201 binding" as defined in RFC 2663. 203 RFC 3489 used the terms "Full Cone", "Restricted Cone", "Port 204 Restricted Cone" and "Symmetric" to refer to different variations of 205 NATs applicable to UDP only. Unfortunately, this terminology has 206 been the source of much confusion as it has proven inadequate at 207 describing real-life NAT behavior. This specification therefore 208 refers to specific individual NAT behaviors instead of using the 209 Cone/Symmetric terminology. 211 4. Network Address and Port Translation Behavior 213 This section describes the various NAT behaviors applicable to NATs. 215 4.1 Address and Port Mapping 217 When an internal endpoint opens an outgoing session through a NAT, 218 the NAT assigns the session an external IP address and port number so 219 that subsequent response packets from the external endpoint can be 220 received by the NAT, translated, and forwarded to the internal 221 endpoint. This is a mapping between an internal IP address and port 222 IP:port and external IP:port tuple. It establishes the translation 223 that will be performed by the NAT for the duration of the session. 224 For many applications, it is important to distinguish the behavior of 225 the NAT when there are multiple simultaneous sessions established to 226 different external endpoints. 228 The key behavior to describe is the criteria for re-use of a mapping 229 for new sessions to external endpoints, after establishing a first 230 mapping between an internal X:x address and port and an external 231 Y1:y1 address tuple. Let's assume that the internal IP address and 232 port X:x is mapped to X1':x1' for this first session. The endpoint 233 then sends from X:x to an external address Y2:y2 and gets a mapping 234 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 235 for various combinations of the relationship between Y1:y1 and Y2:y2 236 is critical for describing the NAT behavior. This arrangement is 237 illustrated in the following diagram: 239 E 240 +------+ +------+ x 241 | Y1 | | Y2 | t 242 +--+---+ +---+--+ e 243 | Y1:y1 Y2:y2 | r 244 +----------+ +----------+ n 245 | | a 246 X1':x1' | | X2':x2' l 247 +--+---+-+ 248 ...........| NAT |............... 249 +--+---+-+ I 250 | | n 251 X:x | | X:x t 252 ++---++ e 253 | X | r 254 +-----+ n 255 a 256 l 258 The following address and port mapping behavior are defined: 260 Endpoint Independent Mapping: 261 The NAT reuses the port mapping for subsequent packets sent 262 from the same internal IP address and port (X:x) to any 263 external IP address and port. Specifically, X1':x1' equals 264 X2':x2' for all values of Y2:y2. 266 Address Dependent Mapping: 267 The NAT reuses the port mapping for subsequent packets sent 268 from the same internal IP address and port (X:x) to the same 269 external IP address, regardless of the external port. 270 Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals 271 Y1. 273 Address and Port Dependent Mapping: 275 The NAT reuses the port mapping for subsequent packets sent 276 from the same internal IP address and port (X:x) to the same 277 external and port while the mapping is still active. 278 Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 279 equals Y1:y1. 281 It is important to note that these three possible choices make no 282 difference to the security properties of the NAT. The security 283 properties are fully determined by which packets the NAT allows in 284 and which it does not. This is determined by the filtering behavior 285 in the filtering portions of the NAT. 287 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 288 independent" behavior. 290 Justification for REQ-1: In order for UNSAF methods to work, REQ-1 291 needs to be met. Failure to meet REQ-1 will force the use of a 292 Media Relay which is very often impractical. 294 Some NATs are capable of assigning IP addresses from a pool of IP 295 addresses on the external side of the NAT, as opposed to just a 296 single IP address. This is especially common with larger NATs. Some 297 NATs use the external IP address mapping in an arbitrary fashion 298 (i.e. randomly): one internal IP address could have multiple external 299 IP address mappings active at the same time for different sessions. 300 These NATs have an "IP address pooling" behavior of "Arbitrary". 301 Some large Enterprise NATs use an IP address pooling behavior of 302 "Arbitrary" as a means of hiding the IP address assigned to specific 303 endpoints by making their assignment less predictable. Other NATs 304 use the same external IP address mapping for all sessions associated 305 with the same internal IP address. These NATs have an "IP address 306 pooling" behavior of "Paired." NATs that use an "IP address pooling" 307 behavior of "arbitrary" can cause issues for applications that use 308 multiple ports from the same endpoint but do not negotiate IP 309 addresses individually (e.g., some applications using RTP and RTCP). 311 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 312 behavior of "Paired". Note that this requirement is not 313 applicable to NATs that do not support IP address pooling. 315 Justification for REQ-2: This will allow applications that use 316 multiple ports originating from the same internal IP address to 317 also have the same external IP address. This is to avoid breaking 318 peer-to-peer applications which are not capable of negotiating the 319 IP address for RTP and the IP address for RTCP separately. As 320 such it is envisioned that this requirement will become less 321 important as applications become NAT-friendlier with time. The 322 main reason why this requirement is here is that in a peer-to-peer 323 application, you are subject to the other peer's mistake. In 324 particular, in the context of SIP, if my application supports the 325 extensions defined in RFC 3605 [9] for indicating RTP and RTCP 326 addresses and ports separately, but the other peer does not, there 327 may still be breakage in the form of letting the stream loose the 328 RTP packets. This requirement will avoid the loss of RTP in this 329 context, although the loss of RTCP may be inevitable in this 330 particular example. It is also worth noting that RFC 3605 is 331 unfortunately not a mandatory part of SIP (RFC 3261). This 332 requirement will therefore address a particularly nasty problem 333 that will prevail for a significant amount of time. 335 4.2 Port Assignment 337 4.2.1 Port Assignment Behavior 339 This section uses the following diagram for reference. 341 E 342 +-------+ +-------+ x 343 | Y1 | | Y2 | t 344 +---+---+ +---+---+ e 345 | Y1:y1 Y2:y2 | r 346 +---------+ +---------+ n 347 | | a 348 X1':x1' | | X2':x2' l 349 +--+---+--+ 350 ...........| NAT |............... 351 +--+---+--+ I 352 | | n 353 +---------+ +---------+ t 354 | X1:x1 X2':x2 | e 355 +---+---+ +---+---+ r 356 | X1 | | X2 | n 357 +-------+ +-------+ a 358 l 360 Some NATs attempt to preserve the port number used internally when 361 assigning a mapping to an external IP address and port (e.g., 362 x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A 363 basic NAT, for example, will preserve the same port and will assign a 364 different IP address from a pool of external IP addresses in case of 365 port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only 366 possible as long as the NAT has enough external IP addresses. If the 367 port x is already in use on all available external IP addresses, then 368 the NAT needs to switch from Basic NAT to Network Address and Port 369 Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or 370 a mapping of X1:x to X':x1' and X2:x to X':x2'). This port 371 assignment behavior is referred to as "port preservation". It does 372 not guarantee that the external port x' will always be the same as 373 the internal port x but only that the NAT will preserve the port if 374 possible. 376 A NAT that does not attempt to make the external port numbers match 377 the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to 378 X':x2') is referred to as "No port preservation". 380 Some NATs use "Port overloading", i.e. they always use port 381 preservation even in the case of collision (i.e., X'=X1'=X2' and 382 x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x). 383 These NATs rely on the source of the response from the external 384 endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal 385 endpoint (X1 or X2). Port overloading fails if the two internal 386 endpoints are establishing sessions to the same external destination. 388 Most applications fail in some cases with "Port Overloading". It is 389 clear that "Port Overloading" behavior will result in many problems. 390 For example it will fail if two internal endpoints try to reach the 391 same external destination, e.g., a server used by both endpoints such 392 as a SIP proxy, or a web server, etc.) 394 When NATs do allocate a new source port, there is the issue of which 395 IANA-defined range of port to choose. The ranges are "well-known" 396 from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ 397 private" from 49152 through 65535. For most protocols, these are 398 destination ports and not source ports, so mapping a source port to a 399 source port that is already registered is unlikely to have any bad 400 effects. Some NATs may choose to use only the ports in the dynamic 401 range; the only down side of this practice is that it limits the 402 number of ports available. Other NAT devices may use everything but 403 the well-known range and may prefer to use the dynamic range first or 404 possibly avoid the actual registered ports in the registered range. 405 Other NATs preserve the port range if it is in the well-known range. 406 It should be noted that port 0 is reserved and must not be used. 408 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 409 overloading". 410 a) If the host's source port was in the range 1-1023, it is 411 RECOMMENDED the NAT's source port be in the same range. If the 412 host's source port was in the range 1024-65535, it is 413 RECOMMENDED that the NAT's source port be in that range. 415 Justification for REQ-3: This requirement must be met in order to 416 enable two applications on the internal side of the NAT both to 417 use the same port to try to communicate with the same destination. 418 NATs that implement port preservation have to deal with conflicts 419 on ports, and the multiple code paths this introduces often result 420 in nondeterministic behavior. However, it should be understood 421 that when a port is randomly assigned, it may just randomly happen 422 to be assigned the same port. Applications must therefore be able 423 to deal with both port preservation, and no port preservation. 424 a) Certain applications expect the source UDP port to be in the 425 well-known range. See RFC 2623 for an example. 427 4.2.2 Port Parity 429 Some NATs preserve the parity of the UDP port, i.e., an even port 430 will be mapped to an even port, and an odd port will be mapped to an 431 odd port. This behavior respects the RFC 3550 [8] rule that RTP use 432 even ports, and RTCP use odd ports. RFC 3550 allows any port numbers 433 to be used for RTP and RTCP if the two numbers are specified 434 separately, for example using RFC 3605 [9]. However, some 435 implementations do not include RFC 3605 and do not recognize when the 436 peer has specified the RTCP port separately using RFC 3605. If such 437 an implementation receives an odd RTP port number from the peer 438 (perhaps after having been translated by a NAT), and then follows the 439 RFC 3550 rule to change the RTP port to the next lower even number, 440 this would obviously result in the loss of RTP. NAT-friendly 441 application aspects are outside the scope of this document. It is 442 expected that this issue will fade away with time, as implementations 443 improve. Preserving the port parity allows for supporting 444 communication with peers that do not support explicit specification 445 of both RTP and RTCP port numbers. 447 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 448 behavior of "Yes". 450 Justification for REQ-4: This is to avoid breaking peer-to-peer 451 applications which do not explicitly and separately specify RTP 452 and RTCP port numbers and which follow the RFC 3550 rule to 453 decrement an odd RTP port to make it even. The same 454 considerations as per the IP address pooling requirement apply. 456 4.2.3 Port Contiguity 458 Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. 459 These NATs do things like sequential assignment or port reservation. 460 Sequential port assignment assumes that the application will open a 461 mapping for RTP first and then open a mapping for RTCP. It is not 462 practical to enforce this requirement on all applications. 464 Furthermore, there is a glaring problem if many applications (or 465 endpoints) are trying to open mapping simultaneously. Port 466 preservation is also problematic since it is wasteful, especially 467 considering that a NAT cannot reliably distinguish between RTP over 468 UDP and other UDP packets where there is no contiguity rule. For 469 those reasons, it would be too complex to attempt to preserve the 470 contiguity rule by suggesting specific NAT behavior, and it would 471 certainly break the deterministic behavior rule. 473 In order to support both RTP and RTCP, it will therefore be necessary 474 that applications follow rules to negotiate RTP and RTCP separately, 475 and account for the very real possibility that the RTCP=RTP+1 rule 476 will be broken. As this is an application requirement, it is outside 477 of the scope of this document. 479 4.3 Mapping Refresh 481 NAT mapping timeout implementations vary but include the timer's 482 value and the way the mapping timer is refreshed to keep the mapping 483 alive. 485 The mapping timer is defined as the time a mapping will stay active 486 without packets traversing the NAT. There is great variation in the 487 values used by different NATs. 489 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 490 minutes. 491 a) The value of the NAT UDP mapping timer MAY be configurable. 492 b) A default value of 5 minutes for the NAT UDP mapping timer is 493 RECOMMENDED. 495 Justification for REQ-5: This requirement is to ensure that the 496 timeout is long enough to avoid too frequent timer refresh 497 packets. 498 a) Configuration is desirable for adapting to specific networks 499 and troubleshooting. 500 b) This default is to avoid too frequent timer refresh packets. 502 Some NATs keep the mapping active (i.e., refresh the timer value) 503 when a packet goes from the internal side of the NAT to the external 504 side of the NAT. This is referred to as having a NAT Outbound 505 refresh behavior of "True". 507 Some NATs keep the mapping active when a packet goes from the 508 external side of the NAT to the internal side of the NAT. This is 509 referred to as having a NAT Inbound Refresh Behavior of "True". 511 Some NATs keep the mapping active on both, in which case both 512 properties are "True". 514 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 515 refresh behavior" of "True". 516 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 517 refresh behavior" of "True". 519 Justification for REQ-6: Outbound refresh is necessary for allowing 520 the client to keep the mapping alive. 521 a) Inbound refresh may be useful for applications with no outgoing 522 UDP traffic. However, allowing inbound refresh may allow an 523 application to keep a mapping alive indefinitely. This may be 524 a security risk. Also, if the process is repeated with 525 different ports, over time, it could use up all the ports on 526 the NAT. 528 5. Filtering Behavior 530 This section describes various filtering behaviors observed in NATs. 532 5.1 Filtering of Unsolicited Packets 534 When an internal endpoint opens an outgoing session through a NAT, 535 the NAT assigns a filtering rule for the mapping between an internal 536 IP:port (X:x) and external IP:port (Y:y) tuple. 538 The key behavior to describe is what criteria are used by the NAT to 539 filter packets originating from specific external endpoints. 541 Endpoint Independent Filtering: 542 The NAT filters out only packets not destined to the internal 543 address and port X:x, regardless of the external IP address and 544 port source (Z:z). The NAT forwards any packets destined to 545 X:x. In other words, sending packets from the internal side of 546 the NAT to any external IP address is sufficient to allow any 547 packets back to the internal endpoint. 549 Address Dependent Filtering: 550 The NAT filters out packets not destined to the internal 551 address X:x. Additionally, the NAT will filter out packets 552 from Y:y destined for the internal endpoint X:x if X:x has not 553 sent packets to Y:any previously (independently of the port 554 used by Y). In other words, for receiving packets from a 555 specific external endpoint, it is necessary for the internal 556 endpoint to send packets first to that specific external 557 endpoint's IP address. 559 Address and Port Dependent Filtering: 560 This is similar to the previous behavior, except that the 561 external port is also relevant. The NAT filters out packets 562 not destined for the internal address X:x. Additionally, the 563 NAT will filter out packets from Y:y destined for the internal 564 endpoint X:x if X:x has not sent packets to Y:y previously. In 565 other words, for receiving packets from a specific external 566 endpoint, it is necessary for the internal endpoint to send 567 packets first to that external endpoint's IP address and port. 569 REQ-7: If application transparency is most important, it is 570 RECOMMENDED that a NAT have an "Endpoint independent filtering" 571 behavior. If a more stringent filtering behavior is most 572 important, it is RECOMMENDED that a NAT have an "Address dependent 573 filtering" behavior. 574 a) The filtering behavior MAY be an option configurable by the 575 administrator of the NAT. 577 OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY? 579 Justification for REQ-7: The recommendation to use Endpoint 580 Independent Filtering is aimed at maximizing application 581 transparency, in particular for applications that receive media 582 simultaneously from multiple locations (e.g., gaming), or 583 applications that use rendezvous techniques. However, it is also 584 possible that in some circumstances, it may be preferable to have 585 a more stringent filtering behavior. Filtering independently of 586 the external endpoint is not as secure: an unauthorized packet 587 could get through a specific port while the port was kept open if 588 it was lucky enough to find the port open. In theory, filtering 589 based on both IP address and port is more secure than filtering 590 based only on the IP address (because the external endpoint could 591 in reality be two endpoints behind another NAT, where one of the 592 two endpoints is an attacker): however, such a policy could 593 interfere with applications that expect to receive UDP packets on 594 more than one UDP port. Using Endpoint Independent Filtering or 595 Address Dependent Filtering instead of Address and Port Dependent 596 Filtering on a NAT (say NAT-A) also has benefits when the other 597 endpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which 598 doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses 599 Address and Port Dependent Filtering, connectivity will require a 600 Media Relay. However, if NAT-A uses Endpoint Independent 601 Filtering or Address Dependent Filtering, ICE will ultimately find 602 connectivity without requiring a Media Relay. Having the 603 filtering behavior being an option configurable by the 604 administrator of the NAT ensures that a NAT can be used in the 605 widest variety of deployment scenarios. 607 5.2 NAT Filter Refresh 609 The time for which a NAT filter is valid can be refreshed based on 610 packets that are inbound, outbound, or going either direction. 612 6. Hairpinning Behavior 614 If two hosts (called X1 and X2) are behind the same NAT and 615 exchanging traffic, the NAT may allocate an address on the outside of 616 the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it 617 goes to the NAT, which must relay the traffic from X1 to X2. This is 618 referred to as hairpinning and is illustrated below. 620 NAT 621 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 622 | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 623 +----+ | v | 624 | v | 625 | v | 626 | v | 627 +----+ from X1':x1' to X2:x2 | v | X2':x2' 628 | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 629 +----+ +-----+ 631 Hairpinning allows two endpoints on the internal side of the NAT to 632 communicate even if they only use each other's external IP addresses 633 and ports. 635 More formally, a NAT that supports hairpinning forwards packets 636 originating from an internal address, X1:x1, destined for an external 637 address X2':x2' that has an active mapping to an internal address 638 X2:x2, back to that internal address X2:x2. Note that typically X1' 639 is the same as X2'. 641 Furthermore, the NAT may present the hairpinned packet with either an 642 internal or an external source IP address and port. The hairpinning 643 NAT behavior can therefore be either "External source IP address and 644 port" or "Internal source IP address and port". "Internal source IP 645 address and port" may cause problems by confusing an implementation 646 that is expecting an external IP address and port. 648 REQ-8: A NAT MUST support "Hairpinning". 649 a) A NAT Hairpinning behavior MUST be "External source IP address 650 and port". 652 Justification for REQ-8: This requirement is to allow communications 653 between two endpoints behind the same NAT when they are trying 654 each other's external IP addresses. 655 a) Using the external IP address is necessary for applications 656 with a restrictive policy of not accepting packets from IP 657 addresses that differ from what is expected. 659 7. Application Level Gateways 661 Certain NATs have implemented Application Level Gateways (ALGs) for 662 various protocols, including protocols for negotiating peer-to-peer 663 sessions such as SIP. 665 Certain NATs have these ALGs turned on permanently, others have them 666 turned on by default but let them be be turned off, and others have 667 them turned off by default but let them be turned on. 669 NAT ALGs may interfere with UNSAF methods or protocols that try to be 670 NAT-aware and must therefore be used with extreme caution. 672 REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those 673 ALGs (except for DNS [19] and FTP [18]) be disabled by default. 674 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 675 the NAT administrator to enable or disable each ALG separately. 677 Justification for REQ-9: NAT ALGs may interfere with UNSAF methods. 678 a) This requirement allows the user to enable those ALGs that are 679 necessary to aid in the operation of some applications without 680 enabling ALGs which interfere with the operation of other 681 applications. 683 8. Deterministic Properties 685 The classification of NATs is further complicated by the fact that 686 under some conditions the same NAT will exhibit different behaviors. 687 This has been seen on NATs that preserve ports or have specific 688 algorithms for selecting a port other than a free one. If the 689 external port that the NAT wishes to use is already in use by another 690 session, the NAT must select a different port. This results in 691 different code paths for this conflict case, which results in 692 different behavior. 694 For example, if three hosts X1, X2, and X3 all send from the same 695 port x, through a port preserving NAT with only one external IP 696 address, called X1', the first one to send (i.e., X1) will get an 697 external port of x but the next two will get x2' and x3' (where these 698 are not equal to x). There are NATs where the External NAT mapping 699 characteristics and the External Filter characteristics change 700 between the X1:x and the X2:x mapping. To make matters worse, there 701 are NATs where the behavior may be the same on the X1:x and X2:x 702 mappings but different on the third X3:x mapping. 704 Some NATs that try to reuse external ports flow from two internal IP 705 addresses to two different external IP addresses. For example, X1:x 706 is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not 707 equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x 708 to X1':x. This works if the NAT mapping is address port dependent. 709 However some NATs change their behavior when this type of port reuse 710 is happening. The NAT may look like it has NAT mappings that are 711 independent when this type of reuse is not happening but may change 712 to Address Port Dependent when this reuse 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 Filtering Behavior at any 730 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 "support ICMP 751 Processing". 753 There is no significant security advantage to blocking ICMP 754 Destination Unreachable packets. Additionally, blocking ICMP 755 Destination Unreachable packets can interfere with application 756 failover, UDP Path MTU Discovery (see RFC1191 [10] and RFC1435 [15]), 757 and traceroute. Blocking any ICMP message is discouraged, and 758 blocking ICMP Destination Unreachable is strongly discouraged. 760 REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT 761 mapping. 762 a) The NAT's default configuration SHOULD NOT filter ICMP messages 763 based on their source IP address. 764 b) It is RECOMMENDED that a NAT support ICMP Destination 765 Unreachable messages. 767 Justification for REQ-11: This is easy to do, is used for many things 768 including MTU discovery and rapid detection of error conditions, 769 and has no negative consequences. 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 Section 9. 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". 845 a) A NAT MAY support receiving fragmented packets that are out of 846 order and be of type "Received Fragment Out of Order". 848 Justification for REQ-13: See Security Considerations. 850 12. Requirements 852 The requirements in this section are aimed at minimizing the 853 complications caused by NATs to applications such as realtime 854 communications and online gaming. The requirements listed earlier in 855 the document are consolidated here into a single section. 857 It should be understood, however, that applications normally do not 858 know in advance if the NAT conforms to the recommendations defined in 859 this section. Peer-to-peer media applications still need to use 860 normal procedures such as ICE [16]. 862 A NAT that supports all of the mandatory requirements of this 863 specification (i.e., the "MUST"), is "compliant with this 864 specification." A NAT that supports all of the requirements of this 865 specification (i.e., included the "RECOMMENDED") is "fully compliant 866 with all the mandatory and recommended requirements of this 867 specification." 869 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 870 independent" behavior. 871 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 872 behavior of "Paired". Note that this requirement is not 873 applicable to NATs that do not support IP address pooling. 874 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 875 overloading". 876 a) If the host's source port was in the range 1-1023, it is 877 RECOMMENDED the NAT's source port be in the same range. If the 878 host's source port was in the range 1024-65535, it is 879 RECOMMENDED that the NAT's source port be in that range. 880 REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" 881 behavior of "Yes". 882 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 883 minutes. 884 a) The value of the NAT UDP mapping timer MAY be configurable. 885 b) A default value of 5 minutes for the NAT UDP mapping timer is 886 RECOMMENDED. 888 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 889 refresh behavior" of "True". 890 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 891 refresh behavior" of "True". 892 REQ-7: If application transparency is most important, it is 893 RECOMMENDED that a NAT have "Endpoint independent filtering" 894 behavior. If a more stringent filtering behavior is most 895 important, it is RECOMMENDED that a NAT have "Address dependent 896 filtering" behavior. 897 a) The filtering behavior MAY be an option configurable by the 898 administrator of the NAT. 899 OPEN ISSUE: Should REQ-7a be a SHOULD instead of a MAY? 900 REQ-8: A NAT MUST support "Hairpinning". 901 a) A NAT Hairpinning behavior MUST be "External source IP address 902 and port". 903 REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those 904 ALGs (except for DNS [19] and FTP [18]) be disabled by default. 905 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 906 the NAT administrator to enable or disable each ALG separately. 907 REQ-10: A NAT MUST have deterministic behavior, i.e., it MUST NOT 908 change the NAT mapping or the External External Filtering Behavior 909 at any point in time or under any particular conditions. 910 REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT 911 mapping. 912 a) The NAT's default configuration SHOULD NOT filter ICMP messages 913 based on their source IP address. 914 b) It is RECOMMENDED that a NAT support ICMP Destination 915 Unreachable messages. 916 REQ-12: A NAT MUST support fragmentation of packets larger than link 917 MTU. 918 REQ-13: A NAT MUST support receiving in order fragments, so it MUST 919 be "Received Fragment Ordered" or "Received Fragment Out of 920 Order". 921 a) A NAT MAY support receiving fragmented packets that are out of 922 order and be of type "Received Fragment Out of Order". 924 13. Security Considerations 926 NATs are often deployed to achieve security goals. Most of the 927 recommendations and requirements in this document do not affect the 928 security properties of these devices, but a few of them do have 929 security implications and are discussed in this section. 931 This work recommends that the timers for mapping be refreshed only on 932 outgoing packets and does not make recommendations about whether or 933 not inbound packets should update the timers. If inbound packets 934 update the timers, an external attacker can keep the mapping alive 935 forever and attack future devices that may end up with the same 936 internal address. A device that was also the DHCP server for the 937 private address space could mitigate this by cleaning any mappings 938 when a DHCP lease expired. For unicast UDP traffic (the scope of 939 this document), it may not seem relevant to support inbound timer 940 refresh; however, for multicast UDP, the question is harder. It is 941 expected that future documents discussing NAT behavior with multicast 942 traffic will refine the requirements around handling of the inbound 943 refresh timer. Some devices today do update the timers on inbound 944 packets. 946 This work recommends that the NAT filters be specific to the external 947 IP only and not the external IP and port. It can be argued that this 948 is less secure than using the IP and port. Devices that wish to 949 filter on IP and port do still comply with these requirements. 951 Non-deterministic NATs are risky from a security point of view. They 952 are very difficult to test because they are, well, non-deterministic. 953 Testing by a person configuring one may result in the person thinking 954 it is behaving as desired, yet under different conditions, which an 955 attacker can create, the NAT may behave differently. These 956 requirements recommend that devices be deterministic. 958 The work requires that NATs have an "external NAT mapping is endpoint 959 independent" behavior. This does not reduce the security of devices. 960 Which packets are allowed to flow across the device is determined by 961 the external filtering behavior, which is independent of the mapping 962 behavior. 964 When a fragmented packet is received from the external side and the 965 packets are out of order so that the initial fragment does not arrive 966 first, many systems simply discard the out of order packets. 967 Moreover, since some networks deliver small packets ahead of large 968 ones, there can be many out of order fragments. NATs that are 969 capable of delivering these out of order packets are possible but 970 they need to store the out of order fragments, which can open up a 971 DoS opportunity if done incorrectly. Fragmentation has been a tool 972 used in many attacks, some involving passing fragmented packets 973 through NATs and others involving DoS attacks based on the state 974 needed to reassemble the fragments. NAT implementers should be aware 975 of RFC 3128 [12] and RFC 1858 [11]. 977 14. IANA Considerations 979 There are no IANA considerations. 981 15. IAB Considerations 983 The IAB has studied the problem of "Unilateral Self Address Fixing", 984 which is the general process by which a client attempts to determine 985 its address in another realm on the other side of a NAT through a 986 collaborative protocol reflection mechanism [2]. 988 This specification does not in itself constitute an UNSAF 989 application. It consists of a series of requirements for NATs aimed 990 at minimizing the negative impact that those devices have on peer-to- 991 peer media applications, especially when those applications are using 992 UNSAF methods. 994 Section 3 of UNSAF lists several practical issues with solutions to 995 NAT problems. This document makes recommendations to reduce the 996 uncertainty and problems introduced by these practical issues with 997 NATs. In addition, UNSAF lists five architectural considerations. 998 Although this is not an UNSAF proposal, it is interesting to consider 999 the impact of this work on these architectural considerations. 1001 Arch-1: The scope of this is limited to UDP packets in NATs like the 1002 ones widely deployed today. The "fix" helps constrain the 1003 variability of NATs for true UNSAF solutions such as STUN. 1004 Arch-2: This will exit at the same rate that NATs exit. It does not 1005 imply any protocol machinery that would continue to live 1006 after NATs were gone or make it more difficult to remove 1007 them. 1008 Arch-3: This does not reduce the overall brittleness of NATs but will 1009 hopefully reduce some of the more outrageous NAT behaviors 1010 and make it easer to discuss and predict NAT behavior in 1011 given situations. 1012 Arch-4: This work and the results [17] of various NATs represent the 1013 most comprehensive work at IETF on what the real issues are 1014 with NATs for applications like VoIP. This work and STUN 1015 have pointed out more than anything else the brittleness NATs 1016 introduce and the difficulty of addressing these issues. 1017 Arch-5: This work and the test results [17] provide a reference model 1018 for what any UNSAF proposal might encounter in deployed NATs. 1020 16. Acknowledgments 1022 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 1023 Dan Kegel for the their multiple contributions on peer-to-peer 1024 communications across a NAT. Dan Wing contributed substantial text 1025 on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, 1026 Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, 1027 Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert 1028 Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka 1029 Takeda and Paul Hoffman for their contributions. 1031 17. References 1032 17.1 Normative References 1034 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1035 Levels", BCP 14, RFC 2119, March 1997. 1037 [2] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1038 Address Fixing (UNSAF) Across Network Address Translation", 1039 RFC 3424, November 2002. 1041 17.2 Informational References 1043 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1044 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1046 [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1047 Translator (Traditional NAT)", RFC 3022, January 2001. 1049 [5] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 1050 IP Network Address Translator", RFC 3027, January 2001. 1052 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1053 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1054 Session Initiation Protocol", RFC 3261, June 2002. 1056 [7] Rosenberg, J., Huitema, C., and R. Mahy, "STUN - Simple 1057 Traversal of User Datagram Protocol (UDP) Through Network 1058 Address Translators (NATs)", draft-ietf-behave-rfc3489bis (work 1059 in progress), February 2003. 1061 [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1062 "RTP: A Transport Protocol for Real-Time Applications", 1063 RFC 3550, July 2003. 1065 [9] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1066 Session Description Protocol (SDP)", RFC 3605, October 2003. 1068 [10] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1069 November 1990. 1071 [11] Ziemba, G., Reed, D., and P. Traina, "Security Considerations 1072 for IP Fragment Filtering", RFC 1858, October 1995. 1074 [12] Miller, I., "Protection Against a Variant of the Tiny Fragment 1075 Attack (RFC 1858)", RFC 3128, June 2001. 1077 [13] Postel, J., "Internet Control Message Protocol", STD 5, 1078 RFC 792, September 1981. 1080 [14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1081 June 1995. 1083 [15] Knowles, S., "IESG Advice from Experience with Path MTU 1084 Discovery", March 1993. 1086 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1087 Methodology for Network Address Translator (NAT) Traversal for 1088 the Session Initiation Protocol (SIP)", 1089 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 1091 [17] Jennings, C., "NAT Classification Results using STUN", 1092 draft-jennings-behave-test-results-00 (work in progress), 1093 February 2005. 1095 [18] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 1096 RFC 959, October 1985. 1098 [19] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 1099 SPECIFICATION", RFC 1035, November 1987. 1101 [20] "Packet-based Multimedia Communications Systems", ITU- 1102 T Recommendation H.323, July 2003. 1104 Authors' Addresses 1106 Francois Audet (editor) 1107 Nortel Networks 1108 4655 Great America Parkway 1109 Santa Clara, CA 95054 1110 US 1112 Phone: +1 408 495 3756 1113 Email: audet@nortel.com 1115 Cullen Jennings 1116 Cisco Systems 1117 170 West Tasman Drive 1118 MS: SJC-21/2 1119 San Jose, CA 95134 1120 US 1122 Phone: +1 408 902 3341 1123 Email: fluffy@cisco.com 1125 Intellectual Property Statement 1127 The IETF takes no position regarding the validity or scope of any 1128 Intellectual Property Rights or other rights that might be claimed to 1129 pertain to the implementation or use of the technology described in 1130 this document or the extent to which any license under such rights 1131 might or might not be available; nor does it represent that it has 1132 made any independent effort to identify any such rights. Information 1133 on the procedures with respect to rights in RFC documents can be 1134 found in BCP 78 and BCP 79. 1136 Copies of IPR disclosures made to the IETF Secretariat and any 1137 assurances of licenses to be made available, or the result of an 1138 attempt made to obtain a general license or permission for the use of 1139 such proprietary rights by implementers or users of this 1140 specification can be obtained from the IETF on-line IPR repository at 1141 http://www.ietf.org/ipr. 1143 The IETF invites any interested party to bring to its attention any 1144 copyrights, patents or patent applications, or other proprietary 1145 rights that may cover technology that may be required to implement 1146 this standard. Please address the information to the IETF at 1147 ietf-ipr@ietf.org. 1149 Disclaimer of Validity 1151 This document and the information contained herein are provided on an 1152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1159 Copyright Statement 1161 Copyright (C) The Internet Society (2005). This document is subject 1162 to the rights, licenses and restrictions contained in BCP 78, and 1163 except as set forth therein, the authors retain all their rights. 1165 Acknowledgment 1167 Funding for the RFC Editor function is currently provided by the 1168 Internet Society.