Network Working Group T. Mrugalski Internet-Draft ISC Intended status: Standards Track March 8, 2011 Expires: September 9, 2011 Requesting Suboptions in DHCPv6 draft-mrugalski-dhc-dhcpv6-suboptions-00 Abstract DHCPv6 clients may use Option Request Option (ORO) to specify, which options they would like to get 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 a compounds of other options (suboptions). This document defines way of using existing ORO to request for specific suboptions. 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 9, 2011. Copyright Notice Copyright (c) 2011 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 Mrugalski Expires September 9, 2011 [Page 1] Internet-Draft Requesting Suboptions in DHCPv6 March 2011 (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. Requesting Suboptions . . . . . . . . . . . . . . . . . . . . . 3 3. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 3 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 8. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Mrugalski Expires September 9, 2011 [Page 2] Internet-Draft Requesting Suboptions in DHCPv6 March 2011 1. Introduction There are 2 ways DHCPv6 client can inform a server about its intent to have an option configured. The first (mandatory) way is to send ORO. The second way (optional, can be used as an addition to the first one) is to send the actual requested option to provide hints for server. Unfortunately, this only solves the problem of requesting top-level options. Clients may also be interested in receiving specific sub-options (i.e. options that do not appear in DHCPv6 messages directly, but rather as components in other options). Unfortunately, this is no clear way for clients to request such sub-options. [RFC3315] does not provide any guidance regarding such problem. 2. Requesting Suboptions Clients that want specific suboptions provided by the server, include ORO in the top-level option that requested option is expected in. 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 single FOO option code. 3. Justification Proposed approach allows clients to limit the amount of information parameters servers will send. This avoids larger than necessary DHCPv6 messages. With complex configuration parameters, like [I-D.ietf-mif-dhcpv6-route-option], the amount of available additional information may be significant. It was suggested that clients may use top-level 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 cause server to misplace requested options (i.e. to place it as top-levle option rather than suboption). Avoiding such pitfalls, would complicate server implementation significantly, as server would have to be configured with extra information regarding each option (where does specific option is supposed to appear - top level or as suboption). 4. DHCPv6 Client Behavior Client includes ORO in each option that it would like to receive suboptions in. For example, if client wants to receive suboption FOO Mrugalski Expires September 9, 2011 [Page 3] Internet-Draft Requesting Suboptions in DHCPv6 March 2011 in IA_NA option, it SHOULD transmit IA_NA that contains a single ORO list. 5. DHCPv6 Server Behavior Server processes the whole client message in a regular way, as explained in [RFC3315]. For each option that is allowed to have suboptions, server checks if there is ORO present within. Each returning top-level option, server populates its response with options specified in said ORO. 6. IANA Considerations IANA is not requested to take any actions regarding this document. 7. Security Considerations TBD 8. Normative References [I-D.ietf-mif-dhcpv6-route-option] Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 Route Option", draft-ietf-mif-dhcpv6-route-option-00 (work in progress), January 2011. [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 Phone: +48 698 088 272 Email: tomasz.mrugalski@eti.pg.gda.pl Mrugalski Expires September 9, 2011 [Page 4]