idnits 2.17.1 draft-tsirtsis-aatn-mech-00.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. ** 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 19 instances of lines with non-ascii characters in the document. == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '... Drafts are...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '... groups may...' == Line 17 has weird spacing: '...also distribu...' == Line 20 has weird spacing: '... Drafts may ...' == (2 more instances...) -- 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 (April 1998) is 9507 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AIIH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'NATB' -- Possible downref: Non-RFC (?) normative reference: ref. 'NET66' -- Possible downref: Non-RFC (?) normative reference: ref. 'PAID' == Outdated reference: A later version (-12) exists of draft-ietf-ipsec-dhcp-00 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT George Tsirtsis 2 Richard O'Brien 3 Martin Tatham 4 Alan O'Neill 5 BTLABS 7 April 1998 9 Possible Mechanisms and Components for AATN 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its Areas, and its Working Groups. Note that other groups may 17 also distribute working documents as Internet Drafts). 19 Internet Drafts are draft documents valid for a maximum of 20 six months. Internet Drafts may be updated, replaced, or 21 obsoleted by other documents at any time. It is not appropriate to 22 use Internet Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress." 25 Please check the I-D abstract listing contained in each 26 Internet Draft directory to learn the current status of this 27 or any other Internet Draft. 29 Abstract 31 This document attempts to list mechanisms that if added to the 32 Internet protocols could take us some way in providing well 33 desirable alternatives and improvements to NAT. Some of the 34 techniques and components described here are controversial and 35 their appearance in this document does not mean that the author 36 supports them. We merely attempt to list the options and issues 37 (most of them already known) as a starting point for an elimination 38 and selection process. 40 Index 42 0. Introduction 44 1. A simple Tunneling alternative to simple NAT 46 2.Host Tunneling to a gateway 47 2.1. Internal NAT-Bypass 48 2.2. External NAT-Bypass 49 2.3. DNS triggered address allocation 51 3. Tunneling between gateways 53 4. How the end host knows to use public addressing: 54 4.1. By simple host �routing� table (prefix or domain based) 55 4.2. By DNS query trigger 56 4.3. ICMP trigger for all external traffic 57 4.4. ICMP trigger for end-to-end sensitive traffic 58 4.5. Gateway initiated tunnels (back to the end-host) 60 5. Summary of Components 62 6. Security Considerations 64 7. References 66 0. Introduction 68 Section 1,2 and 3 explain the various mechanisms that use tunneling 69 as a main tool in an attempt to provide alternatives to NAT. Note 70 the similarities between the proposals. 72 Section 4 explains lists mechanisms that may answer the question 73 �How the end host knows to use public addressing (as opposed to 74 private)�. 76 Section 5 summarises possible changes to existing protocols or 77 requirement for new ones as a result of this study. 79 Note that there is no section on �How you find a tunnel end point� 80 but the issue is discussed throughout the document. 82 We apologise in advance if we missed (and I am sure we did :) or 83 misinterpreted (and I hope we did not :) any of the existing 84 proposals. 86 1. A simple Tunneling alternative to simple NAT 88 A number of proposed solutions focus on the requirement of not 89 changing the end host stack. This is supported by the fact that if 90 you change the host, then the change should involve IPv6. 92 These solutions invariably involve some form of tunneling. The idea 93 is that since the host does not change (it things that all 94 addresses are unique and reachable) some other box needs to act on 95 its behalf. This philosophy of transparency to the end host was 96 also adopted by NAT and that is partly why it became so successful. 98 The alternative proposals use a typical router with tunneling 99 capabilities instead of a NAT router. These �tunneling routers� 100 encapsulate or decapsulate instead of translating using more or 101 less the same kind of addresses internally and externally that NAT 102 does. 104 The example given here assumes a hostA in a private network is 105 trying to communicate with a host in the Internet. 107 In the NAT case: 108 HostA---Private NET10---NAT -----------Internet--------HostB 109 10.0.0.1 Pool: 164.193.10.1 x.x.x.x 111 host A send packet: ---> NAT translates to: 112 SA DA SA DA 113 10.0.0.1 x.x.x.x 163.193.10.1 x.x.x.x 115 In the Tunneling Router (TR) case: 116 Tunnel 117 <============================> 118 HostA---Private NET10--TR -------------Internet--------HostB 119 10.0.0.1 Pool: 164.193.10.1 x.x.x.x 121 host A send packet: ---> TR tunnels to: 122 Original Packet Tunnel 123 SA DA SA DA | SA DA 124 10.0.0.1 x.x.x.x 10.0.0.1 x.x.x.x | 163.193.10.1 x.x.x.x 126 This apparently avoids translation providing that: 127 a) the destination host can terminate tunnels 128 b) the destination host has a global Internet address 129 It can be argued that this solution covers a large number of cases 130 where NAT is used today; that is, as a gateway from a private 131 network to the global Internet. The obvious problem, however, is 132 that it requires the end host to support tunnel termination. 134 Note that wile tunnel termination on clients may require changes to 135 hosts, tunnel termination on servers may be much easier and it 136 probably conforms better to their specs (L2TP tunnels are designed 137 to also terminate on servers; they could easily also terminate 138 IPinIP, IPSEC, mobile IP etc). 140 Applicability 141 - A private network using private addresses and requires to 142 communicate with the global Internet. Note that the addresses used 143 by the private network should be from the designated blocks of 144 addresses that have been assigned for private use (e.g.: NET10). If 145 global but not registered addresses are used the technique will 146 fail if (and only if) the source address overlaps with the address 147 of the destination host. Note that if the destination host address 148 is not the same with that of the originating private host the 149 technique will work since the tunnel isolates this address from the 150 Internet. 151 - Accessing WWW, IRC, ftp, video, audio, mail, IPsec? etc globally 152 reachable servers from a private network could be done this way. 154 Problems 155 - How do you know a server supports tunnel termination and if yes, 156 what kind of tunneling (L2TP, mobile IP, IPSEC, IPinIP etc)? One 157 way is to first try tunneling (whichever the TR supports) and if 158 not succeed use NAT? This is obviously a hit and miss approach; 159 discovery mechanisms (often complicated) have been proposed but 160 here we try to provide a simple solution. Could a �tunnel type� 161 negotiation help here? Is there any available but even if there is, 162 it involves even more changes... 163 - How many global IP addresses the TR needs for the tunnels? Some 164 tunneling protocols will allow the use of a single IP address for 165 all tunnels (L2TP can mux on UDP port numbers), others (e.g IPinIP) 166 may need one per tunnel? 167 - Though any requirement for change should be targeting networks 168 that are �misbehaving� (in this case by using private addressing) 169 the described proposal requires servers to add tunneling 170 capabilities to their tack. Some servers do that anyway but the 171 ones who do not can do it in a case by case bases. After all 172 servers are there to serve and the above technique only increases 173 the amount of hosts that can be served by them... 175 2.Host Tunneling to a gateway 177 Tunneling to the gateway of a private network (from inside and/or 178 from outside the private network) has been discussed in a number of 179 proposals. The basic idea is the following: 181 Tunnel Tunnel 182 <=================> <============================> 183 HostA---Private NET10--TR -------------Internet--------HostB 184 10.0.0.1 Global Pool: 164.193.10.1 x.x.x.x 185 Private Pool: 10.0.0.3 187 A host in the private network or the global internet tunnels to a 188 gateway to the global Internet or the private network respectively. 189 This allows the host to get an address from the corresponding 190 network (if it does not already have on, as in mobile IP) and 191 communicate with hosts inside this network (private or Internet). 193 There are few proposals that use a variety of techniques to allow 194 that. 196 2.1. Internal NAT-Bypass 198 One of them [NATB], allows a host in the private network to build 199 an L2TP tunnel to its Internet gateway and be assigned a global 200 address from the pool of addresses available to the gateway (as in 201 NAT). This address can now be used for end-to-end communication 202 with the external hosts. 204 HostA---Private NET10--TR -------------Internet--------HostB 205 Set tunnel 206 ---------------------> 207 assign global addr 208 ,---------------------, (tunnel to TR)) 209 (<--------------------- ) 210 �---------------------� 211 end-to-end communication with global address 212 ,----------------------, (tunnel to TR) 213 (<--------------------------------------------------------> 214 �----------------------� 216 Note that, the tunnel, after the address assignment phase, may not 217 be used if the private network supports global routing as suggested 218 by Jim Bound. 220 2.2. External NAT-Bypass 222 The same could be done from the other side: 224 HostA---Private NET10--TR -------------Internet--------HostB 225 Set tunnel 226 <------------------------------- 227 assign private address 228 (tunnel to TR),------------------------------, 229 (------------------------------->) 230 �------------------------------� 231 end-to-end communication with private address 232 (tunnel to TR),------------------------------, 233 <----------------------------------------------------->) 234 �------------------------------� 236 Note that with mobile IP tunneling (as proposed by Vipul in [MIP]) 237 address assignment is not required since HostB is a host from the 238 private network that has been temporarily moved to the global 239 Internet and it already has a private address. 241 The tunnel here is required for the duration of the session since 242 there is no way the global Internet can route private addresses. 244 L2TP has been proposed as the tunneling mechanisms for both 245 scenarios since it was designed for this kind of remote access and 246 has all the hooks for authentication, accounting, address 247 assignment etc. IPSEC tunnel mode could also be used since some 248 associated mechanisms for address assignment through IPSEC tunnels 249 have appeared [SECALL]. Mobile IP [MIP] may also be used but a lot 250 of details and possibly modifications may be required (how you 251 accommodate hosts that are not originate from the private network, 252 thus, do not have private addresses?). IPinIP tunneling may also be 253 used if appropriate mechanisms are developed for address 254 assignment. I am sure that there are many other tunneling protocols 255 that could also be used. 257 Applicability 258 - Accessing servers both in private networks and in the global 259 Internet from hosts in the global Internet and private networks 260 respectively. 262 Problems 263 - How do you discover the tunnel termination point (in this case 264 the TR) address that can be reached from your position. A number of 265 ways have been proposed and are discussed later in this document. 266 - How do you know that you want to create a tunnel (i.e.: access a 267 private network or the global Internet)? This is arguably a 268 difficult problem and possibly involves significant changes to the 269 end hosts. Possible options are discussed later in this document. 271 2.3. DNS triggered address allocation 273 Another interesting variation that may or may not use tunnels is 274 the following: 276 HostA---Private NET10�--NAT/TR------------Internet--------HostB 278 The first problem that one needs to solve here, when HostB needs to 279 connect to say HostA, is how HostB knows that HostA even exists. 280 Today this is possible if there is a statically mapped global 281 address for HostA, if that is not true HostB has no way of knowing 282 anything about HostA. 284 If we assume that the name HostA.Pnet.com is globally unique, then 285 HostB may be aware of that name. A name lookup on HostA.Pnet.com 286 will have to go all the way back to the authoritative DNS server 287 for the domain Pnet.com in order to be resolved. Now there are two 288 ways to proceed. 290 a) The DNS for the Pnet.com domain can in some way interact with 291 the NAT/TR Gateway. In this case the DNS triggers an address 292 mapping between the private address of HostA and a global address. 293 The mapping is retained in the NAT/TR and the global address is 294 returned as a DNS reply to the requesting HostB. HostB can now send 295 a packet to the global address of HostA. When the packet reaches 296 the NAT/TR it will have to be translated since the destination 297 address stated on the packet is only known to the NAT/TR and not to 298 HostA. Tunneling can not be used to deliver the packet to HostA 299 without translation since the encapsulated packet will have an 300 address unknown to HostA. 302 c) The DNS for the Pnet.com domain can in some way interact with 303 the local DHCP server. This can only be of use if the DHCP server 304 is able to perform server initiated address allocation. If yes, 305 then this is as described in [AIIH], where the DNS triggers the 306 DHCP to allocate an address to HostA. Then, communication with 307 HostB can take place without any need of translation or tunneling. 308 Unless the private network can not route on global addresses, in 309 which case the DHCP may also provide HostA with information about 310 the tunnel type and endpoint address, there is no need to use 311 tunnels. 313 In any case, the DNS trigger described in (a) may be a useful 314 addition to the NAT spec in order to allow incoming session through 315 a NAT router. 317 3. Tunneling between gateways 319 In many ways this is similar to (2) but it is viewed as a more 320 generic solution and brings up a number of interesting points. 322 The problem space is as follows: 324 Tunnel 325 <==================> 326 HostA--Private NET-�TR1-----Internet----TR2--Private NET�-HostB 327 z.z.z.z x.x.x.x y.y.y.y w.w.w.w 329 This scenario arises from (2) since the destination (HostB) may not 330 be part of the global Internet but part of another private network. 331 Typically, this is called a VPN (though there is much argument 332 about what VPN actually is...:). 334 [NET66] attempts to solve this problem by introducing a special 335 range of addresses, globally unique but not routable, that are 336 assigned to servers in private networks. By limiting the number of 337 addresses used for that purpose it is possible to inject this 338 address space in the DNS system and create mappings between these 339 designate addresses, working almost as identifiers, and their 340 nearest globally reachable gateway, serving as a locator (KX 341 records). NET66, however, does not avoid using NAT in the case of 342 overlapping address spaces. That is, apart from the servers with 343 designated addresses, the rest of the private network may use 344 private addresses overlapping with the address space of another 345 private network that attempts to use this server. Since the tunnels 346 only go between gateways, overlapping address space can not be 347 supported. Extending the tunnel into the private network and up to 348 the servers, may eliminate the problem. 350 Other relevant proposals, like [PAID] and others, are more 351 aggressive in the architectural changes that require, generalising 352 the above principle. The (probably oversimplified) basic idea of 353 such proposals is that there is a core, globally reachable, network 354 of gateways that serve corresponding non-globally reachable 355 networks. This way, an end host is identified by a pair of 356 addresses; the end-host address + a gateway address. This seams 357 like an increased address space but a closer look arises a lot of 358 questions about their feasibility. 360 There two variations of this solution; the end-host is aware of the 361 architecture; the end-host is not aware of the architecture. 363 a) The end-host is aware of the architecture 364 In this case the end-host has knowledge of the fact that a 365 destination host needs to be reached using two (rather than one) 366 addresses. This way the host can make clever use of the available 367 information and with possible/proposed changes to DNS it can 368 discover the related gateways, register it self to a gateway 369 address and use tunneling mechanisms to achieve the desired 370 communication. The fundamental problem of this approach, however 371 plausible, is that it requires many changes to end-host, gateways, 372 DNS and possibly many other protocols that its practical deployment 373 seams unlikely. It also comes down to the fact that the effort 374 required to deploy such a scheme would be more than enough to 375 deploy IPv6 instead. 376 b) The end-host is not aware of the architecture 377 In this case the burden is placed on the gateways, to hide the 378 operations of the network from the end-host. The problem with this 379 approach is that the end-host things that communicates with a 380 globally reachable hosts as usual and it can not do anything more 381 than what it does today. So, the network needs to provide to the 382 end-host information about say private addresses (introducing 383 changes to DNS) and the gateways need to be able to find each other 384 (introducing gateway discover protocols or even more changes to 385 DNS). Also the problem of overlapping address space between end 386 nodes seams difficult to solve like that. 388 4. How the end host knows to use public addressing: 390 In this section we attempt to list a number of ways to solve the 391 problem in hand. Some of these have already mentioned in various 392 drafts or discussions in IETF meetings and some others are new. 393 Please take the following analysis for its face value, we are just 394 listing the options that we could thing of and it does not mean 395 that we support the ideas. 397 For each option, we also attempt to list concerns and potential 398 problems; at least the obvious ones. The aim is to trigger 399 interested parties that may find feasible ways to implement/use 400 these options in concrete solutions. Also note, that depending on 401 the way that these options might be implemented and the combination 402 of options that one might use, the impact on the protocol stack 403 and existing protocols might considerably changes. Thus, at this 404 point only obvious change requirements are indicated and future 405 work should discover the details of these mechanisms. 407 4.1. By simple host �routing� table (prefix or domain based) 409 HostA---Private NET10--GateWay ----------Internet--------HostB 410 10.0.0.1 x.x.x.x 411 HostA, which is assumed to be capable of supporting at least two 412 addresses, could maintain a simple host routing table. This would 413 take the following form: 414 * A list of destination prefixes for each virtual interface. In the 415 case of multiple non-loadsharing gateways, the host routing table 416 would have to have a prefix list and virtual interface per gateway. 417 By default, the list of private address prefixes in the domain 418 (e.g. 10.0.0.0/8) would be associated with the host�s virtual 419 interface numbered with its private address. A default route would 420 also be associated with another virtual interface (the yet-to-be- 421 assigned public address). 422 * If HostA needs a tunnel to the GateWay in order to access the 423 Internet, the tunnel type (e.g. PPTP, L2TP, IP-in-IP, ATMP, GRE) is 424 also required. 425 * The gateway address (which would equate, in the case of tunnels, 426 to the tunnel end point). 428 This simple host routing table could be downloaded using DHCP 429 (extensions required) on initial boot together with tunnel end 430 point addresses and tunnel types when required. 432 In the simplest cases they could even be pre-configured e.g. 433 all 10.0.0.0/8 addresses use private address, 434 Tunnel type = IPinIP and 435 Tunnel destination = 10.0.0.5). 437 Applicability 438 - Private networks with clean addressing schemes (all hosts use 439 private addresses of known prefix(es). 440 - If private network is a stub domain with singly gateway router 441 this becomes easier. 442 - DHCP initiated network can benefit greatly since the 443 configuration is automated. 445 Issues: 446 - Virtual interfaces need to be created in advance of address 447 assignment. 448 - How you calculate lease time of public address? 449 - The host is becoming a router. Note that in the simple case only 450 static routs are required but in the general case, with multiple 451 exit points and big private networks, real routing capabilities may 452 be required on the host. 454 4.2. By DNS query trigger 456 When the host needs to communicate with an external host, it 457 performs a DNS lookup. The DNS resolver has, or may be configured 458 to have, the information necessary to know whether the destination 459 host is internal or external to the private addressing domain: 461 a) The destination host is in a name domain outside the local 462 private-address domain OR the destination host has a public address 463 outside the private domain. 464 b) The DNS resolver either: 465 - Triggers a DHCP server-initiated address allocation (this 466 would require changes to DHCP like those done by Jim Bound/Dec in 467 DHCPv6, I think Jim is also working on that in DHCPv4) to the host, 468 providing it with a temporary address to use, or, 469 - the DNS uses a different record type which returns not 470 only the destination address but also indicates that this is 471 external. The host then issues a DHCP request. 472 c) In the case of multiple non-loadsharing gateways, either the 473 DHCP server or DNS resolver would have to know about gateway 474 routing tables. Both of these are problematic since DNS and DHCP 475 are not/should not participate in routing. 477 Possible Changes 479 - DHCPv4 to support server initiated address allocation (as DHCPv6 480 does). 481 - DNS to have (or appear to have) a notion of site. A record (flag) 482 to indicate internal/external address may also be required. A lot 483 of issues may come up with either of these changes and without 484 fundamental (and probably not desirable) changes to the way that 485 DNS works a lot depends on the network/DNS administrator which 486 makes the solution error prone. 487 - The end-host clearly needs to be changed in order to use most of 488 the above mechanisms. 490 4.3. ICMP trigger for all external traffic 492 HostA---Private NET10--GateWay ----------Internet--------HostB 493 10.0.0.1 x.x.x.x 495 In this case all external traffic needs to use globally unique 496 addresses, possibly retrieved from a DHCP server. 498 Host in private domain initiates session, without knowing whether 499 the destination is internal or external. If external, and datagram 500 reaches gateway, and ICMP message is send back to indicate that a 501 global address is required. The ICMP message used could be an ICMP 502 Destination Unreachable, Redirect or Source Quench, with changed 503 semantics, or an all together new ICMP message (not desirable). The 504 end-host, on reception of such a message should attempt to acquire 505 a global address with some mechanism like DHCP or by initiating 506 tunneling mechanisms as described in (2). 508 Note that this mechanism would rely on the fact that communication 509 from the private network to the Internet is the minority case and 510 as such, failure to make a valid connection first time is not too 511 costly. 513 4.4. ICMP trigger for end-to-end sensitive traffic 515 HostA---Private NET10---NAT--------------Internet--------HostB 516 10.0.0.1 x.x.x.x 518 In this case, the Gateway to the internet is a NAT router and the 519 ICMP message is only send back when the session can not be 520 translated (e.g: IPSEC) 522 Host in private domain initiates session, without knowing whether 523 the destination is internal or external. If external, and datagram 524 reaches NAT box, address translation validity is checked. If 525 address translation is invalid (according to certain rules) then 526 the NAT box returns an ICMP message, indicating that a public 527 address needs to be used. Various ICMP message could again be used 528 if the semantics can change or a new message type is needed (say 529 Source Redirect) 531 As before, when the host receives the ICMP message, it sends a 532 request to the DHCP server to obtain a public address, and then 533 sends the datagram as in (2) (tunnelled or routed to NAT). This 534 method is also advantageous for the case where numerous NAT 535 gateways are used. The return of the ICMP message may indicate to 536 the host which gateway to tunnel to. 538 The Translation Rules that the NAT router uses to determine if 539 something should be translated or not could take a number of forms: 541 a) The NAT knows what it can translate. In this case the NAT has to 542 know what is �safe� to translate. For example, if NAT has an ALG 543 for the particular application then it can translate or if the IP 544 Payload is scrambled (end-to-end security is used) it can not 545 translate. A list of applications that are not to break by the 546 particular NAT implementation could also be stored in the NAT or a 547 rule that says �if unsure do not translate� could be used. In any 548 case this is largely and implementation/configuration issue. 550 b) The host knows what it should/should not be translated. In this 551 case the host needs to make an intelligent decision (to be defined) 552 on whether a packet/session should be subject to translation and 553 notify the gateway accordingly. The problem here is the 554 notification of the gateway/NAT. A �Don�t Translate� option in the 555 IP header would be beneficial. This could be set by the sending 556 host, as an indication to NATs to encapsulate rather than to 557 translate. It could also be used between NAT gateways. This would 558 enable the host stack to decide where address translation is 559 appropriate, rather than the gateway. Obviously, changes to both 560 hosts and gateways/NATs are required for that. 562 Note that this mechanism is more scalable than that of (4.3.) since 563 only traffic that can not sustain translation is tunneled. 565 Obviously, an number of changes to ICMP, NAT and host are required 566 to make this work. The most important problem, however, is that the 567 host needs to change source address AFTER sending the first packet 568 (and getting back the ICMP message). One way to cope with that is 569 to take the connection down and set-up a new one, but even for that 570 the host stack needs to be changed. 572 4.5. Gateway initiated tunnels (back to the end-host) 574 This is very similar to the above mechanism. 576 The host, as above, does not know whether a destination address is 577 in or out of the site. The packet is send out and if the 578 destination is out of the site it will reach the NAT/Gateway. If 579 the packet can be translated, it does as normal. If not, the NAT 580 could initiate a tunnel back to the host and allocate a global 581 address ala NAT-bypass. Note that if L2TP is used address 582 allocation maybe easier since, this appears to the end-host as a 583 PPP call back service and it will accept address allocation as part 584 of the IPCP process from the tunnel originator, without having to 585 initiate DHCP. 587 In this case the host needs to be able to terminate tunnels from 588 the gateway which is not conformed to a typical client spec. The 589 host also needs to be aware of the process in order to associate 590 the incoming tunnel with a previous communication attempt. This 591 becomes particularly difficult if a number of connections are 592 initiated at the same time from a single host. 594 5. Summary of Components 595 Depending on the scheme some of the below are required: 597 * Fundamental (not so controversial?) Components 598 - Gateway discovery protocols/mechanisms (some already defined 599 e.g: NET66, PAID) 600 - Tunnel type negotiation. There is number of proposals that 602 use some kind of tunneling technique. If no single tunneling 603 protocol is adopted by all (highly unlikely) the choices are static 604 configuration or a negotiation protocol. DHCP can also help as 605 described above. 606 - Server initiated DHCP configurations ala DHCPv6 608 * Controversial Components 609 - the ability for a host to maintain multiple virtual 610 interfaces. Hosts today do not support that very well or do not 611 supported at all. 613 One of the following: 614 - A �Don�t Translate� IP option which may be set by the 615 hosts to indicate where address translation is inappropriate. 616 - A new or overloaded ICMP message, which a NAT/gateway may 617 return to the sending host when it is unable to translate a packet 618 without problems. 619 - NAT routers to be able to recognise packets/sessions that 620 can be safely translated. 622 - Extended DNS - DHCP and/or DNS - NAT/TR interaction 624 - Client hosts to be able to terminate tunnels 626 6. Security Considerations 628 This is not a protocols specification and security considerations, 629 although many, are not discussed here. If any of the ideas 630 described in this documents are going to become protocols or parts 631 of protocols, security considerations will be discussed in the 632 corresponding specifications. 634 7. References 636 [AIIH], J.Bound, Assignment of IPv4 Global Addresses to IPv6 Hosts 637 (AIIH), , March 1998 639 [MIP], G. Montenegro, V. Gupta, Firewall Support for Mobile IP, 641 [NATB], G.Tsirtsis, A.O'Neill, NAT Bypass for End 2 End 'sensitive' 642 applications, , January 1998 644 [NET66], R. G. Moskowitz, Network Address Translation issues with 645 Ipsec, , February 6, 1998 647 [PAID], Y. Li, W. T. Teo, IP Private Address Identification (PAID), 648 [SECALL], Baiju V. Patel, Dynamic remote host configuration over 649 IPSEC using DHCP, draft-ietf-ipsec-dhcp-00.txt, September, 1997 651 ------------------------------------------------------------------- 652 Notice: This contribution has been prepared to assist the IETF as a 653 basis for discussion. It is not a binding proposal on British 654 Telecommunications plc; specifically, British Telecomminications plc 655 reserves the right to modify, delete or amend any statements contained 656 herein. 657 -------------------------------------------------------------------