idnits 2.17.1 draft-ietf-dhc-container-opt-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 418. 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 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 (November 28, 2008) is 5626 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 (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Working Group R. Droms 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track November 28, 2008 5 Expires: June 1, 2009 7 Container Option for Server Configuration 8 draft-ietf-dhc-container-opt-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 1, 2009. 35 Abstract 37 In some DHCP service deployments, it is desirable for a DHCP server 38 in one administrative domain to pass configuration options to a DHCP 39 server in a different administrative domain. This DHCP option 40 carries a set of DHCP options that can be used by another DHCP 41 server. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Problem statement and requirements for RG DHCP server 48 configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Design alternatives . . . . . . . . . . . . . . . . . . . . . 5 50 5. Semantics and syntax of the Container option . . . . . . . . . 6 51 5.1. DHCPv4 Container option . . . . . . . . . . . . . . . . . 6 52 5.2. DHCPv6 Container option . . . . . . . . . . . . . . . . . 6 53 5.3. SP server behavior . . . . . . . . . . . . . . . . . . . . 7 54 5.4. RG client behavior . . . . . . . . . . . . . . . . . . . . 7 55 5.5. RG server behavior . . . . . . . . . . . . . . . . . . . . 7 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 8.1. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 8 60 8.2. Revision -03 . . . . . . . . . . . . . . . . . . . . . . . 9 61 8.3. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 9 62 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Intellectual Property and Copyright Statements . . . . . . . . . . 11 67 1. Introduction 69 In some DHCP service deployments, it is desirable to pass 70 configuration options from a DHCP server in one administrative domain 71 to another DHCP server in a different administrative domain. In one 72 example of such a deployment, an IPTV service provider (SP) may need 73 to provide certain SP domain-specific information to IPTV device(s) 74 located in the consumer domain. This information is sent from the 75 IPTV SP DHCP server to the consumer DHCP server located in the 76 Residential Gateway (RG), which can then be passed along to IPTV 77 device(s) in the subscriber network. 79 Existing RGs may pass some configuration information received by the 80 RG DHCP client to the RG server for configuration of devices attached 81 to the consumer network. There are several motivations for this 82 option: 84 o The devices attached to the consumer network may require different 85 configuration information than the DHCP options provided to the 86 RG. 88 o Existing RG DHCP clients are typically not coded to process new 89 DHCP options and, therefore, will be unable to pass those new 90 options to the RG DHCP server. 92 o Existing RG DHCP clients are typically coded to pass only a fixed 93 list of DHCP options to the RG DHCP server and, therefore, will be 94 unable to pass newly defined options to the RG DHCP server. 96 The DHCP Container option defined in this document provides a 97 mechanism through which the RG DHCP client can pass DHCP options to 98 the RG DHCP server without explicit knowledge of the semantics of 99 those options. With this option, the SP DHCP server can pass both 100 current and future DHCP options to the RG DHCP server. 102 The DHCP Container option does not carry IP addresses, IPv6 prefixes 103 or other information about leases. It carries other configuration 104 information. 106 2. Terminology 108 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 109 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 110 interpreted as described in RFC2119 [RFC2119]. 112 The following terms and acronyms are used in this document: 114 DHCPv4 "Dynamic Host Configuration Protocol" [RFC2131] 116 DHCPv6 "Dynamic Host Configuration Protocol for IPv6" 117 [RFC3315] 119 DHCP DHCPv4 and/or DHCPv6 121 RG "residential gateway"; the device through which 122 the consumer network connects to the broadband 123 WAN; typically a layer 3 forwarding device 125 RG DHCP client (or "RG client") the DHCP client in the RG 127 RG DHCP server (or "RG server") the DHCP server in the RG 129 SP DHCP server (or "SP server") the DHCP server managed by the 130 service provider (SP) 132 This document uses other terminology for DHCPv4 and DHCPv6 as defined 133 in RFC 2131 and RFC 3315, respectively. 135 3. Problem statement and requirements for RG DHCP server configuration 137 The following diagram shows the components in a network deployment 138 using the DHCP Container option: 140 Client host -+ +---------+ +------+ 141 | | RG | | SP | 142 Client host -+ | Client+--- ... ---+ DHCP | 143 +--+Server | |server| 144 Client host -+ +---------+ +------+ 146 In this diagram, the RG client engages in DHCP message exchanges with 147 the SP server to obtain its IP address and other configuration 148 information. 150 The problem under consideration in this document is to transmit 151 configuration information from the SP DHCP server to hosts, such as 152 computers and set-top boxes, attached to the consumer network. The 153 problem solution has the following requirements: 155 o The SP server MUST be able to transmit different configuration 156 information to the consumer devices than the DHCP options provided 157 to the RG. 159 o The SP server MUST be able to control which DHCP options are 160 transmitted to the consumer device. 162 o There MUST be a way for the SP server to pass DHCP options to be 163 defined in the future to consumer devices. 165 4. Design alternatives 167 The following three designs meet the solution requirements: 169 o SP server passes container option to RG client, which forwards 170 contents to RG server; this alternative is the preferred solution 172 o RG server does direct DHCP info request to SP server; this 173 alternative is not preferred because it: 175 * requires that the RG server include a DHCP client, 177 * requires that the SP server be able to differentiate between RG 178 client and server requests, and it 180 * does not scale well, as it at least doubles the load on the SP 181 server. 183 o RG server passes device requests to SP DHCP server; this 184 alternative is not preferred because it: 186 * requires that the RG also function as a DHCP relay, 188 * requires that the RG relay function be configured with the IP 189 addresses of the SP DHCP server(s), and it 191 * requires that the RG relay function differentiate between DHCP 192 messages that are processed by the RG server and DHCP messages 193 that are processes by the SP server, which does not scale well. 195 A variant on the preferred design would allow the inclusion of 196 multiple sets of DHCP options intended for different classes of 197 devices in the consumer network; e.g., the design would allow for one 198 set of options for video set-top boxes and a second set of options 199 for VoIP MTAs. The variant would require the specification of rules 200 to be provided by the SP server through which the RG server would 201 differentiate its clients and send the appropriate set of options to 202 each device. At present, there is no requirement for differential 203 configuration of consumer devices and this alternative is not defined 204 in this document. 206 5. Semantics and syntax of the Container option 208 Along with configuration information intended for the RG, the SP 209 server can include the DHCP Container option. When the RG client 210 receives the DHCP Container option, it passes the contents of the 211 option to the RG server. The means through which the information is 212 passed between the RG client and the RG server is out of the scope of 213 this document and left unspecified. 215 The DHCP options in this container are carried in DHCP message format 216 (option-code/length/value). In this format, the contained options 217 can be passed through a DHCP client to a co-located DHCP server 218 without specific knowledge on the part of the client or the server of 219 the semantics of the options. 221 5.1. DHCPv4 Container option 223 The DHCPv4 Container option has the following format: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Code | len | DHCP Options for RG server | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 230 . . 231 . . 232 . . 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Code OPTION_CONTAINER_V4 (TBDv4) 237 len Length of options for RG server, in octets 239 5.2. DHCPv6 Container option 241 The DHCPv6 Container option has the following format: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | OPTION_CONTAINER_V6 | option-len | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | DHCP Options for RG server | 249 . . 250 . . 251 . . 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 option-code OPTION_CONTAINER_V6 (TBDv6). 256 option-len Length of options for RG server, in octets 258 5.3. SP server behavior 260 The SP server MAY include the Container option in any DHCP message 261 sent to an RG client. 263 The policy through which the SP server is instructed to include a 264 Container option for an RG client, and the policy determining the 265 contents of the Container object are out of scope of this document 266 and left unspecified. 268 5.4. RG client behavior 270 The RG client MUST pass the contents of the received Container option 271 to the RG server without alteration. The details of the 272 implementation through which the RG client parses the content of the 273 Container option and passes the options to the RG server are out of 274 scope for this document and left unspecified. 276 5.5. RG server behavior 278 The RG server MUST discard any options related to IP address 279 assignment, IPv6 prefix delegation or operation of the DHCP protocol 280 itself. 282 The Container option provides a mechanism through which the SP might 283 be able to unilaterally control the configuration settings passed 284 from a RG DHCP server to a host in the subscriber network. This 285 configuration channel must be handled with some care if the 286 subscriber is to retain desired control over the host configurations. 287 The following behaviors limit the degree to which the SP can control 288 host configuration: 290 o The RG server MAY discard any undesired options, as determined by 291 policy in the RG. 293 o The RG server MUST return to any DHCP client only those options 294 requested by the DHCP client in a Parameter Request List option 295 (DHCPv4 option code 55) or an Option Request option (DHCPv6 option 296 code 6). 298 6. Security Considerations 300 A rogue server can use this option to pass invalid information to the 301 RG client, which would then be passed to the Client hosts. This 302 invalid information could be used to mount a denial of service attack 303 or a man-in-the-middle attack against some applications. 305 Authentication of DHCP messages (RFC 3118 [RFC3118] and section 20 of 306 RFC 3315 [RFC3315]) can be used to ensure that the contents of this 307 option are not altered in transit between the DHCP server and client. 309 7. IANA Considerations 311 When this document is published, IANA is asked to assign an option 312 tag from the "BOOTP Vendor Extensions and DHCP Options" registry for 313 OPTION_CONTAINER_V4 (TBDv4). 315 When this document is published, IANA is asked to assign an option 316 code from the "DHCPv6 Option Codes" registry for OPTION_CONTAINER_V6 317 (TBDv6). 319 8. Change Log 321 If this document is accepted for publication as an RFC, this change 322 log is to be removed before publication. 324 8.1. Revision -02 326 o Corrected a cut-and-paste error in section "DHCPv6 Container 327 option": The Time Protocol Servers option -> The DHCPv4 Container 328 option 330 o Added text to section "RG Server Behavior" to address policy 331 management concerns 333 8.2. Revision -03 335 Corrected several typos (thanks to Alfred Hoenes for his review). 337 8.3. Revision -04 339 Corrected additional typos (again, thanks to Alfred Hoenes for his 340 review). 342 Added pointer to "CableLabs' DHCP Options Registry" as background for 343 this option. 345 9. Related Work 347 The Container option is based on the CableLabs eRouter DHCP Container 348 vendor-identifying vendor-specific option, as defined in "CableLabs' 349 DHCP Options Registry" [eRouter]. 351 10. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997. 356 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 357 RFC 2131, March 1997. 359 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 360 Messages", RFC 3118, June 2001. 362 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 363 and M. Carney, "Dynamic Host Configuration Protocol for 364 IPv6 (DHCPv6)", RFC 3315, July 2003. 366 [eRouter] CableLabs, "CableLabs' DHCP Options Registry (CL-SP-CANN- 367 DHCP-Reg-I02-080306)", March 2008. 369 Author's Address 371 Ralph Droms 372 Cisco Systems, Inc. 373 1414 Massachusetts Avenue 374 Boxborough, MA 01719 375 USA 377 Phone: +1 978.936.1674 378 Email: rdroms@cisco.com 380 Full Copyright Statement 382 Copyright (C) The IETF Trust (2008). 384 This document is subject to the rights, licenses and restrictions 385 contained in BCP 78, and except as set forth therein, the authors 386 retain all their rights. 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 391 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 392 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 393 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Intellectual Property 398 The IETF takes no position regarding the validity or scope of any 399 Intellectual Property Rights or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; nor does it represent that it has 403 made any independent effort to identify any such rights. Information 404 on the procedures with respect to rights in RFC documents can be 405 found in BCP 78 and BCP 79. 407 Copies of IPR disclosures made to the IETF Secretariat and any 408 assurances of licenses to be made available, or the result of an 409 attempt made to obtain a general license or permission for the use of 410 such proprietary rights by implementers or users of this 411 specification can be obtained from the IETF on-line IPR repository at 412 http://www.ietf.org/ipr. 414 The IETF invites any interested party to bring to its attention any 415 copyrights, patents or patent applications, or other proprietary 416 rights that may cover technology that may be required to implement 417 this standard. Please address the information to the IETF at 418 ietf-ipr@ietf.org.