idnits 2.17.1 draft-ietf-ngtrans-dstm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-ietf-ngtrans-dstm-00', but the file name used is 'draft-ietf-ngtrans-dstm-01' == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Client MUST not assume it can use the IPv4 Global Address until it has received a corresponding Reply to the Client Request, which is required for a Reconfigure Message too as specified in section 7.2. -- 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) == Unused Reference: '1' is defined on line 938, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 959, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 974, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 980, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 991, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-14 -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2065 (ref. '10') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (ref. '11') (Obsoleted by RFC 3007) ** Downref: Normative reference to an Informational RFC: RFC 2185 (ref. '12') == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-siit-03 -- Possible downref: Non-RFC (?) normative reference: ref. '18' ** Obsolete normative reference: RFC 2462 (ref. '19') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2373 (ref. '20') (Obsoleted by RFC 3513) Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jim Bound 2 NGTRANS Tools Working Group Compaq 3 Obsoletes draft-ietf-ngtrans-dstm-00.txt Laurent Toutain 4 Expires April 2000 Hossam Afifi 5 ENST Bretagne 7 Dual Stack Transition Mechanism (DSTM) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Distribution of this memo is unlimited. 40 Abstract 42 The initial deployment of IPv6 will require a tightly coupled use of 43 IPv4 addresses to support the interoperation of IPv6 and IPv4, within 44 an IPv6 Network. Nodes will be able to be deployed with IPv6 45 addresses, but will still need to communicate with IPv4 nodes that do 46 not have a dual IP layer supporting both IPv4 and IPv6. The Dual 47 Stack Transition Method (DSTM) provides a set of mechanisms to assign 48 temporary Global IPv4 Addresses to IPv6 nodes, use of dynamic tunnels 49 within an IPv6 Network to carry IPv4 traffic, and a defined set of 50 processes and architecture for the supporting infrastructure required 51 for this transition mechanism. 53 Table of Contents: 55 1. Introduction.................................................3 56 2. Terminology..................................................4 57 2.1 IPv6 AIIH Terminology.......................................4 58 2.2 Specification Language......................................4 59 3. DSTM Overview................................................5 60 4. Scenarios....................................................8 61 4.1 IPv6 node to an IPv4 node - Scenario 1......................9 62 4.2 IPv4 node to an IPv6 node - Scenario 2.....................10 63 4.3 IPv4 compiled application between to IPv6 nodes - Scenario 311 64 5. AIIH Server Design Model....................................11 65 5.1 AIIH DHCPv6/DNS Server.....................................12 66 5.1.1. Requesting an IPv4 Global Address.......................12 67 5.1.2 AIIH DHCPv6 Client IPv4 Global Address Requests..........13 68 5.1.3 AIIH DNS Query and DHCPv6 Processing.....................13 69 5.1.4. Cleaning up the AIIH IPv4 Assigned Address..............14 70 5.2 Links with other DNS.......................................14 71 6. DTI.........................................................15 72 6.1. DTI Architecture..........................................15 73 6.1 Assignment of the IPv4 address to the DTI..................16 74 6.2 Encapsulation of IPv4 packets..............................16 75 6.2.1 IPv6 source address......................................16 76 6.2.2 IPv6 destination address.................................16 77 6.2.2.1 Dynamic TEP (optional).................................17 78 6.2.2.2 Static TEP (mandatory).................................17 79 7. AIIH DHCPv6 Requirements....................................18 80 7.1 DHCPv6 IPv4 Global Address Extension.......................18 81 7.2 AIIH Server Processing of an IPv4 Global Address Extension.18 82 7.3 AIIH Client Processing of an IPv4 Global Address Extension.19 83 8. Security Considerations.....................................19 84 9. Year 2000 Considerations....................................20 85 Changes from draft 00 to draft 01..............................20 86 References.....................................................20 87 1. Introduction 89 The initial deployment of IPv6 will require a tightly coupled use of 90 IPv4 addresses to support the interoperation of IPv6 and IPv4, within an 91 IPv6 Network. Nodes will be able to be deployed with IPv6 addresses, 92 but will still need to communicate with IPv4 nodes that do not have a 93 dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition 94 Method (DSTM) provides a set of mechanisms to assign temporary Global 95 IPv4 Addresses to IPv6 nodes, use of dynamic tunnels within an IPv6 96 Network to carry IPv4 traffic, and a defined set of processes and 97 architecture for the supporting infrastructure required for this 98 transition mechanism. In the dual stack approach defined in RFC 1933, 99 every node needs both an IPv4 and an IPv6 address to exchange 100 information with the IPv4 and the IPv6 world. Use of the dual stack 101 approach can be acceptable during a short period for testing IPv6 102 applications and initial network deployment, but does not scale since it 103 does not solve the lack of IPv4 addresses, once IPv6 begins production 104 deployment. 106 The DSTM assigns, when needed an IPv4 address to an IPv6 host. This will 107 allow either IPv6 hosts to communicate with IPv4-only hosts, or for 108 IPv4-only applications to run without modification on an IPv6 host. This 109 allocation mechanism is coupled with the ability to perform dynamic 110 tunneling of an IPv4 packet inside an IPv6 packet, to suppress the 111 exposure of IPv4 native packets within some areas of an IPv6 network. 112 This will simplify the network management of IPv6 deployment, since 113 routers need only IPv6 routing tables to move IPv4 packets across an 114 IPv6 network. 116 DSTM is targeted to help the interoperation of IPv6 newly deployed 117 networks with existing IPv4 networks. The main theme of DSTM is to avoid 118 situations where the introduction of IPv6 in a network, is delayed 119 because IPv6 will have to interoperate with IPv4 networks and 120 applications for some time. 122 DSTM also assumes that a users objective of deploying an IPv6 network is 123 to reduce the need and reliability on IPv4 within a portion of their 124 network. In addition the IPv4 globally routable address space available 125 to the network is a scarce resource, and the user does not want to 126 deploy DHCPv4[16] to assign temporary IPv4 addresses to IPv6 nodes, and 127 would rather require those nodes to use IPv6 to obtain or be given the 128 IPv4 temporary addresses from DHCPv6. Also to reduce the IPv4 129 applications a user has to support to obtain a temporary IPv4 compatible 130 address the client only has to run a DHCPv6 client process. 132 DSTM is composed of a DHCPv6 server tightly coupled with a DNS server 133 that provides for the Assignment of IPv4 Global Addresses to IPv6 Hosts 134 (AIIH Server). This AIIH server will allocate temporary IPv4 addresses 135 to IPv6 hosts using DHCPv6. This server will also be used to maintain 136 the mapping between the allocated IPv4 address and the permanent IPv6 137 address of the host. Every IPv6 host will have an IPv4 interface called 138 DTI (Dynamic Tunneling Interface) designed to encapsulate IPv4 packets 139 into IPv6 packets and resolve the address space mechanics, between IPv4 140 and IPv6. 142 DSTM has a mandatory part and an optional part. The mandatory part is 143 for IPv6 nodes on the Intranet to be able to communicate with nodes on 144 the IPv4 Internet or on the internal Intranet through the DSTM 145 mechanisms specified in this document. The optional part permits IPv4 146 nodes on the Internet, to communicate with an IPv6 node by DSTM 147 assigning an IPv6 node a temporary IPv4 address, when an IPv4 nodes 148 attempts communications with the IPv6 node. This is optional because 149 there are security ramifications that are not addressed within this 150 specification. This optional behavior MAY be permitted on an Intranet 151 so IPv4 nodes can communicate with DSTM participating IPv6 nodes. 153 The specification will begin by defining the terminology (section 2), 154 then section 3 provides a technical overview of the DSTM methodology as 155 a transition mechanism. Then in section 4 we discuss three scenarios 156 depicting the use of DSTM mechanisms in different configuration 157 settings. Section 5 describes the relation between DHCPv6 and DNS 158 Servers, which constitutes the AIIH Server. Section 6 discusses the DTI 159 architecture and mechanisms. Section 7 discusses the DHCPv6 extension 160 requirements. 162 2. Terminology 164 2.1 IPv6 AIIH Terminology 166 DSTM Domain The network areas on an Intranet where an 167 AIIH Server has access to IPv6 nodes participating 168 in DSTM for that network. 170 DSTM Border Router A borderd router within a DSTM domain and 171 an IPv4-ONLY domain (Internet or Intranet). 173 IPv6 Protocol Terms: See [3] 175 IPv6 Transition Terms: See [15] 177 DHCPv6 Terms: See [4,5] 179 DTI: Dynamic Tunneling Interface. An interface 180 encapsulating IPv4 packets into IPv6 packets. 182 AIIH Server: A Server that supports DNS [2] and DHCPv6 [4,5] 183 and communications between DNS and DHCPv6, which 184 is implementation defined. 186 IPv4 Global Address: An IPv4 address that is globally routable on 187 the Internet. 189 Tunnel End Point (TEP) Destination of the IPv6 packet containing an 190 IPv4 packet. 192 2.2 Specification Language 194 In this document, several words are used to signify the requirements 195 of the specification, in accordance with RFC 2119 [9]. These words 196 are often capitalized. 198 MUST This word, or the adjective "required", means that 199 the definition is an absolute requirement of the 200 specification. 202 MUST NOT This phrase means that the definition is an absolute 203 prohibition of the specification. 205 SHOULD This word, or the adjective "recommended", means 206 that there may exist valid reasons in particular 207 circumstances to ignore this item, but the full 208 implications must be understood and carefully 209 weighed before choosing a different course. 210 Unexpected results may result otherwise. 212 MAY This word, or the adjective "optional", means that 213 this item is one of an allowed set of alternatives. 214 An implementation which does not include this option 215 MUST be prepared to interoperate with another 216 implementation which does include the option. 218 silently discard 219 The implementation discards the packet without 220 further processing, and without indicating an error 221 to the sender. The implementation SHOULD provide 222 the capability of logging the error, including the 223 contents of the discarded packet, and SHOULD record 224 the event in a statistics counter. 226 3. DSTM Overview 228 DSTM as discussed in the introduction are a set of mechanisms which use 229 existing protocols to support the operations within DSTM. DSTM does not 230 specify a protocol, except for defining some new DHCPv6 Extensions for 231 transition. 233 The reason for DSTM is to provide IPv6 nodes a means to acquire an IPv4 234 address, for communications with IPv4-only nodes or IPv4 applications. 236 The core assumption within this mechanism is that it is totally 237 transparent to applications, which can continue to work with IPv4 238 addresses. It is also transparent to the network which carry only IPv6 239 packets. It is the authors viewpoint that the user in this case, has 240 deployed IPv6 to support end-2-end computing, without translation. This 241 aspect is fundamental during a transition process to gurantee that every 242 existing application will continue to work. 244 The DSTM model is as follows: 246 - The DSTM domain is within an Intranet not on the Internet. 248 - IPv6 nodes do not maintain IPv4 addresses except on a temporary basis, 249 to communicate with IPv4-only and IPv4 Applications. 251 - Standard DNS is used to cause access to a DNS server that will 252 know the request is an IPv4 address for an IPv6 node above. 254 - Standard DHCPv6 is used to support the extensions to provide 255 and accept from DHCPv6 clients Global IPv4 Addresses. 257 - The network for the IPv6 nodes would like to keep IPv4 routing 258 tables to a minimum and use IPv6 routing whenever possible, 259 as an initial transition mechanism for IPv6. 261 - Once IPv6 nodes have IPv4 addresses Dynamic Tunneling is used 262 to move the IPv4 packet within IPv6 to an IPv6 TEP, where the 263 packet will be forwarded using IPv4. DHCPv6 is used to provide 264 TEPs to IPv6 nodes supporting DTI. 266 - Implementation defined software must exist within DSTM to support 267 the following processes: 269 o Software on a DNS implementation to inform a DHCPv6 server 270 that a request is being made for an IPv4 address for an 271 IPv6 node. This specifications initial assumption is that 272 the DNS and DHCPv6 are co-located on the same node. This 273 eliminates the need for a network protocol for DHCPv6 274 and DNS to communicate over a wireless or wired medium. 276 o Software on a DHCPv6 implementation to support speaking 277 with a DNS implementation for the above purposes. In addition 278 software within DHCPv6 to maintain configuration information 279 about tunnel endpoints for encapsulating IPv4 packets between 280 IPv6 nodes that can forward IPv4 packets to an IPv4 routing 281 realm. 283 o The DHCPv6 and DNS processes and implementation defined parts 284 above are collectively named the AIIH Server in this model 285 and the specification. 287 o Software within an IPv6 node to support the dynamic tunneling 288 mechanisms in this specification to encapsulate IPv4 packets 289 within IPv6 to send IPv4 packets on an IPv6 node. In addition 290 a daemon must exist to access an AIIH server for addresses 291 and TEPs. 293 o Software in DSTM domain routers to recall or be able to cache 294 the association of IPv6 and IPv4 addresses of nodes during 295 decapsulation and encapsulation. 297 A simplistic overview of DSTM is as follows: 299 ----------------------------------------------- 300 | IPv4 Internet/Intranet 301 DSTM Domain Intranet | IPv4 Applications 302 | Domain 303 _____________________ | 304 | | | 305 | AIIH Server | | 306 | | | 307 | DHCPv6 Server | | 308 | DNS Server | | 309 |_____________________| | 310 ^ ^ | 311 | | | 312 __________________ | |incoming _|_______ 313 | | | |optional | | 314 | IPv6/IPv4 Node | | --------->| DSTM | 315 |------------------| | | Router | 316 | AIIH Daemon |<------- | IPv6 | 317 |------------------| outgoing mandatory | & | 318 | DTI/Route |<-------------------->| IPv4 | 319 ------------------- --------- 320 | 321 ---------------------------------------------- 323 Both the IPv6/IPv4 node and the DSTM Router have occasion to access the 324 AIIH Server. For more depth please read the following sections of this 325 specification. 327 For an IPv6 host to participate in the AIIH mechanism it MUST have a 328 dual IP layer, supporting both an IPv4 and an IPv6 stack. This 329 specification makes the assumption that for IPv6 initial deployment host 330 nodes will not be shipped with an IPv6-only stack implementation. For 331 embedded system type nodes that support only an IPv6 stack, AIIH cannot 332 be a solution. 334 4. Scenarios 336 These different scenarios illustrate interoperability problems occurring 337 during the interoperation between IPv4 and IPv6. IPv6 end nodes have a 338 dual stack, but only the IPv6 stack is configured through an IPv6 auto- 339 configuration mechanism. Intermediary routers have only an IPv6 routing 340 table configured. 342 In the examples below, the following notation will be used: 344 X will designate an IPv6 host with a dual stack, X6 will be the IPv6 345 address of this host and X4 the IPv4 address 346 Y will designate a DSTM border router at the boundary between an 347 IPv6 DSTM domain and an IPv4-only domain. 348 Z will designate an IPv4-only host and Z4 its address. 349 ==> means an IPv6 packet 350 --> means an IPv4 packet 351 ++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet 352 ..> means a DNS query or response. The path taken by this 353 packet does not matter in the examples 354 "a" means the DNS name of a host 356 4.1 IPv6 node to an IPv4 node - Scenario 1 358 This scenario describes the case where an application (either compiled 359 for the IPv6 or IPv4 API) running on an IPv6 host (X6) wants to 360 establish a session with an IPv4 application on an IPv4-only host (Z4). 362 The IPv6 host is configured with the IPv6 address of a tunnel end-point, 363 where an IPv4 encapsulated packet will be sent. 365 The IPv4 routing table of node X is configured to send IPv4 packets to 366 the DTI interface. 368 AIIH TB Z4 369 X6 Y6/Y4 370 | | | 371 |. . . . . . . .> Z | - X6 asks the DNS for an AAAA for "Z" 372 |<. . . . . . . . error | - the DNS answers with an error 373 |. . . . . . . .> Z | - X6 asks for the A RR for "Z" 374 |<. . . . . . . . Z4 | - the answer is Z4 375 | | | 376 | | | - The application sends its first IPv4 377 | | | packet which arrives to the DTI interface 378 | | | (If the application is compiled for IPv6 379 | | | this can be done through an IPv4-mapped 380 | | | address). 381 | | | 382 | | | - X6 needs an IPv4 address (first use) 383 |====> | | - X6 queries the DHCPv6 server for an 384 | | | IPv4 address using DHCPv6 385 |<==== | | - The DHCPv6 server locates the client 386 | | | and provides temporarily an IPv4 387 | | | address. 388 | | | - the DHCPv6 Server sends a Dynamic Update 389 | | | to the DNS to register the association 390 | | | x4<->x6. 391 | | | 392 |+++++++++++>| | - The DTI sends the IPv6 packet to the 393 | | | tunnel end-point 394 | |----------->| - Y sends the packet to the destination Z4 395 | | | - Y MAY cache the association between 396 | | | the IPv4 and IPv6 address of X. 398 When Z answers two cases are possible either the packet comes back 399 through Y and Y has cached the association between the IPv4 and the IPv6 400 address of X, or the packet arrives through another router within the 401 IPv6 network. 403 For the first case, Y simply encapsulates the IPv4 packet inside an IPv6 404 packet to X6. If the IPv4 packet size is greater than the MTU inside the 405 IPv6 DSTM domain, the packet is fragmented, if the IPv4 DF bit is set to 406 0. Otherwise an ICMP message is sent to Z4. This case is mandatory for 407 DSTM support. 409 Also in the above case it is not required that the AIIH tightly coupled 410 paradigm between DHCPv6 Server and DNS Server exists in the deployment 411 of DSTM. 413 4.2 IPv4 node to an IPv6 node - Scenario 2 415 This example covers any scenario where an IPv4-only host wants to 416 establish a session with an IPv6 host, which does not have an IPv4 417 address. This case is optional and not recommended without strong 418 security when the IPv4-Host is on the Internet, and lesser security when 419 the IPv4-Host is on the IPv6 nodes Intranet. 421 No modification can be made to the IPv4 host or to the application, 422 especially the IPv4-application cannot be recompiled. 424 DNSv4 AIIH Y4 Z4 425 DNSv6 Y6 426 | <. . . . . . . . . | - ask for the IPv4 address of X 427 | | | - this request arrives to the AIIH Server 428 | | | 429 | | | - if node X does not have already a 430 | | | temporary IPv4 address assigned then the 431 | | | AIIH allocates an IPv4 address and 432 |<===== | | registers it in the DNS. 433 | . . . . . . . . . >| - AIIH returns the IPv4 address to node Z4 434 | | | 435 | |<-----------| - Z4 sends an IPv4 packet which arrives at Y4 436 | <=====| | - Y4 asks the AIIH server for the IPv6 address 437 | | | corresponding to X4. 438 | =====>| | - AIIH server responds 439 |<++++++++++ | | - The packet is tunneled to node X6 440 | | | 442 4.3 IPv4 compiled application between to IPv6 nodes - Scenario 3 444 To maintain compatibility between two IPv4 applications, an IPv4 445 application running on an IPv6 host may wish to send IPv4 packets to 446 another application running also on an IPv6 host, called Z6. To allow 447 end-to-end communication without the use of a static Tunnel End Point, 448 nodes can use the same mechanism as the DSTM border router in the 449 previous example. This means that a DTI interface can ask the AIIH 450 server to perform address resolution. If the resolution fails, the DTI 451 interface can still use the static TEP. This case is an optional 452 mechanism in DSTM. 454 AIIH 455 X6 Z6 456 | | 457 |............> | - X asks for the IPv4 address of Z. 458 | ============>| - AIIH Server assigns an IPv4 address to Z 459 | | - AIIH registers this address to 460 | | its DNS server 461 |<........... | - Z4 is returned to X 462 | | - The IPv4 address of Z is used by the 463 | | application, which sends an IPv4 packet 464 | | to the IPv6 IP implementation 465 | | - the routing table has been previously 466 | | configured in X to route 467 | | IPv4 through DTI 468 |===========> | - DTI receives its first packets, asks 469 |<========== | the AIIH server to assign 470 | | the IPv4 address to the DTI interface 471 | | - AIIH registers this address 472 | | to the DNS 473 | | - DTI has to find the IPv6 address 474 | | of the tunnel end-point for Z4 475 |===========> | - DTI daemon asks the AIIH Server for the 476 |<=========== | temporary address of Z4 477 |++++++++++++++++++++++++>| - DTI tunnels the packet to Z6 479 5. AIIH Server Design Model 481 The design model provides two mechanisms (one mandatory and one 482 optional) to assign an IPv6 host an IPv4 address. The assumption in this 483 specification is that a site has a certain number of IPv4 Global 484 Addresses, which can be assigned within the network on a temporary basis 485 for use by hosts in the site. 487 The first mechanism is mandatory and allow an host to request an IPv4 488 address that is globally routable (cf. scenario 1). 490 The second mechanism is optional and is descibed in scenario 2 and 3. It 491 allows an AIIH Server to assign an IPv6 host a globally routable IPv4 492 address using the DHCPv6 Reconfigure Message. 494 5.1 AIIH DHCPv6/DNS Server 496 The AIIH Server supports a co-located DHCPv6 and DNS Server and other 497 implementation defined software functions. The AIIH server configuration 498 files and database is not defined in this specification. There can be 499 one or many AIIH Servers on an Intranet and how they maintain 500 consistency and Tunnel End Point configurations for IPv6 links is 501 implementation defined. 503 The AIIH Server is an implementation where DNS, DHCPv6, and 504 communications between those two applications exists. These applications 505 MAY be co-located on the same host, but that is not a requirement of 506 this specification. How DNS and DHCPv6 communicate is implementation 507 defined . The AIIH Server SHOULD support the following operations: 509 1. MAY act as the Authoritative DNS Name Server for a set of IPv6 510 hosts that can be queried for IPv4 Global Addresses. 512 2. MAY communicate information between the AIIH DNS server and the 513 AIIH DHCPv6 Server. 515 3. An AIIH DHCPv6 Server MUST maintain a pool of IPv4 Global 516 Addresses in an implementation defined manner. 518 4. An AIIH DHCPv6 Server SHOULD maintain Tunnel End Points for 519 IPv6 Links in an implementation defined manner. 521 5. An AIIH DHCPv6 Server MAY process DNS AIIH IPv6 host DNS queries, 522 and Reconfiguring IPv6 hosts to assign IPv4 Global Addresses to 523 their interfaces. 525 6. MUST support DHCPv6 Client's requesting IPv4 Global Addresses. 527 7. MAY dynamically update DNS with an IPv4 Global Address for 528 an IPv6 host that supports IPv4/IPv6. 530 The tight coupling between DHCPv6 and DNS is only needed for the 531 optional scenarios 2 and 3, and not needed for scenario 1. 533 An AIIH Server MUST support a dual IPv4/IPv6 network layer and 534 implementation of IPv4/IPv6. 536 The IPv4 address allocation can be triggered by two events. The first 537 one is when an IPv6 host requests through DHCPv6 an IPv4 address to 538 configure its IPv4 stack, which is mandatory. The second event happens 539 when a DNS A query is made for a node that only has an IPv6 address (see 540 section 5.2) fails to respond to a DNS A RR query, which is optional. 542 5.1.1. Requesting an IPv4 Global Address 544 An IPv4/IPv6 host can request an IPv4 Global Address by using the IPv4 545 Global Address Extension defined in section 7. The IPv4/IPv6 host MUST 546 support DHCPv6 [4] and the DHCPv6 Extensions [5]. The Requests/Response 547 Model of DHCPv6 will process this new extension as any other extension. 548 There is no need to define a new message type for DHCPv6 for this 549 processing or add to the DHCPv6 protocol. 551 Once the host has obtained an IPv4 Global Address it MUST NOT update DNS 552 to reflect an A type or PTR type record for this address. The reason is 553 that the intent is to provide a host with this temporary address to use 554 for communications with an IPv4 node. Once the reason for obtaining an 555 IPv4 Global Address has been satisfied the host MUST Release this IPv4 556 Global Address from the AIIH DHCPv6 Server implementation. 558 On the other hand, if the address lifetime is about to expire, the AIIH 559 client may send another request to the AIIH Server to keep this address 560 assigned. 562 5.1.2 AIIH DHCPv6 Client IPv4 Global Address Requests 564 An AIIH DHCPv6 Server will receive DHCPv6 Requests for IPv4 Global 565 Addresses from IPv6 hosts. The AIIH DHCPv6 Server will determine if an 566 address is available and assign the address to the DHCPv6 Client as 567 specified in section 7 of this specification. 569 5.1.3 AIIH DNS Query and DHCPv6 Processing 571 Once the AIIH DNS finds the IPv6 host being queried the AIIH DNS 572 requests from its corresponding AIIH DHCPv6 Server to assign an IPv4 573 Global Address to the IPv6 host being queried. 575 The AIIH DHCPv6 Server will look within its pool of IPv4 Global 576 Addresses for an address and if a Tunnel End Point address is required 577 for the IPv6 host to reach the router to route packets onto the 578 Internet. If an address is available the DHCPv6 Server will send a 579 DHCPv6 Reconfigure Message to the IPv6 node to temporarily assign the 580 node an IPv4 Global Address (see section 7). 582 Once the AIIH DHCPv6 server is certain that the IPv6 host has assigned 583 the address to an interface, the AIIH DHCPv6 Server responds back to the 584 corresponding AIIH DNS Server with the IPv4 Global Address assigned to 585 the IPv6 host being queried, or that an address could not be assigned to 586 this IPv6 host. 588 It is important to wait for an acknowledgment from the client to be sure 589 that the host is up before validating an IPv4 address has been assigned. 590 Nevertheless, this could introduce a delay incompatible with the timer 591 used during a DNS query. The dialog could be modified. Just after the 592 DNSv6 temporary IPv4 address assignment, the AIIH DNS returns this 593 address but with a small TTL. The real TTL will be used if the 594 acknowledgment is received, otherwise the IPv4 address is deprecated for 595 a some period of time. 597 The AIIH DNS Server will now respond to the IPv4 DNS Query as the 598 Authoritative DNS Name Server with an address or host not found. 600 The AIIH DHCPv6 Server MAY send a dynamic update to DNS [6] to add an A 601 type record to the Primary DNS Server, where the query came from to the 602 AIIH DNS Server. The Time-To-Live (TTL) field in the update MUST NOT be 603 set to be greater than the valid lifetime for the IPv4-Compatible 604 address in the DHCPv6 Extension provided to the DHCPv6 Client. It is 605 highly recommended to not update the DNS with an A record for the IPv6 606 host, unless that IPv6 host provides a permanent IPv4 Application 607 service needed by IPv4 hosts. 609 5.1.4. Cleaning up the AIIH IPv4 Assigned Address 611 Once the IPv4 address expires, the DHCPv6 Server will permit the IPv4 612 address to be reused. But before the address can be reused the DHCPv6 613 Server MUST delete the IPv4 address from the Primary DNS Server, through 614 the Dynamic Updates to DNS mechanism, if an A record was added to the 615 relative Primary DNS Server. 617 If an AIIH client wants to keep the temporary IPv4 address after its 618 expiration time, it MUST send a DHCPv6 request before the address 619 expires. 621 5.2 Links with other DNS 623 When the Primary DNS Server for the IPv6 node receives the IPv4 hosts 624 query, it will do a DNS search for that IPv6 host and find that there is 625 an Authoritative DNS Server for that specific DNS A record, which 626 represents an IPv6 host. That DNS Server will be one part of the AIIH 627 Server software. After the AIIH DHCPv6 Server assigns the IPv6 node a 628 temporary IPv4 Global Address, the AIIH DNS Server will respond to the 629 original IPv4 DNS query authoritatively with an IPv4 Global Address for 630 the IPv6 host or return host Not Found. 632 For Example: 634 IPv4 node "v4host.abc.com" queries for "v6host1.xyz.com" 636 Query reaches Primary DNS Server for "v6host1.xyz.com". 638 xyz.com. IN SOA primary.xyz.com. etc etc. 639 . 640 . 641 xyz.com IN NS primary.xyz.com 642 aiih.xyz.com IN NS v6trans.aiih.xyz.com 643 . 644 . 645 primary.xyz.com IN A 202.13.12.6 646 v6trans.aiih.xyz.com IN A 202.13.12.8 647 . 648 . 649 . 650 v6host1.xyz.com IN CNAME v6host1.aiih.xyz.com 651 v6host2.xyz.com IN CNAME v6host2.aiih.xyz.com 652 v6host3.xyz.com IN CNAME v6host3.aiih.xyz.com 654 DNS query will end up going to the authoritative server 655 v6trans.aiih.xyz.com looking for v6host1.aiih.xyz.com. This permits 656 the AIIH Server to now process a request for an IPv4 Global Address 657 for an IPv6 host that had no IPv6 DNS AAAA Record [18]. 659 If DTI is present, the reverse DNS must be linked to the pool of 660 addresses managed by the AIIH Server. 662 6. DTI 664 6.1. DTI Architecture 666 The DTI interface will be used to send IPv4 packets during the 667 interoperation of IPv4 and IPv6. The routing table of the host forwards 668 the information to that interface. It is possible to send all the IPv4 669 packets through this interface by using only the default prefix. 671 The DTI interface is placed between the IPv4 API and the IPv6 layer, as 672 shown in the following figure, the architectural model assumes a BSD 673 UNIX type platform. 675 (-------------) 676 ( AIIH daemon ) 677 (-------------) 679 +------------||------------+------------||------------+--||--+ 680 | IPv6 API | IPv4 API | PF_ | 681 | | | ROUTE| 682 | +--------------------------+ | 684 | | | 685 +-----------------------------------------------------+------+ 687 On every IPv6 node an AIIH daemon is running to manage the allocation of 688 the IPv4 addresses need. The daemon MAY also perform the address 689 resolution when needed. 691 The following example gives the configuration of an IPv4 routing table 692 with DTI. 694 All IPv4 packets except those to the 192.44.77/24 prefix are sent 695 through the dti0 interface. They will be encapsulated into IPv6 packets. 696 Packet to the 192.44.77/24 prefix will be sent natively on the link. 698 Routing tables 700 Internet: 701 Destination Gateway Flags Refs Use Mtu Netif Expire 702 default link#1 UGSc 3 0 1460 dti0 703 192.44.77.0/24 192.44.77.3 UC 0 0 1500 le0 - 704 192.44.77.3 8:0:2b:1c:af:15 UHLW 4 0 1500 le0 649 705 127.0.0.1 127.0.0.1 UHl 1 102 16384 lo0 706 6.1 Assignment of the IPv4 address to the DTI 708 When the DTI interface is activated, no IPv4 address is given to that 709 interface. If the interface is active, but has no IPv4 address, when it 710 has to send the first IPv4 packet, the interface sends a request to the 711 daemon. The daemon will send a DHCPv6 request to the AIIH server to get 712 the temporary IPv4 address. 714 An IPv6 node can know it needs an IPv4 address if the DNS resolver on 715 the node knows that the destination address will be an IPv4 address. 716 Once the resolver knows this then a query to the interface index of the 717 node will inform the IPv6 if it has an IPv4 interface configured. This 718 is just one example of how an implementation can determine if the AIIH 719 daemon must be called. 721 6.2 Encapsulation of IPv4 packets 723 The protocol value for IPv4 encapsulation is 4 (as for IPv4 tunneling 724 over IPv4). When a tunneled packet arrives to the IPv6 destination, the 725 IPv6 header is removed and the packet is processed by the IPv4 layer. 726 The receiver SHOULD cache the association between the IPv4 and IPv6 727 source address. 729 6.2.1 IPv6 source address 731 The IPv6 source address of an encapsulated packet will be the IPv6 732 address of the interface on which the IPv6 packet will be sent. 734 6.2.2 IPv6 destination address 736 When a DTI has to encapsulate an IPv4 packet into an IPv6 packet. The 737 DTI as to find the IPv6 address for the destination, called in this 738 document a Tunnel End Point (TEP). The tunnel end point can be directly 739 the host destination or, if the destination host is IPv4-only, the IPv6 740 address of an IPv4/IPv6 router. 742 This document propose two ways for resolving the tunnel end point. The 743 first one is static and is returned in the DHCPv6 packet when a 744 temporary IPv4 address is allocated to the interface or by static 745 configuration of the node. A DTI MUST allow static TEP. The second one 746 is optional and uses a query to the AIIH to find dynamically the TEP 747 associated with the IPv4 address. 749 The IPv6 host MUST allow static TEP. DSTM border routers SHOULD use 750 dynamic TEP, but in the case of a single homed network, and for exiting 751 traffic only, the association of the IPv4 and IPv6 source address of 752 incoming packets MAY be done on the fly by reading packets headers. 754 For a host in the case of the failure of the dynamic TEP, static TEP 755 SHOULD be used. 757 For DSTM border routers, failure of the dynamic TEP SHOULD generate an 758 ICMPv4 host unreachable message. 760 6.2.2.1 Dynamic TEP (optional) 762 Dynamic TEP determination is similar to MAC address resolution when 763 sending a IP packet over an Ethernet link. The only difference is that 764 no broadcast facilities can be used to find a TEP. 766 In the UNIX operating system, this resolution should not be done in the 767 kernel. Some operating systems offer the possibility to do external 768 resolution. A query is sent to a daemon in the user space. This daemon 769 does a DHCPv6 query to find the TEP. In the rest of this document we 770 will consider this architectural model, but this is not a limitation for 771 implementing DTI. 773 When the resolver daemon receives a query from the kernel, it sends a 774 DHCPv6 query to the AIIH Server to get the IPv4 address for this host. 776 Static TEP cache contains the IPv6 address of a node inside the network. 777 The IPv6 address is stored in a cache for a duration indicated in the 778 DHCPv6 message. 780 6.2.2.2 Static TEP (mandatory) 782 Static TEP may be returned by the AIIH Server with the temporary IPv4 783 address. This TEP is used when the dynamic TEP resolution fails or has 784 not been activated. This will be the case when the DTI daemon asks for 785 an address not registered in the AIIH Server (for example an IPv4 786 address outside of the DSTM cloud). 788 Static TEP contains the IPv6 address of a DSTM border router. Static TEP 789 records are stored as long as the temporary IPv4 address is assigned to 790 the interface in case of DHCP configuration, and as long as the DTI 791 interface is active in case of manual configuration. 793 7. AIIH DHCPv6 Requirements 795 The AIIH DHCPv6 processes will use the DHCPv6 protocol and extensions to 796 communicate between the AIIH DHCPv6 Server and the DHCPv6 Client. A new 797 extension is required for DHCPv6 (section 4.1) to support AIIH. But 798 there are some additional requirements placed on the AIIH processes that 799 are not specific to the DHCPv6 protocol, but as transition and 800 interoperation mechanisms for the IPv6 hosts. 802 7.1 DHCPv6 IPv4 Global Address Extension 804 The DHCPv6 IPv4 Global Address Extension informs a DHCPv6 Server or 805 Client that the IPv6 Address Extension [5] following this extension will 806 contain an IPv4- Compatible Address [20], or is a Request for an IPv4 807 Global Address from a Client, or a Reply assigning a Global IPv4 Address 808 to a Client from a Server. The extension can also provide an IPv4- 809 Compatible or IPv6 address to be used as the Tunnel End Point to 810 encapsulate an IPv6 packet within IPv4, or an IPv4 packet within IPv6. 812 0 1 2 3 813 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type | Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Tunnel End Point | 818 | (If Present) | 819 | (16 octets) | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Type: TBD 823 Length: 0 or 16 824 Tunnel End Point: IPv6 Address if Present 826 An IPv4 Global Address Extension MUST only apply to the extension 827 following and not to any additional extensions in the DHCPv6 828 protocol. 830 7.2 AIIH Server Processing of an IPv4 Global Address Extension 832 When a DHCPv6 Server receives an IPv4 Global Address Extension it MUST 833 assume that the next extension in a DHCPv6 Request or Release Message; 834 the Client is either Requesting an IPv4 Global Address or Releasing an 835 IPv4 Global Address. If an address is present in either of these 836 messages it will be in the form of an IPv4-Compatible Address. 838 A DHCPv6 Server MAY send a Client a Reconfigure message to provide the 839 Client an IPv4-Compatible address. The Client will recognize this by 840 processing the IPv4 Global Address Extension. 842 The Server will no a priori the IPv6 routable address, when sending a 843 Reconfiguration Message, of a Client within the Intranet, and should use 844 that address with its own IPv6 address as the transaction binding cache 845 until the DHCPv6 Client/Server protocol processing has completed. 847 The Server will look in its implementation defined IPv4 Global Address 848 configuration to determine if a Tunnel End Point is required for a 849 specific IPv6 Address Prefix. If that is the case the Server will put 850 the address for the Tunnel End Point in the IPv4 Global Address 851 Extension. If the Tunnel End Point address is an IPv4 address the Server 852 will put that address in the extension as an IPv4-Compatible address. 854 7.3 AIIH Client Processing of an IPv4 Global Address Extension 856 When a DHCPv6 Client receives an IPv4 Global Address Extension it MUST 857 assume that the next extension in a DHCPv6 Reconfigure or Reply Message; 858 the Server is either assigning an IPv4 Global Address or supplying an 859 IPv4 Global Address. The address present in either of these messages 860 will be in the form of an IPv4-Compatible Address. 862 When the Client supplies an IPv4 Global Address as a Request or Release 863 it MUST represent that address as an IPv4-Compatible Address. 865 The Client MUST not assume it can use the IPv4 Global Address until it 866 has received a corresponding Reply to the Client Request, which is 867 required for a Reconfigure Message too as specified in section 7.2. 869 Once the Client is assured it can use the IPv4 Global Address it can 870 perform the following operations: 872 1. In an implementation defined manner the Client MUST assign the 873 address to an interface, supporting the Client's IPv4 stack 874 implementation. 876 2. In an implementation defined manner the Client MUST create an entry 877 as an IPv4-Compatible Address supporting the processing required 878 for an IPv6 address regarding the valid and preferred lifetimes 879 as specified in IPv6 Addrconf [19]. Once the IPv4-Compatible 880 address valid lifetime expires the IPv4 address MUST be deleted 881 from the respective interface and a DHCPv6 Release Message 882 MUST be sent to the AIIH DHCPv6 Server to delete the IPv4 Global 883 Address from the Servers bindings. 885 3. If a Tunnel End Point address is provided in the IPv4 Global 886 Address Extension, the Client MUST create a configured tunnel 887 to the Tunnel End Point address, in an implementation defined 888 manner. If the Tunnel End Point address is an IPv4-Compatible 889 address then the encapsulation is IPv4 within IPv4, if the 890 Tunnel End Point is an IPv6 address then the encapsulation 891 is IPv6 in IPv4. These encapsulation mechanisms are defined 892 in other IPv6 specifications [13, 15]. 894 8. Security Considerations 896 The AIIH mechanism can use all the defined security specifications for 897 each functional part of the operation. For DNS the DNS Security 898 Extensions/Update can be used [10, 11], for DHCPv6 the DHCPv6 899 Authentication Message can be used [5], and for communications between 900 the IPv6 node, once it has an IPv4 address, and the remote IPv4 node, 901 IPSEC [8] can be used as AIIH does not break secure end- to-end 902 communications at any point in the mechanism. 904 9. Year 2000 Considerations 906 There are no Year 2000 issues in this specification. 908 Changes from draft 00 to draft 01 910 1. Added text explaining why the draft does not use DHCPv4 to assign 911 IPv4 compatible addresses to the "Introduction". 913 2. Defined what is mandatory and what is optional and added relative 914 text in various places to clarify this change. And added RFC 915 2119 adjectives to the spec where appropriate. 917 3. Scenario 1 where IPv6 node wants to communicate with IPv4 918 node is mandatory. 920 4. Scenarios 2 and 3 are now optional where an IPv6 node is 921 assigned an IPv4 compatible address because an external 922 IPv4 node is attempting communications with the IPv6 node. 924 5. For scenario 1 DHCPv6 is only needed for DSTM and not the 925 tightly coupled paradigm of a co-existent DHCPv6 and 926 DNS server. Also added mandatory and optional to the 927 DSTM AIIH/NODE/ROUTER Diagram. 929 6. Made Static Tunnel Endpoints mandatory and Dyanmic Tunnel 930 End Points optional. 932 7. Fixed DHCPv6 Reconfigure statements to take into account 933 changes to the Reconfigure message in the DHCPv6 working 934 group, to support AIIH processing. 936 References 938 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 939 13, RFC 1034, USC/Information Sciences Institute, November 1987. 941 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 942 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 943 November 1987. 945 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 946 Architecture", RFC 2460, December 1998. 948 [4] J. Bound and C. Perkins. Dynamic host Configuration Protocol 949 for IPv6. draft-ietf-dhc-dhcpv6-14.txt March 1999 (work 950 in progress). 952 [5] C. Perkins. Extensions for the Dynamic host Configuration 953 Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-11.txt March 954 1999. (work in progress). 956 [6] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 957 to the Domain Name System (DNS). RFC 2136, April 1997. 959 [7] William R. Cheswick and Steven Bellovin. Firewalls and Internet 960 Security. Addison-Wesley, Reading, MA 1994 (ISBN: 961 0-201-63357-4). 963 [8] IPSEC - This needs to include the Arch, Auth, and ESP specs. 965 [9] S. Bradner. Key words for use in RFCs to indicate Requirement 966 Levels. RFC 2119, March 1997. 968 [10] D. Eastlake and C. Kaufman. Domain Name System Security 969 Extensions. RFC 2065, January 1997. 971 [11] D. Eastlake. Secure Domain Name System Dynamic Update. 972 RFC 2137, April 1997. 974 [12] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition 975 RFC 2185, September 1997. 977 [13] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 978 RFC 2473, December 1998. 980 [14] E. Nordmark. Stateless IP/ICMP Translator (SIIT) 981 draft-ietf-ngtrans-siit-03.txts, November 1998 982 (work in progress) 984 [15] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 985 hosts and Routers. draft-ietf-ngtrans-trans-mech-01.txt, 986 August 1998 (work in progress). 988 [16] R. Droms. Dynamic host Configuration Protocol. 989 RFC 2131, March 1997. 991 [17] Rekhter, Moskowitz, Karrenburg, Groot. Address Allocation 992 for Private Networks. RFC 1918. February 1996. 994 [18] This needs to reflect the new DNS work for IPv6. 996 [19] Thomson, Narten. IPv6 Stateless Address Configuration. 997 RFC 2462, December 1998. 999 [20] Hinden, Deering. IP Version 6 Addressing Architecture. 1000 RFC 2373, July 1998. 1002 Authors' Address 1004 Jim Bound 1005 Compaq Computer Corporation 1006 110 Spitbrook Road, ZKO3-3/W20 1007 Nashua, NH 03062 1008 Phone: (603) 884-0400 1009 Email: bound@zk3.dec.com 1011 Laurent Toutain 1012 ENST Bretagne 1013 BP 78 1014 35 512 Cesson S�vign� Cedex 1015 Phone : +33 2 99 12 70 26 1016 Email : Laurent.Toutain@enst-bretagne.fr 1018 Hossam Afifi 1019 ENST Bretagne 1020 BP 78 1021 35 512 Cesson S�vign� Cedex 1022 Phone : +33 2 99 12 70 36 1023 Email : Hossam.Afifi@enst-bretagne.fr