draft-ietf-roll-mpl-parameter-configuration-04.txt   draft-ietf-roll-mpl-parameter-configuration-05.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: October 24, 2015 Itron, Inc Expires: January 1, 2016 Itron, Inc
April 22, 2015 June 30, 2015
MPL Parameter Configuration Option for DHCPv6 MPL Parameter Configuration Option for DHCPv6
draft-ietf-roll-mpl-parameter-configuration-04 draft-ietf-roll-mpl-parameter-configuration-05
Abstract Abstract
This draft defines a way to configure a parameter set of MPL This document defines a way to configure a parameter set for MPL
(Multicast Protocol for Low power and Lossy Networks) via 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 be configured with a single set of MPL this document, a network can be configured with a single set of MPL
parameter easily. parameters easily.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 24, 2015. This Internet-Draft will expire on January 1, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . 5 2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5
2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 5 2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 5
2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 6 2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 6
2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 6 2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 6
2.6. Operational Considerations . . . . . . . . . . . . . . . 6 2.6. Operational Considerations . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Update History . . . . . . . . . . . . . . . . . . . 7 Appendix A. Update History . . . . . . . . . . . . . . . . . . . 8
Appendix B. Considerations on Inconsistent Parameter Set . . . . 8 Appendix B. Considerations on Inconsistent Parameter Set . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 network 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
parameter controls trade-off between end-to-end delay and network parameters control the trade-off between end-to-end delay and network
utilization. In most environments, the default parameters are utilization. In most environments, the default parameters are
acceptable. However, in some environments, the parameter set must be acceptable. However, in some environments, the parameter set must be
configured carefully in order to meet the requirements of each configured carefully in order to meet the requirements of each
environment. According to the MPL draft section 5.4, each parameter environment. According to the MPL document section 5.4, each
in the set should be same for all nodes within an MPL domain. And parameter in the set should be the same for all nodes within an MPL
the MPL draft does not define a method to configure the MPL parameter domain, but the MPL document does not define a method to configure
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 set 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 are required to identical parameter set). And a parameter set is required to
configure an MPL domain. configure an MPL domain.
This document is to define the way to distribute parameter sets for This document defines the way to distribute parameter sets for MPL
MPL forwarders as a DHCPv6 [RFC3315] option. This document is forwarders as a DHCPv6 [RFC3315] option. This document is intended
intended to follow the guideline [RFC7227]. to follow [RFC7227] the guideline.
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
Per MPL domain, there are following 10 parameters. An MPL domain is Per MPL domain, there are the following 10 parameters. An MPL domain
defined by an MPL domain address. is defined by an MPL domain address.
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 37 skipping to change at page 3, line 37
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 from 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 To distribute a configuration of an MPL domain or a default value for
all MPL domains (wildcard) under the network managed by the DHCP all MPL domains (wildcard) under the network managed by the DHCP
server, this document defines a DHCPv6 option format as follows. server, this document defines a DHCPv6 option format as follows.
Short floating point format is used to describe wide range of timer
values.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) | DM_T_EXP | C_K | | DM_T_EXP | C_K | C_IMIN >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C_IMIN | C_IMAX | >(cont'ed) | C_IMAX | C_T_EXP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C_T_EXP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(if option_len = 34 ) (if option_len = 32 )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPL Domain Address >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> MPL Domain Address (128bits) > | MPL Domain Address (128bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (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 18 (without MPL option_len: Length of the option. It SHOULD be 16 (without MPL
domain address) or 34 (with MPL domain address) domain address) or 32 (with MPL domain address).
P (1 bit): A flag to indicate PROACTIVE_FORWARDING P (1 bit): A flag to indicate PROACTIVE_FORWARDING. The flag is set
if PROACTIVE_FORWARDING is true.
Z (7 bits) Reserved. Should be 0. Z (7 bits): Reserved. Should be 0.
TUNIT (unsigned 8 bit integer) Unit time of times in this option. 0 TUNIT (unsigned 8-bit integer): Unit time of timer parameters
and 0xff are reserved and SHALL NOT be used. (SE_LIFETIME, and *_IMIN) in this option. 0 and 0xff are reserved
and SHALL NOT be used.
SE_LIFETIME: SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. 0 and SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT
0xffff are reserved and SHALL NOT be used. in milliseconds. 0 and 0xffff are reserved and SHALL 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 in
milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. milliseconds. 0 and 0xffff are reserved and SHALL NOT be used.
DM_IMAX (unsigned 16 bit integer): DATA_MESSAGE_IMAX/TUNIT in DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. 0 and 0xff are
milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. reserved and SHALL 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.
TUNIT in milliseconds. 0 and 0xffff are reserved and SHALL NOT be 0 and 0xffff are reserved and SHALL NOT be used.
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 in
milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. milliseconds. 0 and 0xffff are reserved and SHALL NOT be used.
C_IMAX: CONTROL_MESSAGE_IMAX/TUNIT in milliseconds. 0 and 0xffff are C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. 0 and 0xff
reserved and SHALL NOT be used. are reserved and SHALL NOT be used.
C_T_EXP: CONTROL_MESSAGE_TIMER_EXPIRATIONS/TUNIT in milliseconds. 0 C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS
and 0xffff are reserved and SHALL NOT be used. . 0 and 0xffff are reserved and SHALL NOT be used.
Note that all time values (Trickle timers and expiration periods) are Note that all time values (Trickle timers and expiration periods) are
in TUNIT milliseconds precision. For example, if TUNIT is 20 and the in TUNIT milliseconds precision. For example, if TUNIT is 20 and the
data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
DM_IMIN shall be set to 50. DM_IMIN shall be set to 50.
2.2. DHCPv6 Client Behavior 2.2. DHCPv6 Client Behavior
Clients MAY request MPL Parameter Configuration Option, as described Clients MAY request the MPL Parameter Configuration Option, as
in RFC3315 [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 described in [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4,
and 22.7. As a convenience to the reader, we mention here that the 18.1.5, and 22.7. As a convenience to the reader, we mention here
client includes requested option codes in Option Request Option. that the client includes requested option codes in the Option Request
Option.
Clients MUST discard MPL Parameter Configuration Option if it is Clients MUST discard the MPL Parameter Configuration Option if it is
invalid (e.g. it sets reserved bits or it has timers with reserved invalid (e.g., it sets reserved bits).
exp=7 in Unsigned Short Floating Point).
2.3. MPL Forwarder Behavior 2.3. MPL Forwarder Behavior
If a DHCPv6 client requests and receives MPL Parameter Configuration If a DHCPv6 client requests and receives the MPL Parameter
Option, the node MAY join the MPL domain given by the option and act Configuration Option, the node SHOULD join the MPL domain given by
as an MPL forwarder. Each joining node SHOULD configure its MPL the option and act as an MPL forwarder. Note that there may be cases
forwarder with the given parameter set for the MPL domain. in which a node may fail is 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.
The priority of MPL Parameter Configuration applied for 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 (optlen=34) o Specific MPL Parameter Configuration to the MPL Domain
(option_len=32)
o Wildcard MPL Parameter Configuration (optlen=18) o Wildcard MPL Parameter Configuration (option_len=16)
o Default configuration given in the MPL specification. o Default configuration given in the MPL specification.
There SHALL be no more than one MPL Parameter Configuration Option There SHALL be no more than one MPL Parameter Configuration Option
for a MPL domain or the wildcard. Thus, the order of DHCPv6 options for an MPL domain or the wildcard. Thus, the order of DHCPv6 options
in the packet has no effect on precedence. in the packet has no effect on precedence.
A node MAY leave from an MPL domain if the following two conditions A node MAY leave an MPL domain if the following two conditions are
are satisfied. 1) The MPL domain is configured by a DHCPv6 option satisfied. 1) The MPL domain is configured by a DHCPv6 option from a
from a DHCPv6 server previously. 2) The node has received an updated DHCPv6 server previously. 2) The node has received an updated MPL
MPL Parameter Configuration Option without a configuration for the Parameter Configuration Option without a configuration for the MPL
MPL domain. domain.
MPL parameter 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 forwarders Refresh Time Option [RFC4242] shall be used to keep each forwarder
updated. updated.
To reduce periodical update traffic a node may try to use very long To reduce periodic update traffic, a node may try to use a very long
interval between updates. In the case, reconfigure message may be interval between updates. In the 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 [RFC3315] govern server operation Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
in regards to option assignment. As a convenience to the reader, we regards to option assignment. As a convenience to the reader, we
mention here that the server will send MPL Parameter Configuration mention here that the server will send the MPL Parameter
Option only if configured with specific value for MPL Parameter Configuration Option only if it was configured with specific values
Configuration Option and the client requested it. for the MPL Parameter Configuration Option and the client requested
it.
Servers SHALL ignore incoming MPL Parameter Configuration Option. Servers SHALL ignore an incoming MPL Parameter Configuration Option.
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
A parameter set for an MPL domain SHOULD NOT be updated more often A parameter set for an MPL domain SHOULD NOT be updated more often
than two times of expected refresh interval. than twice of Information Refresh Time, even if the clients use
longer Information Refresh Time to reduce DHCPv6 load on the network.
If a node with MPL forwarder configured by MPL Parameter If a node with an MPL forwarder configured by the MPL Parameter
configuration Option failed to refresh the option for two times of Configuration Option failed to refresh the option within twice the
information refresh time, it SHALL suspend the MPL forwarders of MPL Information Refresh Time, it SHALL suspend the MPL forwarders of the
domains configured by the option. MPL forwarders configured by other MPL domains configured by the option. MPL forwarders configured by
methods such as static configuration file SHALL NOT be suspended. other methods such as static configuration file SHALL NOT be
suspended.
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. Protocol for IPv6 (DHCPv6) Registry.
4. Security Considerations 4. Security Considerations
A forged option may cause excessive layer-2 broadcasting. There are detailed discussion on security threats on DHCPv6 in
Implementations should set reasonable bounds for each parameter. For Section 23 of RFC3315 [RFC3315] and Section 23 of RFC7227 [RFC7227].
example, not too high K, not too low IMIN, etc. These may be
implementation dependent or may be derived from MAC/PHY In addition, a forged MPL parameter configuration may cause excessive
specifications. DHCP server or the network itself shall be trusted layer-2 broadcasting. Implementations should set reasonable bounds
by some means including network access control or DHCP for each parameter. For example, not too high DM/C_K, not too low DM
authentications. /C_IMIN, etc. These bounds may be implementation dependent or may be
derived from MAC/PHY 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 authentications described in Section 21 of RFC3315
[RFC3315]. However, ROLL environment may expect less computing
resource, and DHCPv6 authentication may not available. In such
cases, other methods for security should be applied to a ROLL
network. Some ROLL specification such as ZigBee IP [ZigBeeIP]
expects RFC5191 [RFC5191] to authenticate joining nodes and all nodes
in the network can be trusted. To protect attacks from outside of
the network, unneccessary DHCPv6 packets should be filtered on the
border router between the ROLL network and the Internet.
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 Forwarding Using Hui, J. and R. Kelsey, "Multicast Protocol for Low power
Trickle", draft-ietf-roll-trickle-mcast-11 (work in and Lossy Networks (MPL)", draft-ietf-roll-trickle-
progress), November 2014. 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, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[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, November 2005.
5.2. Informative References
[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, May 2014.
5.2. Informative References
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[ZigBeeIP]
ZigBee Alliance, "ZigBee IP Specification", Mar 2014.
Appendix A. Update History Appendix A. Update History
Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll- Updates on draft-ietf-roll-mpl-configuration-03 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: mpl-configuration-04:
o References updated (Non-normative -> Informative) o References updated (Non-normative -> Informative)
o IANA section is updated to make clear request of option ID o IANA section is updated to make clear request of option ID
o Typo fixed o Reserved numbers are clearly denoted
Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll- Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll-
mpl-configuration-03: mpl-configuration-03:
o References updated o References updated
o Removed reference for DHCPv6 stateless reconfiguration as it has o Removed reference for DHCPv6 stateless reconfiguration as it has
expired expired
Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll-
skipping to change at page 8, line 43 skipping to change at page 9, line 32
Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll- Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll-
mpl-configuration-00: mpl-configuration-00:
o I-D renamed. o I-D renamed.
Appendix B. Considerations on Inconsistent Parameter Set Appendix B. Considerations on Inconsistent Parameter Set
This draft introduces dynamic update of MPL parameters. Because the This draft introduces dynamic update of MPL parameters. Because the
update process is not synchronized, nodes may have inconsistent update process is not synchronized, nodes may have inconsistent
parameter set. parameter sets.
Inconsistent parameter may reduce performance. On the other hand, it Inconsistent parameter set may reduce performance. On the other
shall work as long as both parameter set are reasonable parameter set hand, this situation will work as long as both parameter sets are
for a given communication load. As motivations for parameter update reasonable parameter sets for a given communication load. As the
are update on environment, node density, or communication load, motivations for parameter update include update of the environment,
operators of MPL networks shall be aware of unupdated nodes and make node density, or communication load, operators of MPL networks shall
sure old and new parameter sets are reasonable for expected refresh be aware of unupdated nodes and make sure old and new parameter sets
intervals. are reasonable for the expected refresh intervals.
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
 End of changes. 61 change blocks. 
118 lines changed or deleted 155 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/