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]
