draft-ietf-roll-mpl-parameter-configuration-07.txt   draft-ietf-roll-mpl-parameter-configuration-08.txt 
roll Y. Doi roll Y. Doi
Internet-Draft TOSHIBA Corporation Internet-Draft TOSHIBA Corporation
Intended status: Standards Track M. Gillmore Intended status: Standards Track M. Gillmore
Expires: March 5, 2016 Itron, Inc Expires: May 5, 2016 Itron, Inc
September 2, 2015 November 2, 2015
MPL Parameter Configuration Option for DHCPv6 MPL Parameter Configuration Option for DHCPv6
draft-ietf-roll-mpl-parameter-configuration-07 draft-ietf-roll-mpl-parameter-configuration-08
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 5, 2016. This Internet-Draft will expire on May 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . 3
2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 6 2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . 7
2.6. Operational Considerations . . . . . . . . . . . . . . . 7 2.6. Operational Considerations . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Considerations on Inconsistent Parameter Set . . . . 9 Appendix A. Update History (TO EDITORS: this section is intended
Appendix B. Update History (TO EDITORS: this section is intended
to be removed before this document becomes an RFC) . 10 to be removed before this document becomes an RFC) . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Multicast Protocol for Low power and Lossy Networks (MPL) Multicast Protocol for Low power and Lossy Networks (MPL)
[I-D.ietf-roll-trickle-mcast] defines a protocol to make a multicast [I-D.ietf-roll-trickle-mcast] defines a protocol to make a multicast
network among low-power and lossy networks, e.g., wireless mesh network among low-power and lossy networks, e.g., wireless mesh
networks. MPL has a set of parameters to control an MPL domain. The 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 parameters control the trade-off between end-to-end delay and network
skipping to change at page 4, line 30 skipping to change at page 4, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (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 (not yet assigned).
option_len: Length of the option. It SHOULD be 16 (without MPL option_len: Length of the option, which is 16 of no MPL domain
domain address) or 32 (with MPL domain address). address is present, or 32 if there is an MPL domain address.
P (1 bit): A flag to indicate PROACTIVE_FORWARDING. The flag is set P (1 bit): A flag to indicate PROACTIVE_FORWARDING. The flag is set
if PROACTIVE_FORWARDING is true. if PROACTIVE_FORWARDING is 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 the bits 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.
skipping to change at page 6, line 37 skipping to change at page 6, line 29
message is considered not received in MPL context and the condition message is considered not received in MPL context and the condition
described in the previous paragraph applies. 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. 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 Section 2 of
[I-D.ietf-roll-trickle-mcast], an MPL Domain Address is an IPv6
multicast address associated to a set of MPL network interfaces in an
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 to the MPL Domain
(option_len=32) (option_len=32)
o Wildcard MPL Parameter Configuration (option_len=16) o Wildcard MPL Parameter Configuration (option_len=16)
o Default configuration given in the MPL specification. o Default configuration given in the MPL specification.
Priority of other configurations such as manual configuration given Priority of other configurations such as manual configuration given
on a node is not defined in the document. on a node is not defined in the 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 SHOULD leave an MPL domain if it receives an updated and all- A node MUST leave an MPL domain if it receives an updated and all-
valid MPL Parameter Configuration Options without a configuration for valid MPL Parameter Configuration Options without a configuration for
the MPL domain, unless it has overriding manual configuration on the the MPL domain, unless it has overriding manual configuration on 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 a MPL
Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY
stay on the MPL domain even if it receives an MPL Parameter stay on the MPL domain even if it receives an MPL Parameter
Configuration Option without configuration for the MPL domain. Configuration Option without 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. Information
Refresh Time Option [RFC4242] shall be used to keep each forwarder Refresh Time Option [RFC4242] shall be used to keep each forwarder
skipping to change at page 8, line 5 skipping to change at page 7, line 44
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's 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 don't 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
update process is not synchronized, nodes may have inconsistent
parameter sets.
[RFC6206] section 6 describe various problems that happens if the [RFC6206] section 6 describe various problems that happens 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 not to 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 in
[RFC3315] or Information Refresh Time in [RFC4242]. [RFC3315] or Information Refresh Time in [RFC4242].
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.
As the motivations for parameter update include update of the
environment, node density, or communication load, operators of MPL
networks shall be aware of unupdated nodes and make sure 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 is requested to assign one option code for OPTION_MPL_PARAMETERS
from the "DHCP Option Codes" table of the Dynamic Host Configuration from the "DHCP Option Codes" table of the Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Registry (http://www.iana.org/assignments/ Protocol 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 There are detailed discussion on security threats on DHCPv6 in
skipping to change at page 8, line 37 skipping to change at page 9, line 9
for each parameter. For example, not too high DM/C_K, not too low DM for each parameter. For example, not too high DM/C_K, not too low DM
/C_IMIN, etc. These bounds may be implementation dependent or may be /C_IMIN, etc. These bounds may be implementation dependent or may be
derived from MAC/PHY specifications. DHCPv6 server and client derived from MAC/PHY specifications. DHCPv6 server and client
implementations need to take care in setting reasonable bounds for implementations need to take care in setting reasonable bounds for
each parameter in order to avoid overloading the network. 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 means
such as DHCPv6 authentications described in Section 21 of RFC3315 such as DHCPv6 authentications described in Section 21 of RFC3315
[RFC3315]. However, ROLL environment may expect less computing [RFC3315]. However, ROLL environment may expect less computing
resource, and DHCPv6 authentication may not available. In such resource, and DHCPv6 authentication may not available. In such
cases, other methods for security should be applied to a ROLL cases, other methods to protect integrity between DHCPv6 servers and
network. Some ROLL specification such as ZigBee IP [ZigBeeIP] clients should be applied to a ROLL network. Some ROLL specification
expects RFC5191 [RFC5191] to authenticate joining nodes and all nodes such as ZigBee IP [ZigBeeIP] expects RFC5191 [RFC5191] to
in the network can be trusted. To protect attacks from outside of authenticate joining nodes and all nodes in the network can be
the network, unnecessary DHCPv6 packets should be filtered on the trusted. To protect attacks from outside of the network, DHCPv6
border router between the ROLL network and the Internet. packets SHOULD be filtered on the border router between the ROLL
network and the Internet, except for the packets between the ROLL
network and a remote DHCPv6 server or DHCPv6 relays configured to
manage the network.
5. References 5. References
5.1. Normative References 5.1. Normative References
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-12 (work in progress), June 2015. mcast-12 (work in progress), June 2015.
skipping to change at page 9, line 33 skipping to change at page 10, line 8
5.2. Informative References 5.2. Informative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[ZigBeeIP] [ZigBeeIP]
ZigBee Alliance, "ZigBee IP Specification", Mar 2014. ZigBee Alliance, "ZigBee IP Specification", Mar 2014.
Appendix A. Considerations on Inconsistent Parameter Set Appendix A. Update History (TO EDITORS: this section is intended to be
removed before this document becomes an RFC)
This draft introduces dynamic update of MPL parameters. Because the Updates on draft-ietf-roll-mpl-configuration-07 to draft-ietf-roll-
update process is not synchronized, nodes may have inconsistent mpl-configuration-08:
parameter sets.
Inconsistent parameter sets may reduce performance. On the other o clarified when to leave (SHOULD->MUST)
hand, this situation will work as long as both new and old parameter
sets are reasonable parameter sets for a given communication load.
As the motivations for parameter update include update of the
environment, node density, or communication load, operators of MPL
networks shall be aware of unupdated nodes and make sure old and new
parameter sets are reasonable for the expected refresh intervals.
Appendix B. Update History (TO EDITORS: this section is intended to be o moved Trickle parameter considerations on appendix to operational
removed before this document becomes an RFC) considerations
o even clarified some texts
Updates on draft-ietf-roll-mpl-configuration-06 to draft-ietf-roll- Updates on draft-ietf-roll-mpl-configuration-06 to draft-ietf-roll-
mpl-configuration-07: mpl-configuration-07:
o clearly stated multiple option support is mandatory (#171) o clearly stated multiple option support is mandatory (#171)
o operational consideration now refers RFC6206 and some texts are o operational consideration now refers RFC6206 and some texts are
moved to section 2.2 (#171) moved to section 2.2 (#171)
o added more per-section reference to I-D.ietf-roll-trickle-mcast o added more per-section reference to I-D.ietf-roll-trickle-mcast
 End of changes. 16 change blocks. 
32 lines changed or deleted 47 lines changed or added

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