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]