idnits 2.17.1 draft-ietf-dhc-bcmcv6-option-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 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. ** 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 : ---------------------------------------------------------------------------- ** 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 207: '...is DHCPv6 option MUST carry one or mor...' RFC 2119 keyword, line 235: '... A client MAY request either or both...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 305 has weird spacing: '...Service in cd...' -- 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 (December 27, 2004) is 7060 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 174 == Unused Reference: 'RFC1035' is defined on line 307, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BCMCS' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 7 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: June 27, 2005 P. Yegani 5 Cisco Systems 6 L. Madour 7 Ericsson 8 December 27, 2004 10 DHCPv6 Options for Broadcast and Multicast Control Servers 11 draft-ietf-dhc-bcmcv6-option-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 June 27, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document defines new options for Broadcast and Multicast Service 47 controller discovery in an IP network. Broadcast and Multicast 48 service over 3G wireless networks are being developed at the time of 49 writing this document. Users of this service interact with a 50 controller in the network to derive informations that are required to 51 receive broadcast service. Dynamic Host Configuration Protocol can 52 be used to configure the controller IPv6 addresses in the user's 53 devices. This document 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 . . . 6 62 4.2 Broadcast Service Controller IPv6 address option . . . . . 6 63 5. Consideration for Client Operation . . . . . . . . . . . . . . 8 64 6. Consideration for Server Operation . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 70 Intellectual Property and Copyright Statements . . . . . . . . 14 72 1. Motivation 74 Dynamic Host Configuration Protocol [RFC3315] can be used to 75 configure various non-IP address type of parameters. These 76 parameters are required for normal operation of various services that 77 are offered over an IP network. 79 Broadcast and multicast service (BCMCS) is one such service that is 80 currently being standardized in various mobile wireless standard 81 bodies such as 3GPP, 3GPP2 and OMA. A description of the BCMCS, for 82 example, in 3GPP2 can be found in [BCMCS]. 84 While DHCP offers necessary mechanisms for device configuration, it 85 lacks the information elements required to configure a mobile device 86 to support BCMCS. 88 This memo is an effort to define the extensions needed for DHCP to 89 provide necessary configuration information to a mobile device in a 90 BCMCS network. 92 DHCP is being used in 3GPP2, for example, to assist with the 93 discovery of the BCMCS Controller in a mobile operators IP network. 94 The BCMCS includes a controller component that is responsible for 95 managing the service via interaction with the users and other network 96 entities. An overview of the 3GPP2 BCMCS architecture is given in 97 the next section. It provides enough information to understand the 98 basics of the 3GPP2 BCMCS operation. Readers are encouraged to find 99 a more detailed description in [BCMCS]. 101 As described in [BCMCS], the users of the service are required to 102 know the IPv6 address of the controller entity so that they can 103 download all the necessary information about a desired broadcast 104 program. In a roaming environment static configuration of the 105 controller IPv6 address becomes unrealistic. Therefore, DHCPv6 106 [RFC3315] is considered to be a method to dynamically configure 107 controller IPv6 address in the user's devices in the 3G wireless 108 networks. DHCPv6 can also be used to convey the fully qualified 109 domain name of the broadcast service controller to the user. The 110 user in turn makes DNS queries to obtain the IPv6 address of the 111 associated broadcast service controller. 113 In order to allow the users to discover the broadcast controllers, 114 the clients need to request for appropriate option codes from the 115 DHCPv6 servers using Option-Request-Option and the DHCPv6 servers 116 need to return corresponding configuration options that carry the 117 broadcast and multicast service controller IPv6 address and/or Domain 118 Name list. The motivation for this document is to define the 119 necessary options and option codes. 121 2. Overview of the 3GPP2 BCMCS Network 123 The Broadcast and Multicast Service architecture in a 3G wireless 124 network such as 3GPP2 has the following model: 126 +------------+ +--------+ 127 | | | | 128 | Controller | | DHCPv6 | 129 | | | Server | 130 +------------+ +--------+ 131 ^ 132 Control| 133 Info| 134 | 135 | 136 V 137 +----+ +------------+ +------------+ 138 | | | | | | 139 | MN/| bearer | Radio | | Broadcast | 140 |User|<-------| Access |<---| Content | 141 | | | Network | | Server | 142 +----+ +------------+ +------------+ 144 Note that this figure is shown here for broad understanding of how 145 Broadcast and Multicast service works in a 3G mobile wireless IP 146 network. The network elements except MN/user and the DHCPv6 server 147 are not relevant to the text in this document. 149 The user interacts with the Controller to request for broadcast/ 150 multicast program information from the network (e.g., scheduled time, 151 multicast IP address, port numbers). The User may also be 152 authenticated by the Controller while downloading the relevant 153 program security related information (such as encryption key). These 154 interactions happen via HTTP and XML. There may be more than one 155 controller in the network. The user should discover the appropriate 156 controller to request the relevant program information. For details 157 of Broadcast and Multicast Service operation in 3GPP2, see [BCMCS]. 159 3. Terminology 161 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in RFC 2119. 165 4. Broadcast Service Controller Options 167 This section defines the configuration options for the controller of 168 Broadcast Service. The options in the document are specified similar 169 to [RFC3319]. 171 4.1 Broadcast Service Controller Domain Name List option 173 The option length is followed by a sequence of labels, encoded 174 according to Section 3.1 of RFC 1035 [5]. 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. 184 Use of multiple domain names is not meant to replace the SRV records, 185 but rather to allow a single DHCPv6 server to indicate the broadcast 186 controllers in the access provider's network. 188 The DHCPv6 option for Boradcast Service Controller Domain Names has 189 the format shown below. 191 option-code: OPTION_BCMCS_SERVER_D (TBD) 193 option-length: Length of the 'Broadcast Control Server Domain Name 194 List' field in octets; variable. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | OPTION_BCMCS_SERVER_D | option-length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Broadcast Control Domain Name List | 202 | ... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 4.2 Broadcast Service Controller IPv6 address option 207 This DHCPv6 option MUST carry one or more 128-bit IPv6 address(es) of 208 the Broadcast Service Controller in a operators network. 210 option-code: OPTION_BCMCS_SERVER_A (TBD) 212 option-length: Length of the 'Broadcast Control Server IPv6 address' 213 field in octets; variable. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | OPTION_BCMCS_SERVER_A | option-length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 | Broadcast Control server-1 address (IPv6 address) | 222 | | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 | Broadcast Control server-2 address (IPv6 address) | 227 | | 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | ... | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 5. Consideration for Client Operation 235 A client MAY request either or both of the Broadcast Service 236 Controller Domain Name List and the IPv6 Address options in the 237 Options Request Option (ORO) as described in [RFC3315]. 239 If a client receives both the Broadcast Service Controller Domain 240 Name List and IPv6 Address options, it SHOULD use the Domain Name 241 List option. In this case, the client MAY use the Broadcast Service 242 Controller IPv6 Address option only if, no server in the Broadcast 243 Service Controller Domain Name List can be resolved or reached. 245 6. Consideration for Server Operation 247 A server MAY send a client one or both of the Broadcast Service 248 Controller Domain Name List and Broadcast Service Controller IPv6 249 Address options if the server is configured to do so. 251 If a client requests both options and the server is configured with 252 both types of information, the server MAY send the client only one of 253 these options if it is configured to do so. In this case the server 254 SHOULD send the Broadcast Service Controller Domain Name List option. 256 A server configured with the Broadcast Service Controller IPv6 257 Address information MUST send a client the Broadcast Service 258 Controller IPv6 Address option if that client requested only the 259 Broadcast Service Controller IPv6 address option and not the 260 Broadcast Service Controller Domain Name List option in the ORO 261 (RFC3315]). 263 If a client requests for the Broadcast Service Controller IPv6 option 264 and the Server is configured only with the Domain Names, the Server 265 MUST return the Domain Names List and vice versa. 267 The following table summarizes the server's response: 269 Client sends in ORO Domain Name List IPv6 Address List 270 __________________________________________________________________ 272 Neither option SHOULD MAY 273 Domain Name List MUST MAY 274 IPv6 Address MAY MUST 275 Both options SHOULD MAY 277 7. Security Considerations 279 The security considerations in the base DHCPv6 spec [RFC3315] 280 applies. An attacker may change information of the Broadcast Service 281 Controller in packets that are in-tranist from DHCPv6 server to the 282 MN, if integrity protection is not in place. In that event, the user 283 of the Broadcast service may be diverted to a rogue broadcast service 284 controller. In the absence of a mutual authentication procedure 285 between MN and the Broadcast controller, the MN may receive wrong or 286 fraudulent information about Broadcast Service. 288 8. IANA Considerations 290 The option codes OPTION_BCMCS_SERVER_A, OPTION_BCMCS_SERVER_D for 291 Broadcast Service Controller Domain Name list and IPv6 address 292 respectively Must be assigned by IANA. 294 9. Acknowledgements 296 Thanks to the following indivduals for their review and constructive 297 comments during the development of this document: 299 AC Mahendran, Jun Wang, Raymond Hsu, Jayshree Bharatia, Ralph Droms, 300 Bernie Volz. 302 10 Normative References 304 [BCMCS] 3GPP2, www.3gpp2.org, "X.S0022, Broadcast and Multicast 305 Service in cdma2000 Wireless IP Network.", February 2005. 307 [RFC1035] Mockapetris, P., "Domain names - implementation and 308 specification", STD 13, RFC 1035, November 1987. 310 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 311 M. Carney, "Dynamic Host Configuration Protocol for IPv6 312 (DHCPv6)", RFC 3315, July 2003. 314 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 315 Protocol (DHCPv6) Options for Session Initiation Protocol 316 (SIP) Servers", RFC 3319, July 2003. 318 Authors' Addresses 320 Kuntal Chowdhury 321 Starent Networks 322 2540 Coolwater Dr. 323 Plano, TX 75025 324 US 326 Phone: +1 214-550-1416 327 EMail: kchowdhury@starentnetworks.com 329 Parviz Yegani 330 Cisco Systems 331 3625 Cisco Way 332 San Jose, CA 95134 333 US 335 Phone: +1 408-832-5729 336 EMail: pyegani@cisco.com 337 Lila Madour 338 Ericsson 339 8400, Decarie Blvd 340 Town of Mount Royal, Quebec H4P 2N2 341 CANADA 343 Phone: +1 514-345-7900 344 EMail: Lila.Madour@ericsson.com 346 Intellectual Property Statement 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use of 360 such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org. 370 Disclaimer of Validity 372 This document and the information contained herein are provided on an 373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 375 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 376 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 377 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 380 Copyright Statement 382 Copyright (C) The Internet Society (2004). This document is subject 383 to the rights, licenses and restrictions contained in BCP 78, and 384 except as set forth therein, the authors retain all their rights. 386 Acknowledgment 388 Funding for the RFC Editor function is currently provided by the 389 Internet Society.