idnits 2.17.1 draft-iab-nat-implications-01.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-25) 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-1631]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 1998) is 9416 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-1631' is mentioned on line 48, but not defined ** Obsolete undefined reference: RFC 1631 (Obsoleted by RFC 3022) == Missing Reference: 'RFC-1918' is mentioned on line 79, but not defined == Missing Reference: 'RFC-2101' is mentioned on line 78, but not defined == Unused Reference: 'RFC 1631' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC 2101' is defined on line 532, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Downref: Normative reference to an Informational RFC: RFC 2101 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB T. Hain, Microsoft 2 Internet Draft 3 Document: draft-iab-nat-implications-01.txt July 1998 5 Architectural Implications of NAT 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet- Drafts as 17 reference material or to cite them other than as "work in progress." 19 To view the entire list of current Internet-Drafts, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 22 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 23 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 25 A revised version of this draft document will be submitted to the 26 RFC editor as an Informational RFC for the Internet Community. 27 Discussion and suggestions for improvement are requested. This 28 document will expire before October 1998. Distribution of this draft 29 is unlimited. 31 Abstract 33 In light of the growing interest in, and deployment of network 34 address translation (NAT) [RFC-1631], this paper will discuss some 35 of the architectural implications and guidelines for 36 implementations. It is assumed the reader is familiar with the 37 address translation concepts presented in [RFC-1631]. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in [RFC-2119]. 45 Hain Informational - Expires January 1999 1 46 Introduction 48 In discussing the architectural impact of NAT's [RFC-1631] on the 49 Internet, the first task is defining the scope of the Internet. The 50 most basic definition is; a concatenation of networks built using 51 IETF defined technologies. This simple description does not 52 distinguish between the public network known as the Internet, and 53 the private networks built using the same technologies. An approach 54 resolving this would be including the resources of Names or 55 Addresses administered through IANA or its delegates. While this is 56 more accurate, it still includes many private networks that have 57 coordinated their names or addresses with the public Internet. 59 Rekhter, et al [RFC-1918] defined hosts as public when they need 60 network layer access outside the enterprise, using a globally 61 unambiguous address. Those that need limited or no access are 62 defined as private. Another way to view this is the transparency of 63 the connection between any given node and the rest of the Internet. 64 True transparency could be stated as; an unambiguous locator known 65 by a node and identifiable by any other node participating in the 66 public Internet, with no restrictions on packet delivery. 68 The ultimate resolution of public or private is found in the intent 69 of the network in question. Generally networks that use coordinated 70 names and addresses, but do not intend to be part of the greater 71 Internet will use some screening technology to insert a barrier. 72 Historically barrier devices between the public and private networks 73 were known as Firewalls or Application Gateways, and were managed to 74 allow approved traffic while blocking everything else. Increasingly 75 the screening technology is becoming a simple NAT, which manages the 76 network locator between the public and private use address spaces. 78 As noted by Carpenter, et al [RFC-2101], once private use addresses 79 [RFC-1918] were deployed in the network, addresses were guaranteed 80 to be ambiguous. At the same time when NAT's were attached to the 81 network, the process of resolving names to or from addresses gained 82 a dependency on where the question was asked; thus both names and 83 addresses became globally ambiguous. As private use addresses are by 84 definition not part of the public infrastructure, and an unambiguous 85 locator is required within a routing realm, NAT's are clearly left 86 sitting at the boundary of the Internet. Here they become another 87 screening technology for connecting private networks. 89 In one view, NAT is the feature which finally breaks the semantic 90 overload of the IP address as both a locator and the end point 91 identifier (EID). Another view of NAT is that of 'necessary evil', 92 where there is a real concern that the technology is the weed which 93 is destined to choke out continued development. In either case, 94 there is no direct impact on the public Internet, since NAT's sit at 95 the boundary. This leaves the discussion focused on the impact on 96 end-to-end communications between hosts that use the public Internet 97 as a transport medium. 99 Hain Informational - Expires January 1999 2 100 Terminology 102 Locator - the address within a packet directing its delivery within 103 a routing realm. 105 Routing realm - unambiguous address pool used by a contiguous 106 collection of routers and end systems. 108 End point identifier (EID) - used by one end system to identify the 109 other end of a communication. Uniqueness is required only within the 110 context of the originating end. Using the Domain Name System as a 111 common database requires uniqueness throughout the Internet. 113 NAT - segregates realms of routing information by connecting between 114 and rewriting packet headers as necessary. A NAT does not interpret 115 packet contents in any way. 117 Application Gateway - segregates realms of transport information by 118 terminating an application data stream then reconstructing packet 119 contents as necessary before forwarding to the next destination. 121 Firewall - blocks unauthorized end-to-end connections. Often used 122 within a routing realm, firewalls adhere to forwarding rules but do 123 not modify packet headers or contents. 125 VPN - Virtual Private Network which technically treats an IP 126 infrastructure as a multiplexing substrate allowing the end points 127 to build virtual circuits to run another instance of IP over. 129 Utility of NAT's 131 A quick look at the popularity of NAT technology shows that it 132 addresses several real world problems. 134 - Masking the address changes that take place, from either dial- 135 access or provider changes, improves stability in the local 136 network. 137 - Globally routable addresses can be reused for intermittent access 138 customers. This lowers the demand and utilization of addresses to 139 the number of active nodes rather than the total number of nodes. 140 - There is a potential that NAT's would lower an ISP's support 141 burden since there could be a consistent, simple device with a 142 known configuration at the customer end of the access interface. 143 - Breaking the Internet into a collection of routing realms would 144 limit the scope of routing knowledge, and thereby the workload on 145 the routers within each realm. 146 - For applications which don't care about the integrity of the 147 packet header, there are no changes necessary in the hosts. 149 Taken together these are strong motivations for moving quickly with 150 NAT deployment. 152 Hain Informational - Expires January 1999 3 153 Removing hosts that are not currently active lowers address demands 154 of the public Internet, which improves the load on the routing 155 system as well as lengthens the lifetime of the IPv4 address space. 156 While this is a natural byproduct of the existing dial access 157 devices, in the dedicated connection case this service could be 158 provided through a NAT. In the case of a port multiplexing NAT, the 159 aggregation potential is even greater as multiple end systems share 160 a single public address. 162 Compartmentalizing routing knowledge and distributing the overhead 163 by breaking a network into a collection of routing realms might 164 improve its stability. It could also alleviate some of the pressure 165 on the routing infrastructure causing ISP's to enforce artificial 166 boundaries on how much detail they are willing to accept in routing 167 updates. Since the details of adjacent routing realms could be 168 completely masked, the level of aggregation possible would dwarf all 169 prior efforts. The number of entries in the routing table would be 170 reduced to the number of external attachments (albeit at the expense 171 of increasing the NAT mapping table at each attachment point). 172 Determination of the proper exit point is left as an exercise for 173 the reader. 175 NAT deployments should raise the awareness of protocol designers who 176 are interested in ensuring that their protocols work end to end. 177 Breaking the semantic overload of the IP address will force 178 applications to find a more appropriate mechanism for end point 179 identification and discourage carrying the locator in the data 180 stream. Since this will not work for legacy applications, RFC-1631 181 discusses how to look into the packet and make NAT transparent to 182 the application (ie: create an application gateway). 184 Another popular practice is hiding a collection of hosts behind a 185 single IP address. In many implementations this is architecturally a 186 NAT, since the addresses are mapped to the real destination on the 187 fly. When packet header integrity is not an issue, this type of 188 virtual host requires no modifications to the remote applications 189 since the end client is unaware of the mapping activity. While the 190 virtual host has the CPU performance characteristics of the total 191 set of machines, the overall performance is bounded by the 192 processing and I/O capabilities of the NAT device as it funnels the 193 packets back and forth. 195 Hain Informational - Expires January 1999 4 196 Repercussion of NAT's 198 One of the major drawbacks of NAT technology is the process of 199 resolving addresses from names, or names from addresses. When the 200 public DNS is required to resolve a given host name on both sides of 201 a NAT there is no obviously correct answer. 203 In the example below it is not clear what answer DNS should return 204 for Host D. Returning the local address will assure global 205 invisibility, while returning the global address will prevent local 206 access from Host C. If DNS were to return both, the results would be 207 unpredictable. By knowing which side the request came from the DNS 208 server could provide the correct answer, but significant development 209 would be required to add the capability to DNS for source specific 210 responses. (note: since Host A has no access to the DNS service it 211 is required to maintain a local table, but the others may be 212 expecting DNS to provide the appropriate resolution.) 214 In the case where Hosts C & D share an address (either time shared 215 or port multiplexed), there is no way Host B could know which it was 216 connecting to. DNS would return a public side address for either, 217 then it is up to the NAT to decide where the packets are eventually 218 directed. Since Host B cannot rely on the fully qualified domain 219 name to uniquely identify a specific host, the name space is 220 fragmented, resulting in pockets of validity. 222 -------- --- --- -------- 223 | Host A |--|NAT|------|NAT|--| Host B | 224 -------- --- --- -------- 225 \ \ 226 --- -------- --- 227 |NAT|---|Internet|----|DNS| 228 --- -------- --- 229 | 230 ----------------- 231 | | 232 -------- -------- 233 | Host C | | Host D | 234 -------- -------- 236 Even if forward mappings are working, implementations that require 237 an unambiguous reverse mapping from the in-addr.arpa tree will fail 238 (diagnostic tools come to mind). 240 Discussions about an arbitrary mesh of NAT connections will 241 ultimately exaggerate the issue of name space integration with the 242 routing infrastructure and show that the only resolution to 243 appropriately answer name queries in a NAT environment is to locate 244 the DNS service within each NAT. This brings the additional 245 complexity of knowing which NAT to look to for remote resolutions. 246 Since most NAT's are engineered to be auto configuring turnkey 247 devices, and DNS has not been known for its auto configuring 248 properties, this is not a particularly viable approach. 250 Hain Informational - Expires January 1999 5 251 One proposal to deal with locating the DNS service in each NAT is 252 the DNS ALG1. Rather than running the full DNS server in the NAT, it 253 provides a mapping service by intercepting DNS messages and 254 modifying the contents appropriately. 256 The recent mass growth of the Internet has been driven by support of 257 low cost publication via the web. The next big push appears to be 258 support of Virtual Private Networks (VPN's). Technically VPN's treat 259 an IP infrastructure as a multiplexing substrate allowing the end 260 points to build what appear to be clear pathways from end to end. 261 VPN's redefine network visibility and increase the likelihood of 262 address collision when traversing NAT's. Address management in the 263 hidden space behind NAT's will become a significant burden, as there 264 is no central body capable of, or willing to do it. The lower burden 265 for the ISP is actually a transfer of burden to the local level, 266 because administration of addresses and names becomes both 267 distributed and more complicated. 269 As noted in RFC-1918, the merging of private address spaces can 270 cause an overlap in address use, which creates a problem. VPN's will 271 increase the likelihood and frequency of that merging through the 272 simplicity of their establishment. There are several configurations 273 of address overlap which will cause failure, but in the simple 274 example shown below the private use address of Host B matches the 275 private use address of the VPN pool used by Host A for inbound 276 connections. When Host B tries to establish the VPN, Host A will 277 assign it an address from its pool for inbound connections, and 278 identify the gateway for Host B to use. In the example, Host B will 279 not be able to distinguish the VPN address of Host A from its own 280 address so the connection will fail. Since private use addresses are 281 by definition not coordinated, as the complexity of the VPN mesh 282 increases so does the likelihood that there will be a collision 283 which cannot be resolved. 285 --------------- ---------------- 286 | 10.10.10.10 |--------VPN--------| Assigned by A | 287 | Host A | --- --- | Host B | 288 | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | 289 --------------- --- --- ---------------- 291 ---------- 292 1 draft-ietf-nat-dns-alg-00.txt (work in progress 7/98) 294 Hain Informational - Expires January 1999 6 295 The primary feature of NAT's is the ability to simply connect 296 private networks to the public Internet. When the private network 297 exists prior to installing the NAT, it is unlikely and unnecessary 298 that its name resolver would use a registered domain. Connecting the 299 NAT device, and reconfiguring the resolver to proxy for all external 300 requests allows access to the public network by hosts on the private 301 network. Configuring the public DNS for the set of private hosts 302 that need inbound connections would require a registered domain 303 (either private, or from the connecting ISP) and a unique name. At 304 this point the name space is partitioned as hosts would have 305 different names based on inside vs. outside queries. 307 -------- -------- 308 | Host A | | Host B | 309 | Foo |-----| Bar | 310 -------- | -------- --- 311 |-------------|DNS| 312 --- --- 313 |NAT| 314 --- 315 | 316 -------- --- 317 |Internet|----|DNS| 318 -------- --- 319 | 320 --- 321 |NAT| 322 --- --- 323 |-------------|DNS| 324 -------- | -------- --- 325 | Host C |-----| Host D | 326 | Foo | | Bar | 327 -------- -------- 329 Everything in this simple example will work until an application 330 embeds a name. For example, a Web service running on Host D might 331 present embedded URL's of the form http://bar/*.html, which would 332 work from Host C, but would thoroughly confuse Host A. If the 333 embedded name matched the public DNS, Host A would be happy, but 334 Host C would not. To establish a connection from Host C, the NAT 335 would have to look at the destination rather than simply forwarding 336 the packet to a router (which would not send it back on the same 337 interface it came from). 339 NAT's place constraints on the deployment of applications that carry 340 IP addresses in the data stream. Applications or protocols that 341 assume end to end integrity of the address will fail when traversing 342 a NAT. The resolution to this is to provide an Application Level 343 Gateway within or alongside each NAT. An additional gateway service 344 is necessary for each application that imbeds its address. Even this 345 approach will fail when requirement is end to end encryption since 346 only the end points have access to the keys. 348 Hain Informational - Expires January 1999 7 349 The greatest concern from the explosion of NAT's is the impact on 350 the fledgling efforts at deploying IP security. For lack of another 351 globally unique EID, the traditional use of the IP address was 352 assumed. This combination of required global uniqueness of the 353 address, and assured ambiguity by NAT leaves the IPsec effort with a 354 severely restricted working set. 356 In a statement about the use of IPv4 today, RFC-2101 details 357 architectural issues and notes: 358 "... it has been considered more useful to deliver the packet, 359 then worry about how to identify the end points, than to provide 360 identity in a packet that cannot be delivered." 362 This argument presumes that delivering the packet has an inherent 363 value, even if the end points can't be identified. In a self- 364 fulfillment of that prophecy, the applications developed to date are 365 structured to assume packets will be delivered and identity is only 366 assured in controlled environments. In many ways, this fundamental 367 impediment to basic trust has been the stalling factor in deploying 368 security across the Internet. In another note from RFC-2101: 369 "Since IP Security authentication headers assume that the 370 addresses in the network header are preserved end-to-end, it is 371 not clear how one could support IP Security-based authentication 372 between a pair of hosts communicating through either an ALG (ed: 373 Application Level Gateway) or a NAT." 375 IPv6 Considerations 377 Beyond all of the above issues, the existence of NAT's will 378 complicate the integration of IPv6 in the Internet because the name 379 space and end point addresses are not consistent and globally 380 unique. While multiple addresses are less of a concern to an IPv6 381 node, the disjoint name space will certainly make management 382 interesting. If IPv6 nodes are willing to continue in private 383 networks behind a NAT, they will only need a link local address and 384 all of the issues become the same as IPv4. If the intent is to move 385 into a public space as a feature of moving to IPv6, address and name 386 administration will require explicit effort. 388 Security Considerations 390 NAT's break one of the fundamental assumptions of IPsec, and 391 therefore may stall further deployment of enhanced security across 392 the Internet. It is difficult to identify all the combinations of 393 header orderings that are possible using NAT's, VPN's, and IPsec. It 394 is even more difficult to clearly state which of those are 395 applicable, or workable in any given context. IPsec can be made to 396 work over NAT's, some of the time, when it is using certs, but even 397 then there may be IP addresses in the SAs. The presumed to be immune 398 Null ESP has problems with NATs because IKE currently uses IP 399 addresses that are in encrypted packets. In some instances there may 401 Hain Informational - Expires January 1999 8 402 be work-arounds through the appropriate ordering of NAT's and VPN's, 403 but in the end the use of private addresses and lack of 404 administration will result in collision and failure. 406 With sufficient thought and advance planning, some of the issues 407 between IPsec and NAT's can be worked around. Attempts to retrofit 408 IPsec over and existing NAT infrastructure can be problematic, so in 409 the generic sense; NAT's are the greatest single threat to security 410 integration being deployed in the Internet today. 412 For security mechanisms that do not rely on IP addresses as 413 identifiers, such as TLS 2 or SSL 3, there is less exposure. For 414 applications that can establish and make use of this type of 415 transport connection, NAT's do not create any additional 416 complications. 418 Guidelines 420 Given that NAT devices are being deployed at a fairly rapid pace, 421 some guidelines are in order. Most of these amount to 'think before 422 you leap'. 424 - Determine the mechanism for name resolution, and ensure the 425 appropriate answer is given for each routing realm. Embedding the 426 DNS server, or its ALG in the NAT device will be more manageable 427 than trying to synchronize independent DNS systems across realms. 429 - Is the NAT configured for static 1 to 1 mappings, or will it 430 dynamically manage them? If dynamic, make sure the TTL of the DNS 431 responses is set to 0, and that the clients pay attention to the 432 don't cache notification. 434 - Examine the applications that will need to traverse the NAT and 435 verify their immunity to address changes. If necessary provide an 436 appropriate ALG or establish a VPN to isolate the application from 437 the NAT. 439 - If there are encrypted payloads, the contents cannot be modified 440 unless the NAT is a security end point acting as a gateway between 441 security realms. 443 - When using VPN's over NAT's, identify a clearinghouse for 444 addresses to avoid collisions. 446 - Assure that applications that will be used both internally and 447 externally either avoid embedding names, or use globally unique 448 ones. 450 ---------- 451 2 draft-ietf-tls-protocol-05.txt (work in progress 11/97) 452 3 http://home.netscape.com/eng/ssl3/ssl-toc.html March 1996 454 Hain Informational - Expires January 1999 9 455 Summary 457 Wherever they are located topologically, NAT's break a long-standing 458 architectural principle that applications can trust packets to move 459 between end points without modification. 461 NAT's are a 'fact of life', and will proliferate as an enhancement 462 that sustains the existing IPv4 infrastructure. At the same time, 463 they require strong applicability statements, clearly stating what 464 works and what does not. 466 NAT's are a 'necessary evil' as well, and by fragmenting the Name 467 Space, NAT's create an administrative burden that is not easily 468 resolved. It is equivalent to digging a hole where the longer we 469 continue digging, the harder it will be to get out. More 470 significantly, they inhibit the roll out of IPsec, which will in 471 turn slow growth of applications that require a secure 472 infrastructure. As such, NAT's represent the single greatest threat 473 to a secure Internet. 475 An overview of the pluses and minuses: 477 NAT utility NAT repercussions 478 -------------------------------- -------------------------------- 479 Masks Global Address Changes Mandates Multiple Name Spaces 480 Routing realms distribute overhead Requires source specific DNS reply 481 Lowers Address Utilization Allows end-to-end address conflicts 482 Lowers ISP support burden Increases local support burden 483 Breaks end-to-end association Breaks end-to-end association 484 Transparent to end systems Unique development for each app 485 Load sharing as virtual host Performance impact with scale 486 Delays need for IPv4 replacement Complicates integration of IPv6 488 There have been many discussions lately about the value of 489 continuing with IPv6 development when the market place is widely 490 deploying IPv4 NAT's. A short sighted view would miss the point that 491 both have a role, because NAT's address some real-world issues 492 today, while IPv6 is targeted at solving fundamental problems, as 493 well as moving forward. It should be recognized that there will be a 494 long co-existence as applications and services develop for IPv6, 495 while the lifetime of the existing IPv4 systems will likely be 496 measured in decades. At their best, NAT's are a diversion from 497 forward motion, but they do enable wider participation at the 498 present state. At their worst, they break an association that 499 arguably should never have been made to begin with. 501 There have also been many questions about the probability of VPN's 502 being established which would raise some of the concerns listed 503 above. While it is hard to predict the future, one way to avoid 504 ALG's for each type of application is to establish a VPN over the 505 NAT's. This restricts the NAT visibility to the headers of the 506 tunnel packets, and removes its effects from all applications. While 508 Hain Informational - Expires January 1999 10 509 this solves the ALG issues, it raises the likelihood that there will 510 be address collisions as arbitrary connections are established. 512 Everyone needs to focus on the goal, which is continued evolution of 513 the Internet, and recognize continued development of IP (in all 514 current and future versions) is the path. It has been noted that the 515 success of the Internet is based on the 'living' characteristic of 516 IP. As in life, when growth, evolution, and forward progress stops, 517 decay overtakes and destroys. History has shown that protocols that 518 were 'complete and finished' as presented, have had very short 519 lifetimes while those still 'a work in progress' manage to survive 520 and continue moving ahead. All parties need to understand the 521 significant role they are playing in pursuing the goal, and that 522 none can get there without all the others. 524 References 526 [RFC 1631], Egevang, K., Francis, P., "The IP Network Address 527 Translator", RFC 1631, May 1994 529 [RFC 1918], Rekhter, et al, "Address Allocation for Private 530 Internets", RFC 1918 February 1996 532 [RFC 2101], Carpenter, et al, "IPv4 Address Behavior Today", RFC 533 2101, February 1997 535 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", RFC 2119, March 1997 538 draft-ietf-nat-dns-alg-00.txt, P. Srisuresh, et al, _DNS extensions 539 to Network Address Translators_, July 1998 541 draft-ietf-tls-protocol-05.txt, T. Dierks, C. Allen, "The TLS 542 Protocol", November 1997 544 Acknowledgments 546 Valuable contributions to this draft came from the IAB, and Yakov 547 Rekhter(cisco). 549 Author's Addresses 551 Tony Hain 552 Microsoft 553 One Microsoft Way Phone: 1-425-703-6619 554 Redmond, Wa. USA Email: tonyhain@microsoft.com 556 Hain Informational - Expires January 1999 11