idnits 2.17.1 draft-ietf-dhc-container-opt-07.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 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 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 (April 08, 2013) is 4033 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Working Group R. Droms 3 Internet-Draft R. Penno 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: October 10, 2013 April 08, 2013 7 Container Option for Server Configuration 8 draft-ietf-dhc-container-opt-07.txt 10 Abstract 12 In some DHCP service deployments, it is desirable for a DHCP server 13 in one administrative domain to pass configuration options to a DHCP 14 server in a different administrative domain. This DHCP option 15 carries a set of DHCP options that can be used by another DHCP 16 server. 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 October 10, 2013. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem statement and requirements . . . . . . . . . . . . . 4 55 4. Design alternatives . . . . . . . . . . . . . . . . . . . . . 4 56 5. Semantics and syntax of the Container option . . . . . . . . 5 57 5.1. DHCPv4 Container option . . . . . . . . . . . . . . . . . 5 58 5.2. DHCPv6 Container option . . . . . . . . . . . . . . . . . 6 59 5.3. SP server behavior . . . . . . . . . . . . . . . . . . . 6 60 5.4. RG client behavior . . . . . . . . . . . . . . . . . . . 6 61 5.5. RG server behavior . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Revision -02 . . . . . . . . . . . . . . . . . . . . . . 8 66 8.2. Revision -03 . . . . . . . . . . . . . . . . . . . . . . 8 67 8.3. Revision -04 . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 In some DHCP service deployments, it is desirable to pass 77 configuration options from a DHCP server in one administrative domain 78 to another DHCP server in a different administrative domain. In one 79 example of such a deployment, an IPTV service provider (SP) may need 80 to provide certain SP domain-specific information to IPTV device(s) 81 located in the consumer domain. This information is sent from the 82 IPTV SP DHCP server to the consumer DHCP server located in the 83 Residential Gateway (RG), which can then be passed along to IPTV 84 device(s) in the subscriber network. 86 Existing RGs may pass some configuration information received by the 87 RG DHCP client to the RG server for configuration of devices attached 88 to the consumer network. There are several motivations for this 89 option: 91 o The devices attached to the consumer network may require different 92 configuration information than the DHCP options provided to the 93 RG. 95 o Existing RG DHCP clients are typically not coded to process new 96 DHCP options and, therefore, will be unable to pass those new 97 options to the RG DHCP server. 99 o Existing RG DHCP clients are typically coded to pass only a fixed 100 list of DHCP options to the RG DHCP server and, therefore, will be 101 unable to pass newly defined options to the RG DHCP server. 103 The DHCP Container option defined in this document provides a 104 mechanism through which the RG DHCP client can pass DHCP options to 105 the RG DHCP server without explicit knowledge of the semantics of 106 those options. With this option, the SP DHCP server can pass both 107 current and future DHCP options to the RG DHCP server. 109 The DHCP Container option is not used to carry options that assign 110 resources (such as addresses or delegated prefixes) to clients. It 111 can only carry other configuration information options. 113 2. Terminology 115 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 116 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 117 interpreted as described in RFC2119 [RFC2119]. 119 The following terms and acronyms are used in this document: 121 DHCPv4 "Dynamic Host Configuration Protocol" [RFC2131] 123 DHCPv6 "Dynamic Host Configuration Protocol for IPv6" 124 [RFC3315] 126 DHCP DHCPv4 and/or DHCPv6 128 RG "residential gateway"; the device through which 129 the consumer network connects to the broadband 130 WAN; typically a layer 3 forwarding device 132 RG DHCP client (or "RG client") the DHCP client in the RG 134 RG DHCP server (or "RG server") the DHCP server in the RG 136 SP DHCP server (or "SP server") the DHCP server managed by the 137 service provider (SP) 139 This document uses other terminology for DHCPv4 and DHCPv6 as defined 140 in RFC 2131 and RFC 3315, respectively. 142 3. Problem statement and requirements 144 The following diagram shows the components in a network deployment 145 using the DHCP Container option: 147 Client host -+ +---------+ +------+ 148 | | RG | | SP | 149 Client host -+ | Client+--- ... ---+ DHCP | 150 +--+Server | |server| 151 Client host -+ +---------+ +------+ 153 In this diagram, the RG client engages in DHCP message exchanges with 154 the SP server to obtain its IP address and other configuration 155 information. 157 The problem under consideration in this document is to transmit 158 configuration information from the SP DHCP server to hosts, such as 159 computers and set-top boxes, attached to the consumer network. The 160 problem solution has the following requirements: 162 o The SP server MUST be able to transmit different configuration 163 information to the consumer devices than the DHCP options provided 164 to the RG. 166 o The SP server MUST be able to control which DHCP options are 167 transmitted to the consumer device. 169 o There MUST be a way for the SP server to pass DHCP options to be 170 defined in the future to consumer devices. 172 4. Design alternatives 174 The following three designs meet the solution requirements: 176 o SP server passes container option to RG client, which forwards 177 contents to RG server; this alternative is the preferred solution 179 o RG server does direct DHCP info request to SP server; this 180 alternative is not preferred because it: 182 * requires that the RG server include a DHCP client, 183 * requires that the SP server be able to differentiate between RG 184 client and server requests, and it 186 * does not scale well, as it at least doubles the load on the SP 187 server. 189 o RG server passes device requests to SP DHCP server; this 190 alternative is not preferred because it: 192 * requires that the RG also function as a DHCP relay, 194 * requires that the RG relay function be configured with the IP 195 addresses of the SP DHCP server(s), and it 197 * requires that the RG relay function differentiate between DHCP 198 messages that are processed by the RG server and DHCP messages 199 that are processes by the SP server, which does not scale well. 201 A variant on the preferred design would allow the inclusion of 202 multiple sets of DHCP options intended for different classes of 203 devices in the consumer network; e.g., the design would allow for one 204 set of options for video set-top boxes and a second set of options 205 for VoIP MTAs. The variant would require the specification of rules 206 to be provided by the SP server through which the RG server would 207 differentiate its clients and send the appropriate set of options to 208 each device. At present, there is no requirement for differential 209 configuration of consumer devices and this alternative is not defined 210 in this document. 212 5. Semantics and syntax of the Container option 214 Along with configuration information intended for the RG, the SP 215 server can include the DHCP Container option. When the RG client 216 receives the DHCP Container option, it passes the contents of the 217 option to the RG server. The means through which the information is 218 passed between the RG client and the RG server is out of the scope of 219 this document and left unspecified. 221 The DHCP options in this container are carried in DHCP message format 222 (option-code/length/value). In this format, the contained options 223 can be passed through a DHCP client to a co-located DHCP server 224 without specific knowledge on the part of the client or the server of 225 the semantics of the options. 227 5.1. DHCPv4 Container option 229 The DHCPv4 Container option has the following format: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Code | len | DHCP Options for RG server | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 236 . . 237 . . 238 . . 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Code OPTION_V4_CONTAINER (TBDv4) 243 len Length of options for RG server, in octets 245 5.2. DHCPv6 Container option 247 The DHCPv6 Container option has the following format: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | OPTION_CONTAINER_V6 | option-len | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | DHCP Options for RG server | 255 . . 256 . . 257 . . 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 option-code OPTION_V6_CONTAINER (TBDv6) 262 option-len Length of options for RG server, in octets 264 5.3. SP server behavior 266 The SP server MAY include the Container option in any DHCP message 267 sent to an RG client. 269 The policy through which the SP server is instructed to include a 270 Container option for an RG client, and the policy determining the 271 contents of the Container object are out of scope of this document 272 and left unspecified. 274 5.4. RG client behavior 275 The RG client MUST pass the contents of the received Container option 276 to the RG server without alteration. The details of the 277 implementation through which the RG client parses the content of the 278 Container option and passes the options to the RG server are out of 279 scope for this document and left unspecified. 281 5.5. RG server behavior 283 The RG server MUST discard any options related to IP address 284 assignment, IPv6 prefix delegation or operation of the DHCP protocol 285 itself. The following options are not permitted. 287 The Container option provides a mechanism through which the SP might 288 be able to unilaterally control the configuration settings passed 289 from a RG DHCP server to a host in the subscriber network. This 290 configuration channel must be handled with some care if the 291 subscriber is to retain desired control over the host configurations. 292 The following behaviors limit the degree to which the SP can control 293 host configuration: 295 o The RG server MAY discard any undesired options, as determined by 296 policy in the RG. 298 o The RG server MUST return to any DHCP client only those options 299 requested by the DHCP client in a Parameter Request List option 300 (DHCPv4 option code 55) or an Option Request option (DHCPv6 option 301 code 6). 303 o DHCPv4 options not permitted: 1, 3, 50, 51, 52, 53, 54, 55, 56, 304 57, 58, 59, 60, 61, 81, 82, 90, 91, 92, 118, 124, 151, 152, 153, 305 154, 155, 156, 157, 220, 221 307 o DHCPv6 options not permitted: 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 308 13, 14, 15, 16, 18, 19, 20, 25, 26, 43, 44, 45, 46, 47, 48, 66, 309 67, 68 311 6. Security Considerations 313 A rogue server can use this option to pass invalid information to the 314 RG client, which would then be passed to the Client hosts. This 315 invalid information could be used to mount a denial of service attack 316 or a man-in-the-middle attack against some applications. 318 Authentication of DHCP messages (RFC 3118 [RFC3118] and section 20 of 319 RFC 3315 [RFC3315]) can be used to ensure that the contents of this 320 option are not altered in transit between the DHCP server and client. 322 7. IANA Considerations 324 When this document is published, IANA is asked to assign an option 325 tag from the "BOOTP Vendor Extensions and DHCP Options" registry for 326 OPTION_CONTAINER_V4 (TBDv4). 328 When this document is published, IANA is asked to assign an option 329 code from the "DHCPv6 Option Codes" registry for OPTION_CONTAINER_V6 330 (TBDv6). 332 8. Change Log 334 If this document is accepted for publication as an RFC, this change 335 log is to be removed before publication. 337 8.1. Revision -02 339 o Corrected a cut-and-paste error in section "DHCPv6 Container 340 option": The Time Protocol Servers option -> The DHCPv4 Container 341 option 343 o Added text to section "RG Server Behavior" to address policy 344 management concerns 346 8.2. Revision -03 348 Corrected several typos (thanks to Alfred Hoenes for his review). 350 8.3. Revision -04 352 Corrected additional typos (again, thanks to Alfred Hoenes for his 353 review). 355 Added pointer to "CableLabs' DHCP Options Registry" as background for 356 this option. 358 9. Related Work 360 The Container option is based on the CableLabs eRouter DHCP Container 361 vendor-identifying vendor-specific option, as defined in "CableLabs' 362 DHCP Options Registry" [eRouter]. 364 10. References 366 10.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 372 2131, March 1997. 374 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 375 Messages", RFC 3118, June 2001. 377 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 378 and M. Carney, "Dynamic Host Configuration Protocol for 379 IPv6 (DHCPv6)", RFC 3315, July 2003. 381 10.2. Informative References 383 [eRouter] CableLabs, , "CableLabs' DHCP Options Registry (CL-SP- 384 CANN-DHCP-Reg-I09-120809)", March 2008. 386 Authors' Addresses 388 Ralph Droms 389 Cisco Systems, Inc. 390 1414 Massachusetts Avenue 391 Boxborough, MA 01719 392 USA 394 Phone: +1 978.936.1674 395 Email: rdroms@cisco.com 397 Reinaldo Penno 398 Cisco Systems, Inc. 399 170 West Tasman Drive 400 San Jose, CA 95134 401 USA 403 Email: repenno@cisco.com