Requesting Suboptions in DHCPv6
draft-mrugalski-dhc-dhcpv6-suboptions-02

Network Working Group                                       T. Mrugalski
Internet-Draft                                                       ISC
Updates: 3315 (if approved)                             October 23, 2011
Intended status: Standards Track
Expires: April 25, 2012

                    Requesting Suboptions in DHCPv6
                draft-mrugalski-dhc-dhcpv6-suboptions-02

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.  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 April 25, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Mrugalski                Expires April 25, 2012                 [Page 1]
Internet-Draft       Requesting Suboptions in DHCPv6        October 2011

   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.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . . . . . 5
   6.  DHCPv6 Server Behavior  . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
     10.2.  Informative References . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Mrugalski                Expires April 25, 2012                 [Page 2]
Internet-Draft       Requesting Suboptions in DHCPv6        October 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
   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 option provided by the server, SHOULD
   include ORO within requested scope.  This ORO MUST include requested
   option type.  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.

Mrugalski                Expires April 25, 2012                 [Page 3]
Internet-Draft       Requesting Suboptions in DHCPv6        October 2011

   Client MAY include several instances of ORO, one for each scope.
   Client MUST NOT include more than one ORO in each scope.

   Discussion: Aforementioned simple procedure is easy to implement, but
   it does not cover all cases.  Therefore following extension may be
   taken into consideration.

   There are cases, when client does not transmit options for each scope
   it expects to receive.  Therefore client may not be able to follow
   procedure defined in previous section.  In such case client SHOULD
   include ORO option in the inner-most scope that is closest to the
   location of desired option.  For example, [I-D.ietf-dhc-pd-exclude]
   defines PD_EXCLUDE option that may be placed within IAPREFIX option,
   that in turn may be placed within IA_PD option that finally is placed
   in a DHCPv6 message.  Client would like to receive PD_EXCLUDE option,
   but it in certain cases may choose to not send IAPREFIX within IA_PD,
   just empty IA_PD (e.g. in SOLICIT message).  In such cases, client
   should include ORO within IA_PD, even though requested PD_EXCLUDE
   option will not be coveyed directly within IA_PD, but rather
   indirectly - within IAPREFIX that will be included in IA_PD.

   Example: TODO (provide example of client requesting top-level and
   nested option, e.g.  DNS_SERVER and PD_EXCLUDE).

4.  Justification

   As DHCPv6 protocol 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 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 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 significantly, 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.

Mrugalski                Expires April 25, 2012                 [Page 4]
Internet-Draft       Requesting Suboptions in DHCPv6        October 2011

   Discussion: (The following section should probably be removed if this
   draft is published).  Currently there are several existing drafts
   that could benefit from this proposal:

   1.  [I-D.ietf-dhc-pd-exclude] defines PD_EXCLUDE option that is
       conveyed within IAPREFIX (that in turn is conveyed in IA_PD).
       Currently this draft calls for requesting PD_EXCLUDE in top-level
       ORO.

   2.  [I-D.ietf-mif-dhcpv6-route-option] defines a way to convey basic
       information about routers and prefixes available via those
       routers.  It defines NEXT_HOP option that contains RT_PREFIX
       options.  Each of those defined options may possibly convey
       additional, not yet defined routing related options, e.g.  MTU,
       flow label, QoS parameters or many others.

   3.  There is at least one existing DHCPv6 implementation (Dibbler)
       that currently requests extra sub-options using top-level ORO.

   4.  A draft about configuring 4rd rules over DHCPv6
       [I-D.mrugalski-dhc-dhcpv6-4rd] defines nested DHCPv6 options.
       Although this is early phase of the work and its layout will
       likely change (there is ongoing work within Softwires group on
       MAP that will likely include this work), the generic high level
       approach will remain similar. 4rd and MAP architectures require
       configuring one or more mapping rules.  Each mapping rule
       consists of several mandatory (Domain IPv6 Prefix, Domain 4rd/MAP
       Prefix, Length of CE IPv6 Prefix) and one optional (Domain IPv6
       suffix) parameters.  As all those options are dedicated to
       configuration of different aspects of the same feature (4rd or
       MAP), there's distinct possibility that it will be defined as
       several options nested within a single grouping option.  Although
       this architecture is a new proposal, there may be new extensions
       proposed, similar to extensions to DS-Lite architecture.  This
       may result in potential new options related to 4rd/MAP.

5.  DHCPv6 Client Behavior

   In addition to standard behavior defined in [RFC3315] client SHOULD
   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.

Mrugalski                Expires April 25, 2012                 [Page 5]
Internet-Draft       Requesting Suboptions in DHCPv6        October 2011

6.  DHCPv6 Server Behavior

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

7.  IANA Considerations

   IANA is not requested to take any actions regarding this document.

8.  Security Considerations

   TBD

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

10.  References

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

10.2.  Informative References

   [I-D.ietf-dhc-pd-exclude]
              Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", draft-ietf-dhc-pd-exclude-03 (work in

Mrugalski                Expires April 25, 2012                 [Page 6]
Internet-Draft       Requesting Suboptions in DHCPv6        October 2011

              progress), August 2011.

   [I-D.ietf-mif-dhcpv6-route-option]
              Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
              Route Options", draft-ietf-mif-dhcpv6-route-option-03
              (work in progress), September 2011.

   [I-D.mrugalski-dhc-dhcpv6-4rd]
              Mrugalski, T., "DHCPv6 Options for IPv4 Residual
              Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work
              in progress), July 2011.

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 April 25, 2012                 [Page 7]