roll Y. Doi Internet-Draft TOSHIBA Corporation Intended status: Standards Track M. Gillmore Expires: March 5, 2016 Itron, Inc September 2, 2015 MPL Parameter Configuration Option for DHCPv6 draft-ietf-roll-mpl-parameter-configuration-07 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 easily be configured with a single set of MPL parameters. 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 March 5, 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 Doi & Gillmore Expires March 5, 2016 [Page 1] Internet-Draft MPL Conf. for DHCPv6 September 2015 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 . . . . . . . . . . . . . . . . . 6 2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 6 2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 7 2.6. Operational Considerations . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Considerations on Inconsistent Parameter Set . . . . 9 Appendix B. Update History (TO EDITORS: this section is intended to be removed before this document becomes an RFC) . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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. Doi & Gillmore Expires March 5, 2016 [Page 2] Internet-Draft MPL Conf. for DHCPv6 September 2015 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 As stated in Section 5.4 of [I-D.ietf-roll-trickle-mcast], there are the following 10 parameters per MPL domain. An MPL domain is defined by an MPL domain address, as described in Section 2 of [I-D.ietf-roll-trickle-mcast]. 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 Doi & Gillmore Expires March 5, 2016 [Page 3] Internet-Draft MPL Conf. for DHCPv6 September 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 for future use. Servers MUST set them to zero. Clients SHOULD ignore the bits set. TUNIT (unsigned 8-bit integer): Unit time of timer parameters (SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved and MUST NOT be used. SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. 0 and 0xffff are reserved and MUST 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 MUST NOT be used. DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual maximum timeout is described as a number of doublings of Doi & Gillmore Expires March 5, 2016 [Page 4] Internet-Draft MPL Conf. for DHCPv6 September 2015 DATA_MESSAGE_IMIN, as described in [RFC6206] Section 4.1. 0 and 0xff are reserved and MUST NOT be used. DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and MUST 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 MUST NOT be used. C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. The actual maximum timeout is described as a number of doublings of CONTROL_MESSAGE_IMIN. 0 and 0xff are reserved and MUST NOT be used. C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS . 0 and 0xffff are reserved and MUST NOT be used. Note that the time values (SEED_SET_ENTRY_LIFETIME, DATA_MESSAGE_IMIN, and CONTROL_MESSAGE_IMIN) in MPL are defined in TUNIT milliseconds precision in MPL Parameter Configuration Options. 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. For maximum interval size (*_IMAX), [RFC6206] defines them as follows: The maximum interval size, Imax, is described as a number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define Imax as 16. If the minimum interval is 100 ms, then the amount of time specified by Imax is 100 ms * 65,536, i.e., 6,553.6 seconds or approximately 109 minutes. Because minimum interval size in the MPL Parameter Configuration Options is described as TUNIT millisecond precision, corresponding maximum interval size is also in TUNIT precision. For example, if TUNIT is 10 and C_IMIN is 50, the minimum interval size of the trickle timer for control messages is 500ms. In this case, the maximum interval size of the trickle timer is 32 seconds (500ms * 2^6) if C_IMAX is 6. Doi & Gillmore Expires March 5, 2016 [Page 5] Internet-Draft MPL Conf. for DHCPv6 September 2015 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 support multiple MPL Parameter Configuration Option, as stated in section 2. If a DHCPv6 client with an MPL forwarder configured by the MPL Parameter Configuration Option is unable to receive a valid response from a server within T2 of the last valid DHCPv6 message sent from the server (if stateful) or twice the Information Refresh Time (if stateless), it MUST suspend the MPL forwarders of the MPL domains configured by the option. MPL forwarders configured by other methods such as static configuration file MUST NOT be suspended. Clients MUST ignore all MPL Parameter Configuration Options if the options in a DHCPv6 message contains any invalid value (e.g., it uses reserved all-0 or all-1 values in parameters). In this case, the message is considered not received in MPL context and the condition described in the previous paragraph applies. 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 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. Doi & Gillmore Expires March 5, 2016 [Page 6] Internet-Draft MPL Conf. for DHCPv6 September 2015 There MUST 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 SHOULD leave an MPL domain if it receives an updated and all- valid MPL Parameter Configuration Options without a configuration for the MPL domain, unless it has overriding manual configuration on the MPL domain. In other words, if a node is configured to work as a MPL Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY stay on the MPL domain even if it receives an MPL Parameter Configuration Option without 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 this 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 MUST ignore an incoming MPL Parameter Configuration Option. Servers MUST support multiple MPL Parameter Configuration Option, as stated in section 2. 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 Doi & Gillmore Expires March 5, 2016 [Page 7] Internet-Draft MPL Conf. for DHCPv6 September 2015 [RFC6206] section 6 describe various problems that happens if the trickle timers do not match between communicating nodes. To keep the timers synchronized, it is RECOMMENDED not to update the parameters of an MPL domain too often. A reasonable update rate would be once per expected information refresh time interval, such as T1 in [RFC3315] or Information Refresh Time in [RFC4242]. 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 (http://www.iana.org/assignments/ dhcpv6-parameters). 4. Security Considerations There are detailed discussion on security threats on DHCPv6 in Section 23 of RFC3315 [RFC3315], Section 23 of RFC7227 [RFC7227], and Section 13 of [I-D.ietf-roll-trickle-mcast]. 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, unnecessary 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. Doi & Gillmore Expires March 5, 2016 [Page 8] Internet-Draft MPL Conf. for DHCPv6 September 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. [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, . [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. 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 sets may reduce performance. On the other hand, this situation will work as long as both new and old 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. Doi & Gillmore Expires March 5, 2016 [Page 9] Internet-Draft MPL Conf. for DHCPv6 September 2015 Appendix B. Update History (TO EDITORS: this section is intended to be removed before this document becomes an RFC) Updates on draft-ietf-roll-mpl-configuration-06 to draft-ietf-roll- mpl-configuration-07: o clearly stated multiple option support is mandatory (#171) o operational consideration now refers RFC6206 and some texts are moved to section 2.2 (#171) o added more per-section reference to I-D.ietf-roll-trickle-mcast (#171) o field 'Z' clarified (#171, #172) o fixed other nits (#171) o clarified use of TUNIT, *_IMIN, and *_IMAX with reference to RFC6206 (#172) Updates on 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 Doi & Gillmore Expires March 5, 2016 [Page 10] Internet-Draft MPL Conf. for DHCPv6 September 2015 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. 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 Doi & Gillmore Expires March 5, 2016 [Page 11] Internet-Draft MPL Conf. for DHCPv6 September 2015 Matthew Gillmore Itron, Inc 2111 N Molter Rd. Liberty Lake, WA 99019 USA Email: matthew.gillmore@itron.com Doi & Gillmore Expires March 5, 2016 [Page 12]