Requesting Suboptions in DHCPv6

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 . 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. does not provide any guidance regarding such problem. This document clarifies how clients should request sub-options.

This section defines terms used in this document. Option - Any DHCPv6 Option, defined according to format specified in . 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.

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 options (sub-options) as well. The section 22.7 of 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.

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.

option-code: OPTION_OXO (TBD) option-length: (number of excluded options) x 2 excluded-option-code: one or more two octet wide fields that specify option codes that are excluded in this particular scope.

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.

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.

Server processes the message received from client in a regular way, as explained in . 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.

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 .

TBD

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).