roll                                                              Y. Doi
Internet-Draft                                       TOSHIBA Corporation
Intended status: Standards Track                             M. Gillmore
Expires: January 1, 3, 2016                                      Itron, Inc
                                                           June 30,
                                                            July 2, 2015

             MPL Parameter Configuration Option for DHCPv6
             draft-ietf-roll-mpl-parameter-configuration-05
             draft-ietf-roll-mpl-parameter-configuration-06

Abstract

   This document defines a way to configure a parameter set for MPL
   (Multicast Protocol for Low power and Lossy Networks) via a DHCPv6
   option.  MPL has a set of parameters to control its behavior, and the
   parameter set is often configured as a network-wide parameter because
   the parameter set should be identical for each MPL forwarder in an
   MPL domain.  Using the MPL Parameter Configuration Option defined in
   this document, a network can be configured with a single set of MPL
   parameters easily.

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 January 1, 3, 2016.

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MPL Parameter Configuration Option  . . . . . . . . . . . . .   3
     2.1.  MPL Parameter Configuration Option Format . . . . . . . .   3
     2.2.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . .   5
     2.3.  MPL Forwarder Behavior  . . . . . . . . . . . . . . . . .   5
     2.4.  DHCPv6 Server Behavior  . . . . . . . . . . . . . . . . .   6
     2.5.  DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . .   6
     2.6.  Operational Considerations  . . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Update History . . . . . . . . . . . . . . . . . . .   8
   Appendix B.  Considerations on Inconsistent Parameter Set . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9  10

1.  Introduction

   Multicast Protocol for Low power and Lossy Networks (MPL)
   [I-D.ietf-roll-trickle-mcast] defines a protocol to make a multicast
   network among low-power and lossy networks, e.g., wireless mesh
   networks.  MPL has a set of parameters to control an MPL domain.  The
   parameters control the trade-off between end-to-end delay and network
   utilization.  In most environments, the default parameters are
   acceptable.  However, in some environments, the parameter set must be
   configured carefully in order to meet the requirements of each
   environment.  According to the MPL document section 5.4, each
   parameter in the set should be the same for all nodes within an MPL
   domain, but the MPL document does not define a method to configure
   the MPL parameter set.

   Some managed wireless mesh networks may have a DHCP server to
   configure network parameters.  MPL parameter sets shall be considered
   as a part of network parameters (nodes in an MPL domain should use an
   identical parameter set).  And a parameter set is required to
   configure an MPL domain.

   This document defines the way to distribute parameter sets for MPL
   forwarders as a DHCPv6 [RFC3315] option.  This document is intended
   to follow [RFC7227] the guideline.

   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 [RFC2119].

2.  MPL Parameter Configuration Option

   Per MPL domain, there are the following 10 parameters.  An MPL domain
   is defined by an MPL domain address.

   o  PROACTIVE_FORWARDING

   o  SEED_SET_ENTRY_LIFETIME

   o  DATA_MESSAGE_IMIN

   o  DATA_MESSAGE_IMAX

   o  DATA_MESSAGE_K

   o  DATA_MESSAGE_TIMER_EXPIRATIONS

   o  CONTROL_MESSAGE_IMIN

   o  CONTROL_MESSAGE_IMAX

   o  CONTROL_MESSAGE_K

   o  CONTROL_MESSAGE_TIMER_EXPIRATIONS

   One network may have multiple MPL domains with different
   configurations.  To configure more than one MPL domain via DHCP,
   there may be more than one MPL Parameter Configuration Option given
   to DHCP clients by a DHCP server.

