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]