Internet DRAFT - draft-mrugalski-dhc-dhcpv6-suboptions
draft-mrugalski-dhc-dhcpv6-suboptions
Network Working Group T. Mrugalski
Internet-Draft ISC
Updates: 3315 (if approved) March 29, 2012
Intended status: Standards Track
Expires: September 30, 2012
Requesting Suboptions in DHCPv6
draft-mrugalski-dhc-dhcpv6-suboptions-04
Abstract
DHCPv6 clients may use Option Request Option (ORO) defined in RFC3315
[RFC3315] to specify, which options they would like to have
configured by DHCPv6 servers. Clients may also be interested in
specific options that do not appear in DHCPv6 message directly (top-
level options), but rather as nested options or sub-options (i.e.
options conveyed within other options). This document clarifies how
to use already defined ORO to request sub-options. It also defines
new Option Exclude Option (OXO) for cases, when client does not want
requested options to appear within specific options. This document
updates RFC3315 (if approved).
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 30, 2012.
Copyright Notice
Mrugalski Expires September 30, 2012 [Page 1]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Suboption Request Procedure . . . . . . . . . . . . . . . . . . 3
4. Option Exclude Option . . . . . . . . . . . . . . . . . . . . . 4
5. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 5
7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Mrugalski Expires September 30, 2012 [Page 2]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
1. Introduction
There are 2 ways a DHCPv6 client can inform a server about its intent
to have an option configured. The first (mandatory) way is to send
Option Request Option (ORO), defined in [RFC3315]. The second way
(optional, can be used as an addition to the first method) is to send
the actual requested option to provide hints to a server.
Clients may also be interested in receiving specific sub-options
(i.e. options that do not appear in DHCPv6 messages directly, but
rather within other options). Unfortunately, there is no clear way
for clients to request such sub-options. [RFC3315] does not provide
any guidance regarding such problem. This document clarifies how
clients should request sub-options.
2. Terminology
This section defines terms used in this document.
Option - Any DHCPv6 Option, defined according to format specified in
[RFC3315]. Option may appear in DHCPv6 message directly or within
other options.
Top-Level Option - an option that appears in DHCPv6 directly. Most
existing options are top-level options.
Sub-Option - An option that appears not as top-level option, but
rather within other option. An example of such option is IAADDR that
may only appear within IA_NA or IA_TA options. Sub-options are
sometimes referred to as nested options.
Scope - Any place (message or option) that is allowed to convey
DHCPv6 options. Examples of scope are top-level (options conveyed
directly within DHCPv6 message), IA_NA (options conveyed within
specific instance of IA_NA option), or IA_PD (options conveyed within
specific instance of IA_PD option). Each instance of an option that
can convey sub-options is a separate scope. For example, if a
message includes two IA_NA options, there are 3 scopes: top-level,
ia_na1 and ia_na2.
3. Suboption Request Procedure
Clients that want specific sub-option provided by the server, MUST
include ORO within message directly (as they do for normal, top-level
options) and include option codes for options that are expected to
appear in message directly (top-level options) and within other
Mrugalski Expires September 30, 2012 [Page 3]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
options (sub-options) as well. The section 22.7 of [RFC3315] still
applies, but this document clarifies that sub-options can be
requested that way as well.
Client that expects requested options to appear only in some option
instances, SHOULD include Option Exclude Option (OXO) within scope
where it does not want to receive specific options.
Client MAY include several instances of ORO, one for each scope.
Client MUST NOT include more than one ORO in each scope.
Discussion: The following approach has the benefit of backward
compatibility. Server that does not support OXO will just assign
requested suboptions in every suboption. Furthermore it is envisaged
that requesting sub-options in only some scope, but not others will
be relatively rare and in most cases clients will want to get
specific option in every scope that requested option is valid for.
4. Option Exclude Option
This option is sent by a client to inform a server that it doesn't
want to receive specific option within a scope OXO is included in.
Clients SHOULD send OXO only if it requested a given option in ORO,
but does not want to receive requested option in a given scope.
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_OXO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| excluded-option-code-1 | excluded-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Option Exclude Option
o option-code: OPTION_OXO (TBD)
o option-length: (number of excluded options) x 2
o excluded-option-code: one or more two octet wide fields that
specify option codes that are excluded in this particular scope.
Mrugalski Expires September 30, 2012 [Page 4]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
5. Justification
As DHCPv6 protocol evolves and continues to be used to configure
increasingly complex features, number of nested options will
increase. To avoid each new document repeating the same sub-option
request procedure, it seems reasonable to define such uniform
procedure now. Even worse, such documents may propose different ways
of requesting different options. This would considerably complicate
server implementations.
Another alternative possible approach would be to simply use ORO as
it is already defined. Client could simply include single instance
of ORO to express desire to receive specific suboptions, without
using OXO. Several existing server implementations deal with all
options in an uniform way. For example, in case when client
requestes two prefixes (sends two IA_PD options), but expects only
one of those prefixes to have PD_EXCLUDE option. Without OXO, such
flexibility is not possible.
6. DHCPv6 Client Behavior
A client that is interested in specific suboptions SHOULD send ORO
requesting both top-level options and sub-options.
If a client wants to receive specific suboptions only in some
options, it should send OXO within options that does not want to
receive excluded options in.
A client MUST NOT send OXO in message directly.
7. DHCPv6 Server Behavior
Server processes the message received from client in a regular way,
as explained in [RFC3315]. The list in ORO includes both top-level
options and sub-options as well. Server that supports OXO SHOULD NOT
include requested suboptions within scopes that excludes given
option.
8. IANA Considerations
IANA is kindly requested to allocate DHCPv6 option code TBD to the
OPTION_OXO. This value should be added to the DHCPv6 option code
space defined in Section 24.3 of [RFC3315].
Mrugalski Expires September 30, 2012 [Page 5]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
9. Security Considerations
TBD
10. Acknowledgements
Author would like to thank Bernie Volz, Jouni Korhonen, Ole Troan and
Ted Lemon for their insightful comments.
This work has been partially supported by Department of Computer
Communications (Gdansk University of Technology) and by the Polish
Ministry of Science and Higher Education under the European Regional
Development Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future
Internet Engineering Project).
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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.
Author's Address
Tomasz Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com
Mrugalski Expires September 30, 2012 [Page 6]
