idnits 2.17.1 draft-ietf-ngtrans-dti-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-19) 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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '...te in the AIIH mechanism, it MUST have...' RFC 2119 keyword, line 197: '...e IPv6 equipment MUST support a dual s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 58 has weird spacing: '...section intr...' == Line 138 has weird spacing: '... to-end solut...' == Line 282 has weird spacing: '...dr.arpa nam...' == Line 349 has weird spacing: '...dr.arpa nam...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'RFC 1933' on line 102 looks like a reference -- Missing reference section? 'SIIT' on line 410 looks like a reference -- Missing reference section? 'AIIH' on line 407 looks like a reference -- Missing reference section? 'NAT' on line 413 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Laurent Toutain 3 NGTRANS Tools Working Group Hossam Afifi 4 December 18,1998 ENST Bretagne 5 expires in 6 month 7 Dynamic Tunneling: A new method for the IPv4-IPv6 Transition 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as work in progress. 22 To view the entire list of current Internet-Drafts, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 We propose to use an IPv6 tunneling mechanism and encapsulate IPv4 31 packets into IPv6 packets. This eases the transition and routers do 32 not need to support IPv6 and IPv4 routing tables. The IN_ADDR.arpa 33 domain is used to find IPv4 to IPv6 correspondence in a way that does 34 not prevent the asymmetrical routing and multi-homing. 36 The model also simplifies IPv4 address management since the address 37 has no more a localization function but only an identification 38 function. 40 1. Introduction 42 The co-existence of IPv6 with IPv4 will be a temporary phase before a 43 progressive transition to the IPv6 protocol even if no limit has been 44 set for the transition period. The first phase in the transition was 45 to install new IPv6 subnetworks connected by tunneling justified by 46 the relatively small number of IPv6 networks compared to the global 47 internet. 49 The goal of this work is to propose a simple and flexible 51 Internet Draft IP Dynamic Tunneling Expire 6/99 53 interconnection mechanism where IPv6 and IPv4 networks can be 54 separated, but where IPv6 and IPv4 applications can transparently 55 exchange information. This gives the opportunity to use IPv6 in 56 combination with other protocols for a more flexible routing. 58 The next section introduces native IPv6 networks and hosts and 59 places the study in its context. First we describe the model we 60 choose to study. We analyze current transitions propositions. In a 61 second part we describe the proposal. We cover the cases where 62 connections are initiated from the IPv6 and from IPv4 sides 63 respectively. 65 2. Transition Model 67 In our view a general model describing the transition period is 68 depicted in figure 1. We consider a domain running mostly IPv6 but 69 where some IPv4 equipments or applications still remain used. This 70 domain is connected to an IPv6-only provider. Somewhere on the 71 network a third party provider is able to link the IPv4 and IPv6 72 domains. We solve the case where IPv6 equipment must talk with 73 equipment in IPv4-only domains and vice versa. We suppose that no 74 change can be made to the IPv4-only equipment and applications. The 75 transition mechanism must be as transparent as possible to keep the 76 advantages of the IPv6 autoconfigation. 78 +------+ +-----+ +-----+ +-----+ +-----+ 79 | DNS |....| DNS |....| DNS |....| DNS |....| DNS | 80 | v6 | | | | | | | | v4 | 81 +------+ +-----+ +-----+ +-----+ ------+ 83 +---------------+ +-----------+ +------------+ 84 | |....|dti-tunnel |....| | 85 | | |provider y | | | 86 | | +-----------+ | | 87 | | | | 88 | IPv6 | | ipv4-only | 89 | network | +-----------+ | network | 90 | |....|dti-tunnel |....| | 91 | | |provider x | | | 92 +---------------+ +-----------+ +------------+ 94 A DNS is running on each domain. Queries to the DNS are done in the 95 respective native protocol (we suppose that they are interconnected 96 but the way of interconnection is beyond the scope of this draft). 98 2.1 The double stack 100 Internet Draft IP Dynamic Tunneling Expire 6/99 102 [RFC 1933] defines a transition mechanism based on a double stack. A 103 host will either send packets in IPv4 or IPv6 depending on the 104 protocol used by the destination. The IPv4 mapped addresses allow 105 applications compiled with IPv6 system calls to talk with IPv4 only 106 applications. 108 This method is currently used in the early phase of the transition. 109 The main drawbacks are the following. An IPv4 address must be 110 allocated to each equipment. If we map this onto our transition model 111 previously described, it means that the IPv6 domain is included in 112 the IPv4 world. Routers must be configured for the two protocols and 113 IPv4 applications must be slightly modified and recompiled to be 114 adapted to the IPv6 API. 116 2.2 The SIIT proposal 118 This proposal is similar to Network Address Translation (explained 119 later), used in IPv4 networks to exchange a private IPv4 address to a 120 public IPv4 address. It is difficult with the SIIT proposal to deal 121 with applications sending addresses (such as FTP or RTP flows). In 122 that case, some Application Level Gateways acting as proxy will be 123 required. The proposal focuses on separate IPv6 and IPv4 domains. If 124 in the IPv6 domain some equipment wants to talk with an IPv4 domain, 125 it will use an automatic IPv4 address allocation of the double stack. 126 In that case, routers will have to administrate IPv4 and IPv6 routing 127 tables. 129 Like NAT (described hereafter), this is a one way translation. It 130 means that outside IPv6 domains, IPv4 applications cannot initiate 131 communications with IPv6 hosts. The context for header translation in 132 the SIIT box can be established only when an exiting IPv6 packet 133 leaves the domain. 135 2.3 The NATPT Proposal 137 Unlike SIIT [SIIT], NAT-PT is designed to provide transparently end- 138 to-end solutions. A pool of IPv4 addresses is used to be assigned to 139 IPv6 hosts dynamically in response to any request for packets leaving 140 one of the boundaries. These assigned addresses in turn are used to 141 transparently replace the original addresses used by IPv6 end nodes 142 and vice versa. This proposal allows translation in both ways since 143 the context inside the transition box is this time established by the 144 DNS. 146 NATPT does not solve the problem of applications sending IP addresses 147 in the payload. DNS and NATPT must be combined to allow the 148 establishment of the context. This is generally not the case if the 149 translation is not directly made by the IPv6 domain. The DNS request 151 Internet Draft IP Dynamic Tunneling Expire 6/99 153 may follow another path that does not go through the third party 154 provider assuring the transition. 156 2.4 The AIIH Proposal 158 The AIIH proposal aims at using a combination of DHCPv6 and the DNS 159 to establish a transition between IPv6 and v4 in both directions. 160 This proposal is complementary to the NAT -PT and SIIT since it 161 focuses on topology where IPv4 and IPv6 are in the same domains. 163 For an IPv6 host to participate in the AIIH mechanism, it MUST have 164 a dual IP layer, supporting both an IPv4 and IPv6 stack. When an IPv6 165 host wants to talk with an IPv4 one, the DNS will not answer with an 166 IPv6 record but with an IPv4 one. The IPv6 will request a temporary 167 IPv4 address. Mechanisms such as DHCP are currently available to do 168 such assignment. The opposite case, where an IPv4 host wants to talk 169 with a IPv6 host is more difficult to solve since no protocol is 170 currently available to do a automatic assignation. 172 In our view, there are two main drawbacks in this proposal. The 173 router must be configured both for IPv4 and IPv6 protocol and the 174 assignment of IPv4 addresses is difficult since the network topology 175 must be taken into account. 177 3. The Dynamic Tunneling Interface 179 In the IPv6 case networks are largely spread, we propose to reverse 180 the tunneling and encapsulate IPv4 packet into IPv6 packets. This 181 would ease the transition since routers need only to be configured 182 with IPv6 routing tables. The case of dynamic attribution of IPv4 183 addresses will also be simplified since the address has no longer a 184 localization function but only an identification function. The system 185 has just to maintain uniqueness of the address allocation. 187 We think this method can be used either in domains where IPv4 188 applications cannot be recompiled, but where the system stack can be 189 changed to take benefit from an IPv6 network or with IPv4 only legacy 190 equipment. We will explain later scenarios where an IPv4 only domain 191 wants to join an IPv6 equipment. 193 3.1 IPv6 to IPv4 195 We start describing the general procedure for an IPv6 host to 196 communicate with an IPv4 only application. From our assumptions we 197 suppose that the IPv6 equipment MUST support a dual stack. 199 When an equipment wants to join an IPv4 host, it may directly use an 201 Internet Draft IP Dynamic Tunneling Expire 6/99 203 IPv4 address or resolve a domain name from the DNS and obtain the 204 correspondent IPv4 destination address. 206 We propose to intercept the packet in a new interface that we call 207 dti for dynamic tunneling interface. It may be intercepted by the 208 host through the IPv4 routing table lookup or through dynamic network 209 libraries hookups but this is implementation dependent. We try hence 210 to offer transparently the dti functionalities with no changes in the 211 applications. The main difference with AIIH is that IPv4 packets will 212 not be directly sent over the network but first filtered by the dti. 214 The dti interface systematically encapsulates the IPv4 packet into an 215 IPv6 packet. It needs to find the destination IPv6 address and also 216 needs to obtain for itself an IPv4 address. We propose to use the DNS 217 to make this resolution. The procedure is explained later. Once a 218 result is obtained, it should be cached after the first resolution. 219 There are many possible results for this IPv6 resolution. 221 - The destination has an IPv6 address. 223 - It has only an IPv4 address. 225 In the first case, the dti returns an IPv6 destination address. It is 226 possible to establish an end-to-end tunnel and there is no need to 227 obtain a global IPv4 address. If the dti has not yet a local address 228 it will configure the IPv4 stack and use the address in the 229 encapsulation. The local IPv4 address should be de-allocated after a 230 certain idle time. 232 In case of an IPv4-only destination equipment, we propose to 233 implement tunneling boxes inside the network that we call dti- 234 tunnels. These boxes should be as close as possible to IPv4 resources 235 to reduce routing of native IPv4 packets. They can also be located on 236 a third party provider network if no possible internetworking between 237 IPv6 and IPv4 can be achieved in the local domain. The dti must 238 obtain a dti-tunnel IPv6 address. This may be statically configured 239 in each dual stack host. It could be obtained as mentioned in AIIH 240 proposal by means of a RR record in the destination domain name (we 241 propose to add in the DNS a new entry for NGTRANS-TUNNELING) or via 242 more advanced methods like NHRP. 244 The dti sends a DHCP(v4) query to the dti-tunnel encapsulated in 245 IPv6. The dti-tunnel assigns an IPv4 address to the dti. In the 246 general case, the assignment can be static through an IPv4 pool of 247 addresses in the dti-tunnel. The dti-tunnel can act as forwarder and 248 obtain dynamically an IPv4 address through a conventional DHCP(v4) 249 procedure. 251 Internet Draft IP Dynamic Tunneling Expire 6/99 253 The dti is now able to send the packets to the dti-tunnel that 254 decapsulates the IPv6 header and sends them to the destination 255 through IPv4 network. The procedure is hence quite similar to NAT but 256 does not need any address translation at boundaries. 258 3.2 DNS Resolution in the dti 260 The dti queries the DNS when a packet is received from an IPv4 261 application to the dual stack. A query to the IN_ADDR.arpa domain is 262 sent to obtain the original destination domain name. This is the main 263 contribution in the dti tunneling model. Once this is achieved a 264 second query is sent to the DNS for the resolution of an AAAA type 265 address. If an answer is obtained a direct tunnel can be established. 266 Otherwise, the dti may, as it is mentioned in the AIIH proposal look 267 for a RR record with the AAAA type to be used as the dti-tunnel. The 268 dti proceeds as explained before. 270 During the name resolution the dti should check whether the 271 destination is located on the local intranet or not. If it is in the 272 same domain as the origin then the dti should use a local dti-tunnel. 273 We illustrate the DNS procedure by an example: the dti receives a 274 packet to be sent over IPv4 to the destination 192.44.77.131. It will 275 make a query to the DNS asking for qtype=ptr. The query itself will 276 look like: 278 131.77.44.192.in-addr.arpa. 280 and the answer : 282 131.77.44.192.in-addr.arpa name = abc.xyz.com. 284 This entry describing the host abc will give more information on its 285 addresses and tell whether there is an IPv6 address for the host. The 286 final answer if there is an IPv6 address will be: 288 abc IN A 192.44.77.131 289 IN AAAA 290 3ffe:0305:1002:0001:0a00:2bff:fe1c:b0df 292 4. IPv4 to IPv6 294 We present the second part of the dti model where an IPv4 only 295 equipment needs to reach an IPv6 only one. 297 If the IPv4 host has already an IPv4 global address to the 298 destination it will send the packet through the normal routing 299 procedures. Once the packet arrives to any dti-tunnel equipment the 300 same DNS resolution as in the dti case (section 3.2) should be done. 302 Internet Draft IP Dynamic Tunneling Expire 6/99 304 We try to find an IPv6 address for the IPv4 destination by consulting 305 the IN_ADDR.arpa domain and once it is obtained we encapsulate the 306 packet in IPv6 and send it to the destination. 308 If the IPv4 only host sends a DNS query to resolve the destination 309 domain name into an IPv4 address the query may succeed and nothing 310 more is needed from the dti model. The packet will be sent using IPv4 311 and will arrive to the dti-tunnel as previously described. If however 312 the resolver fails to locate an IPv4 address for the requested domain 313 name we use the dti model to execute an additional procedure instead 314 of returning the name-error to the IPv4 application. The dti will 315 make a second query for the same domain name asking this time for an 316 IPv6 address resolution. If there is no IPv6 available then the 317 resolver will return a name error. 319 If however an IPv6 address is found for the requested domain name the 320 resolver library should trigger a special dti procedure for the 321 tunneling. This is explained in the next paragraph. 323 IPv4 to IPv6 tunneling 325 The resolver must have a pre-configured dti-tunnel IPv4 address for 326 its domain. It should send a query to this equipment asking to assign 327 an IPv4 address to the IPv6 destination. The dti-tunnel obtains an 328 IPv4 address from a local pool or using DHCPv4. It remotely 329 configures the IPv4 destination stack and updates the in_addr.arpa 330 domain name with a pointer entry to the IPv6 host. Since the 331 destination may be multi-homed, it is also necessary to update the 332 destination DNS database with the new IPv4 address. We present 333 hereafter a solution to avoid the need to update the destination 334 domain name. Note also that all these procedure will use time to live 335 fields that will protect the system from any malicious attack trying 336 to consume all IPv4 available addresses in a site. The following 337 example traces the steps in the IPv4/IPv6 direction. 339 The resolver intercepts a query to lmn.xyz.com asking for an IPv4 340 address (A type query). The query fails and the resolver asks again 341 for an IPv6 address. This time the query succeeds and an IPv6 address 342 is returned. The resolver sends a special query to its pre-configured 343 dti-tunnel asking for the assignment of an IPv4 address to the 344 lmn.xyz.com destination. The dti-tunnel makes a DHCPv4 query and 345 obtains the required address (192.108.119.33 for example). It should 346 use a special procedure to configure (lmn.xyz.com) with the new 347 address and update its own DNS: 349 33.119.108.192.in-addr.arpa name = lmn.xyz.com. 351 In case the dti-tunnel uses an additional DHCP(v4) feature that 353 Internet Draft IP Dynamic Tunneling Expire 6/99 355 enables to remotely configure the destination dual stack with the 356 newly assigned IPv4 address, it returns the IPv4 address to the 357 resolver and stops. If however a different procedure is used to 358 configure the remote destination host with the IPv4 address another 359 DNS update in the destination domain will also be needed: 361 lmn IN A 192.119.108.33 362 AAAA 363 3ffe:0305:1002:0001:0a00:2bff:fe1c:b099 365 Any dti-tunnel that will receive the packet will be able to find the 366 IPv6 address and establish the tunnel by consulting the destination 367 domain name. Again if the use of a DHCPv4 server driven procedure is 368 adopted then when a different dti-tunnel receives an IPv4 assignment 369 request for the IPv6 host it will try to configure remotely the 370 destination stack through DHCPv4. If an address is already assigned 371 for that host then the DHCPv4 configuration will fail and the current 372 IPv4 destination address will be returned in the error message (see 373 section 5). The dti-tunnel will return the address to the resolver 374 and the communication will start. 376 The usage of a new server driven DHCPv4 request will improve the 377 security environment since the dti-tunnel will not need to update the 378 destination domain name. 380 4.1 Path MTU 382 When packets are sent to the dti-tunnel the header length may change 383 the link MTU. This can be either detected by the PMTU detection or if 384 necessary by means of the IPv6 fragmentation extension. 386 5. Required Additional Features 388 The dti model will require some additional protocol features. Note 389 that most of them are also required in the AIIH proposal. 391 In the reverse direction (from IPv4 to IPv6) two new procedures are 392 required. The dti resolver needs to send a query to the dti-tunnel 393 asking for the assignment of an IPv4 address. The dti-tunnel has to 394 remotely configure the destination IPv4 stack with a new address. 395 This whole procedure could be done by the DHCPv4 protocol if an 396 additional feature enables the DHCPv4 server to initiate an IPv4 397 assignment procedure without a previous solicitation from the client. 399 An additional entry in the DNS for ipv4/ipv6 capability tunnel would 400 also be very useful (for all the proposals) in order to find for each 401 domain the closest tunneling equipment. 403 Internet Draft IP Dynamic Tunneling Expire 6/99 405 6. Bibliography 407 [AIIH] J. Bound. Assignment of IPv4 Global Addresses to IPv6 Hosts 408 (AIIH). Expired. 410 [SIIT] E. Nordmark,Stateless IP/ICMP Translator (SIIT), 411 , Work in progress, November 1998. 413 [NAT] G. Tsirtsis, P. Srishuresh. Network Address Translation - 414 Protocol Translation (NAT-PT). . 416 7. Authors Addresses 418 Laurent Toutain Hossam 419 Afifi ENST 420 Bretagne 2 rue de la chataigneraie BP 78 421 35512 Cesson Sevigne {toutain, 422 afifi}@rennes.enst-bretagne.fr Tel: (+33) 2 99 12 70 20 - 423 Fax: (+33) 2 99 12 70 30