From: "Harrington, Dan" To: "'iana@iana.org'" Subject: Request for DHCP option code Date: Fri, 25 Jul 1997 17:06:36 -0400 NGTrans Working Group Dan Harrington Internet Draft Lucent Technologies July 1997 DHCP Option for IPv6 Transitions draft-harrington-ngtrans-dhcp-option-00.txt Abstract This draft introduces a proposed DHCP option which could be helpful in establishing connectivity between isolated IPv6 hosts in an IPv4 network. This work is introduced to the NGTrans Working Group initially, and will also be reviewed in the DHCP Working Group. Status of This Memo This document is a submission to the NGTrans 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Table Of Contents 1. Introduction 2 2. Terminology and Definitions 2 3. Problem Statement 2 4. IPv6 Router 6over4 Address Option 3 5. Security Issues 3 6. Acknowledgements 3 7. References 4 8. Author's Address 4 Expires January 1998 [Page 1] Internet Draft IPv6 Transition DHCP Option July 1997 1. Introduction During an initial deployment of IPv6 hosts in a given network, there is likely to be a period in which the administrative focus and resources will be directed towards support of the prevalent IPv4 infrastructure. The mechanism described in this document is an attempt to leverage some of the IPv4 technology base in order to enable connectivity of IPv6-capable hosts with dual (or hybrid) stack support. Specifically, it defines DHCPv4 (hereafter, referred to simply as DHCP) options which identify the IPv4 address of a tunnel endpoint on an IPv6 router. Additional options are defined to refine the use of IPv4-compatible addressing on the host. 2. Terminology and Definitions link a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. neighbors nodes attached to the same link. Neighbor Discovery The protocol by which IPv6 systems resolve and advertise reachability information amongst neighbors, using ICMPv6 messages. interface a node's attachment to a link. link-local address An address formed during interface initialization, composed of the well known prefix FE80:: and a media specific token. This address is limited in scope to the link and may not be forwarded by a router. 3. Problem Statement The draft [6over4] describes the use of IPv4 as a link layer for IPv6, including support for running Neighbor Discovery using IPv4 multicast capabilities. Using IPv4 multicast permits the IPv6 host to discover a nearby IPv6 router (and other systems), even though they do not share a physical link, by treating the IPv4 multicast capable network as a logical link. So by utilizing one aspect of the widely deployed IPv4 infrastructure, IPv6 deployment can be eased. However, not all networks support IPv4 multicast technology, either due to a lack of support in the existing infrastructure, or for internal policy reasons. Without this feature, and in the absence of alternative mechanisms, it is impossible for an isolated IPv6 host in such an IPv4 network to achieve connectivity with other IPv6 systems without manual configuration. This is clearly undesirable, as IPv6 host deployment will not always be done in a managed and controlled manner. Expires January 1998 [Page 2] Internet Draft IPv6 Transition DHCP Option July 1997 This document suggests the use of a DHCP option which would provide such an isolated host, in a non-multicast capable IPv4 network, with the IPv4 address of an IPv6 router tunnel endpoint. With this piece of information, the IPv6 host would be able to initiate the Neighbor Discovery process, thereby making itself known to the IPv6 router. From the Router Solicitation and Router Advertisement exchange, the host would be able to gain sufficient information to complete the address autoconfiguration mechanism. If the IPv6 router was functioning as a DHCPv6 relay, the host would be able to participate in a stateful configuration transaction. Once the single piece of information, the IPv4 address of the IPv6 router's tunnel endpoint, is known to the host, it can become fully capable of true IPv6 connectivity. Without that piece of information, and in the absence of configured knowledge, it is alone. 4. IPv6 Router 6over4 Address Option The following option defines a set of IPv4 addresses of IPv6 router interfaces which support the IPv6 capabilities specified in [6over4]. The minimum length of this option is 4 octets, and the length MUST be a multiple of 4. A maximum of 63 addresses can be returned. Code Len Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | a1 | a2 | a3 | a4 | b1 | b2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- Figure 1 Code: TBD (value to be requested from IANA) Len: Minimum value 4, Maximum 252, must be multiple of 4 Address: A series of IPv4 addresses, in network byte order. 5. Security Issues This mechanism provides no greater risk or benefit than that which exists between DHCP clients and servers currently. If a Security Association is required between the IPv6 host and the IPv6 router(s) identified in this option, its establishment may require additional mechanisms which are not identified in this document. 6. Acknowledgements Thanks to Brian Carpenter and Cyndi Jung, whose draft sparked the discussion of how to support isolated IPv6 hosts in an IPv4 network. Thanks also to Jim Bound and Charlie Perkins for early discussions of this mechanism. Expires January 1998 [Page 3] Internet Draft IPv6 Transition DHCP Option July 1997 7. References [DHCP] RFC???? [DHCP-FQDN] Rekhter/Drums draft [6over4] Carpenter/Jung draft [ADDRCONF] S. Thompson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC1971. 8. Author's Address If you have any questions about this draft or would like to make any suggestions on how it might be improved, please use the ngtrans@sunroof.eng.sun.com mailing list, or contact the author directly at the address below. Dan Harrington Lucent Technologies 300 Baker Ave. Suite 100 Concord, MA 01742 Phone: (508) 287-2843 Email: dth@lucent.com Expires January 1998 [Page 4]