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]