Network Working Group H. Deng Internet-Draft H. Liu Intended status: Standards Track China Mobile Expires: May 7, 2009 B. Volz Cisco Systems, Inc November 3, 2008 Service Identfiers Option for DHCPv6 draft-deng-dhc-service-identifiers-03 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 7, 2009. Deng, et al. Expires May 7, 2009 [Page 1] Internet-Draft Service Identifiers November 2008 Abstract This document describes a new option for DHCPv6 [RFC3315] that provides a mechanism for specifying a list of service identifer which this connection support or don't support. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Service Identifiers Supported Option . . . . . . . . . . . . . 4 3. Service Identifiers Unsupported Option . . . . . . . . . . . . 5 4. Option usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Deng, et al. Expires May 7, 2009 [Page 2] Internet-Draft Service Identifiers November 2008 1. Introduction With the various kind of promising wireless broadband access technologies, there are more possbilities that mobile node could have multiple connections which may provide different kind of service available. In some cases, the operator would like to let the mobile node to know services are allowed or not allowed (not available) for the connection. It may influence network routing, policy and quality of service, et al. There are several candidate protocols such as SLP, DNS(srv records) which could be used for identifing the service available. User could also just try to attempt the connection. If it works, Ok; If not, service will be not available. This will happen anyway if the 'server' for a service is down or temporaily unreachable This document propose a new option for DHCPv6 [RFC3315] that provides a mechanism for specifying a list of service identifer which this connection support or don't support. DHCP based mechanism make client know whether to attempt a connection in the first place comparing with SLP, DNS, and trial. Deng, et al. Expires May 7, 2009 [Page 3] Internet-Draft Service Identifiers November 2008 2. Service Identifiers Supported Option Service which network supported means that it is OK to try that service over the connection. The format of the Service Identifiers Supported Option is as the below, the lifetime of the data for this option is controlled by the t1 times or the OPTION_INFORMATION_REFRESH_TIME (Information-Request/Reply). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | Service Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | Service Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | length | Service | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+ Figure 1: Service Identifiers Supported Option option-code: OPTION_SERVICE_SUPPORTED (TBD). option-length: length of the "service identifier list" field in octets. length length of the "service identifier" field in octets. For example 'ims' will be 3, 'voip' will be 4, 'p2p' will be 3. Sometime it need indicate which port number will be supported, in such case ascii string will be used for it like the format of 'length''ascii-string' such as '5''34212'. Service Identifier A variable length UTF-8 encoded service identifier string used to identify the requested service. 'ims', 'voip' and 'p2p' are valid examples of Service Identifiers. Some other protocol identifier has been specified by http://www.iana.org/protocols/. When it need indicate the port number information, ascii string will be used for the format like '34212'. Deng, et al. Expires May 7, 2009 [Page 4] Internet-Draft Service Identifiers November 2008 3. Service Identifiers Unsupported Option Service which network unsupported means that it will not be able to try that service over the connection. The format of the Service Identifiers Unsupported Option is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | Service Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | Service Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | length | Service | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+ Figure 2: Service Identifiers Unsupported Option option-code: OPTION_SERVICE_UNSUPPORTED (TBD). option-length: length of the "service identifier list" field in octets. length length of the "service identifier" field in octets. For example 'ims' will be 3, 'voip' will be 4, 'p2p' will be 3. Sometime it need indicate which port number will be unsupported, in such case ascii string will be used for it like the format of 'length''ascii-string' such as '5''34212'. Service Identifier A variable length UTF-8 encoded service identifier string used to identify the requested service. 'ims', 'voip' and 'p2p' are valid examples of Service Identifiers. Some other protocol identifier has been specified by http://www.iana.org/protocols/. When it need indicate the port number information, ascii string will be used for the format like '34212'. Deng, et al. Expires May 7, 2009 [Page 5] Internet-Draft Service Identifiers November 2008 4. Option usage There are various kinds of wireless broadband access technologies, one mobile node may have multiple wireless cards, thus a subscriber may choose different connections for different services. The operators DHCPv6 server may provide a list of service identifiers option. The mobile node will decide which service may be used with which connection based on this advertisement of the dhcp option. A mobile node that receives these options would need to remember which services are available / are not available on each interface. It may influence mobile node local routing policy or routing metrics. if one service could be supported by both wireless link, local routing policy will setup the priority for that service. if the server advetise the Service Identifiers Supported Option with a 0 length list, it indicate that no service is allowed in this connection. if the server advetise the Service Identifiers Unsupported Option with a 0 length list, it indicate that all kinds of service will be allowed in this connection. In the case of a mobile node has no connection with a particular service? It may need subscribe different service or connect with the network operator. A mobile node could also provide this option with a list of service, the server should use that to limits its response to just those services. A client MAY provide this option with a list of the services it is [and/or is not] interested in. A server MAY use the client's provided option to limit what it places in the response to the client. However, A server is not required to do this and may just send back a configured list. Note that in any case the client MUST include this option in the parameter request list (there is no obligation for a server to return this option if it does not appear in the ORO option). Deng, et al. Expires May 7, 2009 [Page 6] Internet-Draft Service Identifiers November 2008 5. Security Considerations Basic security considerations in DHCP are described in section 23, "Security Considerations" of RFC3315. There is a possibility that a rogue DHCPv6 server could specify that all service is unsupported which would prevent access. But rogue DHCPv6 server can do a lots of other things like assign a bad IP address or fake DNS servers, et. Deng, et al. Expires May 7, 2009 [Page 7] Internet-Draft Service Identifiers November 2008 6. IANA Consideration This document defines two new DHCPv6 options, and IANA is requested to assign the following new DHCPv6 Option Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters: OPTION_SERVICE_SUPPORTED for the Service Identifier Supported Option. OPTION_SERVICE_UNSUPPORTED for the Service Identifier Unsupported Option. New service identifier names are assigned through Standards Action, as defined in RFC 5225. 'ims', 'voip', 'p2p' for the service identifier of the IMS, VoIP, and P2P Internet service. And IANA is requested to establish a registry for the service identifier names. Deng, et al. Expires May 7, 2009 [Page 8] Internet-Draft Service Identifiers November 2008 7. Acknowledgements Thanks for the comments and review by Ted Lemon, David Miles, Mark Stapp, Shane Kerr, Jari Arkko, Ralph Droms. Deng, et al. Expires May 7, 2009 [Page 9] Internet-Draft Service Identifiers November 2008 8. Normative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Deng, et al. Expires May 7, 2009 [Page 10] Internet-Draft Service Identifiers November 2008 Authors' Addresses Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Hong Liu China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: liuhong@chinamobile.com Bernie Volz Cisco Systems, Inc 1414 Massachusetts Ave. Boxborough MA 01719 USA Email: volz@cisco.com Deng, et al. Expires May 7, 2009 [Page 11] Internet-Draft Service Identifiers November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Deng, et al. Expires May 7, 2009 [Page 12]