idnits 2.17.1 draft-ietf-behave-nat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1071. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1087), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (October 15, 2004) is 7125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3424 (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '7') (Obsoleted by RFC 5389) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-02 == Outdated reference: A later version (-02) exists of draft-jennings-midcom-stun-results-01 -- Obsolete informational reference (is this intentional?): RFC 923 (ref. '17') (Obsoleted by RFC 943) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE F. Audet 3 Internet-Draft Nortel Networks 4 Expires: April 15, 2005 C. Jennings 5 Cisco Systems 6 October 15, 2004 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-00 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 April 15, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document defines basic terminology for describing different 43 types of behavior for NATs when handling unicast UDP. It also 44 defines a set of requirements for NATs that would allow many 45 applications, such as multimedia communications or online gaming, to 46 work consistently. Developing NATs that meet this set of 47 requirements will greatly increase the likelihood that applications 48 will function properly. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Network Address and Port Translation Behavior . . . . . . . 6 56 3.1 Address and Port Binding . . . . . . . . . . . . . . . . . 6 57 3.2 Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 58 3.3 Bind Refresh Direction . . . . . . . . . . . . . . . . . . 9 59 3.4 Bind Refresh Scope . . . . . . . . . . . . . . . . . . . . 10 60 4. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . 10 61 4.1 Filtering of Unsolicited Packets . . . . . . . . . . . . . 10 62 4.2 NAT Filter Refresh . . . . . . . . . . . . . . . . . . . . 11 63 5. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . 11 64 6. Application Level Gateways . . . . . . . . . . . . . . . . . 12 65 7. Deterministic Properties . . . . . . . . . . . . . . . . . . 12 66 8. ICMP Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. Fragmentation of Packets . . . . . . . . . . . . . . . . . . 14 68 9.1 Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 14 69 9.2 Smaller Network MTU . . . . . . . . . . . . . . . . . . . 14 70 10. Receiving Fragmented Packets . . . . . . . . . . . . . . . . 14 71 11. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 72 11.1 Requirement Discussion . . . . . . . . . . . . . . . . . 17 73 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 75 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 16.1 Normative References . . . . . . . . . . . . . . . . . . . 21 79 16.2 Informational References . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 81 Intellectual Property and Copyright Statements . . . . . . . 24 83 1. Introduction 85 Network Address Translators (NAT) are well known to cause very 86 significant problems with applications that carry IP addresses in the 87 payload RFC 3027 [5]. Applications that suffer from this problem 88 include Voice Over IP and Multimedia Over IP (e.g., SIP [6] and H.323 89 [11]), as well as online gaming. 91 Many techniques are used to attempt to make realtime multimedia 92 applications, online games, and other applications work across NATs. 93 Application Level Gateways [3] are one such mechanism. STUN [7] 94 describes a UNilateral Self-Address Translation (UNSAF) mechanism [2] 95 . UDP Relays have also been used to enable applications across NATs, 96 but these are generally seen as a solution of last resort. ICE [9] 97 describes a methodology for using many of these techniques and 98 avoiding a UDP Relay unless the type of NAT is such that it forces 99 the use of such a UDP Relay. This specification defines requirements 100 for improving NATs. Meeting these requirements ensures that 101 applications will not be forced to use UDP media relay. 103 Several recommendations regarding NATs for Peer-to-Peer media were 104 made in [10] and this specification derives some of its requirements 105 from that draft. 107 As pointed out in UNSAF [2] , "From observations of deployed 108 networks, it is clear that different NAT boxes' implementation vary 109 widely in terms of how they handle different traffic and addressing 110 cases." This wide degree of variability is one part of what 111 contributes to the overall brittleness introduced by NATs and makes 112 it extremely difficult to predict how any given protocol will behave 113 on a network traversing NATs. Discussions with many of the major NAT 114 vendors have made it clear that they would prefer to deploy NATs that 115 were deterministic and caused the least harm to applications while 116 still meeting the requirements that caused their customers to deploy 117 NATs in the first place. The problem the NAT vendors face is they 118 are not sure how best to do that or how to document how their NATs 119 behave. 121 The goals of this document are to define a set of common terminology 122 for describing the behavior of NATs and to produce a set of 123 requirements on a specific set of behaviors for NATs. The 124 requirements represent what many vendors are already doing, and it is 125 not expected that it should be any more difficult to build a NAT that 126 meets these requirements or that these requirements should affect 127 performance. 129 The authors strongly believe that if there were a common set of 130 requirements that were simple and useful for voice, video, and games, 131 the bulk of the NAT vendors would choose to meet those requirements. 132 This document will simplify the analysis of protocols for deciding 133 whether or not they work in this environment and will allow providers 134 of services that have NAT traversal issues to make statements about 135 where their applications will work and where they will not, as well 136 as to specify requirements for NATs. 138 1.1 Scope 140 This specification only covers Traditional NATs [4]. Bi-directional, 141 Twice NAT, and Multihomed NAT [3] are outside the scope of this 142 document. 144 Approaches using directly signaled control off the middle boxes such 145 as Midcom, UPnP, or in-path signaling are out of scope. 147 UDP Relays are out of the scope of this document. 149 Application aspects are out of scope as the focus is strictly on the 150 NAT itself. 152 This document only covers the UDP unicast aspects of NAT traversal 153 and does not cover TCP, ICMP, IPSEC, or other protocols. Since the 154 document is on UDP unicast only, packet inspection below the UDP 155 layer (including RTP) is also out-of-scope. 157 This document does not cover Firewalls. However, it does cover the 158 inherent filtering aspects of NATs. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [1]. 166 It is assumed that the reader is familiar with the terminology 167 described in RFC 2663 [3] and RFC 3022 [4]. This specification 168 attempts to preserve the terminology used in those RFCs. 170 This document uses the term "session" as defined in RFC 2663 [3]: 171 "TCP/UDP sessions are uniquely identified by the tuple of (source IP 172 address, source TCP/UDP ports, target IP address, target TCP/UDP 173 Port)." 175 This document uses the term "address binding" as defined in RFC 2663 176 RFC 3022: "Address binding is the phase in which a local IP address 177 is associated with an external address, or vice versa, for purpose of 178 translation." 179 The term NAT is used to refer to both traditional address translation 180 and address port translation. The authors understand that there was 181 a time when these were considered different, but terminology has 182 changed over time, and the term NAT has subsumed port translation as 183 part of it. 185 RFC 3489 [7] defines a terminology for different NAT variations. In 186 particular, it uses the terms "Full Cone", "Restricted Cone", "Port 187 Restricted Cone" and "Symmetric" to refer to different variations of 188 NATs. Unfortunately, this terminology has been the source of much 189 confusion. This terminology does not distinguish between the NAT 190 behavior and the filtering behavior of the device. It was found that 191 many devices' behaviors do not exactly fit into the described 192 variations. For example, a device could be symmetric from a 193 filtering point of view and Cone from a NAT point of view. Other 194 aspects of NATs are not covered by this terminology: for example, 195 many NATs will switch over from basic NAT (preserving ports) to NAPT 196 (mapping ports) in order to preserve ports when possible. 198 This specification will therefore not use the Cone/Symmetric 199 terminology. Furthermore, many other important behaviors are not 200 fully described by the Cone/Symmetric terminology. This 201 specification refers to specific individual NAT behaviors instead of 202 using the Cone/Symmetric terminology. 204 Note: RFC 3489 defines a "Symmetric NAT" in effectively two parts: 206 1. All requests from the same internal IP address and port to a 207 specific destination IP address and port are mapped to the same 208 external IP address and port. If a host sends a packet with the 209 same source address and port to different destination addresses 210 or ports, a different mapping is used for each. 211 2. Furthermore, only the external host that receives a packet can 212 send a UDP packet back to the internal host. 214 Condition 1 is the NAT behavior and condition 2 is the filtering 215 behavior. However, they are not necessarily dependent: we have 216 observed NATs that will conform to condition (1) but not to (2). 217 Using RFC 3489, this type of NAT would be detected as a "Cone NAT" 218 since it uses condition (2). Using a different algorithm such as the 219 one described in NATCHECK [12] which uses condition (1), the same NAT 220 would be detected as a "Symmetric NAT". If the endpoint receiving 221 the media has a permissive policy on accepting media, condition (2) 222 is more appropriate, but if it has a restrictive policy, condition 223 (1) is more appropriate. 225 3. Network Address and Port Translation Behavior 227 This section describes the various NAT behaviors applicable to 228 dynamic NAT; static NAT is outside the scope of this document. 230 3.1 Address and Port Binding 232 When an internal endpoint opens an outgoing UDP session through a 233 NAT, the NAT assigns the session an external IP address and port 234 number so that subsequent response packets from the external endpoint 235 can be received by the NAT, translated and forwarded to the internal 236 endpoint. This is a binding between an internal IP address and port 237 (IP:port) and external IP:port tuple. It establishes the translation 238 that will be performed by the NAT for the duration of the session. 239 For many applications, it is important to distinguish the behavior of 240 the NAT when there are multiple simultaneous sessions established to 241 different external endpoints. 243 The key behavior to describe is the criteria for re-use of a binding 244 for new sessions to external endpoints, after establishing a first 245 binding between an internal X:x address and port and an external 246 Y1:y1 address tuple. Let's assume that the internal IP address and 247 port X:x is mapped to X1':x1' for this first session. The endpoint 248 then sends from X:x to an external address Y2:y2 and gets a mapping 249 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 250 for various combinations of the relationship between Y1:y1 and Y2:y2 251 is critical for describing the NAT behavior. This arrangement is 252 illustrated in the following diagram: 254 E 255 +------+ +------+ x 256 | Y1 | | Y2 | t 257 +--+---+ +---+--+ e 258 | Y1:y1 Y2:y2 | r 259 +----------+ +----------+ n 260 | | a 261 X1':x1' | | X2':x2' l 262 +--+---+-+ 263 ...........| NAT |............... 264 +--+---+-+ I 265 | | n 266 X:x | | X:x t 267 ++---++ e 268 | X | r 269 +-----+ n 270 a 271 l 273 The following address and port binding behavior are defined: 275 External NAT binding is endpoint independent: The NAT reuses the port 276 binding for subsequent sessions initiated from the same internal 277 IP address and port (X:x) to any external IP address and port. 278 Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. 279 (From an RFC 3489 NAT perspective, this is a "Cone NAT" where the 280 sub-type is really based on the filtering behavior.) 282 External NAT binding is endpoint address dependent: The NAT reuses 283 the port binding for subsequent sessions initiated from the same 284 internal IP address and port (X:x) only for sessions to the same 285 external IP address, regardless of the external port. 286 Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals 287 Y1. (From an RFC 3489 NAT perspective, but not necessarily a 288 filtering perspective, this is a "Symmetric NAT".) 290 External NAT binding is endpoint address and port dependent: The NAT 291 reuses the port binding for subsequent sessions initiated from the 292 same internal IP address and port (X:x) only for sessions to the 293 same external and port. Specifically, X1':x1' equals X2':x2' if, 294 and only if, Y2:y2 equals Y1:y1. (From an RFC 3489 NAT 295 perspective, but not necessarily a filtering perspective, this is 296 a "Symmetric NAT".) 298 The three possibilities are abbreviated as NB=I, NB=AD, and NB=APD, 299 respectively. NB stands for Nat Binding, I for independent, AD for 300 Address Dependent, and APD for Address Port Dependent. 302 It is important to note that these three possible choices make no 303 difference to the security properties of the NAT. The security 304 properties are fully determined by which packets the NAT allows in 305 and which it does not. This is determined by the filtering behavior 306 in the filtering portions of the NAT. 308 Some NATs are capable of assigning IP addresses from a pool of IP 309 addresses on the external side of the NAT, as opposed to just a 310 single IP address. This is especially common with larger NATs. Some 311 NATs use the external IP address binding in an arbitrary fashion 312 (i.e. randomly): one internal IP address could have multiple 313 external IP address bindings active at the same time for different 314 sessions. These NATs have an "IP address pooling" behavior of 315 "arbitrary". Other NATs use the same external IP address binding for 316 all sessions associated with the same internal IP address in any 317 circumstance, even if ports are running out, in which case they would 318 fail to establish a session. These NATs have an "IP address pooling" 319 behavior of "Paired, strict." Yet other NATs use the same external IP 320 address binding for all sessions associated with the same IP internal 321 IP address only when possible. These NATs have an "IP address 322 pooling" behavior of "Paired, best effort." NATs that use an "IP 323 address pooling" behavior of "arbitrary" can cause issues for 324 applications that use multiple ports from the same endpoint but have 325 no way to negotiate IP addresses individually (e.g., RTP and RTCP 326 ports). 328 3.2 Port Assignment 330 Some NATs attempt to preserve the port number used internally when 331 assigning a binding to an external IP address and port (e.g., X:x to 332 X':x). A basic NAT, for example, will preserve the same port and 333 will assign a different IP address from a pool of external IP 334 addresses in case of port collision (e.g. X1:x to X1':x and X2:x to 335 X2':x). This is only possible as long as the NAT has enough external 336 IP addresses. If the port x is already in use on all available 337 external IP addresses, then the NAT needs to switch from Basic NAT to 338 a Network Address and Port Translator (NAPT) mode (i.e., X1:x to X':x 339 and X2:x to X':x'). This is referred to as "port preservation". It 340 does not guarantee that the external port x' will always be the same 341 as the internal port x but only that the NAT will preserve the port 342 if possible. 344 A NAT that does not attempt to make the external port numbers match 345 the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to 346 X':x2') is referred to as "no port preservation". 348 Tools such as network sniffers identify traffic based on the 349 destination port, not the source port, so port preservation does not 350 help these tools. 352 Some particularly nasty NATs use port overloading, i.e. they always 353 use port preservation even in the case of collision (i.e., X1:x to 354 X':x, and X2:x to X':x). These NATs rely on the source of the 355 response from the external endpoint (Y:y, Z:z) to forward a packet to 356 the proper internal endpoint (X1 or X2). Port overloading fails if 357 the two internal endpoints are establishing sessions to the same 358 external destination. This is referred to as "port overloaded". 360 Most applications fail in some cases with "Port overloaded". It is 361 clear that "port overloaded" behavior will result in many problems. 363 Some NATs preserve the parity of the UDP port, i.e., an even port 364 will be mapped to an even port, and an odd port will be mapped to an 365 odd port. This behavior respects the RFC 3550 [8] rule that RTP use 366 even ports, and RTCP use odd ports. There is some very unfortunate 367 wording in RFC 3550 section 11, which can cause some problematic 368 behavior in RTP clients. The wording could be interpreted as saying 369 that if a client receives an odd port for sending RTP, it SHOULD 370 change it to the next lower even number. This would obviously result 371 in the loss of RTP/UDP. In the event that a NAT supporting port 372 parity preservation is running out of available ports for a specific 373 parity, it may either fail to assign a port, or it could decide not 374 respect port parity. We refer to these properties as "port parity 375 preservation" of "No", "Yes, strict" and "Yes, best effort". 377 When NATs do allocate a new source port, there is the issue of which 378 IANA-defined range of port to choose. The ranges are "well-known" 379 from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ 380 private" from 49152 through 65535. For most protocols, these are 381 destination ports and not source ports, so mapping a source port to a 382 source port that is already registered is unlikely to have any bad 383 effects. There has been some suggestion that some IDS systems with 384 deep packet inspection devices may end up looking at the ports. This 385 is clearly true for destination ports but less understood for source 386 ports. Some NATs may choose to use only the ports in the dynamic 387 range; the only down side of this practice is that it limits the 388 number of ports available. Other NAT devices may use everything but 389 the well-known range and may prefer to use the dynamics range first 390 or possibly avoid the actual registered ports in the registered 391 range. 393 3.3 Bind Refresh Direction 395 NAT UDP binding timeout implementations vary but include the timer's 396 value and the way the binding timer is refreshed to keep the binding 397 alive. 399 The binding timer is defined as the time a binding will stay active 400 without packets traversing the NAT. There is great variation in the 401 values used by different NATs. 403 Some NATs keep the binding active (i.e., refresh the timer value) 404 when a packet goes from the internal side of the NAT to the external 405 side of the NAT. This is referred to as having an Outbound NAT 406 refresh behavior of "True". 408 Some NATs keep the binding active when a packet goes from the 409 external side of the NAT to the internal side of the NAT. This is 410 referred to as having an Inbound NAT refresh direction behavior of 411 "True". 413 Some NATs keep the binding active on both, in which case both 414 properties are "True". 416 3.4 Bind Refresh Scope 418 If the binding is refreshed for all sessions on that bind by any 419 outbound traffic, the NAT is said to have a NAT refresh method 420 behavior of "Per binding". If the binding is refreshed only on a 421 specific session on that particular bind by any outbound traffic, the 422 NAT is said to have a "Per session" NAT refresh method behavior. 424 4. Filtering Behavior 426 This section describes various filtering behaviors observed in NATs. 428 4.1 Filtering of Unsolicited Packets 430 When an internal endpoint opens an outgoing UDP session through a 431 NAT, the NAT assigns a filtering rule for the binding between an 432 internal IP:port (X:x) and external IP:port (Y:y) tuple. 434 The key behavior to describe is what criteria are used by the NAT to 435 filter packets originating from specific external endpoints. 437 External filtering is open: The NAT does not filter any packets. 439 External filtering is endpoint independent: The NAT filters out only 440 packets not destined to the internal address and port X:x, 441 regardless of the external IP address and port source (Z:z). The 442 NAT forwards any packets destined to X:x. In other words, sending 443 packets from the internal side of the NAT to any external IP 444 address is sufficient to allow any packets back to the internal 445 endpoint. (From an RFC 3489 filtering perspective, this is a 446 "Full Cone NAT".) 448 External filtering is endpoint address dependent: The NAT filters out 449 packets not destined to the internal address X:x. Additionally, 450 the NAT will filter out packets from Y:y destined for the internal 451 endpoint X:x if X:x has not sent packets to Y previously 452 (independently of the port used by Y). In other words, for 453 receiving packets from a specific external endpoint, it is 454 necessary for the internal endpoint to send packets first to that 455 specific external endpoint's IP address. (From an RFC 3489 456 filtering perspective, this is a "Restricted Cone NAT".) 458 External filtering is endpoint address and port dependent: This is 459 similar to the previous behavior, except that the external port is 460 also relevant. The NAT filters out packets not destined for the 461 internal address X:x. Additionally, the NAT will filter out 462 packets from Y:y destined for the internal endpoint X:x if X:x has 463 not sent packets to Y:y previously. In other words, for receiving 464 packets from a specific external endpoint, it is necessary for the 465 internal endpoint to send packets first to that external 466 endpoint's IP address and port. (From an RFC 3489 filtering 467 perspective, this is both a "Port Restricted Cone NAT" and a 468 "Symmetric NAT" as they have the same filtering behavior.) 470 These are abbreviated as EF=O, EF=I, EF=AD, EF=APD respectively. In 471 the case of a NAT, "open" cannot forward a packet unless there is a 472 NAT binding, so for all practical purposes, a NAT will never be 473 "open" but will be one of the others. 475 4.2 NAT Filter Refresh 477 The time for which a NAT filter is valid can be refreshed based on 478 packets that are inbound, outbound, or going either direction. In 479 the case of EF=AD or EF=APD NATs, the scope of the refresh could 480 include the filters for just the particular port and destination or 481 for all the ports and destinations sharing the same external address 482 and port on the NAT. 484 5. Hairpinning Behavior 486 If two hosts (called X1 and X2) are behind the same NAT and 487 exchanging traffic, the NAT may allocate an address on the outside of 488 the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it 489 goes to the NAT, which must relay the traffic from X1 to X2. This is 490 referred to as hairpinning and is illustrated below. 492 NAT 493 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 494 | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 495 +----+ | v | 496 | v | 497 | v | 498 | v | 499 +----+ from X2':x2' to X1:x1 | v | X2':x2' 500 | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 501 +----+ +-----+ 503 Hairpinning allows two endpoints on the internal side of the NAT to 504 communicate even if they only use each other's external IP addresses 505 and ports. 507 More formally, a NAT that supports hairpinning forwards packets 508 originating from an internal address, X1:x1, destined for an external 509 address X2':x2' that has an active binding to an internal address 510 X2:x2, back to that internal address X2:x2. (Note that typically, 511 X1'=X2'.) 513 Furthermore, the NAT may present the hairpinned packet with either an 514 internal or an external source IP address and port. The hairpinning 515 NAT behavior can therefore be either "External source IP address and 516 port" or "Internal source IP address and port". "Internal source IP 517 address and port" may cause problems by confusing an implementation 518 that is expecting an external IP address and port. 520 6. Application Level Gateways 522 Certain NATs have implemented Application Level Gateways (ALGs) for 523 various protocols, including protocols for negotiating peer-to-peer 524 UDP sessions. 526 Certain NATs have these ALGs turned on permanently, others have them 527 turned on by default but let them be be turned off, and others have 528 them turned off by default but let them be turned on. 530 NAT ALGs may interfere with UNSAF methods and must therefore be used 531 with extreme caution. 533 7. Deterministic Properties 535 The diagnosis is further complicated by the fact that under some 536 conditions the same NAT will exhibit different behaviors. This has 537 been seen on NATs that preserve ports or have specific algorithms for 538 selecting a port other than a free one. If the external port that 539 the NAT wishes to use is already in use by another session, the NAT 540 must select a different port. This results in different code paths 541 for this conflict case, which results in different behavior. 543 For example, if three hosts X1, X2, and X3 all send from the same 544 port x, through a port preserving NAT with only one external IP 545 address, called X1', the first one to send (i.e., X1) will get an 546 external port of x but the next two will get x2' and x3' (where these 547 are not equal to x). There are NATs where the External NAT Binding 548 characteristics and the External Filter characteristics change 549 between the X1:x and the X2:x binding. To make matters worse, there 550 are NATs where the behavior may be the same on the X1:x and X2:x 551 binds but different on the third X3:x binding. 553 Some NATs that try to reuse external ports flow from two internal IP 554 addresses to two different external IP addresses. For example, X1:x 555 is going to Y1:y1 and X2:x is going to Y2:y2, where Y1:y1 does not 556 equal Y2:y2. Some NATs will map X1:x to X1':x and will also map X2:x 557 to X1':x. This works in the case where the NAT Binding is address 558 port dependent. However some NATs change their behavior when this 559 type of port reuse is happening. The NAT may look like it has NAT 560 Bindings that are independent when this type of reuse is not 561 happening but may change to Address Port Dependent when this reuse 562 happens. 564 Any NAT that changes the NAT Binding or the External Filtering at any 565 point in time or under any particular conditions is referred to as a 566 "non-deterministic" NAT. NATs that don't are called "deterministic". 568 Non-deterministic NATs generally change behavior when a conflict of 569 some sort happens, i.e. when the port that would normally be used is 570 already in use by another bind. The NAT binding and External 571 Filtering in the absence of conflict is referred to as the Primary 572 behavior. The behavior after the first conflict is referred to as 573 Secondary and after the second conflict is referred to as Tertiary. 574 No NATs have been observed that change on further conflicts but 575 additional testing may be required. 577 8. ICMP Behavior 579 There are cases in which a host inside the NAT sends a packet to the 580 NAT that gets relayed towards a host on the external side of the NAT 581 that results in an ICMP Destination Unreachable message being 582 returned to the NAT. Most NATs will send an appropriate ICMP 583 Destination Unreachable message to the internal host that sent the 584 original packet. NATs that do not filter out this ICMP Destination 585 Unreachable message when it is in reply to a IP packet sent are 586 referred to as "Support Destination Unreachable" (abbreviated SU). 588 Incoming Destination Unreachable messages can be ignored after some 589 period of time after the packet which elicited the Destination 590 Unreachable message. This IMCP timeout needs to be greater than the 591 RTT for any destination the NAT may attempt to send IP packets to. 592 Keep in mind satellite links when setting this timeout. 594 Applications use the destination unreachable message to decide that 595 they can stop trying to retransmit to a particular IP address and can 596 fail over to a secondary address. If a destination unreachable 597 message is not received, the fail over will take too long for many 598 applications. Another key use of this message is for MTU discovery 599 (described in RFC 1191 [14]). MTU discovery is important for 600 allowing applications to avoid the fragmentation problems discussed 601 in the next section. The arrival of a destination unreachable packet 602 cannot destroy the NAT binding, as the occasional arrival of these 603 messages is normal for black-hole discovery RFC 2923 [17]. 605 There is no significant security advantage to blocking these ICMP 606 Destination Unreachable packets. 608 9. Fragmentation of Packets 610 When sending a packet, there are two situations that may cause IP 611 fragmentation for packets from the inside to the outside. It is 612 worth noting that many IP stacks do not use Path MTU Discovery with 613 UDP packets. 615 9.1 Smaller Adjacent MTU 617 The first situation is when the MTU of the adjacent link is too 618 small. This can occur if the NAT is doing PPPoE, or if the NAT has 619 been configured with a small MTU to reduce serialization delay when 620 sending large packets and small, higher-priority packets. 622 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 623 (DF=0). 625 If the packet has DF=1, the NAT should send back an ICMP message 626 "fragmentation needed and DF set" message to the host RFC 792 [18]. 628 If the packet has DF=0, the NAT should fragment the packet and send 629 the fragments, in order. This is the same function a router performs 630 in a similar situation RFC 1812 [19]. 632 NATs that operate as described in this section are described as 633 "Supports Fragmentation" (abbreviated SF). 635 9.2 Smaller Network MTU 637 The second situation is when the MTU in the middle of the network is 638 too small. If DF=0, the router adjacent to the small-MTU segment 639 will fragment the packet and forward the fragments RFC 1812 [19]. 641 If DF=1, the router adjacent to the small-MTU segment will send the 642 ICMP message "fragmentation needed and DF set" back towards the NAT. 643 The NAT needs to forward this ICMP message to the inside host. 645 The classification of NATs that perform this behavior is covered in 646 the ICMP section of this document. 648 10. Receiving Fragmented Packets 650 For a variety of reasons, a NAT may receive a fragmented UDP packet. 651 The IP packet containing the UDP header could arrive first or last 652 depending on network conditions, packet ordering, and the 653 implementation of the IP stack that generated the fragments. 655 A NAT that is capable only of receiving UDP fragments in order (that 656 is, with the UDP header in the first packet) and forwarding each of 657 the fragments to the internal host is described as Received Fragments 658 Ordered (abbreviated RF=O). 660 A NAT that is capable of receiving UDP fragments in or out of order 661 and forwarding the individual packets (or a reassembled packet) to 662 the internal host is referred to as Receive Fragments Out of Order 663 (abbreviated RF=OO). See the Security Considerations section of this 664 document for a discussion of this behavior. 666 A NAT that is neither of these is referred to as Receive Fragments 667 None (abbreviated RF=N). 669 11. Requirements 671 The requirements in this section are aimed at minimizing the damage 672 caused by NATs to applications such as realtime communications and 673 online gaming. 675 It should be understood, however, that applications normally do not 676 know in advance if the NAT conforms to the recommendations defined in 677 this section. Peer-to-peer media applications still need to use 678 normal procedures such as ICE [9]. 680 REQ-1: A NAT MUST have an "External NAT Binding is endpoint 681 independent" behavior (NB=I). 683 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 684 behavior of "Paired, best effort". Note that this requirement is 685 not applicable to NATs that do not support IP address pooling. 687 REQ-2a: A NAT MAY have an "IP address pooling" behavior of 688 "Yes, strict." 689 REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of 690 "No". 692 REQ-3: It is RECOMMENDED that a NAT have a "No port preservation" 693 behavior. 695 REQ-3a: A NAT MAY use a "Port preservation" behavior. 696 REQ-3b: A NAT MUST NOT have a "Port overloaded" behavior. 697 REQ-3c: If the NAT changes the source port, it MUST NOT 698 allocate the new port from within the range of 0-1023. 700 REQ-4: It is RECOMMENDED that a NAT have a "Port parity 701 preservation" behavior of "Yes, best effort". 703 REQ-4a: A NAT MAY have a "Port parity preservation" behavior of 704 "Yes, strict." 705 REQ-4b: A NAT MUST NOT have a "Port parity preservation" 706 behavior of "No". 708 REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less 709 than 2 minutes. 711 REQ-5a: The value of the NAT UDP binding timer MAY be 712 configurable. 713 REQ-5b: A default value of 5 minutes for the NAT UDP binding 714 timer is RECOMMENDED. 716 REQ-6: The NAT UDP timeout binding MUST have a NAT Outbound 717 refresh behavior of "True". 719 REQ-6a: The NAT UDP timeout binding MAY have a NAT Inbound 720 refresh behavior of "True". 721 REQ-6b: The NAT UDP timeout binding MUST have a NAT refresh 722 method behavior of "Per binding" (i.e. refresh all sessions 723 active on a particular bind). 725 REQ-7: It is RECOMMENDED that a NAT have an "External filtering is 726 endpoint address dependent" behavior. (EF=AD) 728 REQ-7a: A NAT MAY have an "External filtering is endpoint 729 independent" behavior. (EF=I) 730 REQ-7b: A NAT MAY have an "External filtering is endpoint 731 address and port dependent" behavior. (EF=APD) 733 REQ-8: The NAT UDP filter timeout behavior MUST be the same as the 734 NAT UDP binding timeout. 736 REQ-9: A NAT MUST support "Hairpinning" behavior. 738 REQ-9a: A NAT Hairpinning behavior MUST be "External source IP 739 address and port". 741 REQ-10: A NAT MUST have the capability to turn off individually 742 all ALGs it supports, except for DNS and IPsec. 744 REQ-10a: Any NAT ALG for SIP MUST be turned off by default. 746 REQ-11: A NAT MUST have deterministic behavior. 748 REQ-12: A NAT MUST support ICMP Destination Unreachable (SU). 750 REQ-12a: The ICMP timeout SHOULD be greater than 2 seconds. 751 REQ-13: A NAT MUST support fragmentation of packets larger than 752 link MTU (SF). 754 REQ-14: A NAT MUST support receiving in order fragments, so it 755 MUST be RF=O or RF=OO. 757 REQ-14a: A NAT MAY support receiving fragmented packets that 758 are out of order and be of type RF=OO. 760 11.1 Requirement Discussion 762 This section describes why each of these requirements was chosen and 763 the consequences of violating any of them: 765 REQ-1: In order for UNSAF methods to work, REQ-1 needs to be met. 766 Failure to meet REQ-1 will force the use of a Media Relay which is 767 very often impractical. 769 REQ-2: This will allow applications that use multiple ports 770 originating from the same internal IP address to also have the 771 same external IP address, but without running out of ports 772 unnecessarily. 774 REQ-3: NATs that implement port preservation have to deal with 775 conflicts on ports, and the multiple code paths this introduces 776 often result in nondeterministic behavior. 778 REQ-3a: Port preservation can work, but the NAT implementors 779 need to be very careful that it does not become a 780 nondeterministic NAT. 781 REQ-3b: REQ-2b must be met in order to enable two applications 782 on the internal side of the NAT both to use the same port to 783 try to communicate with the same destination. 784 REQ-3c: This requirement is because some applications may not 785 be able to use ports in the well-known range because of 786 priviledge restrictions. 788 REQ-4: This will respect the RTP/RTCP parity convention when 789 possible, but without running out of ports unnecessarily. 791 REQ-5: This requirement is to ensure that the timeout is long 792 enough to avoid too frequent timer refresh packets. 794 REQ-5a: Configuration is desirable for adapting to specific 795 networks and troubleshooting. 796 REQ-5b: This default is to avoid too frequent timer refresh 797 packets. 799 REQ-6: Outbound refresh is necessary for allowing the client to 800 keep the binding alive. 802 REQ-6a: Inbound refresh may be useful for applications where 803 there is no outgoing UDP traffic. 804 REQ-6b: Using the refresh on a per binding basis avoids the 805 need for separate keep alives for all the available sessions. 807 REQ-7: Filtering based on the IP address is felt to have the 808 maximum balance between security and usefulness. See below. 810 REQ-7a: Filtering independently of the external IP address and 811 port is not as secure: an unauthorized packet could get at a 812 specific port while the port was kept open if it was lucky 813 enough to find the port open. 814 REQ-7b: In theory, filtering based on both IP address and port 815 is more secure than filtering based only on the IP address 816 (because the external endpoint could in reality be two 817 endpoints behind another NAT, where one of the two endpoints is 818 an attacker). However, such a restrictive policy could 819 interfere with certain applications that use more than one 820 port. 822 REQ-8: This is to avoid overly complex applications. 824 REQ-9: This requirement is to allow communications between two 825 endpoints behind the same NAT when they are trying each other's 826 external IP addresses. 828 REQ-9a: Using the external IP address is necessary for 829 applications with a restrictive policy of not accepting packets 830 from IP addresses that differ from what is expected. 832 REQ-10: NAT ALGs may interfere with UNSAF methods. 834 REQ-10a: A SIP NAT ALG will interfere with UNSAF methods. 836 REQ-11: Non-deterministic NATs are very difficult to troubleshoot 837 because they require more intensive testing. This 838 non-deterministic behavior is the root cause of much of the 839 uncertainty that NATs introduce about whether or not applications 840 will work. 842 REQ-12: This is easy to do, is used for many things including MTU 843 discovery and rapid detection of error conditions, and has no 844 negative consequences. 846 REQ-13 and REQ-13: Fragmented packets become more common with 847 large video packets and should continue to work. Applications can 848 use MTU discovery to work around this. 850 12. Security Considerations 852 NATs are often deployed to achieve security goals. Most of the 853 recommendations and requirements in this document do not affect the 854 security properties of these devices, but a few of them do have 855 security implications and are discussed in this section. 857 This work recommends that the timers for binding be refreshed only on 858 outgoing packets and does not make recommendations about whether or 859 not inbound packets should update the timers. If inbound packets 860 update the timers, an external attacker can keep the binding alive 861 forever and attack future devices that may end up with the same 862 internal address. A device that was also the DHCP server for the 863 private address space could mitigate this by cleaning any bindings 864 when a DHCP lease expired. For unicast UDP traffic (the scope of 865 this document), it may not seem relevant to support inbound timer 866 refresh; however, for multicast UDP, the question is harder. It is 867 expected that future documents discussing NAT behavior with multicast 868 traffic will refine the requirements around handling of the inbound 869 refresh timer. Some devices today do update the timers on inbound 870 packets. 872 This work recommends that the NAT filters be specific to the external 873 IP only and not the external IP and port. It can be argued that this 874 is less secure than using the IP and port. Devices that wish to 875 filter on IP and port do still comply with these requirements. 877 Non-deterministic NATs are risky from a security point of view. They 878 are very difficult to test because they are, well, non-deterministic. 879 Testing by a person configuring one may result in the person thinking 880 it is behaving as desired, yet under different conditions, which an 881 attacker can create, the NAT may behave differently. These 882 requirements recommend that devices be deterministic. 884 The work requires that NATs have an "external NAT binding is endpoint 885 independent" behavior. This does not reduce the security of devices. 886 Which packets are allowed to flow across the device is determined by 887 the external filtering behavior, which is independent of the binding 888 behavior. 890 When a fragmented packet is received from the external side and the 891 packets are out of order so that the initial fragment does not arrive 892 first, many systems simply discard the out of order packets. 893 Moreover, since some networks deliver small packets ahead of large 894 ones, there can be many out of order fragments. NATs that are 895 capable of delivering these out of order packets are possible but 896 they need to store the out of order fragments, which can open up a 897 DoS opportunity. Fragmentation has been a tool used in many attacks, 898 some involving passing fragmented packets through NATs and others 899 involving DoS attacks based on the state needed to reassemble the 900 fragments. NAT implementers should be aware of RFC 3128 [16] and RFC 901 1858 [15]. 903 13. IANA Considerations 905 There are no IANA considerations. 907 14. IAB Considerations 909 The IAB has studied the problem of "Unilateral Self Address Fixing", 910 which is the general process by which a client attempts to determine 911 its address in another realm on the other side of a NAT through a 912 collaborative protocol reflection mechanism [2]. 914 This specification does not in itself constitute an UNSAF 915 application. It consists of a series of requirements for NATs aimed 916 at minimizing the negative impact that those devices have on 917 peer-to-peer media applications, especially when those applications 918 are using UNSAF methods. 920 Section 3 of UNSAF lists several practical issues with solutions to 921 NAT problems. This document makes recommendations to reduce the 922 uncertainty and problems introduced by these practical issues with 923 NATs. In addition, UNSAF lists five architectural considerations. 924 Although this is not an UNSAF proposal, it is interesting to consider 925 the impact of this work on these architectural considerations. 927 Arch-1: The scope of this is limited to UDP packets in NATs like the 928 ones widely deployed today. The "fix" helps constrain the 929 variability of NATs for true UNSAF solutions such as STUN. 930 Arch-2: This will exit at the same rate that NATs exit. It does not 931 imply any protocol machinery that would continue to live after 932 NATs were gone or make it more difficult to remove them. 934 Arch-3: This does not reduce the overall brittleness of NATs but will 935 hopefully reduce some of the more outrageous NAT behaviors and 936 make it easer to discuss and predict NAT behavior in given 937 situations. 938 Arch-4: This work and the results [13] of various NATs represent the 939 most comprehensive work at IETF on what the real issues are with 940 NATs for applications like VoIP. This work and STUN have pointed 941 out more than anything else the brittleness NATs introduce and the 942 difficulty of addressing these issues. 943 Arch-5: This work and the test results [13] provide a reference model 944 for what any UNSAF proposal might encounter in deployed NATs. 946 15. Acknowledgments 948 Dan Wing contributed substantial text on IP fragmentation. 950 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 951 Dan Kegel for the NATP2P [10] draft, from which a lot of the material 952 in this specification is derived. Thanks to Rohan Mahy, Jonathan 953 Rosenberg, Mary Barnes, Dan Wing, Melinda Shore, Lyndsay Campbell, 954 Geoff Huston, Jiri Kuthan, Harald Welte and Spencer Dawkins for their 955 important contributions. 957 16. References 959 16.1 Normative References 961 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 962 Levels", BCP 14, RFC 2119, March 1997. 964 [2] Daigle, L. and IAB, "IAB Considerations for UNilateral 965 Self-Address Fixing (UNSAF) Across Network Address Translation", 966 RFC 3424, November 2002. 968 16.2 Informational References 970 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 971 (NAT) Terminology and Considerations", RFC 2663, August 1999. 973 [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 974 Translator (Traditional NAT)", RFC 3022, January 2001. 976 [5] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 977 IP Network Address Translator", RFC 3027, January 2001. 979 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 980 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 981 Session Initiation Protocol", RFC 3261, June 2002. 983 [7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 984 Simple Traversal of User Datagram Protocol (UDP) Through 985 Network Address Translators (NATs)", RFC 3489, March 2003. 987 [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 988 "RTP: A Transport Protocol for Real-Time Applications", RFC 989 3550, July 2003. 991 [9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 992 Methodology for Network Address Translator (NAT) Traversal for 993 the Session Initiation Protocol (SIP)", 994 draft-ietf-mmusic-ice-02 (work in progress), July 2004. 996 [10] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P) 997 communication across Network Address Translators(NATs)", 998 draft-ford-midcom-p2p-03 (work in progress), June 2004. 1000 [11] "Packet-based Multimedia Communications Systems", ITU-T 1001 Recommendation H.323, July 2003. 1003 [12] Ford, B. and D. Andersen, "Nat Check Web Site: 1004 http://midcom-p2p.sourceforge.net", June 2004. 1006 [13] Jennings, C., "NAT Classification Results using STUN", 1007 draft-jennings-midcom-stun-results-01 (work in progress), July 1008 2004. 1010 [14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1011 November 1990. 1013 [15] Ziemba, G., Reed, D. and P. Traina, "Security Considerations 1014 for IP Fragment Filtering", RFC 1858, October 1995. 1016 [16] Miller, I., "Protection Against a Variant of the Tiny Fragment 1017 Attack (RFC 1858)", RFC 3128, June 2001. 1019 [17] Reynolds, J. and J. Postel, "Assigned numbers", RFC 923, 1020 October 1984. 1022 [18] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1023 792, September 1981. 1025 [19] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1026 June 1995. 1028 Authors' Addresses 1030 Francois Audet 1031 Nortel Networks 1032 4655 Great America Parkway 1033 Santa Clara, CA 95054 1034 USA 1036 Phone: +1-408-495-3756 1037 EMail: audet@nortelnetworks.com 1039 Cullen Jennings 1040 Cisco Systems 1041 170 West Tasman Drive 1042 MS: SJC-21/2 1043 San Jose, CA 95134 1044 USA 1046 Phone: +1-408-902-3341 1047 EMail: fluffy@cisco.com 1049 Intellectual Property Statement 1051 The IETF takes no position regarding the validity or scope of any 1052 Intellectual Property Rights or other rights that might be claimed to 1053 pertain to the implementation or use of the technology described in 1054 this document or the extent to which any license under such rights 1055 might or might not be available; nor does it represent that it has 1056 made any independent effort to identify any such rights. Information 1057 on the procedures with respect to rights in RFC documents can be 1058 found in BCP 78 and BCP 79. 1060 Copies of IPR disclosures made to the IETF Secretariat and any 1061 assurances of licenses to be made available, or the result of an 1062 attempt made to obtain a general license or permission for the use of 1063 such proprietary rights by implementers or users of this 1064 specification can be obtained from the IETF on-line IPR repository at 1065 http://www.ietf.org/ipr. 1067 The IETF invites any interested party to bring to its attention any 1068 copyrights, patents or patent applications, or other proprietary 1069 rights that may cover technology that may be required to implement 1070 this standard. Please address the information to the IETF at 1071 ietf-ipr@ietf.org. 1073 Disclaimer of Validity 1075 This document and the information contained herein are provided on an 1076 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1077 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1078 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1079 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1080 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1081 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1083 Copyright Statement 1085 Copyright (C) The Internet Society (2004). This document is subject 1086 to the rights, licenses and restrictions contained in BCP 78, and 1087 except as set forth therein, the authors retain all their rights. 1089 Acknowledgment 1091 Funding for the RFC Editor function is currently provided by the 1092 Internet Society.