idnits 2.17.1 draft-iab-nat-implications-08.txt: -(74): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(105): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(352): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(567): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1136): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 22 instances of lines with non-ascii characters in the document. 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8685 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 12 looks like a reference -- Missing reference section? '2' on line 411 looks like a reference -- Missing reference section? '3' on line 189 looks like a reference -- Missing reference section? '4' on line 125 looks like a reference -- Missing reference section? '5' on line 126 looks like a reference -- Missing reference section? '6' on line 159 looks like a reference -- Missing reference section? '7' on line 1011 looks like a reference -- Missing reference section? '8' on line 308 looks like a reference -- Missing reference section? '9' on line 432 looks like a reference -- Missing reference section? '10' on line 545 looks like a reference -- Missing reference section? '11' on line 545 looks like a reference -- Missing reference section? '12' on line 833 looks like a reference -- Missing reference section? 'RFC 1752' on line 989 looks like a reference -- Missing reference section? '14' on line 1014 looks like a reference -- Missing reference section? '15' on line 1037 looks like a reference -- Missing reference section? '16' on line 1054 looks like a reference -- Missing reference section? '17' on line 1054 looks like a reference -- Missing reference section? '18' on line 1054 looks like a reference -- Missing reference section? '19' on line 1059 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB T. Hain 2 Internet Draft Microsoft 3 Document: draft-iab-nat-implications-08.txt July 2000 4 Category: Informational 6 Architectural Implications of NAT 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 "This memo provides information for the Internet community. This 27 memo does not specify an Internet standard of any kind. Distribution 28 of this memo is unlimited." 30 Abstract 32 In light of the growing interest in, and deployment of network 33 address translation (NAT) RFC-1631, this paper will discuss some of 34 the architectural implications and guidelines for implementations. 35 It is assumed the reader is familiar with the address translation 36 concepts presented in RFC-1631. 38 Hain Informational - Expires December 2000 1 39 Table of Contents 40 Abstract............................................................1 41 1. Introduction....................................................3 42 2. Terminology.....................................................5 43 3. Scope...........................................................7 44 4. End-to-End Model................................................7 45 5. Advantages of NATs..............................................9 46 6. Problems with NATs.............................................11 47 7. Illustrations..................................................13 48 7.1 Single point of failure.......................................13 49 7.2. ALG complexity..............................................14 50 7.3. TCP state violations.........................................15 51 7.4. Symmetric state management..................................16 52 7.5. Need for a globally unique FQDN when advertising public 53 services..........................................................17 54 7.6. L2TP tunnels increase frequency of address collisions.......18 55 7.7. Centralized data collection system report correlation.......19 56 8. IPv6...........................................................19 57 9. Security Considerations........................................21 58 10. Deployment Guidelines.........................................23 59 11. Summary.......................................................24 60 12. References....................................................25 61 13. Acknowledgments...............................................27 62 14. Author�s Addresses............................................27 64 Hain Informational - Expires December 2000 2 65 1. Introduction 67 Published in May 1994, written by K. Egevang and P. Francis, RFC- 68 1631 [2] defined NAT as one means to ease the growth rate of IPv4 69 address use. But the authors were worried about the impact of this 70 technology. Several places in the document they pointed out the need 71 to experiment and see what applications may be adversely affected by 72 NAT�s header manipulations, even before there was any significant 73 operational experience. This is further evidenced in a quote from 74 the conclusions: �NAT has several negative characteristics that make 75 it inappropriate as a long term solution, and may make it 76 inappropriate even as a short term solution.� 78 Now, six years later and in spite of the prediction, the use of NATs 79 is becoming widespread in the Internet. Some people are proclaiming 80 NAT as both the short and long term solution to some of the 81 Internet�s address availability issues and questioning the need to 82 continue the development of IPv6. The claim is sometimes made that 83 NAT "just works" with no serious effects except on a few legacy 84 applications. At the same time others see a myriad of difficulties 85 caused by the increasing use of NAT. 87 The arguments pro & con frequently take on religious tones, with 88 each side passionate about its position. 89 - Proponents bring enthusiasm and frequently cite the most popular 90 applications of Mail & Web services as shining examples of NAT 91 transparency. They will also point out that NAT is the feature 92 that finally breaks the semantic overload of the IP address as 93 both a locator and the global endpoint identifier (EID). 94 - An opposing view of NAT is that of a malicious technology, a weed 95 which is destined to choke out continued Internet development. 96 While recognizing there are perceived address shortages, the 97 opponents of NAT view it as operationally inadequate at best, 98 bordering on a sham as an Internet access solution. 99 Reality lies somewhere in between these extreme viewpoints. 101 In any case it is clear NAT affects the transparency of end-to-end 102 connectivity for transports relying on consistency of the IP header, 103 and for protocols which carry that address information in places 104 other than the IP header. Using a patchwork of consistently 105 configured application specific gateways (ALG�s), endpoints can work 106 around some of the operational challenges of NAT. These operational 107 challenges vary based on a number of factors including network and 108 application topologies and the specific applications in use. It can 109 be relatively easy to deal with the simplest case, with traffic 110 between two endpoints running over an intervening network with no 111 parallel redundant NAT devices. But things can quickly get quite 112 complicated when there are parallel redundant NAT devices, or where 113 there are more distributed and multi-point applications like multi- 114 party document sharing. The complexity of coordinating the updates 115 necessary to work around NAT grows geometrically with the number of 117 Hain Informational - Expires December 2000 3 118 endpoints. In a large environment, this may require concerted effort 119 to simultaneously update all endpoints of a given application or 120 service. 122 The architectural intent of NAT is to divide the Internet into 123 independent address administrations, (also see "address realms", 124 RFC-2663 [3]) specifically facilitating casual use of private 125 address assignments RFC-1918 [4]. As noted by Carpenter, et al RFC- 126 2101 [5], once private use addresses were deployed in the network, 127 addresses were guaranteed to be ambiguous. For example, when NATs 128 are inserted into the network, the process of resolving names to or 129 from addresses becomes dependent on where the question was asked. 130 The result of this division is to enforce a client/server 131 architecture (vs. peer/peer) where the servers need to exist in the 132 public address realm. 134 A significant factor in the success of the Internet is the 135 flexibility derived from a few basic tenets. Foremost is the End-to- 136 End principle (discussed further below), which notes that certain 137 functions can only be performed in the endpoints, thus they are in 138 control of the communication, and the network should be a simple 139 datagram service that moves bits between these points. Restated, the 140 endpoint applications are often the only place capable of correctly 141 managing the data stream. Removing this concern from the lower layer 142 packet-forwarding devices streamlines the forwarding process, 143 contributing to system-wide efficiency. 145 Another advantage is that the network does not maintain per 146 connection state information. This allows fast rerouting around 147 failures through alternate paths and to better scaling of the 148 overall network. Lack of state also removes any requirement for the 149 network nodes to notify each other as endpoint connections are 150 formed or dropped. Furthermore, the endpoints are not, and need not 151 be, aware of any network components other than the destination, 152 first hop router(s), and an optional name resolution service. Packet 153 integrity is preserved through the network, and transport checksums 154 and any address-dependent security functions are valid end-to-end. 156 NAT devices (particularly the NAPT variety) undermine most of these, 157 basic advantages of the end-to-end model, reducing overall 158 flexibility, while often increasing operational complexity and 159 impeding diagnostic capabilities. NAT variants such as RSIP [6] have 160 recently been proposed to address some of the end-to-end concerns. 161 While these proposals may be effective at providing the private node 162 with a public address (if ports are available), they do not 163 eliminate several issues like network state management, upper layer 164 constraints like TCP_TIME_WAIT state, or well-known-port sharing. 165 Their port multiplexing variants also have the same DNS limitations 166 as NAPT, and each host requires significant stack modifications to 167 enable the technology (see below). 169 It must be noted that firewalls also break the end-to-end model and 170 raise several of the same issues that NAT devises do, while adding a 172 Hain Informational - Expires December 2000 4 173 few of their own. But one operational advantage with firewalls is 174 that they are generally installed into networks with the explicit 175 intent to interfere with traffic flow, so the issues are more likely 176 to be understood or at least looked at if mysterious problems arise. 177 The same issues with NAT devices can sometimes be overlooked since 178 NAT devices are frequently presented as transparent to applications. 180 One thing that should be clearly stated up front is, that attempts 181 to use a variant of NAT as a simple router replacement may create 182 several significant issues that should be addressed before 183 deployment. The goal of this document is to discuss these with the 184 intent to raise awareness. 186 2. Terminology 188 Recognizing that many of these terms are defined in detail in RFC 189 2663 [3], the following are summaries as used in this document. 191 NAT - Network Address Translation in simple form is a method by 192 which IP addresses are mapped from one address administration to 193 another. The NAT function is unaware of the applications traversing 194 it, as it only looks at the IP headers. 196 ALG - Application Layer Gateway: inserted between application peers 197 to simulate a direct connection when some intervening protocol or 198 device prevents direct access. It terminates the transport 199 protocol, and may modify the data stream before forwarding. 201 NAT/ALG - combines ALG functions with simple NAT. Generally more 202 useful than pure NAT, because it embeds components for specific 203 applications that would not work through a pure NAT. 205 DNS/ALG � a special case of the NAT/ALG, where an ALG for the DNS 206 service interacts with the NAT component to modify the contents of a 207 DNS response. 209 Firewall - access control point that may be a special case of an 210 ALG, or routing filter. 212 Proxy - Special case of an ALG that is a simple relay service 213 designed into a protocol, rather than arbitrarily inserted. 215 Static NAT - provides stable one-to-one mapping between address 216 spaces. 218 Dynamic NAT - provides dynamic mapping between address spaces 219 normally used with a relatively large number of addresses on one 220 side (private space) to a few addresses on the other (public space). 222 NAPT - Network Address Port Translation accomplishes translation by 223 multiplexing transport level identifiers of multiple addresses from 224 one side, simultaneously into the transport identifiers of a single 226 Hain Informational - Expires December 2000 5 227 address on the other. See 4.1.2 of RFC-2663. This permits multiple 228 endpoints to share and appear as a single IP address. 230 RSIP - Realm Specific IP allows endpoints to acquire and use the 231 public address and port number at the source. It includes mechanisms 232 for the private node to request multiple resources at once. RSIP 233 clients must be aware of the address administration boundaries, 234 which specific administrative area its peer resides in for each 235 application, and the topology for reaching the peer. To complete a 236 connection, the private node client requests one or more addresses 237 and/or ports from the appropriate RSIP server, then initiates a 238 connection via that RSIP server using the acquired public resources. 239 Hosts must be updated with specific RSIP software to support the 240 tunneling functions. 242 VPN - For purposes of this document, Virtual Private Networks 243 technically treat an IP infrastructure as a multiplexing substrate, 244 allowing the endpoints to build virtual transit pathways, over which 245 they run another instance of IP. Frequently the 2nd instance of IP 246 uses a different set of IP addresses. 248 AH - IP Authentication Header, RFC-2401 [7], which provides data 249 integrity, data origin authentication, and an optional anti-replay 250 service. 252 ESP - Encapsulating Security Payload protocol, RFC 2401, may provide 253 data confidentiality (encryption), and limited traffic flow 254 confidentiality. It also may provide data integrity, data origin 255 authentication, and an anti-replay service. 257 Address administration - coordinator of an address pool assigned to 258 a collection of routers and end systems. 260 Addressing realm � a collection of routers and end systems 261 exchanging locally unique location knowledge. (Further defined in 262 RFC-2663 NAT Terminology). NAT is used a means to distribute address 263 allocation authority and provide a mechanism to map addresses from 264 one address administration into those of another administration. 266 Hain Informational - Expires December 2000 6 267 3. Scope 269 In discussing the architectural impact of NATs on the Internet, the 270 first task is defining the scope of the Internet. The most basic 271 definition is; a concatenation of networks built using IETF defined 272 technologies. This simple description does not distinguish between 273 the public network known as the Internet, and the private networks 274 built using the same technologies (including those connected via 275 NAT). Rekhter, et al in RFC-1918 defined hosts as public when they 276 need network layer access outside the enterprise, using a globally 277 unambiguous address. Those that need limited or no access are 278 defined as private. Another way to view this is in terms of the 279 transparency of the connection between any given node and the rest 280 of the Internet. 282 The ultimate resolution of public or private is found in the intent 283 of the network in question. Generally, networks that do not intend 284 to be part of the greater Internet will use some screening 285 technology to insert a barrier. Historically barrier devices between 286 the public and private networks were known as Firewalls or 287 Application Gateways, and were managed to allow approved traffic 288 while blocking everything else. Increasingly, part of the screening 289 technology is a NAT, which manages the network locator between the 290 public and private-use address spaces, and then, using ALGs adds 291 support for protocols that are incompatible with NAT. (Use of NAT 292 within a private network is possible, and is only addressed here in 293 the context that some component of the private network is used as a 294 common transit service between the NAT attached stubs.) 296 RFC-1631 limited the scope of NAT discussions to stub appendages of 297 a public Internet, that is, networks with a single connection to the 298 rest of the Internet. The use of NAT in situations in which a 299 network has multiple connections to the rest of the Internet is 300 significantly more complex than when there is only a single 301 connection since the NATs have to be coordinated to ensure that they 302 have a consistent understanding of address mapping for each 303 individual device. 305 4. End-to-End Model 307 The concept of the End-to-End model is reviewed by Carpenter in 308 Internet Transparency [8]. One of the key points is "state should 309 be maintained only in the endpoints, in such a way that the state 310 can only be destroyed when the endpoint itself breaks"; this is 311 termed "fate-sharing". The goal behind fate-sharing is to ensure 312 robustness. As networks grow in size, likelihood of component 313 failures affecting a connection becomes increasingly frequent. If 314 failures lead to loss of communication, because key state is lost, 315 then the network becomes increasingly brittle, and its utility 316 degrades. However, if an endpoint itself fails, then there is no 317 hope of subsequent communication anyway. Therefore the End-to-End 318 model argues that as much as possible, only the endpoints should 319 hold critical state. 321 Hain Informational - Expires December 2000 7 322 For NATs, this aspect of the End-to-End model translates into the 323 NAT becoming a critical infrastructure element: if it fails, all 324 communication through it fails, and, unless great care is taken to 325 assure consistent, stable storage of its state, even when it 326 recovers the communication that was passing through it will still 327 fail (because the NAT no longer translates it using the same 328 mappings). Note that this latter type of failure is more severe 329 than the failure of a router; when a router recovers, any 330 communication that it had been forwarding previous can continue to 331 be successfully forwarded through it. 333 There are other important facets to the End-to-End model: 334 - when state is held in the interior of the network, then traffic 335 dependent on that state cannot be routed around failures unless 336 somehow the state is replicated to the fail-over points, which can 337 be very difficult to do in a consistent yet efficient and timely 338 fashion. 339 - a key principle for scaling networks to large size is to push 340 state-holding out to the edges of the network. If state is held 341 by elements in the core of the network, then as the network grows 342 the amount of state the elements must holds likewise grows. The 343 capacities of the elements can become severe chokepoints and the 344 number of connections affected by a failure also grows. 345 - if security state must be held inside the network (see the 346 discussion below), then the possible trust models the network can 347 support become restricted. 348 A network for which endpoints need not trust network service 349 providers has a great deal more security flexibility than one which 350 does. (Picture, for example, a business traveler connecting from 351 their hotel room back to their home office: should they have to 352 trust the hotel�s networking staff with their security keys?, or the 353 staff of the ISP that supplies the hotel with its networking 354 service? How about when the traveler connects over a wireless 355 connection at an airport?) 356 Related to this, RFC-2101 notes: 357 Since IP Security authentication headers assume that the addresses 358 in the network header are preserved end-to-end, it is not clear 359 how one could support IP Security-based authentication between a 360 pair of hosts communicating through either an ALG or a NAT. 362 In addition, there are distributed applications that assume that IP 363 addresses are globally scoped, globally routable, and all hosts and 364 applications have the same view of those addresses. Indeed, a 365 standard technique for such applications to manage their additional 366 control and data connections is for one host to send to another the 367 address and port that the second host should connect to. NATs break 368 these applications. Similarly, there are other applications that 369 assume that all upper layer ports from a given IP address map to the 370 same endpoint, and port multiplexing technologies like NAPT and RSIP 371 break these. For example, a web server may desire to associate a 372 connection to port 80 with one to port 443, but due to the possible 374 Hain Informational - Expires December 2000 8 375 presence of a NATPT, the same IP address no longer ensures the same 376 host. 378 Limiting such applications is not a minor issue: much of the success 379 of the Internet today is due to the ease with which new applications 380 can run on endpoints without first requiring upgrades to 381 infrastructure elements. If new applications must have the NATs 382 upgraded in order to achieve widespread deployment, then rapid 383 deployment is hindered, and the pace of innovation slowed. 385 5. Advantages of NATs 387 A quick look at the popularity of NAT as a technology shows that it 388 tackles several real world problems. 390 - By masking the address changes that take place, from either dial- 391 access or provider changes, minimizes impact on the local network 392 by avoiding renumbering. 393 - Globally routable addresses can be reused for intermittent access 394 customers. This pushes the demand for addresses towards the number 395 of active nodes rather than the total number of nodes. 396 - There is a potential that ISP provided and managed NATs would 397 lower support burden since there could be a consistent, simple 398 device with a known configuration at the customer end of an access 399 interface. 400 - Breaking the Internet into a collection of address authorities 401 limits the need for continual justification of allocations allows 402 network managers to avoid the use of more advanced routing 403 techniques such as variable length subnets. 404 - Changes in the hosts may not be necessary for applications that 405 don�t rely on the integrity of the packet header, or carry IP 406 addresses in the payload. 407 - Like route filtering Firewalls, NAPT, & RSIP block inbound 408 connections to all ports until they are administratively mapped. 410 Taken together these explain some of the strong motivations for 411 moving quickly with NAT deployment. Traditional NAT [2] provides a 412 relatively simple function that is easily understood. 414 Removing hosts that are not currently active lowers address demands 415 on the public Internet. In cases where providers would otherwise end 416 up with address allocations that could not be aggregated, this 417 improves the load on the routing system as well as lengthens the 418 lifetime of the IPv4 address space. While reclaiming idle addresses 419 is a natural byproduct of the existing dynamic allocation, dial- 420 access devices, in the dedicated connection case this service could 421 be provided through a NAT. In the case of a NAPT, the aggregation 422 potential is even greater as multiple end systems share a single 423 public address. 425 Hain Informational - Expires December 2000 9 426 By reducing the potential customer connection options and minimizing 427 the support matrix, it is possible that ISP provided NATs would 428 lower support costs. 430 Part of the motivation for NAT is to avoid the high cost of 431 renumbering inherent in the current IPv4 Internet. Guidelines for 432 the assignment of IPv4 addresses RFC-2050 [9] mean that ISP 433 customers are currently required to renumber their networks if they 434 want to switch to a new ISP. Using a NAT (or a firewall with NAT 435 functions) means that only the Internet facing IP addresses must be 436 changed and internal network nodes do not need to be reconfigured. 437 Localizing address administration to the NAT minimizes renumbering 438 costs, and simultaneously provides for a much larger local pool of 439 addresses than is available under current allocation guidelines. 440 (The registry guidelines are intended to prolong the lifetime of the 441 IPv4 address space and manage routing table growth, until IPv6 is 442 ready or new routing technology reduces the pressure on the routing 443 table. This is accomplished by managing allocations to match actual 444 demand and to enforce hierarchical addressing. An unfortunate 445 byproduct of the current guidelines is that they may end up 446 hampering growth in areas where it is difficult to sort out real 447 need from potential hoarding.) NAT is effective at masking provider 448 switching or other requirements to change addresses, thus mitigates 449 some of the growth issues. 451 NAT deployments have been raising the awareness of protocol 452 designers who are interested in ensuring that their protocols work 453 end-to-end. Breaking the semantic overload of the IP address will 454 force applications to find a more appropriate mechanism for endpoint 455 identification and discourage carrying the locator in the data 456 stream. Since this will not work for legacy applications, RFC-1631 457 discusses how to look into the packet and make NAT transparent to 458 the application (ie: create an application gateway). This may not be 459 possible for all applications (such as IP based authentication in 460 SNMPv3), and even with application gateways in the path it may be 461 necessary to modify each end host to be aware when there are 462 intermediaries modifying the data. 464 Another popular practice is hiding a collection of hosts that 465 provide a combined service behind a single IP address (ie: web host 466 load sharing). In many implementations this is architecturally a 467 NAT, since the addresses are mapped to the real destination on the 468 fly. When packet header integrity is not an issue, this type of 469 virtual host requires no modifications to the remote applications 470 since the end client is unaware of the mapping activity. While the 471 virtual host has the CPU performance characteristics of the total 472 set of machines, the processing and I/O capabilities of the NAT/ALG 473 device bound the overall performance as it funnels the packets back 474 and forth. 476 Hain Informational - Expires December 2000 10 477 6. Problems with NATs 479 - NATs break the flexible end-to-end model of the Internet. 480 - NATs create a single point where fates are shared, in the device 481 maintaining connection state and dynamic mapping information. 482 - NATs complicate the use of multi-homing by a site in order to 483 increase the reliability of their Internet connectivity. 484 (While single routers are a point of fate sharing, the lack of 485 state in a router makes creating redundancy trivial. Indeed, this 486 is on of the reasons why the Internet protocol suite developed 487 using a connectionless datagram service as its network layer.) 488 - NATs inhibit implementation of security at the IP level. 489 - NATs enable casual use of private addresses. These uncoordinated 490 addresses are subject to collisions when companies using these 491 addresses merge or want to directly interconnect using VPNs. 492 - NATs facilitate concatenating existing private name spaces with 493 the public DNS. 494 - Port versions (NAPT and RSIP) increase operational complexity when 495 publicly published services reside on the private side. 496 - NATs invalidate the authentication mechanism of SNMPv3. 497 - Products may embed a NAT function without identifying it as such. 499 By design, NATs impose limitations on flexibility. As such, 500 extended thought about the introduced complications is called for. 501 This is especially true for products where the NAT function is a 502 hidden service, such as load balancing routers that re-write the IP 503 address to other public addresses. Since the addresses may be all in 504 publicly administered space these are rarely recognized as NATs, but 505 they break the integrity of the end-to-end model just the same. 507 NATs place constraints on the deployment of applications that carry 508 IP addresses (or address derivatives) in the data stream, and they 509 operate on the assumption that each session is independent. 510 However, there are applications such as FTP and H.323 that use one 511 or more control sessions to set the characteristics of the follow-on 512 sessions in their control session payload. Other examples include 513 SNMP MIBs for configuration, and COPS policy messages. Applications 514 or protocols like these assume end-to-end integrity of addresses and 515 will fail when traversing a NAT. (TCP was specifically designed to 516 take advantage of, and reuse, the IP address in combination with its 517 ports for use as a transport address.) To fix how NATs break such 518 applications, an Application Level Gateway needs to exist within or 519 alongside each NAT. An additional gateway service is necessary for 520 each application that may imbed an address in the data stream. The 521 NAT may also need to assemble fragmented datagrams to enable 522 translation of the application stream, and then adjust TCP sequence 523 numbers, prior to forwarding. 525 As noted earlier, NATs break the basic tenet of the Internet that 526 the endpoints are in control of the communication. The original 527 design put state control in the endpoints so there would be no other 528 inherent points of failure. Moving the state from the endpoints to 529 specific nodes in the network reduces flexibility, while it 531 Hain Informational - Expires December 2000 11 532 increases the impact of a single point failure. See further 533 discussion in Illustration 1 below. 535 In addition, NATs are not transparent to all applications, and 536 managing simultaneous updates to a large array of ALGs may exceed 537 the cost of acquiring additional globally routable addresses. See 538 further discussion in Illustration 2 below. 540 While RSIP addresses the transparency and ALG issues, for the 541 specific case of an individual private host needing public access, 542 there is still a node with state required to maintain the 543 connection. Dynamic NAT and RSIP will eventually violate higher 544 layer assumptions about address/port number reuse as defined in RFC- 545 793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is 546 specifically designed to prevent replay of packets between the 4- 547 tuple of IP and port for a given IP address pair. Since the TCP 548 state machine of a node is unaware of any previous use of RSIP, its 549 attempt to connect to the same remote service that its neighbor just 550 released (which is still in TCP_TIME_WAIT) may fail, or with a 551 larger sequence number may open the prior connection directly from 552 TCP_TIME_WAIT state, at the loss of the protection afforded by the 553 TCP_TIME_WAIT state. 555 For address translators (which do not translate ports) to comply 556 with the TCP_TIME_WAIT requirements, they must refrain from 557 assigning the same address to a different host until a period of 558 2*MSL has elapsed since the last use of the address, where MSL is 559 the Maximum Segment Lifetime defined in RFC-793 as two minutes. For 560 address-and-port translators to comply with this requirement, they 561 similarly must refrain from assigning the same host/port pair until 562 2*MSL has elapsed since the end of its first use. While these 563 requirements are simple to state, they can place a great deal of 564 pressure on the NAT, because they temporarily reduce the pool of 565 available addresses and ports. Consequently, it will be tempting or 566 NAT implementers to ignore or shorten the TCP_TIME_WAIT 567 requirements, at the cost of some of TCP�s strong reliability. Note 568 that in the case where the strong reliability is in fact compromised 569 by the appearance of an old packet, the failure can manifest itself 570 as the receiver accepting incorrect data. See further discussion in 571 Illustration 3 below. 573 It is sometimes argued that NATs simply function to facilitate 574 "routing realms", where each domain is responsible for finding 575 addresses within its boundaries. Such a viewpoint clouds the 576 limitations created by NAT with the better-understood need for 577 routing management. Compartmentalization of routing information is 578 correctly a function of routing protocols and their scope of 579 application. NAT is simply a means to distribute address allocation 580 authority and provide a mechanism to map addresses from one address 581 realm into those of another realm. 583 In particular, it is sometimes erroneously believed that NATs serve 584 to provide routing isolation. In fact, if someone were to define an 586 Hain Informational - Expires December 2000 12 587 OSPF ALG it would actually be possible to route across a NAT 588 boundary. Rather than NAT providing the boundary, it is the 589 experienced operators who know how to limit network topology that 590 serve to avoid leaking addresses across a NAT. This is an 591 operational necessity given the potential for leaked addresses to 592 introduce inconsistencies into the public infrastructure. 594 One of the greatest concerns from the explosion of NATs is the 595 impact on the fledgling efforts at deploying network layer end-to- 596 end IP security. One fundamental issue for IPSec is that with both 597 AH and ESP, the authentication check covers the TCP/UDP checksum 598 (which in turn covers the IP address). When a NAT changes the IP 599 address, the checksum calculation will fail, and therefore 600 authentication is guaranteed to fail. Attempting to use the NAT as a 601 security boundary fails when requirement is end-to-end network layer 602 encryption, since only the endpoints have access to the keys. See 603 further discussion in Illustration 4 below. 605 Finally, while the port multiplexing variants of NAT (popular 606 because they allow Internet access through a single address) work 607 modestly well for connecting private hosts to public services, they 608 create management problems for applications connecting from public 609 toward private. The concept of a well-known port is undermined 610 because only one private side system can be mapped through the 611 single public-side port number. This will affect home networks, when 612 applications like multi-player Internet games can only be played on 613 one system at a time. It will also affect small businesses when only 614 one system at a time can be operated on the standard port to provide 615 web services. These may sound like only medium-grade restrictions 616 for the present, but as a basic property of the Internet, not to 617 change years into the future, it is highly undesirable. The issue is 618 that the public toward private usage requires administrative mapping 619 for each target prior to connection. If the ISP chooses to provide 620 a standardized version of these to lower configuration options, they 621 may find the support costs of managing the ALGs will exceed the cost 622 of additional address space. See further discussion in Illustration 623 6 below. 625 7. Illustrations 627 7.1 Single point of failure 628 A characteristic of stateful devices like NATs is the creation of a 629 single point of failure. Attempts to avoid this by establishing 630 redundant NATs, creates a new set of problems related to timely 631 communication of the state, and routing related failures. This 632 encompasses several issues such as update frequency, performance 633 impact of frequent updates, reliability of the state update 634 transaction, a-priori knowledge of all nodes needing this state 635 information, and notification to end nodes of alternatives. (This 636 notification could be accomplished with a routing protocol, which 637 might require modifications to the hosts so they will listen.) 639 Hain Informational - Expires December 2000 13 640 -------- -------- 641 | Host A |-----| Host B | 642 -------- | -------- 643 ----------------- 644 | | 645 ------ ------ 646 | AD 1 | | AD 2 | 647 ------ ------ 648 \ / 649 -------- 650 /Internet\ 651 ---------- 653 -------- 654 Illustration 1 656 In the traditional case where Access Device (AD) 1 & 2 are routers, 657 the single point of failure is the end Host, and the only effort 658 needed to maintain the connections through a router or link failure 659 is a simple routing update from the surviving router. In the case 660 where the ADs are a NAT variant there will be connection state 661 maintained in the active path that would need to be shared with 662 alternative NATs. When the Hosts have open connections through 663 either NAT, and it fails, the application connections will drop 664 unless the state had been previously moved to the surviving NAT. 665 The hosts will still need to acquire a routing redirect. In the 666 case of RSIP, the public side address pool would also need to be 667 shared between the ADs to allow movement. This sharing creates 668 another real-time operational complexity to prevent conflicting 669 assignments at connection setup. NAT as a technology creates a 670 point fate sharing outside the endpoints, in direct contradiction to 671 the original Internet design goals. 673 7.2. ALG complexity 674 In the following example of a proposed corporate network, each 675 NAT/ALG was to be one or more devices at each physical location, and 676 there were to be multiple physical locations per diagramed 677 connection. The logistics of simply updating software on this scale 678 is cumbersome, even when all the devices are the same manufacturer 679 and model. While this would also be true with routers, it would be 680 unnecessary for all devices to run a consistent version for an 681 application to work across an arbitrary path. 683 Hain Informational - Expires December 2000 14 684 ---------------------------------------- 685 | Corporate Network | 686 | Asia |------| Americas |------| Europe | 687 ------ ---------- -------- 688 | | | 689 -------- -------- -------- 690 |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| 691 -------- -------- -------- 692 | | | 693 -------------------------------------------- 694 | Internet | 695 -------------------------------------------- 696 | | | 697 -------- -------- -------- 698 |NAT/ALGs| |NAT/ALGs| |NAT/ALGs| 699 -------- -------- -------- 700 | | | 701 ------------------ -------------- ---------------- 702 Home Telecommuters Branch Offices Partner Networks 703 ------------------ -------------- ---------------- 705 -------- 706 Illustration 2 708 7.3. TCP state violations 709 The full range of upper layer architectural assumptions that are 710 broken by NAT technologies may not be well understood without a very 711 large-scale deployment, because it sometimes requires the diversity 712 that comes with large-scale use to uncover unusual failure modes. 713 The following example illustrates an instance of the problem 714 discussed above in section 6. 716 -------- -------- 717 | Host A |-----| Host B | 718 -------- | -------- 719 -------- 720 |NAT/RSIP| 721 -------- 722 | 723 -------- 724 |Internet| 725 -------- 726 | 727 --------- 728 | Web | 729 | Server | 730 --------- 732 -------- 733 Illustration 3 735 Hain Informational - Expires December 2000 15 736 Host A completes its transaction and closes the web service on TCP 737 port 80, and the RSIP releases the public side address used for Host 738 A. Host B attempts to open a connection to the same web service, 739 and the NAT assigns then next free public side address which is the 740 same one A just released. The source port selection rules on Host B 741 happen to lead it to the same choice that A used. The connect 742 request from Host B is rejected because the web server, conforming 743 to the TCP specifications, has that 4-tuple in TIME WAIT for 4 744 minutes. By the time a call from Host B gets through to the 745 helpdesk complaining about no access, the requested retry will work, 746 so the issue is marked as resolved, when it in fact is an on-going, 747 but intermittent, problem. 749 7.4. Symmetric state management 750 Operational management of networks incorporating stateful packet 751 modifying device is considerably easier if inbound and outbound 752 packets traverse the same path. (Otherwise it�s a headache to keep 753 state for the two directions synchronized.) While easy to say, even 754 with careful planning it can be difficult to manage using a 755 connectionless protocol like IP. The problem of creating redundant 756 connections is ensuring that routes advertised to the private side 757 reach the end nodes and map to the same device as the public side 758 route advertisements. This state needs to persist throughout the 759 lifetime of sessions traversing the NAT, in spite of frequent or 760 simultaneous internal and external topology churn. Consider the 761 following case where the -X- links are broken, or flapping. 763 -------- -------- 764 | Host A | | Host B | 765 | Foo | | Bar | 766 -------- -------- 767 | | 768 ---- ---- 769 |Rtr1|---X1---|Rtr2| 770 ---- ---- 771 | | 772 ---- ---- 773 |NAT1| |NAT2| 774 ---- ---- 775 | | 776 -------------- 777 |Rtr Rtr| 778 | / Internet \ | --- 779 |Rtr----X2---Rtr|----|DNS| 780 -------------- --- 781 | | 782 | | 783 -------- -------- 784 | Host C | | Host D | 785 -------- -------- 787 -------- 788 Illustration 4 790 Hain Informational - Expires December 2000 16 791 To preserve a consistent view of routing, the best path to the 792 Internet for Routers 1 & 2 is via NAT1, while the Internet is told 793 the path to the address pool managed by the NATs is best found 794 through NAT1. When the path X1 breaks, Router 2 would attempt to 795 switch to NAT2, but the external return path would still be through 796 NAT1. This is because the NAT1 device is advertising availability of 797 a pool of addresses. Directly connected routers in this same 798 situation would advertise the specific routes that existed after the 799 loss. In this case, redundancy was useless. 801 Consider the case that the path between Router 1 & 2 is up, and some 802 remote link in the network X2 is down. It is also assumed that DNS 803 returns addresses for both NATs when queried for Hosts A or B. When 804 Host D tries to contact Host B, the request goes through NAT2, but 805 due to the internal routing, the reply is through NAT1. Since the 806 state information for this connection is in NAT2, NAT1 will provide 807 a new mapping. Even if the remote path is restored, the connection 808 will not be made because the requests are to the public IP of NAT2, 809 while the replies are from the public IP of NAT1. 811 In a third case, both Host A & B want to contact Host D, when the 812 remote link X2 in the Internet breaks. As long as the path X1 is 813 down, Host B is able to connect, but Host A is cut off. Without a 814 thorough understanding of the remote topology (unlikely since 815 Internet providers tend to consider that sensitive proprietary 816 information), the administrator of Hosts A & B would have no clue 817 why one worked and the other didn�t. As far as he can tell the 818 redundant paths through the NATs are up but only one connection 819 works. Again, this is due to lack of visibility to the topology that 820 is inherent when a stateful device is advertising availability to a 821 pool rather than the actual connected networks. 823 In any network topology, individual router or link failures may 824 present problems with insufficient redundancy, but the state 825 maintenance requirements of NAT present an additional burden that is 826 not as easily understood or resolved. 828 7.5. Need for a globally unique FQDN when advertising public services 829 The primary feature of NATs is the �simple� ability to connect 830 private networks to the public Internet. When the private network 831 exists prior to installing the NAT, it is unlikely and unnecessary 832 that its name resolver would use a registered domain. As noted in 833 RFC 1123 [12] DNS queries may be resolved via local multicast. 834 Connecting the NAT device, and reconfiguring it�s resolver to proxy 835 for all external requests allows access to the public network by 836 hosts on the private network. Configuring the public DNS for the set 837 of private hosts that need inbound connections would require a 838 registered domain (either private, or from the connecting ISP) and a 839 unique name. At this point the partitioned name space is 840 concatenated and hosts would have different names based on inside 841 vs. outside queries. 843 Hain Informational - Expires December 2000 17 844 -------- -------- 845 | Host A | | Host B | 846 | Foo |-----| Bar | 847 -------- | -------- --- 848 |-------------|DNS| 849 --- --- 850 |NAT| 851 --- 852 | 853 -------- --- 854 |Internet|----|DNS| 855 -------- --- 856 | 857 --- 858 |NAT| 859 --- --- 860 |-------------|DNS| 861 -------- | -------- --- 862 | Host C |-----| Host D | 863 | Foo | | Bar | 864 -------- -------- 866 -------- 867 Illustration 5 869 Everything in this simple example will work until an application 870 embeds a name. For example, a Web service running on Host D might 871 present embedded URL�s of the form http://D/bar.html, which would 872 work from Host C, but would thoroughly confuse Host A. If the 873 embedded name resolved to the public address, Host A would be happy, 874 but Host C would be looking for some remote machine. Using the 875 public FQDN resolution to establishing a connection from Host C to 876 D, the NAT would have to look at the destination rather than simply 877 forwarding the packet out to the router. (Normal operating mode for 878 a NAT is translate & forward out the other interface, while routers 879 do not send packets back on the same interface they came from). The 880 NAT did not create the name space fragmentation, but it facilitates 881 attempts to merge networks with independent name administrations. 883 7.6. L2TP tunnels increase frequency of address collisions 884 The recent mass growth of the Internet has been driven by support of 885 low cost publication via the web. The next big push appears to be 886 support of Virtual Private Networks (VPNs) frequently accomplished 887 using L2TP. Technically VPN tunnels treat an IP infrastructure as a 888 multiplexing substrate allowing the endpoints to build what appear 889 to be clear pathways from end-to-end. These tunnels redefine network 890 visibility and increase the likelihood of address collision when 891 traversing multiple NATs. Address management in the private space 892 behind NATs will become a significant burden, as there is no central 893 body capable of, or willing to do it. The lower burden for the ISP 894 is actually a transfer of burden to the local level, because 895 administration of addresses and names becomes both distributed and 896 more complicated. 898 Hain Informational - Expires December 2000 18 899 As noted in RFC-1918, the merging of private address spaces can 900 cause an overlap in address use, creating a problem. L2TP tunnels 901 will increase the likelihood and frequency of that merging through 902 the simplicity of their establishment. There are several 903 configurations of address overlap which will cause failure, but in 904 the simple example shown below the private use address of Host B 905 matches the private use address of the VPN pool used by Host A for 906 inbound connections. When Host B tries to establish the VPN 907 interface, Host A will assign it an address from its pool for 908 inbound connections, and identify the gateway for Host B to use. In 909 the example, Host B will not be able to distinguish the remote VPN 910 gateway address of Host A from its own private address on the 911 physical interface, thus the connection will fail. Since private use 912 addresses are by definition not publicly coordinated, as the 913 complexity of the VPN mesh increases so does the likelihood that 914 there will be a collision that cannot be resolved. 916 --------------- ---------------- 917 | 10.10.10.10 |--------L2TP-------| Assigned by A | 918 | Host A | --- --- | Host B | 919 | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | 920 --------------- --- --- ---------------- 922 -------- 923 Illustration 6 925 7.7. Centralized data collection system report correlation 926 It has been reported that NAT introduces additional challenges when 927 intrusion detection systems attempt to correlate reports between 928 sensors inside and outside the NAT. While the details of individual 929 systems are beyond the scope of this document, it is clear that a 930 centralized system with monitoring agents on both sides of the NAT 931 would also need access to the current NAT mappings to get this 932 right. It would also be critical that the resulting data be indexed 933 properly if there were agents behind multiple NATs using the same 934 address range for the private side. 936 This also applies to management data collected via SNMP. Any time 937 the data stream carries an IP address; the central collector or ALG 938 will need to manipulate the data based on the current mappings in 939 the NAT. 941 8. IPv6 943 It has been argued that IPv6 is no longer necessary because NATs 944 relieve the address space constraints and allow the Internet to 945 continue growing. The reality is they point out the need for IPv6 946 more clearly than ever. People are trying to connect multiple 947 machines through a single access line to their ISP and have been 948 willing to give up some functionality to get that at minimum cost. 950 Hain Informational - Expires December 2000 19 951 Frequently the reason for cost increases is the perceived scarcity 952 (therefore increased value) of IPv4 addresses, which would be 953 eliminated through deployment of IPv6. This crisis mentality is 954 creating a market for a solution to a problem already solved with 955 greater flexibility by IPv6. 957 If NAT had never been defined, the motivation to resolve the 958 dwindling IPv4 address space would be a much greater. Given that 959 NATs are enabling untold new hosts to attach to the Internet daily, 960 it is difficult to ascertain the actual impact to the lifetime of 961 IPv4, but NAT has certainly extended it. It is also difficult to 962 determine the extent of delay NAT is causing for IPv6, both by 963 relieving the pressure, and by redirecting the intellectual cycles 964 away from the longer-term solution. 966 But at the same time NAT functionality may be a critical facilitator 967 in the deployment of IPv6. There are already 100 million or more 968 computers running IPv4 on data networks. Some of these networks are 969 connected to and thus part of the Internet and some are on private 970 isolated networks. It is inconceivable that we could have a "flag 971 day" and convert all of the existing IPv4 nodes to IPv6 at the same 972 time. There will be a very long period of coexistence while both 973 IPv4 and IPv6 are being used in the Internet and in private 974 networks. The original IPv6 transition plan relied heavily on having 975 new IPv6 nodes also be able to run IPv4 - a "dual stack" approach. 976 When the dual stack node looks up another node in the DNS it will 977 get back a IPv4 or an IPv6 address in response. If the response is 978 an IPv4 address then the node uses IPv4 to contact the other node. 979 And if the response is an IPv6 address then IPv6 can be used to make 980 the contact. Turning the NAT into a 6to4 [13]router enables 981 widespread deployment of IPv6 while providing an IPv4 path if IPv6 982 is unavailable. While this maintains the current set of issues for 983 IPv4 connections, it reestablishes the end-to-end principle for IPv6 984 connections. 986 An alternative methodology would be to translate the packets between 987 IPv6 and IPv4 at the boarders between IPv4 supporting networks and 988 IPv6 supporting networks. The need for this functionality was 989 recognized in [RFC 1752], the document that recommended to the IETF 990 that IPv6 be developed and recommended that a set of working groups 991 be established to work on a number of specific problems. Header 992 translation (i.e, NAT) was one of those problems. 994 Of course, NATs in an IPv6 to IPv4 translation environment encounter 995 all of the same problems that NATs encounter in a pure IPv4 and the 996 environment and cautions in this document apply to both situations. 998 Hain Informational - Expires December 2000 20 999 9. Security Considerations 1001 NAT (particularly NAPT) actually has the potential to lower overall 1002 security because it creates the illusion of a security barrier, but 1003 does so without the managed intent of a firewall. Appropriate 1004 security mechanisms are implemented in the end host, without 1005 reliance on assumptions about routing hacks, firewall filters, or 1006 missing NAT translations, which may change over time to enable a 1007 service to a neighboring host. In general, defined security barriers 1008 assume that any threats are external, leading to practices that make 1009 internal breaches much easier. 1011 IPsec RFC-2401 [7] defines a set of mechanisms to support packet- 1012 level authentication and encryption for use in IP networks. While 1013 this may be less efficient than application-level security but in 1014 the words of RFC-1752 [14] "support for basic packet-level 1015 authentication will provide for the adoption of a much needed, 1016 widespread, security infrastructure throughout the Internet." 1018 NATs break IPsec�s authentication and encryption technologies 1019 because these technologies depend on an end-to-end consistency of 1020 the IP addresses in the IP headers, and therefore may stall further 1021 deployment of enhanced security across the Internet. NATs raise a 1022 number of specific issues with IPsec. For example; 1023 - Use of AH is not possible via NAT as the hash protects the IP 1024 address in the header. 1025 - Authenticated certificates may contain the IP address as part of 1026 the subject name for authentication purposes. 1027 - Encrypted Quick Mode structures may contain IP addresses and ports 1028 for policy verifications. 1029 - The Revised Mode of public key encryption includes the peer 1030 identity in the encrypted payload. 1031 It may be possible to engineer and work around NATs for IPsec on a 1032 case-by-case basis, but at the cost of restricting the trust model, 1033 as discussed in section 4 above. With all of the restrictions placed 1034 on deployment flexibility, NATs present a significant obstacle to 1035 security integration being deployed in the Internet today. 1037 As noted in the RFC-2694 [15], the DNS/ALG cannot support secure DNS 1038 name servers in the private domain. Zone transfers between DNSsec 1039 servers will be rejected when necessary modifications are attempted. 1040 It is also the case that DNS/ALG will break any modified, signed 1041 responses. This would be the case for all public side queries of 1042 private nodes, when the DNS server is on the private side. It would 1043 also be true for any private side queries for private nodes, when 1044 the DNS server is on the public side. Digitally signed records could 1045 be modified by the DNS/ALG if it had access to the source 1046 authentication key. DNSsec has been specifically designed to avoid 1047 distribution of this key, to maintain source authenticity. So NATs 1048 that use DNS/ALG to repair the namespace resolutions will either; 1049 break the security when modifying the record, or will require access 1050 to all source keys to requested resolutions. 1052 Hain Informational - Expires December 2000 21 1053 Security mechanisms that do not protect or rely on IP addresses as 1054 identifiers, such as TLS [16], SSL [17], or SSH [18] may operate in 1055 environments containing NATs. For applications that can establish 1056 and make use of this type of transport connection, NATs do not 1057 create any additional complications. These technologies may not 1058 provide sufficient protection for all applications as the header is 1059 exposed, allowing subversive acts like TCP resets. RFC-2385 [19] 1060 discusses the issues in more detail. 1062 Arguments that NATs may operate in a secure mode preclude true End- 1063 to-End security, as the NAT becomes the security endpoint. 1064 Operationally the NAT must be managed as part of the security 1065 domain, and in this mode the packets on the unsecured side of the 1066 NAT are fully exposed. 1068 Hain Informational - Expires December 2000 22 1069 10. Deployment Guidelines 1070 Given that NAT devices are being deployed at a fairly rapid pace, 1071 some guidelines are in order. Most of these cautionary in nature and 1072 are designed to make sure that the reader fully understands the 1073 implications of the use of NATs in their environment. 1074 - Determine the mechanism for name resolution, and ensure the 1075 appropriate answer is given for each address administration. 1076 Embedding the DNS server, or a DNS ALG in the NAT device will 1077 likely be more manageable than trying to synchronize independent 1078 DNS systems across administrations. 1079 - Is the NAT configured for static one to one mappings, or will it 1080 dynamically manage them? If dynamic, make sure the TTL of the DNS 1081 responses is set to 0, and that the clients pay attention to the 1082 don�t cache notification. 1083 - Will there be a single NAT device, or parallel with multiple 1084 paths? If single, consider the impact of a device failure. If 1085 multiple, consider how routing on both sides will insure the 1086 packets flow through the same box over the connection lifetime of 1087 the applications. 1088 - Examine the applications that will need to traverse the NAT and 1089 verify their immunity to address changes. If necessary provide an 1090 appropriate ALG or establish a VPN to isolate the application from 1091 the NAT. 1092 - Determine need for public toward private connections, variability 1093 of destinations on the private side, and potential for 1094 simultaneous use of public side port numbers. NAPTs increase 1095 administration if these apply. 1096 - Determine if the applications traversing the NAPT or RSIP expect 1097 all ports from the public IP address to be the same endpoint. 1098 Administrative controls to prevent simultaneous access from 1099 multiple private hosts will be required if this is the case. 1100 - If there are encrypted payloads, the contents cannot be modified 1101 unless the NAT is a security endpoint, acting as a gateway between 1102 security realms. This precludes end-to-end confidentiality, as the 1103 path between the NAT and endpoint is exposed. 1104 - Determine the path for name resolutions. If hosts on the private 1105 side of a NAPT or RSIP server need visibility to each other, a 1106 private side DNS server may be required. 1107 - If the environment uses secure DNS records, the DNS/ALG will 1108 require access to the source authentication keys for all records 1109 to be translated. 1110 - When using VPNs over NATs, identify a clearinghouse for the 1111 private side addresses to avoid collisions. 1112 - Assure that applications used both internally and externally avoid 1113 embedding names, or use globally unique ones. 1114 - When using RSIP, recognize the scope is limited to individual 1115 private network connecting to the public Internet. If other NATs 1116 are in the path (including web-server load-balancing devices), the 1117 advantage of RSIP (end-to-end address/port pair use) is lost. 1118 - For RSIP, determine the probability of TCP_Time_Wait collisions 1119 when subsequent private side hosts attempt to contact a recently 1120 disconnected public side service. 1122 Hain Informational - Expires December 2000 23 1123 11. Summary 1125 Over the 6-year period since RFC-1631, the experience base has 1126 grown, further exposing concerns raised by the original authors. NAT 1127 breaks a fundamental assumption of the Internet design; the 1128 endpoints are in control. Another design principle, �keep-it-simple� 1129 is being overlooked as more features are added to the network to 1130 work around the complications created by NATs. In the end, overall 1131 flexibility and manageability are lowered, and support costs go up 1132 to deal with the problems introduced. 1134 Evangelists, for and against the technology, present their cases as 1135 righteous while downplaying any rebuttals. 1136 - NATs are a �fact of life�, and will proliferate as an enhancement 1137 that sustains the existing IPv4 infrastructure. 1138 - NATs are a �necessary evil� and create an administrative burden 1139 that is not easily resolved. More significantly, they inhibit the 1140 roll out of IPsec, which will in turn slow growth of applications 1141 that require a secure infrastructure. 1142 In either case, NATs require strong applicability statements, 1143 clearly declaring what works and what does not. 1145 An overview of the pluses and minuses: 1146 NAT advantages NAT disadvantages 1147 -------------------------------- -------------------------------- 1148 Masks global address changes Breaks end-to-end model 1149 Eases renumbering when providers Facilitates concatenation of 1150 change multiple name spaces 1151 Breaks IPsec 1152 Stateful points of failure 1153 Address administrations avoid Requires source specific DNS reply 1154 justifications to registries or DNS/ALG 1155 DNS/ALG breaks DNSsec replies 1156 Lowers address utilization Enables end-to-end address 1157 conflicts 1158 Lowers ISP support burden Increases local support burden and 1159 complexity 1160 Transparent to end systems in some Unique development for each app 1161 cases 1162 Load sharing as virtual host Performance limitations with scale 1163 Delays need for IPv4 replacement May complicate integration of IPv6 1165 There have been many discussions lately about the value of 1166 continuing with IPv6 development when the market place is widely 1167 deploying IPv4 NATs. A shortsighted view would miss the point that 1168 both have a role, because NATs address some real-world issues today, 1169 while IPv6 is targeted at solving fundamental problems, as well as 1170 moving forward. It should be recognized that there will be a long 1171 co-existence as applications and services develop for IPv6, while 1172 the lifetime of the existing IPv4 systems will likely be measured in 1173 decades. NATs are a diversion from forward motion, but they do 1174 enable wider participation at the present state. They also break a 1176 Hain Informational - Expires December 2000 24 1177 class of applications, which creates the need for complex work- 1178 around scenarios. 1180 Efforts to enhance general security in the Internet include IPsec 1181 and DNSsec. These technologies provide a variety of services to both 1182 authenticate and protect information during transit. By breaking 1183 these technologies, NAT and the DNS/ALG work-around, hinder 1184 deployment of enhanced security throughout the Internet. 1186 There have also been many questions about the probability of VPNs 1187 being established that might raise some of the listed concerns. 1188 While it is hard to predict the future, one way to avoid ALGs for 1189 each application is to establish a L2TP over the NATs. This 1190 restricts the NAT visibility to the headers of the tunnel packets, 1191 and removes its effects from all applications. While this solves the 1192 ALG issues, it raises the likelihood that there will be address 1193 collisions as arbitrary connections are established between 1194 uncoordinated address spaces. It also creates a side concern about 1195 how an application establishes the necessary tunnel. 1197 The original IP architecture is powerful because it provides a 1198 general mechanism on which other things (yet unimagined) may be 1199 built. While it is possible to build a house of cards, time and 1200 experience have lead to building standards with more structural 1201 integrity. IPv6 is the long-term solution that retains end-to-end 1202 transparency as a principle. NAT is a technological diversion to 1203 sustain the lifetime of IPv4. 1205 12. References 1207 1 RFC-2026 Bradner, S., " The Internet Standards Process -- 1208 Revision 3", BCP 9, RFC 2026, October 1996. 1210 2 RFC-1631 Egevang, K., Francis, P., "The IP Network Address 1211 Translator", RFC 1631, May 1994 1213 3 RFC-2663, Srisuresh & Holdrege, "NAT Terminology and 1214 Considerations", RFC 2663 August 1999 1216 4 RFC-1918, Rekhter, et al, "Address Allocation for Private 1217 Internets", RFC 1918 February 1996 1219 5 RFC-2101, Carpenter, et al, "IPv4 Address Behavior Today", RFC 1220 2101, February 1997 1222 6 draft-ietf-nat-rsip-protocol-06.txt, M. Borella, D. Grabelsky, 1223 J.lo, K. Tuniguchi, "Realm Specific IP: Protocol Specification", 1224 March 2000 1226 Hain Informational - Expires December 2000 25 1227 7 RFC-2401, Kent & Atkinson, "Security Architecture for IP", 1228 November 1998 1230 8 RFC-2775, Carpenter, "Internet Transparency", February 2000 1232 9 RFC-2050, Hubbard, et. Al., "Internet Registry IP Allocation 1233 Guidelines", November 1996 1235 10 RFC-793, J. Postel, "Transmission Control Protocol", RFC 793, 1236 September 1981 1238 11 RFC-1185, V. Jacobson, R. Braden, L. Zhang, "TCP Extension for 1239 High-Speed Paths", RFC 1185, October 1990 1241 12 RFC-1123, R. Braden, "Requirements for Internet Hosts", RFC 1242 1123, October 1989 1244 13 draft-ietf-ngtrans-6to4-06.txt, B. Carpenter, K. Moore, 1245 "Connection of IPv6 Domains via IPv4 Clouds without Explicit 1246 Tunnels", June 2000 1248 14 RFC-1752, Bradner & Mankin, "Recommendation for IPng", January 1249 1995 1251 15 RFC-2694, Srisuresh, et al., "DNS extensions to NAT", September 1252 1999 1254 16 RFC-2246, T. Dierks, C. Allen, "The TLS Protocol", January 1999 1256 17 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 1258 18 draft-ietf-secsh-architecture-02.txt, T. Ylonen, et al, "SSH 1259 Protocol Architecture", August 1998 1261 19 RFC-2385, A. Heffernan, "Protection of BGP Sessions via the TCP 1262 MD5 Signature Option", RFC 2385, August 1998 1264 Hain Informational - Expires December 2000 26 1265 13. Acknowledgments 1266 Valuable contributions to this draft came from the IAB, Vern Paxson 1267 (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas Narten 1268 (ibm), Yakov Rekhter(cisco), Pyda Srisuresh, Matt Holdrege (lucent), 1269 and Eliot Lear (cisco). 1271 14. Author�s Addresses 1272 Tony Hain 1273 Microsoft 1274 One Microsoft Way Phone: 1-425-703-6619 1275 Redmond, Wa. USA Email: tonyhain@microsoft.com 1277 Hain Informational - Expires December 2000 27