idnits 2.17.1 draft-ietf-dhc-bcmc-options-00.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 176: '... The option MAY contain multiple dom...' RFC 2119 keyword, line 177: '... SHOULD be used to construct SRV lookups as specified in [BCMCS],...' RFC 2119 keyword, line 178: '...ferent A records. The client MUST try...' RFC 2119 keyword, line 189: '... Clients MUST support compression ac...' RFC 2119 keyword, line 195: '... the domain list MUST be represented i...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 365 has weird spacing: '...vice in cdma2...' -- 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 (February 27, 2005) is 6995 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) -- Looks like a reference, but probably isn't: '5' on line 221 -- Possible downref: Non-RFC (?) normative reference: ref. 'BCMCS' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury 3 Internet-Draft Starent Networks 4 Expires: August 28, 2005 P. Yegani 5 Cisco Systems 6 L. Madour 7 Ericsson 8 February 27, 2005 10 DHCP Options for Broadcast and Multicast Control Servers 11 draft-ietf-dhc-bcmc-options-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document defines new options for Broadcast and Multicast Service 47 controller discovery in an IP network. Broadcast service is being 48 developed for 3G wireless networks. Users of the service interact 49 with a controller in the network to derive informations that are 50 required to receive broadcast service. Dynamic Host Configuration 51 Protocol can be used to configure the controller IPv4 addresses or 52 fully qualified domain names in the user's devices. This document 53 defines the related options and option codes. 55 Table of Contents 57 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Overview of the 3GPP2 BCMCS Network . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Broadcast Service Controller Options . . . . . . . . . . . . . 6 61 4.1 Broadcast Service Controller Domain Name List Option 62 for DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2 Broadcast Service Controller Domain Name List Option 64 for DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3 Broadcast Service Controller IPv4 Address Option . . . . . 8 66 4.4 Broadcast Service Controller IPv6 Address Option . . . . . 8 67 5. Consideration for Client Operation for DHCPv6 . . . . . . . . 9 68 6. Consideration for Server Operation . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . 15 76 1. Motivation 78 Dynamic Host Configuration Protocol [RFC2131] and [RFC3315] can be 79 used to configure various non-IP address type of parameters. These 80 parameters are required for normal operation of various services that 81 are offered over an IP network. 83 Broadcast and multicast service (BCMCS) is one such service that is 84 currently being standardized in various mobile wireless standard 85 bodies such as 3GPP, 3GPP2 and OMA. A description of the BCMCS, for 86 example, in 3GPP2 can be found in [BCMCS]. 88 While DHCP offers necessary mechanisms for device configuration, it 89 lacks the information elements required to configure a mobile device 90 to support BCMCS. This memo is an effort to define the extensions 91 needed for DHCP to provide necessary configuration information to a 92 mobile device in a BCMCS network. 94 DHCP is being used in 3GPP2, for example, to assist with the 95 discovery of the BCMCS Controller in a mobile operators IP network. 96 The BCMCS includes a controller component that is responsible for 97 managing the service via interaction with the users and other network 98 entities. 100 An overview of the 3GPP2 BCMCS architecture is given in the next 101 section. It provides enough information to understand the basics of 102 the 3GPP2 BCMCS operation. Readers are encouraged to find a more 103 detailed description in [BCMCS]. 105 As described in [BCMCS], the users of the service are required to 106 know the IPv4 or the IPv6 address of the controller entity so that 107 they can download all the necessary information about a desired 108 broadcast program. In a roaming environment static configuration of 109 the controller's IP address becomes unrealistic. Therefore, DHCP is 110 considered to be a method to dynamically configure the controller's 111 IP address or the fully qualified domain name of the controller in 112 the 3G wireless networks. 114 In order to allow the users to discover the broadcast controllers, 115 the clients request for appropriate option codes from the DHCP 116 servers using Parameter Request List option. The DHCP servers need 117 to return the corresponding configuration options that carry either 118 broadcast and multicast service controller's IP address or fully 119 qualified domain name based on configuration. The motivation for 120 this document is to define the necessary options and option codes. 122 2. Overview of the 3GPP2 BCMCS Network 124 The Broadcast and Multicast Service architecture in a 3G wireless 125 network such as 3GPP2 has the following model: 127 +------------+ +--------+ 128 | | | | 129 | Controller | | DHCP | 130 | | | Server | 131 +------------+ +--------+ 132 ^ 133 Control| 134 Info| 135 | 136 | 137 V 138 +----+ +------------+ +------------+ 139 | | | | | | 140 | MN/| bearer | Radio | | Broadcast | 141 |User|<-------| Access |<---| Content | 142 | | | Network | | Server | 143 +----+ +------------+ +------------+ 145 Note that this figure is shown here for broad understanding of how 146 Broadcast and Multicast service works in a 3G mobile wireless IP 147 network. The network elements except MN/user and the DHCP server are 148 not relevant to the text in this document. 150 The user interacts with the Controller to request for 151 broadcast/multicast program information from the network (e.g., 152 scheduled time, multicast IP address, port numbers). The User may 153 also be authenticated by the Controller while downloading the 154 relevant program security related information (such as encryption 155 key). These interactions happen via HTTP and XML. There may be more 156 than one controller in the network. The user should discover the 157 appropriate controller to request the relevant program information. 158 For details of Broadcast and Multicast Service operation in 3GPP2, 159 see [BCMCS]. 161 3. Terminology 163 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 165 this document are to be interpreted as described in RFC 2119. 167 4. Broadcast Service Controller Options 169 This section defines the configuration option for the controller of 170 Broadcast Service. The Configuration Option contains the IPv4 171 address or of the IPv4 address or the fully qualified domain names of 172 the broadcast service controller. 174 4.1 Broadcast Service Controller Domain Name List Option for DHCP 176 The option MAY contain multiple domain names, but these domain names 177 SHOULD be used to construct SRV lookups as specified in [BCMCS], 178 rather than querying for different A records. The client MUST try 179 the records in the order listed, applying the mechanism described in 180 [BCMCS] for each entry. The client only resolves the subsequent 181 domain names if attempts to contact the first one failed or yielded 182 no common transport protocols between the client and the controller 183 or denote a domain administratively prohibited by client's policy. 185 Use of multiple domain names is not meant to replace the SRV records, 186 but rather to allow a single DHCP server to indicate the broadcast 187 controllers in the access provider's network. 189 Clients MUST support compression according to the encoding in Section 190 4.1.4 of "Domain Names - Implementation And Specification [RFC1035]. 192 Since the domain names are supposed to be different domains, 193 compression will likely have little effect, however. If the length 194 of the domain list exceeds the maximum permissible within a single 195 option (254 octets), then the domain list MUST be represented in the 196 DHCP message as specified in [RFC3396] . 198 The DHCP option for this encoding has the following format: 200 Code Len FQDN(s) of Broadcast Controller 201 +-----+-----+-----+-----+-----+-----+-----+-- 202 | TBD | n | s1 | s2 | s3 | s4 | s5 | ... 203 +-----+-----+-----+-----+-----+-----+-----+-- 205 An example case when two controller domain names e.g. 206 bcmc1.carrier1.com, bcmc2.carrier1.com are returned without compression will be: 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 |TBD|38 | 5 |'b'|'c'|'m'|'c'|'1'| 8 |'c'|'a'|'r'|'r'|'i'|'e'|'r'| 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 212 |'1'| 3 |'c'|'o'|'m'| 5 |'b'|'c'|'m'|'c'|'2'| 8 |'c'|'a'|'r'|'r'| 213 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 +---+---+---+---+---+---+---+---+ 215 |'i'|'e'|'r'|'1'| 3 |'c'|'o'|'m'| 216 +---+---+---+---+---+---+---+---+ 218 4.2 Broadcast Service Controller Domain Name List Option for DHCPv6 220 The option length is followed by a sequence of labels, encoded 221 according to Section 3.1 of RFC 1035 [5]. 223 The option MAY contain multiple domain names, but these domain names 224 SHOULD be used to construct SRV lookups as specified in [BCMCS], 225 rather than querying for different A records. The client MUST try 226 the records in the order listed, applying the mechanism described in 227 [BCMCS] for each entry. The client only resolves the subsequent 228 domain names if attempts to contact the first one failed or yielded 229 no common transport protocols between the client and the controller 230 or denote a domain administratively prohibited by client's policy. 231 Use of multiple domain names is not meant to replace the SRV records, 232 but rather to allow a single DHCPv6 server to indicate the broadcast 233 controllers in the access provider's network. 235 The DHCPv6 option for Boradcast Service Controller Domain Names has 236 the format shown below. 238 option-code: OPTION_BCMCS_SERVER_D (TBD) 240 option-length: Length of the 'Broadcast Control Server Domain Name 241 List' field in octets; variable. 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_BCMCS_SERVER_D | option-length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Broadcast Control Domain Name List | 249 | ... | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 4.3 Broadcast Service Controller IPv4 Address Option 254 If the 'enc' byte has a value of 1, the encoding byte is followed by 255 a list of IPv4 addresses indicating broadcast controller IPv4 256 addresses. The controllers MUST be listed in order of preference. 257 Its minimum length is 5, and the length MUST be a multiple of 4 plus 258 one. The DHCP option for this encoding has the following format: 260 Code Len Address 1 Address 2 261 +-----+-----+-----+-----+-----+-----+-----+-- 262 | TBD | n | a1 | a2 | a3 | a4 | a1 | ... 263 +-----+-----+-----+-----+-----+-----+-----+-- 265 4.4 Broadcast Service Controller IPv6 Address Option 267 This DHCPv6 option MUST carry one or more 128-bit IPv6 address(es) of 268 the Broadcast Service Controller in a operators network. 270 option-code: OPTION_BCMCS_SERVER_A (TBD) 272 option-length: Length of the 'Broadcast Control Server IPv6 address' 273 field in octets; variable. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | OPTION_BCMCS_SERVER_A | option-length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 | Broadcast Control server-1 address (IPv6 address) | 282 | | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 | Broadcast Control server-2 address (IPv6 address) | 287 | | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | ... | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 5. Consideration for Client Operation for DHCPv6 295 A client MAY request either or both of the Broadcast Service 296 Controller Domain Name List and the IPv6 Address options in the 297 Options Request Option (ORO) as described in [RFC3315]. 299 If a client receives both the Broadcast Service Controller Domain 300 Name List and IPv6 Address options, it SHOULD use the Domain Name 301 List option. In this case, the client MAY use the Broadcast Service 302 Controller IPv6 Address option only if, no server in the Broadcast 303 Service Controller Domain Name List can be resolved or reached. 305 6. Consideration for Server Operation 307 A server MAY send a client either the Broadcast Service Controller 308 Domain Name List Option or the Broadcast Service Controller IPv6 309 Address/IPv4 Address options if the server is configured to do so. 311 In case of DHCPv6, If a client requests both options and the server 312 is configured with both types of information, the server MAY send the 313 client only one of these options if it is configured to do so. In 314 this case the server SHOULD send the Broadcast Service Controller 315 Domain Name List option. 317 A server configured with the Broadcast Service Controller IPv6 318 Address information MUST send a client the Broadcast Service 319 Controller IPv6 Address option if that client requested only the 320 Broadcast Service Controller IPv6 address option and not the 321 Broadcast Service Controller Domain Name List option in the ORO 322 [RFC3315]. 324 If a client requests for the Broadcast Service Controller IPv6 option 325 and the Server is configured only with the Domain Names, the Server 326 MUST return the Domain Names List and vice versa. 328 The following table summarizes the server's response for DHCPv6: 330 Client sends in ORO Domain Name List IPv6 Address List 331 __________________________________________________________________ 333 Neither option SHOULD MAY 334 Domain Name List MUST MAY 335 IPv6 Address MAY MUST 336 Both options SHOULD MAY 338 7. Security Considerations 340 The security considerations in the base DHCP specs [RFC2131] and 341 [RFC3315] apply. An attacker may change information of the Broadcast 342 Service Controller in packets that are in-tranist from DHCP server to 343 the MN, if integrity protection is not in place. In that event, the 344 user of the Broadcast service may be diverted to a rogue broadcast 345 service controller. In the absence of a mutual authentication 346 procedure between MN and the Broadcast controller, the MN may receive 347 wrong or fraudulent information about Broadcast Service. 349 8. IANA Considerations 351 The option code for Broadcast Service Controller options MUST be 352 assigned by IANA. 354 9. Acknowledgements 356 Thanks to the following indivduals for their review and constructive 357 comments during the development of this document: 359 AC Mahendran, Jun Wang, Raymond Hsu, Jayshree Bharatia, Ralph Droms, 360 Ted Lemon, Bernie Volz. 362 10 Normative References 364 [BCMCS] 3GPP2, www.3gpp2.org, "X.S0022, Broadcast and Multicast 365 Service in cdma2000 Wireless IP Network.", February 2005. 367 [RFC1035] Mockapetris, P., "Domain names - implementation and 368 specification", STD 13, RFC 1035, November 1987. 370 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 371 2131, March 1997. 373 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 374 M. Carney, "Dynamic Host Configuration Protocol for IPv6 375 (DHCPv6)", RFC 3315, July 2003. 377 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 378 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 379 November 2002. 381 Authors' Addresses 383 Kuntal Chowdhury 384 Starent Networks 385 30 International Place 386 Tewksbury, MA 01876 387 US 389 Phone: +1 214-550-1416 390 EMail: kchowdhury@starentnetworks.com 392 Parviz Yegani 393 Cisco Systems 394 3625 Cisco Way 395 San Jose, CA 95134 396 US 398 Phone: +1 408-832-5729 399 EMail: pyegani@cisco.com 400 Lila Madour 401 Ericsson 402 8400, Decarie Blvd 403 Town of Mount Royal, Quebec H4P 2N2 404 CANADA 406 Phone: +1 514-345-7900 407 EMail: Lila.Madour@ericsson.com 409 Intellectual Property Statement 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at 431 ietf-ipr@ietf.org. 433 Disclaimer of Validity 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 438 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 439 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 440 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 Copyright Statement 445 Copyright (C) The Internet Society (2005). This document is subject 446 to the rights, licenses and restrictions contained in BCP 78, and 447 except as set forth therein, the authors retain all their rights. 449 Acknowledgment 451 Funding for the RFC Editor function is currently provided by the 452 Internet Society.