idnits 2.17.1 draft-ietf-dhc-dhcpv6-relay-supplied-options-05.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 -- The document date (May 9, 2011) is 4735 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 (~~), 1 warning (==), 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: November 10, 2011 Huawei 6 May 9, 2011 8 Relay-Supplied DHCP Options 9 draft-ietf-dhc-dhcpv6-relay-supplied-options-05 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 November 10, 2011. 35 Copyright Notice 37 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 | options... 127 +-+-+-+-+-+-+-+-+-+-+-+ 129 OPTION_RSOO 131 Relay-Supplied Options code (TBD). 133 option-length 135 Length of Relay-Supplied Options option. 137 options 139 One or more DHCPv6 options. 141 4. RSOO-enabled options 143 Unless specifically called out as an RSOO-enabled option, no DHCP 144 option should appear in an RSOO. Specifications that describe RSOO- 145 enabled options MUST reference this specification, and MUST state 146 that the option they define is RSOO-enabled. No DHCP option 147 specified prior to the issuance of this specification is RSOO- 148 enabled. 150 A current list of RSOO-enabled options can be found in the list 151 titled "Options Permitted in the Relay-Supplied Options option" 152 maintained at http://www.iana.org/assignments/dhcpv6-parameters. 154 DHCP option specifications that define RSOO-enabled options MUST add 155 text similar to the following to their IANA considerations section; 156 "random relay option" should be replaced with the name of the option 157 being defined in the specification: 159 We request that IANA add the name "random relay option" to the 160 registry titled "Options Permitted in the Relay-Supplied Options 161 Option" maintained at 162 http://www.iana.org/assignments/dhcpv6-parameters. 164 5. DHCP Relay Agent Behavior 166 DHCP relay agents that implement this specification MUST be 167 configurable not to send the Relay-Supplied Options option. 169 Relay agents MAY include a Relay-Supplied Options option in the 170 option payload of a Relay-Forward message. Relay agents MUST NOT 171 modify the contents of any message before forwarding it to the DHCP 172 client. 174 Relay agents MUST NOT send non-RSOO-enabled options in the Relay- 175 Supplied Options option. 177 Relay agents implementing this specification SHOULD have a 178 configuration parameter that determines whether or not they will 179 relay a Relay-Forward message toward the DHCP server if it contains a 180 Relay-Supplied Options option. 182 Relay agents that have this configuration parameter and that are 183 configured to enable this behavior MUST silently discard any Relay- 184 Forward packet that contains a Relay-Supplied Options option. 186 Implementations that can be configured in this way MUST examine all 187 Relay-Forward encapsulations, not just the outer encapsulation. 189 6. DHCP Server Behavior 191 DHCP servers that implement this specification MUST examine each 192 option contained in an RSOO to see if it is an RSOO-enabled option. 193 DHCP servers MUST silently discard any option contained in an RSOO 194 that is not RSOO-enabled. DHCP server implementations SHOULD have a 195 user-configurable list of RSOO-enabled options, so that new RSOO- 196 enabled options do not require software to be updated. 198 DHCP servers normally construct a list of options that are candidates 199 to send to the DHCP client, and then construct the DHCP packet 200 according to section 17.2.2 of DHCPv6 [RFC3315]. 202 If the server implementing this specificaton receives an RSOO, it 203 SHOULD add any options that appear in the RSOO for which it has no 204 internal candidate to the list of options that are candidates to send 205 to the DHCP client. The server SHOULD discard any options that 206 appear in the RSOO for which it already has one or more candidates. 208 Aside from the addition of options from the RSOO, the DHCP server 209 should then construct a DHCP packet as it normally would, and 210 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 212 DHCP servers may receive multiply-nested Relay-Forward messages 213 containing conflicting values for options contained in Relay Supplied 214 Options options in these messages. 216 When such a conflict exists, the DHCP server MUST choose no more than 217 one of these options to forward to the client. The DHCP server MUST 218 NOT forward more than one of these options to the client. 220 By default, the DHCP server MUST choose the innermost value--the 221 value supplied by the relay agent closest to the DHCP client, to 222 forward to the DHCP client. 224 DHCP server implementations MAY provide other heuristics for choosing 225 which one of a set of such conflicting options to forward to the 226 client, as long as the specified behavior is the default behavior. 228 7. Security Considerations 230 This document provides a mechanism whereby a relay agent can inject 231 options into the response the DHCP server sends to the DHCP client. 232 In general it is expected that RSOO-enabled options will be specified 233 because they only make sense when originating from the relay agent. 234 This is true of existing use cases. 236 In the event that some new RSOO-enabled option is specified that can 237 originate from either the server or the relay agent, this should be 238 addressed in the security considerations section of the document that 239 specifies the use of that option. 241 In some environments, there is an interface on one side of which is 242 the client, and zero or more routers, and on the other side of which 243 is a network managed by a monolithic or effectively monolithic 244 administrative entity. Nodes and routers on the client side of the 245 interface are not controlled by this entity, and are considered 246 "untrusted." Nodes and routers on the other side of this interface 247 are considered trusted. 249 It is possible for a relay agent on the untrusted side of this 250 interface to supply a Relay-Supplied Options option containing one or 251 more RSOO-enabled options that would override the same option or 252 options that were provided by a relay agent on the trusted side of 253 the interface. 255 In environments where this is a possibility, network administrators 256 are advised to use relay agents that are capable of dropping Relay- 257 Forward messages containing the Relay-Supplied Options option, and 258 are advised to configure those relays to drop such messages. 260 Note, however, that this will only be effective if the message from 261 the DHCP server to the DHCP client is authenticated as specified in 262 Section 21 of DHCP Version 6 [RFC3315], or using some similar 263 mechanism. Without this authentication, the relay agent on the 264 untrusted portion of the network can simply modify the DHCP server's 265 response in transit back to the DHCP client, and there is no way for 266 the client to detect that this has happened. 268 8. IANA Considerations 270 We request that IANA assign one new option code from the registry of 271 DHCP Option Codes maintained at 272 http://www.iana.org/assignments/dhcpv6-parameters. This option code 273 will be assigned to the Relay-Supplied Options option. 275 We request that the IANA create a new registry on the same 276 assignments page, titled "Options Permitted in the Relay-Supplied 277 Options Option". This option will contain a list of names of options 278 from the DHCP Option Codes list. Currently, the list is empty. 280 9. References 282 9.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 288 and M. Carney, "Dynamic Host Configuration Protocol for 289 IPv6 (DHCPv6)", RFC 3315, July 2003. 291 9.2. Informative References 293 [I.D-ietf-hokey-ldn-discovery] 294 Zorn, G., Wu, Q., and Y. Wang, "The ERP Local Domain Name 295 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in 296 progress), April 2011. 298 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 299 authentication Protocol (ERP)", RFC 5296, August 2008. 301 Authors' Addresses 303 Ted Lemon 304 Nominum 305 2000 Seaport Blvd 306 Redwood City, CA 94063 307 USA 309 Phone: +1 650 381 6000 310 Email: mellon@nominum.com 312 Qin Wu 313 Huawei Technologies Co., Ltd. 314 101 Software Avenue, Yuhua District 315 Nanjing, Jiangsu 210012 316 China 318 Email: sunseawq@huawei.com