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