idnits 2.17.1 draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-ngtrans-nnat-00', but the file name used is 'draft-ietf-ngtrans-assgn-ipv4-addrs-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 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 17 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 9 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 2 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.) -- The document date (March 1998) is 9538 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 784, but no explicit reference was found in the text == 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') -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-tunnel is -07, but you're referring to -08. (However, the state information for draft-ietf-dhc-dhcpv6ext is not up-to-date. The last update was unsuccessful) -- No information found for draft-ietf-ngtrans-header-trans - is the name correct? -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-01) exists of draft-ietf-ngtrans-trans-mech-00 -- Possible downref: Normative reference to a draft: ref. '18' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addrconf-v2 is -01, but you're referring to -02. (However, the state information for draft-ietf-ngtrans-header-trans is not up-to-date. The last update was unsuccessful) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Jim Bound 3 NGTRANS Tools Working Group Digital Equipment Corp 4 Obsoletes draft-ietf-ngtrans-nnat-00.txt March 1998 6 Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH) 8 10 Status of this Memo 12 This document is a submission by the Next Generation Transition 13 Working Group of the Internet Engineering Task Force (IETF). 14 Comments should be submitted to the ngtrans@sunroof.eng.sun.com 15 mailing list. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 To view the entire list of current Internet-Drafts, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 31 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 32 Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 The initial deployment of IPv6 will require a tightly coupled use of 37 IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes 38 will be able to be deployed with IPv6 addresses, but will still need 39 to communicate with IPv4 nodes that do not have a dual IP layer 40 supporting both IPv4 and IPv6. This specification defines a 41 mechanism called Assignment of IPv4 Global Addresses to IPv6 Hosts 42 (AIIH), which will assign an IPv6 Host a temporary IPv4 Global 43 Address, which can be used to communicate with a Host that supports 44 IPv4 or IPv4/IPv6. An objective of this specification is to avoid 45 the use of address translation for the deployment of IPv6 in a 46 network. Another objective is to demonstrate that IPv6 Addresses can 47 be deployed now instead of non-Global IPv4 Addresses within an 48 Intranet. 50 Table of Contents: 52 1. Introduction.................................................3 53 2. Terminology..................................................4 54 2.1 IPv6 NNAT Terminology.......................................4 55 2.2 Specification Language......................................5 56 3. AIIH Design Model ...........................................6 57 3.1 AIIH DHCPv6/DNS Server......................................6 58 3.2 AIIH Network Configuration Intranet to Internet Taxonomy....6 59 3.3 Accessing Hosts Services within an IPv6 Intranet............7 60 3.4 IPv6 Communications over the Internet with IPv4 Tunnels.....8 61 4. Requesting an IPv4 Global Address............................8 62 5. IPv4 Query for an IPv6 Host..................................8 63 5.1 Reaching the Intranet Primary DNS Server....................8 64 5.2 Getting the A Record Query to the AIIH Server...............9 65 6. AIIH Server Processing.......................................9 66 6.1 AIIH DNS Query and DHCPv6 Processing.......................10 67 6.2 AIIH DHCPv6 Client IPv4 Global Address Requests............11 68 6.3 Cleaning up the AIIH IPv4 Assigned Address.................11 69 6.3 Conceptual Model of an AIIH Server Implementation..........11 70 7. AIIH DHCPv6 Requirements....................................11 71 7.1 DHCPv6 IPv4 Global Address Extension.......................11 72 7.2 AIIH Server Processing of an IPv4 Global Address Extension.12 73 7.3 AIIH Client Processing of an IPv4 Global Address Extension.13 74 8. Security Considerations.....................................13 75 9. Year 2000 Considerations....................................14 76 Appendix A - Open Issues.......................................14 77 Appendix B - Draft Changes and Rationale History...............15 78 Acknowledgments................................................16 79 References.....................................................16 80 Authors' Address...............................................17 81 1. Introduction 83 The initial deployment of IPv6 will require a tightly coupled use of 84 IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes 85 will be able to be deployed with IPv6 addresses, but will still need 86 to communicate with IPv4 nodes that do not have a dual IP layer 87 supporting both IPv4 and IPv6. This specification defines a 88 mechanism called Assignment of IPv4 Global Addresses to IPv6 Hosts 89 (AIIH), which will assign an IPv6 Host a temporary IPv4 Global 90 Address, which can be used to communicate with a Host that supports 91 IPv4 or IPv4/IPv6. An objective of this specification is to avoid 92 the use of address translation for the deployment of IPv6 in a 93 network. Another objective is to demonstrate that IPv6 Addresses can 94 be deployed now instead of non-Global IPv4 Addresses within an 95 Intranet. 97 AIIH uses the DNS [1,2] mechanisms to resolve a query for an IPv6 98 Host name from an IPv4 stack that wants to communicate with the IPv4 99 stack of an IPv6 Host that supports both IPv6 and IPv4. The IPv6 100 Host that is the object of such a query will be assigned a temporary 101 IPv4 Global Address, thru DHCPv6 [4], and the IPv4 Host performing 102 the query will receive the IPv4 address assigned to the IPv6 Host in 103 a DNS query response. Communications between the two Hosts can then 104 begin directly without any intermediate nodes performing Network 105 Address Translation [14] or Application Level Gateway [7] functions. 107 AIIH also permits IPv6 Hosts to request IPv4 Global Addresses thru 108 the new DHCPv6 Extension [5] defined in this specification (section 109 7). This new Extension will also provide the Host with the IPv4 or 110 IPv6 Tunnel End Point to be used to encapsulate an IPv4 packet [15] 111 to reach an IPv4 or IPv4/IPv6 router. 113 The reason for this specification is that users deploying IPv6 will 114 not want (and most likely will not be able) to assign IPv4 addresses 115 to IPv6 nodes as they are deployed into their site, because IPv4 116 addresses are a rare commodity. But, IPv6 Hosts will still need to 117 communicate with IPv4 Hosts within an Intranet and across the 118 Internet. The AIIH mechanisms provide a means to avoid address 119 translation in a network for IPv6 Hosts that support a dual IPv4/IPv6 120 network layer [15]. 122 The specification will begin by defining the terminology (section 2), 123 then discuss the AIIH design model (section 3), then define the 124 mechanism for an IPv6 Host to request an IPv4 address (section 4), 125 then define the mechanism used for an IPv4 node to query an IPv6 node 126 (section 5), then discuss the AIIH Server processing to support this 127 mechanism (section 6), and completes the mechanism by defining the 128 DHCPv6 Extension needed to assign a temporary IPv4 address to an IPv6 129 node (section 7). The specification then discusses Security (section 130 8) and Year 2000 considerations (section 9). Appendix A will discuss 131 Open Issues that need to be discussed in the ngtrans Tools Working 132 Group, and maintain the state of Open Issues as STILL OPEN, RESOLVED, 133 or PARTIALLY RESOLVED during the draft updates to AIIH. Appendix B 134 will keep a historical account of changes to the draft and rationale 135 for those changes as they occur, and maintain consistence with the 136 Open Issues in Appendix A. 138 2. Terminology 140 2.1 IPv6 NNAT Terminology 142 IPv6 Protocol Terms: See [3] 144 IPv6 Transition Terms: See [15] 146 DHCPv6 Terms: See [4,5] 148 AIIH Server: A Server that supports DNS [2] and DHCPv6 [4,5] 149 and communications between DNS and DHCPv6, which 150 is implementation defined. See sections 4, 5 151 and 6. 153 IPv4 Global Address: An IPv4 address that is globally routable on 154 the Internet. 156 2.2 Specification Language 158 In this document, several words are used to signify the requirements 159 of the specification, in accordance with RFC 2119 [9]. These words 160 are often capitalized. 162 MUST This word, or the adjective "required", means that 163 the definition is an absolute requirement of the 164 specification. 166 MUST NOT This phrase means that the definition is an absolute 167 prohibition of the specification. 169 SHOULD This word, or the adjective "recommended", means 170 that there may exist valid reasons in particular 171 circumstances to ignore this item, but the full 172 implications must be understood and carefully 173 weighed before choosing a different course. 174 Unexpected results may result otherwise. 176 MAY This word, or the adjective "optional", means that 177 this item is one of an allowed set of alternatives. 178 An implementation which does not include this option 179 MUST be prepared to interoperate with another 180 implementation which does include the option. 182 silently discard 183 The implementation discards the packet without 184 further processing, and without indicating an error 185 to the sender. The implementation SHOULD provide 186 the capability of logging the error, including the 187 contents of the discarded packet, and SHOULD record 188 the event in a statistics counter. 190 3. AIIH Design Model 192 The design model provides two mechanism to assign an IPv6 Host an 193 IPv4 address. The first mechanism is for the Host to request an IPv4 194 address that is globally routable, and the second is for an AIIH 195 Server to assign an IPv6 Host a globally routable IPv4 address using 196 the DHCPv6 Reconfigure Message. The assumption in this specification 197 is that a site has a certain number of IPv4 Global Addresses, which 198 can be assigned within their enterprise on a temporary basis for use 199 by Hosts in the site. The design model also assumes the site has an 200 IPv4/IPv6 router in the site that is used to send and receive packets 201 over the Internet. 203 For an IPv6 Host to participate in the AIIH mechanism it MUST have a 204 dual IP layer, supporting both an IPv4 and IPv6 stack. This 205 specification makes the assumption that for IPv6 initial deployment 206 Host nodes will not ship an IPv6-only stack implementation. For 207 embedded system type nodes that support only an IPv6 stack AIIH 208 cannot be a solution. 210 3.1 AIIH DHCPv6/DNS Server 212 The AIIH Server supports a co-located DHCPv6 and DNS Server and other 213 implementation defined software functions. The AIIH server 214 configuration files and database is not defined in this 215 specification. There can be one or many AIIH Servers on an Intranet 216 and how they maintain consistency and Tunnel End Point configurations 217 for IPv6 links is implementation defined. 219 3.2 AIIH Network Configuration Intranet to Internet Taxonomy 221 The design model supports the following network configuration abstraction: 223 Host X ----------------------- Router Y ------------------- Host Z 224 (Intranet) (Intranet & Internet) (Intranet) 226 Host X represents an IPv4/IPv6 implementation, that has an 227 IPv6 address. The IPv6 addresses is denoted as X6. 229 Router Y represents an IPv4/IPv6 implementation that has both 230 an IPv4 Global and IPv6 Address. The IPv4 address is denoted as 231 Y4 and the IPv6 address is denoted as Y6. 233 Host Z represents an IPv4 or IPv4/IPv6 implementation that has 234 an IPv4 Global Address, and MAY have an IPv6 Address. The IPv4 235 address is denoted as Z4 and if an IPv6 address exists it is 236 denoted as Z6. 238 For Host X to communicate with Host Z4 it must perform several 239 operations: 241 1. Obtain an IPv4 Global Address denoted by X4, from an AIIH 242 Server. 243 2. Send the packet to Y4 or Y6 so it can be routed to Z4. This can 244 be accomplished in several manners from the information 245 provided by the new DHCPv6 IPv4 Global Address Extension 246 (section 7) sent to X6: 248 2.1 If the Tunnel End Point is an IPv4-Compatible [20] 249 address then encapsulate IPv4 packets to Z4 within 250 IPv4 to reach Y4 [14]. 252 2.2 If the Tunnel End Point is an IPv6 Address then 253 encapsulate IPv4 packets to Z4 within IPv6 to reach 254 Y6 [13], this means an IPv4/IPv6 interim router exists 255 between X4 and Y6. 257 2.3 If the Tunnel End Point is zero (not present) then 258 it is assumed that the router on X4's LAN can route 259 IPv4 Global Addresses to Y4 within the site. This 260 means the site has an IPv4 Global Address backbone 261 at least for routability to Y4. 263 For Y4 to communicate with X4, upon receiving packets from 264 Z4 for X4 several options exist: 266 1. When Y4 received an IPv4 or encapsulated packet from 267 2.1 above then it MUST maintain that route to X4 268 from that IPv4 address and either encapsulate the 269 IPv4 packet to X4 or send it directly to the interim 270 router that can reach X4. 272 2. When Y4 received an IPv6 packet from X4 in 2.2 above 273 it MUST maintain a tunnel route to the IPv6 address 274 from which it received the X4 packet. 276 3. When Y4's site has an IPv4 Global Address backbone 277 routable network in place, Y4 uses normal routing 278 mechanisms to forward the packet to X4. 280 3.3 Accessing Hosts Services within an IPv6 Intranet 282 When Z4 wants to communicate with an application service on X4, the 283 mechanisms defined in section 5 will accomplish this task. For this 284 type of service Y4 and X4 MUST be able to communicate by way of an 285 IPv4 Global Address backbone network within the Site to X4. Section 286 5 also discusses Hosts within the Intranet accessing X4, when an IPv4 287 Global Address is used for that communications. 289 If the site is using non-Global IPv4 Addresses as a network topology 290 [17] for Intranet communications, Host X can obtain that address from 291 an IPv4 DHCPv4 Server [16] using X's IPv4 implementation and such 292 addresses are denoted as X4P (for IPv4 private address) and are only 293 used for site Intranet communications. 295 3.4 IPv6 Communications over the Internet with IPv4 Tunnels 297 AIIH could be used to communicate with IPv6 Hosts across the Internet 298 by X6 tunneling IPv6 packets in IPv4 to Y4, which would be delivered 299 to the network domain at Z. At Z's network the IPv4 packet would be 300 decapsulated and the IPv6 packet would be delivered to Z6. This 301 would add significant mechanisms to this specification and a possible 302 extension for future work around AIIH. But it is noted here now for 303 consistency, and as a possible future work item. 305 4. Requesting an IPv4 Global Address 307 An IPv4/IPv6 Host can request an IPv4 Global Address by using the 308 IPv4 Global Address Extension defined in section 7. The IPv4/IPv6 309 Host MUST support DHCPv6 [4] and the DHCPv6 Extensions [5]. The 310 Requests/Response Model of DHCPv6 will process this new extension as 311 any other extension. There is no need to define a new message type 312 for DHCPv6 for this processing or add to the DHCPv6 protocol. 314 Once the Host has obtained an IPv4 Global Address it SHOULD NOT 315 update DNS to reflect an A type or PTR type record for this address. 316 The reason is that the intent is to provide a Host with this 317 temporary address to use for communications with an IPv4 node. Once 318 the reason for obtaining an IPv4 Global Address has been satisfied 319 the Host MUST Release this IPv4 Global Address from the AIIH DHCPv6 320 Server implementation. 322 When an IPv4/IPv6 Host receives an IPv4 Global Address either from a 323 Request as a Client DHCPv6 Host or from an AIIH Server Reconfigure 324 Message as defined in section 6, the Host MUST create any necessary 325 configured tunnels using the Tunnel End Point address provided by the 326 AIIH DHCPv6 Server in an implementation defined manner. See section 327 7 for additional requirements for processing the DHCPv6 IPv4 Global 328 Address Extension. 330 5. IPv4 Query for an IPv6 Host 332 AIIH supports IPv4 DNS queries from the Internet or within an 333 Intranet to establish communications with an IPv6 Host. An IPv4 Host 334 will not necessarily know that it is trying to establish 335 communications with an IPv6 Host. The IPv4 Host will communicate 336 with the IPv6 Host by first obtaining an IPv4 Global Address for the 337 IPv6 node as it does for any other node (e.g. gethostbyname API). 339 5.1 Reaching the Intranet Primary DNS Server 341 The IPv4 DNS query will reach the Primary DNS Name Server for the 342 IPv6 Host. It is implementation defined how the DNS query passes 343 thru a domains Firewall [7] to reach the IPv6 nodes Primary DNS 344 Server. This is a per user policy that is beyond the scope of this 345 specification. 347 5.2 Getting the A Record Query to the AIIH Server 349 When the Primary DNS Server for the IPv6 node receives the IPv4 Hosts 350 query, it will do a DNS search for that IPv6 Host and find that there 351 is an Authoritative DNS Server for that specific DNS A record, which 352 represents an IPv6 Host. That DNS Server will be one part of the 353 AIIH Server software. After the AIIH DHCPv6 Server assigns the IPv6 354 node a temporary IPv4 Global Address, the AIIH DNS Server will 355 respond to the original IPv4 DNS query authoritatively with an IPv4 356 Global Address for the IPv6 Host or return Host Not Found. 358 For Example: 360 IPv4 node "v4host.abc.com" queries for "v6host1.xyz.com" 362 Query reaches Primary DNS Server for "v6host1.xyz.com". 364 ----------- 365 xyz.com. IN SOA primary.xyz.com. etc etc. 366 . 367 . 368 xyz.com IN NS primary.xyz.com 369 aiih.xyz.com IN NS v6trans.aiih.xyz.com 370 . 371 . 372 primary.xyz.com IN A 202.13.12.6 373 v6trans.aiih.xyz.com IN A 202.13.12.8 374 . 375 . 376 . 377 v6host1.xyz.com IN CNAME v6host1.aiih.xyz.com 378 v6host2.xyz.com IN CNAME v6host2.aiih.xyz.com 379 v6host3.xyz.com IN CNAME v6host3.aiih.xyz.com 381 DNS query will end up going to the authoritative server 382 v6trans.aiih.xyz.com looking for v6host1.aiih.xyz.com. This permits 383 the AIIH Server to now process a request for an IPv4 Global Address 384 for an IPv6 Host that had no IPv6 DNS AAAA Record [18]. 386 6. AIIH Server Processing 388 The AIIH Server is an implementation where DNS, DHCPv6, and 389 communications between those two applications exists. These 390 applications MAY be co-located on the same Host, but that is not a 391 requirement of this specification. How DNS and DHCPv6 communicate is 392 implementation defined. The AIIH Server SHOULD support the following 393 operations: 395 1. Act as the Authoritative DNS Name Server for a set of IPv6 396 Hosts that can be queried for IPv4 Global Addresses. 398 2. Communications between the AIIH DNS server and the AIIH DHCPv6 399 Server. 401 3. An AIIH DHCPv6 Server that can maintain a pool of IPv4 Global 402 Addresses in an implementation defined manner. 404 4. An AIIH DHCPv6 Server that can maintain Tunnel End Points for 405 IPv6 Links in an implementation defined manner. 407 5. An AIIH DHCPv6 Server to process DNS AIIH IPv6 Host DNS queries, 408 and Reconfiguring IPv6 Hosts to assign IPv4 Global Addresses to 409 their interfaces. 411 6. Support DHCPv6 Client's requesting IPv4 Global Addresses. 413 7. Dynamically Updating DNS with an IPv4 Global Address for 414 an IPv6 Host that supports IPv4/IPv6. 416 An AIIH Server MUST support a dual IPv4/IPv6 network layer and 417 implementation of IPv4/IPv6. 419 6.1 AIIH DNS Query and DHCPv6 Processing 421 Once the AIIH DNS finds the IPv6 Host (v6host1.xyz.com) being queried 422 the AIIH DNS requests from its corresponding AIIH DHCPv6 Server to 423 assign an IPv4 Global Address to the IPv6 Host being queried. 425 The AIIH DHCPv6 Server will look within its pool of IPv4 Global 426 Addresses for an address and if a Tunnel End Point address is 427 required for the IPv6 Host to reach the router (Y4) to route packets 428 onto the Internet. If an address is available the DHCPv6 Server will 429 send a DHCPv6 Reconfigure Message to the IPv6 node to temporarily 430 assign the node an IPv4 Global Address (see section 7). 432 Once the AIIH DHCPv6 server is certain that the IPv6 Host has 433 assigned the address to an interface, the AIIH DHCPv6 Server responds 434 back to the corresponding AIIH DNS Server with the IPv4 Global 435 Address assigned to the IPv6 Host being queried (v6host1.xyz.com), or 436 that an address could not be assigned to this IPv6 Host. 438 The AIIH DNS Server will now respond to the IPv4 DNS Query (Z4) as 439 the Authoritative DNS Name Server with an address or Host not found. 441 The AIIH DHCPv6 Server MAY send a dynamic update to DNS [6] to add an 442 A type record to the Primary DNS Server, where the query came from to 443 the AIIH DNS Server. The Time-To-Live (TTL) field in the update MUST 444 NOT be set to be greater than the valid lifetime for the IPv4- 445 Compatible address in the DHCPv6 Extension provided to the DHCPv6 446 Client. It is highly recommended that the DNS not be updated with an 447 A record for the IPv6 Host, unless that IPv6 Host provides a 448 permanent IPv4 Application service needed by IPv4 Hosts. 450 6.2 AIIH DHCPv6 Client IPv4 Global Address Requests 452 An AIIH DHCPv6 Server will receive DHCPv6 Requests for IPv4 Global 453 Addresses from IPv6 Host's. The AIIH DHCPv6 Server will determine if 454 an address is available and assign the address to the DHCPv6 Client 455 as specified in section 7 of this specification. 457 A DHCPv6 Client MUST NOT dynamically update DNS with an A record for 458 an IPv4 Global Address it has been assigned. All updates to DNS MUST 459 be done by the AIIH DHCPv6 Server. A DHCPv6 Client MAY request an 460 that an address it has been assigned be added to the DNS, but as 461 stated in section 6.1 this behavior is discouraged unless the Client 462 perceives that an application it is providing will be of a permanent 463 nature for IPv4 Hosts, as opposed to a transient need for an IPv4 464 Global Address from the AIIH DHCPv6 Server. 466 6.3 Cleaning up the AIIH IPv4 Assigned Address 468 Once the IPv4 address expires the DHCPv6 Server will permit the IPv4 469 address to be reused. But before the address can be reused the 470 DHCPv6 Server MUST delete the IPv4 address from the Primary DNS 471 Server, thru the Dynamic Updates to DNS mechanism, if an A record was 472 added to the relative Primary DNS Server. 474 6.3 Conceptual Model of an AIIH Server Implementation 476 A conceptual model (not part of this specification) for the AIIH DNS 477 Server and DHCPv6 Server to communicate could be a number of 478 mechanisms that support interprocess communications between two 479 processes (e.g. Threads, Local Domain Sockets, Shared Memory). The 480 IPv4 pool of addresses maintained by the DHCPv6 server is 481 implementation defined how that is obtained and configured as is 482 specified for IPv6 addresses in DHCPv6. Once the IPv4 address is 483 assigned it can be kept as part of the IPv6 nodes binding entry on 484 the DHCPv6 Server as other configuration data is specified in DHCPv6. 486 7. AIIH DHCPv6 Requirements 488 The AIIH DHCPv6 processes will use the DHCPv6 protocol and extensions 489 to communicate between the AIIH DHCPv6 Server and the DHCPv6 Client. 490 A new extension is required for DHCPv6 (section 7.1) to support AIIH. 491 But there are some additional requirements placed on the AIIH 492 processes that are not specific to the DHCPv6 protocol, but as 493 transition and interoperation mechanisms for the IPv6 Hosts. 495 7.1 DHCPv6 IPv4 Global Address Extension 497 The DHCPv6 IPv4 Global Address Extension informs a DHCPv6 498 Server or Client that the IPv6 Address Extension [5] following this 499 extension will contain an IPv4-Compatible Address [20], or is a Request 500 for an IPv4 Global Address from a Client, or a Reply assigning a Global 501 IPv4 Address to a Client from a Server. The extension can also 502 provide an IPv4-Compatible or IPv6 address to be used as the Tunnel 503 End Point to encapsulate an IPv6 packet within IPv4, or an IPv4 504 packet within IPv6. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Tunnel End Point | 512 | (If Present) | 513 | (16 octets) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Type: TBD 517 Length: 0 or 16 518 Tunnel End Point: IPv6 Address if Present 520 An IPv4 Global Address Extension MUST only apply to the extension 521 following and not to any additional extensions in the DHCPv6 522 protocol. 524 7.2 AIIH Server Processing of an IPv4 Global Address Extension 526 When a DHCPv6 Server receives an IPv4 Global Address Extension it 527 MUST assume that the next extension in a DHCPv6 Request or Release 528 Message; the Client is either Requesting an IPv4 Global Address or 529 Releasing an IPv4 Global Address. If an address is present in either 530 of these messages it will be in the form of an IPv4-Compatible 531 Address. 533 When a DHCPv6 Server sends a Client a Reconfigure Message to assign 534 an IPv4 Global Address to an interface the Server MUST NOT set the 535 "N" bit in the Reconfigure Message, so the Client performs the 536 necessary Request/Reply DHCPv6 processing to obtain the address from 537 the Server. The Server MUST NOT assume that the Client has assigned 538 the address to an interface until it has sent the corresponding Reply 539 to the Client. 541 The Server will no a priori the IPv6 routable address, when sending a 542 Reconfiguration Message, of a Client within the Intranet, and should 543 use that address with its own IPv6 address as the transaction binding 544 cache until the DHCPv6 Client/Server protocol processing has 545 completed. 547 The Server will look in its implementation defined IPv4 Global 548 Address configuration to determine if a Tunnel End Point is required 549 for a specific IPv6 Address Prefix. If that is the case the Server 550 will put the address for the Tunnel End Point in the IPv4 Global 551 Address Extension. If the Tunnel End Point address is an IPv4 552 address the Server will put that address in the extension as an 553 IPv4-Compatible address. 555 7.3 AIIH Client Processing of an IPv4 Global Address Extension 557 When a DHCPv6 Client receives an IPv4 Global Address Extension it 558 MUST assume that the next extension in a DHCPv6 Reconfigure or Reply 559 Message; the Server is either assigning an IPv4 Global Address or 560 supplying an IPv4 Global Address. The address present in either of 561 these messages will be in the form of an IPv4-Compatible Address. 563 When the Client supplies an IPv4 Global Address as a Request or 564 Release it MUST represent that address as an IPv4-Compatible Address. 566 The Client MUST not assume it can use the IPv4 Global Address until 567 it has received a corresponding Reply to the Client Request, which is 568 required for a Reconfigure Message too as specified in section 7.2. 570 Once the Client is assured it can use the IPv4 Global Address it can 571 perform the following operations: 573 1. In an implementation defined manner the Client MUST assign the 574 address to an interface, supporting the Client's IPv4 stack 575 implementation. 577 2. In an implementation defined manner the Client MUST create an entry 578 as an IPv4-Compatible Address supporting the processing required 579 for an IPv6 address regarding the valid and preferred lifetimes 580 as specified in IPv6 Addrconf [19]. Once the IPv4-Compatible 581 address valid lifetime expires the IPv4 address MUST be deleted 582 from the respective interface and a DHCPv6 Release Message 583 MUST be sent to the AIIH DHCPv6 Server to delete the IPv4 Global 584 Address from the Servers bindings. 586 3. If a Tunnel End Point address is provided in the IPv4 Global 587 Address Extension, the Client MUST create a configured tunnel 588 to the Tunnel End Point address, in an implementation defined 589 manner. If the Tunnel End Point address is an IPv4-Compatible 590 address then the encapsulation is IPv4 within IPv4, if the 591 Tunnel End Point is an IPv6 address then the encapsulation 592 is IPv6 in IPv4. These encapsulation mechanisms are defined 593 in other IPv6 specifications [13, 15]. 595 8. Security Considerations 597 The AIIH mechanism can use all the defined security specifications 598 for each functional part of the operation. For DNS the DNS Security 599 Extensions/Update can be used [10, 11], for DHCPv6 the DHCPv6 600 Authentication Message can be used [5], and for communications 601 between the IPv6 node, once it has an IPv4 address, and the remote 602 IPv4 node, IPSEC [8] can be used as AIIH does not break secure end- 603 to-end communications at any point in the mechanism. 605 9. Year 2000 Considerations 607 There are no Year 2000 issues in this specification. 609 Appendix A - Open Issues 611 December 1997 draft-ietf-ngtrans-nnat-00.txt 613 - The draft does not speak of PTR records for the IPv6 node 614 A record once its created. But its only useful during the 615 lifetime of the assigned IPv4 address. 617 STILL OPEN 3/98 Draft. 619 - RFC 1183 RT Record is Experimental and there is some concern 620 its obsolete. Though some implementations still support some 621 code for the RT record. Also the Route Through semantics 622 specified may need to strongly state the query is passed thru 623 to the NNAT server. This needs to be discussed. 625 RESOLVED 3/98 Draft RT record deprecated. 627 - The Primary Server must look for the IPv6 node A record first 628 before finding the RT record. This needs to be verified 629 as an implementation issue. 631 RESOLVED 3/98 Draft - Use CNAME Records. 633 - When the NNAT Server responds to the query it may not be 634 authoritative. This needs to be verified and checked. 636 RESOLVED 3/98 Draft - Use CNAME Records and AIIH Server will 637 be authoritative for the AIIH ZONE. 639 - Use of TTL for DNS Caches can cause problems for existing IPv4 640 applications that cache IPv4 addresses. 642 PARTIALLY RESOLVED - 3/98 Draft do not update DNS unless 643 application will be permanent as opposed to transient. 644 But TTL's that are updated still need some thought for 645 legacy applications. This also points to possibly adding 646 new fields to the hostent structure which will at least 647 help new IPv6 applications and legacy IPv4 applications 648 to change to act in a well behaved manner. 650 - Specification needs a design example to get packets from 651 the IPv6 node to an egress IPv4 router. 653 PARTIALLY RESOLVED - 3/98 Draft added Design Section discussing 654 tunneling mechanisms to be used and added Tunnel End Point address 655 supplied by the AIIH DHCPv6 Server. Still needs more discussion. 657 - NNAT name does not state what the specification does. 659 RESOLVED - 3/98 Draft changed name to AIIH. 661 Appendix B - Draft Changes and Rationale History 663 March 1998 draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt 665 - Changed the name of the draft from NNAT to AIIH. This also 666 was done to prevent any perceived antagonism towards the NAT 667 IETF work, which is not an objective of this work. 669 - Changed the Introduction to be more descriptive of the task 670 at hand. 672 - Added IPv4 Global Address definition to terminology section. 674 - Added tunnel routability discussion to Design Model and a 675 diagram abstraction to be used by the specification as 676 a point of reference. 678 - Added to the architecture the ability for an IPv6 node to 679 request an IPv4 Global Address from an AIIH DHCPv6 Server. 680 This will permit AIIH to not only be useful for incoming 681 IPv4 Host communications with IPv6 Hosts but also for outgoing 682 IPv4 communications to the Internet from IPv6 Hosts and for 683 Intranet enterprise communications between an IPv6 Host and 684 IPv4 Host. 686 - Hinted that AIIH could be used in future work to define 687 the capability for two IPv6 Hosts separated by an IPv4 cloud to 688 to communicate thru tunnels, like thru a production 6bone 689 network on the Internet. 691 - Added new section to define how an IPv6 Host can request 692 an IPv4 Global Address. 694 - Defined new mechanism for DNS query processing when an IPv6 695 Host is looked for from an IPv4 Host, thru the use of CNAME 696 and NS records. This also permits IPv4 Host Intranet queries 697 too now. 699 - New text clarifying that within the Intranet processing AIIH 700 must only be used with IPv4 Global Addresses and Private 701 IPv4 addresses should be retrieved from DHCPv4, via the IPv6 702 Hosts IPv4 stack. 704 - Added new text defining the AIIH Server and the interaction 705 with DHCPv6 and DNS applications. Also further refined the 706 requirements of the AIIH Server model. 708 - Expanded the section on the new DHCPv6 Section defining the 709 required Server and Client behavior. Added support to permit 710 AIIH to be used for Intranet and Internet communications from 711 within the site. 713 - Changed the DHCPv6 Extension for IPv4 Global Addresses to 714 make it an extension which defines the next extension to 715 be a request for AIIH processing relative to DHCPv6. 717 - Added a Tunnel End Point address to the new extension so 718 IPv6 Hosts can configure tunnels to communicate with the 719 egress router to transmit or reply with IPv4 on the Internet 720 or within the Intranet. 722 - Defined the AIIH side affect requirements for IPv6 Hosts using 723 this mechanism with DHCPv6. 725 - Updated and added to the Acknowledgment and References Section. 727 - Updated the Open Issues from December 1997 draft and noted 728 the status of each issue as STILL OPEN, RESOLVED, or PARTIALLY 729 RESOLVED. 731 - Updated the Changes from this draft. 733 Acknowledgments 735 The author would like to thank Erik Nordmark for spending time 736 reviewing with him this idea and suggesting the use of the DHCPv6 737 Reconfigure Message, Richard Johnson for suggesting the use of the 738 DNS CNAME Record, and Robert Watson who suggested that the AIIH 739 DHCPv6 and DNS Server be co-located. George Tsirtsis who suggested 740 using AIIH to assign IPv4 Global Addresses to IPv6 Hosts in general. 741 Richard Draves and Jack McCann who have provided many helpful 742 technical suggestions, and the NGTRANS working group for taking the 743 time to work on AIIH. 745 References 747 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 748 13, RFC 1034, USC/Information Sciences Institute, November 1987. 750 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 751 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 752 November 1987. 754 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 755 Architecture", draft-ietf-ipngwg-ipv6-spec-v2-01.txt, 756 December 1997 (work in progress). 758 [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol 759 for IPv6. draft-ietf-dhc-dhcpv6-13.txt March 1998 (work 760 in progress). 762 [5] C. Perkins. Extensions for the Dynamic Host Configuration 763 Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-09.txt March 764 1998. (work in progress). 766 [6] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 767 to the Domain Name System (DNS). RFC 2136, April 1997. 769 [7] William R. Cheswick and Steven Bellovin. Firewalls and Internet 770 Security. Addison-Wesley, Reading, MA 1994 (ISBN: 771 0-201-63357-4). 773 [8] IPSEC *TBD* - This needs to include the Arch, Auth, and ESP specs. 775 [9] S. Bradner. Key words for use in RFCs to indicate Requirement 776 Levels. RFC 2119, March 1997. 778 [10] D. Eastlake and C. Kaufman. Domain Name System Security 779 Extensions. RFC 2065, January 1997. 781 [11] D. Eastlake. Secure Domain Name System Dynamic Update. 782 RFC 2137, April 1997. 784 [12] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition 785 RFC 2185, September 1997. 787 [13] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 788 draft-ietf-ipngwg-ipv6-tunnel-08.txt. January 1998. 789 (work in progress). 791 [14] E. Nordmark. IPv4/IPv6 Stateless Header Translator 792 draft-ietf-ngtrans-header-trans-00.txt. July 1997. 793 (work in progress). 795 [15] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 796 Hosts and Routers. draft-ietf-ngtrans-trans-mech-00.txt, 797 November 1997 (work in progress). 799 [16] R. Droms. Dynamic Host Configuration Protocol. 800 RFC 2131, March 1997. 802 [17] Rekhter, Moskowitz, Karrenburg, Groot. Address Allocation 803 for Private Networks. RFC 1918. February 1996. 805 [18] Huitema, Thomson. DNS Extensions to support IP version 6. 806 draft-ietf-ipngwg-aaaa-03.txt, February 1998 807 (work in progress). 809 [19] Thomson, Narten. IPv6 Stateless Address Configuration. 810 draft-ietf-ipngwg-addrconf-v2-02.txt, February 1998, 811 (work in progress). 813 [20] Hinden, Deering. IP Version 6 Addressing Architecture. 814 draft-ietf-ipngwg-addr-arch-v2-06.txt, January 1998. 815 (work in progress). 817 Authors' Address 819 Jim Bound 820 Digital Equipment Corporation 821 110 Spitbrook Road, ZKO3-3/U14 822 Nashua, NH 03062 823 Phone: (603) 884-0400 824 Email: bound@zk3.dec.com