draft-ietf-roll-mpl-parameter-configuration-08.txt   rfc7774.txt 
roll Y. Doi Internet Engineering Task Force (IETF) Y. Doi
Internet-Draft TOSHIBA Corporation Request for Comments: 7774 Toshiba Corporation
Intended status: Standards Track M. Gillmore Category: Standards Track M. Gillmore
Expires: May 5, 2016 Itron, Inc ISSN: 2070-1721 Itron, Inc.
November 2, 2015 March 2016
MPL Parameter Configuration Option for DHCPv6 Multicast Protocol for Low-Power and Lossy Networks (MPL)
draft-ietf-roll-mpl-parameter-configuration-08 Parameter Configuration Option for DHCPv6
Abstract Abstract
This document defines a way to configure a parameter set for MPL This document defines a way to configure a parameter set for MPL
(Multicast Protocol for Low power and Lossy Networks) via a DHCPv6 (Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6
option. MPL has a set of parameters to control its behavior, and the option. MPL has a set of parameters to control its behavior, and the
parameter set is often configured as a network-wide parameter because parameter set is often configured as a network-wide parameter because
the parameter set should be identical for each MPL forwarder in an the parameter set should be identical for each MPL Forwarder in an
MPL domain. Using the MPL Parameter Configuration Option defined in MPL Domain. Using the MPL Parameter Configuration Option defined in
this document, a network can easily be configured with a single set this document, a network can easily be configured with a single set
of MPL parameters. of MPL parameters.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 5, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7774.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
2. MPL Parameter Configuration Option . . . . . . . . . . . . . 3 2. MPL Parameter Configuration Option ..............................3
2.1. MPL Parameter Configuration Option Format . . . . . . . . 3 2.1. MPL Parameter Configuration Option Format ..................4
2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5 2.2. DHCPv6 Client Behavior .....................................6
2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 6 2.3. MPL Forwarder Behavior .....................................6
2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 2.4. DHCPv6 Server Behavior .....................................7
2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 7 2.5. DHCPv6 Relay Behavior ......................................8
2.6. Operational Considerations . . . . . . . . . . . . . . . 7 2.6. Operational Considerations .................................8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations .............................................8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations .........................................8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. References ......................................................9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9 5.1. Normative References .......................................9
5.2. Informative References . . . . . . . . . . . . . . . . . 9 5.2. Informative References ....................................10
Appendix A. Update History (TO EDITORS: this section is intended Authors' Addresses ................................................10
to be removed before this document becomes an RFC) . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Multicast Protocol for Low power and Lossy Networks (MPL) The Multicast Protocol for Low-Power and Lossy Networks (MPL)
[I-D.ietf-roll-trickle-mcast] defines a protocol to make a multicast [RFC7731] defines a protocol to make a multicast network among
network among low-power and lossy networks, e.g., wireless mesh low-power and lossy networks, e.g., wireless mesh networks. MPL has
networks. MPL has a set of parameters to control an MPL domain. The a set of parameters to control an MPL Domain. The parameters control
parameters control the trade-off between end-to-end delay and network the trade-off between end-to-end delay and network utilization. In
utilization. In most environments, the default parameters are most environments, the default parameters are acceptable. However,
acceptable. However, in some environments, the parameter set must be in some environments, the parameter set must be configured carefully
configured carefully in order to meet the requirements of each in order to meet the requirements of each environment. According to
environment. According to the MPL document section 5.4, each Section 5.4 of [RFC7731], each parameter in the set should be the
parameter in the set should be the same for all nodes within an MPL same for all nodes within an MPL Domain, but [RFC7731] does not
domain, but the MPL document does not define a method to configure define a method to configure the MPL parameter set.
the MPL parameter set.
Some managed wireless mesh networks may have a DHCP server to Some managed wireless mesh networks may have a DHCP server to
configure network parameters. MPL parameter sets shall be considered configure network parameters. MPL parameter sets shall be considered
as a part of network parameters (nodes in an MPL domain should use an as a part of network parameters (nodes in an MPL Domain should use an
identical parameter set). And a parameter set is required to identical parameter set). A parameter set is required to configure
configure an MPL domain. an MPL Domain.
This document defines the way to distribute parameter sets for MPL This document defines a way to distribute parameter sets for MPL
forwarders as a DHCPv6 [RFC3315] option. This document is intended Forwarders via a new DHCPv6 [RFC3315] option. This document is
to follow [RFC7227] the guideline. intended to follow the guidelines provided in [RFC7227].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. MPL Parameter Configuration Option 2. MPL Parameter Configuration Option
As stated in Section 5.4 of [I-D.ietf-roll-trickle-mcast], there are As defined in Section 5.4 of [RFC7731], there are 10 parameters per
the following 10 parameters per MPL domain. An MPL domain is defined MPL Domain, as listed below. An MPL Domain is defined by an MPL
by an MPL domain address, as described in Section 2 of Domain Address, as described in Section 2 of [RFC7731].
[I-D.ietf-roll-trickle-mcast].
o PROACTIVE_FORWARDING o PROACTIVE_FORWARDING
o SEED_SET_ENTRY_LIFETIME o SEED_SET_ENTRY_LIFETIME
o DATA_MESSAGE_IMIN o DATA_MESSAGE_IMIN
o DATA_MESSAGE_IMAX o DATA_MESSAGE_IMAX
o DATA_MESSAGE_K o DATA_MESSAGE_K
skipping to change at page 3, line 36 skipping to change at page 3, line 45
o DATA_MESSAGE_TIMER_EXPIRATIONS o DATA_MESSAGE_TIMER_EXPIRATIONS
o CONTROL_MESSAGE_IMIN o CONTROL_MESSAGE_IMIN
o CONTROL_MESSAGE_IMAX o CONTROL_MESSAGE_IMAX
o CONTROL_MESSAGE_K o CONTROL_MESSAGE_K
o CONTROL_MESSAGE_TIMER_EXPIRATIONS o CONTROL_MESSAGE_TIMER_EXPIRATIONS
One network may have multiple MPL domains with different One network may have multiple MPL Domains with different
configurations. To configure more than one MPL domain via DHCP, configurations. To configure more than one MPL Domain via DHCP,
there may be more than one MPL Parameter Configuration Option given there may be more than one MPL Parameter Configuration Option given
to DHCP clients by a DHCP server. to DHCP clients by a DHCP server.
2.1. MPL Parameter Configuration Option Format 2.1. MPL Parameter Configuration Option Format
To distribute a configuration of an MPL domain or a default value for This document defines the OPTION_MPL_PARAMETERS DHCPv6 option. This
all MPL domains (wildcard) under the network managed by the DHCP new option provides a means to distribute a configuration of an MPL
server, this document defines a DHCPv6 option format as follows. 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
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 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 | | OPTION_MPL_PARAMETERS | option_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Z | TUNIT | SE_LIFETIME | |P| Z | TUNIT | SE_LIFETIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DM_K | DM_IMIN | DM_IMAX | | DM_K | DM_IMIN | DM_IMAX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DM_T_EXP | C_K | C_IMIN > | DM_T_EXP | C_K | C_IMIN >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>(cont'ed) | C_IMAX | C_T_EXP | >(cont'ed) | C_IMAX | C_T_EXP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(if option_len = 32 ) (if option_len = 32)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPL Domain Address (128bits) > | MPL Domain Address (128 bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) > > (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) > > (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) | > (cont'ed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned). OPTION_MPL_PARAMETERS: DHCPv6 option identifier (104).
option_len: Length of the option, which is 16 of no MPL domain option_len: Length of the option in octets. The value MUST be
address is present, or 32 if there is an MPL domain address. 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. The flag is set P (1 bit): A flag to indicate PROACTIVE_FORWARDING. This flag is
if PROACTIVE_FORWARDING is true. set if PROACTIVE_FORWARDING = TRUE.
Z (7 bits): Reserved for future use. Servers MUST set them to zero. Z (7 bits): Reserved for future use. Servers MUST set them to zero.
Clients SHOULD ignore the bits set. Clients SHOULD ignore any bits that have been set.
TUNIT (unsigned 8-bit integer): Unit time of timer parameters TUNIT (unsigned 8-bit integer): Unit time of timer parameters
(SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved (SE_LIFETIME and *_IMIN) in this option. 0 and 0xff are reserved
and MUST NOT be used. and MUST NOT be used.
SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT SE_LIFETIME (unsigned 16-bit integer):
in milliseconds. 0 and 0xffff are reserved and MUST NOT be used. 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_K (unsigned 8-bit integer): DATA_MESSAGE_K.
DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT in DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT,
milliseconds. 0 and 0xffff are reserved and MUST NOT be used. in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual
maximum timeout is described as a number of doublings of maximum timeout is described as a number of doublings of
DATA_MESSAGE_IMIN, as described in [RFC6206] Section 4.1. 0 and DATA_MESSAGE_IMIN, as described in [RFC6206], Section 4.1.
0xff are reserved and MUST NOT be used. 0 and 0xff are reserved and MUST NOT be used.
DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS. DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS.
0 and 0xffff are reserved and MUST NOT be used. 0 and 0xffff are reserved and MUST NOT be used.
C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K. C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K.
C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT in C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT,
milliseconds. 0 and 0xffff are reserved and MUST NOT be used. in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. The actual C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. The actual
maximum timeout is described as a number of doublings of maximum timeout is described as a number of doublings of
CONTROL_MESSAGE_IMIN. 0 and 0xff are reserved and MUST NOT be CONTROL_MESSAGE_IMIN. 0 and 0xff are reserved and MUST NOT
used. be used.
C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS C_T_EXP (unsigned 16-bit integer):
. 0 and 0xffff are reserved and MUST NOT be used. CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and
MUST NOT be used.
Note that the time values (SEED_SET_ENTRY_LIFETIME, Note that the time values (SEED_SET_ENTRY_LIFETIME,
DATA_MESSAGE_IMIN, and CONTROL_MESSAGE_IMIN) in MPL are defined in DATA_MESSAGE_IMIN, and CONTROL_MESSAGE_IMIN) in MPL are defined to a
TUNIT milliseconds precision in MPL Parameter Configuration Options. precision of TUNIT milliseconds in MPL Parameter Configuration
For example, if TUNIT is 20 and the data message interval minimum Options. For example, if TUNIT is 20 and the minimum Data Message
(DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50. interval (DATA_MESSAGE_IMIN) is 1000 ms, then DM_IMIN shall be set
to 50.
For maximum interval size (*_IMAX), [RFC6206] defines them as For the maximum interval size (*_IMAX), [RFC6206] defines them as
follows: follows:
The maximum interval size, Imax, is described as a number of The maximum interval size, Imax, is described as a number of
doublings of the minimum interval size (the base-2 log(max/min)). doublings of the minimum interval size (the base-2 log(max/min)).
For example, a protocol might define Imax as 16. If the minimum 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 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 100 ms * 65,536, i.e., 6,553.6 seconds or approximately
minutes. 109 minutes.
Because minimum interval size in the MPL Parameter Configuration Because the minimum interval size in MPL Parameter Configuration
Options is described as TUNIT millisecond precision, corresponding Options is described in TUNIT-millisecond precision, the
maximum interval size is also in TUNIT precision. For example, if corresponding maximum interval size is also in TUNIT-millisecond
TUNIT is 10 and C_IMIN is 50, the minimum interval size of the precision. For example, if TUNIT is 10 and C_IMIN is 50, the minimum
trickle timer for control messages is 500ms. In this case, the interval size of the Trickle timer for Control Messages is 500 ms.
maximum interval size of the trickle timer is 32 seconds (500ms * In this case, the maximum interval size of the Trickle timer is
2^6) if C_IMAX is 6. 32 seconds (500 ms * 2^6) if C_IMAX is 6.
2.2. DHCPv6 Client Behavior 2.2. DHCPv6 Client Behavior
Clients MAY request the MPL Parameter Configuration Option, as 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, described in Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and
18.1.5, and 22.7. As a convenience to the reader, we mention here 22.7 of [RFC3315]. As a convenience to the reader, we mention here
that the client includes requested option codes in the Option Request that the client includes requested option codes in the Option Request
Option. Option.
Clients MUST support multiple MPL Parameter Configuration Option, as Clients MUST support multiple MPL Parameter Configuration Options,
stated in section 2. which are listed in Section 2.
If a DHCPv6 client with an MPL forwarder configured by the MPL If a DHCPv6 client with an MPL Forwarder configured by the MPL
Parameter Configuration Option is unable to receive a valid response Parameter Configuration Option is unable to receive a valid response
from a server within T2 of the last valid DHCPv6 message sent from from a server within T2 [RFC3315] of the last valid DHCPv6 message
the server (if stateful) or twice the Information Refresh Time (if sent from the server (if stateful) or twice the information refresh
stateless), it MUST suspend the MPL forwarders of the MPL domains time [RFC4242] (if stateless), it MUST suspend the MPL Forwarders of
configured by the option. MPL forwarders configured by other methods the MPL Domains configured by the option. MPL Forwarders configured
such as static configuration file MUST NOT be suspended. by other methods (e.g., via a static configuration file) MUST NOT be
suspended.
Clients MUST ignore all MPL Parameter Configuration Options if the Clients MUST ignore all MPL Parameter Configuration Options if the
options in a DHCPv6 message contains any invalid value (e.g., it uses options in a DHCPv6 message contain any invalid values (e.g.,
reserved all-0 or all-1 values in parameters). In this case, the reserved all-0 or all-1 values are used in parameters). In this
message is considered not received in MPL context and the condition case, in the context of MPL the message is considered not received,
described in the previous paragraph applies. and the condition described in the previous paragraph applies.
2.3. MPL Forwarder Behavior 2.3. MPL Forwarder Behavior
If a DHCPv6 client requests and receives the MPL Parameter If a DHCPv6 client requests and receives the MPL Parameter
Configuration Option, the node SHOULD join the MPL domain given by 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 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 in which a node may fail to join a domain (or domains) due to local
resource constraints. Each joining node SHOULD configure its MPL resource constraints. Each joining node SHOULD configure its MPL
forwarder with the given parameter set for the MPL domain. Each 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 Domain is defined by an MPL Domain Address given by an MPL Parameter
Configuration Option. As defined in Section 2 of Configuration Option. As defined in Section 2 of [RFC7731], an MPL
[I-D.ietf-roll-trickle-mcast], an MPL Domain Address is an IPv6 Domain Address is an IPv6 multicast address associated to a set of
multicast address associated to a set of MPL network interfaces in an MPL network interfaces in an MPL Domain.
MPL Domain.
The priority of MPL Parameter Configurations applied to an MPL Domain The priority of MPL parameter configurations applied to an MPL Domain
is as follows (high to low): is as follows (high to low):
o Specific MPL Parameter Configuration to the MPL Domain o Specific MPL parameter configuration for the MPL Domain
(option_len=32) (option_len = 32 bits).
o Wildcard MPL Parameter Configuration (option_len=16) o Wildcard MPL parameter configuration (option_len = 16 bits).
o Default configuration given in the MPL specification. o Default configuration as described in [RFC7731].
Priority of other configurations such as manual configuration given Priorities of other configurations, such as manual configuration of a
on a node is not defined in the document. node, are not defined in this document.
There MUST be no more than one MPL Parameter Configuration Option for 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 an MPL Domain or the wildcard. Thus, the order of DHCPv6 options in
the packet has no effect on precedence. the packet has no effect on precedence.
A node MUST leave an MPL domain if it receives an updated and all- A node MUST leave an MPL Domain if it receives updated and all-valid
valid MPL Parameter Configuration Options without a configuration for MPL Parameter Configuration Options without a configuration for the
the MPL domain, unless it has overriding manual configuration on 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 a MPL MPL Domain. In other words, if a node is configured to work as an
Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY MPL Forwarder for an MPL Domain regardless of DHCPv6 options, the
stay on the MPL domain even if it receives an MPL Parameter node MAY stay in the MPL Domain even if it receives an MPL Parameter
Configuration Option without configuration for the MPL domain. Configuration Option without a configuration for the MPL Domain.
MPL parameters may be updated occasionally. With stateful DHCPv6, MPL parameters may be updated occasionally. With stateful DHCPv6,
updates can be done when the renewal timer expires. Information updates can be done when the renewal timer expires. The information
Refresh Time Option [RFC4242] shall be used to keep each forwarder refresh time option [RFC4242] shall be used to keep each forwarder
updated. updated.
To reduce periodic update traffic, a node may try to use a very long To reduce periodic update traffic, a node may try to use a very long
interval between updates. In this case, reconfigure messages may be interval between updates. In this case, Reconfigure messages may be
used to keep forwarder parameter sets synchronized. used to keep forwarder parameter sets synchronized.
2.4. DHCPv6 Server Behavior 2.4. DHCPv6 Server Behavior
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
regards to option assignment. As a convenience to the reader, we regard to option assignment. As a convenience to the reader, we
mention here that the server will send the MPL Parameter mention here that the server will send the MPL Parameter
Configuration Option only if it was configured with specific values Configuration Option only if it was configured with specific values
for the MPL Parameter Configuration Option and the client requested for the MPL Parameter Configuration Option and the client
it. requested it.
Servers MUST ignore an incoming MPL Parameter Configuration Option. Servers MUST ignore an incoming MPL Parameter Configuration Option.
Servers MUST support multiple MPL Parameter Configuration Option, as Servers MUST support multiple MPL Parameter Configuration Options,
stated in section 2. which are listed in Section 2.
2.5. DHCPv6 Relay Behavior 2.5. DHCPv6 Relay Behavior
It's never appropriate for a relay agent to add options to a message It is never appropriate for a relay agent to add options to a message
heading toward the client, and relay agents don't actually construct heading toward the client, and relay agents do not actually construct
Relay-Reply messages anyway. There are no additional requirements Relay-Reply messages anyway. There are no additional requirements
for relays. for relays.
2.6. Operational Considerations 2.6. Operational Considerations
This draft introduces dynamic update of MPL parameters. Because the This document introduces the dynamic updating of MPL parameters.
update process is not synchronized, nodes may have inconsistent Because the update process is not synchronized, nodes may have
parameter sets. inconsistent parameter sets.
[RFC6206] section 6 describe various problems that happens if the [RFC6206], Section 6 describes various problems that occur if the
trickle timers do not match between communicating nodes. To keep the Trickle timers do not match between communicating nodes. To keep the
timers synchronized, it is RECOMMENDED not to update the parameters timers synchronized, it is RECOMMENDED to not update the parameters
of an MPL domain too often. A reasonable update rate would be once of an MPL Domain too often. A reasonable update rate would be once
per expected information refresh time interval, such as T1 in per expected information refresh time interval, such as T1 [RFC3315]
[RFC3315] or Information Refresh Time in [RFC4242]. or information refresh time as defined in [RFC4242].
Inconsistent parameter sets may reduce performance. On the other Inconsistent parameter sets may reduce performance. On the other
hand, this situation will work as long as both new and old parameter hand, this situation will work as long as both new and old parameter
sets are reasonable parameter sets for a given communication load. sets are reasonable parameter sets for a given communication load.
As the motivations for parameter update include update of the Because motivations for parameter updates include updates of the
environment, node density, or communication load, operators of MPL environment, node density, or communication load, operators of MPL
networks shall be aware of unupdated nodes and make sure old and new networks need to be aware of nodes that are not updated and make sure
parameter sets are reasonable for the expected refresh intervals. that old and new parameter sets are reasonable for the expected
refresh intervals.
3. IANA Considerations 3. IANA Considerations
IANA is requested to assign one option code for OPTION_MPL_PARAMETERS IANA has assigned an option code to OPTION_MPL_PARAMETERS (104) from
from the "DHCP Option Codes" table of the Dynamic Host Configuration the "Option Codes" table of the "Dynamic Host Configuration Protocol
Protocol for IPv6 (DHCPv6) Registry (http://www.iana.org/assignments/ for IPv6 (DHCPv6)" registry (http://www.iana.org/assignments/
dhcpv6-parameters). dhcpv6-parameters).
4. Security Considerations 4. Security Considerations
There are detailed discussion on security threats on DHCPv6 in Section 23 of [RFC3315], Section 23 of [RFC7227], and Section 12 of
Section 23 of RFC3315 [RFC3315], Section 23 of RFC7227 [RFC7227], and [RFC7731] provide detailed discussions regarding security threats for
Section 13 of [I-D.ietf-roll-trickle-mcast]. DHCPv6.
In addition, a forged MPL parameter configuration may cause excessive Note also that a forged MPL parameter configuration may cause
layer-2 broadcasting. Implementations should set reasonable bounds excessive Layer 2 broadcasting. Implementations should set
for each parameter. For example, not too high DM/C_K, not too low DM reasonable bounds for each parameter -- for example, not setting
/C_IMIN, etc. These bounds may be implementation dependent or may be DM/C_K too high, not setting DM/C_IMIN too low. These bounds may be
derived from MAC/PHY specifications. DHCPv6 server and client implementation dependent or may be derived from MAC/PHY
implementations need to take care in setting reasonable bounds for specifications. DHCPv6 server and client implementations need to
each parameter in order to avoid overloading the network. 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 The DHCP server or the network itself should be trusted by some
such as DHCPv6 authentications described in Section 21 of RFC3315 means, such as DHCPv6 authentication as described in Section 21 of
[RFC3315]. However, ROLL environment may expect less computing [RFC3315]. However, Routing Over Low-Power and Lossy (ROLL) network
resource, and DHCPv6 authentication may not available. In such 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 cases, other methods to protect integrity between DHCPv6 servers and
clients should be applied to a ROLL network. Some ROLL specification clients should be applied to a ROLL network. Some specifications
such as ZigBee IP [ZigBeeIP] expects RFC5191 [RFC5191] to related to ROLL implementations, such as ZigBee IP [ZigBeeIP] and
authenticate joining nodes and all nodes in the network can be [RFC5191], assume that joining nodes will be authenticated so that
trusted. To protect attacks from outside of the network, DHCPv6 all nodes in the network can be trusted. To protect against attacks
packets SHOULD be filtered on the border router between the ROLL from outside of the network, DHCPv6 packets SHOULD be filtered on the
network and the Internet, except for the packets between the ROLL border router between the ROLL network and the Internet, except for
network and a remote DHCPv6 server or DHCPv6 relays configured to packets between the ROLL network and a remote DHCPv6 server or DHCPv6
manage the network. relays configured to manage the network.
5. References 5. References
5.1. Normative 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005. IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242,
November 2005, <http://www.rfc-editor.org/info/rfc4242>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>. March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, May 2014. BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.
5.2. Informative References 5.2. Informative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
Yegin, "Protocol for Carrying Authentication for Network and A. Yegin, "Protocol for Carrying Authentication for
Access (PANA)", RFC 5191, May 2008. Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[ZigBeeIP] [ZigBeeIP]
ZigBee Alliance, "ZigBee IP Specification", Mar 2014. ZigBee Alliance, "ZigBee IP Specification", 2015,
<http://www.zigbee.org/>.
Appendix A. Update History (TO EDITORS: this section is intended to be
removed before this document becomes an RFC)
Updates on draft-ietf-roll-mpl-configuration-07 to draft-ietf-roll-
mpl-configuration-08:
o clarified when to leave (SHOULD->MUST)
o moved Trickle parameter considerations on appendix to operational
considerations
o even clarified some texts
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
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 Authors' Addresses
Yusuke Doi Yusuke Doi
TOSHIBA Corporation Toshiba Corporation
Komukai Toshiba Cho 1 Komukai Toshiba Cho 1
Saiwai-Ku Saiwai-Ku
Kawasaki, Kanagawa 2128582 Kawasaki, Kanagawa 2128582
JAPAN Japan
Phone: +81-45-342-7230 Phone: +81-45-342-7230
Email: yusuke.doi@toshiba.co.jp Email: yusuke.doi@toshiba.co.jp
Matthew Gillmore Matthew Gillmore
Itron, Inc Itron, Inc.
2111 N Molter Rd. 2111 N. Molter Rd.
Liberty Lake, WA 99019 Liberty Lake, WA 99019
USA United States
Email: matthew.gillmore@itron.com Email: matthew.gillmore@itron.com
 End of changes. 73 change blocks. 
297 lines changed or deleted 215 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/