Requesting Suboptions in DHCPv6
draft-mrugalski-dhc-dhcpv6-suboptions-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Tomek Mrugalski | ||
| Last updated | 2012-03-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mrugalski-dhc-dhcpv6-suboptions-03
Network Working Group T. Mrugalski
Internet-Draft ISC
Updates: 3315 (if approved) March 12, 2012
Intended status: Standards Track
Expires: September 13, 2012
Requesting Suboptions in DHCPv6
draft-mrugalski-dhc-dhcpv6-suboptions-03
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 specific options within scopes
other than top-level and introduces new option that signals support
for per-option ORO. This document updates RFC3315.
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 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Mrugalski Expires September 13, 2012 [Page 1]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
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. Suboption Option Request Option . . . . . . . . . . . . . . . . 4
5. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 5
7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Mrugalski Expires September 13, 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).
3. Suboption Request Procedure
Clients that want specific sub-option provided by the server, MAY
include ORO within requested scope. However, many server
implementations may not support it. Therefore client SHOULD send
SUBOPT_ORO option code in ORO, when sending its message. If server
is configured to support per-option ORO, it will return SUBOPT_ORO
option. Presence of this option indicates that server supports per-
option ORO. In such case client SHOULD include ORO in sent options
Mrugalski Expires September 13, 2012 [Page 3]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
to request specific suboptions. For example, if client expects to
have suboption FOO configured in IA_NA, it should transmit IA_NA
option that contains ORO. This ORO should convey a FOO option code
and possibly other options requested within that scope.
Client that did not receive SUBOPT_ORO assumes that server does not
support per-option ORO and SHOULD NOT send ORO within other option
and limit itself to sending ORO in top level, as specified in Section
22.7 of [RFC3315].
Client MAY include several instances of ORO, one for each scope.
Client MUST NOT include more than one ORO in each scope.
Client MUST include ORO in sent messages directly as specified in
Section 22.7 of [RFC3315] to request top-level options.
4. Suboption Option Request Option
This option is returned by a server to inform client that it is able
to process ORO within other options. Server that supports per option
ORO MUST send this option if requested by client and MAY send it,
even when not requested.
Clients SHOULD request this option to discover if server is able to
process ORO sent within other options.
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_SUBOPT_ORO | option-length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Suboption Option Request Option
o option-code: OPTION_SUBOPT_ORO (TBD)
o option-length: 0
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
Mrugalski Expires September 13, 2012 [Page 4]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
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 include single instance of ORO
to express desire to receive specific suboptions. Several existing
server implementations deal with all options in an uniform way.
Using top-level ORO to request suboptions would possibly cause server
to misplace requested options (i.e. to place them as top-level option
rather than suboption). Avoiding such pitfalls, would complicate
server implementation, as servers would have to be configured with
extra information regarding each option (where does specific option
is supposed to appear - top level or as suboption). For example, in
case when client requested PD_EXCLUDE and DNS_SERVERS options, server
would have to handle each requested option differently and put one
option inside an IAPREFIX option, while the other option directly in
a message.
Using ORO as top-level option has the drawback of being global, i.e.
affecting all options. In certain situations, it may be useful to be
able to limit option requests to certain instances of an option. For
example, requesting router that needs two prefixes may request
PD_EXCLUDE only in first IA_PD option, but not in the second. Such
flexibility is not available when using only "classic" ORO.
6. DHCPv6 Client Behavior
A client that is interested in specific suboptions SHOULD request
SUBOPT_ORO option, when sending ORO in its SOLICIT, REBIND or
INFORMATION-REQUEST messages. Client MAY request SUBOPT_ORO in other
transmitted messages.
If a client receives SUBOPT_ORO option, then sending server supports
per-option ORO. In such case, an addition to standard behavior
defined in [RFC3315] client MAY include ORO in each option that it
would like to receive suboptions in. For example, if client wants to
receive suboption FOO in IA_NA option, it SHOULD transmit IA_NA
option that contains a single ORO with FOO option code.
A client SHOULD NOT send ORO within other options, if the server
didn't return SUBOPT_ORO option.
7. DHCPv6 Server Behavior
Server processes the message received from client in a regular way,
as explained in [RFC3315]. Server that supports per option ORO, MUST
Mrugalski Expires September 13, 2012 [Page 5]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
send SUBOPT_ORO option if requested by client and MAY send it, even
when not requested.
Server that supports this mechanism performs additional processing.
For each option that is allowed to have suboptions (i.e. for each
scope), server checks if there is ORO present. For each ORO present,
server appends requested options if it is configured to do so.
8. IANA Considerations
IANA is kindly requested to allocate DHCPv6 option code TBD to the
OPTION_SUBOPT_ORO. This value should be added to the DHCPv6 option
code space defined in Section 24.3 of [RFC3315].
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.
Mrugalski Expires September 13, 2012 [Page 6]
Internet-Draft Requesting Suboptions in DHCPv6 March 2012
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 13, 2012 [Page 7]