Subject: Request for DHCP option code
From: "Harrington, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
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 [email-masked] 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 
    [email-masked] 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: [email-masked]

 

 

 

 

 

 

 

 

 

 

 
Expires January 1998                                            [Page 4]