idnits 2.17.1 draft-droms-dhc-dhcpv6-default-router-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 2, 2009) is 5534 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Working Group R. Droms 3 Internet-Draft Cisco 4 Intended status: Standards Track T. Narten 5 Expires: September 3, 2009 IBM 6 March 2, 2009 8 Default Router and Prefix Advertisement Options for DHCPv6 9 draft-droms-dhc-dhcpv6-default-router-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 3, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 In some IPv6 deployments, there is a requirement to communicate a 48 list of default routers and advertised prefixes to a host through 49 DHCP. This document defines DHCP options to carry that information. 51 1. Introduction 53 In many IPv6 deployments, particularly in edge networks, end devices 54 obtain configuration information about default routers, on-link 55 prefixes and addresses from Router Advertisements as defined in 56 Neighbor Discovery. In some deployments, however, there is a strong 57 desire not to use Router Advertisements at all and to perform all 58 configuration via DHCP [RFC3315]. For example, network 59 administration may want to control all host configuration through a 60 single centralized DHCP service in order to more closely manage which 61 addresses are assigned and in use. In such an environment, network 62 administration may prefer to manage all host configuration aspects 63 through a single on-the-wire protocol rather than a combination of 64 the Neighbor Discovery (ND) protocol [RFC4861] and DHCP. In 65 addition, most existing IPv4 deployments are already use DHCP 66 exclusively for configuration. In deploying IPv6, an operator may 67 wish to continue a DHCP-only configuration approach in order to 68 minimize the number of gratuitous operational changes needed to 69 deploy IPv6. 71 When DHCP was originally defined, it was felt that configuration 72 information concerning default routers and prefixes was best learned 73 exclusively via Router Advertisements and (unlike DHCPv4) no DHCPv6 74 options were defined to carry such information. This document 75 recognizes that there are deployment scenarios where an operator may 76 want to disable the use of Router Advertisements completely and rely 77 exclusively on DHCP for all configuration. 79 This document defines two DHCP options, the Default Router option and 80 the Prefix Information option, which carry information a host needs 81 to use IPv6 on a link where no information is provided by ND. 83 These options are not targeted towards networks characterized by a 84 wide variety of end devices running diverse software chosen by end 85 users (e.g., laptops, PDAs, etc.). Rather, the options are targeted 86 towards networks that are typically under a single administrative 87 control where the operator has significant control over the number 88 and kinds of devices that connect to the network. As an example, 89 broadband deployments may include an access network on which all 90 devices run software controlled by the operator. 92 2. Terminology 94 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 95 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 96 interpreted as described in RFC 2119 [RFC2119]. 98 The following terms are used throughout this document: 100 o DHCP - Dynamic Host Configuration Protocol for IPv6 [RFC3315] 102 o ND - Neighbor Discovery protocol [RFC4861] 104 Additional terms used in the description of ND and DHCP in this 105 documents are defined in RFC 4861 and RFC 3315. 107 3. Requirements and Design Considerations 109 In planning and deploying IPv6, some network operators have expressed 110 the following requirements for operating an IPv6 network: 112 o IPv4 works with a just a single configuration protocol, DHCPv4; it 113 should be possible to deploy IPv6 using just one configuration 114 protocol. 116 o For consistency and ease of management, DHCPv6 should carry the 117 same information and enable the same mode of operation as DHCPv4. 119 o Use of Router Advertisements provides identical configuration of 120 default routers and prefixes for all hosts on a link, while some 121 deployments require that different classes or groups of hosts be 122 configured with different default routers and prefixes. 124 o Misconfigured Router Advertisements immediately cause connectivity 125 disruptions and can come from any router as a side effect of other 126 changes in configuration or even simple attachment to a link. 127 DHCP service is typically provided by a centralized service 128 composed of fewer managed components, so DHCP server 129 misconfiguration is less likely than delivery of misconfigured 130 Router Advertisements. 132 In addition to the information currently carried by DHCP, a host 133 requires, at a minimum, a default router and an on-link prefix to 134 enable IPv6 operation. 136 The DHCP options to carry default router and prefix information 137 should, wherever possible, reuse the conceptual variables, router 138 selection and other mechanisms from ND. The intention is to allow 139 IPv6 implementations to share data structures and code between ND and 140 DHCP, treating information received through either source in a 141 uniform way. 143 The host's use of the information in the DHCP options should follow 144 the model of other DHCP information. There will only be one DHCP 145 server providing default router and prefix information for an 146 interface, and the server will provide all of the relevant 147 information with each update. 149 4. Design Overview and Client Behaviors 151 In general, the use of these DHCP options follows the design and use 152 of Router Advertisements, as defined in RFC 4861, as closely as 153 possible. Unless otherwise specified, the host uses the information 154 from the DHCP Default Router and Prefix Information options in the 155 same way as defined for information derived from Router 156 Advertisements as defined in RFC 4861. Some explicit references to 157 text in RFC 4861 are included here for clarity. 159 4.1. Conceptual Data Structures and Sending Algorithm, 161 A host that receives the DHCP Default Router and Prefix Information 162 options inserts the information from the option in the Prefix List 163 and Default Router list, which are defined in section 5.1 of RFC 164 4861. 166 A host continues to use the Conceptual Sending Algorithm defined in 167 section 5.2 of RFC 4861 when the Prefix List and the Default Router 168 list are populated with prefixes and default router information 169 derived from DHCP options. 171 4.2. Host Specification 173 A host that receives the DHCP Default Router and Prefix Information 174 options follows the Host Specification defined in section 6.3 of RFC 175 4861, with some specific exceptions as defined below. 177 The host maintains the Host Variables as defined in section 6.3.2. A 178 host processes information received through the DHCP Default Router 179 and Prefix Information options somewhat differently than information 180 received through ND, as specified in section 6.3.4 of RFC 4861. The 181 differences are described in the following paragraphs. 183 The host takes the Router Address and Router Lifetime from a received 184 DHCP Default Router option and processes it as specified in section 185 6.3.4 of RFC 4861. The option is required to contain a valid address 186 from the router interface on the link to which the host is connected. 188 Any prefixes received in DHCP Prefix Information options are defined 189 to be on-link and to be processed as specified in section 6.3.4 of 190 RFC 4861. 192 5. Option Formats 194 This section defines the information that will be carried in the DHCP 195 Default Router and Prefix Information options. The exact format of 196 the options is TBD. 198 5.1. DHCP Default Router option 200 The DHCP Default Router option carries the following information: 202 o Address of the interface for a default router 204 o Source link-layer address for the interface (opt) 206 o Router lifetime 208 Multiple DHCP Default Router options can appear in a DHCP message. A 209 DHCP client indicates that it requires Default Router information by 210 including the DHCP Default Router option code in an Option Request 211 option send to the server. 213 5.2. DHCP Prefix Information option 215 The DHCP Prefix Information option carries the following information: 217 o Prefix 219 o Prefix length 221 o Valid lifetime 223 o Preferred lifetime 225 Multiple DHCP Prefix Information options can appear in a DHCP 226 message. A DHCP client indicates that it requires Prefix Information 227 by including the DHCP Prefix Information option code in an Option 228 Request option send to the server. 230 6. Discussion and Open Issues 232 MTU, Cur Hop Limit, Reachable Time and Retrans Timer can be defined 233 in a separate DHCP option(s) if there is demand. 235 Timing for renewal of information received through these options is 236 TBD. There are two alternatives: 238 o Host is responsible for contacting server before any timers such 239 as preferred lifetime or router lifetime expire. 241 o Server provides timer values, similar to T1 and T2, in the options 243 Default router and prefix information are considered independent and 244 one may be received through Router Advertisements while the other is 245 received through DHCP. 247 Conflicting or overlapping information received through Router 248 Advertisements and through DHCP is considered a misconfiguration and 249 is out-of-scope of this document. For example, if a host receives a 250 list of default routers through DHCP and a Router Advertisement with 251 a non-zero lifetime, the result is undefined. 253 Note that the IPv6 stateless address autoconfiguration specification 254 [RFC4862] allows a host to initiate a DHCP message exchange if the 255 host receives no Router Advertisements. Therefore, the information 256 carried in the Default Router and Prefix Information options allows 257 for hosts to use IPv6 on a link where no Router Advertisements are 258 transmitted. 260 Any prefixes received through Prefix Information options are assumed 261 to be on-link. 263 7. Security Considerations 265 An adversarial DHCP server could use these options to divert IP 266 traffic to mount a man-in-the-middle attack. Mitigation of attacks 267 through DHCP is discussed in RFC 3315. 269 8. IANA Considerations 271 IANA is requested to assign option codes to the Default Router and 272 Prefix Information options from the DHCPv6 Option Code registry. 274 9. References 276 9.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 282 and M. Carney, "Dynamic Host Configuration Protocol for 283 IPv6 (DHCPv6)", RFC 3315, July 2003. 285 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 286 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 287 September 2007. 289 9.2. Informative References 291 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 292 Address Autoconfiguration", RFC 4862, September 2007. 294 Authors' Addresses 296 Ralph Droms 297 Cisco 298 1414 Massachusetts Avenue 299 Boxborough, MA 01719 300 USA 302 Phone: +1 978.936.1674 303 Email: rdroms@cisco.com 305 Thomas Narten 306 IBM 308 Email: narten@us.ibm.com