Internet DRAFT - draft-harrington-ngtrans-dhcp-option

draft-harrington-ngtrans-dhcp-option



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:18:32 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 09 Aug 1997 03:22:14 GMT
ETag: "2e6f74-247a-33ebe266"
Accept-Ranges: bytes
Content-Length: 9338
Connection: close
Content-Type: text/plain

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 and routers 
   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                                             4
       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 a DHCPv4 (hereafter, 
   referred to simply as DHCP) option which identifies the IPv4 address 
   of a tunnel endpoint on an IPv6 router.

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 [ADDRCONF].  If the IPv6 router 
   was functioning as a DHCPv6 relay [DHCPv6], 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 has been requested from IANA)

   	Len: Minimum value 4, Maximum 252, must be multiple of 4

   	Address: A series of IPv4 addresses, in network byte order.

   Note that this option could also take advantage of the DHCP option 
   which permits the use of fully qualified domain names [FQDN], in 
   which case only a single FQDN would appear in each instance of this 
   option.

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.






Expires January 1998                                            [Page 3]

Internet Draft         IPv6 Transition DHCP Option             July 1997

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.

7. References

   [DHCP]	R. Droms, "Dynamic Host Configuration Protocol",
   		RFC 2131, March 1997.

   [DHCP-FQDN]	Y. Rekhter, R. Droms, "An option for FQDNs in DHCP options"
   		draft-ietf-dhc-fqdn-opt-02.txt, Work in Progress.

   [6over4]	B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains
   		Without Explicit Tunnels", draft-carpenter-ipng-6over4-02.txt,
   		Work in Progress.

   [ADDRCONF]	S. Thompson and T. Narten, "IPv6 Stateless Address
   		Autoconfiguration", RFC1971.

   [DHCPv6]	J. Bound, C. Perkins, "Dynamic Host Configuration Protocol
   		for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-10.txt, Work in
   		Progress.

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]