idnits 2.17.00 (12 Aug 2021) /tmp/idnits49401/draft-deng-dhc-service-identifiers-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3315]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 196: '...vices. A client MAY provide this opti...' RFC 2119 keyword, line 197: '...] interested in. A server MAY use the...' RFC 2119 keyword, line 201: '... MUST include this option in the par...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 3, 2008) is 4940 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) == Unused Reference: 'RFC1700' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 255, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Deng 3 Internet-Draft H. Liu 4 Intended status: Standards Track China Mobile 5 Expires: May 7, 2009 B. Volz 6 Cisco Systems, Inc 7 November 3, 2008 9 Service Identfiers Option for DHCPv6 10 draft-deng-dhc-service-identifiers-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 7, 2009. 37 Abstract 39 This document describes a new option for DHCPv6 [RFC3315] that 40 provides a mechanism for specifying a list of service identifer which 41 this connection support or don't support. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Service Identifiers Supported Option . . . . . . . . . . . . . 4 47 3. Service Identifiers Unsupported Option . . . . . . . . . . . . 5 48 4. Option usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 50 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8 51 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 52 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 54 Intellectual Property and Copyright Statements . . . . . . . . . . 12 56 1. Introduction 58 With the various kind of promising wireless broadband access 59 technologies, there are more possbilities that mobile node could have 60 multiple connections which may provide different kind of service 61 available. 63 In some cases, the operator would like to let the mobile node to know 64 services are allowed or not allowed (not available) for the 65 connection. It may influence network routing, policy and quality of 66 service, et al. 68 There are several candidate protocols such as SLP, DNS(srv records) 69 which could be used for identifing the service available. User could 70 also just try to attempt the connection. If it works, Ok; If not, 71 service will be not available. This will happen anyway if the 72 'server' for a service is down or temporaily unreachable 74 This document propose a new option for DHCPv6 [RFC3315] that provides 75 a mechanism for specifying a list of service identifer which this 76 connection support or don't support. DHCP based mechanism make 77 client know whether to attempt a connection in the first place 78 comparing with SLP, DNS, and trial. 80 2. Service Identifiers Supported Option 82 Service which network supported means that it is OK to try that 83 service over the connection. The format of the Service Identifiers 84 Supported Option is as the below, the lifetime of the data for this 85 option is controlled by the t1 times or the 86 OPTION_INFORMATION_REFRESH_TIME (Information-Request/Reply). 88 0 1 2 3 89 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 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | option-code | option-length | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | length | Service Identifier | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | length | Service Identifier | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | | length | Service | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Identifier | 100 +-+-+-+-+-+-+-+-+ 102 Figure 1: Service Identifiers Supported Option 104 option-code: OPTION_SERVICE_SUPPORTED (TBD). 106 option-length: length of the "service identifier list" field in 107 octets. 109 length 111 length of the "service identifier" field in octets. For 112 example 'ims' will be 3, 'voip' will be 4, 'p2p' will be 3. 113 Sometime it need indicate which port number will be supported, 114 in such case ascii string will be used for it like the format 115 of 'length''ascii-string' such as '5''34212'. 117 Service Identifier 119 A variable length UTF-8 encoded service identifier string used 120 to identify the requested service. 'ims', 'voip' and 'p2p' are 121 valid examples of Service Identifiers. Some other protocol 122 identifier has been specified by 123 http://www.iana.org/protocols/. When it need indicate the port 124 number information, ascii string will be used for the format 125 like '34212'. 127 3. Service Identifiers Unsupported Option 129 Service which network unsupported means that it will not be able to 130 try that service over the connection. The format of the Service 131 Identifiers Unsupported Option is: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | option-code | option-length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | length | Service Identifier | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | length | Service Identifier | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | length | Service | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Identifier | 145 +-+-+-+-+-+-+-+-+ 147 Figure 2: Service Identifiers Unsupported Option 149 option-code: OPTION_SERVICE_UNSUPPORTED (TBD). 151 option-length: length of the "service identifier list" field in 152 octets. 154 length 156 length of the "service identifier" field in octets. For 157 example 'ims' will be 3, 'voip' will be 4, 'p2p' will be 3. 158 Sometime it need indicate which port number will be 159 unsupported, in such case ascii string will be used for it like 160 the format of 'length''ascii-string' such as '5''34212'. 162 Service Identifier 164 A variable length UTF-8 encoded service identifier string used 165 to identify the requested service. 'ims', 'voip' and 'p2p' are 166 valid examples of Service Identifiers. Some other protocol 167 identifier has been specified by 168 http://www.iana.org/protocols/. When it need indicate the port 169 number information, ascii string will be used for the format 170 like '34212'. 172 4. Option usage 174 There are various kinds of wireless broadband access technologies, 175 one mobile node may have multiple wireless cards, thus a subscriber 176 may choose different connections for different services. The 177 operators DHCPv6 server may provide a list of service identifiers 178 option. The mobile node will decide which service may be used with 179 which connection based on this advertisement of the dhcp option. 181 A mobile node that receives these options would need to remember 182 which services are available / are not available on each interface. 183 It may influence mobile node local routing policy or routing metrics. 184 if one service could be supported by both wireless link, local 185 routing policy will setup the priority for that service. if the 186 server advetise the Service Identifiers Supported Option with a 0 187 length list, it indicate that no service is allowed in this 188 connection. if the server advetise the Service Identifiers 189 Unsupported Option with a 0 length list, it indicate that all kinds 190 of service will be allowed in this connection. In the case of a 191 mobile node has no connection with a particular service? It may need 192 subscribe different service or connect with the network operator. 194 A mobile node could also provide this option with a list of service, 195 the server should use that to limits its response to just those 196 services. A client MAY provide this option with a list of the 197 services it is [and/or is not] interested in. A server MAY use the 198 client's provided option to limit what it places in the response to 199 the client. However, A server is not required to do this and may 200 just send back a configured list. Note that in any case the client 201 MUST include this option in the parameter request list (there is no 202 obligation for a server to return this option if it does not appear 203 in the ORO option). 205 5. Security Considerations 207 Basic security considerations in DHCP are described in section 23, 208 "Security Considerations" of RFC3315. 210 There is a possibility that a rogue DHCPv6 server could specify that 211 all service is unsupported which would prevent access. But rogue 212 DHCPv6 server can do a lots of other things like assign a bad IP 213 address or fake DNS servers, et. 215 6. IANA Consideration 217 This document defines two new DHCPv6 options, and IANA is requested 218 to assign the following new DHCPv6 Option Codes in the registry 219 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 221 OPTION_SERVICE_SUPPORTED 223 for the Service Identifier Supported Option. 225 OPTION_SERVICE_UNSUPPORTED 227 for the Service Identifier Unsupported Option. 229 New service identifier names are assigned through Standards Action, 230 as defined in RFC 5225. 232 'ims', 'voip', 'p2p' 234 for the service identifier of the IMS, VoIP, and P2P Internet 235 service. And IANA is requested to establish a registry for the 236 service identifier names. 238 7. Acknowledgements 240 Thanks for the comments and review by Ted Lemon, David Miles, Mark 241 Stapp, Shane Kerr, Jari Arkko, Ralph Droms. 243 8. Normative References 245 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 246 October 1994. 248 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 249 RFC 2131, March 1997. 251 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 252 and M. Carney, "Dynamic Host Configuration Protocol for 253 IPv6 (DHCPv6)", RFC 3315, July 2003. 255 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 256 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 257 May 2008. 259 Authors' Addresses 261 Hui Deng 262 China Mobile 263 53A,Xibianmennei Ave., 264 Xuanwu District, 265 Beijing 100053 266 China 268 Email: denghui02@gmail.com 270 Hong Liu 271 China Mobile 272 53A,Xibianmennei Ave., 273 Xuanwu District, 274 Beijing 100053 275 China 277 Email: liuhong@chinamobile.com 279 Bernie Volz 280 Cisco Systems, Inc 281 1414 Massachusetts Ave. 282 Boxborough MA 01719 283 USA 285 Email: volz@cisco.com 287 Full Copyright Statement 289 Copyright (C) The IETF Trust (2008). 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 298 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 299 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 300 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Intellectual Property 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org.