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]