idnits 2.17.1 draft-ford-behave-app-05.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1175. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1146. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1153. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1159. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 21 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 5, 2007) is 6255 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-03 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-00 == Outdated reference: A later version (-07) exists of draft-ford-behave-top-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-09 == Outdated reference: A later version (-06) exists of draft-ietf-behave-p2p-state-02 -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intended Status: Best Current Practice 3 BEHAVE WG B. Ford 4 Internet-Draft M.I.T. 5 Expires: September 5, 2007 P. Srisuresh 6 Kazeon Systems 7 D. Kegel 8 kegel.com 9 March 5, 2007 11 Application Design Guidelines for Traversal 12 through Network Address Translators 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document defines guidelines by which application designers 41 can create applications that communicate reliably and efficiently 42 in the presence of Network Address Translators (NATs), 43 particularly when the application has a need for "peer-to-peer" 44 (P2P) type of communication. The guidelines allow a P2P application 45 to work reliably across a majority of existing NATs, as well as all 46 future NATs that conform to the behave requirements specified in 47 companion documents. The NAT traversal techniques described in 48 the document do not require the use of special proxy or relay 49 protocols, do not require specific knowledge about the network 50 topology or the number and type of NATs in the path, and do not 51 require any modifications to IP or transport-layer protocols 52 on the end hosts. 54 Table of Contents 56 1. Introduction and Scope........................................ 57 2. Terminology and Conventions Used ............................. 58 3. BEHAVE-compliant versus Legacy NATs .......................... 59 4. General NAT Traversal Concepts ............................... 60 4.1. NAT Functions Influencing Traversal Logic ............... 61 4.2. Communication Between Peers Behind Distinct NATs ........ 62 4.3. Short-Circuiting Sessions on Private Networks ........... 63 4.4. Authenticating Peer-to-Peer Connections ................. 64 4.5. NAT Behavior Detection .................................. 65 5. NAT Traversal for UDP ........................................ 66 5.1. UDP Idle Timeouts ....................................... 67 6. NAT Traversal for TCP ........................................ 68 6.1. Ensuring Robustness ..................................... 69 7. Summary of Requirements ...................................... 70 8. Security Considerations ...................................... 71 8.1. Denial-of-service attacks ............................... 72 8.2. Man-in-the-middle attacks ............................... 73 9. IANA Considerations .......................................... 74 10. Normative references ......................................... 75 11. Informative references ...................................... 77 1. Introduction and Scope 79 The present-day Internet has seen ubiquitous deployment of Network 80 Address Translators (NATs), driven by a variety of practical 81 challenges such as privacy and the ongoing depletion of the IPv4 82 address space. The asymmetric addressing and connectivity regimes 83 established by NATs, however, cause problems for many applications 84 such as teleconferencing ([SIP], [H.323]) and multiplayer on-line 85 gaming systems. Such application protocols require "peer-to-peer" 86 communication directly between arbitrary hosts, and not just 87 traditional "client/server" communication between a "client" host 88 and a "well-known" server with a global IP address and DNS name. 89 RFC 3235 [NAT-APPL] already proposes NAT friendly design guidelines 90 for applications, but merely recommends against using peer-to-peer 91 communication and does not provide a workable solution to this 92 problem. This document acts as an adjunct to [NAT-APPL], with 93 focus on Peer-to-peer application design guidelines. The guidelines 94 in the document apply to Traditional NATs as described in RFC 2663 95 [NAT-TERM]. As such, the term NAT used throughput the document 96 refers to Traditional NAT. 98 Given the increasing demand for applications that require P2P 99 communication, in conjunction with the ubiquity of NATs, applications 100 are increasingly implementing and deploying various workarounds to 101 this problem. Most of the workarounds take the form of a NAT 102 traversal or "hole punching" algorithm, by which two "peers" lying 103 behind one or more NATs cooperate with a well-known "rendezvous 104 server" to set up a direct peer-to-peer communication path between 105 them. As pointed out in [UNSAF], application endpoints are fixed 106 uniquely in the public realm with the aid of the rendezvous server. 107 The rendezvous server is crucial to the initial path setup but 108 does not take part in the subsequent peer-to-peer data stream. 110 There are many different NAT traversal algorithms already in use and 111 currently being explored. However, due to the lack of standardization 112 for NAT behavior up to this point, none of these algorithms can be 113 guaranteed to work reliably over all currently deployed NATs. 114 Further, without standardization of NAT traversal algorithms there 115 is a strong danger that the proliferation of traversal algorithms 116 may further compound the reliability and predictability problems 117 that NAT created in the first place. 119 This document focuses exclusively on NAT traversal techniques that do 120 not require the application to communicate explicitly with the NATs 121 in the path. Protocols that allow applications to obtain external 122 communication endpoints through explicit interaction with NATs in the 123 path are outside the scope of this document. Several such protocols 124 exist and are documented elsewhere ([SOCKS], [RSIP], [MIDCOM], 125 [UPNP]), but so far none of these protocols have become widely 126 accepted. 128 This document defines a set of best current practices for 129 implementing NAT traversal in applications. The specific 130 recommendations are described at length in the sections 2 through 131 5 and later summarized concisely in Section 6. 133 2. Terminology and Conventions Used 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 In this document, the IP addresses 192.0.2.1, 192.0.2.128, and 140 192.0.2.254 are used as example IP addresses [RFC3330]. Although 141 these addresses are all from the same /24 network, this is a 142 limitation of the example addresses available in [RFC3330]. In 143 practice, these addresses would be on different networks 145 3. BEHAVE-compliant versus Legacy NATs 147 BEHAVE-compliant NATs are those NAT devices that conform to the 148 behavioral requirements set out in [BEH-TCP], [BEH-UDP], 149 [BEH-ICMP], and other protocol specific behave document(s) in the 150 future which define requirements for NATs when handling protocol 151 specific traffic. 153 The NAT traversal techniques described in this document are known 154 to work in practice with a variety of existing NATs in the most 155 common interconnection scenarios. 157 To be considered "BEHAVE-compliant", an application MUST be 158 designed to operate reliably when all NATs in its communication 159 paths are BEHAVE-compliant. It is also RECOMMENDED that new 160 applications assume that all NATs in the application path are 161 BEHAVE-compliant, since non-BEHAVE-compliant NATs are expected to 162 be deprecated quickly. Adding complexity to applications for the 163 purpose of handling legacy NATs risks introducing additional 164 unpredictability into the network. 166 This document does not specifically prohibit applications from 167 implementing more elaborate NAT traversal algorithms that may 168 function over a wider variety of non-BEHAVE-compliant, "legacy" 169 NATs. Some known techniques for operating over such poorly-behaved 170 NATs are outlined briefly in [P2P-STATE], and are described more 171 thoroughly in [NUTSS], [P2PNAT], [NATBLAST], and [NATTRAV]. 172 Applications implementing fancier protocols such as these, however, 173 must ensure that their traversal algorithms operate just as 174 efficiently as the ones specified here over BEHAVE-compliant NATs, 175 and do not create new security vulnerabilities or unnecessarily 176 burden network components in the path. 178 REQ-1 Applications MUST be designed to operate reliably over BEHAVE- 179 compliant NATs. New applications are RECOMMENDED to assume 180 that all NATs in the path are BEHAVE-compliant. 182 4. General NAT Traversal Concepts 184 This section describes requirements and techniques for NAT traversal 185 that are independent of transport protocol; subsequent sections will 186 specifically address NAT traversal for the UDP and TCP transport 187 protocols. For more detailed background information on current 188 practices in use by existing applications, please refer to the 189 companion document [P2P-STATE]. 191 4.1. NAT Functions Influencing Traversal Logic 193 Traditional NATs ([NAT-TRAD]) are the most commonly deployed NATs. 194 These NATs integrate two logical functions, each of which interferes 195 with peer-to-peer communication in a different way and thus requires 196 NAT traversal support in applications. 198 Address Translation: 200 A NAT modifies the IP-level and often the transport-level header 201 information in packets flowing across the boundary, in order to 202 enable many "private" hosts behind the NAT to share the use of a 203 smaller number of public IP addresses (often just one). Hosts 204 behind the NAT usually have no unique, permanently usable address 205 on the public Internet, and can only communicate through 206 temporary public endpoints that the NAT assigns them dynamically 207 as a result of communication attempts initiated by hosts on the 208 private network. 210 When two hosts reside on two different private networks behind 211 distinct NATs, neither of them has a permanent address that the 212 other can reach at any time, so in order to establish peer-to-peer 213 connections the hosts must rely on the temporary public endpoints 214 their NATs assign them as a result of prior outgoing 215 client/server style communication sessions. Discovering, 216 exchanging, and using these temporary public endpoints generally 217 requires that the two hosts first collaborate through a well-known 218 server on the public Internet that both hosts can reach, as 219 described below. 221 Filtering of Unsolicited Traffic: 223 The filtering function in a Traditional NAT device restricts 224 communication between a private internal network and the public 225 Internet by dropping incoming sessions that are deemed 226 "unsolicited". All packets arriving from the public Internet 227 are dropped unless they are part of an existing communication 228 session that was previously initiated by a host on the private 229 network. 231 When two hosts reside on two different private networks behind 232 distinct NATs, an attempt by either host to initiate a peer-to- 233 peer connection to the other will usually fail, even if the 234 connection attempt is directed to the correct temporary public 235 endpoint assigned by the opposite host's NAT, because the opposite 236 host's NATs will interpret this attempt as unsolicited incoming 237 traffic and reject it. NAT traversal in this case requires the 238 two hosts to cooperate, typically by communicating initially 239 through a well-known server on the public Internet that they can 240 both reach, so as to make their peer-to-peer connection appear to 241 each host's NAT as if it was initiated from within that host's own 242 private network. 244 The cooperation of two hosts to create a peer-to-peer connection 245 across NATs does not constitute a violation of the filtering policy 246 imposed by the NAT. Network firewall functionality in general is 247 outside the scope of this document, and this document does not 248 condone any attempts by application developers to subvert security 249 policies that may be imposed by NATs or firewalls. 251 4.2. Communication Between Peers Behind Distinct NATs 253 Although the details of NAT traversal vary from one transport 254 protocol to another depending on how NATs recognize and handle 255 sessions for that transport, the basic approach to NAT traversal is 256 transport-independent. We merely assume for now that each transport 257 uses session endpoints consisting of an (IP address, port number) 258 pair to identify and differentiate communication sessions, and that 259 each communication session is uniquely identified by its two 260 endpoints. We focus here specifically on the one NAT traversal 261 algorithm recommended here for new applications. 263 Suppose client hosts A and B both have private IP addresses and lie 264 behind different NATs, as shown below. 266 Server S 267 192.0.2.128:1234 268 | 269 +----------------------------+----------------------------+ 270 | | 271 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 272 | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | 273 | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | 274 | | 275 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 276 | | 192.0.2.254:31000 | | 192.0.2.1:62000 | | 277 | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | 278 | | 279 +------------------+ +------------------+ 280 | 192.0.2.1 | | 192.0.2.254 | 281 | | | | 282 | BEHAVE-compliant | | BEHAVE-compliant | 283 | NAT A | | NAT B | 284 +------------------+ +------------------+ 285 | | 286 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 287 | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | 288 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 289 | | 290 | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | 291 | | 192.0.2.254:31000 | | 192.0.2.1:62000 | | 292 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 293 | | 294 Client A Client B 295 10.0.0.1:1234 10.1.1.3:1234 297 Figure 1: Simultaneous outgoing sessions to accomplish direct-P2P 299 A peer-to-peer application running on clients A and B, and also on a 300 well-known rendezvous server S, each use port number 1234 at their 301 own IP address to form their primary local communication endpoint. A 302 and B have each initiated communication sessions from their local 303 endpoint server S's endpoint. As a result of A's outgoing connection 304 attempt to S, NAT A has dynamically assigned port 62000 at its own 305 public IP address, 192.0.2.1, to A's session with S, so that S 306 sees this session as having been initiated from the endpoint 307 192.0.2.1:62000, rather than from A's original private endpoint of 308 10.0.0.1:1234. Similarly, B's outgoing connection to S causes NAT B 309 to assign port 31000 at its own IP address to B's session with S, 310 thus forming B's public endpoint of 192.0.2.254:31000. 312 Now suppose that host A wants to establish a communication session 313 directly with host B. If A just naively initiates a new 314 communication session to the endpoint B believes itself to be using, 315 namely 10.1.1.3:1234, then A's connection attempt will either reach 316 the wrong host - a different host on A's own private network that 317 happens to have the private IP address 10.1.1.3 - or it will reach no 318 host at all, because B's private IP address 10.1.1.3 is not routable 319 over the Internet. 321 Even if A learns B's temporary public endpoint, 192.0.2.254:31000, 322 from server S, and attempts to initiate a communication session to 323 that destination endpoint, NAT B may reject this attempt because 324 the IP packet's source and destination endpoints do not match 325 those of an existing session previously initiated from within the 326 private network. The destination endpoint of A's connection attempt 327 to B matches the source endpoint of B's existing session with S, 328 but the source endpoint of A's connection attempt is of course 329 different. Similarly, if B makes a unilateral connection attempt 330 to A's public endpoint, NAT A may similarly reject B's attempt. 332 As it turns out, this difficulty could arise even if NAT-A and 333 NAT-B are replaced by firewalls with the standard filtering 334 policy of rejecting unsolicited incoming communication attempts. 336 In order to operate reliably across NATs and firewalls that reject 337 unsolicited incoming communication, the client hosts A and B 338 collaborate with an external server S to learn each other's public 339 AND private endpoints, and then each of the two client hosts 340 initiate "approximately simultaneous" connection attempts from their 341 existing primary local endpoints (the same local endpoints they used 342 previously for the connection to S), and directed at all of the known 343 endpoints (public and private) for the other host. In the scenario 344 illustrated above, A's connection attempt to B's public endpoint is 345 interpreted by NAT A as a legitimate, outgoing session whose private 346 source endpoint (10.0.0.1:1234) is the same as that of A's existing 347 session with S, but whose public destination endpoint 348 (192.0.2.254:31000) is different. If NAT A is BEHAVE-compliant, it 349 will translate A's private source endpoint for this new session in 350 the same way that it did for A's existing session with S, so that the 351 new session appears on the public Internet to be a session between 352 A's public endpoint, 192.0.2.1:62000, and B's public endpoint, 353 192.0.2.254:31000. 355 In similar fashion, B's "approximately simultaneous" connection 356 attempt from its private endpoint, 10.1.1.3:1234, to A's public 357 endpoint, 192.0.2.1:62000, results in NAT B opening a new 358 translation session that reuses the existing public endpoint for B, 359 192.0.2.254:31000, which NAT B previously assigned to B's session 360 with S. NAT B is now set up to allow communication between A's 361 public endpoint and B's private endpoint, and on the public Internet 362 this session has the endpoints 192.0.2.1:62000 and 363 192.0.2.254:31000, the same as the endpoints of the session that A 364 initiated above toward B's public endpoint. Both NATs are thus set 365 up to permit communication between these two public endpoints, 366 translating and forwarding the traffic comprising this session to the 367 respective client hosts on the private networks as appropriate. 369 Applications wishing to establish peer-to-peer communication MUST 370 support NAT traversal using the "approximate simultaneous" 371 connection technique. The traversal technique relies on certain 372 aspects of NAT behavior described fully in the companion documents 373 [BEH-TCP], [BEH-UDP], and [BEH-ICMP]. The technique also relies on 374 the transport protocol allowing a connection to be initiated 375 actively by two endpoints, rather than asymmetrically in traditional 376 client/server fashion. Fortunately both of the two ubiquitous 377 transports, TCP and UDP, allow symmetric connection initiation in 378 this way. 380 REQ-2 Applications wishing to establish peer-to-peer communication 381 MUST support NAT traversal using the "approximate 382 simultaneous" connection technique and using the help of a 383 "rendezvous server" in the public network. 385 4.3. Short-Circuiting Sessions on Private Networks 387 Although the network topology illustrated in figure 1 is typical 388 of the situation seen by P2P applications, it is by no means 389 the only possible scenario. Only one of the client hosts may be 390 behind, or one or more of the clients may be located behind two or 391 more levels of NATs, any number of which may be shared between the 392 two clients. The general NAT traversal algorithm described above 393 will work reliably in all of the common topological scenarios 394 provided that the NATs involved are BEHAVE-compliant. One other 395 particularly common scenario is worth special consideration however. 396 In the situation illustrated below the two clients (probably 397 unknowingly) happen to reside behind the same NAT, and are therefore 398 located in the same private IP address space. 400 Server S 401 192.0.2.128:1234 402 | 403 ^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^ 404 | 192.0.2.128:1234 | | | 192.0.2.128:1234 | 405 | 192.0.2.1:62000 | | | 192.0.2.1:62001 | 406 | 407 +------------------+ 408 | 192.0.2.1 | 409 | | 410 | Behave-Compliant | 411 | NAT | 412 +------------------+ 413 | 414 +-----------------------------+----------------------------+ 415 | | 416 | ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ | 417 | | 192.0.2.128:1234 | | 192.0.2.128:1234 | | 418 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 419 | | 420 | ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1 (B-A)^ | 421 | | 10.1.1.3:1234 | | 10.0.0.1:1234 | | 422 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 423 | | 424 | ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A)^ | 425 | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | 426 | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | 427 | | 428 Client A Client B 429 10.0.0.1:1234 10.1.1.3:1234 431 Figure 2: Register private identity & NAT identity with Relay server 433 In this scenario, client A has established a session with well-known 434 server S as before, to which the common NAT has assigned public port 435 number 62000. Client B has similarly established a session with S, 436 to which the NAT has assigned public port number 62001. Suppose that 437 A and B use the NAT traversal technique outlined above to establish a 438 communication channel using server S as an introducer. If A and B 439 only attempt simultaneous connections to each other's public 440 endpoints, 192.0.2.1:62001 and 192.0.2.1:62000 respectively, 441 then their connection attempts will succeed only if the NAT supports 442 hairpin translation, as described in [P2P-STATE] and [BEH-TOP]. 443 Although hairpin translation is required for a NAT to be 444 considered fully BEHAVE-compliant, this feature is not yet widely 445 supported by commonly deployed NATs at the time of this writing. 447 Additionally, the resulting connection between A and B will be 448 sub-optimal in this case because all traffic will unnecessarily 449 pass through and be translated by the NAT, whereas the two 450 endpoint hosts are perfectly capable of communicating directly on 451 their common IP network without the NAT intervention. 453 To address this problem, P2P applications MUST exchange their local 454 endpoints as known to themselves, in addition to the global 455 endpoints they register with the rendezvous server. In case an 456 application host has multiple IP addresses or is registered with 457 multiple rendezvous servers, the P2P application SHOULD exchange 458 all pertinent endpoints with its peers. 460 Further, P2P applications MUST be prepared to make "approximately 461 simultaneous" connection attempts to all exchanged endpoints, 462 including the private endpoints and the public endpoints of the 463 desired peer. By doing this, a P2P application is able to use 464 whichever connection succeeds first in establishing bi-directional 465 communication between the correct peers. If the two end hosts 466 happen to be located in the same private network, their connection 467 attempt using each others' private endpoints is likely to succeed 468 first because it follows a shorter network path not involving the 469 NAT. If the NAT does not support hairpin translation, the 470 connection attempts using the hosts' private endpoints will be the 471 only one to succeed. 473 REQ-3 Applications implementing NAT traversal MUST exchange their 474 local endpoints as known to themselves, in addition to the 475 global endpoints they register with the rendezvous server. 476 In case an application host has multiple IP addresses or 477 is registered with multiple rendezvous servers, the P2P 478 application SHOULD exchange all pertinent endpoints with 479 its peers. Further, peering applications MUST be prepared to 480 make "approximately simultaneous" connection attempts to all 481 exchanged endpoints of the desired peer. 483 4.4. Authenticating Peer-to-Peer Connections 485 It is extremely important not only for security but also for general 486 robustness that applications implementing a NAT traversal protocol 487 authenticate any peer-to-peer connections they establish, using some 488 higher-level application-specific notion of host or user identity. 489 To operate reliably and securely, applications must consider any IP 490 addresses and port numbers they use for communication with other 491 hosts to be merely "locators" for hosts, serving as hints indicating 492 how the desired host might be reached, and not as a reliable 493 "identifier" for the target host or user. 495 In particular, applications must not merely assume that the first 496 communication attempt that establishes transport-level connectivity 497 and elicits a response from a particular target endpoint (IP address 498 and port number) necessarily represents a connection to the desired 499 host. Consider the following topological scenario, for example, 500 which is in fact extremely common in today's Internet. 502 Server S 503 192.0.2.128:1234 504 | 505 +----------------------------+----------------------------+ 506 | | 507 | | 508 +------------------+ +------------------+ 509 | 192.0.2.1 | | 192.0.2.254 | 510 | | | | 511 | BEHAVE-compliant | | BEHAVE-compliant | 512 | NAT A | | NAT B | 513 +------------------+ +------------------+ 514 | | 515 -------+----+-----------+ | 516 | | | 517 Client X Client A Client B 518 10.1.1.10:1234 10.0.0.11:1234 10.1.1.10:1234 520 Figure 3: Clients behind different NATs can bear same local endpoint 522 In this scenario, suppose that NAT A and NAT B are both "off-the- 523 shelf" consumer NAT routers from the same vendor, which the vendor 524 has configured by default to act as DHCP servers that hand out 525 private IP addresses starting at 10.1.1.10. (Most users of such 526 devices know little or nothing about IP addresses, and therefore are 527 very unlikely to reconfigure their NATs any more than is necessary to 528 get them to connect to the Internet.) As before, Client A wishes to 529 establish a peer-to-peer connection with Client B with the help of 530 Server S. Client A happened to receive private IP address 10.1.1.11 531 on NAT A's private network, after Client X had already been assigned 532 private IP address 10.1.1.10. Client B happens to be the only host 533 on NAT B's private network, and thus received the first available 534 private IP address, 10.1.1.10. Client X happens to be running the 535 same P2P application as is running on clients A and B, and thus has 536 port 1234 allocated and ready to initiate and accept peer-to-peer 537 connections. 539 Suppose Client A follows the NAT traversal approach described above 540 to establish a peer-to-peer session with Client B. As per the 541 suggested protocol, A and B each make approximately simultaneous 542 connection attempts both to each other's public and private 543 endpoints. B's connection attempt to A's private endpoint, 544 10.1.1.11:1234, will of course fail because there is no host 545 10.1.1.11 on NAT B's private network and that IP address is not 546 globally routable. A's connection attempt to B's public endpoint and 547 B's connection attempt to A's public endpoint will eventually succeed 548 in establishing the desired peer-to-peer connection if the two NATs 549 are BEHAVE-compliant. However, A's connection attempt to B's private 550 endpoint, 10.1.1.10:1234, will succeed at the transport layer but 551 connect to the wrong host: namely client X, the host on NAT A's 552 private network that happens to have the same private IP address as B 553 does on NAT B's network. Furthermore, this bogus connection to 554 client X is likely to succeed much more quickly than the actually 555 desired connection to client B, because X is on the same private 556 network as A. If the application running on client A does not 557 properly authenticate its peer-to-peer connections using some higher- 558 level notion of identity that is independent of IP address, then 559 client A is likely to assume that its transport-level connection to X 560 is the desired peer-to-peer connection, cancel its attempt to connect 561 to B's public endpoint, and subsequently become very confused when 562 the peer it connected to fails to behave like client B. 564 Given the prevalence of NAT routers that are pre-configured by their 565 vendors to hand out private IP addresses via DHCP in more-or-less 566 deterministic fashion from a standard private IP address block, 567 different hosts on different private networks are very likely to have 568 the same private IP addresses, making the above scenario extremely 569 likely for P2P applications to encounter. P2P applications therefore 570 MUST authenticate their transport-layer connections using a 571 higher level application-specific notion of identity, before 572 concluding they have successfully connected to the desired host. 573 Strong cryptographic authentication using standard algorithms is of 574 course preferred. 576 REQ-4 P2P applications MUST authenticate their transport-layer 577 connections using a higher level application-specific notion 578 of identity, before concluding they have successfully 579 connected to the desired host. 581 4.5. NAT Behavior Detection 583 In many existing NAT traversal protocols for both TCP and UDP, each 584 client attempts to determine experimentally certain properties of any 585 NATs it is located behind before attempting to establish peer-to-peer 586 connections with other clients. For example, even when a NAT does 587 not re-use the same public endpoint for all sessions involving a 588 given private endpoint as required for BEHAVE compliance, it is 589 sometimes possible to predict which port the NAT will assign to a 590 new session. 592 Extensive testing of various existing NATs, however, has revealed 593 that there is no truly robust way a client can predict how a legacy 594 NAT will behave in the future based on such experimental tests. Some 595 legacy NATs behave differently depending on the local port number the 596 application is using on the client, and can even switch behaviors 597 dynamically depending on unpredictable timing and network conditions. 598 Therefore, applications SHOULD NOT attempt to predict the future 599 behavior of NATs in the path through empirical tests. If they do use 600 such experimental tests in an attempt to make peer-to-peer 601 connections work across a wider variety of legacy NATs, they MUST 602 ensure that such methods do not delay or otherwise impede the 603 the performance or reliability of the application over 604 BEHAVE-compliant NATs. 606 REQ-5 Applications SHOULD NOT attempt to predict the future behavior 607 of NATs in the path through empirical tests. If they do, 608 applications MUST ensure that any such tests do not delay or 609 otherwise impede the performance or reliability of NAT 610 traversal over BEHAVE-compliant NATs. 612 5. NAT Traversal for UDP 614 NAT traversal for UDP, also commonly known as UDP "hole punching", 615 was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and 616 first publicly documented informally on the Internet [KEGEL]. 617 Because of UDP's simplicity and its connectionless nature, NAT 618 traversal for UDP is somewhat simpler, more widely understood, and 619 hence more universally supported by NATs and applications than is NAT 620 traversal for TCP, though the principles are the same for both 621 transports. NAT traversal for UDP has been used in several recent 622 experimental Internet protocols [TEREDO], [ICE] along with various 623 proprietary or non-standardized protocols. The NAT traversal 624 approach recommended in this document is also described informally in 625 [P2PNAT], and other variations of hole punching are explored more 626 thoroughly in other recent research papers [NUTSS], [NATBLAST], 627 and [NATTRAV]. 629 To set up a peer-to-peer UDP session between two clients A and B, we 630 assume that the clients have each bound to a particular primary local 631 UDP port, and that the clients have each initiated a UDP session from 632 this primary local port to a well-known rendezvous server S, as 633 described earlier. Each client then learns the other's public and 634 private UDP endpoints from the server S, and simply begins sending 635 UDP datagrams, from their respective primary local ports (the same 636 ports they used to contact S), to all of the other client's known 637 endpoints. If one or both of the clients is behind a BEHAVE- 638 compliant NAT, the outgoing datagrams from each client will "open a 639 hole" through a firewall or establish a translation session 640 through the NAT, causing the NAT to forward subsequent incoming 641 datagrams from the opposite client as desired. 643 5.1. UDP Idle Timeouts 645 Because of its inherently connectionless nature, NATs have no fully 646 reliable way to determine when a UDP communication session crossing 647 the NAT has terminated, other than simply by assuming the session is 648 over if it observes a sufficiently long idle period. Applications 649 whose UDP communication sessions may experience long idle periods 650 must therefore account for this idle timeout. 652 As specified in [BEH-UDP], any BEHAVE-compliant NAT is required to 653 have an idle timeout of at least two minutes, but idle timeouts as 654 small as 30 seconds have been observed in existing NATs. 655 Additionally, BEHAVE-compliant NATs are only required to reset the 656 idle timer on the observance of outgoing traffic leaving the private 657 network; the NAT may ignore incoming traffic for this purpose, in 658 order to prevent external hosts from being able to hold UDP sessions 659 open unilaterally and thus consume NAT resources indefinitely. 660 BEHAVE-compliant NATs are required to support Address and Port 661 Dependent filtering Behavior, which essentially resets the idle 662 timer for each session whenever outbound traffic is seen for that 663 session. A NAT's UDP idle timeouts affects P2P applications 664 implementing NAT traversal in two main ways: 666 Rendezvous Server Registration Sessions: 668 Client hosts implementing UDP hole punching typically register 669 with one or more well-known rendezvous servers, S in the above 670 scenarios, and expect to be notified by S when a second client 671 wishes to open a peer-to-peer connection to the first. However, 672 if a NAT's UDP idle timer times out while the first client is 673 waiting for incoming connections, then the client will not 674 receive the notification from S of the second client's desire 675 to connect. The client therefore SHOULD send periodic outbound 676 "keep-alive" packets to the rendezvous server(s) in order to 677 ensure that the registration session remains open while the 678 application is active. If a UDP application maintains active 679 registration sessions with more than one well-known rendezvous 680 server simultaneously, then the application SHOULD send outbound 681 keep-alive packets periodically to each of the rendezvous 682 servers it is registered with. The periodicity is at least once 683 within the BEHAVE-compliant NAT UDP timeout [BEH-UDP]. 685 If a UDP application merely desires to be compatible with BEHAVE- 686 compliant NATs, then its outbound keep-alive packets need not 687 elicit a response from the server unless the application is 688 concerned about detecting if the server disappears. 690 REQ-6 Applications wishing to accept connections from other peers 691 after registering via UDP with one or more rendezvous servers 692 SHOULD send periodic outgoing UDP "keep-alive" packets to 693 each of the rendezvous servers, at least once within the 694 BEHAVE-compliant NAT UDP timeout [BEH-UDP] in order to ensure 695 that the registration session remains open while the 696 application is active. 698 Peer-to-Peer Sessions: 700 Once two client hosts have used a rendezvous server to set up a 701 peer-to-peer UDP communication session between them, this peer-to- 702 peer session is similarly vulnerable to being closed by any of the 703 NATs along the path if it goes idle for too long. 705 If an application has only a few peer-to-peer sessions active at 706 once, then the application SHOULD use keep-alives for each of the 707 active peering sessions to keep the sessions open. If an 708 application has many idle peer-to-peer sessions at once, then 709 the application SHOUL NOT use keep-alives on peer-to-peer sessions 710 so the network is not flooded with keep-alives. Instead, the 711 application SHOULD be prepared to re-establish peer-to-peer 712 sessions as needed after an idle period, by simply re-running the 713 NAT traversal protocol via the original rendezvous server. 715 REQ-7 An Application SHOULD use the following guidelines with regard 716 to its UDP peer-to-peer sessions. 717 a) If the application has only a small number of peer-to-peer 718 sessions active at once, then send periodic outgoing UDP 719 "keep-alive" packets to each active peer at least once 720 within the BEHAVE-compliant NAT UDP timeout [BEH-UDP]. 721 b) If the application has many peer-to-peer sessions active 722 at once, then do not send periodic "keep-alive" packets to 723 peers so the network is not flooded with keep-alives. 724 c) If the application has a peer-to-peer UDP session that may 725 go idle for more than the BEHAVE-compliant NAT UDP timeout at 726 a time without a keep-alive, and the session connectivity is 727 detected to have been lost, then be prepared to re-run the 728 original NAT traversal protocol to re-establish the 729 peer-to-peer session. 731 6. NAT Traversal for TCP 733 NAT traversal for TCP, or "TCP hole punching," is not yet as well- 734 understood or widely supported as is UDP hole punching. 735 Nevertheless, the general technique described in section 2 above 736 works for TCP as well as UDP, as long as all NATs in the path are 737 well-behaved. The recommended NAT traversal algorithm for TCP, 738 described here, makes use of the symmetric TCP connection initiation 739 feature of TCP as specified in RFC 793 [TCP] and RFC 1122 [RFC1122]. 740 This algorithm is guaranteed to work reliably as long as all NATs in 741 the path are BEHAVE-compliant [BEH-TCP], and as long as the end-hosts 742 correctly implement the TCP protocol. 744 Other more complex TCP hole punching algorithms have been developed 745 and explored elsewhere in [NUTSS], [NATBLAST], and [NATTRAV]. 746 These algorithms use various tricks to work around the nonstandard 747 behaviors of many existing NATs, and/or to work around bugs in the 748 TCP implementations of certain existing operating systems. 749 Applications MAY implement more complex algorithms such as these 750 in order to achieve broader compatibility with existing NATs and 751 hosts, but applications MUST ensure that any such alternative 752 algorithm still works reliably and efficiently over 753 BEHAVE-compliant NATs without substantially burdening the network 754 and any NATs on the path. 756 To prepare for TCP NAT traversal, a P2P client application first 757 binds to an arbitrary local port, which becomes the application's 758 primary local port. The Application SHOULD use the port to 759 simultaneously listen for incoming peer-to-peer connections and to 760 initiate outgoing connections to rendezvous servers and other peers. 761 Because standard sockets APIs usually associate TCP sockets with 762 individual TCP sessions rather than with a local port as with UDP, 763 the application must typically open multiple TCP sockets - one 764 listen socket and one or more connect-sockets - and explicitly bind 765 them to the same local port, using a special socket option usually 766 named SO_REUSEADDR or SO_REUSEPORT. 768 Once a TCP application has bound to its primary local port, started 769 listening on it, and opened connections to one or more rendezvous 770 servers, the application SHOULD use "approximately simultaneous" 771 connection technique to initiate outgoing connections or to accept 772 incoming connections. Each peer SHOULD use the "approximate 773 simultaneous" connection technique to connect to all of the known 774 endpoints (including original and translated) of its peer. For 775 example, say two clients, A and B, wish to establish a peer-to-peer 776 connection with the help of a common rendezvous server S. They first 777 exchange their public and private TCP endpoints through S as 778 described in section 2. Each client then simultaneously attempts 779 to initiate outgoing TCP connections from its primary local port to 780 each of the opposite client's known TCP endpoints (public and 781 private). As long as all NATs in the path are well-behaved, each 782 client's outgoing TCP connection attempt will open firewall and/or 783 translation sessions through any NATs it is located behind, 784 eventually resulting in a working bi-directional TCP connection 785 through all intervening NATs on the path, in the same way as for UDP. 787 Because of timing dependencies and differences in TCP 788 implementations, applications may observe slightly different (but 789 functionally equivalent) results when a P2P connection is 790 successfully established using this method. If client B is not 791 actually located behind a firewall or NAT, for example, and client 792 A's first attempt to connect directly to B reaches B before its peer- 793 to-peer connection request relayed through S reaches B, then B will 794 accept A's connection via its outstanding listen socket, in 795 traditional client/server fashion. Even if A's connection request 796 (SYN packet) to B crosses B's corresponding request to A, resulting 797 in a TCP simultaneous open at the protocol level, some end-host 798 operating systems may still "deliver" the resulting connection to the 799 application via the application's outstanding listen socket for its 800 primary local port, rather than via the socket by which the 801 application explicitly initiated a connection to the opposite client. 802 The application must be prepared to handle all such possible cases 803 gracefully. 805 Applications MAY alternatively establish peer-to-peer TCP 806 connections via other, asymmetric methods if one or both endpoint 807 hosts do not correctly support simultaneous TCP open. 809 REQ-8 Applications implementing peer-to-peer communication via 810 TCP SHOULD simultaneously listen for incoming peer-to-peer 811 connections and open connections to rendezvous servers and 812 other peers from the same endpoint. 814 REQ-9 Applications SHOULD establish peer-to-peer TCP connections by 815 making "approximately simultaneous" connection attempts from 816 each peer to all of the known endpoints (including original 817 and translated) for its peer. 818 Applications MAY alternatively establish peer-to-peer TCP 819 connections via other, asymmetric methods if one or both 820 endpoint hosts do not correctly support simultaneous TCP open. 822 6.1. Ensuring Robustness 824 Some existing NATs actively reject an apparently-unsolicited incoming 825 TCP connection by sending back TCP RST or ICMP error packets to the 826 connection initiator, rather than simply dropping the incoming SYN. 827 This behavior can cause one of the clients to observe bogus 828 timing-dependent connection failures. While this NAT behavior is 829 deprecated and not allowed for BEHAVE-compliant NATs, P2P 830 applications can easily make themselves robust against this 831 behavior. If a client's attempt to initiate a peer-to-peer 832 connection fails with a "Connection Refused" or "Network Unreachable" 833 or similar network-related error before some application-defined 834 peer-to-peer connection timeout has expired, the application SHOULD 835 simply retry the same outgoing connection attempt. However, the 836 application MUST NOT retry more frequently than once per second. 837 Doing so avoids accidental flooding of the network with SYNs if 838 the cause of the error is close to the client and is thus reported 839 very quickly after each attempt. 841 REQ-10 Applications SHOULD re-try peer-to-peer TCP connection 842 attempts that fail due to network conditions other than 843 timeout, but MUST NOT re-try connecting to a given peer 844 more than once per second. 846 7. Summary of Requirements 848 An application that supports all of the mandatory requirements of 849 this specification (the "MUST" requirements), is "compliant with 850 this specification" or "BEHAVE-compliant". An application that 851 supports all of the mandatory and optional recommendations of this 852 specification (including the "SHOULD" or "RECOMMENDED" ones) is 853 "fully compliant with all the mandatory and recommended 854 requirements of this specification." 856 REQ-1 Applications MUST be designed to operate reliably over BEHAVE- 857 compliant NATs. New applications are RECOMMENDED to assume 858 that all NATs in the path are BEHAVE-compliant. 860 REQ-2 Applications wishing to establish peer-to-peer communication 861 MUST support NAT traversal using the "approximate 862 simultaneous" connection technique and using the help of a 863 "rendezvous server" in the public network. 865 REQ-3 Applications implementing NAT traversal MUST exchange their 866 local endpoints as known to themselves, in addition to the 867 global endpoints they register with the rendezvous server. 868 In case an application host has multiple IP addresses or 869 is registered with multiple rendezvous servers, the P2P 870 application SHOULD exchange all pertinent endpoints with 871 its peers. Further, peering applications MUST be prepared to 872 make "approximately simultaneous" connection attempts to all 873 exchanged endpoints of the desired peer. 875 REQ-4 P2P applications MUST authenticate their transport-layer 876 connections using a higher level application-specific notion 877 of identity, before concluding they have successfully 878 connected to the desired host. 880 REQ-5 Applications SHOULD NOT attempt to predict the future behavior 881 of NATs in the path through empirical tests. If they do, 882 applications MUST ensure that any such tests do not delay or 883 otherwise impede the performance or reliability of NAT 884 traversal over BEHAVE-compliant NATs. 886 REQ-6 Applications wishing to accept connections from other peers 887 after registering via UDP with one or more rendezvous servers 888 SHOULD send periodic outgoing UDP "keep-alive" packets to 889 each of the rendezvous servers, at least once within the 890 BEHAVE-compliant NAT UDP timeout [BEH-UDP] in order to ensure 891 that the registration session remains open while the 892 application is active. 894 REQ-7 An Application SHOULD use the following guidelines with regard 895 to its UDP peer-to-peer sessions. 896 a) If the application has only a small number of peer-to-peer 897 sessions active at once, then send periodic outgoing UDP 898 "keep-alive" packets to each active peer at least once 899 within the BEHAVE-compliant NAT UDP timeout [BEH-UDP]. 900 b) If the application has many peer-to-peer sessions active 901 at once, then do not send periodic "keep-alive" packets to 902 peers so the network is not flooded with keep-alives. 903 c) If the application has a peer-to-peer UDP session that may 904 go idle for more than the BEHAVE-compliant NAT UDP timeout at 905 a time without a keep-alive, and the session connectivity is 906 detected to have been lost, then be prepared to re-run the 907 original NAT traversal protocol to re-establish the 908 peer-to-peer session. 910 REQ-8 Applications implementing peer-to-peer communication via 911 TCP SHOULD simultaneously listen for incoming peer-to-peer 912 connections and open connections to rendezvous servers and 913 other peers from the same endpoint. 915 REQ-9 Applications SHOULD establish peer-to-peer TCP connections by 916 making "approximately simultaneous" connection attempts from 917 each peer to all of the known endpoints (including original 918 and translated) for its peer. 919 Applications MAY alternatively establish peer-to-peer TCP 920 connections via other, asymmetric methods if one or both 921 endpoint hosts do not correctly support simultaneous TCP open. 923 REQ-10 Applications SHOULD re-try peer-to-peer TCP connection 924 attempts that fail due to network conditions other than 925 timeout, but MUST NOT re-try connecting to a given peer more 926 than once per second. 928 8. Security Considerations 930 This document does not inherently create new security issues. 931 This section describes security risks the applications could 932 inadvertently create in attempting to support P2P communication 933 across NAT devices. 935 8.1. Denial-of-service attacks 937 P2P applications and the public registry servers that support them 938 must protect themselves against denial-of-service attacks, and 939 ensure that they cannot be used by an attacker to mount 940 denial-of-service attacks against other targets. To protect 941 themselves, P2P applications and registry servers must avoid taking 942 any action requiring significant local processing or storage 943 resources until authenticated two-way communication is established. 944 To avoid being used as a tool for denial-of-service attacks, P2P 945 applications and servers must minimize the amount and rate of 946 traffic they send to any newly-discovered IP address until after 947 authenticated two-way communication is established with the intended 948 target. 950 For example, P2P applications that register with a public rendezvous 951 server can claim to have any private IP address, or perhaps multiple 952 IP addresses. A well-connected host or group of hosts that can 953 collectively attract a substantial volume of P2P connection attempts 954 (e.g., by offering to serve popular content) could mount a 955 denial-of-service attack on a target host C simply by including C's 956 IP address in their own list of IP addresses they register with the 957 rendezvous server. There is no way the rendezvous server can verify 958 the IP addresses, since they could well be legitimate private 959 network addresses useful to other hosts for establishing 960 network-local communication. The P2P application protocol must 961 therefore be designed to size- and rate-limit traffic to unverified 962 IP addresses in order to avoid the potential damage such a 963 concentration effect could cause. 965 8.2. Man-in-the-middle attacks 967 Any network device on the path between a P2P client and a 968 rendezvous server can mount a variety of man-in-the-middle 969 attacks by pretending to be a NAT. For example, suppose 970 host A attempts to register with rendezvous server S, but a 971 network-snooping attacker is able to observe this registration 972 request. The attacker could then flood server S with requests 973 that are identical to the client's original request except with 974 a modified source IP address, such as the IP address of the 975 attacker itself. If the attacker can convince the server to 976 register the client using the attacker's IP address, then the 977 attacker can make itself an active component on the path of all 978 future traffic from the server AND other P2P hosts to the 979 original client, even if the attacker was originally only able 980 to snoop the path from the client to the server. 982 The client cannot protect itself from this attack by 983 authenticating its source IP address to the rendezvous server, 984 because in order to be NAT-friendly the application must allow 985 intervening NATs to change the source address silently. This 986 appears to be an inherent security weakness of the NAT paradigm. 987 The only defense against such an attack is for the client to 988 authenticate and potentially encrypt the actual content of its 989 communication using appropriate higher-level identities, so that 990 the interposed attacker is not able to take advantage of its 991 position. Even if all application-level communication is 992 authenticated and encrypted, however, this attack could still be 993 used as a traffic analysis tool for observing who the client is 994 communicating with. 996 9. IANA Considerations 998 There are no IANA considerations. 1000 10. Normative References 1002 [BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and Guha, S., "NAT 1003 Behavioral Requirements for ICMP protocol", 1004 draft-ietf-behave-nat-icmp-03.txt (Work In Progress), 1005 March 2007. 1007 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Francis, P., Sivakumar, S., 1008 and Srisuresh, P., "NAT Behavioral Requirements for 1009 Unicast TCP", draft-ietf-behave-tcp-00.txt (Work In 1010 Progress), February 2006. 1012 [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for 1013 Unicast UDP", RFC 4787, January 2007. 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, March 1997. 1018 11. Informative References 1020 [BEH-TOP] Srisuresh, P., and Ford, B., "Complications from Network 1021 Address Translator Deployment Topologies", 1022 draft-ford-behave-top-02.txt (Work In Progress), 1023 July 2006. 1025 [H.323] "Packet-based Multimedia Communications Systems", ITU-T 1026 Recommendation H.323, July 2003. 1028 [ICE] Rosenberg, J. "Interactive Connectivity Establishment (ICE): 1029 A Methodology for Network Address Translator (NAT) Traversal 1030 for Offer/Answer Protocols", draft-ietf-mmusic-ice-09.txt 1031 (work in Progress), June 2006. 1033 [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. 1034 http://www.alumni.caltech.edu/~dank/peer-nat.html 1036 [MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1037 Rayhan, A., "Middlebox communication architecture and 1038 framework", RFC 3303, August 2002. 1040 [NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly 1041 Application Design Guidelines", RFC 3235, January 2002. 1043 [NAT-PROT] Holdrege, M., and Srisuresh, P., "Protocol Complications 1044 with the IP Network Address Translator", RFC 3027, 1045 January 2001. 1047 [NAT-TERM] Srisuresh, P., and Holdrege, M., "IP Network Address 1048 Translator (NAT) Terminology and Considerations", RFC 2663, 1049 August 1999. 1051 [NAT-TRAD] Srisuresh, P., and Egevang, K., "Traditional IP Network 1052 Address Translator (Traditional NAT)", RFC 3022, 1053 January 2001. 1055 [NATBLAST] Biggadike, A., Ferullo, D., Wilson, G. and Perrig, A., 1056 "NATBLASTER: Establishing TCP Connections Between Hosts 1057 Behind NATs", ACM SIGCOMM Asia Workshop, April 2005. 1059 [NUTSS] Guha, S., Takeday Y., and Francis, P., "NUTSS: A 1060 SIP-based Approach to UDP and TCP Network Connectivity", 1061 SIGCOMM 2004 Workshops, August 2004. 1063 [NATTRAV] Eppinger, J.L., "TCP Connections for P2P Apps: A 1064 Software Approach to Solving the NAT Problem", Carnegie 1065 Mellon Tech Report CMU-ISRI-05-104, January 2005. 1067 [P2PNAT] Ford, B., Srisuresh, P., and Kegel, D., "Peer-to-Peer 1068 Communication Across Network Address Translators", USENIX 1069 Annual Technical Conference, April 2005. 1071 [P2P-STATE] Srisuresh, P., Ford, B., and Kegel, D., "State of Peer-to- 1072 Peer (P2P) communication across Network Address Translators 1073 (NATs)", draft-ietf-behave-p2p-state-02.txt (Work In 1074 Progress), February 2007. 1076 [RFC1122] Braden, R., Editor, "Requirements for Internet Hosts - 1077 Communication Layers", STD 3, RFC 1122, October 1989. 1079 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 1080 2002. 1082 [RSIP] Borella, M., Lo, J., Grabelsky, D., and Montenegro, G., 1083 "Realm Specific IP: Framework", RFC 3102, October 2001. 1085 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1086 A., Peterson, J., Sparks, R., Handley, M., and Schooler, 1087 E. "SIP: Session Initiation Protocol", RFC 3261, 1088 June 2002. 1090 [SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1091 Jones, L., "SOCKS Protocol Version 5", RFC 1928, 1092 March 1996. 1094 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 1095 RFC 793, September 1981. 1097 [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1098 NATs", draft-ietf-ngtrans-shipworm-08.txt (Work In 1099 Progress), September 2002. 1101 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1102 Device Control Protocol V 1.0", November 2001. 1103 http://www.upnp.org/standardizeddcps/igd.asp 1105 [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral 1106 Self-Address Fixing (UNSAF) Across Network Address 1107 Translation", RFC 3424, November 2002. 1109 Authors' Addresses: 1111 Bryan Ford 1112 Computer Science and Artificial Intelligence Laboratory 1113 Massachusetts Institute of Technology 1114 77 Massachusetts Ave. 1115 Cambridge, MA 02139 1116 U.S.A. 1117 Phone: (617) 253-5261 1118 E-mail: baford@mit.edu 1119 Web: http://www.brynosaurus.com/ 1121 Pyda Srisuresh 1122 Kazeon Systems, Inc. 1123 1161 San Antonio Rd. 1124 Mountain View, CA 94043 1125 U.S.A. 1126 Phone: (408)836-4773 1127 E-mail: srisuresh@yahoo.com 1129 Dan Kegel 1130 Kegel.com 1131 901 S. Sycamore Ave. 1132 Los Angeles, CA 90036 1133 Phone: (323) 931-6717 1134 E-mail: dank@kegel.com 1135 Web: http://www.kegel.com/ 1137 Intellectual Property Statement 1139 The IETF takes no position regarding the validity or scope of any 1140 Intellectual Property Rights or other rights that might be claimed to 1141 pertain to the implementation or use of the technology described in 1142 this document or the extent to which any license under such rights 1143 might or might not be available; nor does it represent that it has 1144 made any independent effort to identify any such rights. Information 1145 on the procedures with respect to rights in RFC documents can be 1146 found in BCP 78 and BCP 79. 1148 Copies of IPR disclosures made to the IETF Secretariat and any 1149 assurances of licenses to be made available, or the result of an 1150 attempt made to obtain a general license or permission for the use of 1151 such proprietary rights by implementers or users of this 1152 specification can be obtained from the IETF on-line IPR repository at 1153 http://www.ietf.org/ipr. 1155 The IETF invites any interested party to bring to its attention any 1156 copyrights, patents or patent applications, or other proprietary 1157 rights that may cover technology that may be required to implement 1158 this standard. Please address the information to the IETF at 1159 ietf-ipr@ietf.org. 1161 Copyright Statement 1163 Copyright (C) The IETF Trust (2007). 1165 This document is subject to the rights, licenses and restrictions 1166 contained in BCP 78, and except as set forth therein, the authors 1167 retain all their rights. 1169 This document and the information contained herein are provided on an 1170 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1171 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1172 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1173 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1174 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1175 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1177 Acknowledgment 1179 Funding for the RFC Editor function is currently provided by the 1180 IETF Trust.