idnits 2.17.1 draft-chowdhury-dhc-bcmcv4-option-01.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 296. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 312), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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 152: '... The option MAY contain multiple dom...' RFC 2119 keyword, line 153: '... SHOULD be used to construct SRV lookups as specified in [BCMCS],...' RFC 2119 keyword, line 154: '...ferent A records. The client MUST try...' RFC 2119 keyword, line 165: '... Clients MUST support compression ac...' RFC 2119 keyword, line 171: '... the domain list MUST be represented i...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 176 has weird spacing: '...de Len enc ...' == Line 202 has weird spacing: '...e Len enc ...' -- 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 (August 17, 2004) is 7191 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BCMCS' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury 3 Internet-Draft Nortel Networks 4 Expires: February 15, 2005 P. Yegani 5 Cisco Systems 6 L. Madour 7 Ericsson 8 August 17, 2004 10 DHCPv4 Options for Broadcast and Multicast Control Servers 11 draft-chowdhury-dhc-bcmcv4-option-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document defines new options for Broadcast and Multicast Service 45 controller discovery in an IP network. Broadcast service is being 46 developed for 3G wireless networks. Users of the service interact 47 with a controller in the network to derive informations that are 48 required to receive broadcast service. Dynamic Host Configuration 49 Protocol can be used to configure the controller IPv4 addresses or 50 fully qualified domain names in the user's devices. This document 51 defines the related options and option codes. 53 Table of Contents 55 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Broadcast Service Controller Options . . . . . . . . . . . . . 6 59 4.1 Broadcast Service Controller Domain Name list . . . . . . 6 60 4.2 Broadcast Service Controller IPv4 address option . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . 12 68 1. Motivation 70 Dynamic Host Configuration Protocol can be used to configure various 71 non-IP address type of parameters. These parameters are required for 72 normal operation of various services that are offered over an IP 73 network. 75 In 3G wirelesss network standards body such as 3GPP2 (www.3gpp2.org), 76 broadcast and multicast service is being developed [BCMCS]. The 77 service includes a controller component that is responsible for 78 managing the service via interaction with the users and other network 79 entities. The users of the service are required to know the IPv4 80 address of the controller entity so that they can download all the 81 necessary information about a desired broadcast program. In a 82 roaming environment static configuration of the controller IPv4 83 address becomes unrealistic. Therefore, DHC is considered to be a 84 method to dynamically configure controller IPv4 address or the fully 85 qualified domain name of the controller in the 3G wireless networks. 87 In order to allow the users to discover the broadcast controllers, 88 the clients need to request for appropriate option codes from the DHC 89 servers using Option-Request-Option and the DHC servers need to 90 return corresponding configuration options that carry the broadcast 91 and multicast service controller IPv4 address or fully qualified 92 domain name. The motivation for this document is to define the 93 necessary options and option codes. 95 2. Overview 97 The Broadcast and Multicast Service architecture in a 3G wireless 98 network such as 3GPP2 has the following model: 100 +------------+ +--------+ 101 | | | | 102 | Controller | | DHCP | 103 | | | Server | 104 +------------+ +--------+ 105 | 106 Control| 107 Info| 108 | 109 | 110 V 111 +----+ +------------+ +------------+ 112 | | | | | | 113 | MN/| bearer | Radio | | Broadcast | 114 |User|<-------| Access |<---| Content | 115 | | | Network | | Server | 116 +----+ +------------+ +------------+ 118 Note that this inforamtive figure is shown here for broad 119 understanding of how Broadcast and Multicast service works in a 3G 120 radio network. The network elements except MN/user and the DHCP 121 server are not relevant to the text in this document. 123 The user interacts with the Controller to request for broadcast/ 124 multicast program information from the network (e.g., scheduled time, 125 multicast IP address, port numbers). The User may also be 126 authenticated by the Controller while downloading the relevant 127 program security related information (such as encryption key). These 128 interactions happen via HTTP and XML. For details of Broadcast and 129 Multicast Service operation in 3GPP2, see [BCMCS]. There may be more 130 than one controller in the network. The user should discover the 131 appropriate controller to request the relevant program information. 133 3. Terminology 135 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 137 this document are to be interpreted as described in RFC 2119. 139 4. Broadcast Service Controller Options 141 This section defines the configuration option for the controller of 142 Broadcast Service. The Configuration Option contains the IPv4 143 address or the fully qualified domain names of the broadcast service 144 controller. 146 4.1 Broadcast Service Controller Domain Name list 148 If the 'enc' byte has a value of 0, the encoding byte is followed by 149 a sequence of labels, encoded according to Section 3.1 of RFC 1035 150 [RFC1035]. 152 The option MAY contain multiple domain names, but these domain names 153 SHOULD be used to construct SRV lookups as specified in [BCMCS], 154 rather than querying for different A records. The client MUST try 155 the records in the order listed, applying the mechanism described in 156 [BCMCS] for each entry. The client only resolves the subsequent 157 domain names if attempts to contact the first one failed or yielded 158 no common transport protocols between the client and the controller 159 or denote a domain administratively prohibited by cleint's policy. 161 Use of multiple domain names is not meant to replace the SRV records, 162 but rather to allow a single DHCP server to indicate the broadcast 163 controllers in the access provider's network. 165 Clients MUST support compression according to the encoding in Section 166 4.1.4 of "Domain Names - Implementation And Specification [RFC1035]. 168 Since the domain names are supposed to be different domains, 169 compression will likely have little effect, however. If the length 170 of the domain list exceeds the maximum permissible within a single 171 option (254 octets), then the domain list MUST be represented in the 172 DHCP message as specified in [RFC3396] . 174 The DHCP option for this encoding has the following format: 176 Code Len enc FQDN(s) of Broadcast Controller 177 +-----+-----+-----+-----+-----+-----+-----+-----+-- 178 | TBD | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 179 +-----+-----+-----+-----+-----+-----+-----+-----+-- 181 An example case when two controller domain names e.g. 182 bcmc1.carrier1.com, bcmc2.carrier1.com are returned will be: 184 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 185 |TBD|38 | 5 |'b'|'c'|'m'|'c'|'1'| 8 |'c'|'a'|'r'|'r'|'i'|'e'|'r'| 186 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 187 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 188 |'1'| 3 |'c'|'o'|'m'| 5 |'b'|'c'|'m'|'c'|'2'| 8 |'c'|'a'|'r'|'r'| 189 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 190 +---+---+---+---+---+---+---+---+ 191 |'i'|'e'|'r'|'1'| 3 |'c'|'o'|'m'| 192 +---+---+---+---+---+---+---+---+ 194 4.2 Broadcast Service Controller IPv4 address option 196 If the 'enc' byte has a value of 1, the encoding byte is followed by 197 a list of IPv4 addresses indicating broadcast controller IPv4 198 addresses. The controllers MUST be listed in order of preference. 199 Its minimum length is 5, and the length MUST be a multiple of 4 plus 200 one. The DHCP option for this encoding has the following format: 202 Code Len enc Address 1 Address 2 203 +-----+-----+-----+-----+-----+-----+-----+-----+-- 204 | TBD | n | 1 | a1 | a2 | a3 | a4 | a1 | ... 205 +-----+-----+-----+-----+-----+-----+-----+-----+-- 207 5. Security Considerations 209 The security considerations in the base DHCPv6 spec [RFC2131] 210 applies. An attacker may change information of the Broadcast Service 211 Controller in packets that are in-tranist from DHCP server to the MN, 212 if integrity protection is not in place. In that event, the user of 213 the Broadcast service may be diverted to a rogue broadcast service 214 controller. In the absence of a mutual authentication procedure 215 between MN and the Broadcast controller, the MN may receive wrong or 216 fraudulent information about Broadcast Service. 218 6. IANA Considerations 220 The option codes for Broadcast Service Controller Domain Name list 221 and the IPv4 address Must be assigned by IANA. 223 7. Acknowledgements 225 Thanks to the follwoing indivduals for their review and constructive 226 comments during the development of this document: 228 AC Mahendran, Jun Wang, Raymond Hsu, Jayshree Bharatia, Ralph Dorms, 229 Ted Lemon. 231 8 Normative References 233 [BCMCS] 3GPP2, www.3gpp2.org, "X.P0022, Broadcast and Multicast 234 Service in cdma2000 Wireless IP Network.", October 2003. 236 [RFC1035] Mockapetris, P., "Domain names - implementation and 237 specification", STD 13, RFC 1035, November 1987. 239 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 240 2131, March 1997. 242 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 243 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 244 November 2002. 246 Authors' Addresses 248 Kuntal Chowdhury 249 Nortel Networks 250 2221 Lakeside Blvd. 251 Richardson, TX 75082 252 US 254 Phone: +1 972-685-7788 255 EMail: chowdury@nortelnetworks.com 257 Parviz Yegani 258 Cisco Systems 259 3625 Cisco Way 260 San Jose, CA 95134 261 US 263 Phone: +1 408-832-5729 264 EMail: pyegani@cisco.com 265 Lila Madour 266 Ericsson 267 8400, Decarie Blvd 268 Town of Mount Royal, Quebec H4P 2N2 269 CANADA 271 Phone: +1 514-345-7900 272 EMail: Lila.Madour@ericsson.com 274 Intellectual Property Statement 276 The IETF takes no position regarding the validity or scope of any 277 Intellectual Property Rights or other rights that might be claimed to 278 pertain to the implementation or use of the technology described in 279 this document or the extent to which any license under such rights 280 might or might not be available; nor does it represent that it has 281 made any independent effort to identify any such rights. Information 282 on the procedures with respect to rights in RFC documents can be 283 found in BCP 78 and BCP 79. 285 Copies of IPR disclosures made to the IETF Secretariat and any 286 assurances of licenses to be made available, or the result of an 287 attempt made to obtain a general license or permission for the use of 288 such proprietary rights by implementers or users of this 289 specification can be obtained from the IETF on-line IPR repository at 290 http://www.ietf.org/ipr. 292 The IETF invites any interested party to bring to its attention any 293 copyrights, patents or patent applications, or other proprietary 294 rights that may cover technology that may be required to implement 295 this standard. Please address the information to the IETF at 296 ietf-ipr@ietf.org. 298 Disclaimer of Validity 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 303 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 304 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 305 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 308 Copyright Statement 310 Copyright (C) The Internet Society (2004). This document is subject 311 to the rights, licenses and restrictions contained in BCP 78, and 312 except as set forth therein, the authors retain all their rights. 314 Acknowledgment 316 Funding for the RFC Editor function is currently provided by the 317 Internet Society.