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]