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
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
Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6
用于低功耗和有损网络的多播协议（MPL）DHCPv6的参数配置选项
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.
本文档定义了通过DHCPv6选项为MPL（低功耗和有损网络的多播协议）配置参数集的方法。MPL有一组参数来控制其行为，参数集通常配置为网络范围的参数，因为MPL域中的每个MPL转发器的参数集都应该相同。使用本文档中定义的MPL参数配置选项，可以使用一组MPL参数轻松配置网络。
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 Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7774.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. MPL Parameter Configuration Option ..............................3
2.1. MPL Parameter Configuration Option Format ..................4
2.2. DHCPv6 Client Behavior .....................................6
2.3. MPL Forwarder Behavior .....................................6
2.4. DHCPv6 Server Behavior .....................................7
2.5. DHCPv6 Relay Behavior ......................................8
2.6. Operational Considerations .................................8
3. IANA Considerations .............................................8
4. Security Considerations .........................................8
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References ....................................10
Authors' Addresses ................................................10
1. Introduction ....................................................2
2. MPL Parameter Configuration Option ..............................3
2.1. MPL Parameter Configuration Option Format ..................4
2.2. DHCPv6 Client Behavior .....................................6
2.3. MPL Forwarder Behavior .....................................6
2.4. DHCPv6 Server Behavior .....................................7
2.5. DHCPv6 Relay Behavior ......................................8
2.6. Operational Considerations .................................8
3. IANA Considerations .............................................8
4. Security Considerations .........................................8
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References ....................................10
Authors' Addresses ................................................10
The Multicast Protocol for Low-Power and Lossy Networks (MPL) [RFC7731] 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 Section 5.4 of [RFC7731], each parameter in the set should be the same for all nodes within an MPL Domain, but [RFC7731] does not define a method to configure the MPL parameter set.
低功率和有损网络的多播协议（MPL）[RFC7731]定义了在低功率和有损网络（例如，无线网状网络）之间建立多播网络的协议。MPL有一组参数来控制MPL域。这些参数控制端到端延迟和网络利用率之间的权衡。在大多数环境中，默认参数是可以接受的。但是，在某些环境中，必须仔细配置参数集，以满足每个环境的要求。根据[RFC7731]第5.4节，对于MPL域中的所有节点，集合中的每个参数都应相同，但[RFC7731]未定义配置MPL参数集合的方法。
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.
某些受管无线网状网络可能具有DHCP服务器来配置网络参数。MPL参数集应视为网络参数的一部分（MPL域中的节点应使用相同的参数集）。配置MPL域需要参数集。
This document defines a way to distribute parameter sets for MPL Forwarders via a new DHCPv6 [RFC3315] option. This document is intended to follow the guidelines provided in [RFC7227].
本文档定义了通过新的DHCPv6[RFC3315]选项为MPL转发器分发参数集的方法。本文件旨在遵循[RFC7227]中提供的指南。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
As defined in Section 5.4 of [RFC7731], there are 10 parameters per MPL Domain, as listed below. An MPL Domain is defined by an MPL Domain Address, as described in Section 2 of [RFC7731].
如[RFC7731]第5.4节所定义，每个MPL域有10个参数，如下所示。MPL域由MPL域地址定义，如[RFC7731]第2节所述。
o PROACTIVE_FORWARDING
o 主动转发
o SEED_SET_ENTRY_LIFETIME
o 种子\u集\u条目\u寿命
o DATA_MESSAGE_IMIN
o 数据信息
o DATA_MESSAGE_IMAX
o 数据\消息\ IMAX
o DATA_MESSAGE_K
o 数据信息
o DATA_MESSAGE_TIMER_EXPIRATIONS
o 数据\消息\计时器\过期
o CONTROL_MESSAGE_IMIN
o 控制信息
o CONTROL_MESSAGE_IMAX
o 控制\u消息\u IMAX
o CONTROL_MESSAGE_K
o 控制信息
o CONTROL_MESSAGE_TIMER_EXPIRATIONS
o 控制\u消息\u计时器\u过期
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.
一个网络可能有多个配置不同的MPL域。要通过DHCP配置多个MPL域，DHCP服务器可能会向DHCP客户端提供多个MPL参数配置选项。
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:
本文档定义了选项_MPL_PARAMETERS DHCPv6选项。此新选项提供了一种方法，用于在由DHCP服务器管理的网络中分发MPL域的配置或所有MPL域的默认值（通配符）。此选项具有以下格式：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(if option_len = 32)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPL Domain Address (128 bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_MPL_PARAMETERS: DHCPv6 option identifier (104).
选项MPL参数：DHCPv6选项标识符（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.
选项长度：以八位字节为单位的选项长度。如果不存在MPL域地址，则该值必须设置为16；如果存在MPL域地址，则该值必须设置为32。
P (1 bit): A flag to indicate PROACTIVE_FORWARDING. This flag is set if PROACTIVE_FORWARDING = TRUE.
P（1位）：表示主动转发的标志。如果主动转发=TRUE，则设置此标志。
Z (7 bits): Reserved for future use. Servers MUST set them to zero. Clients SHOULD ignore any bits that have been set.
Z（7位）：保留供将来使用。服务器必须将它们设置为零。客户端应忽略已设置的任何位。
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.
TUNIT（无符号8位整数）：此选项中计时器参数的单位时间（SE_life和*_IMIN）。0和0xff是保留的，不能使用。
SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT, in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
SE_生存期（无符号16位整数）：种子设置项生存期/t，以毫秒为单位。0和0xffff是保留的，不能使用。
DM_K (unsigned 8-bit integer): DATA_MESSAGE_K.
DM_K（无符号8位整数）：数据消息。
DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT, in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
DM_IMIN（无符号16位整数）：数据消息IMIN/TUNIT，以毫秒为单位。0和0xffff是保留的，不能使用。
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 [RFC6206], Section 4.1. 0 and 0xff are reserved and MUST NOT be used.
DM_IMAX（无符号8位整数）：数据_消息_IMAX。如[RFC6206]第4.1节所述，实际最大超时被描述为数据消息IMIN的双倍数。0和0xff是保留的，不能使用。
DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and MUST NOT be used.
DM_T_EXP（无符号16位整数）：数据\u消息\u计时器\u过期。0和0xffff是保留的，不能使用。
C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K.
C_K（无符号8位整数）：控制消息。
C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT, in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
C_IMIN（无符号16位整数）：控制消息IMIN/TUNIT，以毫秒为单位。0和0xffff是保留的，不能使用。
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_IMAX（无符号8位整数）：控制_消息_IMAX。实际最大超时被描述为控制消息IMIN的双倍数。0和0xff是保留的，不能使用。
C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and MUST NOT be used.
C_T_EXP（无符号16位整数）：控制消息计时器过期。0和0xffff是保留的，不能使用。
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.
请注意，在MPL参数配置选项中，MPL中的时间值（种子\设置\条目\生命周期、数据\消息\ IMIN和控制\消息\ IMIN）的定义精度为t毫秒。例如，如果TUNIT为20，且最小数据消息间隔（Data_Message_IMIN）为1000 ms，则DM_IMIN应设置为50。
For the maximum interval size (*_IMAX), [RFC6206] defines them as follows:
对于最大间隔大小（*u IMAX），[RFC6206]定义如下：
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.
最大间隔大小Imax被描述为最小间隔大小（base-2 log（max/min））的倍数。例如，协议可能将Imax定义为16。如果最小间隔为100 ms，则Imax指定的时间量为100 ms*65536，即6553.6秒或约109分钟。
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.
由于MPL参数配置选项中的最小间隔大小以TUNIT毫秒精度表示，因此相应的最大间隔大小也以TUNIT毫秒精度表示。例如，如果TUNIT为10，C_IMIN为50，则控制消息的涓流计时器的最小间隔大小为500毫秒。在这种情况下，如果C_IMAX为6，涓流计时器的最大间隔大小为32秒（500毫秒*2^6）。
Clients MAY request the MPL Parameter Configuration Option as described in Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7 of [RFC3315]. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request Option.
客户可以请求MPL参数配置选项，如[RFC3315]第17.1.1、18.1.1、18.1.3、18.1.4、18.1.5和22.7节所述。为了方便读者，我们在这里提到，客户机在选项请求选项中包含请求的选项代码。
Clients MUST support multiple MPL Parameter Configuration Options, which are listed in Section 2.
客户端必须支持多个MPL参数配置选项，这些选项在第2节中列出。
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 [RFC3315] of the last valid DHCPv6 message sent from the server (if stateful) or twice the information refresh time [RFC4242] (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.
如果带有由MPL参数配置选项配置的MPL转发器的DHCPv6客户端无法从服务器发送的最后一条有效DHCPv6消息的T2[RFC3315]内或信息刷新时间[RFC4242]的两倍（如果无状态）内的服务器接收到有效响应，它必须挂起由选项配置的MPL域的MPL转发器。不得挂起通过其他方法（例如，通过静态配置文件）配置的MPL转发器。
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.
如果DHCPv6消息中的选项包含任何无效值（例如，参数中使用保留的all-0或all-1值），则客户端必须忽略所有MPL参数配置选项。在这种情况下，在MPL的上下文中，消息被视为未接收，并且上一段中描述的条件适用。
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 Section 2 of [RFC7731], an MPL Domain Address is an IPv6 multicast address associated to a set of MPL network interfaces in an MPL Domain.
如果DHCPv6客户端请求并接收MPL参数配置选项，则节点应加入该选项给定的MPL域，并充当MPL转发器。请注意，在某些情况下，由于本地资源限制，节点可能无法加入域。每个加入节点应使用为MPL域设置的给定参数配置其MPL转发器。每个MPL域由MPL参数配置选项提供的MPL域地址定义。如[RFC7731]第2节所定义，MPL域地址是与MPL域中的一组MPL网络接口关联的IPv6多播地址。
The priority of MPL parameter configurations applied to an MPL Domain is as follows (high to low):
应用于MPL域的MPL参数配置的优先级如下（从高到低）：
o Specific MPL parameter configuration for the MPL Domain (option_len = 32 bits).
o MPL域的特定MPL参数配置（选项长度=32位）。
o Wildcard MPL parameter configuration (option_len = 16 bits).
o 通配符MPL参数配置（选项长度=16位）。
o Default configuration as described in [RFC7731].
o [RFC7731]中描述的默认配置。
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.
对于MPL域或通配符，不能有多个MPL参数配置选项。因此，数据包中DHCPv6选项的顺序对优先级没有影响。
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参数配置选项而没有MPL域的配置，则必须离开MPL域，除非它具有MPL域的覆盖手动配置。换句话说，如果节点被配置为作为MPL域的MPL转发器工作，而不管DHCPv6选项如何，则即使节点接收到MPL参数配置选项而没有MPL域的配置，该节点也可以留在MPL域中。
MPL parameters may be updated occasionally. With stateful DHCPv6, updates can be done when the renewal timer expires. The information refresh time option [RFC4242] shall be used to keep each forwarder updated.
MPL参数可能会偶尔更新。使用有状态DHCPv6，更新可以在续订计时器过期时完成。应使用信息刷新时间选项[RFC4242]来更新每个转发器。
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.
为了减少定期更新流量，节点可以尝试在更新之间使用很长的间隔。在这种情况下，可以使用重新配置消息来保持转发器参数集的同步。
Sections 17.2.2 and 18.2 of [RFC3315] 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.
[RFC3315]第17.2.2节和第18.2节规定了与选项分配有关的服务器操作。为了方便读者，我们在这里提到，只有当服务器配置了MPL参数配置选项的特定值并且客户端请求时，服务器才会发送MPL参数配置选项。
Servers MUST ignore an incoming MPL Parameter Configuration Option. Servers MUST support multiple MPL Parameter Configuration Options, which are listed in Section 2.
服务器必须忽略传入的MPL参数配置选项。服务器必须支持第2节中列出的多个MPL参数配置选项。
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.
中继代理向指向客户端的消息标题添加选项是不合适的，而且中继代理实际上并不构建中继回复消息。对继电器没有额外要求。
This document introduces the dynamic updating of MPL parameters. Because the update process is not synchronized, nodes may have inconsistent parameter sets.
本文档介绍MPL参数的动态更新。由于更新过程未同步，节点可能具有不一致的参数集。
[RFC6206], Section 6 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 [RFC3315] or information refresh time as defined in [RFC4242].
[RFC6206]第6节描述了在通信节点之间涓流定时器不匹配时发生的各种问题。为了保持计时器同步，建议不要过于频繁地更新MPL域的参数。合理的更新率应为每个预期信息刷新时间间隔一次，如T1[RFC3315]或[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. 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.
参数集不一致可能会降低性能。另一方面，只要新的和旧的参数集对于给定的通信负载都是合理的参数集，这种情况就会起作用。由于参数更新的动机包括环境、节点密度或通信负载的更新，MPL网络的运营商需要了解未更新的节点，并确保新旧参数集对于预期的刷新间隔是合理的。
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 (http://www.iana.org/assignments/ dhcpv6-parameters).
IANA已从“IPv6动态主机配置协议（DHCPv6）”注册表的“选项代码”表中为选项MPL参数（104）分配了一个选项代码(http://www.iana.org/assignments/ dhcpv6参数）。
Section 23 of [RFC3315], Section 23 of [RFC7227], and Section 12 of [RFC7731] provide detailed discussions regarding security threats for DHCPv6.
[RFC3315]第23节、[RFC7227]第23节和[RFC7731]第12节详细讨论了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
还要注意，伪造的MPL参数配置可能会导致第2层广播过多。实现应该为每个参数设置合理的界限——例如，不要将DM/C_K设置得太高，不要将DM/C_IMIN设置得太低。这些边界可能依赖于实现，也可能来自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.
规格。DHCPv6服务器和客户端实现需要注意为每个参数设置合理的界限，以避免网络过载。
The DHCP server or the network itself should be trusted by some means, such as DHCPv6 authentication as described in Section 21 of [RFC3315]. 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 [ZigBeeIP] and [RFC5191], 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.
应通过某种方式信任DHCP服务器或网络本身，如[RFC3315]第21节所述的DHCPv6身份验证。然而，低功耗和有损（ROLL）网络环境中的路由通常具有较少的计算资源，并且DHCPv6身份验证在这些环境中可能不可用。在这种情况下，保护DHCPv6服务器和客户端之间完整性的其他方法应应用于ROLL网络。一些与ROLL实现相关的规范，如ZigBee IP[ZigBeeIP]和[RFC5191]，假设加入节点将经过身份验证，以便可以信任网络中的所有节点。为了防止来自网络外部的攻击，应在ROLL网络和Internet之间的边界路由器上过滤DHCPv6数据包，但ROLL网络和远程DHCPv6服务器或配置为管理网络的DHCPv6中继之间的数据包除外。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 2005, <http://www.rfc-editor.org/info/rfc4242>.
[RFC4242]Venaas，S.，Chown，T.，和B.Volz，“IPv6动态主机配置协议（DHCPv6）的信息刷新时间选项”，RFC 4242，DOI 10.17487/RFC4242，2005年11月<http://www.rfc-editor.org/info/rfc4242>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6206]Levis，P.，Clausen，T.，Hui，J.，Gnawali，O.，和J.Ko，“涓流算法”，RFC 6206，DOI 10.17487/RFC6206，2011年3月<http://www.rfc-editor.org/info/rfc6206>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <http://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<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>.
[RFC7731]Hui，J.和R.Kelsey，“低功耗和有损网络的多播协议（MPL）”，RFC 7731，DOI 10.17487/RFC7731，2016年2月<http://www.rfc-editor.org/info/rfc7731>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[RFC5191]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 5191，DOI 10.17487/RFC5191，2008年5月<http://www.rfc-editor.org/info/rfc5191>.
[ZigBeeIP] ZigBee Alliance, "ZigBee IP Specification", 2015, <http://www.zigbee.org/>.
[ZigBeeIP]ZigBee联盟，“ZigBee IP规范”，2015年<http://www.zigbee.org/>.
Authors' Addresses
作者地址
Yusuke Doi Toshiba Corporation Komukai Toshiba Cho 1 Saiwai-Ku Kawasaki, Kanagawa 2128582 Japan
日本神奈川市川崎赛维区东芝町1号公井东芝株式会社
Phone: +81-45-342-7230
Email: yusuke.doi@toshiba.co.jp
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
Matthew Gillmore Itron，Inc.美国华盛顿州自由湖N.Molter路2111号，邮编99019
Email: matthew.gillmore@itron.com
Email: matthew.gillmore@itron.com