TOSHIBA Corporation

Komukai Toshiba Cho 1 Saiwai-Ku Kawasaki Kanagawa 2128582 JAPAN +81-45-342-7230 yusuke.doi@toshiba.co.jp

Itron, Inc

2111 N Molter Rd. Liberty Lake WA 99019 USA matthew.gillmore@itron.com

rtg roll MPL, DHCPv6 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.

Multicast Protocol for Low power and Lossy Networks (MPL) 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 option. This document is intended to follow 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 .

Per MPL domain, there are the following 10 parameters. An MPL domain is defined by an MPL domain address. PROACTIVE_FORWARDING SEED_SET_ENTRY_LIFETIME DATA_MESSAGE_IMIN DATA_MESSAGE_IMAX DATA_MESSAGE_K DATA_MESSAGE_TIMER_EXPIRATIONS CONTROL_MESSAGE_IMIN CONTROL_MESSAGE_IMAX CONTROL_MESSAGE_K 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.

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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCPv6 option identifier (not yet assigned). Length of the option. It SHOULD be 16 (without MPL domain address) or 32 (with MPL domain address). A flag to indicate PROACTIVE_FORWARDING. The flag is set if PROACTIVE_FORWARDING is true. Reserved. Should be 0. Unit time of timer parameters (SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved and SHALL NOT be used. SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. DATA_MESSAGE_K. DATA_MESSAGE_IMIN/TUNIT in milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. DATA_MESSAGE_IMAX. 0 and 0xff are reserved and SHALL NOT be used. DATA_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and SHALL NOT be used. CONTROL_MESSAGE_K. CONTROL_MESSAGE_IMIN/TUNIT in milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. CONTROL_MESSAGE_IMAX. 0 and 0xff are reserved and SHALL NOT be used. 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.

Clients MAY request the MPL Parameter Configuration Option, as described in , 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).

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): Specific MPL Parameter Configuration to the MPL Domain (option_len=32) Wildcard MPL Parameter Configuration (option_len=16) Default configuration given in the MPL specification. 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 leave an MPL domain if the following two conditions are satisfied. 1) The MPL domain is configured by a DHCPv6 option from a DHCPv6 server previously. 2) The node has received 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 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.

Sections 17.2.2 and 18.2 of 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.

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.

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.

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.

There are detailed discussion on security threats on DHCPv6 in Section 23 of RFC3315 and Section 23 of 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. 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 expects 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.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK] This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315. This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in a MPL Domain. MPL has two modes of operation. One mode uses the Trickle algorithm to manage control- and data-plane message transmissions, and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, a MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency. This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK] ZigBee Alliance

Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll-mpl-configuration-05: fixed *_IMAX definition as RFC6206 defines fixed *_EXP definition as draft-ietf-roll-trickle-mcast defines added references to RFC3315 and RFC7227 in security considerations section added a paragraph on security consideration according to secdir review fixed some nits and updated references Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll-mpl-configuration-04: References updated (Non-normative -> Informative) IANA section is updated to make clear request of option ID Reserved numbers are clearly denoted Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll-mpl-configuration-03: References updated 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: Short unsigned floating point is dropped (#159) 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: Operational considerations (normative) and appendix considerations (non-normative) are added (Issue #157) 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: I-D renamed.

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.