idnits 2.17.1 draft-toutain-ngtrans-dstm-00.txt: -(773): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(857): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 6 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 1 longer page, the longest (page 1) being 1261 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 76 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 182 has weird spacing: '...tion is neede...' == 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 5.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 1164, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1185, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1217, 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-13 -- 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: 11 errors (**), 0 flaws (~~), 17 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Laurent Toutain 2 NGTRANS Tools Working Group Hossam Afifi 3 Expired December 1999 ENST Bretagne 5 Jim Bound 6 Compaq 8 Dual Stack Transition Mechanism (DSTM) 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 This document is a submission by the Next Generation Transition 18 Working Group of the Internet Engineering Task Force (IETF). 19 Comments should be submitted to the ngtrans@sunroof.eng.sun.com 20 mailing list. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 To view the entire list of current Internet-Drafts, please check 40 the "1id-abstracts.txt" listing contained in the Internet-Drafts 41 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 42 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 43 Coast), or ftp.isi.edu (US West Coast). 45 Distribution of this memo is unlimited. 47 Abstract 49 The initial deployment of IPv6 will require a tightly coupled use of 50 IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes 51 will be able to be deployed with IPv6 addresses, but will still need 52 to communicate with IPv4 nodes that do not have a dual IP layer 53 supporting both IPv4 and IPv6. This specification defines a 54 mechanism called "Assignment of IPv4 Global Addresses to IPv6 hosts" 55 (AIIH), which will assign an IPv6 host a temporary IPv4 Global 56 Address, which can be used to communicate with a host that supports 57 IPv4 or IPv4/IPv6. This document includes also the definition of a 58 Dynamic Tunneling Interface (DTI) to ease the automatic IPv4 address 59 assignment and to remove the IPv4 routing table from routers. 60 Another objective is to demonstrate that IPv6 Addresses can 61 be deployed now instead of non-Global IPv4 Addresses within an 62 Intranet. 64 Table of Contents: 66 1. Introduction 68 The initial deployment of IPv6 will require a tightly coupled use of 69 IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes 70 will be able to be deployed with IPv6 addresses, but will still need 71 to communicate with IPv4 nodes that do not have a dual IP layer 72 supporting both IPv4 and IPv6. 74 This specification defines a 75 mechanism called "Assignment of IPv4 Global Addresses to IPv6 hosts" 76 (AIIH), which will assign an IPv6 host a temporary IPv4 Global 77 Address, which can be used to communicate with a host that supports 78 IPv4 or IPv4/IPv6. A AIIH Server combines the functionality of a 79 extended DHCPv6 server and a DNS server. An AIIH DHCPv6 server assigns 80 dynamically temporary IPv4 addresses to Dual Stack Equipments. 81 The AIIH DNS server is used to keep a mapping between the 82 name, the IPv4 address and the IPv6 address of a Dual Stack Equipment. 84 Another objective of this document is to define the functionality 85 of a dynamic tunneling interface (DTI) encapsulating 86 IPv4 packets into IPv6 packets. This will ease the assignment of 87 dynamic IPv4 address since the 88 network topology is hidden. This allows, most of the time, a 89 flat addressing plan. 90 The second advantage is that IPv4 packets will not 91 be directly forwarded anymore. The IPv4 routing table can be 92 suppressed. 94 This document also proposes some steps to migrate from the 95 dual environment described in RFC 1933 to an IPv6 only domain. 96 It exhibits some scenarios 97 to validate the introduction of AIIH servers and DTI interfaces. 99 The methods described in this document may not be used 100 for the general case. The best way is to migrate as quickly as 101 possible hosts and applications to IPv6 or to use Application 102 Level gateways (ALG). This document proposes a way to remove a possible 103 blocking situation during the migration period, which would 104 postpone the introduction of IPv6. 106 1.1. Scenarios 108 To study the behavior of the AIIH Server and the DTI interface, we 109 focus on the following scenarios: 111 - The first scenario is the case of an IPv6 application running on a 112 IPv6 host initiating a dialog with an IPv4 equipment. 114 - The second scenario is an IPv4 application, running on an IPv6 host 115 initiating a dialog with an IPv4-only host. 117 - The third scenario is an IPv4-only application running on an IPv4-only 118 host initiating a dialog with a IPv6 host. 120 1.3. Architecture model 122 The design model supports the following network configuration abstraction: 124 <------- domain --------------------------><-provider-v4-only----> 125 | | | 126 host X ----------------------- Router Y ------------------- host Z 127 (Intranet) (Intranet & Internet) (Intranet) 129 Host X represents an IPv4/IPv6 implementation, that has an 130 IPv6 address. The IPv6 address is denoted as X6 and, if 131 available, the IPv4 address will be denoted as X4. 133 Router Y represents an IPv4/IPv6 implementation that has both 134 an IPv4 Global addresse and an IPv6 Address. The IPv4 address 135 is denoted as Y4 and the IPv6 address is denoted as Y6. Router Y 136 implements two routing tables, one for IPv4 and one for IPv6. 137 Router Y belongs to the same domain as host X. 139 Host Z represents an IPv4 or IPv4/IPv6 implementation that has 140 an IPv4 Global Address, and MAY have an IPv6 Address. The IPv4 141 address is denoted as Z4 and if an IPv6 address exists it is 142 denoted as Z6. 144 1.2. Migration steps 146 RFC 1933 describes the Dual Stack approach and defines a way to 147 introduce compatibility between IPv4 and IPv6 applications. If the 148 operating system and the applications have been "v6fied", dialogs 149 between IPv6 hosts will use the IPv6 protocol. Otherwise dialogs with 150 at least one IPv4 host or application will use IPv4 protocol. 151 IPv6 applications can use both stacks with IPv4-mapped addresses. 153 Nevertheless, this requires a dual configuration either for the hosts or 154 for the intermediary equipments. This does not solve the problem for 155 the lack of IPv4 addresses since each equipment still needs a IPv4 156 address. 158 This is the first step of the transition. It is more or less the 159 state of IPv6 platforms now deployed in the 6bone. 161 The second step is to remove the static configuration of IPv4 addresses 162 when possible. When it will be necessary, 163 an AIIH server will assign a temporary IPv4 address to a host 164 that needs to communicate with an IPv4-only equipment or with a 165 IPv4-only application. The rest of the time, the IPv6 stack will 166 be used. 168 The configuration during this step will be difficult since an 169 addressing plan will still be necessary for the IPv4 protocol and 170 routers will have to manage the IPv6 and the IPv4 routing plan. 172 The third step is to remove the IPv4 routing functions inside routers 173 and keep only the IPv6 routing plan. The IPv4 packets produced by IPv4 174 applications or hosts will be encapsulated inside IPv6 packets. DTI 175 interfaces will establish the mapping between the IPv4 address and the 176 IPv6 address of the destination by using the AIIH server of the 177 destination (if available). The IPv4 source address will be, 178 as in step 2, assigned temporary by the AIIH server. 180 Note that DTI interface can be deployed without any dynamic 181 address allocation, without a AIIH Server. In this case manual 182 configuration is needed to assign 183 address to the DTI interface and to configure the DNS. So it is more 184 logic in a migration process to start with dynamic IPv4 185 address allocation and then use DTI to remove IPv4 routing. 187 In the fourth step, the mechanisms described in step 3 are the same, 188 but they are managed by the 189 IPv6-only provider which carries IPv4 packets using tunnels. This 190 allows a company to get a unique provider, which manages the inter- 191 connectivity with the IPv4 world. Some security measures must be taken 192 to avoid attacks like deny of service by requesting the entire IPv4 193 address pool of the provider. These measures are not in the scope of 194 this document. 196 1.3. Document architecture 198 The specification will begin by defining the terminology (section 2), 199 then discuss the AIIH design model (section 3), then the DTI 200 architecture model is described with its interaction with the 201 AIIH Server (section 4). Section 5 completes the mechanism by 202 defining the DHCPv6 Extension needed to assign a temporary IPv4 address 203 to an IPv6 node. The specification then discusses Security (section 204 5) and Year 2000 considerations (section 6). Appendix A will enumerates 205 Open Issues that need to be discussed in the ngtrans Tools Working 206 Group, and maintain the state of Open Issues as STILL OPEN, RESOLVED, 207 or PARTIALLY RESOLVED during the draft updates to AIIH. Appendix B 208 will keep a historical account of changes to the draft and rationale 209 for those changes as they occur, and maintain consistence with the 210 Open Issues in Appendix A. 212 2. Terminology 214 2.1 IPv6 AIIH Terminology 216 AIIH Domain An area where AIIH Server can access to IPv6 217 equipments. 219 IPv6 Protocol Terms: See [3] 221 IPv6 Transition Terms: See [15] 223 DHCPv6 Terms: See [4,5] 225 DTI: Dynamic Tunneling Interface. An interface 226 encapsulating IPv4 packets into IPv6 packets. 228 DTI encapsulation box: A intermediary equipment doing the IPv6 tunneling 229 when the end-system is unable to do it. 231 DTI resolver: An application that finds the IPv6 destination 232 address using the IPv4 address of the packet 233 being encapsulated. As ARP or Neighbor discovery 234 the DTI resolver is only called for the first 235 packet. 237 DTI daemon synomyn to DTI resolver 239 AIIH Server: A Server that supports DNS [2] and DHCPv6 [4,5] 240 and communications between DNS and DHCPv6, which 241 is implementation defined. 243 IPv4 Global Address: An IPv4 address that is globally routable on 244 the Internet. 246 Transition Box An equipment managing the encapsulation of 247 IPv4 packets either when one of the links is 248 IPv4-only or when the destination has only an 249 IPv4 stack. 251 Tunnel End Point Destination of the IPv6 packet containing a 252 IPv4 packet. 254 2.2 Specification Language 256 In this document, several words are used to signify the requirements 257 of the specification, in accordance with RFC 2119 [9]. These words 258 are often capitalized. 260 MUST This word, or the adjective "required", means that 261 the definition is an absolute requirement of the 262 specification. 264 MUST NOT This phrase means that the definition is an absolute 265 prohibition of the specification. 267 SHOULD This word, or the adjective "recommended", means 268 that there may exist valid reasons in particular 269 circumstances to ignore this item, but the full 270 implications must be understood and carefully 271 weighed before choosing a different course. 272 Unexpected results may result otherwise. 274 MAY This word, or the adjective "optional", means that 275 this item is one of an allowed set of alternatives. 276 An implementation which does not include this option 277 MUST be prepared to interoperate with another 278 implementation which does include the option. 280 silently discard 281 The implementation discards the packet without 282 further processing, and without indicating an error 283 to the sender. The implementation SHOULD provide 284 the capability of logging the error, including the 285 contents of the discarded packet, and SHOULD record 286 the event in a statistics counter. 288 3. AIIH Design Model 290 The design model provides two mechanisms to assign an IPv6 host an 291 IPv4 address. The first mechanism is for the host to request an IPv4 292 address that is globally routable, and the second is for an AIIH 293 Server to assign an IPv6 host a globally routable IPv4 address using 294 the DHCPv6 Reconfigure Message. The assumption in this specification 295 is that a site has a certain number of IPv4 Global Addresses, which 296 can be assigned within the enterprise on a temporary basis for use 297 by hosts in the site. The design model also assumes that the site has an 298 IPv4/IPv6 router in the site that is used to send and receive packets 299 over the Internet. 301 For an IPv6 host to participate in the AIIH mechanism it MUST have a 302 dual IP layer, supporting both an IPv4 and an IPv6 stack. This 303 specification makes the assumption that for IPv6 initial deployment 304 host nodes will not be shipped with IPv6-only stack implementation. For 305 embedded system type nodes that support only an IPv6 stack, AIIH 306 cannot be a solution. 308 3.1 AIIH DHCPv6/DNS Server 310 The AIIH Server supports a co-located DHCPv6 and DNS Server and other 311 implementation defined software functions. The AIIH server 312 configuration files and database is not defined in this 313 specification. There can be one or many AIIH Servers on an Intranet 314 and how they maintain consistency and Tunnel End Point configurations 315 for IPv6 links is implementation defined. 316 The AIIH Server is an implementation where DNS, DHCPv6, and 317 communications between those two applications exists. These 318 applications MAY be co-located on the same host, but that is not a 319 requirement of this specification. How DNS and DHCPv6 communicate is 320 implementation defined. The AIIH Server SHOULD support the following 321 operations: 323 1. Act as the Authoritative DNS Name Server for a set of IPv6 324 hosts that can be queried for IPv4 Global Addresses. 326 2. Communications between the AIIH DNS server and the AIIH DHCPv6 327 Server. 329 3. An AIIH DHCPv6 Server that can maintain a pool of IPv4 Global 330 Addresses in an implementation defined manner. 332 4. An AIIH DHCPv6 Server that can maintain Tunnel End Points for 333 IPv6 Links in an implementation defined manner. 335 5. An AIIH DHCPv6 Server to process DNS AIIH IPv6 host DNS queries, 336 and Reconfiguring IPv6 hosts to assign IPv4 Global Addresses to 337 their interfaces. 339 6. Support DHCPv6 Client's requesting IPv4 Global Addresses. 341 7. Dynamically Updating DNS with an IPv4 Global Address for 342 an IPv6 host that supports IPv4/IPv6. 344 An AIIH Server MUST support a dual IPv4/IPv6 network layer and 345 implementation of IPv4/IPv6. 347 The IPv4 address allocation can be triggered by two events. The first 348 one is when a IPv6 host requests through DHCPv6 an IPv4 address to 349 configure its IPv4 stack. The second event is when the AIIH DNS Server 350 fails to response to a A RR query. The temporary IPv4 address is sent 351 by the AIIH DNS Server which keeps the 352 mapping with the IPv6 address and the name of the equipment in the 353 AIIH domain. The temporary IPv4 address is stored in the AIIH DNS Server 354 as a A record. 356 3.1.1. Requesting an IPv4 Global Address 358 An IPv4/IPv6 host can request an IPv4 Global Address by using the 359 IPv4 Global Address Extension defined in section 5. The IPv4/IPv6 360 host MUST support DHCPv6 [4] and the DHCPv6 Extensions [5]. The 361 Requests/Response Model of DHCPv6 will process this new extension as 362 any other extension. There is no need to define a new message type 363 for DHCPv6 for this processing or add to the DHCPv6 protocol. 365 Once the host has obtained an IPv4 Global Address it MUST NOT 366 update DNS to reflect an A type or PTR type record for this address. 367 The reason is that the intent is to provide a host with this 368 temporary address to use for communications with an IPv4 node. Once 369 the reason for obtaining an IPv4 Global Address has been satisfied 370 the host MUST Release this IPv4 Global Address from the AIIH DHCPv6 371 Server implementation. 373 On the other hand, if the address lifetime is about to expire, the 374 AIIH client may send another request to the AIIH Server to keep this 375 address assigned. 377 3.1.2 AIIH DHCPv6 Client IPv4 Global Address Requests 379 An AIIH DHCPv6 Server will receive DHCPv6 Requests for IPv4 Global 380 Addresses from IPv6 hosts. The AIIH DHCPv6 Server will determine if 381 an address is available and assign the address to the DHCPv6 Client 382 as specified in section 5 of this specification. 384 In case of an IPv4 addressing plan (i.e. step 2 of the migration 385 process), the AIIH Server MUST be configured to allocate IPv4 386 address in regard with the network topology. 388 The AIIH DHCPv6 Server sends a Dynamic Update to the AIIH DNS server. 389 The TTL must be shorter than the duration of the allocation to 390 the client. 392 3.1.3 AIIH DNS Query and DHCPv6 Processing 394 Once the AIIH DNS finds the IPv6 host being queried 395 the AIIH DNS requests from its corresponding AIIH DHCPv6 Server to 396 assign an IPv4 Global Address to the IPv6 host being queried. 398 The AIIH DHCPv6 Server will look within its pool of IPv4 Global 399 Addresses for an address and if a Tunnel End Point address is 400 required for the IPv6 host to reach the router to route packets 401 onto the Internet. If an address is available the DHCPv6 Server will 402 send a DHCPv6 Reconfigure Message to the IPv6 node to temporarily 403 assign the node an IPv4 Global Address (see section 5). 405 Once the AIIH DHCPv6 server is certain that the IPv6 host has 406 assigned the address to an interface, the AIIH DHCPv6 Server responds 407 back to the corresponding AIIH DNS Server with the IPv4 Global 408 Address assigned to the IPv6 host being queried, or 409 that an address could not be assigned to this IPv6 host. 411 It is important to wait a acknowledgment from the client to be sure 412 that the host is up before validate an IPv4 address assignation. 413 Nevertheless 414 this could introduce a delay incompatible with the timer used during 415 a DNS query. The dialog could be modified. Just after the DNSv6 416 temporary IPv4 address assignment, the AIIH DNS returns this address 417 but with a small TTL. The real TTL will be used if the acknowledgment 418 is received, otherwise the IPv4 address is deprecated for a while. 420 The AIIH DNS Server will now respond to the IPv4 DNS Query as 421 the Authoritative DNS Name Server with an address or host not found. 423 The AIIH DHCPv6 Server MAY send a dynamic update to DNS [6] to add an 424 A type record to the Primary DNS Server, where the query came from to 425 the AIIH DNS Server. The Time-To-Live (TTL) field in the update MUST 426 NOT be set to be greater than the valid lifetime for the IPv4- 427 Compatible address in the DHCPv6 Extension provided to the DHCPv6 428 Client. It is highly recommended to not update the DNS with an 429 A record for the IPv6 host, unless that IPv6 host provides a 430 permanent IPv4 Application service needed by IPv4 hosts. 432 The Dynamic Update will be done for the direct queries, this will allows 433 other queries for the IPv4 address to get the same answer. If DTI is 434 present, another Dynamic Update will be done for the reverse queries. 435 The type recorded should be TEP (Tunnel End Point). See discussion 436 paragraph 4.1.1. 438 3.1.4. Cleaning up the AIIH IPv4 Assigned Address 440 Once the IPv4 address expires, the DHCPv6 Server will permit the IPv4 441 address to be reused. But before the address can be reused the 442 DHCPv6 Server MUST delete the IPv4 address from the Primary DNS 443 Server, thru the Dynamic Updates to DNS mechanism, if an A record was 444 added to the relative Primary DNS Server. 446 If a AIIH client wants to keep the temporary IPv4 address after 447 its expiration time, it MUST send a DHCPv6 request before the address 448 expires. 450 3.2 Links with other DNS. 452 When the Primary DNS Server for the IPv6 node receives the IPv4 hosts 453 query, it will do a DNS search for that IPv6 host and find that there 454 is an Authoritative DNS Server for that specific DNS A record, which 455 represents an IPv6 host. That DNS Server will be one part of the 456 AIIH Server software. After the AIIH DHCPv6 Server assigns the IPv6 457 node a temporary IPv4 Global Address, the AIIH DNS Server will 458 respond to the original IPv4 DNS query authoritatively with an IPv4 459 Global Address for the IPv6 host or return host Not Found. 461 For Example: 463 IPv4 node "v4host.abc.com" queries for "v6host1.xyz.com" 465 Query reaches Primary DNS Server for "v6host1.xyz.com". 467 ----------- 468 xyz.com. IN SOA primary.xyz.com. etc etc. 469 . 470 . 471 xyz.com IN NS primary.xyz.com 472 aiih.xyz.com IN NS v6trans.aiih.xyz.com 473 . 474 . 475 primary.xyz.com IN A 202.13.12.6 476 v6trans.aiih.xyz.com IN A 202.13.12.8 477 . 478 . 479 . 480 v6host1.xyz.com IN CNAME v6host1.aiih.xyz.com 481 v6host2.xyz.com IN CNAME v6host2.aiih.xyz.com 482 v6host3.xyz.com IN CNAME v6host3.aiih.xyz.com 484 DNS query will end up going to the authoritative server 485 v6trans.aiih.xyz.com looking for v6host1.aiih.xyz.com. This permits 486 the AIIH Server to now process a request for an IPv4 Global Address 487 for an IPv6 host that had no IPv6 DNS AAAA Record [18]. 489 If DTI is present, the reverse DNS must be linked to the pool of 490 addresses managed by the AIIH Server. 492 3.3 Scenarios 494 These scenarios take place during the step 2 of the migration process. 495 IPv6 equipments have a dual stack, but only the IPv6 stack is 496 configured. Routers have both of their stacks configured. 498 Notation of the equipment is defined in paragraph 1.2. 500 ==> means a IPv6 packet 501 --> means a IPv4 packet 502 ..> means a DNS query or response. The path taken by this 503 packet is unknown 504 "Z" means the DNS name of "Z" 506 3.3.1 X6 (with a v6 application) to Z4 508 AIIH Y4 Z4 509 X6 Y6 510 | | | 511 | | | - X6 asks the DNS for a AAAA for "Z" 512 | | | - the DNS answers a error 513 | | | - X6 asks for the A RR for "Z" 514 | | | - the answer is Z4 515 | | | - X6 needs a IPv4 address 516 |====> | | - X6 queries the AIIH server for an 517 | | | IPv4 address using DHCPv6 518 |<==== | | - The DHCP server locates the client 519 | | | and attributes temporally a v4 520 | | | address. (the tunnel end-point is 521 | | | not set in the response) 522 | | | - The AIIH Server may register IPv4 523 | | | address to the DNS through 524 | | | a Dynamic Update 525 |------------+----------->| - X4 can send the IPv4 packet to Z4 526 |<-----------+----------->| - and vice versa. 528 3.3.2 X6 (with a v4 application) to Z4 530 Same behavior as 3.3.1, except that X will request directly a A RR 531 to the DNS instead of going first through a AAAA query. 533 3.3.3 Z4 to X6 535 AIIH Y4 DNS Z4 536 X6 Y6 537 | | | 538 | | <-----| - Z asks for �X� 539 | <-...| | - The request reaches to the AIIH 540 | | | Server 541 |<===== | | - The AIIH Server assigns a v4 542 | | | address to X 543 |=====> | | - X acknowledges 544 | ..................>| - The AIIH server answers with the 545 | | | newly assigned v4 address 546 | | | - The AIIH Server may register the 547 | | | IPv4 address through a Dynamic Update 548 |<-----------+------------| - Z4 can send the packet to X4 549 |<-----------+----------->| - and vice versa 550 | | | 552 4. DTI 554 4.1. DTI Architecture 556 The DTI interface will be used to send IPv4 packets during the migration 557 process. The routing table of the host forwards the information to 558 that interface. It is possible to send all the IPv4 packets through this 559 interface. Some other prefixes can be used to send directly native IPv4 560 packets. 562 The DTI interface is placed between the IPv4 API and the IPv6 layer, 563 as shown in the following figure. 565 +------------||------------+------------||------------+ 566 | IPv6 API | IPv4 API | 567 | | | 568 | +--------------------------+ 569 | | 570 +-----------------------------------------------------+ 572 The following example gives the configuration of a routing 573 table using DTI. The addresses in this example are private, but the 574 use of global IPv4 addresses gives a similar result. With this routing 575 table, if the destination address contains the prefix 10.35.3/24 576 IPv4 packet are send directly on the link. If the destination prefix is 577 10.34.3.0/24, packets are sent to the DTI interface. Otherwise the 578 packet is sent to the default router. 580 Routing tables 582 Internet: 583 Destination Gateway Flags Refs Use Mtu Netif Expire 584 default 10.35.3.3 UGSc 3 0 1500 le0 585 10.34.3/24 10.34.3.2 UXc 0 10 1460 dti0 586 10.35.3/24 link#3 UC 0 0 1500 le0 - 587 10.35.3.3 8:0:2b:1c:af:15 UHLW 4 0 1500 le0 649 588 127.0.0.1 127.0.0.1 UHl 1 102 16384 lo0 590 In this example, the DTI already has an IPv4 address. But this address 591 can be dynamically acquired using the AIIH Server as explained in 592 chapter 3. 594 When a DTI has to encapsulate a IPv4 packet into IPv6 packet. The DTI 595 as to find the IPv6 address for the destination, called in this document 596 a Tunnel End Point (TEP). The tunnel end point can be directly the host 597 or, if the destination host is IPv4-only, a IPv6 address of a transition 598 box. 600 The protocol value for IPv4 encapsulation is 4 (as for IPv4 tunneling 601 over IPv4). When a tunneled packet arrives to the IPv6 602 destination, the IPv6 header is removed and the packet is proceed by the 603 IPv4 layer. The receiver should memorize the association between IPv4 604 destination address and TEP. 606 This document propose two ways for resolving tunnel end point. The first 607 one is dynamic and use the AIIH DNS Server, the second one is static and 608 is returned in the DHCPv6 packet when a temporary IPv4 address is 609 allocated to the interface. The dynamic resolution is mandatory. The 610 tunnel end point in the DHCPv6 message is optional. This TEP is used 611 when dynamic TEP fails (for example, the destination does not have a 612 AIIH server). 614 Dynamic TEP should be used when IPv4 host or application are 615 spread inside a domain. Static TEP should be used when the boundary 616 between IPv4 and IPv6 domain is clear (for example an IPv6 617 domain, connected to an IPv4-only provider). 619 4.1.1 Dynamic TEP 621 Dynamic TEP determination is about the same process as MAC address 622 resolution when sending a IP packet over a Ethernet link. The only 623 difference is that no broadcast facilities can be used to find a TEP. 625 In Unix operating systems, this resolution should not be done in the 626 kernel. Some operating systems offer the possibility to do external 627 resolution. A query is sent to a daemon in the user space. This daemon 628 does a DNS query to find the TEP. In the rest of this document we will 629 consider this architectural model, but this is not a limitation for 630 implementing DTI. 632 The AIIH DNS Server MUST be reachable in the reverse query 633 DNS tree for the range of IPv4 addresses managed by this server. 635 When the resolver daemon receives a query from the kernel, it sends a 636 reverse query to the DNS to get the record for this host. Three kinds 637 of records can be proceeded by the daemon: 639 - PTR record: the daemon sends another query to the DNS to get the 640 AAAA record of this host and returns the value to the kernel. 642 - AAAA record: the value is returned to the kernel 644 - TEP record: this record must be introduced for the DTI interface to 645 avoid confusion between the destination and the tunnel end point (see 646 paragraph 4.2.1). It contains the address of the tunnel end point. Its 647 value is returned to the kernel. We recommend the use of this record. 648 Only the AIIH server will have to manage such records. They are, 649 most of the time, created by the AIIH DHCP Dynamic Update when a 650 temporary address is allocated to an IPv6 host. 652 The IPv6 address is stored in a cache for a duration indicated in the 653 TTL field of the DNS answer. The following example shows a entry for 654 destination 10.34.3.1 656 /homes/toutain>netstat2 -rnf inet 657 Routing tables 659 Internet: 660 Destination Gateway Flags Refs Use Mtu Netif Expire 661 default 10.35.3.3 UGSc 3 21 1500 le0 662 10.34.3/24 10.34.3.2 UXc 0 109 1460 dti0 663 10.34.3.1 3ffe:305:1002:4:a00:2bff:fe1b:8942 UHLS 0 0 1460 dti0 27 664 10.35.3/24 link#3 UC 0 0 1500 le0 - 665 10.35.3.2 8:0:2b:1c:11:1f UHLWl 0 29 1500 lo0 666 10.35.3.3 8:0:2b:1c:af:15 UHLW 4 0 1500 le0 304 667 10.35.3.255 ff:ff:ff:ff:ff:ff UHLWb 0 2 1500 le0 668 127.0.0.1 127.0.0.1 UHl 1 298 16384 lo0 670 4.1.2 Static TEP 672 Static TEP may be returned by the AIIH Server with the temporary IPv4 673 address. This TEP is used when the dynamic TEP resolution fails. This 674 will be the case when the DTI daemon asks for a TEP RR on a non 675 AIIH DNS Server. 677 Static TEP is used to tunnel packets to a transition box linked to 678 a IPv4 network. In some 679 domains where the delimitation between the IPv6 and the IPv4 is strict 680 it is sub-optimal to wait for the failure of the DNS query 681 before using the 682 static TEP. DHCPv6 configuration message should contain a flag to 683 force the use of static TEP. 685 4.1.3 IPv4-only hosts 687 It is not possible to modify IPv4-only hosts or the applications running 688 on such hosts. These hosts are configured to send IPv4 packet on the 689 network to a transition box that will encapsulate IPv4 packet into IPv6 690 packets. For an IPv4-only host, this equipment is viewed has a default 691 router. 693 This means that an addressing plan is required for these hosts. At least 694 two IPv4 addresses are needed. This will depend on the number of IPv4 695 addresses available. One extreme possibility is to keep the addressing 696 plan that existed before DTI, but this could lead to a waste of IPv4 697 addresses. The other possibility is, if the capability of the IPv4-only 698 allows it, to assign a prefix length of 30 to that link. 700 The IPv4 address is configured manually in the reverse DNS tree 701 in association 702 with a TEP record that gives the IPv6 address of the tunnel end point. 704 Depending on the DF bit of the IPv4 packet, the translation box will do 705 the fragmentation (i.e. use the IPv6 fragmentation extension) or will 706 send a ICMP message to the IPv4-only host. 708 4.2 Examples 710 The notation +++> means a IPv4 packet encapsulated in a IPv6 packet. 712 4.2.1 X6 (with v6 application) to Z4 with TEP dynamic resolution 714 Z4 is in the same domain as X6. The DNS for "Z" is configured in the 715 reverse query DNS database as follow: 717 128.3.4.6 PTR Z.aiih... ;the database is statically configured for Z 718 TEP 3ffe:..... ;address of the Tunnel End Point 720 The DNS has been configured with the address of Z 722 Z A 128.3.4.6 724 AIIH TB Z4 725 X6 Y6/Y4 726 | | | 727 | | | - X6 asks the DNS for a AAAA for "Z" 728 | | | - the DNS answers a error 729 | | | - X6 asks for the A RR for "Z" 730 | | | - the answer is Z4 731 | | | - routing protocol has been previously 732 | | | configured in X to route v4 through 733 | | | dti (compatible with IPv4-mapped 734 | | | addresses). 735 | | | - X6 needs a IPv4 address (first use) 736 |====> | | - X6 queries the AIIH server for an 737 | | | IPv4 address using DHCPv6 738 |<==== | | - The DHCP server locates the client 739 | | | and attributes temporally a v4 740 | | | address. (the tunnel end-point is 741 | | | not set in the response). 742 | | | - the DHCP Server sends a Dynamic Update 743 | | | to the DNS to memorize the association 744 | | | x4<->x6 (x4 TEP X6). 745 | | | - dti has to find the IPv6 address of 746 | | | the tunnel end-point for Z4 747 |.....................> | - dti daemon asks the dns for the IPv6 748 | | | TEP for Z4 (transition box) 749 |<..................... | - AIIH DNS answers the TEP 750 |+++++++++++++++++> | - The dti sends the v6 packet to the 751 | | | tunnel end-point 752 | | ------>| - The TB sends the packet to 753 | | | the destination 755 If the tunnel end point for Z4 had been recorded in the DNS with a 756 AAAA record, then the source would have been confused and would have 757 sent the packet directly in IPv6 to the transition box. 759 4.2.2 X6 (with v4 application) to Z4 with TEP dynamic resolution 761 The dialog is the same as shown in paragraph 4.2.1 when an IPv4 762 application wants to talk with a IPv4 application on Z4. 764 To maintain compatibility between two v4 application, a v4 application 765 running on a IPv6 host may wish to send IPv4 packets to another 766 application running also on an IPv6 host, called Z6. Y6 is not used in 767 this model. It was kept to show that X and Z can belong to two separate 768 AIIH domains. 770 AIIH AIIH 771 X6 Y6 Z6 772 | | | 773 |............|.....> | - X asks for the v4 address of �Z�. 774 | | =====>| - AIIH Server assigns a v4 address to Z 775 | | | - AIIH registers this address to 776 | | | its DNS server 777 |<...........|..... | - Z4 is returned to X 778 | | | - The v4 address of Z is used by the 779 | | | application, which sends v4 packet 780 | | | to the kernel 781 | | | - routing table has been previously 782 | | | configured in X to route 783 | | | v4 through dti 784 |=====> | | - dti receives its first packets, asks 785 |<===== | | the AIIH server to assign 786 | | | the v4 address to the DTI interface 787 | | | - AIIH registers this address 788 | | | to the dns server 789 | | | - dti has to find the IPv6 address 790 | | | of the tunnel end-point for Z4 791 |..................> | - dti daemon asks the dns for the 792 |<.................. | TEP RR for Z4 793 |++++++++++++++++++++++++>| - dti tunnels the packet to Z6 795 4.2.3 Z4 to X6 with TEP dynamic resolution 797 This example covers any scenario where a IPv4-only host wants to reach 798 an IPv6 host. This could be any application, but in this example, we 799 will focus on a DNS query for a IPv4-only host to the DNS server of the 800 domain. 802 The IPv4-only host is configured with an IPv4 address and a default 803 router. The DNS is also configured with the IPv4 address of the DNS 804 server. Therefore, the DNS server must have a statically assigned 805 IPv4 address. This configuration could be stored in the AIIH Server 806 or directly on the host running the name server. We will suppose in 807 this example that the configuration is stored in the AIIH Server. 809 DNSv4 AIIH Y4 Z4 810 DNSv6 Y6 811 | | | 812 | | | - Z4 wants to know the IPv4 address 813 | | | of some equipment in the Internet 814 | | | - Z4 has been configured with Y4 as 815 | | | default router and DNSv4 as resolver 816 | |<-----------| - Z4 sends a query to the default route 817 | | | - Y receive the packet, Y routing table 818 | | | lead packets (except for the link where 819 | | | Z4 is connected) to the DTI interface. 820 | <=====| | - DTI has to find the TEP. It sends a 821 | =====>| | query to the AIIH server for the TEP 822 | | | for DNSv4. 823 |<===== | | - AIIH assigns the IPv4 address to DNSv6 824 |<++++++++++ | | - The query is tunneled to DNSv6 825 | | | 827 4.2.3 X6 to Z4 with static TEP resolution 829 This example covers the case where X6 wants to reach a host outside the 830 AIIH domain. Y is the last router for the IPv6 domain and is connected 831 to the Internet v4. In this example, Y belongs to the domain. 833 This scenario is used when a web browser in the IPv6 domain contact a 834 IPv4 HTTP server. 836 AIIH DNS Z4 837 X6 Y6/Y4 838 | | | 839 |=====> | | - X6 after the first DNS query to get 840 | | | Z4 address, sends a request to the 841 | | | AIIH server to obtain a temporary 842 | | | IPv4 address. 843 |<===== | | - AIIH returns the IPv4 address and 844 | | | the tunnel end-point 845 |.....................> | - dti daemon asks the dns for the IPv6 846 | | | TEP for Z4 (transition box) 847 | | | 848 | | | 849 | | | - no answer, the DTI use the static TEP 850 |+++++++++++>| | - Packet is tunneled to the static TEP 851 | |----------->| - and sent with IPv4 to Z4 853 When Z4 replies, the packet will not necessary reach the router Y. 854 Routing in the internet is not symmetrical and can change. The AIIH 855 Server does not participate to the routing protocol, so the given TEP 856 can be sub-optimal. The IPv4 packet sent by Z4 will reach a router 857 Y� (by definition Y� is at the boundary between a IPv4-only domain 858 and an IPv6 domain). Y� can find out the TEP to reach X6 by using 859 the dynamic TEP resolution. 861 To avoid the time-out when the dynamic TEP resolution fails, the DTI 862 can be configured to send directly packets to the static TEP. 864 5. AIIH DHCPv6 Requirements 866 The AIIH DHCPv6 processes will use the DHCPv6 protocol and extensions 867 to communicate between the AIIH DHCPv6 Server and the DHCPv6 Client. 868 A new extension is required for DHCPv6 (section 5.1) to support AIIH. 869 But there are some additional requirements placed on the AIIH 870 processes that are not specific to the DHCPv6 protocol, but as 871 transition and interoperation mechanisms for the IPv6 hosts. 873 5.1 DHCPv6 IPv4 Global Address Extension 875 The DHCPv6 IPv4 Global Address Extension informs a DHCPv6 876 Server or Client that the IPv6 Address Extension [5] following this 877 extension will contain an IPv4-Compatible Address [20], or is a Request 878 for an IPv4 Global Address from a Client, or a Reply assigning a Global 879 IPv4 Address to a Client from a Server. The extension can also 880 provide an IPv4-Compatible or IPv6 address to be used as the Tunnel 881 End Point to encapsulate an IPv6 packet within IPv4, or an IPv4 882 packet within IPv6. 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Type | Length | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Tunnel End Point | 890 | (If Present) | 891 | (16 octets) | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Type: TBD 895 Length: 0 or 16 896 Tunnel End Point: IPv6 Address if Present 898 An IPv4 Global Address Extension MUST only apply to the extension 899 following and not to any additional extensions in the DHCPv6 900 protocol. 902 << NOTE >> 903 flags are missing in this specification 904 <> 906 5.2 AIIH Server Processing of an IPv4 Global Address Extension 908 When a DHCPv6 Server receives an IPv4 Global Address Extension it 909 MUST assume that the next extension in a DHCPv6 Request or Release 910 Message; the Client is either Requesting an IPv4 Global Address or 911 Releasing an IPv4 Global Address. If an address is present in either 912 of these messages it will be in the form of an IPv4-Compatible 913 Address. 915 When a DHCPv6 Server sends a Client a Reconfigure Message to assign 916 an IPv4 Global Address to an interface the Server MUST NOT set the 917 "N" bit in the Reconfigure Message, so the Client performs the 918 necessary Request/Reply DHCPv6 processing to obtain the address from 919 the Server. The Server MUST NOT assume that the Client has assigned 920 the address to an interface until it has sent the corresponding Reply 921 to the Client. 923 The Server will no a priori the IPv6 routable address, when sending a 924 Reconfiguration Message, of a Client within the Intranet, and should 925 use that address with its own IPv6 address as the transaction binding 926 cache until the DHCPv6 Client/Server protocol processing has 927 completed. 929 The Server will look in its implementation defined IPv4 Global 930 Address configuration to determine if a Tunnel End Point is required 931 for a specific IPv6 Address Prefix. If that is the case the Server 932 will put the address for the Tunnel End Point in the IPv4 Global 933 Address Extension. If the Tunnel End Point address is an IPv4 934 address the Server will put that address in the extension as an 935 IPv4-Compatible address. 937 5.3 AIIH Client Processing of an IPv4 Global Address Extension 939 When a DHCPv6 Client receives an IPv4 Global Address Extension it 940 MUST assume that the next extension in a DHCPv6 Reconfigure or Reply 941 Message; the Server is either assigning an IPv4 Global Address or 942 supplying an IPv4 Global Address. The address present in either of 943 these messages will be in the form of an IPv4-Compatible Address. 945 When the Client supplies an IPv4 Global Address as a Request or 946 Release it MUST represent that address as an IPv4-Compatible Address. 948 The Client MUST not assume it can use the IPv4 Global Address until 949 it has received a corresponding Reply to the Client Request, which is 950 required for a Reconfigure Message too as specified in section 5.2. 952 Once the Client is assured it can use the IPv4 Global Address it can 953 perform the following operations: 955 1. In an implementation defined manner the Client MUST assign the 956 address to an interface, supporting the Client's IPv4 stack 957 implementation. 959 2. In an implementation defined manner the Client MUST create an entry 960 as an IPv4-Compatible Address supporting the processing required 961 for an IPv6 address regarding the valid and preferred lifetimes 962 as specified in IPv6 Addrconf [19]. Once the IPv4-Compatible 963 address valid lifetime expires the IPv4 address MUST be deleted 964 from the respective interface and a DHCPv6 Release Message 965 MUST be sent to the AIIH DHCPv6 Server to delete the IPv4 Global 966 Address from the Servers bindings. 968 3. If a Tunnel End Point address is provided in the IPv4 Global 969 Address Extension, the Client MUST create a configured tunnel 970 to the Tunnel End Point address, in an implementation defined 971 manner. If the Tunnel End Point address is an IPv4-Compatible 972 address then the encapsulation is IPv4 within IPv4, if the 973 Tunnel End Point is an IPv6 address then the encapsulation 974 is IPv6 in IPv4. These encapsulation mechanisms are defined 975 in other IPv6 specifications [13, 15]. 977 6. Security Considerations 979 The AIIH mechanism can use all the defined security specifications 980 for each functional part of the operation. For DNS the DNS Security 981 Extensions/Update can be used [10, 11], for DHCPv6 the DHCPv6 982 Authentication Message can be used [5], and for communications 983 between the IPv6 node, once it has an IPv4 address, and the remote 984 IPv4 node, IPSEC [8] can be used as AIIH does not break secure end- 985 to-end communications at any point in the mechanism. 987 7. Year 2000 Considerations 989 There are no Year 2000 issues in this specification. 991 Appendix A - Open Issues 993 - Need to add Examples for the new A6 Record types and how 994 AAAA records can be used initially and references. 996 OPEN 1/99 998 - Should use new Basic API terms for APIs. 1000 OPEN 1/99 1002 - Need to add references for IPsec. 1004 OPEN 1/99 1006 - Need to change references for DNS SEC esp solutions 1007 for Dynamic Updates to DNS. 1009 OPEN 1/99 1011 - Need to look at issues for TCP TIME_WAIT state and other 1012 issues of addresses timing out. 1014 OPEN 1/99 1016 - Need to add words to the design objective of preserving the 1017 end-to-end model for IPv6. 1019 OPEN 1/99 1021 - The draft does not speak of PTR records for the IPv6 node 1022 A record once its created. But its only useful during the 1023 lifetime of the assigned IPv4 address. 1025 STILL OPEN 3/98 Draft. Closed - New A6 Records 1027 - RFC 1183 RT Record is Experimental and there is some concern 1028 its obsolete. Though some implementations still support some 1029 code for the RT record. Also the Route Through semantics 1030 specified may need to strongly state the query is passed thru 1031 to the AIIH server. This needs to be discussed. 1033 RESOLVED 3/98 Draft RT record deprecated. 1035 - The Primary Server must look for the IPv6 node A record first 1036 before finding the RT record. This needs to be verified 1037 as an implementation issue. 1039 RESOLVED 3/98 Draft - Use CNAME Records. 1041 - When the AIIH Server responds to the query it may not be 1042 authoritative. This needs to be verified and checked. 1043 RESOLVED 3/98 Draft - Use CNAME Records and AIIH Server will 1044 be authoritative for the AIIH ZONE. 1046 - Use of TTL for DNS Caches can cause problems for existing IPv4 1047 applications that cache IPv4 addresses. 1049 PARTIALLY RESOLVED - 3/98 Draft do not update DNS unless 1050 application will be permanent as opposed to transient. 1051 But TTL's that are updated still need some thought for 1052 legacy applications. This also points to possibly adding 1053 new fields to the hostent structure which will at least 1054 help new IPv6 applications and legacy IPv4 applications 1055 to change to act in a well behaved manner. 1057 - Specification needs a design example to get packets from 1058 the IPv6 node to an egress IPv4 router. 1060 PARTIALLY RESOLVED - 3/98 Draft added Design Section discussing 1061 tunneling mechanisms to be used and added Tunnel End Point address 1062 supplied by the AIIH DHCPv6 Server. Still needs more discussion. 1064 - NNAT name does not state what the specification does. 1066 RESOLVED - 3/98 Draft changed name to AIIH. 1068 Appendix B - Draft Changes and Rationale History 1070 Prior to January 1999: 1072 - Changed the name of the draft from NNAT to AIIH. This also 1073 was done to prevent any perceived antagonism towards the NAT 1074 IETF work, which is not an objective of this work. 1076 - Changed the Introduction to be more descriptive of the task 1077 at hand. 1079 - Added IPv4 Global Address definition to terminology section. 1081 - Added tunnel routability discussion to Design Model and a 1082 diagram abstraction to be used by the specification as 1083 a point of reference. 1085 - Added to the architecture the ability for an IPv6 node to 1086 request an IPv4 Global Address from an AIIH DHCPv6 Server. 1087 This will permit AIIH to not only be useful for incoming 1088 IPv4 host communications with IPv6 hosts but also for outgoing 1089 IPv4 communications to the Internet from IPv6 hosts and for 1090 Intranet enterprise communications between an IPv6 host and 1091 IPv4 host. 1093 - Hinted that AIIH could be used in future work to define 1094 the capability for two IPv6 hosts separated by an IPv4 cloud to 1095 to communicate thru tunnels, like thru a production 6bone 1096 network on the Internet. 1098 - Added new section to define how an IPv6 host can request 1099 an IPv4 Global Address. 1101 - Defined new mechanism for DNS query processing when an IPv6 1102 host is looked for from an IPv4 host, thru the use of CNAME 1103 and NS records. This also permits IPv4 host Intranet queries 1104 too now. 1106 - New text clarifying that within the Intranet processing AIIH 1107 must only be used with IPv4 Global Addresses and Private 1108 IPv4 addresses should be retrieved from DHCPv4, via the IPv6 1109 hosts IPv4 stack. 1111 - Added new text defining the AIIH Server and the interaction 1112 with DHCPv6 and DNS applications. Also further refined the 1113 requirements of the AIIH Server model. 1115 - Expanded the section on the new DHCPv6 Section defining the 1116 required Server and Client behavior. Added support to permit 1117 AIIH to be used for Intranet and Internet communications from 1118 within the site. 1120 - Changed the DHCPv6 Extension for IPv4 Global Addresses to 1121 make it an extension which defines the next extension to 1122 be a request for AIIH processing relative to DHCPv6. 1124 - Added a Tunnel End Point address to the new extension so 1125 IPv6 hosts can configure tunnels to communicate with the 1126 egress router to transmit or reply with IPv4 on the Internet 1127 or within the Intranet. 1129 - Defined the AIIH side affect requirements for IPv6 hosts using 1130 this mechanism with DHCPv6. 1132 - Updated and added to the Acknowledgment and References Section. 1134 - Updated the Open Issues from December 1997 draft and noted 1135 the status of each issue as STILL OPEN, RESOLVED, or PARTIALLY 1136 RESOLVED. 1138 - Updated the Changes from this draft. 1140 January 1999: 1142 - Updated References. 1144 - Fixed Edit Issues 1146 - Added new Open Issues. 1148 - Removed all terms of NNAT except for History. 1150 Acknowledgments 1152 The author would like to thank Erik Nordmark for spending time 1153 reviewing with him this idea and suggesting the use of the DHCPv6 1154 Reconfigure Message, Richard Johnson for suggesting the use of the 1155 DNS CNAME Record, and Robert Watson who suggested that the AIIH 1156 DHCPv6 and DNS Server be co-located. George Tsirtsis who suggested 1157 using AIIH to assign IPv4 Global Addresses to IPv6 hosts in general. 1158 Richard Draves and Jack McCann who have provided many helpful 1159 technical suggestions, and the NGTRANS working group for taking the 1160 time to work on AIIH. 1162 References 1164 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 1165 13, RFC 1034, USC/Information Sciences Institute, November 1987. 1167 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 1168 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 1169 November 1987. 1171 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1172 Architecture", RFC 2460, December 1998. 1174 [4] J. Bound and C. Perkins. Dynamic host Configuration Protocol 1175 for IPv6. draft-ietf-dhc-dhcpv6-13.txt March 1998 (work 1176 in progress). 1178 [5] C. Perkins. Extensions for the Dynamic host Configuration 1179 Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-10.txt March 1180 1998. (work in progress). 1182 [6] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 1183 to the Domain Name System (DNS). RFC 2136, April 1997. 1185 [7] William R. Cheswick and Steven Bellovin. Firewalls and Internet 1186 Security. Addison-Wesley, Reading, MA 1994 (ISBN: 1187 0-201-63357-4). 1189 [8] IPSEC - This needs to include the Arch, Auth, and ESP specs. 1191 [9] S. Bradner. Key words for use in RFCs to indicate Requirement 1192 Levels. RFC 2119, March 1997. 1194 [10] D. Eastlake and C. Kaufman. Domain Name System Security 1195 Extensions. RFC 2065, January 1997. 1197 [11] D. Eastlake. Secure Domain Name System Dynamic Update. 1198 RFC 2137, April 1997. 1200 [12] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition 1201 RFC 2185, September 1997. 1203 [13] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 1204 RFC 2473, December 1998. 1206 [14] E. Nordmark. Stateless IP/ICMP Translator (SIIT) 1207 draft-ietf-ngtrans-siit-03.txts, November 1998 1208 (work in progress) 1210 [15] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 1211 hosts and Routers. draft-ietf-ngtrans-trans-mech-01.txt, 1212 August 1998 (work in progress). 1214 [16] R. Droms. Dynamic host Configuration Protocol. 1215 RFC 2131, March 1997. 1217 [17] Rekhter, Moskowitz, Karrenburg, Groot. Address Allocation 1218 for Private Networks. RFC 1918. February 1996. 1220 [18] This needs to reflect the new DNS work for IPv6. 1222 [19] Thomson, Narten. IPv6 Stateless Address Configuration. 1223 RFC 2462, December 1998. 1225 [20] Hinden, Deering. IP Version 6 Addressing Architecture. 1226 RFC 2373, July 1998. 1228 Authors' Address 1230 Jim Bound 1231 Compaq Computer Corporation 1232 110 Spitbrook Road, ZKO3-3/U14 1233 Nashua, NH 03062 1234 Phone: (603) 884-0400 1235 Email: bound@zk3.dec.com 1237 Laurent Toutain 1238 ENST Bretagne 1239 BP 78 1240 35 512 Cesson S�vign� Cedex 1241 Phone : +33 2 99 12 70 26 1242 Email : Laurent.Toutain@enst-bretagne.fr 1244 Hossam Afifi 1245 ENST Bretagne 1246 BP 78 1247 35 512 Cesson S�vign� Cedex 1248 Phone : +33 2 99 12 70 36 1249 Email : Hossam.Afifi@enst-bretagne.fr