idnits 2.17.1 draft-ietf-dhc-dhcpv6-relay-supplied-options-08.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 the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2011) is 4665 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc T. Lemon 3 Internet-Draft Nominum 4 Updates: 3315 (if approved) Q. Wu 5 Intended status: Standards Track Huawei 6 Expires: January 13, 2012 July 12, 2011 8 Relay-Supplied DHCP Options 9 draft-ietf-dhc-dhcpv6-relay-supplied-options-08 11 Abstract 13 DHCPv6 relay agents can not communicate with DHCPv6 clients directly. 14 However, in some cases, the relay agent possesses some information 15 that would be useful to the DHCPv6 client. This document describes a 16 mechanism whereby the DHCPv6 relay agent can provide such information 17 to the DHCPv6 server, which can, in turn, pass this information on to 18 the DHCP client. 20 This document updates RFC3315 (DHCPv6) by making explicit the 21 implicit requirement that relay agents not modify the content of 22 encapsulation payloads as they are relayed back toward clients. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 13, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. RSOO-enabled options . . . . . . . . . . . . . . . . . . . . . 4 64 5. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 5 65 6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The DHCPv6 specification [RFC3315] allows DHCP relay agents to 76 forward DHCPv6 messages between clients and servers that are not on 77 the same IPv6 link. In some cases the DHCP relay agent has 78 information not available to the DHCP server that would be useful to 79 provide to a DHCP client. For example, the DHCP client may need to 80 learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for 81 use in EAP re-authentication [RFC5296], which is known to the relay 82 agent but not the server. 84 The DHCPv6 protocol specification does not provide a mechanism 85 whereby the relay agent can provide options to the client. This 86 document extends DHCP with a mechanism that allows DHCP relay agents 87 to propose options for the server to send to DHCP clients. 89 This document is not intended to provide a general mechanism for 90 storing client configuration information in the relay agent. Rather, 91 it is intended to address specific use cases where only the relay 92 agent has information needed by the client. This extension is not 93 applicable to DHCP options in general, but rather provided as a 94 mechanism for new specifications that require this functionality. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 1.2. Terminology 104 The following terms and acronyms are used in this document: 106 DHCP Dynamic Host Configuration Protocol Version 6 [RFC3315] 108 RSOO Relay-Supplied Options option 110 2. Protocol Summary 112 DHCP clients do not support a mechanism for receiving options from 113 relay agents--the relay agent is required to deliver the payload from 114 the DHCP server to the DHCP client without changing it. In order for 115 the DHCP relay agent to provide options to the client, it sends those 116 options to the DHCP server, encapsulated in a Relay-Supplied Options 117 option. The DHCP server can then choose to place those options in 118 the response it sends to the client. 120 3. Encoding 122 In order to supply options for the DHCP server to send to the client, 123 the relay agent sends a Relay-Supplied Options option in the Relay- 124 Forward message. This option encapsulates whatever options the relay 125 agent wishes to provide to the DHCPv6 server. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | OPTION_RSOO | option-length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | options... 133 +-+-+-+-+-+-+-+-+-+-+-+ 135 OPTION_RSOO 137 Relay-Supplied Options code (TBD). 139 option-length 141 Length of Relay-Supplied Options option. 143 options 145 One or more DHCPv6 options. 147 4. RSOO-enabled options 149 The RSOO MUST NOT contain any option that is not specifically called 150 out as an RSOO-enabled option. Specifications that describe RSOO- 151 enabled options MUST reference this specification, and MUST state 152 that the option they define is RSOO-enabled. No DHCP option 153 specified prior to the issuance of this specification is RSOO- 154 enabled. 156 A current list of RSOO-enabled options can be found in the list 157 titled "Options Permitted in the Relay-Supplied Options option" 158 maintained at http://www.iana.org/assignments/dhcpv6-parameters. 160 DHCP option specifications that define RSOO-enabled options MUST add 161 text similar to the following to their IANA considerations section; 162 "random relay option" should be replaced with the name of the option 163 being defined in the specification: 165 We request that IANA add the name "random relay option" to the 166 registry titled "Options Permitted in the Relay-Supplied Options 167 Option" maintained at 168 http://www.iana.org/assignments/dhcpv6-parameters. 170 5. DHCP Relay Agent Behavior 172 Relay agents MAY include a Relay-Supplied Options option in the 173 option payload of a Relay-Forward message being sent toward a DHCP 174 server. When relaying the payload of Relay-Reply messages toward 175 clients, Relay agents MUST NOT modify the payload. 177 Relay agents MUST NOT send non-RSOO-enabled options in the Relay- 178 Supplied Options option. 180 In order to allow network administrators to control the flow of RSOO 181 options onto the network, relay agents that implement the Relay 182 Supplied Options Option need to have a configuration parameter that 183 determines to whether or not they will relay RSOO-containing Relay- 184 Forward messages. 186 Relay agents that have this configuration parameter and that are 187 configured to disable forwarding of Relay-Forward messages that 188 contain a Relay-Supplied Options option MUST silently discard any 189 such message. 191 Implementations that can be configured in this way MUST examine all 192 Relay-Forward encapsulations, not just the outer encapsulation. 194 6. DHCP Server Behavior 196 DHCP servers that implement Relay-Supplied DHCP Options MUST examine 197 each option contained in an RSOO to see if it is an RSOO-enabled 198 option. DHCP servers MUST silently discard any option contained in 199 an RSOO that is not RSOO-enabled. DHCP server implementations SHOULD 200 have an administrator-configurable list of RSOO-enabled options, so 201 that new RSOO-enabled options do not require software to be updated. 203 DHCP servers normally construct a list of options that are candidates 204 to send to the DHCP client, and then construct the DHCP packet 205 according to section 17.2.2 of DHCPv6 [RFC3315]. 207 If the server implementing Relay-Supplied DHCP Options receives an 208 RSOO, it SHOULD add any options that appear in the RSOO for which it 209 has no internal candidate to the list of options that are candidates 210 to send to the DHCP client. The server SHOULD discard any options 211 that appear in the RSOO for which it already has one or more 212 candidates. 214 Aside from the addition of options from the RSOO, the DHCP server 215 should then construct a DHCP packet as it normally would, and 216 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 218 DHCP servers may receive multiply-nested Relay-Forward messages 219 containing conflicting values for options contained in Relay Supplied 220 Options options in these messages. 222 When such a conflict exists, the DHCP server MUST choose no more than 223 one of these options to forward to the client. The DHCP server MUST 224 NOT forward more than one of these options to the client. 226 By default, the DHCP server MUST choose the innermost value--the 227 value supplied by the relay agent closest to the DHCP client, to 228 forward to the DHCP client. 230 DHCP server implementations MAY provide other heuristics for choosing 231 which one of a set of such conflicting options to forward to the 232 client, as long as the specified behavior is the default behavior. 234 7. Security Considerations 236 This document provides a mechanism whereby a relay agent can inject 237 options into the response the DHCP server sends to the DHCP client. 238 In general it is expected that RSOO-enabled options will be specified 239 because they only make sense when originating from the relay agent. 240 This is true of existing use cases. 242 In the event that some new RSOO-enabled option is specified that can 243 originate from either the server or the relay agent, this should be 244 addressed in the security considerations section of the document that 245 specifies the use of that option. 247 In some environments, there is an interface on one side of which is 248 the client, and zero or more routers, and on the other side of which 249 is a network managed by a monolithic or effectively monolithic 250 administrative entity. Nodes and routers on the client side of the 251 interface are not controlled by this entity, and are considered 252 "untrusted." Nodes and routers on the network side of this interface 253 are considered trusted. 255 It is possible for a malicious node acting as a relay agent on the 256 untrusted side of this interface to supply a Relay-Supplied Options 257 option containing one or more RSOO-enabled options that would 258 override the same option or options that were provided by a relay 259 agent on the trusted side of the interface. 261 In environments where this is a possibility, network administrators 262 are advised to use relay agents that are capable of dropping Relay- 263 Forward messages containing the Relay-Supplied Options option, and 264 are advised to configure those relays to drop such messages. 266 Note, however, that this will only be effective if the message from 267 the DHCP server to the DHCP client is authenticated as specified in 268 Section 21 of DHCP Version 6 [RFC3315], or using some similar 269 mechanism. Without this authentication, the malicious node on the 270 untrusted portion of the network can simply modify the DHCP server's 271 response in transit back to the DHCP client, and there is no way for 272 the client to detect that this has happened. 274 8. IANA Considerations 276 We request that IANA assign one new registry code from the registry 277 of DHCP Option Codes maintained at 278 http://www.iana.org/assignments/dhcpv6-parameters. This registry 279 code will be assigned to the Relay-Supplied Options option. 281 We request that the IANA create a new registry on the same 282 assignments page, titled "Options Permitted in the Relay-Supplied 283 Options Option". This option will contain a list of names of options 284 from the DHCP Option Codes list. Currently, the list is empty. 285 Options may be added to this list after IETF Review[RFC5226]. 287 IETF Review should include careful consideration of the security 288 implications of allowing a relay agent to provide a value for the 289 option being considered for addition to this registry. In the case 290 where an IETF working group chartered to review DHCP protocol 291 extensions exists, it is not sufficient for some other working group 292 to review the registry addition. 294 9. References 296 9.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 302 and M. Carney, "Dynamic Host Configuration Protocol for 303 IPv6 (DHCPv6)", RFC 3315, July 2003. 305 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 306 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 307 May 2008. 309 9.2. Informative References 311 [I.D-ietf-hokey-ldn-discovery] 312 Zorn, G., Wu, Q., and Y. Wang, "The ERP Local Domain Name 313 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in 314 progress), April 2011. 316 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 317 authentication Protocol (ERP)", RFC 5296, August 2008. 319 Authors' Addresses 321 Ted Lemon 322 Nominum 323 2000 Seaport Blvd 324 Redwood City, CA 94063 325 USA 327 Phone: +1 650 381 6000 328 Email: mellon@nominum.com 330 Qin Wu 331 Huawei Technologies Co., Ltd. 332 101 Software Avenue, Yuhua District 333 Nanjing, Jiangsu 210012 334 China 336 Email: sunseawq@huawei.com