1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Internet Engineering Task Force (IETF) Y. Doi
Request for Comments: 7774 Toshiba Corporation
Category: Standards Track M. Gillmore
ISSN: 2070-1721 Itron, Inc.
March 2016
<span class="h1">Multicast Protocol for Low-Power and Lossy Networks (MPL)</span>
<span class="h1">Parameter Configuration Option for DHCPv6</span>
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 is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7774">http://www.rfc-editor.org/info/rfc7774</a>.
<span class="grey">Doi & Gillmore Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. MPL Parameter Configuration Option ..............................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. MPL Parameter Configuration Option Format ..................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. DHCPv6 Client Behavior .....................................<a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. MPL Forwarder Behavior .....................................<a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. DHCPv6 Server Behavior .....................................<a href="#page-7">7</a>
<a href="#section-2.5">2.5</a>. DHCPv6 Relay Behavior ......................................<a href="#page-8">8</a>
<a href="#section-2.6">2.6</a>. Operational Considerations .................................<a href="#page-8">8</a>
<a href="#section-3">3</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. References ......................................................<a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Normative References .......................................<a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Informative References ....................................<a href="#page-10">10</a>
Authors' Addresses ................................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Multicast Protocol for Low-Power and Lossy Networks (MPL)
[<a href="./rfc7731" title=""Multicast Protocol for Low-Power and Lossy Networks (MPL)"">RFC7731</a>] 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
<a href="./rfc7731#section-5.4">Section 5.4 of [RFC7731]</a>, each parameter in the set should be the
same for all nodes within an MPL Domain, but [<a href="./rfc7731" title=""Multicast Protocol for Low-Power and Lossy Networks (MPL)"">RFC7731</a>] does not
define a method to configure the MPL parameter set.
<span class="grey">Doi & Gillmore Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
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). A parameter set is required to configure
an MPL Domain.
This document defines a way to distribute parameter sets for MPL
Forwarders via a new DHCPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] option. This document is
intended to follow the guidelines provided in [<a href="./rfc7227" title=""Guidelines for Creating New DHCPv6 Options"">RFC7227</a>].
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. MPL Parameter Configuration Option</span>
As defined in <a href="./rfc7731#section-5.4">Section 5.4 of [RFC7731]</a>, there are 10 parameters per
MPL Domain, as listed below. An MPL Domain is defined by an MPL
Domain Address, as described in <a href="./rfc7731#section-2">Section 2 of [RFC7731]</a>.
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.
<span class="grey">Doi & Gillmore Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. MPL Parameter Configuration Option Format</span>
This document defines the OPTION_MPL_PARAMETERS DHCPv6 option. This
new option provides a means to distribute a configuration of an MPL
Domain or a default value for all MPL Domains (a wildcard) within the
network managed by the DHCP server. This option has the following
format:
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 (128 bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_MPL_PARAMETERS: DHCPv6 option identifier (104).
option_len: Length of the option in octets. The value MUST be
set to 16 if no MPL Domain Address is present, or 32 if an
MPL Domain Address is present.
P (1 bit): A flag to indicate PROACTIVE_FORWARDING. This flag is
set if PROACTIVE_FORWARDING = TRUE.
Z (7 bits): Reserved for future use. Servers MUST set them to zero.
Clients SHOULD ignore any bits that have been 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.
<span class="grey">Doi & Gillmore Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
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
DATA_MESSAGE_IMIN, as described in <a href="./rfc6206#section-4.1">[RFC6206], Section 4.1</a>.
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 to a
precision of TUNIT milliseconds in MPL Parameter Configuration
Options. For example, if TUNIT is 20 and the minimum Data Message
interval (DATA_MESSAGE_IMIN) is 1000 ms, then DM_IMIN shall be set
to 50.
For the maximum interval size (*_IMAX), [<a href="./rfc6206" title=""The Trickle Algorithm"">RFC6206</a>] 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.
<span class="grey">Doi & Gillmore Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
Because the minimum interval size in MPL Parameter Configuration
Options is described in TUNIT-millisecond precision, the
corresponding maximum interval size is also in TUNIT-millisecond
precision. For example, if TUNIT is 10 and C_IMIN is 50, the minimum
interval size of the Trickle timer for Control Messages is 500 ms.
In this case, the maximum interval size of the Trickle timer is
32 seconds (500 ms * 2^6) if C_IMAX is 6.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. DHCPv6 Client Behavior</span>
Clients MAY request the MPL Parameter Configuration Option as
described in Sections <a href="#section-17.1.1">17.1.1</a>, <a href="#section-18.1.1">18.1.1</a>, <a href="#section-18.1.3">18.1.3</a>, <a href="#section-18.1.4">18.1.4</a>, <a href="#section-18.1.5">18.1.5</a>, and
22.7 of [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]. 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 Options,
which are listed in <a href="#section-2">Section 2</a>.
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 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] of the last valid DHCPv6 message
sent from the server (if stateful) or twice the information refresh
time [<a href="./rfc4242" title=""Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC4242</a>] (if stateless), it MUST suspend the MPL Forwarders of
the MPL Domains configured by the option. MPL Forwarders configured
by other methods (e.g., via a static configuration file) MUST NOT be
suspended.
Clients MUST ignore all MPL Parameter Configuration Options if the
options in a DHCPv6 message contain any invalid values (e.g.,
reserved all-0 or all-1 values are used in parameters). In this
case, in the context of MPL the message is considered not received,
and the condition described in the previous paragraph applies.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. MPL Forwarder Behavior</span>
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. Each MPL
Domain is defined by an MPL Domain Address given by an MPL Parameter
Configuration Option. As defined in <a href="./rfc7731#section-2">Section 2 of [RFC7731]</a>, an MPL
Domain Address is an IPv6 multicast address associated to a set of
MPL network interfaces in an MPL Domain.
<span class="grey">Doi & Gillmore Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
The priority of MPL parameter configurations applied to an MPL Domain
is as follows (high to low):
o Specific MPL parameter configuration for the MPL Domain
(option_len = 32 bits).
o Wildcard MPL parameter configuration (option_len = 16 bits).
o Default configuration as described in [<a href="./rfc7731" title=""Multicast Protocol for Low-Power and Lossy Networks (MPL)"">RFC7731</a>].
Priorities of other configurations, such as manual configuration of a
node, are not defined in this document.
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 MUST leave an MPL Domain if it receives updated and all-valid
MPL Parameter Configuration Options without a configuration for the
MPL Domain, unless it has an overriding manual configuration for the
MPL Domain. In other words, if a node is configured to work as an
MPL Forwarder for an MPL Domain regardless of DHCPv6 options, the
node MAY stay in the MPL Domain even if it receives an 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. The information
refresh time option [<a href="./rfc4242" title=""Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC4242</a>] 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.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. DHCPv6 Server Behavior</span>
Sections <a href="#section-17.2.2">17.2.2</a> and <a href="#section-18.2">18.2</a> of [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] govern server operation in
regard 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 Options,
which are listed in <a href="#section-2">Section 2</a>.
<span class="grey">Doi & Gillmore Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. DHCPv6 Relay Behavior</span>
It is never appropriate for a relay agent to add options to a message
heading toward the client, and relay agents do not actually construct
Relay-Reply messages anyway. There are no additional requirements
for relays.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Operational Considerations</span>
This document introduces the dynamic updating of MPL parameters.
Because the update process is not synchronized, nodes may have
inconsistent parameter sets.
<a href="./rfc6206#section-6">[RFC6206], Section 6</a> describes various problems that occur if the
Trickle timers do not match between communicating nodes. To keep the
timers synchronized, it is RECOMMENDED to not 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 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]
or information refresh time as defined in [<a href="./rfc4242" title=""Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC4242</a>].
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.
Because motivations for parameter updates include updates of the
environment, node density, or communication load, operators of MPL
networks need to be aware of nodes that are not updated and make sure
that old and new parameter sets are reasonable for the expected
refresh intervals.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IANA Considerations</span>
IANA has assigned an option code to OPTION_MPL_PARAMETERS (104) from
the "Option Codes" table of the "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)" registry (<a href="http://www.iana.org/assignments/dhcpv6-parameters">http://www.iana.org/assignments/</a>
<a href="http://www.iana.org/assignments/dhcpv6-parameters">dhcpv6-parameters</a>).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
<a href="./rfc3315#section-23">Section 23 of [RFC3315]</a>, <a href="./rfc7227#section-23">Section 23 of [RFC7227]</a>, and <a href="./rfc7731#section-12">Section 12 of
[RFC7731]</a> provide detailed discussions regarding security threats for
DHCPv6.
Note also that a forged MPL parameter configuration may cause
excessive Layer 2 broadcasting. Implementations should set
reasonable bounds for each parameter -- for example, not setting
DM/C_K too high, not setting DM/C_IMIN too low. These bounds may be
implementation dependent or may be derived from MAC/PHY
<span class="grey">Doi & Gillmore Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
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 authentication as described in <a href="./rfc3315#section-21">Section 21 of
[RFC3315]</a>. However, Routing Over Low-Power and Lossy (ROLL) network
environments often have fewer computing resources, and DHCPv6
authentication may not be available in these environments. In such
cases, other methods to protect integrity between DHCPv6 servers and
clients should be applied to a ROLL network. Some specifications
related to ROLL implementations, such as ZigBee IP [<a href="#ref-ZigBeeIP">ZigBeeIP</a>] and
[<a href="./rfc5191" title=""Protocol for Carrying Authentication for Network Access (PANA)"">RFC5191</a>], assume that joining nodes will be authenticated so that
all nodes in the network can be trusted. To protect against attacks
from outside of the network, DHCPv6 packets SHOULD be filtered on the
border router between the ROLL network and the Internet, except for
packets between the ROLL network and a remote DHCPv6 server or DHCPv6
relays configured to manage the network.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, DOI 10.17487/RFC3315,
July 2003, <<a href="http://www.rfc-editor.org/info/rfc3315">http://www.rfc-editor.org/info/rfc3315</a>>.
[<a id="ref-RFC4242">RFC4242</a>] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", <a href="./rfc4242">RFC 4242</a>, DOI 10.17487/RFC4242,
November 2005, <<a href="http://www.rfc-editor.org/info/rfc4242">http://www.rfc-editor.org/info/rfc4242</a>>.
[<a id="ref-RFC6206">RFC6206</a>] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", <a href="./rfc6206">RFC 6206</a>, DOI 10.17487/RFC6206,
March 2011, <<a href="http://www.rfc-editor.org/info/rfc6206">http://www.rfc-editor.org/info/rfc6206</a>>.
<span class="grey">Doi & Gillmore Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7774">RFC 7774</a> MPL Configuration for DHCPv6 March 2016</span>
[<a id="ref-RFC7227">RFC7227</a>] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
<a href="https://www.rfc-editor.org/bcp/bcp187">BCP 187</a>, <a href="./rfc7227">RFC 7227</a>, DOI 10.17487/RFC7227, May 2014,
<<a href="http://www.rfc-editor.org/info/rfc7227">http://www.rfc-editor.org/info/rfc7227</a>>.
[<a id="ref-RFC7731">RFC7731</a>] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", <a href="./rfc7731">RFC 7731</a>, DOI 10.17487/RFC7731,
February 2016, <<a href="http://www.rfc-editor.org/info/rfc7731">http://www.rfc-editor.org/info/rfc7731</a>>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-RFC5191">RFC5191</a>] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", <a href="./rfc5191">RFC 5191</a>, DOI 10.17487/RFC5191,
May 2008, <<a href="http://www.rfc-editor.org/info/rfc5191">http://www.rfc-editor.org/info/rfc5191</a>>.
[<a id="ref-ZigBeeIP">ZigBeeIP</a>]
ZigBee Alliance, "ZigBee IP Specification", 2015,
<<a href="http://www.zigbee.org/">http://www.zigbee.org/</a>>.
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
Matthew Gillmore
Itron, Inc.
2111 N. Molter Rd.
Liberty Lake, WA 99019
United States
Email: matthew.gillmore@itron.com
Doi & Gillmore Standards Track [Page 10]
</pre>
|
