idnits 2.17.1 draft-ietf-roll-mpl-parameter-configuration-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... the option. It SHOULD be 18 (without...' RFC 2119 keyword, line 175: '... It SHALL NOT be 0 or 255....' RFC 2119 keyword, line 178: '... SHALL NOT be 0 or 0xffff....' RFC 2119 keyword, line 183: '...illiseconds. It SHALL NOT be 0 or 0xf...' RFC 2119 keyword, line 186: '...illiseconds. It SHALL NOT be 0 or 0xf...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2014) is 3560 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) == Unused Reference: 'I-D.ietf-dhc-option-guidelines' is defined on line 315, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-07 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 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 22, 2015 Itron, Inc 6 July 21, 2014 8 MPL Parameter Configuration Option for DHCPv6 9 draft-ietf-roll-mpl-parameter-configuration-02 11 Abstract 13 This draft defines a way to configure a parameter set of MPL 14 (Multicast Protocol for Low power and Lossy Networks) via 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 parameter 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 22, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 5.2. Non-Normative References . . . . . . . . . . . . . . . . 7 69 Appendix A. Update History . . . . . . . . . . . . . . . . . . . 8 70 Appendix B. Considerations on Inconsistent Parameter Set . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 network e.g. wireless mesh 78 networks. MPL has a set of parameters to control an MPL domain. The 79 parameter controls 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 draft section 5.4, each parameter 84 in the set should be same for all nodes within an MPL domain. And 85 the MPL draft does not define a method to configure the MPL parameter 86 set. 88 Some managed wireless mesh networks may have a DHCP server to 89 configure network parameters. MPL parameter set 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 are required to 92 configure an MPL domain. 94 This document is to define the way to distribute parameter sets for 95 MPL forwarders as a DHCPv6 [RFC3315] option. This document is 96 intended to follow the guideline [RFC7227]. 98 2. MPL Parameter Configuration Option 100 Per MPL domain, there are following 10 parameters. An MPL domain is 101 defined by an MPL domain address. 103 o PROACTIVE_FORWARDING 105 o SEED_SET_ENTRY_LIFETIME 107 o DATA_MESSAGE_IMIN 109 o DATA_MESSAGE_IMAX 111 o DATA_MESSAGE_K 113 o DATA_MESSAGE_TIMER_EXPIRATIONS 115 o CONTROL_MESSAGE_IMIN 117 o CONTROL_MESSAGE_IMAX 119 o CONTROL_MESSAGE_K 121 o CONTROL_MESSAGE_TIMER_EXPIRATIONS 123 One network may have multiple MPL domains with different 124 configurations. To configure more than one MPL domain via DHCP, 125 there may be more than one MPL Parameter Configuration Option given 126 to DHCP clients from a DHCP server. 128 2.1. MPL Parameter Configuration Option Format 130 To distribute a configuration of an MPL domain or a default value for 131 all MPL domains (wildcard) under the network managed by the DHCP 132 server, this document defines a DHCPv6 option format as follows. 133 Short floating point format is used to describe wide range of timer 134 values. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | OPTION_MPL_PARAMETERS | option_len | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |P| Z | TUNIT | SE_LIFETIME | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | DM_K | DM_IMIN | DM_IMAX > 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 > (cont'ed) | DM_T_EXP | C_K | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | C_IMIN | C_IMAX | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | C_T_EXP | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 (if option_len = 34 ) 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | MPL Domain Address > 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. It SHOULD be 18 (without MPL 168 domain address) or 34 (with MPL domain address) 170 P (1 bit): A flag to indicate PROACTIVE_FORWARDING 172 Z (7 bits) Reserved. Should be 0. 174 TUNIT (unsigned 8 bit integer) Unit time of times in this option. 175 It SHALL NOT be 0 or 255. 177 SE_LIFETIME: SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. It 178 SHALL NOT be 0 or 0xffff. 180 DM_K (unsigned 8 bit integer): DATA_MESSAGE_K. 182 DM_IMIN (unsigned 16 bit integer): DATA_MESSAGE_IMIN/TUNIT in 183 milliseconds. It SHALL NOT be 0 or 0xffff. 185 DM_IMAX (unsigned 16 bit integer): DATA_MESSAGE_IMAX/TUNIT in 186 milliseconds. It SHALL NOT be 0 or 0xffff. 188 DM_T_EXP (unsigned 16 bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS/ 189 TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. 191 C_K (unsigned 8 bit integer): CONTROL_MESSAGE_K. 193 C_IMIN (unsigned 16 bit integer): CONTROL_MESSAGE_IMIN/TUNIT in 194 milliseconds. It SHALL NOT be 0 or 0xffff. 196 C_IMAX: CONTROL_MESSAGE_IMAX/TUNIT in milliseconds. It SHALL NOT be 197 0 or 0xffff. 199 C_T_EXP: CONTROL_MESSAGE_TIMER_EXPIRATIONS/TUNIT in milliseconds. 200 It SHALL NOT be 0 or 0xffff. 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 MPL Parameter Configuration Option, as described 210 in RFC3315 [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 211 and 22.7. As a convenience to the reader, we mention here that the 212 client includes requested option codes in Option Request Option. 214 Clients MUST discard MPL Parameter Configuration Option if it is 215 invalid (e.g. it sets reserved bits or it has timers with reserved 216 exp=7 in Unsigned Short Floating Point). 218 2.3. MPL Forwarder Behavior 220 If a DHCPv6 client requests and receives MPL Parameter Configuration 221 Option, the node MAY join the MPL domain given by the option and act 222 as an MPL forwarder. Each joining node SHOULD configure its MPL 223 forwarder with the given parameter set for the MPL domain. 225 The priority of MPL Parameter Configuration applied for an MPL Domain 226 is as follows (high to low). 228 o Specific MPL Parameter Configuration to the MPL Domain (optlen=34) 230 o Wildcard MPL Parameter Configuration (optlen=18) 232 o Default configuration given in the MPL specification. 234 There SHALL be no more than one MPL Parameter Configuration Option 235 for a MPL domain or the wildcard. Thus, the order of DHCPv6 options 236 in the packet has no effect on precedence. 238 A node MAY leave from an MPL domain if the following two conditions 239 are satisfied. 1) The MPL domain is configured by a DHCPv6 option 240 from a DHCPv6 server previously. 2) The node has received an updated 241 MPL Parameter Configuration Option without a configuration for the 242 MPL domain. 244 MPL parameter may be updated occasionally. With stateful DHCPv6, 245 updates can be done when the renewal timer expires. Information 246 Refresh Time Option [RFC4242] shall be used to keep each forwarders 247 updated. 249 To reduce periodical update traffic a node may try to use very long 250 interval between updates. In the case, reconfigure shall be used to 251 keep forwarder parameter sets synchronized. For stateless DHCPv6, 252 [I-D.jiang-dhc-stateless-reconfiguration] may be used (if approved). 254 2.4. DHCPv6 Server Behavior 256 Sections 17.2.2 and 18.2 of RFC3315 [RFC3315] govern server operation 257 in regards to option assignment. As a convenience to the reader, we 258 mention here that the server will send MPL Parameter Configuration 259 Option only if configured with specific value for MPL Parameter 260 Configuration Option and the client requested it. 262 Servers SHALL ignore incoming MPL Parameter Configuration Option. 264 2.5. DHCPv6 Relay Behavior 266 It's never appropriate for a relay agent to add options to a message 267 heading toward the client, and relay agents don't actually construct 268 Relay-Reply messages anyway. There are no additional requirements 269 for relays. 271 2.6. Operational Considerations 273 A parameter set for an MPL domain SHOULD NOT be updated more often 274 than two times of expected refresh interval. 276 If a node with MPL forwarder configured by MPL Parameter 277 configuration Option failed to refresh the option for two times of 278 information refresh time, it SHALL suspend the MPL forwarders of MPL 279 domains configured by the option. MPL forwarders configured by other 280 methods such as static configuration file SHALL NOT be suspended. 282 3. IANA Considerations 284 A DHCPv6 option code for MPL Parameter Configuration Option needs to 285 be assigned from IANA. 287 4. Security Considerations 288 A forged option may cause excessive layer-2 broadcasting. 289 Implementations should set reasonable bounds for each parameter. For 290 example, not too high K, not too low IMIN, etc. These may be 291 implementation dependent or may be derived from MAC/PHY 292 specifications. DHCP server or the network itself shall be trusted 293 by some means including network access control or DHCP 294 authentications. 296 5. References 298 5.1. Normative References 300 [I-D.ietf-roll-trickle-mcast] 301 Hui, J. and R. Kelsey, "Multicast Forwarding Using 302 Trickle", draft-ietf-roll-trickle-mcast-07 (work in 303 progress), Feburary 2014. 305 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 306 and M. Carney, "Dynamic Host Configuration Protocol for 307 IPv6 (DHCPv6)", RFC 3315, July 2003. 309 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 310 Time Option for Dynamic Host Configuration Protocol for 311 IPv6 (DHCPv6)", RFC 4242, November 2005. 313 5.2. Non-Normative References 315 [I-D.ietf-dhc-option-guidelines] 316 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 317 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 318 draft-ietf-dhc-option-guidelines-17 (work in progress), 319 January 2014. 321 [I-D.jiang-dhc-stateless-reconfiguration] 322 Jiang, S. and B. Liu, "Stateless Reconfiguration in 323 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 324 draft-jiang-dhc-stateless-reconfiguration-01 (work in 325 progress), February 2014. 327 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 328 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 329 BCP 187, RFC 7227, May 2014. 331 Appendix A. Update History 333 Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- 334 mpl-configuration-02: 336 o Short unsigned floating point is dropped (#159) 338 o Packed value is removed and now every value has its own byte(s) 339 (#159) 341 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- 342 mpl-configuration-01: 344 o Operational considerations (normative) and appendix considerations 345 (non-normative) are added (Issue #157) 347 o More control on nodes / allow constrained nodes to ignore the 348 configuration: "the node s/SHOULD/MAY/ join the MPL domain given 349 by the option" (Issue #158) 351 Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll- 352 mpl-configuration-00: 354 o I-D renamed. 356 Appendix B. Considerations on Inconsistent Parameter Set 358 This draft introduces dynamic update of MPL parameters. Because the 359 update process is not synchronized, nodes may have inconsistent 360 parameter set. 362 Inconsistent parameter may reduce performance. On the other hand, it 363 shall work as long as both parameter set are reasonable parameter set 364 for a given communication load. As motivations for parameter update 365 are update on environment, node density, or communication load, 366 operators of MPL networks shall be aware of unupdated nodes and make 367 sure old and new parameter sets are reasonable for expected refresh 368 intervals. 370 Authors' Addresses 371 Yusuke Doi 372 TOSHIBA Corporation 373 Komukai Toshiba Cho 1 374 Saiwai-Ku 375 Kawasaki, Kanagawa 2128582 376 JAPAN 378 Phone: +81-45-342-7230 379 Email: yusuke.doi@toshiba.co.jp 381 Matthew Gillmore 382 Itron, Inc 383 2111 N Molter Rd. 384 Liberty Lake, WA 99019 385 USA 387 Email: matthew.gillmore@itron.com