idnits 2.17.1 draft-ietf-roll-mpl-parameter-configuration-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2015) is 3220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 roll Y. Doi 3 Internet-Draft TOSHIBA Corporation 4 Intended status: Standards Track M. Gillmore 5 Expires: January 3, 2016 Itron, Inc 6 July 2, 2015 8 MPL Parameter Configuration Option for DHCPv6 9 draft-ietf-roll-mpl-parameter-configuration-06 11 Abstract 13 This document defines a way to configure a parameter set for MPL 14 (Multicast Protocol for Low power and Lossy Networks) via a DHCPv6 15 option. MPL has a set of parameters to control its behavior, and the 16 parameter set is often configured as a network-wide parameter because 17 the parameter set should be identical for each MPL forwarder in an 18 MPL domain. Using the MPL Parameter Configuration Option defined in 19 this document, a network can be configured with a single set of MPL 20 parameters easily. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. MPL Parameter Configuration Option . . . . . . . . . . . . . 3 58 2.1. MPL Parameter Configuration Option Format . . . . . . . . 3 59 2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5 60 2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 5 61 2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 6 62 2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 6 63 2.6. Operational Considerations . . . . . . . . . . . . . . . 6 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 5.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Update History . . . . . . . . . . . . . . . . . . . 8 70 Appendix B. Considerations on Inconsistent Parameter Set . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Multicast Protocol for Low power and Lossy Networks (MPL) 76 [I-D.ietf-roll-trickle-mcast] defines a protocol to make a multicast 77 network among low-power and lossy networks, e.g., wireless mesh 78 networks. MPL has a set of parameters to control an MPL domain. The 79 parameters control the trade-off between end-to-end delay and network 80 utilization. In most environments, the default parameters are 81 acceptable. However, in some environments, the parameter set must be 82 configured carefully in order to meet the requirements of each 83 environment. According to the MPL document section 5.4, each 84 parameter in the set should be the same for all nodes within an MPL 85 domain, but the MPL document does not define a method to configure 86 the MPL parameter set. 88 Some managed wireless mesh networks may have a DHCP server to 89 configure network parameters. MPL parameter sets shall be considered 90 as a part of network parameters (nodes in an MPL domain should use an 91 identical parameter set). And a parameter set is required to 92 configure an MPL domain. 94 This document defines the way to distribute parameter sets for MPL 95 forwarders as a DHCPv6 [RFC3315] option. This document is intended 96 to follow [RFC7227] the guideline. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. MPL Parameter Configuration Option 104 Per MPL domain, there are the following 10 parameters. An MPL domain 105 is defined by an MPL domain address. 107 o PROACTIVE_FORWARDING 109 o SEED_SET_ENTRY_LIFETIME 111 o DATA_MESSAGE_IMIN 113 o DATA_MESSAGE_IMAX 115 o DATA_MESSAGE_K 117 o DATA_MESSAGE_TIMER_EXPIRATIONS 119 o CONTROL_MESSAGE_IMIN 121 o CONTROL_MESSAGE_IMAX 123 o CONTROL_MESSAGE_K 125 o CONTROL_MESSAGE_TIMER_EXPIRATIONS 127 One network may have multiple MPL domains with different 128 configurations. To configure more than one MPL domain via DHCP, 129 there may be more than one MPL Parameter Configuration Option given 130 to DHCP clients by a DHCP server. 132 2.1. MPL Parameter Configuration Option Format 134 To distribute a configuration of an MPL domain or a default value for 135 all MPL domains (wildcard) under the network managed by the DHCP 136 server, this document defines a DHCPv6 option format as follows. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | OPTION_MPL_PARAMETERS | option_len | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |P| Z | TUNIT | SE_LIFETIME | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | DM_K | DM_IMIN | DM_IMAX | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | DM_T_EXP | C_K | C_IMIN > 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 >(cont'ed) | C_IMAX | C_T_EXP | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 (if option_len = 32 ) 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | MPL Domain Address (128bits) > 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 > (cont'ed) > 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 > (cont'ed) > 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 > (cont'ed) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned). 165 option_len: Length of the option. It SHOULD be 16 (without MPL 166 domain address) or 32 (with MPL domain address). 168 P (1 bit): A flag to indicate PROACTIVE_FORWARDING. The flag is set 169 if PROACTIVE_FORWARDING is true. 171 Z (7 bits): Reserved. Should be 0. 173 TUNIT (unsigned 8-bit integer): Unit time of timer parameters 174 (SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved 175 and SHALL NOT be used. 177 SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT 178 in milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. 180 DM_K (unsigned 8-bit integer): DATA_MESSAGE_K. 182 DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT in 183 milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. 185 DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. 0 and 0xff are 186 reserved and SHALL NOT be used. 188 DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS. 189 0 and 0xffff are reserved and SHALL NOT be used. 191 C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K. 193 C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT in 194 milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. 196 C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. 0 and 0xff 197 are reserved and SHALL NOT be used. 199 C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS 200 . 0 and 0xffff are reserved and SHALL NOT be used. 202 Note that all time values (Trickle timers and expiration periods) are 203 in TUNIT milliseconds precision. For example, if TUNIT is 20 and the 204 data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then 205 DM_IMIN shall be set to 50. 207 2.2. DHCPv6 Client Behavior 209 Clients MAY request the MPL Parameter Configuration Option, as 210 described in [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 211 18.1.5, and 22.7. As a convenience to the reader, we mention here 212 that the client includes requested option codes in the Option Request 213 Option. 215 Clients MUST discard the MPL Parameter Configuration Option if it is 216 invalid (e.g., it sets reserved bits). 218 2.3. MPL Forwarder Behavior 220 If a DHCPv6 client requests and receives the MPL Parameter 221 Configuration Option, the node SHOULD join the MPL domain given by 222 the option and act as an MPL forwarder. Note that there may be cases 223 in which a node may fail is to join a domain (or domains) due to 224 local resource constraints. Each joining node SHOULD configure its 225 MPL forwarder with the given parameter set for the MPL domain. 227 The priority of MPL Parameter Configurations applied to an MPL Domain 228 is as follows (high to low): 230 o Specific MPL Parameter Configuration to the MPL Domain 231 (option_len=32) 233 o Wildcard MPL Parameter Configuration (option_len=16) 235 o Default configuration given in the MPL specification. 237 Priority of other configurations such as manual configuration given 238 on a node is not defined in the document. 240 There SHALL be no more than one MPL Parameter Configuration Option 241 for an MPL domain or the wildcard. Thus, the order of DHCPv6 options 242 in the packet has no effect on precedence. 244 A node SHOULD leave an MPL domain if it receives an updated MPL 245 Parameter Configuration Option without a configuration for the MPL 246 domain, unless it has overriding manual configuration on the MPL 247 domain. In other words, if a node is configured to work as a MPL 248 Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY 249 stay on the MPL domain even if it receives an MPL Parameter 250 Configuration Option without configuration for the MPL domain. 252 MPL parameters may be updated occasionally. With stateful DHCPv6, 253 updates can be done when the renewal timer expires. Information 254 Refresh Time Option [RFC4242] shall be used to keep each forwarder 255 updated. 257 To reduce periodic update traffic, a node may try to use a very long 258 interval between updates. In the case, reconfigure messages may be 259 used to keep forwarder parameter sets synchronized. 261 2.4. DHCPv6 Server Behavior 263 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 264 regards to option assignment. As a convenience to the reader, we 265 mention here that the server will send the MPL Parameter 266 Configuration Option only if it was configured with specific values 267 for the MPL Parameter Configuration Option and the client requested 268 it. 270 Servers SHALL ignore an incoming MPL Parameter Configuration Option. 272 2.5. DHCPv6 Relay Behavior 274 It's never appropriate for a relay agent to add options to a message 275 heading toward the client, and relay agents don't actually construct 276 Relay-Reply messages anyway. There are no additional requirements 277 for relays. 279 2.6. Operational Considerations 281 A parameter set for an MPL domain SHOULD NOT be updated more often 282 than twice of Information Refresh Time, even if the clients use 283 longer Information Refresh Time to reduce DHCPv6 load on the network. 285 If a node with an MPL forwarder configured by the MPL Parameter 286 Configuration Option failed to refresh the option within twice the 287 Information Refresh Time, it SHALL suspend the MPL forwarders of the 288 MPL domains configured by the option. MPL forwarders configured by 289 other methods such as static configuration file SHALL NOT be 290 suspended. 292 3. IANA Considerations 294 IANA is requested to assign one option code for OPTION_MPL_PARAMETERS 295 from the "DHCP Option Codes" table of the Dynamic Host Configuration 296 Protocol for IPv6 (DHCPv6) Registry. 298 4. Security Considerations 300 There are detailed discussion on security threats on DHCPv6 in 301 Section 23 of RFC3315 [RFC3315] and Section 23 of RFC7227 [RFC7227]. 303 In addition, a forged MPL parameter configuration may cause excessive 304 layer-2 broadcasting. Implementations should set reasonable bounds 305 for each parameter. For example, not too high DM/C_K, not too low DM 306 /C_IMIN, etc. These bounds may be implementation dependent or may be 307 derived from MAC/PHY specifications. DHCPv6 server and client 308 implementations need to take care in setting reasonable bounds for 309 each parameter in order to avoid overloading the network. 311 The DHCP server or the network itself should be trusted by some means 312 such as DHCPv6 authentications described in Section 21 of RFC3315 313 [RFC3315]. However, ROLL environment may expect less computing 314 resource, and DHCPv6 authentication may not available. In such 315 cases, other methods for security should be applied to a ROLL 316 network. Some ROLL specification such as ZigBee IP [ZigBeeIP] 317 expects RFC5191 [RFC5191] to authenticate joining nodes and all nodes 318 in the network can be trusted. To protect attacks from outside of 319 the network, unneccessary DHCPv6 packets should be filtered on the 320 border router between the ROLL network and the Internet. 322 5. References 324 5.1. Normative References 326 [I-D.ietf-roll-trickle-mcast] 327 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 328 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 329 mcast-12 (work in progress), June 2015. 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 335 and M. Carney, "Dynamic Host Configuration Protocol for 336 IPv6 (DHCPv6)", RFC 3315, July 2003. 338 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 339 Time Option for Dynamic Host Configuration Protocol for 340 IPv6 (DHCPv6)", RFC 4242, November 2005. 342 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 343 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 344 BCP 187, RFC 7227, May 2014. 346 5.2. Informative References 348 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 349 Yegin, "Protocol for Carrying Authentication for Network 350 Access (PANA)", RFC 5191, May 2008. 352 [ZigBeeIP] 353 ZigBee Alliance, "ZigBee IP Specification", Mar 2014. 355 Appendix A. Update History 357 Updates on draft-ietf-roll-mpl-configuration-05 to draft-ietf-roll- 358 mpl-configuration-06: 360 o added description on manual (external) configurations 362 Updates on draft-ietf-roll-mpl-configuration-04 to draft-ietf-roll- 363 mpl-configuration-05: 365 o fixed *_IMAX definition as RFC6206 defines 367 o fixed *_EXP definition as draft-ietf-roll-trickle-mcast defines 369 o added references to RFC3315 and RFC7227 in security considerations 370 section 372 o added a paragraph on security consideration according to secdir 373 review 375 o fixed some nits and updated references 377 Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll- 378 mpl-configuration-04: 380 o References updated (Non-normative -> Informative) 381 o IANA section is updated to make clear request of option ID 383 o Reserved numbers are clearly denoted 385 Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll- 386 mpl-configuration-03: 388 o References updated 390 o Removed reference for DHCPv6 stateless reconfiguration as it has 391 expired 393 Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- 394 mpl-configuration-02: 396 o Short unsigned floating point is dropped (#159) 398 o Packed value is removed and now every value has its own byte(s) 399 (#159) 401 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- 402 mpl-configuration-01: 404 o Operational considerations (normative) and appendix considerations 405 (non-normative) are added (Issue #157) 407 o More control on nodes / allow constrained nodes to ignore the 408 configuration: "the node s/SHOULD/MAY/ join the MPL domain given 409 by the option" (Issue #158) 411 Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll- 412 mpl-configuration-00: 414 o I-D renamed. 416 Appendix B. Considerations on Inconsistent Parameter Set 418 This draft introduces dynamic update of MPL parameters. Because the 419 update process is not synchronized, nodes may have inconsistent 420 parameter sets. 422 Inconsistent parameter set may reduce performance. On the other 423 hand, this situation will work as long as both parameter sets are 424 reasonable parameter sets for a given communication load. As the 425 motivations for parameter update include update of the environment, 426 node density, or communication load, operators of MPL networks shall 427 be aware of unupdated nodes and make sure old and new parameter sets 428 are reasonable for the expected refresh intervals. 430 Authors' Addresses 432 Yusuke Doi 433 TOSHIBA Corporation 434 Komukai Toshiba Cho 1 435 Saiwai-Ku 436 Kawasaki, Kanagawa 2128582 437 JAPAN 439 Phone: +81-45-342-7230 440 Email: yusuke.doi@toshiba.co.jp 442 Matthew Gillmore 443 Itron, Inc 444 2111 N Molter Rd. 445 Liberty Lake, WA 99019 446 USA 448 Email: matthew.gillmore@itron.com