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