idnits 2.17.1 draft-ietf-dhc-dhcpv6-relay-supplied-options-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When such a conflict exists, the DHCP server MUST choose no more than one of these options to forward to the client. The DHCP server MUST not forward more than one of these options to the client. -- The document date (October 11, 2010) is 4939 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) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc T. Lemon 3 Internet-Draft Nominum 4 Intended status: Standards Track Q. Wu 5 Expires: April 14, 2011 Huawei 6 October 11, 2010 8 Relay-Supplied DHCP Options 9 draft-ietf-dhc-dhcpv6-relay-supplied-options-03 11 Abstract 13 This document describes a mechanism whereby a DHCPv6 relay agent can 14 provide options to a DHCPv6 server that the DHCPv6 server can then 15 provide to the DHCPv6 client in certain restricted cases where this 16 is necessary. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 14, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. RSOO-enabled options . . . . . . . . . . . . . . . . . . . . . 4 58 5. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 5 59 6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The DHCPv6 specification [RFC3315] allows DHCP relay agents to 70 forward DHCPv6 messages between clients and servers that are not on 71 the same IPv6 link. In some cases the DHCP relay agent has 72 information not available to the DHCP server that would be useful to 73 provide to a DHCP client. For example, the DHCP client may need to 74 learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for 75 use in EAP re-authentication [RFC5296], which is known to the relay 76 agent but not the server. 78 The DHCPv6 protocol specification does not provide a mechanism 79 whereby the relay agent can provide options to the client. This 80 document extends DHCP with a mechanism that allows DHCP relay agents 81 to propose options for the server to send to DHCP clients. 83 This document is not intended to provide a general mechanism for 84 storing client configuration information in the relay agent. Rather, 85 it is intended to address specific use cases where only the relay 86 agent has information needed by the client. This extension is not 87 applicable to DHCP options in general, but rather provided as a 88 mechanism for new specifications that require this functionality. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 1.2. Terminology 98 The following terms and acronyms are used in this document: 100 DHCP Dynamic Host Configuration Protocol Version 6 [RFC3315] 102 RSOO Relay-Supplied Options option 104 2. Protocol Summary 106 DHCP clients do not support a mechanism for receiving options from 107 relay agents--the function of the relay agent is simply to deliver 108 the payload from the server. Consequently, in order for the DHCP 109 relay agent to provide options to the client, it sends those options 110 to the DHCP server, encapsulated in a Relay-Supplied Options option. 111 The DHCP server can then choose to place those options in the 112 response it sends to the client. 114 3. Encoding 116 In order to supply options for the DHCP server to send to the client, 117 the relay agent sends a Relay-Supplied Options option in the Relay- 118 Forward message. This option encapsulates whatever options the relay 119 agent wishes to provide to the DHCPv6 server. 121 0 1 2 3 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | OPTION_RSOO | option-length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | suboptions... 127 +-+-+-+-+-+-+-+-+-+-+-+ 129 OPTION_RSOO Relay-Supplied Options code (TBD). 131 option-length Length of Relay-Supplied Options option. 133 suboptions One or more DHCPv6 options. 135 4. RSOO-enabled options 137 Unless specifically called out as an RSOO-enabled option, no DHCP 138 option should appear in an RSOO. Specifications that describe RSOO- 139 enabled options MUST reference this specification, and MUST state 140 that the option they define is RSOO-enabled. No DHCP option 141 specified prior to the issuance of this specification is RSOO- 142 enabled. 144 A current list of RSOO-enabled options can be found in the list 145 titled "Options Permitted in the Relay-Supplied Options option" 146 maintained at http://www.iana.org/assignments/dhcpv6-parameters. 148 DHCP option specifications that define RSOO-enabled options MUST add 149 text similar to the following to their IANA considerations section; 150 "random relay option" should be replaced with the name of the option 151 being defined in the specification: 153 We request that IANA add the name "random relay option" to the 154 registry titled "Options Permitted in the Relay-Supplied Options 155 Option" maintained at 156 http://www.iana.org/assignments/dhcpv6-parameters. 158 5. DHCP Relay Agent Behavior 160 DHCP relay agents that implement this specification MUST be 161 configurable not to send the Relay-Supplied Options option. 163 Relay agents MAY include a Relay-Supplied Options option in the 164 option payload of a Relay-Forward message. Relay agents MUST NOT 165 modify the contents of any message before forwarding it to the DHCP 166 client. 168 Relay agents MUST NOT send non-RSOO-enabled options in the Relay- 169 Supplied Options option. 171 Relay agents implementing this specification SHOULD have a 172 configuration parameter that determines whether or not they will 173 relay a Relay-Forward message toward the DHCP server if it contains a 174 Relay-Supplied Options option. 176 Relay agents that have this configuration parameter and that are 177 configured to enable this behavior MUST silently discard any Relay- 178 Forward packet that contains a Relay-Supplied Options option. 180 Implementations that can be configured in this way MUST examine all 181 Relay-Forward encapsulations, not just the outer encapsulation. 183 6. DHCP Server Behavior 185 DHCP servers that implement this specification MUST examine each 186 option contained in an RSOO to see if it is an RSOO-enabled option. 187 DHCP servers MUST silently discard any option contained in an RSOO 188 that is not RSOO-enabled. DHCP server implementations SHOULD have a 189 user-configurable list of RSOO-enabled options, so that new RSOO- 190 enabled options do not require software to be updated. 192 DHCP servers normally construct a list of options that are candidates 193 to send to the DHCP client, and then construct the DHCP packet 194 according to section 17.2.2 of DHCPv6 [RFC3315]. 196 If the server implementing this specificaton receives an RSOO, it 197 SHOULD add any options that appear in the RSOO for which it has no 198 internal candidate to the list of options that are candidates to send 199 to the DHCP client. The server SHOULD discard any options that 200 appear in the RSOO for which it already has one or more candidates. 202 Aside from the addition of options from the RSOO, the DHCP server 203 should then construct a DHCP packet as it normally would, and 204 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 206 DHCP servers may receive multiply-nested Relay-Forward messages 207 containing conflicting values for options contained in Relay Supplied 208 Options options in these messages. 210 When such a conflict exists, the DHCP server MUST choose no more than 211 one of these options to forward to the client. The DHCP server MUST 212 not forward more than one of these options to the client. 214 By default, the DHCP server MUST choose the innermost value--the 215 value supplied by the relay agent closest to the DHCP client, to 216 forward to the DHCP client. 218 DHCP server implementations MAY provide other heuristics for choosing 219 which one of a set of such conflicting options to forward to the 220 client, as long as the specified behavior is the default behavior. 222 7. Security Considerations 224 This document provides a mechanism whereby a relay agent can inject 225 options into the response the DHCP server sends to the DHCP client. 226 In general it is expected that RSOO-enabled options will be specified 227 because they only make sense when originating from the relay agent. 228 This is true of existing use cases. 230 In the event that some new RSOO-enabled option is specified that can 231 originate from either the server or the relay agent, this should be 232 addressed in the security considerations section of the document that 233 specifies the use of that option. 235 In some environments, there is an interface on one side of which is 236 the client, and zero or more routers, and on the other side of which 237 is a network managed by a monolithic or effectively monolithic 238 administrative entity. Nodes and routers on the client side of the 239 interface are not controlled by this entity, and are considered 240 "untrusted." Nodes and routers on the other side of this interface 241 are considered trusted. 243 It is possible for a relay agent on the untrusted side of this 244 interface to supply a Relay-Supplied Options option containing one or 245 more RSOO-enabled options that would override the same option or 246 options that were provided by a relay agent on the trusted side of 247 the interface. 249 In environments where this is a possibility, network administrators 250 are advised to use relay agents that are capable of dropping Relay- 251 Forward messages containing the Relay-Supplied Options option, and 252 are advised to configure those relays to drop such messages. 254 Note, however, that this will only be effective if the message from 255 the DHCP server to the DHCP client is authenticated as specified in 256 Section 21 of DHCP Version 6 [RFC3315], or using some similar 257 mechanism. Without this authentication, the relay agent on the 258 untrusted portion of the network can simply modify the DHCP server's 259 response in transit back to the DHCP client, and there is no way for 260 the client to detect that this has happened. 262 8. IANA Considerations 264 We request that IANA assign one new option code from the registry of 265 DHCP Option Codes maintained at 266 http://www.iana.org/assignments/dhcpv6-parameters. This option code 267 will be assigned to the Relay-Supplied Options option. 269 We request that the IANA create a new registry on the same 270 assignments page, titled "Options Permitted in the Relay-Supplied 271 Options Option". This option will contain a list of names of options 272 from the DHCP Option Codes list. Currently, the list is empty. 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 9.2. Informative References 287 [I.D-ietf-hokey-ldn-discovery] 288 Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name 289 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in 290 progress), September 2010. 292 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 293 authentication Protocol (ERP)", RFC 5296, August 2008. 295 Authors' Addresses 297 Ted Lemon 298 Nominum 299 2000 Seaport Blvd 300 Redwood City, CA 94063 301 USA 303 Phone: +1 650 381 6000 304 Email: mellon@nominum.com 306 Qin Wu 307 Huawei Technologies Co., Ltd. 308 101 Software Avenue, Yuhua District 309 Nanjing, Jiangsu 210012 310 China 312 Email: sunseawq@huawei.com