idnits 2.17.1 draft-ford-behave-top-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1106. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1119. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 20 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. 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 23, 2006) is 6366 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) == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-01 -- No information found for draft-ietf-behave-nat-tcp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BEH-TCP' ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') == Outdated reference: A later version (-06) exists of draft-ietf-behave-p2p-state-00 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P. Srisuresh 3 Document: draft-ford-behave-top-03.txt Consultant 4 Expires: April 23, 2007 B. Ford 5 M.I.T. 6 October 23, 2006 8 Complications from Network Address Translator Deployment Topologies 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document identifies two deployment scenarios that have arisen 37 from the unconventional network topologies formed using Network 38 Address Translator devices (NATs). First, the simplicity of 39 administering networks through the combination of NAT and DHCP has 40 increasingly lead to the deployment of multi-level inter-connected 41 private networks involving overlapping IP address spaces. Second, 42 the proliferation of private networks in enterprises, hotels and 43 conferences, and the wide spread use of Virtual Private Networks 44 (VPNs) to access enterprise intranet from remote locations has 45 increasingly lead to overlapping IP address space between remote 46 and corporate networks. The document does not dismiss these 47 unconventional scenarios as invalid, but recognizes them as real and 48 offers recommendations to ensure these real scenarios can funtion. 50 Table of Contents 52 1. Introduction and Scope........................................ 53 2. Multi-Level NAT Network Topologies ........................... 54 2.1 Operational Details of the Multi-Level NAT Network ....... 55 2.1.1. Client/Server Communication ....................... 56 2.1.2. Peer-to-Peer Communication ........................ 57 2.2. Anomalies of the Multi-Level NAT Network ................ 58 2.2.1. Plug-and-Play NAT Devices ......................... 59 2.2.2. Unconventional Addressing on NAT Devices .......... 60 2.2.3. Multi-Level NAT Translations ...................... 61 2.2.4. Mistaken End Host Identity ........................ 62 2.3. Summary of Recommendations .............................. 63 3. Remote Access VPN Network Topologies ......................... 64 3.1. Operational Details of the Remote Access VPN Network .... 65 3.2. Anomalies of the Remote Access VPN Network .............. 66 3.2.1. Remote Router and DHCP Server Address Conflict ... 67 3.2.2. Simultaneous Connectivity Conflict ............... 68 3.2.3. VIP Address Conflict ............................. 69 3.2.4. Mistaken End Host Identity ....................... 70 3.3. Summary of Recommendations .............................. 71 4. Security Considerations ...................................... 72 5. Acknowledgements ............................................. 73 6. Normative References ......................................... 74 7. Informational References ..................................... 76 1. Introduction and Scope 78 The Internet was originally designed to use a single, global 32-bit 79 IP address space to uniquely identify hosts on the network, allowing 80 applications on one host to address and initiate communications with 81 applications on any other host regardless of the respective hosts' 82 topological locations or administrative domains. For a variety of 83 pragmatic reasons, however, the Internet has gradually drifted away 84 from strict conformance to this ideal of a single flat global address 85 space, and towards a hierarchy of smaller "private" address spaces 86 [RFC1918] clustered around a large central "public" address space. 87 The most important pragmatic causes of this unintended evolution of 88 the Internet's architecture appear to be the following. 90 1. Depletion of the 32-bit IPv4 address space due to the exploding 91 total number of hosts on the Internet. Although IPv6 promises to 92 solve this problem, the uptake of IPv6 has in practice been slower 93 than expected. 95 2. Perceived Security and Privacy: Traditional NAT devices provide a 96 filtering function that permits session flows to cross the NAT in 97 just one direction, from private hosts to public network hosts. 98 This filtering function is widely perceived as a security benefit. 99 In addition, the NAT's translation of a host's original IP 100 addresses and port number in private network into an unrelated, 101 external IP address and port number is perceived by some as a 102 privacy benefit. 104 3. Ease-of-use: NAT vendors often combine the NAT function with a 105 DHCP server function in the same device, which creates a 106 compelling, effectively "plug-and-play" method of setting up small 107 Internet-attached personal networks that is often much easier in 108 practice for unsophisticated consumers than configuring an 109 IP subnet. The many popular and inexpensive consumer NAT devices 110 on the market are usually configured "out of the box" to obtain a 111 single "public" IP address from an ISP or "upstream" network via 112 DHCP, and the NAT device in turn acts as both a DHCP server and 113 default router for any "downstream" hosts (and even other NATs) 114 that the user plugs into it. Consumer NATs in this way effectively 115 create and manage private home networks automatically without 116 requiring any knowledge of network protocols or management on the 117 part of the user. Auto-configuration of private hosts makes 118 NAT devices a compelling solution in this common scenario. 120 The term NAT used throughout the document refers to the traditional 121 NAT, as defined in [NAT-TERM] and specified in [NAT-TRAD]. 123 [NAT-PROT] identifies various complications with application 124 protocols due to NAT devices. This document acts as an adjunct to 125 [NAT-PROT]. The scope of the document is restricted to the two 126 scenarios identified in sections 2 and 3, as arising out of 127 unconventional NAT deployment and private address space overlap. 128 Even though the scenarios appear unconventional, they are real and 129 and not uncommon to find. For each scenario, the document describes 130 the seeming anomalies and offers recommendations on how best to make 131 the topologies work. 133 Section 2 describes the problem of private address space overlap 134 due to multi-level NAT topology, the anomalies with the topology and 135 recommendations to address the anomalies. Section 3 describes the 136 problem of private address space overlap with remote access 137 Virtual Private Network (VPN) connection, the anomalies with 138 address overlap and recommendations to address the anomalies. 139 Section 4 describes the security considerations in these scenarios. 141 2 Multi-Level NAT Network Topologies 142 Due to the pragmatic considerations discussed in the previous 143 section and perhaps others, NATs are increasingly, and often 144 unintentionally, used to create hierarchically interconnected 145 clusters of private networks as illustrated in figure 1 below. The 146 creation of multi-level hierarchies is often unintentional, since 147 each level of NAT is typically deployed by a separate 148 administrative entity such as an ISP, a corporation, or a home user. 150 Public Internet 151 (Public IP addresses) 152 ----+---------------+---------------+---------------+---- 153 | | | | 154 | | | | 155 66.39.3.7 18.181.0.31 138.76.29.7 155.99.25.1 156 +-------+ Host A Host B +-------------+ 157 | NAT-1 | (Alice) (Jim) | NAT-2 | 158 | (Bob) | | (CheapoISP) | 159 +-------+ +-------------+ 160 10.1.1.1 10.1.1.1 161 | | 162 | | 163 Private Network 1 Private Network 2 164 (private IP addresses) (private IP addresses) 165 ----+--------+---- ----+-----------------------+---- 166 | | | | | 167 | | | | | 168 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12 169 Host C Host D +-------+ Host E +-------+ 170 | NAT-3 | (Mary) | NAT-4 | 171 | (Ann) | | (Lex) | 172 +-------+ +-------+ 173 10.1.1.1 10.1.1.1 174 | | 175 | | 176 Private Network 3 | Private Network 4 177 (private IP addresses)| (private IP addresses) 178 ----+-----------+---+ ----+-----------+---- 179 | | | | 180 | | | | 181 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 182 Host F Host G Host H Host I 184 Figure 1. Multi-level NAT topology with Overlapping Address Space 186 In the above scenario, Bob, Alice, Jim, and CheapoISP have each 187 obtained a "genuine", globally routable IP address from an upstream 188 service provider. Alice and Jim have chosen to attach only a single 189 machine at each of these public IP addresses, preserving the 190 originally intended architecture of the Internet and making their 191 hosts, A and B, globally addressable throughout the Internet. Bob, 192 in contrast, has purchased and attached a typical consumer NAT box. 193 Bob's NAT obtains its external IP address (66.39.3.7) from Bob's ISP 194 via DHCP, and automatically creates a private 10.1.1.x network for 195 Bob's hosts C and D, acting as the DHCP server and default router for 196 this private network. Bob probably does not even know anything about 197 IP addresses; he merely knows that plugging the NAT into the Internet 198 as instructed by the ISP, and then plugging his hosts into the NAT as 199 the NAT's manual indicates, seems to work and gives all of his hosts 200 access to Internet. 202 CheapoISP, an inexpensive service provider, has allocated only one or 203 a few globally routable IP addresses, and uses NAT to share these 204 public IP addresses among its many customers. Such an arrangement is 205 becoming increasingly common, especially in rapidly-developing 206 countries where the exploding number of Internet-attached hosts 207 greatly outstrips the ability of ISPs to obtain globally unique IP 208 addresses for them. CheapoISP has chosen the popular 10.1.1.x 209 address for its private network, since this is one of the three 210 well-known private IP address blocks allocated in [RFC1918] 211 specifically for this purpose. 213 Of the three incentives listed in section 1 for NAT deployment, the 214 last two still apply even to customers of ISPs that use NAT, 215 resulting in multi-level NAT topologies as illustrated in the right 216 side of the above diagram. Even three-level NAT topologies are known 217 to exist. CheapoISP's customers Ann, Mary, and Lex have each obtained 218 a single IP address on CheapoISP's network (Private Network 2), via 219 DHCP. Mary attaches only a single host at this point, but 220 Ann and Lex each independently purchase and deploy consumer NATs in 221 the same way that Bob did above. As it turns out, these consumer 222 NATs also happen to use 10.1.1.x addresses for the private networks 223 they create, since these are the configuration defaults hard-coded 224 into the NATs by their vendors. Ann and Lex probably know nothing 225 about IP addresses, and in particular they are probably unaware that 226 the IP address spaces of their own private networks overlap not only 227 with each other but also with the private IP address space used by 228 their immediately upstream network. 230 Nevertheless, despite this direct overlap, all of the "multi-level 231 NATted hosts" - F, G, H, and I in this case - all nominally function 232 and are able to initiate connections to any public server on the 233 public Internet that has a globally routable IP address. Connections 234 made from these hosts to the main Internet are merely translated 235 twice. Once by the consumer NAT (NAT-3 or NAT-44) into the IP 236 address space of CheapoISP's Private Network 2, and then again by 237 CheapoISP's NAT-2 into the public Internet's global IP address 238 space. 240 2.1 Operational Details of the Multi-Level NAT Network 242 In the "de facto" Internet address architecture that has resulted 243 from the above pragmatic and economic incentives, only the nodes on 244 the public Internet have globally unique IP addresses assigned by 245 the official IP address registries. IP addresses on different 246 private networks are typically managed independently - either 247 manually by the administrator of the private network itself, or 248 automatically by the NAT through which the private network is 249 connected to its "upstream" service provider. 251 By convention, nodes on private networks are usually assigned IP 252 addresses in one of the private address space ranges specifically 253 allocated to this purpose in RFC 1918, ensuring that private IP 254 addresses are easily distinguishable and do not conflict with the 255 public IP addresses officially assigned to globally routable Internet 256 hosts. However, when "plug-and-play" NATs are used to create 257 hierarchically interconnected clusters of private networks, a given 258 private IP address can be and often is reused across many different 259 private networks. In figure 1 above, for example, private networks 260 1, 2, 3, and 4 all have a node with IP address 10.1.1.10. 262 2.1.1. Client/Server Communication 264 When a host on a private network initiates a client/server-style 265 communication session with a server on the public Internet, via the 266 server's public IP address, the NAT intercepts the packets comprising 267 that session (usually as a consequence of being the default router 268 for the private network), and modifies the packets' IP and TCP/UDP 269 headers so as to make the session appear externally as if it was 270 initiated by the NAT itself. 272 For example, if host C above initiates a connection to host A at IP 273 address 18.181.0.31, NAT-1 modifies the packets comprising the 274 session so as to appear on the public Internet as if the session 275 originated from NAT-1. Similarly, if host F on private network 3 276 initiates a connection to host A, NAT-3 modifies the outgoing packet 277 so the packet appears on private network 2 as if it had originated 278 from NAT-3 at IP address 10.1.1.10. When the modified packet 279 traverses NAT-2 on private network 2, NAT-2 further modifies the 280 outgoing packet so as to appear on the public Internet as if it had 281 originated from NAT-2 at public IP address 155.99.25.1. The NATs in 282 effect serve as proxies that give their private "downstream" client 283 nodes a temporary presence on "upstream" networks to support 284 individual communication sessions. 286 In summary, all hosts on the private networks 1, 2, 3, and 4 in 287 figure 1 above are able to establish a client/server-style 288 communication sessions with servers on the public Internet. 290 2.1.2. Peer-to-Peer Communication 292 While this network organization functions in practice for 293 client/server-style communication, when the client is behind one or 294 more levels of NAT and the server is on the public Internet, the lack 295 of globally routable addresses for hosts on private networks makes 296 direct peer-to-peer communication between those hosts difficult. For 297 example, two private hosts F and H on the network shown above might 298 "meet" and learn of each other through a well-known server on the 299 public Internet, such as Host A, and desire to establish direct 300 communication between G and H without requiring A to forward each 301 packet. If G and H merely learn each other's (private) IP addresses 302 from a registry kept by A, their attempts to connect to each other 303 will fail because G and H reside on different private networks. 304 Worse, if their connection attempts are not properly authenticated, 305 they may appear to succeed but end up talking to the wrong host. For 306 example, G may end up talking to Host F, the host on private 307 network 3 that happens to have the same private IP address as Host H. 308 Host H might similarly end up unintentionally connecting to Host I. 310 In summary, peer-to-peer communication between hosts on disjoint 311 private networks 1, 2, 3, and 4 in figure 1 above is a challenge 312 without the assistance of a well known server on the public 313 Internet. However, with assistance from a node in the public 314 Internet, all hosts on the private networks 1, 2, 3, and 4 in 315 figure 1 above are able to establish a peer-to-peer style 316 communication sessions amongst themselves as well as with hosts 317 on the public Internet. 319 2.2. Anomalies of the Multi-Level NAT Network 321 Even though conventional wisdom would suggest that the network 322 described above is seriously broken, in practice it still works in 323 many ways. We break up figure 1 into two sub figures to better 324 illustrate the anomalies. Figure 1.1 is the left half of figure 1 325 and reflects the conventional single NAT deployment that is widely 326 prevalent in many last-mile locations. The deployment in figure 1.1 327 is popularly viewed as a pragmatic solution to work around the 328 depletion of IPv4 address space and is not considered broken. 329 Figure 1.2 is the right half of figure-1 and is representative of 330 the anomalies we are about to discuss. 332 Public Internet 333 (Public IP addresses) 334 ----+---------------+---------------+----------- 335 | | | 336 | | | 337 66.39.3.7 18.181.0.31 138.76.29.7 338 +-------+ Host A Host B 339 | NAT-1 | (Alice) (Jim) 340 | (Bob) | 341 +-------+ 342 10.1.1.1 343 | 344 | 345 Private Network 1 346 (private IP addresses) 347 ----+--------+---- 348 | | 349 | | 350 10.1.1.10 10.1.1.11 351 Host C Host D 353 Figure 1.1. Conventional Single-level NAT Network topology 354 Public Internet 355 (Public IP addresses) 356 ---+---------------+---------------+---- 357 | | | 358 | | | 359 18.181.0.31 138.76.29.7 155.99.25.1 360 Host A Host B +-------------+ 361 (Alice) (Jim) | NAT-2 | 362 | (CheapoISP) | 363 +-------------+ 364 10.1.1.1 365 | 366 | 367 Private Network 2 368 (private IP addresses) 369 ----+---------------+-------------+--+------- 370 | | | 371 | | | 372 10.1.1.10 10.1.1.11 10.1.1.12 373 +-------+ Host E +-------+ 374 | NAT-3 | (Mary) | NAT-4 | 375 | (Ann) | | (Lex) | 376 +-------+ +-------+ 377 10.1.1.1 10.1.1.1 378 | | 379 | | 380 Private Network 3 Private Network 4 381 (private IP addresses) (private IP addresses) 382 ----+-----------+------ ----+-----------+---- 383 | | | | 384 | | | | 385 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 386 Host F Host G Host H Host I 388 Figure 1.2. Unconventional Multi-level NAT Network topology 390 2.2.1. Plug-and-Play NAT Devices 392 Consumer NAT devices are predominantly "plug-and-play" NAT devices, 393 and assume minimal user intervention during device setup. The 394 "plug-and-play" NAT devices provide DHCP service on one interface 395 and NAT function on another interface. Vendors of the consumer NAT 396 devices make assumptions about how their consumers configure and 397 hook up their PCs to the device. When consumers do not adhere to the 398 vendor assumptions, the consumers end up with a broken network. 400 A "plug-and-play" NAT device provides DHCP service on the LAN 401 attached to the private interface, and assumes that all private 402 hosts at the consumer site have DHCP client enabled and are 403 connected to the single LAN. Consumers should be informed of the 404 assumption that all private hosts must be on a single LAN, with no 405 router in between. 407 A "Plug-and-Play" NAT device also assumes that there is no other 408 NAT device or DHCP server device on the same LAN at the customer 409 premises. When there are multiple "Plug-and-play" NAT devices on 410 the same LAN, each NAT device will offer DHCP service on the same 411 LAN, and likely from the same address pool. This could result 412 in multiple end nodes on the same LAN ending up with identical IP 413 addresses. That will break network connectivity to end hosts. 414 Consumers should be cautioned against using more than one 415 "plug-and-play" NAT device on the same LAN. 417 Recommendation-1. Consumers should be informed that all private 418 hosts behind a "Plug-and-play" NAT must be on a single LAN subnet, 419 and that there should be no more than one "Plug-and-play" NAT device 420 on the same LAN. 422 2.2.2. Unconventional Addressing on NAT Devices 424 Let us consider the unconventional addressing with NAT-3 and 425 NAT-4. NAT-3 and NAT-4 are apparently multi-homed on the same 426 subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24 427 through its external interface facing NAT-2, as well as through its 428 private interface facing clients Host-F and Host-G. Likewise, NAT-4 429 also has two interfaces on the same subnet 10.1.1/24. 431 In a traditional network, when a node has multiple interfaces with 432 IP addresses on the same subnet, it is natural to assume that all 433 interfaces with addresses on the same subnet must be on a single 434 connected LAN (bridged LAN or a single physical LAN). Clearly, that 435 is not the case here. Even though both NAT-3 and NAT-4 have two 436 interfaces on the same subnet 10.1.1/24, the NAT devices view the 437 two interfaces as being on two disjoint subnets and routing realms. 438 The "plug-and-play" NAT devices are really not multi-homed on the 439 same subnet as in a traditional sense. 441 In a traditional network, both NAT-3 and NAT-4 in figure 1.2 should 442 be incapable of communicating reliably as a transport endpoint with 443 other nodes on their adjacent networks (ex: private networks 2 and 444 3 in the case of NAT-3 and private Networks 2 and 4 in the case of 445 NAT-4). This is because applications on either of the NAT devices 446 cannot know to differentiate packets from hosts on either of the 447 subnets bearing the same IP address. If NAT-3 attempts to resolve 448 the IP address of a neighboring host in the conventional manner by 449 broadcasting an ARP request on all of its physical interfaces 450 bearing the same subnet, it may get a different response on each 451 of its physical interfaces. 453 Even though both NAT-3 and NAT-4 have hosts bearing the same IP 454 address on the adjacent networks, the NAT devices do communicate 455 effectively as end points. Many of the "plug-and-play" NAT devices 456 offer a limited number of services on them. For example, many of 457 the NAT devices respond to pings from hosts on either of the 458 interfaces. Even though a NAT device is often not actively 459 managed, many of the NAT devices are equipped to be managed from 460 the private interface. This unconventional communication with 461 NAT devices is achievable because NAT devices view the 462 two interfaces as being on two disjoint routing domains and 463 distinguish between sessions with hosts on either interface 464 (private or public). 466 Consumer oriented "Plug-and-Play" NAT devices must and all NATs 467 should be able to handle multi-level NAT topologies such as the one 468 described in figure 1.2, in which a private IP address space on one 469 side of the NAT potentially conflicts with the private IP address 470 space on the other side. Essentially NAT must be able to keep the 471 two IP address spaces separate in its internal data structures, and 472 base all packet processing decisions on the "side" or "port" from 473 which the packet arrived and not just on the basis of the IP 474 addresses it contains. This recommendation reiterates REQ-7 of 475 [BEH-UDP]. 477 Recommendation-2. As specified in REQ-7 of [BEH-UDP], NAT devices 478 should support IP address space overlap between the address space 479 on its private interface and the address space on its public 480 interface. Essentially, a NAT device should keep the two IP address 481 spaces separate and base all packet processing decisions on the 482 "side" or "port" from which the packet arrived and not just on the 483 basis of the IP addresses. 485 2.2.3. Multi-Level NAT Translations 487 Use of a single NAT to connect private hosts to the public Internet 488 as in figure 1.1 is a fairly common practice. Many consumer NATs are 489 deployed this way. However, use of multi-level NAT translations as 490 in figure 1.2 is not a common practice and is not well understood. 492 Let us consider the conventional single NAT translation in 493 figure 1.1. Because the public and private IP address ranges are 494 numerically disjoint, nodes on private networks can make use of both 495 public and private IP addresses when initiating network 496 communication sessions. Nodes on a private network can use private 497 IP addresses to refer to other nodes on the same private network, 498 and public IP addresses to refer to nodes on the public Internet. 499 For example, host C in figure 1.1 is on private network 1 and can 500 directly address hosts A, B and D using their assigned IP addresses. 501 This is in spite of the fact that hosts A and B are on the public 502 Internet and host D alone is on the private network. 504 Next, let us consider the unconventional multi-level NAT topology in 505 figure 1.2. In this scenario, private hosts are able to connect to 506 hosts on the public Internet. But, private hosts are not able to 507 connect with all other private hosts. For example, host F in 508 figure 1.2 can directly address hosts A, B, and G using their 509 assigned IP addresses, but F has no way to address any of the 510 other hosts in the diagram. Host F in particular cannot address 511 host E by its assigned IP address, even though host E is located on 512 the immediately "upstream" private network through which F is 513 connected to the Internet. Host E has the same IP address as 514 host G. Yet, this addressing is "legitimate" in the NAT world 515 because the two hosts are on different private networks. 517 It would seem that the topology in figure 1.2 with multiple 518 NAT translations is broken because private hosts are not able to 519 address each other directly. However, the network is not broken. 520 Nodes on any private network have no direct method of addressing 521 nodes on other private networks. The private networks 1, 2, 3 and 4 522 are all disjoint. Hosts on private network 1 are unable to directly 523 address nodes on private networks 2, 3 or 4 and vice versa. Multiple 524 NAT translations was not the cause of this. 526 As described in sections 2.1.1 and 2.1.2, client-server and 527 peer-to-peer communication can and should be possible even with 528 multi-level NAT topology deployment. A host on any private network 529 must be able to communicate with any other host, no matter which 530 private network the host is attached to or where the private network 531 is located. Host F should be able to communicate with host E and 532 carry out both client-server communication and peer-to-peer 533 communication, and vice versa. Host F and host E form a hairpin 534 session through NAT-2 to communicate with each other. Each host 535 uses the public endpoint assigned by the Internet facing NAT (NAT-2) 536 to address its peer. NAT devices should support hairpin translation 537 ([P2P-STATE]) for session flows that originate from a host on one 538 attached private network and targeted to a host on another private 539 network also attached to the same NAT device. Hairpin translation 540 is explained in detail in section 4.4 of [P2P-STATE]. 542 Ideally, ISPs should not use NAT devices to connect their customers, 543 so the customers do not get caught up in a multi-level NAT scenario 544 and hairpin session flows. NAT devices must support hairpin 545 translations for all protocol sessions the NAT device supports. 546 Hairpin translation support is a requirement for peer node 547 connectivity in multi-level NAT topologies. This is reiterated in 548 BEHAVE recommendations for NAT devices for UDP, TCP and ICMP 549 protocols ([BEH_UDP], [BEH-TCP], [BEH-ICMP]). 551 Recommendation-3. As specified in BEHAVE documents for IP protocols 552 ([BEH-UDP], [BEH-TCP], [BEH-ICMP]), NAT devices need to support 553 hairpin translation. 555 2.2.4. Mistaken End Host Identity 557 There can be a potential security threat due to mistaken identity 558 in figure 1.2. Suppose, the CheapoISP in figure 1.2 used host E as 559 the ISP mail server. Host E is assigned an RFC 1918 address of 560 10.1.1.11. This address can potentially overlap with addresses on 561 private networks 3 and 4. So, if a customer of CheapoISP had a 562 mail server installed on his/her private network, bearing an IP 563 address exactly the same as host E, this could pose a severe 564 security threat to customer's mail messages. Potentially, the 565 customer mail messages could be hijacked by the ISP's mail server. 567 Ideally, ISPs should not use NAT devices to provide connectivity to 568 their customers. If they do, any servers on the ISP's private 569 network that need to be accessible to the ISP's customers 570 (e.g., mail servers) should have global IP addresses, to ensure 571 accessibility to customers who deploy NAT devices themselves. 573 Recommendation-4. Ideally, ISPs should not use NAT devices to 574 provide connectivity to their customers. If they do, any 575 servers on the ISP's private network that need to be accessible to 576 the ISP's customers (e.g., mail servers) should have global IP 577 addresses, to ensure customer IP addresses don't conflict with 578 IP addresses of the ISP's servers. 580 2.3. Summary of Recommendations 582 The following is a summary of recommendations identified in section 583 2.2 to support the unconventional multi-level NAT topologies, such 584 as the one identified in figure 1. The recommendations are addressed 585 to NAT vendors, ISPs and consumers. Note, the recommendations listed 586 are emanating merely from the perspective of a specific topology 587 considered in the document. For this reason, the recommendations 588 should not be considered complete for NAT vendors, ISPs or 589 consumers. Specifically, the recommendations for NAT vendors is 590 limited. Readers should refer BEHAVE protocol documents ([BEH-UDP], 591 [BEH-TCP] and [BEH-ICMP]) for a comprehensive list of requirements 592 for NAT vendors. It may be noted that the recommendations provided 593 for NAT vendors in this document (i.e., recommendations 2 & 3) are 594 well in line with the recommendations in BEHAVE documents. 596 Recommendation-1. Consumers should be informed that all private 597 hosts behind a "Plug-and-play" NAT must be on a single LAN subnet, 598 and that there should be no more than one "Plug-and-play" NAT device 599 on the same LAN. 601 Recommendation-2. As specified in REQ-7 of [BEH-UDP], NAT devices 602 should support IP address space overlap between the address space 603 on its private interface and the address space on its public 604 interface. Essentially, a NAT device should keep the two IP address 605 spaces separate and base all packet processing decisions on the 606 "side" or "port" from which the packet arrived and not just on the 607 basis of the IP addresses. 609 Recommendation-3. As specified in BEHAVE documents for IP protocols 610 ([BEH-UDP], [BEH-TCP], [BEH-ICMP]), NAT devices need to support 611 hairpin translation. 613 Recommendation-4. Ideally, ISPs should not use NAT devices to 614 provide connectivity to their customers. If they do, any 615 servers on the ISP's private network that need to be accessible to 616 the ISP's customers (e.g., mail servers) should have global IP 617 addresses, to ensure customer IP addresses don't conflict with 618 IP addresses of the ISP's servers. 620 3. Remote Access VPN Network Topologies 622 Enterprises use remote access VPN to allow secure access to the 623 employees working outside the enterprise premises. While outside 624 the enterprise premises, an employee may be located in his/her 625 home office, hotel, conference or a partner's office. In all cases, 626 it is desirable for the employee at the remote site to have 627 unhindered access to his/her corporate network and the applications 628 running on the corporate networks. This is so the employee can get 629 his/her work done seamlessly without jeopardizing the integrity and 630 confidentiality of the corporate network and the applications 631 running on the network. 633 IPsec, L2TP and SSL are some of the well known secure VPN 634 technologies used by the remote access vendors. Besides 635 authenticating employees for granting access, remote access VPN 636 servers often enforce different forms of security (e.g. IPsec, SSL) 637 to protect the integrity and confidentiality of the run-time 638 traffic between the VPN client and the VPN server. 640 Many enterprises deploy their internal networks using RFC-1918 641 private address space and use NAT devices to connect to the public 642 Internet. Further, many of the applications in the corporate network 643 refer to information (such as URLs) and services using private 644 addresses in the corporate network. Applications such as NFS rely on 645 simple source IP address based filtering to restrict access to 646 corporate users. These are some reasons why the remote access VPN 647 servers are configured with a block of IP addresses from the 648 corporate private network to assign to remote access clients. VPN 649 clients use the virtual IP (VIP) address assigned to them (by the 650 corporate VPN server) to access applications inside the corporate. 652 Consider the remote access VPN scenario in figure 2 below. 654 (Corporate Private network 10.0.0.0/8) 655 ---------------+---------------------- 656 | 657 10.1.1.10 658 +---------+-------+ 659 | Enterprise Site | 660 | Remote Access | 661 | VPN Server | 662 +--------+--------+ 663 129.32.34.18 664 | 665 {---------+------} 666 { } 667 { } 668 { Public Internet } 669 { (Public IP addresses) } 670 { } 671 { } 672 {---------+------} 673 | 674 155.99.25.1 675 +--------+--------+ 676 | Remote Site | 677 | "Plug-and-Play" | 678 | NAT router | 679 +--------+--------+ 680 10.1.1.1 681 | 683 Remote Site Private Network | 684 -----+-----------+-----------+-------------+----------- 685 | | | | 686 10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13 687 Host A Host B +--------+ Host C 688 | VPN | 689 | Client | 690 | on a PC| 691 +--------+ 693 Figure 2. Remote Access VPN with Overlapping Address Space 695 In the above scenario, say an employee of the corporate is at a 696 remote location and attempts to access the corporate network using 697 the VPN client. The corporate network is laid out using RFC-1918 698 address pool of 10.0.0.0/8 and say the VPN server is configured with 699 an address block of 10.1.1.0/24 to assign virtual IP addresses to 700 remote access VPN clients. Now, say the employee at the remote site 701 is attached to a network on the remote site which also happens to be 702 using a RFC-1918 address space based network and coincidentally 703 overlaps the corporate network. In this scenario, it is 704 conventionally problematic for the VPN client to connect to the 705 server(s) and other hosts at the enterprise. 707 Nevertheless, despite the direct address overlap, the remote access 708 VPN connection between the VPN client at the remote site and the 709 VPN server at the enterprise should remain connected and should be 710 made to work. I.e., the NAT device at the remote site should not 711 obstruct the VPN connection traversing it. And, the remote user 712 should be able to connect to any host at the enterprise through the 713 VPN from the remote desktop. 715 The following subsections describe the operational details of the 716 VPN, anomalies with the address overlap and recommendations on 717 how best to address the situation. 719 3.1. Operational Details of Remote Access VPN Network 721 As mentioned earlier, in the "de facto" Internet address 722 architecture, only the nodes on the public Internet have globally 723 unique IP addresses assigned by the official IP address registries. 724 Many of the networks in the edges use private IP addresses from 725 RFC 1918 and use NAT devices to connect their private networks 726 to the public Internet. Many enterprises adapted the approach of 727 using private IP addresses internally. Employees within the 728 enterprise's Intranet private network are "trusted" and may connect 729 to any of the internal hosts with minimal administrative or policy 730 enforcement overhead. When an employee leaves the enterprise 731 premises, remote access VPN provides the same level of intranet 732 connectivity to the remote user. 734 The objective of this section is to provide an overview of the 735 operational details of a remote access VPN application so the reader 736 has an appreciation for the problem of remote address space overlap. 737 This is not a tutorial or specification of remote access VPN 738 products, per se. 740 When an employee at a remote site launches his/her remote access VPN 741 client, the VPN server at the corporate premises demands the VPN 742 client to authenticate itself. When the authentication succeeds, 743 the VPN server assigns a Virtual IP (VIP) address to the client for 744 connecting with the corporate Intranet. From this point onwards, 745 while the VPN is active, outgoing IP packets directed to the hosts 746 in the corporate Intranet are tunneled through the VPN, in that the 747 the VPN server serves as the next-hop and the VPN connection as the 748 next-hop link for these packets. Within the corporate Intranet, the 749 outbound IP packets appear as arriving from the VIP address. so, 750 IP packets from the corporate hosts to the remote user are sent to 751 the remote user's VIP address and the IP packets are tunneled 752 inbound to the remote user's PC through the VPN tunnel. 754 This works well so long as the subnets in the corporate network 755 do not conflict with subnets at the remote site where the remote 756 user's PC is located. However, when the corporate network is built 757 using RFC 1918 private address space and the remote location where 758 the VPN client is launched is also using an overlapping network from 759 RFC 1918 address space, there can be addressing conflicts. The 760 remote user's PC will have a conflict in accessing nodes on the 761 corporate site and nodes at the remote site bearing the same IP 762 address simultaneously. Consequently, the VPN client may be unable 763 to have full access to the employee's corporate network and the 764 local network at the remote site simultaneously. 766 In spite of address overlap, remote access VPN clients should be 767 able to successfully establish connections with Intranet hosts in 768 the enterprise. 770 3.2. Anomalies of the Remote Access VPN network 772 Even though conventional wisdom would suggest that the remote access 773 VPN scenario with overlapping address space would be seriously 774 broken, in practice it still works in many ways. Let us look at some 775 anomalies where there might be a problem and identify solutions 776 through which the remote access VPN application could be made to 777 work even under the problem situations. 779 3.2.1. Remote Router and DHCP Server Address Conflict 781 Routing and DHCP service are bootstrap services essential for a 782 remote host to establish a VPN connection. Without DHCP lease, the 783 remote host can not communicate over the IP network. Without a 784 router to connect to the Internet, the remote host is unable to 785 access past the local subnet to connect to the VPN server at the 786 enterprise. It is essential that neither of these bootstrap services 787 be tampered at the remote host in order for the VPN connection to 788 stay operational. Typically, a "Plug-and-play" NAT device at the 789 remote site provides both routing and DHCP services from the same 790 IP address. 792 When there is address overlap between hosts at corporate Intranet 793 and hosts at the remote site, the remote VPN user is often unaware 794 of the address conflict. Address overlap could potentially cause the 795 remote user to lose connectivity to the enterprise entirely or 796 lose connectivity to an arbitrary block of hosts at the enterprise. 798 Consider, for example, a scenario where the IP address of the DHCP 799 server at the remote site matched the IP address of a host at 800 the enterprise network. When the remote user's PC is ready to 801 renew the lease of the locally assigned IP address, the remote 802 user's VPN client would incorrectly identify the IP packet 803 as being addressed to an enterprise host and tunnel the DHCP 804 renewal packet over the VPN to the remote VPN server. The DHCP 805 renewal requests simply do not reach the DHCP server at the 806 remote site. As a result, the remote PC would eventually lose the 807 lease on the IP address and the VPN connection to the enterprise 808 would be broken. 810 Consider another scenario where the IP address of the remote user's 811 router overlapped with the IP address of a host in the enterprise 812 network. If the remote user's PC were to send ping or some type of 813 periodic keep-alive packets to the router (say, to test the liveness 814 of the router), the packets are intercepted by the VPN client and 815 simply redirected to the VPN tunnel. This type of unintended 816 redirection has the twin effect of hijackng critical packets 817 addresed to the router as well as the host in the enterprise 818 network (bearing the same IP address as the remote router) being 819 bombarded with unintended keep-alive packets. Loss of connectivity 820 to the router can result in the VPN connection being broken. 822 Clearly, it is not desirable for the corporate intranet to conflict 823 with the IP addresses of the router and DHCP server at the remote 824 site. VPN servers should, at a minimum, disallow access to corporate 825 hosts that are using an IP address that might match any of the 826 following entities at the remote site - a) client's next-hop router 827 IP address used to access the VPN server, and b) DHCP server 828 providing address lease on the remote host network interface. By 829 doing this, VPN client on the remote PC will not intercept IP 830 packets whose target IP addresses are not in the authorized list 831 of enterprise hosts. And, the VPN connection remains. This however 832 has the downside that the VPN client loses connectivity to a 833 potentially mission critical host at the corporate site. 835 Recommendation-5. When deploying a remote access VPN client, if 836 there is conflict of address space between corporate Intranet and 837 the remote site, the VPN server server should disallow access from 838 the VPN client to corporate hosts bearing the same IP address as the 839 router or DHCP server at the remote site. 841 3.2.2. Simultaneous Connectivity Conflict 843 Ideally speaking, it is not desirable for the corporate intranet to 844 conflict with any of the hosts at the remote site. As a general 845 practice, if simultaneous communication with end hosts at the remote 846 location is important, it is advisable to disallow access to any 847 corporate network resource that overlaps the client's subnet at the 848 remote site. By doing this, the remote user is able to connect to 849 all local hosts simultaneously while the VPN connection is active. 850 For example, if the PC's external network interface is configured 851 with 10.1.1.1/24, the VPN server may be configured to disallow 852 access to the corporate network that overlaps this subnet at the 853 remote site for the VPN client. Such a configuration on the VPN 854 server is also termed sometimes as "Split VPN" configuration. When 855 "Split VPN" is enabled, the remote user is able to carry out 856 simultaneous communication with hosts at the remote site and the 857 hosts at the corporate intranet, with the exception of the hosts 858 that overlapped the remote subnet. 860 If simultaneous connectivity to local hosts is not important, the 861 VPN server may be configured to require the VPN client to direct 862 all communication traffic from the remote user to the VPN server 863 across the VPN. This essentially ensures that all 864 communication from the remote user's PC traverses the VPN link and 865 routed through the VPN server. No communication takes place with 866 hosts on the remote site. This configuration on the VPN server is 867 also termed sometimes as "Non-split VPN". When "Non-Split VPN" is 868 enabled, all traffic from the remote user's PC is directed to the 869 VPN server, with the exception of traffic directed to the local 870 router and DHCP server. 872 Recommendation-6. If simultaneous communication with end hosts at 873 remote site is important, enterprises should configure the VPN 874 server in "Split VPN" mode and disallow access to corporate hosts 875 that overlap the client's subnet at remote site. If simultaneous 876 connectivity to hosts at remote site is not important, enterprises 877 should configure the VPN server in "Non-split VPN" mode, so the VPN 878 client directs to the VPN server all traffic from the remote user, 879 with the exception of traffic to the router and DHCP server at the 880 remote site. 882 3.2.3. VIP Address Conflict 884 When the VIP address assigned to the VPN client at the remote site 885 is in direct conflict with the IP address of the existing network 886 interface, the VPN client might be unable to establish the VPN 887 connection. 889 Consider a scenario where the VIP address assigned by the 890 VPN server directly matched the IP address of the networking 891 interface at the remote site. When the VPN client on the remote 892 host attempts to set the VIP address on a virtual adapter (specific 893 to the remote access application), the VIP address configuration 894 will simply fail due to conflict with the IP address of the existing 895 network interface. The configuration failure in turn will result in 896 the remote access VPN tunnel not being established. 898 Clearly, it is not advisable to have the VIP address overlap 899 the IP address of the remote user's existing network interface. As a 900 general rule, it is not advisable for the VIP address to overlap 901 any IP address in the remote user's local subnet, as the VPN client 902 on the remote PC might be forced to respond to ARP requests on the 903 remote site and the VPN client might not process the handling of ARP 904 requests gracefully. 906 We recommend that VPN vendors offer provision to detect conflict of 907 VIP address with remote site address space and switch between a 908 minimum two VIP address pools on the VPN server. We also recommend 909 enterprises deploying the VPN solution to use this vendor provision 910 and configure the VPN server with a minimum of two distinct IP 911 address pools. Alternately, the enterprises should deploy a minimum 912 of two VPN servers with different address pools. By doing this, a 913 VPN client that detected the conflict of VIP address with the local 914 subnet is able to reconnect with the alternate VPN server using 915 the alternate address pool that will not conflict. 917 Recommendation-7. VPN vendors should offer provision to detect 918 conflict of VIP address with remote site address space and 919 switch between a minimum of two VIP address pools with different 920 subnets on the VPN server so the VIP address assigned is not in 921 conflict with the address space at remote site. 923 Recommendation-8. Enterprises deploying remote access VPN solution 924 should adapt a strategy to avoid VIP address conflict with the 925 subnet at remote site. Below are two suggestions. 926 a) If the VPN device being deployed has provision to configure two 927 address pools (as in recommendation above), configure the VPN 928 server with a minimum of two distinct IP address pools. 929 b) Deploy a minimum of two VPN servers with different address pools. 930 By doing this, a VPN client that detected the conflict of VIP 931 address with the subnet at remote site has the option to switch to 932 alternate VPN server and eliminate VIP address conflict. 934 3.2.4. Mistaken End Host Identity 936 When "Split VPN" configuration is set on the VPN server, there can 937 be a potential security threat due to mistaken identity. 938 Say, a certain service (ex: SMTP mail service) is configured on 939 exactly the same IP address on both the corporate site and the 940 remote site. The user could unknowingly be using the service on the 941 remote site, thereby violating the integrity and confidentiality of 942 the contents relating to that application. Potentially, remote 943 user mail messages could be hijacked by the ISP's mail server. 945 Enterprises deploying remote access VPN servers should allocate 946 global IP addresses for the critical servers the remote VPN clients 947 typically need to access. By doing this, even if most of the private 948 corporate network uses RFC 1918 address space, this will ensure that 949 the remote VPN clients can always access the critical servers 950 regardless of the private address space used at the remote 951 attachment point. 953 Recommendation-9. When "Split VPN" is configured on the VPN server, 954 enterprises deploying remote access VPN servers should allocate 955 global IP addresses for the critical servers the remote VPN clients 956 typically need to access. 958 3.3. Summary of Recommendations 960 The following is a summary of recommendations identified in section 961 3.2 to support the address overlap in remote access VPN networks, 962 such as the one identified in figure 2. The recommendations are 963 addressed to remote access VPN vendors, enterprises deploying the 964 VPN servers and finally, the remote access VPN consumers. Following 965 the recommendations will help ensure that a complete "network 966 meltdown" is prevented. 968 Recommendation-5. When deploying a remote access VPN client, if 969 there is conflict of address space between corporate Intranet and 970 the remote site, the VPN server server should disallow access from 971 the VPN client to corporate hosts bearing the same IP address as the 972 router or DHCP server at the remote site. 974 Recommendation-6. If simultaneous communication with end hosts at 975 remote site is important, enterprises should configure the VPN 976 server in "Split VPN" mode and disallow access to corporate hosts 977 that overlap the client's subnet at remote site. If simultaneous 978 connectivity to hosts at remote site is not important, enterprises 979 should configure the VPN server in "Non-split VPN" mode, so the VPN 980 client directs to the VPN server all traffic from the remote user, 981 with the exception of traffic to the router and DHCP server at the 982 remote site. 984 Recommendation-7. VPN vendors should offer provision to detect 985 conflict of VIP address with remote site address space and 986 switch between a minimum of two VIP address pools with different 987 subnets on the VPN server so the VIP address assigned is not in 988 conflict with the address space at remote site. 990 Recommendation-8. Enterprises deploying remote access VPN solution 991 should adapt a strategy to avoid VIP address conflict with the 992 subnet at remote site. Below are two suggestions. 993 a) If the VPN device being deployed has provision to configure two 994 address pools (as in recommendation above), configure the VPN 995 server with a minimum of two distinct IP address pools. 996 b) Deploy a minimum of two VPN servers with different address pools. 997 By doing this, a VPN client that detected the conflict of VIP 998 address with the subnet at remote site has the option to switch to 999 alternate VPN server and eliminate VIP address conflict. 1001 Recommendation-9. When "Split VPN" is configured on the VPN server, 1002 enterprises deploying remote access VPN servers should allocate 1003 global IP addresses for the critical servers the remote VPN clients 1004 typically need to access. 1006 4. Security Considerations 1008 This document does not inherently create new security issues. 1009 Security issues known to DHCP servers and NAT devices are 1010 applicable, but not within the scope of this document. Likewise, 1011 security issues specific to remote access VPN devices are also 1012 appliable to the remote access VPN topology, but not within the 1013 scope of this document. The security issues reviewed here only 1014 those relevant to the topologies described in sections 2 and 3, 1015 specifcally as they apply to private address space overlap in the 1016 topologies described. 1018 Mistaken end host identity is a security concern present in both 1019 topologies discussed. Mistaken end host identity, described in 1020 sections 2.2.4 and 3.2.4 for each of the topologies reviewed, 1021 essentially points the possibility of application services being 1022 hijacked by the wrong application server (ex: Mail server). Security 1023 violation due to mistaken end host identity arises principally due 1024 to critical servers being assigned RFC 1918 private addresses. The 1025 recommendation suggested for both scenarios is to assign globally 1026 unique pulic IP addresses for the critical servers. 1028 It is also recommended in section 2.1.2 that applications adapt 1029 end-to-end authentication and not depend on source IP address for 1030 authentication. Doing this will thwart connection hijacking and 1031 denial of service attacks. 1033 5. Acknowledgements 1035 The authors wish to thank Dan Wing for reviewing the document in 1036 detail and making helpful suggestions in reorganizing the 1037 document format. 1039 6. Normative References 1041 [BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and Guha, S., 1042 "NAT Behavioral Requirements for ICMP Protocol", 1043 draft-ietf-behave-nat-icmp-01.txt (Work In Progress), 1044 October 2006. 1046 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and 1047 Srisuresh, P., "NAT Behavioral Requirements for TCP", 1048 draft-ietf-behave-nat-tcp-02.txt (Work In Progress), 1049 October 2006. 1051 [BEH-UDP] Audet, F. and Jennings, C., "NAT Behavioral Requirements 1052 for Unicast UDP", draft-ietf-behave-nat-udp-08.txt (Work 1053 In Progress), October 2006. 1055 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator 1056 (NAT) Terminology and Considerations", RFC 2663, August 1057 1999. 1059 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address 1060 Translator (Traditional NAT)", RFC 3022, January 2001. 1062 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and 1063 Lear, E., "Address Allocation for Private Internets", BCP 5, 1064 RFC 1918, February 1996. 1066 7. Informational References 1068 [NAT-PROT] Holdrege, M., and Srisuresh, P., "Protocol Complications 1069 with the IP Network Address Translator", RFC 3027, 1070 January 2001. 1072 [P2P-STATE] Srisuresh, P., Ford, B., and Kegel, D., "State of Peer-to- 1073 Peer(P2P) Communication Across Network Address Translators 1074 (NATs)", draft-ietf-behave-p2p-state-00.txt, 1075 October 2006, Work in Progress. 1077 Authors' Addresses: 1079 Pyda Srisuresh 1080 Consultant 1081 20072 Pacifica Dr. 1082 Cupertino, CA 95014 1083 U.S.A. 1084 Phone: (408) 836-4773 1085 E-mail: srisuresh@yahoo.com 1087 Bryan Ford 1088 Computer Science and Artificial Intelligence Laboratory 1089 Massachusetts Institute of Technology 1090 77 Massachusetts Ave. 1091 Cambridge, MA 02139 1092 U.S.A. 1093 Phone: (617) 253-5261 1094 E-mail: baford@mit.edu 1095 Web: http://www.brynosaurus.com/ 1097 Intellectual Property Statement 1099 The IETF takes no position regarding the validity or scope of any 1100 Intellectual Property Rights or other rights that might be claimed to 1101 pertain to the implementation or use of the technology described in 1102 this document or the extent to which any license under such rights 1103 might or might not be available; nor does it represent that it has 1104 made any independent effort to identify any such rights. Information 1105 on the procedures with respect to rights in RFC documents can be 1106 found in BCP 78 and BCP 79. 1108 Copies of IPR disclosures made to the IETF Secretariat and any 1109 assurances of licenses to be made available, or the result of an 1110 attempt made to obtain a general license or permission for the use of 1111 such proprietary rights by implementers or users of this 1112 specification can be obtained from the IETF on-line IPR repository at 1113 http://www.ietf.org/ipr. 1115 The IETF invites any interested party to bring to its attention any 1116 copyrights, patents or patent applications, or other proprietary 1117 rights that may cover technology that may be required to implement 1118 this standard. Please address the information to the IETF at 1119 ietf-ipr@ietf.org. 1121 Full Copyright Statement 1123 Copyright (C) The Internet Society (2006). 1125 This document is subject to the rights, licenses and restrictions 1126 contained in BCP 78, and except as set forth therein, the authors 1127 retain all their rights. 1129 This document and the information contained herein are provided on 1130 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1131 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1132 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1133 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1134 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1135 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1136 PARTICULAR PURPOSE.