[要約] RFC 7774は、低消費電力かつ損失の多いネットワーク向けのマルチキャストプロトコル（MPL）パラメータ設定オプションのためのDHCPv6に関する規格です。このRFCの目的は、MPLネットワークでのDHCPv6を使用して、マルチキャストプロトコルのパラメータを効果的に設定することです。
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
DHCPv6の低電力および損失の多いネットワーク（MPL）パラメータ構成オプションのマルチキャストプロトコル
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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のパラメーターがあります。 [RFC7731]のセクション2で説明されているように、MPLドメインはMPLドメインアドレスによって定義されます。
o PROACTIVE_FORWARDING
o PROACTIVE_FORWARDING
o SEED_SET_ENTRY_LIFETIME
o SEED_SET_ENTRY_LIFETIME
o DATA_MESSAGE_IMIN
o だた＿めっさげ＿いみん
o DATA_MESSAGE_IMAX
o DATA_MESSAGE_IMAX
o DATA_MESSAGE_K
o DATA_MESSAGE_K
o DATA_MESSAGE_TIMER_EXPIRATIONS
o DATA_MESSAGE_TIMER_EXPIRATIONS
o CONTROL_MESSAGE_IMIN
o こんＴろＬ＿めっさげ＿いみん
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 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.
1つのネットワークに、構成が異なる複数の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:
このドキュメントでは、OPTION_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(if option_len = 32)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPL Domain Address (128 bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_MPL_PARAMETERS: DHCPv6 option identifier (104).
OPTION_MPL_PARAMETERS：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.
option_len：オクテット単位のオプションの長さ。この値は、MPLドメインアドレスが存在しない場合は16に、MPLドメインアドレスが存在する場合は32に設定する必要があります。
P (1 bit): A flag to indicate PROACTIVE_FORWARDING. This flag is set if PROACTIVE_FORWARDING = TRUE.
P（1ビット）：PROACTIVE_FORWARDINGを示すフラグ。このフラグは、PROACTIVE_FORWARDING = TRUEの場合に設定されます。
Z (7 bits): Reserved for future use. Servers MUST set them to zero. Clients SHOULD ignore any bits that have been set.
Z（7ビット）：将来の使用のために予約されています。サーバーはそれらをゼロに設定する必要があります。クライアントは、設定されているビットをすべて無視する必要があります（SHOULD）。
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_LIFETIMEおよび* _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_LIFETIME（符号なし16ビット整数）：SEED_SET_ENTRY_LIFETIME / TUNIT（ミリ秒単位）。 0と0xffffは予約されており、使用してはなりません。
DM_K (unsigned 8-bit integer): DATA_MESSAGE_K.
DM_K（符号なし8ビット整数）：DATA_MESSAGE_K。
DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT, in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
DM_IMIN（符号なし16ビット整数）：DATA_MESSAGE_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ビット整数）：DATA_MESSAGE_IMAX。 [RFC6206]のセクション4.1で説明されているように、実際の最大タイムアウトはDATA_MESSAGE_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ビット整数）：DATA_MESSAGE_TIMER_EXPIRATIONS。 0と0xffffは予約されており、使用してはなりません。
C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K.
C_K（符号なし8ビット整数）：CONTROL_MESSAGE_K。
C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT, in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.
C_IMIN（符号なし16ビット整数）：CONTROL_MESSAGE_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ビット整数）：CONTROL_MESSAGE_IMAX。実際の最大タイムアウトは、CONTROL_MESSAGE_IMINを2倍にした数として表されます。 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ビット整数）：CONTROL_MESSAGE_TIMER_EXPIRATIONS。 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の時間値（SEED_SET_ENTRY_LIFETIME、DATA_MESSAGE_IMIN、およびCONTROL_MESSAGE_IMIN）は、MPLパラメーター構成オプションでTUNITミリ秒の精度で定義されることに注意してください。たとえば、TUNITが20で、最小データメッセージ間隔（DATA_MESSAGE_IMIN）が1000ミリ秒の場合、DM_IMINは50に設定されます。
For the maximum interval size (*_IMAX), [RFC6206] defines them as follows:
最大間隔サイズ（* _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 * 65,536、つまり6,553.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 ms * 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.
[RFC3315]のセクション17.1.1、18.1.1、18.1.3、18.1.4、18.1.5、および22.7で説明されているように、クライアントはMPLパラメータ構成オプションを要求できます（MAY）。読者の便宜のため、ここではクライアントがオプション要求オプションに要求されたオプションコードを含めることを述べます。
Clients MUST support multiple MPL Parameter Configuration Options, which are listed in Section 2.
クライアントは、セクション2に記載されている複数のMPLパラメータ構成オプションをサポートする必要があります。
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]内のサーバーから有効な応答を受信できない場合（ステートフルの場合）または情報更新時間の2倍[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メッセージのオプションに無効な値が含まれている場合（たとえば、予約済みのすべて0または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フォワーダとして機能する必要があります（SHOULD）。ローカルリソースの制約のために、ノードがドメインに参加できない場合があることに注意してください。参加する各ノードは、MPLドメインに指定されたパラメーターセットを使用してMPLフォワーダーを構成する必要があります（SHOULD）。各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パラメータ構成（option_len = 32ビット）。
o Wildcard MPL parameter configuration (option_len = 16 bits).
o ワイルドカードMPLパラメーター構成（option_len = 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パラメータ構成オプションを1つだけ含める必要があります。したがって、パケット内の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ドメインを離れる必要があります。つまり、ノードがDHCPv6オプションに関係なくMPLドメインのMPLフォワーダーとして機能するように構成されている場合、ノードは、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]で定義されている情報更新時間など、予想される情報更新時間間隔ごとに1回です。
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）」レジストリ（http://www.iana.org/assignments/ dhcpv6-parameters）の「オプションコード」テーブルから、OPTION_MPL_PARAMETERS（104）にオプションコードを割り当てました。
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 specifications. DHCPv6 server and client implementations need to take care in setting reasonable bounds for each parameter in order to avoid overloading the network.
また、偽造されたMPLパラメータ設定は、過剰なレイヤ2ブロードキャストを引き起こす可能性があることにも注意してください。実装では、各パラメーターに適切な境界を設定する必要があります。たとえば、DM / C_Kを高く設定しすぎたり、DM / C_IMINを低く設定しすぎたりしないでください。これらの境界は、実装に依存する場合や、MAC / PHY仕様から導出される場合があります。 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ネットワークに適用する必要があります。 ZigBee IP [ZigBeeIP]や[RFC5191]など、ROLL実装に関連する一部の仕様では、ネットワーク内のすべてのノードを信頼できるように、参加するノードが認証されることを想定しています。ネットワークの外部からの攻撃から保護するために、ROLLネットワークとリモートDHCPv6サーバー間のパケットまたはネットワークを管理するように構成されたDHCPv6リレーを除き、DHCPv6パケットはROLLネットワークとインターネット間の境界ルーターでフィルタリングする必要があります（SHOULD）。
[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.、and M. Carney、 "Dynamic Host Configuration Protocol for 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.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「The Trickle Algorithm」、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、「Protocol for Carrying Authentication for Network Access（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 Alliance、「ZigBee IP仕様」、2015年、<http://www.zigbee.org/>。
Authors' Addresses
著者のアドレス
Yusuke Doi Toshiba Corporation Komukai Toshiba Cho 1 Saiwai-Ku Kawasaki, Kanagawa 2128582 Japan
ゆすけ どい としば こｒぽらちおん こむかい としば ちょ １ さいわいーく かわさき、 かながわ ２１２８５８２ じゃぱん
Phone: +81-45-342-7230
Email: yusuke.doi@toshiba.co.jp
Matthew Gillmore Itron, Inc. 2111 N. Molter Rd. Liberty Lake, WA 99019 United States
Matthew Gillmore Itron、Inc. 2111 N. Molter Rd。 Liberty Lake、WA 99019アメリカ合衆国
Email: matthew.gillmore@itron.com