2.1.  MPL Parameter Configuration Option Format

   To distribute a configuration of an MPL domain or a default value for
   all MPL domains (wildcard) under the network managed by the DHCP
   server, this document defines a DHCPv6 option format as follows.

    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_MPL_PARAMETERS      |          option_len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P|     Z       |     TUNIT     |            SE_LIFETIME        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    DM_K       |         DM_IMIN               |     DM_IMAX   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         DM_T_EXP              |      C_K      |    C_IMIN     >
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   >(cont'ed)      |    C_IMAX     |          C_T_EXP              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (if option_len = 32 )
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MPL Domain Address  (128bits)                        >
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   >          (cont'ed)                                            >
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   >          (cont'ed)                                            >
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   >          (cont'ed)                                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OPTION_MPL_PARAMETERS:  DHCPv6 option identifier (not yet assigned).

   option_len:  Length of the option.  It SHOULD be 16 (without MPL
      domain address) or 32 (with MPL domain address).

   P (1 bit):  A flag to indicate PROACTIVE_FORWARDING.  The flag is set
      if PROACTIVE_FORWARDING is true.

   Z (7 bits):  Reserved.  Should be 0.

   TUNIT (unsigned 8-bit integer):  Unit time of timer parameters
      (SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved
      and SHALL NOT be used.

   SE_LIFETIME (unsigned 16-bit integer):  SEED_SET_ENTRY_LIFETIME/TUNIT
      in milliseconds. 0 and 0xffff are reserved and SHALL NOT be used.

   DM_K (unsigned 8-bit integer):  DATA_MESSAGE_K.

   DM_IMIN (unsigned 16-bit integer):  DATA_MESSAGE_IMIN/TUNIT in
      milliseconds. 0 and 0xffff are reserved and SHALL NOT be used.

   DM_IMAX (unsigned 8-bit integer):  DATA_MESSAGE_IMAX. 0 and 0xff are
      reserved and SHALL NOT be used.

   DM_T_EXP (unsigned 16-bit integer):  DATA_MESSAGE_TIMER_EXPIRATIONS.
      0 and 0xffff are reserved and SHALL NOT be used.

   C_K (unsigned 8-bit integer):  CONTROL_MESSAGE_K.

   C_IMIN (unsigned 16-bit integer):  CONTROL_MESSAGE_IMIN/TUNIT in
      milliseconds. 0 and 0xffff are reserved and SHALL NOT be used.

   C_IMAX (unsigned 8-bit integer):  CONTROL_MESSAGE_IMAX. 0 and 0xff
      are reserved and SHALL NOT be used.

   C_T_EXP (unsigned 16-bit integer):  CONTROL_MESSAGE_TIMER_EXPIRATIONS
      . 0 and 0xffff are reserved and SHALL NOT be used.

   Note that all time values (Trickle timers and expiration periods) are
   in TUNIT milliseconds precision.  For example, if TUNIT is 20 and the
   data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
   DM_IMIN shall be set to 50.

2.2.  DHCPv6 Client Behavior

   Clients MAY request the MPL Parameter Configuration Option, as
   described in [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4,
   18.1.5, and 22.7.  As a convenience to the reader, we mention here
   that the client includes requested option codes in the Option Request
   Option.

   Clients MUST discard the MPL Parameter Configuration Option if it is
   invalid (e.g., it sets reserved bits).

2.3.  MPL Forwarder Behavior

   If a DHCPv6 client requests and receives the MPL Parameter
   Configuration Option, the node SHOULD join the MPL domain given by
   the option and act as an MPL forwarder.  Note that there may be cases
   in which a node may fail is to join a domain (or domains) due to
   local resource constraints.  Each joining node SHOULD configure its
   MPL forwarder with the given parameter set for the MPL domain.

   The priority of MPL Parameter Configurations applied to an MPL Domain
   is as follows (high to low):

   o  Specific MPL Parameter Configuration to the MPL Domain
      (option_len=32)

   o  Wildcard MPL Parameter Configuration (option_len=16)

   o  Default configuration given in the MPL specification.

   Priority of other configurations such as manual configuration given
   on a node is not defined in the document.

   There SHALL be no more than one MPL Parameter Configuration Option
   for an MPL domain or the wildcard.  Thus, the order of DHCPv6 options
   in the packet has no effect on precedence.

   A node MAY SHOULD leave an MPL domain if it receives an updated MPL
   Parameter Configuration Option without a configuration for the following two conditions are
   satisfied. 1) The MPL domain
   domain, unless it has overriding manual configuration on the MPL
   domain.  In other words, if a node is configured by to work as a DHCPv6 option from MPL
   Forwarder for a MPL domain regardless of DHCPv6 server previously. 2) The Options, the node has received MAY
   stay on the MPL domain even if it receives an updated MPL Parameter
   Configuration Option without a configuration for the MPL domain.

   MPL parameters may be updated occasionally.  With stateful DHCPv6,
   updates can be done when the renewal timer expires.  Information
   Refresh Time Option [RFC4242] shall be used to keep each forwarder
   updated.

   To reduce periodic update traffic, a node may try to use a very long
   interval between updates.  In the case, reconfigure messages may be
   used to keep forwarder parameter sets synchronized.

2.4.  DHCPv6 Server Behavior

   Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
   regards to option assignment.  As a convenience to the reader, we
   mention here that the server will send the MPL Parameter
   Configuration Option only if it was configured with specific values
   for the MPL Parameter Configuration Option and the client requested
   it.

   Servers SHALL ignore an incoming MPL Parameter Configuration Option.

2.5.  DHCPv6 Relay Behavior

   It's never appropriate for a relay agent to add options to a message
   heading toward the client, and relay agents don't actually construct
   Relay-Reply messages anyway.  There are no additional requirements
   for relays.

2.6.  Operational Considerations

   A parameter set for an MPL domain SHOULD NOT be updated more often
   than twice of Information Refresh Time, even if the clients use
   longer Information Refresh Time to reduce DHCPv6 load on the network.

   If a node with an MPL forwarder configured by the MPL Parameter
   Configuration Option failed to refresh the option within twice the
   Information Refresh Time, it SHALL suspend the MPL forwarders of the
   MPL domains configured by the option.  MPL forwarders configured by
   other methods such as static configuration file SHALL NOT be
   suspended.

3.  IANA Considerations

   IANA is requested to assign one option code for OPTION_MPL_PARAMETERS
   from the "DHCP Option Codes" table of the Dynamic Host Configuration
   Protocol for IPv6 (DHCPv6) Registry.

4.  Security Considerations

   There are detailed discussion on security threats on DHCPv6 in
   Section 23 of RFC3315 [RFC3315] and Section 23 of RFC7227 [RFC7227].

   In addition, a forged MPL parameter configuration may cause excessive
   layer-2 broadcasting.  Implementations should set reasonable bounds
   for each parameter.  For example, not too high DM/C_K, not too low DM
   /C_IMIN, etc.  These bounds may be implementation dependent or may be
   derived from MAC/PHY specifications.  DHCPv6 server and client
   implementations need to take care in setting reasonable bounds for
   each parameter in order to avoid overloading the network.

   The DHCP server or the network itself should be trusted by some means
   such as DHCPv6 authentications described in Section 21 of RFC3315
   [RFC3315].  However, ROLL environment may expect less computing
   resource, and DHCPv6 authentication may not available.  In such
   cases, other methods for security should be applied to a ROLL
   network.  Some ROLL specification such as ZigBee IP [ZigBeeIP]
   expects RFC5191 [RFC5191] to authenticate joining nodes and all nodes
   in the network can be trusted.  To protect attacks from outside of
   the network, unneccessary DHCPv6 packets should be filtered on the
   border router between the ROLL network and the Internet.

5.  References

5.1.  Normative References

   [I-D.ietf-roll-trickle-mcast]
              Hui, J. and R. Kelsey, "Multicast Protocol for Low power
              and Lossy Networks (MPL)", draft-ietf-roll-trickle-
              mcast-12 (work in progress), June 2015.

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

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4242, November 2005.

   [RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              BCP 187, RFC 7227, May 2014.

5.2.  Informative References

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [ZigBeeIP]
              ZigBee Alliance, "ZigBee IP Specification", Mar 2014.

Appendix A.  Update History

   Updates on draft-ietf-roll-mpl-configuration-03 draft-ietf-roll-mpl-configuration-05 to draft-ietf-roll-
   mpl-configuration-06:

   o  added description on manual (external) configurations

   Updates on draft-ietf-roll-mpl-configuration-04 to draft-ietf-roll-
   mpl-configuration-05:

   o  fixed *_IMAX definition as RFC6206 defines

   o  fixed *_EXP definition as draft-ietf-roll-trickle-mcast defines

   o  added references to RFC3315 and RFC7227 in security considerations
      section

   o  added a paragraph on security consideration according to secdir
      review

   o  fixed some nits and updated references

   Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll-
   mpl-configuration-04:

   o  References updated (Non-normative -> Informative)
   o  IANA section is updated to make clear request of option ID

   o  Reserved numbers are clearly denoted

   Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll-
   mpl-configuration-03:

   o  References updated

   o  Removed reference for DHCPv6 stateless reconfiguration as it has
      expired

   Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll-
   mpl-configuration-02:

   o  Short unsigned floating point is dropped (#159)

   o  Packed value is removed and now every value has its own byte(s)
      (#159)

   Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll-
   mpl-configuration-01:

   o  Operational considerations (normative) and appendix considerations
      (non-normative) are added (Issue #157)

   o  More control on nodes / allow constrained nodes to ignore the
      configuration: "the node s/SHOULD/MAY/ join the MPL domain given
      by the option" (Issue #158)

   Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll-
   mpl-configuration-00:

   o  I-D renamed.

Appendix B.  Considerations on Inconsistent Parameter Set

   This draft introduces dynamic update of MPL parameters.  Because the
   update process is not synchronized, nodes may have inconsistent
   parameter sets.

   Inconsistent parameter set may reduce performance.  On the other
   hand, this situation will work as long as both parameter sets are
   reasonable parameter sets for a given communication load.  As the
   motivations for parameter update include update of the environment,
   node density, or communication load, operators of MPL networks shall
   be aware of unupdated nodes and make sure old and new parameter sets
   are reasonable for the expected refresh intervals.

Authors' Addresses

   Yusuke Doi
   TOSHIBA Corporation
   Komukai Toshiba Cho 1
   Saiwai-Ku
   Kawasaki, Kanagawa  2128582
   JAPAN

   Phone: +81-45-342-7230
   Email: yusuke.doi@toshiba.co.jp

   Matthew Gillmore
   Itron, Inc
   2111 N Molter Rd.
   Liberty Lake, WA  99019
   USA

   Email: matthew.gillmore@itron.com