[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
dhc Working Group R. Droms
Internet-Draft Cisco
Intended status: Standards Track T. Narten
Expires: September 3, 2009 IBM
March 2, 2009
Default Router and Prefix Advertisement Options for DHCPv6
draft-droms-dhc-dhcpv6-default-router-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
In some IPv6 deployments, there is a requirement to communicate a
list of default routers and advertised prefixes to a host through
Droms & Narten Expires September 3, 2009 [Page 1]
Internet-Draft DHCP Default Router and Prefix Options March 2009
DHCP. This document defines DHCP options to carry that information.
1. Introduction
In many IPv6 deployments, particularly in edge networks, end devices
obtain configuration information about default routers, on-link
prefixes and addresses from Router Advertisements as defined in
Neighbor Discovery. In some deployments, however, there is a strong
desire not to use Router Advertisements at all and to perform all
configuration via DHCP [RFC3315]. For example, network
administration may want to control all host configuration through a
single centralized DHCP service in order to more closely manage which
addresses are assigned and in use. In such an environment, network
administration may prefer to manage all host configuration aspects
through a single on-the-wire protocol rather than a combination of
the Neighbor Discovery (ND) protocol [RFC4861] and DHCP. In
addition, most existing IPv4 deployments are already use DHCP
exclusively for configuration. In deploying IPv6, an operator may
wish to continue a DHCP-only configuration approach in order to
minimize the number of gratuitous operational changes needed to
deploy IPv6.
When DHCP was originally defined, it was felt that configuration
information concerning default routers and prefixes was best learned
exclusively via Router Advertisements and (unlike DHCPv4) no DHCPv6
options were defined to carry such information. This document
recognizes that there are deployment scenarios where an operator may
want to disable the use of Router Advertisements completely and rely
exclusively on DHCP for all configuration.
This document defines two DHCP options, the Default Router option and
the Prefix Information option, which carry information a host needs
to use IPv6 on a link where no information is provided by ND.
These options are not targeted towards networks characterized by a
wide variety of end devices running diverse software chosen by end
users (e.g., laptops, PDAs, etc.). Rather, the options are targeted
towards networks that are typically under a single administrative
control where the operator has significant control over the number
and kinds of devices that connect to the network. As an example,
broadband deployments may include an access network on which all
devices run software controlled by the operator.
2. Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
Droms & Narten Expires September 3, 2009 [Page 2]
Internet-Draft DHCP Default Router and Prefix Options March 2009
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC 2119 [RFC2119].
The following terms are used throughout this document:
o DHCP - Dynamic Host Configuration Protocol for IPv6 [RFC3315]
o ND - Neighbor Discovery protocol [RFC4861]
Additional terms used in the description of ND and DHCP in this
documents are defined in RFC 4861 and RFC 3315.
3. Requirements and Design Considerations
In planning and deploying IPv6, some network operators have expressed
the following requirements for operating an IPv6 network:
o IPv4 works with a just a single configuration protocol, DHCPv4; it
should be possible to deploy IPv6 using just one configuration
protocol.
o For consistency and ease of management, DHCPv6 should carry the
same information and enable the same mode of operation as DHCPv4.
o Use of Router Advertisements provides identical configuration of
default routers and prefixes for all hosts on a link, while some
deployments require that different classes or groups of hosts be
configured with different default routers and prefixes.
o Misconfigured Router Advertisements immediately cause connectivity
disruptions and can come from any router as a side effect of other
changes in configuration or even simple attachment to a link.
DHCP service is typically provided by a centralized service
composed of fewer managed components, so DHCP server
misconfiguration is less likely than delivery of misconfigured
Router Advertisements.
In addition to the information currently carried by DHCP, a host
requires, at a minimum, a default router and an on-link prefix to
enable IPv6 operation.
The DHCP options to carry default router and prefix information
should, wherever possible, reuse the conceptual variables, router
selection and other mechanisms from ND. The intention is to allow
IPv6 implementations to share data structures and code between ND and
DHCP, treating information received through either source in a
uniform way.
Droms & Narten Expires September 3, 2009 [Page 3]
Internet-Draft DHCP Default Router and Prefix Options March 2009
The host's use of the information in the DHCP options should follow
the model of other DHCP information. There will only be one DHCP
server providing default router and prefix information for an
interface, and the server will provide all of the relevant
information with each update.
4. Design Overview and Client Behaviors
In general, the use of these DHCP options follows the design and use
of Router Advertisements, as defined in RFC 4861, as closely as
possible. Unless otherwise specified, the host uses the information
from the DHCP Default Router and Prefix Information options in the
same way as defined for information derived from Router
Advertisements as defined in RFC 4861. Some explicit references to
text in RFC 4861 are included here for clarity.
4.1. Conceptual Data Structures and Sending Algorithm,
A host that receives the DHCP Default Router and Prefix Information
options inserts the information from the option in the Prefix List
and Default Router list, which are defined in section 5.1 of RFC
4861.
A host continues to use the Conceptual Sending Algorithm defined in
section 5.2 of RFC 4861 when the Prefix List and the Default Router
list are populated with prefixes and default router information
derived from DHCP options.
4.2. Host Specification
A host that receives the DHCP Default Router and Prefix Information
options follows the Host Specification defined in section 6.3 of RFC
4861, with some specific exceptions as defined below.
The host maintains the Host Variables as defined in section 6.3.2. A
host processes information received through the DHCP Default Router
and Prefix Information options somewhat differently than information
received through ND, as specified in section 6.3.4 of RFC 4861. The
differences are described in the following paragraphs.
The host takes the Router Address and Router Lifetime from a received
DHCP Default Router option and processes it as specified in section
6.3.4 of RFC 4861. The option is required to contain a valid address
from the router interface on the link to which the host is connected.
Any prefixes received in DHCP Prefix Information options are defined
to be on-link and to be processed as specified in section 6.3.4 of
Droms & Narten Expires September 3, 2009 [Page 4]
Internet-Draft DHCP Default Router and Prefix Options March 2009
RFC 4861.
5. Option Formats
This section defines the information that will be carried in the DHCP
Default Router and Prefix Information options. The exact format of
the options is TBD.
5.1. DHCP Default Router option
The DHCP Default Router option carries the following information:
o Address of the interface for a default router
o Source link-layer address for the interface (opt)
o Router lifetime
Multiple DHCP Default Router options can appear in a DHCP message. A
DHCP client indicates that it requires Default Router information by
including the DHCP Default Router option code in an Option Request
option send to the server.
5.2. DHCP Prefix Information option
The DHCP Prefix Information option carries the following information:
o Prefix
o Prefix length
o Valid lifetime
o Preferred lifetime
Multiple DHCP Prefix Information options can appear in a DHCP
message. A DHCP client indicates that it requires Prefix Information
by including the DHCP Prefix Information option code in an Option
Request option send to the server.
6. Discussion and Open Issues
MTU, Cur Hop Limit, Reachable Time and Retrans Timer can be defined
in a separate DHCP option(s) if there is demand.
Timing for renewal of information received through these options is
Droms & Narten Expires September 3, 2009 [Page 5]
Internet-Draft DHCP Default Router and Prefix Options March 2009
TBD. There are two alternatives:
o Host is responsible for contacting server before any timers such
as preferred lifetime or router lifetime expire.
o Server provides timer values, similar to T1 and T2, in the options
Default router and prefix information are considered independent and
one may be received through Router Advertisements while the other is
received through DHCP.
Conflicting or overlapping information received through Router
Advertisements and through DHCP is considered a misconfiguration and
is out-of-scope of this document. For example, if a host receives a
list of default routers through DHCP and a Router Advertisement with
a non-zero lifetime, the result is undefined.
Note that the IPv6 stateless address autoconfiguration specification
[RFC4862] allows a host to initiate a DHCP message exchange if the
host receives no Router Advertisements. Therefore, the information
carried in the Default Router and Prefix Information options allows
for hosts to use IPv6 on a link where no Router Advertisements are
transmitted.
Any prefixes received through Prefix Information options are assumed
to be on-link.
7. Security Considerations
An adversarial DHCP server could use these options to divert IP
traffic to mount a man-in-the-middle attack. Mitigation of attacks
through DHCP is discussed in RFC 3315.
8. IANA Considerations
IANA is requested to assign option codes to the Default Router and
Prefix Information options from the DHCPv6 Option Code registry.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Droms & Narten Expires September 3, 2009 [Page 6]
Internet-Draft DHCP Default Router and Prefix Options March 2009
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
9.2. Informative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Authors' Addresses
Ralph Droms
Cisco
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Phone: +1 978.936.1674
Email: rdroms@cisco.com
Thomas Narten
IBM
Email: narten@us.ibm.com
Droms & Narten Expires September 3, 2009 [Page 7]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/