INTERNET-DRAFT Jim Bound NGTRANS Tools Working Group Digital Equipment Corp November 1997 No Network Address Translation (NNAT) for IPv6 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 No Network Address Translation (NNAT), which will assign an IPv6 node a temporary IPv4 address, which can be used to communicate with a node that supports only IPv4. Bound Expires May 1998 [Page 1] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 Table of Contents: 1. Introduction....................................................3 2. Terminology.....................................................3 2.1 IPv6 NNAT Terminology.......................................3 2.2 Specification Language......................................4 3. NNAT Design Model...............................................5 4. IPv4 Query of an IPv6 Node......................................5 4.1 Reaching the Site Primary DNS Server........................5 4.2 Relaying the A Record Query to the NNAT Server..............5 5. NNAT Server Processing of a DNS A Query.........................6 5.1 DNS and DHCPv6 Processing...................................6 5.2 Cleaning up the NNAT IPv4 Assigned Address..................7 5.3 Conceptual Model of an Implementation.......................7 6. DHCPv6 Reconfigure IPv4 Address Extension.......................7 7. Security Considerations.........................................8 8. Year 2000 Considerations........................................8 Appendix A - Open Issues...........................................8 Appendix B - Draft Changes and Rationale History...................8 Acknowledgements...................................................8 References.........................................................9 Authors' Address..................................................10 Bound Expires May 1998 [Page 2] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 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 No Network Address Translation (NNAT), which will assign an IPv6 node a temporary IPv4 address, which can be used to communicate with a node that supports only IPv4. NNAT uses the DNS [2,9] mechanisms to resolve a query for an IPv6 node name by an IPv4 node that wishes to communicate with the IPv4 stack of an IPv6 node that supports both IPv6 and IPv4. The IPv6 node that is the object of such a query will be assigned a temporary IPv4 address, thru DHCPv6 [4], and the IPv4 node performing the query will receive the address assigned to the IPv6 node in the query response. Communications between the two nodes can then begin directly without any intermediate nodes performing Network Address Translation [15] or Application Level Gateway [7] functions. 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, IPv4 addresses will be needed to permit IPv6 nodes to communicate with IPv6 nodes, which can support both IPv4 and IPv6 communications. The specification will begin by defining the terminology (section 2), then discuss the NNAT design model (section 3), then define the mechanism used for an IPv4 node to query an IPv6 node (section 4), then discuss the NNAT Server processing to support this mechanism (section 5), and complete the mechanism by defining the DHCPv6 Extension needed to assign a temporary IPv4 address to an IPv6 node (section 6). The specification then discusses Security (section 7) and Year 2000 considerations (section 8). Appendix A will discuss Open Issues that need to be discussed in the ngtrans Tools Working Group and Appendix B will keep a historical account of changes to the draft and rationale for those changes as they occur. 2. Terminology 2.1 IPv6 NNAT Terminology IPv6 Protocol Terms: See [3] IPv6 Transition Terms: See [16] DHCPv6 Terms: See [4,5] NNAT Server: A Server that supports DNS [2] and DHCPv6 [4,5] and communications between DNS and DHCPv6, which is implementation defined. See section 4 and 5. Bound Expires May 1998 [Page 3] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 2.2 Specification Language In this document, several words are used to signify the requirements of the specification, in accordance with RFC 2119 [10]. 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 May 1998 [Page 4] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 3. NNAT Design Model The design model assumes that NNAT MUST only be used to obtain a temporary IPv4 address for an IPv6 node from the receipt of a DNS query for a DNS A Type Relative Record [1,2]. If an IPv6 node needs to obtain an IPv4 address to initiate communications, it SHOULD locate that address using DHCPv4 [17], using its IPv4 stack. For an IPv6 node to participate in the NNAT 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 NNAT cannot be a solution. It is beyond the scope of this specification to define the mechanisms used to describe the variant routing configurations to verify that IPv4 connectivity exists between the IPv6 node and the ingress or egress points of the IPv6 nodes site, to communicate with the IPv4 node establishing communications. It is assumed that IPv4-in-IPv6 and IPv6-in-IPv4 configured and automatic tunnels can be used as defined in other transition mechanism documents [13, 14, 16]. 4. IPv4 Query of an IPv6 Node NNAT supports IPv4 DNS querys from the Internet or within a site to establish communications with an IPv6 node. An IPv4 node will not necessarily know that it is trying to establish communications with an IPv6 node. The IPv4 node will communicate with the IPv6 node by first obtaining an IPv4 address for the IPv6 node as it does for any other node (e.g. gethostbyname API). 4.1 Reaching the Site Primary DNS Server The IPv4 DNS query will reach the Primary DNS Name Server for the IPv6 node. 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 specification. 4.2 Relaying the A Record Query to the NNAT Server When the Primary DNS Server for the IPv6 node processes the IPv4 nodes query, it will do a lookup for that IPv6 node and find a Route Through (RT) DNS Type Record [9]. The RT record will inform the Primary DNS Server to forward the query to an intermediate DNS Server, which will respond to the IPv4 node that made the original query, after a temporary IPv4 address has been assigned to the IPv6 node. The intermediate DNS Server is also the NNAT Server. Bound Expires May 1998 [Page 5] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 For Example: IPv4 node "v4node.abc.com" querys for "v6node.xyz.com" Query reaches Primary DNS Server for "v6node.xyz.com". Primary DNS Server finds: v6node.xyz.com IN RT 5 nnat6.xyz.com Primary DNS Server forwards the query to "nnat6.xyz.com" 5. NNAT Server Processing of a DNS A Query 5.1 DNS and DHCPv6 Processing At this point the NNAT Server has received the DNS query from the Primary DNS Server. An NNAT Server MUST support both a DNS Server and DHCPv6 Server implementation to perform the necessary NNAT operations. The NNAT DNS Server will communicate to the DHCPv6 Server that an IPv6 node is being queried for an IPv4 address. The DHCPv6 Server will look within its pool of IPv4 addresses for NNAT IPv4 temporary addresses for assignment. 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 address. The DHCPv6 extension to this is defined in section 6. Then the DHCPv6 Server MUST 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 NNAT Server. The Time-To-Live (TTL) field in the update MUST not be set to be greater than the lifetime (section 6) for the IPv4 address assigned to the IPv6 node. The TTL value will permit the A record to be cached for at least as long as the lifetime. Then the DHCPv6 Server MUST communicate to the NNAT DNS Server the IPv4 address assigned to the IPv6 node. Then the NNAT DNS Server responds to the query of the IPv4 node with the IPv4 address of the IPv6 node. When the query is received by the NNAT DNS Server and an IPv4 address cannot be assigned, the NNAT DNS Server MUST respond to the IPv4 node that the IPv6 node A Record could not be found. For Example: NNAT DNS Server informs DHCPv6 it needs an IPv4 address for v6node.xyz.com. DHCPv6 Server assigns 15.131.12.6 to v6node.xyz.com thru Bound Expires May 1998 [Page 6] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 the Reconfigure IPv4 Address Extension with a lifetime of 5 hours. DHCPv6 updates the Primary DNS Server: v6node.xyz.com 18000 IN A 15.131.12.6 ; Explicit TTL cache for 5 hours DHCPv6 Server informs NNAT DNS Server of the IPv4 Address. NNAT DNS Server responds to "v4node.abc.com" query. 5.2 Cleaning up the NNAT 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 Dyanamic Updates to DNS mechanism. 5.3 Conceptual Model of an Implementation A conceptual model (not part of this specification) for the NNAT 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 as specified in DHCPv6. 6. DHCPv6 Reconfigure IPv4 Address Extension The DHCPv6 Reconfigure IPv4 Address Extension provides an IPv6 DHCPv6 Client with a temporary IPv4 address. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | | (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | | (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 8 IPv4 Address: 32bit IPv4 Address Lifetime: Absolute Time in Seconds Bound Expires May 1998 [Page 7] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 7. Security Considerations The NNAT 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 [11, 12], 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 NNAT does not break secure end- to-end communications at any point in the mechanism. 8. Year 2000 Considerations There are no Year 2000 issues in this specification. Appendix A - Open Issues - 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. - 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. - 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. - WHen the NNAT Server responds to the query it may not be authorative. This needs to be verified and checked. Appendix B - Draft Changes and Rationale History None at this time. Acknowledgements The author would like to thank Erik Nordmark for spending time working with him on this idea and suggesting the use of the DHCPv6 Reconfigure Message, Gerd Hoelzing for suggesting the use of the DNS RT Record, and Robert Watson who suggested that the NNAT DHCPv6 and DNS Server be co-located. Bound Expires May 1998 [Page 8] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 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", RFC 1883, December 1995. [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-11.txt November 1997 (work in progress). [5] C. Perkins. Extensions for the Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-08.txt November 1997. (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). [8] IPSEC *TBD* - This needs to include the Arch, Auth, and ESP specs. [9] C. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris. New DNS RR Definitions, RFC 1183, October 1990. [10] S. Bradner. Key words for use in RFCs to indicate Requirment Levels. RFC 2119, March 1997. [11] D. Eastlake and C. Kaufman. Domain Name System Security Extensions. RFC 2065, January 1997. [12] D. Eastlake. Secure Domain Name System Dynamic Update. RFC 2137, April 1997. [13] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition RFC 2185, September 1997. [14] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. draft-ietf-ipngwg-ipv6-tunnel-07.txt. December 1996. (work in progress) [15] E. Nordmark. IPv4/IPv6 Stateless Header Translator draft-ietf-ngtrans-header-trans-00.txt. July 1997. (work in progress) [16] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers. RFC 1933, April 1996. [17] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1997. Bound Expires May 1998 [Page 9] INTERNET-DRAFT draft-ietf-ngtrans-nnat-00.txt November 1997 Authors' Address Jim Bound Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: (603) 881-0400 Email: bound@zk3.dec.com Bound Expires May 1998 [Page 10]