idnits 2.17.1 draft-ietf-roll-mpl-parameter-configuration-08.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 (November 2, 2015) is 3090 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: May 5, 2016 Itron, Inc 6 November 2, 2015 8 MPL Parameter Configuration Option for DHCPv6 9 draft-ietf-roll-mpl-parameter-configuration-08 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 easily be configured with a single set 20 of MPL parameters. 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 May 5, 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 . . . . . . . . . . . . . . . . . 6 61 2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 62 2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 7 63 2.6. Operational Considerations . . . . . . . . . . . . . . . 7 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 5.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Appendix A. Update History (TO EDITORS: this section is intended 70 to be removed before this document becomes an RFC) . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 As stated in Section 5.4 of [I-D.ietf-roll-trickle-mcast], there are 105 the following 10 parameters per MPL domain. An MPL domain is defined 106 by an MPL domain address, as described in Section 2 of 107 [I-D.ietf-roll-trickle-mcast]. 109 o PROACTIVE_FORWARDING 111 o SEED_SET_ENTRY_LIFETIME 113 o DATA_MESSAGE_IMIN 115 o DATA_MESSAGE_IMAX 117 o DATA_MESSAGE_K 119 o DATA_MESSAGE_TIMER_EXPIRATIONS 121 o CONTROL_MESSAGE_IMIN 123 o CONTROL_MESSAGE_IMAX 125 o CONTROL_MESSAGE_K 127 o CONTROL_MESSAGE_TIMER_EXPIRATIONS 129 One network may have multiple MPL domains with different 130 configurations. To configure more than one MPL domain via DHCP, 131 there may be more than one MPL Parameter Configuration Option given 132 to DHCP clients by a DHCP server. 134 2.1. MPL Parameter Configuration Option Format 136 To distribute a configuration of an MPL domain or a default value for 137 all MPL domains (wildcard) under the network managed by the DHCP 138 server, this document defines a DHCPv6 option format as follows. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | OPTION_MPL_PARAMETERS | option_len | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |P| Z | TUNIT | SE_LIFETIME | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | DM_K | DM_IMIN | DM_IMAX | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | DM_T_EXP | C_K | C_IMIN > 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 >(cont'ed) | C_IMAX | C_T_EXP | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 (if option_len = 32 ) 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | MPL Domain Address (128bits) > 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 > (cont'ed) > 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 > (cont'ed) > 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 > (cont'ed) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned). 167 option_len: Length of the option, which is 16 of no MPL domain 168 address is present, or 32 if there is an MPL domain address. 170 P (1 bit): A flag to indicate PROACTIVE_FORWARDING. The flag is set 171 if PROACTIVE_FORWARDING is true. 173 Z (7 bits): Reserved for future use. Servers MUST set them to zero. 174 Clients SHOULD ignore the bits set. 176 TUNIT (unsigned 8-bit integer): Unit time of timer parameters 177 (SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved 178 and MUST NOT be used. 180 SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT 181 in milliseconds. 0 and 0xffff are reserved and MUST NOT be used. 183 DM_K (unsigned 8-bit integer): DATA_MESSAGE_K. 185 DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT in 186 milliseconds. 0 and 0xffff are reserved and MUST NOT be used. 188 DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual 189 maximum timeout is described as a number of doublings of 190 DATA_MESSAGE_IMIN, as described in [RFC6206] Section 4.1. 0 and 191 0xff are reserved and MUST NOT be used. 193 DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS. 194 0 and 0xffff are reserved and MUST NOT be used. 196 C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K. 198 C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT in 199 milliseconds. 0 and 0xffff are reserved and MUST NOT be used. 201 C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. The actual 202 maximum timeout is described as a number of doublings of 203 CONTROL_MESSAGE_IMIN. 0 and 0xff are reserved and MUST NOT be 204 used. 206 C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS 207 . 0 and 0xffff are reserved and MUST NOT be used. 209 Note that the time values (SEED_SET_ENTRY_LIFETIME, 210 DATA_MESSAGE_IMIN, and CONTROL_MESSAGE_IMIN) in MPL are defined in 211 TUNIT milliseconds precision in MPL Parameter Configuration Options. 212 For example, if TUNIT is 20 and the data message interval minimum 213 (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50. 215 For maximum interval size (*_IMAX), [RFC6206] defines them as 216 follows: 218 The maximum interval size, Imax, is described as a number of 219 doublings of the minimum interval size (the base-2 log(max/min)). 220 For example, a protocol might define Imax as 16. If the minimum 221 interval is 100 ms, then the amount of time specified by Imax is 222 100 ms * 65,536, i.e., 6,553.6 seconds or approximately 109 223 minutes. 225 Because minimum interval size in the MPL Parameter Configuration 226 Options is described as TUNIT millisecond precision, corresponding 227 maximum interval size is also in TUNIT precision. For example, if 228 TUNIT is 10 and C_IMIN is 50, the minimum interval size of the 229 trickle timer for control messages is 500ms. In this case, the 230 maximum interval size of the trickle timer is 32 seconds (500ms * 231 2^6) if C_IMAX is 6. 233 2.2. DHCPv6 Client Behavior 235 Clients MAY request the MPL Parameter Configuration Option, as 236 described in [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 237 18.1.5, and 22.7. As a convenience to the reader, we mention here 238 that the client includes requested option codes in the Option Request 239 Option. 241 Clients MUST support multiple MPL Parameter Configuration Option, as 242 stated in section 2. 244 If a DHCPv6 client with an MPL forwarder configured by the MPL 245 Parameter Configuration Option is unable to receive a valid response 246 from a server within T2 of the last valid DHCPv6 message sent from 247 the server (if stateful) or twice the Information Refresh Time (if 248 stateless), it MUST suspend the MPL forwarders of the MPL domains 249 configured by the option. MPL forwarders configured by other methods 250 such as static configuration file MUST NOT be suspended. 252 Clients MUST ignore all MPL Parameter Configuration Options if the 253 options in a DHCPv6 message contains any invalid value (e.g., it uses 254 reserved all-0 or all-1 values in parameters). In this case, the 255 message is considered not received in MPL context and the condition 256 described in the previous paragraph applies. 258 2.3. MPL Forwarder Behavior 260 If a DHCPv6 client requests and receives the MPL Parameter 261 Configuration Option, the node SHOULD join the MPL domain given by 262 the option and act as an MPL forwarder. Note that there may be cases 263 in which a node may fail to join a domain (or domains) due to local 264 resource constraints. Each joining node SHOULD configure its MPL 265 forwarder with the given parameter set for the MPL domain. Each MPL 266 domain is defined by an MPL Domain Address given by an MPL Parameter 267 Configuration Option. As defined in Section 2 of 268 [I-D.ietf-roll-trickle-mcast], an MPL Domain Address is an IPv6 269 multicast address associated to a set of MPL network interfaces in an 270 MPL Domain. 272 The priority of MPL Parameter Configurations applied to an MPL Domain 273 is as follows (high to low): 275 o Specific MPL Parameter Configuration to the MPL Domain 276 (option_len=32) 278 o Wildcard MPL Parameter Configuration (option_len=16) 280 o Default configuration given in the MPL specification. 282 Priority of other configurations such as manual configuration given 283 on a node is not defined in the document. 285 There MUST be no more than one MPL Parameter Configuration Option for 286 an MPL domain or the wildcard. Thus, the order of DHCPv6 options in 287 the packet has no effect on precedence. 289 A node MUST leave an MPL domain if it receives an updated and all- 290 valid MPL Parameter Configuration Options without a configuration for 291 the MPL domain, unless it has overriding manual configuration on the 292 MPL domain. In other words, if a node is configured to work as a MPL 293 Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY 294 stay on the MPL domain even if it receives an MPL Parameter 295 Configuration Option without configuration for the MPL domain. 297 MPL parameters may be updated occasionally. With stateful DHCPv6, 298 updates can be done when the renewal timer expires. Information 299 Refresh Time Option [RFC4242] shall be used to keep each forwarder 300 updated. 302 To reduce periodic update traffic, a node may try to use a very long 303 interval between updates. In this case, reconfigure messages may be 304 used to keep forwarder parameter sets synchronized. 306 2.4. DHCPv6 Server Behavior 308 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 309 regards to option assignment. As a convenience to the reader, we 310 mention here that the server will send the MPL Parameter 311 Configuration Option only if it was configured with specific values 312 for the MPL Parameter Configuration Option and the client requested 313 it. 315 Servers MUST ignore an incoming MPL Parameter Configuration Option. 316 Servers MUST support multiple MPL Parameter Configuration Option, as 317 stated in section 2. 319 2.5. DHCPv6 Relay Behavior 321 It's never appropriate for a relay agent to add options to a message 322 heading toward the client, and relay agents don't actually construct 323 Relay-Reply messages anyway. There are no additional requirements 324 for relays. 326 2.6. Operational Considerations 328 This draft introduces dynamic update of MPL parameters. Because the 329 update process is not synchronized, nodes may have inconsistent 330 parameter sets. 332 [RFC6206] section 6 describe various problems that happens if the 333 trickle timers do not match between communicating nodes. To keep the 334 timers synchronized, it is RECOMMENDED not to update the parameters 335 of an MPL domain too often. A reasonable update rate would be once 336 per expected information refresh time interval, such as T1 in 337 [RFC3315] or Information Refresh Time in [RFC4242]. 339 Inconsistent parameter sets may reduce performance. On the other 340 hand, this situation will work as long as both new and old parameter 341 sets are reasonable parameter sets for a given communication load. 342 As the motivations for parameter update include update of the 343 environment, node density, or communication load, operators of MPL 344 networks shall be aware of unupdated nodes and make sure old and new 345 parameter sets are reasonable for the expected refresh intervals. 347 3. IANA Considerations 349 IANA is requested to assign one option code for OPTION_MPL_PARAMETERS 350 from the "DHCP Option Codes" table of the Dynamic Host Configuration 351 Protocol for IPv6 (DHCPv6) Registry (http://www.iana.org/assignments/ 352 dhcpv6-parameters). 354 4. Security Considerations 356 There are detailed discussion on security threats on DHCPv6 in 357 Section 23 of RFC3315 [RFC3315], Section 23 of RFC7227 [RFC7227], and 358 Section 13 of [I-D.ietf-roll-trickle-mcast]. 360 In addition, a forged MPL parameter configuration may cause excessive 361 layer-2 broadcasting. Implementations should set reasonable bounds 362 for each parameter. For example, not too high DM/C_K, not too low DM 363 /C_IMIN, etc. These bounds may be implementation dependent or may be 364 derived from MAC/PHY specifications. DHCPv6 server and client 365 implementations need to take care in setting reasonable bounds for 366 each parameter in order to avoid overloading the network. 368 The DHCP server or the network itself should be trusted by some means 369 such as DHCPv6 authentications described in Section 21 of RFC3315 370 [RFC3315]. However, ROLL environment may expect less computing 371 resource, and DHCPv6 authentication may not available. In such 372 cases, other methods to protect integrity between DHCPv6 servers and 373 clients should be applied to a ROLL network. Some ROLL specification 374 such as ZigBee IP [ZigBeeIP] expects RFC5191 [RFC5191] to 375 authenticate joining nodes and all nodes in the network can be 376 trusted. To protect attacks from outside of the network, DHCPv6 377 packets SHOULD be filtered on the border router between the ROLL 378 network and the Internet, except for the packets between the ROLL 379 network and a remote DHCPv6 server or DHCPv6 relays configured to 380 manage the network. 382 5. References 384 5.1. Normative References 386 [I-D.ietf-roll-trickle-mcast] 387 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 388 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 389 mcast-12 (work in progress), June 2015. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 395 and M. Carney, "Dynamic Host Configuration Protocol for 396 IPv6 (DHCPv6)", RFC 3315, July 2003. 398 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 399 Time Option for Dynamic Host Configuration Protocol for 400 IPv6 (DHCPv6)", RFC 4242, November 2005. 402 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 403 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 404 March 2011, . 406 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 407 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 408 BCP 187, RFC 7227, May 2014. 410 5.2. Informative References 412 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 413 Yegin, "Protocol for Carrying Authentication for Network 414 Access (PANA)", RFC 5191, May 2008. 416 [ZigBeeIP] 417 ZigBee Alliance, "ZigBee IP Specification", Mar 2014. 419 Appendix A. Update History (TO EDITORS: this section is intended to be 420 removed before this document becomes an RFC) 422 Updates on draft-ietf-roll-mpl-configuration-07 to draft-ietf-roll- 423 mpl-configuration-08: 425 o clarified when to leave (SHOULD->MUST) 427 o moved Trickle parameter considerations on appendix to operational 428 considerations 430 o even clarified some texts 432 Updates on draft-ietf-roll-mpl-configuration-06 to draft-ietf-roll- 433 mpl-configuration-07: 435 o clearly stated multiple option support is mandatory (#171) 437 o operational consideration now refers RFC6206 and some texts are 438 moved to section 2.2 (#171) 440 o added more per-section reference to I-D.ietf-roll-trickle-mcast 441 (#171) 443 o field 'Z' clarified (#171, #172) 445 o fixed other nits (#171) 447 o clarified use of TUNIT, *_IMIN, and *_IMAX with reference to 448 RFC6206 (#172) 450 Updates on draft-ietf-roll-mpl-configuration-05 to draft-ietf-roll- 451 mpl-configuration-06: 453 o added description on manual (external) configurations 455 Updates on draft-ietf-roll-mpl-configuration-04 to draft-ietf-roll- 456 mpl-configuration-05: 458 o fixed *_IMAX definition as RFC6206 defines 460 o fixed *_EXP definition as draft-ietf-roll-trickle-mcast defines 462 o added references to RFC3315 and RFC7227 in security considerations 463 section 465 o added a paragraph on security consideration according to secdir 466 review 468 o fixed some nits and updated references 470 Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll- 471 mpl-configuration-04: 473 o References updated (Non-normative -> Informative) 475 o IANA section is updated to make clear request of option ID 477 o Reserved numbers are clearly denoted 479 Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll- 480 mpl-configuration-03: 482 o References updated 484 o Removed reference for DHCPv6 stateless reconfiguration as it has 485 expired 487 Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- 488 mpl-configuration-02: 490 o Short unsigned floating point is dropped (#159) 492 o Packed value is removed and now every value has its own byte(s) 493 (#159) 495 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- 496 mpl-configuration-01: 498 o Operational considerations (normative) and appendix considerations 499 (non-normative) are added (Issue #157) 501 o More control on nodes / allow constrained nodes to ignore the 502 configuration: "the node s/SHOULD/MAY/ join the MPL domain given 503 by the option" (Issue #158) 505 Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll- 506 mpl-configuration-00: 508 o I-D renamed. 510 Authors' Addresses 511 Yusuke Doi 512 TOSHIBA Corporation 513 Komukai Toshiba Cho 1 514 Saiwai-Ku 515 Kawasaki, Kanagawa 2128582 516 JAPAN 518 Phone: +81-45-342-7230 519 Email: yusuke.doi@toshiba.co.jp 521 Matthew Gillmore 522 Itron, Inc 523 2111 N Molter Rd. 524 Liberty Lake, WA 99019 525 USA 527 Email: matthew.gillmore@itron.com