INTERNET-DRAFT Jim Bound NGTRANS Tools Working Group Digital Equipment Corp Obsoletes draft-ietf-ngtrans-nnat-00.txt March 1998 Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH) <draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt> Status of this Memo This document is a submission by the Next Generation Transition Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ngtrans@sunroof.eng.sun.com mailing list. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes will be able to be deployed with IPv6 addresses, but will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. This specification defines a mechanism called Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH), which will assign an IPv6 Host a temporary IPv4 Global Address, which can be used to communicate with a Host that supports IPv4 or IPv4/IPv6. An objective of this specification is to avoid the use of address translation for the deployment of IPv6 in a network. Another objective is to demonstrate that IPv6 Addresses can be deployed now instead of non-Global IPv4 Addresses within an Intranet. Bound Expires September 1998 [Page 1]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 Table of Contents: 1. Introduction.................................................3 2. Terminology..................................................4 2.1 IPv6 NNAT Terminology.......................................4 2.2 Specification Language......................................5 3. AIIH Design Model ...........................................6 3.1 AIIH DHCPv6/DNS Server......................................6 3.2 AIIH Network Configuration Intranet to Internet Taxonomy....6 3.3 Accessing Hosts Services within an IPv6 Intranet............7 3.4 IPv6 Communications over the Internet with IPv4 Tunnels.....8 4. Requesting an IPv4 Global Address............................8 5. IPv4 Query for an IPv6 Host..................................8 5.1 Reaching the Intranet Primary DNS Server....................8 5.2 Getting the A Record Query to the AIIH Server...............9 6. AIIH Server Processing.......................................9 6.1 AIIH DNS Query and DHCPv6 Processing.......................10 6.2 AIIH DHCPv6 Client IPv4 Global Address Requests............11 6.3 Cleaning up the AIIH IPv4 Assigned Address.................11 6.3 Conceptual Model of an AIIH Server Implementation..........11 7. AIIH DHCPv6 Requirements....................................11 7.1 DHCPv6 IPv4 Global Address Extension.......................11 7.2 AIIH Server Processing of an IPv4 Global Address Extension.12 7.3 AIIH Client Processing of an IPv4 Global Address Extension.13 8. Security Considerations.....................................13 9. Year 2000 Considerations....................................14 Appendix A - Open Issues.......................................14 Appendix B - Draft Changes and Rationale History...............15 Acknowledgments................................................16 References.....................................................16 Authors' Address...............................................17 Bound Expires September 1998 [Page 2]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 1. Introduction The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4. Nodes will be able to be deployed with IPv6 addresses, but will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. This specification defines a mechanism called Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH), which will assign an IPv6 Host a temporary IPv4 Global Address, which can be used to communicate with a Host that supports IPv4 or IPv4/IPv6. An objective of this specification is to avoid the use of address translation for the deployment of IPv6 in a network. Another objective is to demonstrate that IPv6 Addresses can be deployed now instead of non-Global IPv4 Addresses within an Intranet. AIIH uses the DNS [1,2] mechanisms to resolve a query for an IPv6 Host name from an IPv4 stack that wants to communicate with the IPv4 stack of an IPv6 Host that supports both IPv6 and IPv4. The IPv6 Host that is the object of such a query will be assigned a temporary IPv4 Global Address, thru DHCPv6 [4], and the IPv4 Host performing the query will receive the IPv4 address assigned to the IPv6 Host in a DNS query response. Communications between the two Hosts can then begin directly without any intermediate nodes performing Network Address Translation [14] or Application Level Gateway [7] functions. AIIH also permits IPv6 Hosts to request IPv4 Global Addresses thru the new DHCPv6 Extension [5] defined in this specification (section 7). This new Extension will also provide the Host with the IPv4 or IPv6 Tunnel End Point to be used to encapsulate an IPv4 packet [15] to reach an IPv4 or IPv4/IPv6 router. The reason for this specification is that users deploying IPv6 will not want (and most likely will not be able) to assign IPv4 addresses to IPv6 nodes as they are deployed into their site, because IPv4 addresses are a rare commodity. But, IPv6 Hosts will still need to communicate with IPv4 Hosts within an Intranet and across the Internet. The AIIH mechanisms provide a means to avoid address translation in a network for IPv6 Hosts that support a dual IPv4/IPv6 network layer [15]. The specification will begin by defining the terminology (section 2), then discuss the AIIH design model (section 3), then define the mechanism for an IPv6 Host to request an IPv4 address (section 4), then define the mechanism used for an IPv4 node to query an IPv6 node (section 5), then discuss the AIIH Server processing to support this mechanism (section 6), and completes the mechanism by defining the DHCPv6 Extension needed to assign a temporary IPv4 address to an IPv6 node (section 7). The specification then discusses Security (section 8) and Year 2000 considerations (section 9). Appendix A will discuss Open Issues that need to be discussed in the ngtrans Tools Working Group, and maintain the state of Open Issues as STILL OPEN, RESOLVED, or PARTIALLY RESOLVED during the draft updates to AIIH. Appendix B will keep a historical account of changes to the draft and rationale for those changes as they occur, and maintain consistence with the Open Issues in Appendix A. Bound Expires September 1998 [Page 3]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 2. Terminology 2.1 IPv6 NNAT Terminology IPv6 Protocol Terms: See [3] IPv6 Transition Terms: See [15] DHCPv6 Terms: See [4,5] AIIH Server: A Server that supports DNS [2] and DHCPv6 [4,5] and communications between DNS and DHCPv6, which is implementation defined. See sections 4, 5 and 6. IPv4 Global Address: An IPv4 address that is globally routable on the Internet. Bound Expires September 1998 [Page 4]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 2.2 Specification Language In this document, several words are used to signify the requirements of the specification, in accordance with RFC 2119 [9]. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. Unexpected results may result otherwise. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. silently discard The implementation discards the packet without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded packet, and SHOULD record the event in a statistics counter. Bound Expires September 1998 [Page 5]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 3. AIIH Design Model The design model provides two mechanism to assign an IPv6 Host an IPv4 address. The first mechanism is for the Host to request an IPv4 address that is globally routable, and the second is for an AIIH Server to assign an IPv6 Host a globally routable IPv4 address using the DHCPv6 Reconfigure Message. The assumption in this specification is that a site has a certain number of IPv4 Global Addresses, which can be assigned within their enterprise on a temporary basis for use by Hosts in the site. The design model also assumes the site has an IPv4/IPv6 router in the site that is used to send and receive packets over the Internet. For an IPv6 Host to participate in the AIIH mechanism it MUST have a dual IP layer, supporting both an IPv4 and IPv6 stack. This specification makes the assumption that for IPv6 initial deployment Host nodes will not ship an IPv6-only stack implementation. For embedded system type nodes that support only an IPv6 stack AIIH cannot be a solution. 3.1 AIIH DHCPv6/DNS Server The AIIH Server supports a co-located DHCPv6 and DNS Server and other implementation defined software functions. The AIIH server configuration files and database is not defined in this specification. There can be one or many AIIH Servers on an Intranet and how they maintain consistency and Tunnel End Point configurations for IPv6 links is implementation defined. 3.2 AIIH Network Configuration Intranet to Internet Taxonomy The design model supports the following network configuration abstraction: Host X ----------------------- Router Y ------------------- Host Z (Intranet) (Intranet & Internet) (Intranet) Host X represents an IPv4/IPv6 implementation, that has an IPv6 address. The IPv6 addresses is denoted as X6. Router Y represents an IPv4/IPv6 implementation that has both an IPv4 Global and IPv6 Address. The IPv4 address is denoted as Y4 and the IPv6 address is denoted as Y6. Host Z represents an IPv4 or IPv4/IPv6 implementation that has an IPv4 Global Address, and MAY have an IPv6 Address. The IPv4 address is denoted as Z4 and if an IPv6 address exists it is denoted as Z6. For Host X to communicate with Host Z4 it must perform several operations: 1. Obtain an IPv4 Global Address denoted by X4, from an AIIH Server. 2. Send the packet to Y4 or Y6 so it can be routed to Z4. This can Bound Expires September 1998 [Page 6]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 be accomplished in several manners from the information provided by the new DHCPv6 IPv4 Global Address Extension (section 7) sent to X6: 2.1 If the Tunnel End Point is an IPv4-Compatible [20] address then encapsulate IPv4 packets to Z4 within IPv4 to reach Y4 [14]. 2.2 If the Tunnel End Point is an IPv6 Address then encapsulate IPv4 packets to Z4 within IPv6 to reach Y6 [13], this means an IPv4/IPv6 interim router exists between X4 and Y6. 2.3 If the Tunnel End Point is zero (not present) then it is assumed that the router on X4's LAN can route IPv4 Global Addresses to Y4 within the site. This means the site has an IPv4 Global Address backbone at least for routability to Y4. For Y4 to communicate with X4, upon receiving packets from Z4 for X4 several options exist: 1. When Y4 received an IPv4 or encapsulated packet from 2.1 above then it MUST maintain that route to X4 from that IPv4 address and either encapsulate the IPv4 packet to X4 or send it directly to the interim router that can reach X4. 2. When Y4 received an IPv6 packet from X4 in 2.2 above it MUST maintain a tunnel route to the IPv6 address from which it received the X4 packet. 3. When Y4's site has an IPv4 Global Address backbone routable network in place, Y4 uses normal routing mechanisms to forward the packet to X4. 3.3 Accessing Hosts Services within an IPv6 Intranet When Z4 wants to communicate with an application service on X4, the mechanisms defined in section 5 will accomplish this task. For this type of service Y4 and X4 MUST be able to communicate by way of an IPv4 Global Address backbone network within the Site to X4. Section 5 also discusses Hosts within the Intranet accessing X4, when an IPv4 Global Address is used for that communications. If the site is using non-Global IPv4 Addresses as a network topology [17] for Intranet communications, Host X can obtain that address from an IPv4 DHCPv4 Server [16] using X's IPv4 implementation and such addresses are denoted as X4P (for IPv4 private address) and are only used for site Intranet communications. Bound Expires September 1998 [Page 7]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 3.4 IPv6 Communications over the Internet with IPv4 Tunnels AIIH could be used to communicate with IPv6 Hosts across the Internet by X6 tunneling IPv6 packets in IPv4 to Y4, which would be delivered to the network domain at Z. At Z's network the IPv4 packet would be decapsulated and the IPv6 packet would be delivered to Z6. This would add significant mechanisms to this specification and a possible extension for future work around AIIH. But it is noted here now for consistency, and as a possible future work item. 4. Requesting an IPv4 Global Address An IPv4/IPv6 Host can request an IPv4 Global Address by using the IPv4 Global Address Extension defined in section 7. The IPv4/IPv6 Host MUST support DHCPv6 [4] and the DHCPv6 Extensions [5]. The Requests/Response Model of DHCPv6 will process this new extension as any other extension. There is no need to define a new message type for DHCPv6 for this processing or add to the DHCPv6 protocol. Once the Host has obtained an IPv4 Global Address it SHOULD NOT update DNS to reflect an A type or PTR type record for this address. The reason is that the intent is to provide a Host with this temporary address to use for communications with an IPv4 node. Once the reason for obtaining an IPv4 Global Address has been satisfied the Host MUST Release this IPv4 Global Address from the AIIH DHCPv6 Server implementation. When an IPv4/IPv6 Host receives an IPv4 Global Address either from a Request as a Client DHCPv6 Host or from an AIIH Server Reconfigure Message as defined in section 6, the Host MUST create any necessary configured tunnels using the Tunnel End Point address provided by the AIIH DHCPv6 Server in an implementation defined manner. See section 7 for additional requirements for processing the DHCPv6 IPv4 Global Address Extension. 5. IPv4 Query for an IPv6 Host AIIH supports IPv4 DNS queries from the Internet or within an Intranet to establish communications with an IPv6 Host. An IPv4 Host will not necessarily know that it is trying to establish communications with an IPv6 Host. The IPv4 Host will communicate with the IPv6 Host by first obtaining an IPv4 Global Address for the IPv6 node as it does for any other node (e.g. gethostbyname API). 5.1 Reaching the Intranet Primary DNS Server The IPv4 DNS query will reach the Primary DNS Name Server for the IPv6 Host. It is implementation defined how the DNS query passes thru a domains Firewall [7] to reach the IPv6 nodes Primary DNS Server. This is a per user policy that is beyond the scope of this Bound Expires September 1998 [Page 8]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 specification. 5.2 Getting the A Record Query to the AIIH Server When the Primary DNS Server for the IPv6 node receives the IPv4 Hosts query, it will do a DNS search for that IPv6 Host and find that there is an Authoritative DNS Server for that specific DNS A record, which represents an IPv6 Host. That DNS Server will be one part of the AIIH Server software. After the AIIH DHCPv6 Server assigns the IPv6 node a temporary IPv4 Global Address, the AIIH DNS Server will respond to the original IPv4 DNS query authoritatively with an IPv4 Global Address for the IPv6 Host or return Host Not Found. For Example: IPv4 node "v4host.abc.com" queries for "v6host1.xyz.com" Query reaches Primary DNS Server for "v6host1.xyz.com". ----------- xyz.com. IN SOA primary.xyz.com. etc etc. . . xyz.com IN NS primary.xyz.com aiih.xyz.com IN NS v6trans.aiih.xyz.com . . primary.xyz.com IN A 202.13.12.6 v6trans.aiih.xyz.com IN A 202.13.12.8 . . . v6host1.xyz.com IN CNAME v6host1.aiih.xyz.com v6host2.xyz.com IN CNAME v6host2.aiih.xyz.com v6host3.xyz.com IN CNAME v6host3.aiih.xyz.com DNS query will end up going to the authoritative server v6trans.aiih.xyz.com looking for v6host1.aiih.xyz.com. This permits the AIIH Server to now process a request for an IPv4 Global Address for an IPv6 Host that had no IPv6 DNS AAAA Record [18]. 6. AIIH Server Processing The AIIH Server is an implementation where DNS, DHCPv6, and communications between those two applications exists. These applications MAY be co-located on the same Host, but that is not a requirement of this specification. How DNS and DHCPv6 communicate is implementation defined. The AIIH Server SHOULD support the following operations: 1. Act as the Authoritative DNS Name Server for a set of IPv6 Hosts that can be queried for IPv4 Global Addresses. 2. Communications between the AIIH DNS server and the AIIH DHCPv6 Bound Expires September 1998 [Page 9]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 Server. 3. An AIIH DHCPv6 Server that can maintain a pool of IPv4 Global Addresses in an implementation defined manner. 4. An AIIH DHCPv6 Server that can maintain Tunnel End Points for IPv6 Links in an implementation defined manner. 5. An AIIH DHCPv6 Server to process DNS AIIH IPv6 Host DNS queries, and Reconfiguring IPv6 Hosts to assign IPv4 Global Addresses to their interfaces. 6. Support DHCPv6 Client's requesting IPv4 Global Addresses. 7. Dynamically Updating DNS with an IPv4 Global Address for an IPv6 Host that supports IPv4/IPv6. An AIIH Server MUST support a dual IPv4/IPv6 network layer and implementation of IPv4/IPv6. 6.1 AIIH DNS Query and DHCPv6 Processing Once the AIIH DNS finds the IPv6 Host (v6host1.xyz.com) being queried the AIIH DNS requests from its corresponding AIIH DHCPv6 Server to assign an IPv4 Global Address to the IPv6 Host being queried. The AIIH DHCPv6 Server will look within its pool of IPv4 Global Addresses for an address and if a Tunnel End Point address is required for the IPv6 Host to reach the router (Y4) to route packets onto the Internet. If an address is available the DHCPv6 Server will send a DHCPv6 Reconfigure Message to the IPv6 node to temporarily assign the node an IPv4 Global Address (see section 7). Once the AIIH DHCPv6 server is certain that the IPv6 Host has assigned the address to an interface, the AIIH DHCPv6 Server responds back to the corresponding AIIH DNS Server with the IPv4 Global Address assigned to the IPv6 Host being queried (v6host1.xyz.com), or that an address could not be assigned to this IPv6 Host. The AIIH DNS Server will now respond to the IPv4 DNS Query (Z4) as the Authoritative DNS Name Server with an address or Host not found. The AIIH DHCPv6 Server MAY send a dynamic update to DNS [6] to add an A type record to the Primary DNS Server, where the query came from to the AIIH DNS Server. The Time-To-Live (TTL) field in the update MUST NOT be set to be greater than the valid lifetime for the IPv4- Compatible address in the DHCPv6 Extension provided to the DHCPv6 Client. It is highly recommended that the DNS not be updated with an A record for the IPv6 Host, unless that IPv6 Host provides a permanent IPv4 Application service needed by IPv4 Hosts. Bound Expires September 1998 [Page 10]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 6.2 AIIH DHCPv6 Client IPv4 Global Address Requests An AIIH DHCPv6 Server will receive DHCPv6 Requests for IPv4 Global Addresses from IPv6 Host's. The AIIH DHCPv6 Server will determine if an address is available and assign the address to the DHCPv6 Client as specified in section 7 of this specification. A DHCPv6 Client MUST NOT dynamically update DNS with an A record for an IPv4 Global Address it has been assigned. All updates to DNS MUST be done by the AIIH DHCPv6 Server. A DHCPv6 Client MAY request an that an address it has been assigned be added to the DNS, but as stated in section 6.1 this behavior is discouraged unless the Client perceives that an application it is providing will be of a permanent nature for IPv4 Hosts, as opposed to a transient need for an IPv4 Global Address from the AIIH DHCPv6 Server. 6.3 Cleaning up the AIIH IPv4 Assigned Address Once the IPv4 address expires the DHCPv6 Server will permit the IPv4 address to be reused. But before the address can be reused the DHCPv6 Server MUST delete the IPv4 address from the Primary DNS Server, thru the Dynamic Updates to DNS mechanism, if an A record was added to the relative Primary DNS Server. 6.3 Conceptual Model of an AIIH Server Implementation A conceptual model (not part of this specification) for the AIIH DNS Server and DHCPv6 Server to communicate could be a number of mechanisms that support interprocess communications between two processes (e.g. Threads, Local Domain Sockets, Shared Memory). The IPv4 pool of addresses maintained by the DHCPv6 server is implementation defined how that is obtained and configured as is specified for IPv6 addresses in DHCPv6. Once the IPv4 address is assigned it can be kept as part of the IPv6 nodes binding entry on the DHCPv6 Server as other configuration data is specified in DHCPv6. 7. AIIH DHCPv6 Requirements The AIIH DHCPv6 processes will use the DHCPv6 protocol and extensions to communicate between the AIIH DHCPv6 Server and the DHCPv6 Client. A new extension is required for DHCPv6 (section 7.1) to support AIIH. But there are some additional requirements placed on the AIIH processes that are not specific to the DHCPv6 protocol, but as transition and interoperation mechanisms for the IPv6 Hosts. 7.1 DHCPv6 IPv4 Global Address Extension The DHCPv6 IPv4 Global Address Extension informs a DHCPv6 Server or Client that the IPv6 Address Extension [5] following this extension will contain an IPv4-Compatible Address [20], or is a Request Bound Expires September 1998 [Page 11]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 for an IPv4 Global Address from a Client, or a Reply assigning a Global IPv4 Address to a Client from a Server. The extension can also provide an IPv4-Compatible or IPv6 address to be used as the Tunnel End Point to encapsulate an IPv6 packet within IPv4, or an IPv4 packet within IPv6. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel End Point | | (If Present) | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 0 or 16 Tunnel End Point: IPv6 Address if Present An IPv4 Global Address Extension MUST only apply to the extension following and not to any additional extensions in the DHCPv6 protocol. 7.2 AIIH Server Processing of an IPv4 Global Address Extension When a DHCPv6 Server receives an IPv4 Global Address Extension it MUST assume that the next extension in a DHCPv6 Request or Release Message; the Client is either Requesting an IPv4 Global Address or Releasing an IPv4 Global Address. If an address is present in either of these messages it will be in the form of an IPv4-Compatible Address. When a DHCPv6 Server sends a Client a Reconfigure Message to assign an IPv4 Global Address to an interface the Server MUST NOT set the "N" bit in the Reconfigure Message, so the Client performs the necessary Request/Reply DHCPv6 processing to obtain the address from the Server. The Server MUST NOT assume that the Client has assigned the address to an interface until it has sent the corresponding Reply to the Client. The Server will no a priori the IPv6 routable address, when sending a Reconfiguration Message, of a Client within the Intranet, and should use that address with its own IPv6 address as the transaction binding cache until the DHCPv6 Client/Server protocol processing has completed. The Server will look in its implementation defined IPv4 Global Address configuration to determine if a Tunnel End Point is required for a specific IPv6 Address Prefix. If that is the case the Server will put the address for the Tunnel End Point in the IPv4 Global Address Extension. If the Tunnel End Point address is an IPv4 address the Server will put that address in the extension as an IPv4-Compatible address. Bound Expires September 1998 [Page 12]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 7.3 AIIH Client Processing of an IPv4 Global Address Extension When a DHCPv6 Client receives an IPv4 Global Address Extension it MUST assume that the next extension in a DHCPv6 Reconfigure or Reply Message; the Server is either assigning an IPv4 Global Address or supplying an IPv4 Global Address. The address present in either of these messages will be in the form of an IPv4-Compatible Address. When the Client supplies an IPv4 Global Address as a Request or Release it MUST represent that address as an IPv4-Compatible Address. 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. Once the Client is assured it can use the IPv4 Global Address it can perform the following operations: 1. In an implementation defined manner the Client MUST assign the address to an interface, supporting the Client's IPv4 stack implementation. 2. In an implementation defined manner the Client MUST create an entry as an IPv4-Compatible Address supporting the processing required for an IPv6 address regarding the valid and preferred lifetimes as specified in IPv6 Addrconf [19]. Once the IPv4-Compatible address valid lifetime expires the IPv4 address MUST be deleted from the respective interface and a DHCPv6 Release Message MUST be sent to the AIIH DHCPv6 Server to delete the IPv4 Global Address from the Servers bindings. 3. If a Tunnel End Point address is provided in the IPv4 Global Address Extension, the Client MUST create a configured tunnel to the Tunnel End Point address, in an implementation defined manner. If the Tunnel End Point address is an IPv4-Compatible address then the encapsulation is IPv4 within IPv4, if the Tunnel End Point is an IPv6 address then the encapsulation is IPv6 in IPv4. These encapsulation mechanisms are defined in other IPv6 specifications [13, 15]. 8. Security Considerations The AIIH mechanism can use all the defined security specifications for each functional part of the operation. For DNS the DNS Security Extensions/Update can be used [10, 11], for DHCPv6 the DHCPv6 Authentication Message can be used [5], and for communications between the IPv6 node, once it has an IPv4 address, and the remote IPv4 node, IPSEC [8] can be used as AIIH does not break secure end- to-end communications at any point in the mechanism. Bound Expires September 1998 [Page 13]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 9. Year 2000 Considerations There are no Year 2000 issues in this specification. Appendix A - Open Issues December 1997 draft-ietf-ngtrans-nnat-00.txt - The draft does not speak of PTR records for the IPv6 node A record once its created. But its only useful during the lifetime of the assigned IPv4 address. STILL OPEN 3/98 Draft. - RFC 1183 RT Record is Experimental and there is some concern its obsolete. Though some implementations still support some code for the RT record. Also the Route Through semantics specified may need to strongly state the query is passed thru to the NNAT server. This needs to be discussed. RESOLVED 3/98 Draft RT record deprecated. - The Primary Server must look for the IPv6 node A record first before finding the RT record. This needs to be verified as an implementation issue. RESOLVED 3/98 Draft - Use CNAME Records. - When the NNAT Server responds to the query it may not be authoritative. This needs to be verified and checked. RESOLVED 3/98 Draft - Use CNAME Records and AIIH Server will be authoritative for the AIIH ZONE. - Use of TTL for DNS Caches can cause problems for existing IPv4 applications that cache IPv4 addresses. PARTIALLY RESOLVED - 3/98 Draft do not update DNS unless application will be permanent as opposed to transient. But TTL's that are updated still need some thought for legacy applications. This also points to possibly adding new fields to the hostent structure which will at least help new IPv6 applications and legacy IPv4 applications to change to act in a well behaved manner. - Specification needs a design example to get packets from the IPv6 node to an egress IPv4 router. PARTIALLY RESOLVED - 3/98 Draft added Design Section discussing tunneling mechanisms to be used and added Tunnel End Point address supplied by the AIIH DHCPv6 Server. Still needs more discussion. - NNAT name does not state what the specification does. RESOLVED - 3/98 Draft changed name to AIIH. Bound Expires September 1998 [Page 14]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 Appendix B - Draft Changes and Rationale History March 1998 draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt - Changed the name of the draft from NNAT to AIIH. This also was done to prevent any perceived antagonism towards the NAT IETF work, which is not an objective of this work. - Changed the Introduction to be more descriptive of the task at hand. - Added IPv4 Global Address definition to terminology section. - Added tunnel routability discussion to Design Model and a diagram abstraction to be used by the specification as a point of reference. - Added to the architecture the ability for an IPv6 node to request an IPv4 Global Address from an AIIH DHCPv6 Server. This will permit AIIH to not only be useful for incoming IPv4 Host communications with IPv6 Hosts but also for outgoing IPv4 communications to the Internet from IPv6 Hosts and for Intranet enterprise communications between an IPv6 Host and IPv4 Host. - Hinted that AIIH could be used in future work to define the capability for two IPv6 Hosts separated by an IPv4 cloud to to communicate thru tunnels, like thru a production 6bone network on the Internet. - Added new section to define how an IPv6 Host can request an IPv4 Global Address. - Defined new mechanism for DNS query processing when an IPv6 Host is looked for from an IPv4 Host, thru the use of CNAME and NS records. This also permits IPv4 Host Intranet queries too now. - New text clarifying that within the Intranet processing AIIH must only be used with IPv4 Global Addresses and Private IPv4 addresses should be retrieved from DHCPv4, via the IPv6 Hosts IPv4 stack. - Added new text defining the AIIH Server and the interaction with DHCPv6 and DNS applications. Also further refined the requirements of the AIIH Server model. - Expanded the section on the new DHCPv6 Section defining the required Server and Client behavior. Added support to permit AIIH to be used for Intranet and Internet communications from within the site. - Changed the DHCPv6 Extension for IPv4 Global Addresses to make it an extension which defines the next extension to be a request for AIIH processing relative to DHCPv6. - Added a Tunnel End Point address to the new extension so IPv6 Hosts can configure tunnels to communicate with the Bound Expires September 1998 [Page 15]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 egress router to transmit or reply with IPv4 on the Internet or within the Intranet. - Defined the AIIH side affect requirements for IPv6 Hosts using this mechanism with DHCPv6. - Updated and added to the Acknowledgment and References Section. - Updated the Open Issues from December 1997 draft and noted the status of each issue as STILL OPEN, RESOLVED, or PARTIALLY RESOLVED. - Updated the Changes from this draft. Acknowledgments The author would like to thank Erik Nordmark for spending time reviewing with him this idea and suggesting the use of the DHCPv6 Reconfigure Message, Richard Johnson for suggesting the use of the DNS CNAME Record, and Robert Watson who suggested that the AIIH DHCPv6 and DNS Server be co-located. George Tsirtsis who suggested using AIIH to assign IPv4 Global Addresses to IPv6 Hosts in general. Richard Draves and Jack McCann who have provided many helpful technical suggestions, and the NGTRANS working group for taking the time to work on AIIH. References [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [2] Mockapetris, P., "Domain Names - Implementation and Specifica- tion", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Architecture", draft-ietf-ipngwg-ipv6-spec-v2-01.txt, December 1997 (work in progress). [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-13.txt March 1998 (work in progress). [5] C. Perkins. Extensions for the Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-09.txt March 1998. (work in progress). [6] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates to the Domain Name System (DNS). RFC 2136, April 1997. [7] William R. Cheswick and Steven Bellovin. Firewalls and Internet Security. Addison-Wesley, Reading, MA 1994 (ISBN: 0-201-63357-4). Bound Expires September 1998 [Page 16]
INTERNET-DRAFT draft-ietf-ngtrans-assgn-ipv4-addrs-00.txt March 1998 [8] IPSEC *TBD* - This needs to include the Arch, Auth, and ESP specs. [9] S. Bradner. Key words for use in RFCs to indicate Requirement Levels. RFC 2119, March 1997. [10] D. Eastlake and C. Kaufman. Domain Name System Security Extensions. RFC 2065, January 1997. [11] D. Eastlake. Secure Domain Name System Dynamic Update. RFC 2137, April 1997. [12] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition RFC 2185, September 1997. [13] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. draft-ietf-ipngwg-ipv6-tunnel-08.txt. January 1998. (work in progress). [14] E. Nordmark. IPv4/IPv6 Stateless Header Translator draft-ietf-ngtrans-header-trans-00.txt. July 1997. (work in progress). [15] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers. draft-ietf-ngtrans-trans-mech-00.txt, November 1997 (work in progress). [16] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1997. [17] Rekhter, Moskowitz, Karrenburg, Groot. Address Allocation for Private Networks. RFC 1918. February 1996. [18] Huitema, Thomson. DNS Extensions to support IP version 6. draft-ietf-ipngwg-aaaa-03.txt, February 1998 (work in progress). [19] Thomson, Narten. IPv6 Stateless Address Configuration. draft-ietf-ipngwg-addrconf-v2-02.txt, February 1998, (work in progress). [20] Hinden, Deering. IP Version 6 Addressing Architecture. draft-ietf-ipngwg-addr-arch-v2-06.txt, January 1998. (work in progress). Authors' Address Jim Bound Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: (603) 884-0400 Email: bound@zk3.dec.com Bound Expires September 1998 [Page 17]
