[要約] RFC 7732は、低消費電力ネットワークにおけるマルチキャストプロトコル（MPL）でのアドミンローカルスコープを持つマルチキャストのためのフォワーダーポリシーに関するものです。このRFCの目的は、MPLネットワークでのアドミンローカルスコープのマルチキャストトラフィックの効果的な転送を提供するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) P. van der Stok
Request for Comments: 7732 Consultant
Category: Informational R. Cragie
ISSN: 2070-1721 ARM Ltd.
February 2016
Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
低電力および損失の多いネットワーク（MPL）のマルチキャストプロトコルの管理者ローカルスコープを使用したマルチキャストのフォワーダーポリシー
Abstract
概要
The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.
このドキュメントの目的は、ボーダールーターで管理者-ローカルスコープを持つ低電力および損失の多いネットワーク（MPL）マルチキャストメッセージのマルチキャストプロトコルのルーティングに関する自動化されたポリシーを指定することです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7732.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7732で入手できます。
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
1.1. Requirements Language ......................................4
1.2. Terminology and Acronyms ...................................4
2. Network Identifier ..............................................4
2.1. IEEE 802.15.4 ..............................................5
2.2. IEEE 802.11 ................................................5
2.3. ITU-T G.9959 ...............................................5
2.4. BLUETOOTH(R) Low Energy ....................................5
3. MPL4 Router .....................................................5
3.1. MPL Interface Parameters ...................................6
3.2. Determination of MPL4 Zone .................................6
4. Admin-Local Policy ..............................................7
4.1. Legal Multicast Messages ...................................7
4.2. Forwarding Legal Packets ...................................8
4.2.1. MPL Message .........................................8
4.2.2. Multicast Messages without MPL Option ...............9
4.3. Encryption Rules ...........................................9
5. MPL Domains and Zones ...........................................9
6. Default Parameter Values .......................................10
7. Security Considerations ........................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................15
Multicast scopes are defined in [RFC4291]. [RFC7346] extends the scope definition with this text:
マルチキャストスコープは[RFC4291]で定義されています。 [RFC7346]は、次のテキストでスコープ定義を拡張します：
"Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other non-multicast-related configurations. Global scope has no boundary. The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured."
「インターフェースローカル、リンクローカル、およびレルムローカルスコープの境界は、物理接続またはその他の非マルチキャスト関連構成から自動的に導出されます。グローバルスコープには境界がありません。管理ローカルまたはその他の予約されていないすべてのスコープの境界は、大きい方は管理上構成されています。」
The Admin-Local scope must therefore be administratively configured. In this document, "administratively configured" does not imply actions by a human beyond installing the protocol specified herein. "Administratively configured" means an automatic derivation as described in this document.
したがって、Admin-Localスコープは管理上構成する必要があります。このドキュメントでは、「管理上構成された」とは、ここで指定されたプロトコルをインストールする以外の人間によるアクションを意味するものではありません。 「管理上構成された」とは、このドキュメントで説明されている自動派生を意味します。
This document describes an automated policy for the Multicast Protocol for Low-Power and Lossy Networks (MPL) [RFC7731] forwarding of multicast messages with Admin-Local scope within a border router that lies between a network running MPL and some other network. This policy is in line with the autonomous networking ideas presented in [RFC7576].
このドキュメントでは、MPLを実行しているネットワークと他のネットワークの間にある境界ルーター内で、Admin-Localスコープを持つマルチキャストメッセージをマルチキャストする、低電力および損失の多いネットワーク（MPL）のマルチキャストプロトコルの自動化ポリシーについて説明します。このポリシーは、[RFC7576]で提示されている自律型ネットワーキングのアイデアと一致しています。
The Realm-Local multicast address is currently used by MPL to propagate the multicast message to all receivers and forwarders within a mesh network. The multicast propagation is limited to a mesh network with a common Layer 2. For example, a Low-Power Wireless Personal Area Network (LoWPAN) is defined by an IEEE 802.15.4 Layer 2 mesh network, composed of all connected nodes sharing the same Personal Area Network (PAN) ID [RFC4944].
Realm-Localマルチキャストアドレスは、現在MPLによって使用されており、メッシュネットワーク内のすべてのレシーバーとフォワーダーにマルチキャストメッセージを伝播します。マルチキャストの伝播は、レイヤー2が共通のメッシュネットワークに限定されます。たとえば、低電力ワイヤレスパーソナルエリアネットワーク（LoWPAN）は、IEEE 802.15.4レイヤー2メッシュネットワークによって定義され、接続されているすべてのノードが同じパーソナルエリアネットワーク（PAN）ID [RFC4944]。
The network concept differs between mesh network technologies. This document maps a general network identifier to the specific network identifier of existing mesh technologies.
ネットワークの概念は、メッシュネットワークテクノロジーによって異なります。このドキュメントでは、一般的なネットワーク識別子を既存のメッシュテクノロジーの特定のネットワーク識別子にマッピングします。
In current and projected deployments, there is a requirement to propagate a multicast message beyond the boundaries of the mesh network in which it originated, independent of the mesh technology.
現在の展開および計画された展開では、メッシュテクノロジーとは関係なく、発信元のメッシュネットワークの境界を越えてマルチキャストメッセージを伝播する必要があります。
Consider the case where propagation over two mesh networks is required. In one example, each mesh network has a border router and the two border routers are connected with an Ethernet link. In another example, each mesh network is connected to its own network interface connected to the same border router. In both cases, an Admin-Local multicast message originating in one network needs to propagate into the other mesh network. The boundary of the Admin-Local scope is administratively configured.
2つのメッシュネットワークでの伝播が必要な場合を考えます。一例では、各メッシュネットワークに境界ルーターがあり、2つの境界ルーターがイーサネットリンクで接続されています。別の例では、各メッシュネットワークは、同じ境界ルーターに接続されている独自のネットワークインターフェイスに接続されています。どちらの場合も、1つのネットワークで発生した管理者ローカルマルチキャストメッセージは、他のメッシュネットワークに伝播する必要があります。 Admin-Localスコープの境界は、管理上構成されています。
This document describes an "MPL4 router" that forwards MPL messages with a multicast address with Admin-Local scope to all interfaces connected to links that connect to other MPL-enabled interfaces. The MPL4 router enables all its interfaces for MPL messages and allocates an additional variable, MPL_BLOCKED, that either permits or forbids the forwarding of MPL messages.
このドキュメントでは、Admin-Localスコープのマルチキャストアドレスを持つMPLメッセージを、他のMPL対応インターフェースに接続するリンクに接続されているすべてのインターフェースに転送する「MPL4ルーター」について説明します。 MPL4ルーターは、MPLメッセージのすべてのインターフェイスを有効にし、MPLメッセージの転送を許可または禁止する追加の変数MPL_BLOCKEDを割り当てます。
The MPL4 router uses the following technique to establish over which links MPL4 messages must be forwarded: The MPL4 router listens on its interfaces for the arrival of MPL4 messages. When MPL4 messages arrive over an interface, the MPL4 router records this interface in the set of interfaces over which incoming MPL4 messages are forwarded. The MPL4 router regularly sends MPL4 messages over its interfaces to provoke the return of MPL4 messages to maintain the set of forwarding interfaces.
MPL4ルーターは、次の手法を使用して、MPL4メッセージを転送する必要のあるリンクを確立します。MPL4ルーターは、MPL4メッセージの到着をインターフェイスでリッスンします。 MPL4メッセージがインターフェイスを介して到着すると、MPL4ルーターは着信MPL4メッセージが転送される一連のインターフェイスにこのインターフェイスを記録します。 MPL4ルーターは、MPL4メッセージを定期的に送信してMPL4メッセージの返信を引き起こし、一連の転送インターフェースを維持します。
It is expected that the private network of an organization, building, or home is connected to the Internet via the edge routers provided by an ISP. The intention is that MPL messages with multicast addresses of Admin-Local scope are freely forwarded within the private network but are never forwarded outside the private network by edge routers.
組織、建物、または家庭のプライベートネットワークは、ISPが提供するエッジルーターを介してインターネットに接続されていることが予想されます。意図は、Admin-Localスコープのマルチキャストアドレスを持つMPLメッセージはプライベートネットワーク内で自由に転送されますが、エッジルーターによってプライベートネットワークの外に転送されることはありません。
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]で説明されているように解釈されます。
This document uses terminology defined in [RFC7731] and [RFC7346]. In addition, the following terms are used in this document:
このドキュメントでは、[RFC7731]と[RFC7346]で定義されている用語を使用しています。さらに、このドキュメントでは次の用語が使用されています。
o MPL4: MPL with Admin-Local scope 4.
o MPL4：管理-ローカルスコープのMPL 4。
o MPL4 message: an MPL Data Message with a destination multicast address of scope 4.
o MPL4メッセージ：宛先マルチキャストアドレスがスコープ4のMPLデータメッセージ。
o MPL4 zone: a convex zone of interconnected interfaces over which MPL messages with Admin-Local scope propagate. An MPL4 zone is bounded by a zone as defined in [RFC4007].
o MPL4ゾーン：相互接続されたインターフェースの凸状ゾーンで、Admin-LocalスコープのMPLメッセージが伝播します。 MPL4ゾーンは、[RFC4007]で定義されているゾーンによって境界付けられています。
o MPL4 router: automatically determines the MPL4 zone in which MPL messages with Admin-Local scope can be propagated.
o MPL4ルーター：アドミンローカルスコープのMPLメッセージを伝達できるMPL4ゾーンを自動的に決定します。
Links may have the concept of a channel. For example, in wireless networks, such a channel is associated with a communication frequency. Additionally, for some link technologies, several networks can coexist using the same channel. For these link technologies, a network identifier exists. The network identifier is determined by the link technology specification. When no network identifier exists for a given link, the network identifier has the value "any".
リンクにはチャネルの概念がある場合があります。例えば、無線ネットワークでは、そのようなチャネルは通信周波数に関連付けられています。さらに、一部のリンクテクノロジーでは、同じチャネルを使用して複数のネットワークが共存できます。これらのリンク技術には、ネットワーク識別子が存在します。ネットワーク識別子は、リンク技術仕様によって決定されます。特定のリンクにネットワーク識別子が存在しない場合、ネットワーク識別子の値は「any」です。
IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is composed of the nodes connected by an IEEE 802.15.4 mesh sharing the same PAN ID. The PAN ID identifies a network in the IEEE 802.15.4 mesh. Several networks with different PAN IDs can coexist on the same channel [IEEE802.15.4]. The PAN ID of an interface is defined when the interface is enabled. The value of the network identifier of an IEEE 802.15.4 link is the value of the PAN ID.
IEEE 802.15.4上のIPv6は[RFC4944]で説明されています。 LoWPANは、同じPAN IDを共有するIEEE 802.15.4メッシュによって接続されたノードで構成されます。 PAN IDは、IEEE 802.15.4メッシュ内のネットワークを識別します。異なるPAN IDを持ついくつかのネットワークは、同じチャネルで共存できます[IEEE802.15.4]。インターフェイスのPAN IDは、インターフェイスが有効になるときに定義されます。 IEEE 802.15.4リンクのネットワーク識別子の値は、PAN IDの値です。
IP over IEEE 802.11 is described in [RFC5416]. The Service Set Identifier (SSID) identifies a network in the IEEE 802.11 link. Several networks with different SSIDs can coexist on the same channel [IEEE802.11]. The SSID of an interface is defined when the interface is switched on. The value of the network identifier of an IEEE 802.11 link is the value of the SSID.
IP over IEEE 802.11は[RFC5416]で説明されています。サービスセット識別子（SSID）は、IEEE 802.11リンクのネットワークを識別します。 SSIDが異なる複数のネットワークが同じチャネルで共存できます[IEEE802.11]。インターフェースのSSIDは、インターフェースがオンになったときに定義されます。 IEEE 802.11リンクのネットワーク識別子の値は、SSIDの値です。
IPv6 over ITU-T G.9959 is specified in [RFC7428]. The HomeID identifies a network of connected nodes [G.9959]. Several HomeIDs can coexist within communication range, but nodes adhering to a network with a given HomeID cannot communicate with nodes adhering to a network with a different HomeID. The value of the network identifier of a G.9959 link is the value of the HomeID.
ITU-T G.9959上のIPv6は[RFC7428]で指定されています。 HomeIDは、接続されたノードのネットワークを識別します[G.9959]。複数のHomeIDが通信範囲内で共存できますが、特定のHomeIDを持つネットワークに付着するノードは、異なるHomeIDを持つネットワークに付着するノードと通信できません。 G.9959リンクのネットワーク識別子の値は、HomeIDの値です。
IPv6 over Bluetooth low energy (BTLE) is specified in [RFC7668]. The medium is specified in [BTLE]. BTLE does not know the concept of multiple networks in one channel. The value of the network identifier of a BTLE link is "any".
IPv6 over Bluetooth Low Energy（BTLE）は[RFC7668]で指定されています。メディアは[BTLE]で指定されます。 BTLEは、1つのチャネル内の複数のネットワークの概念を認識していません。 BTLEリンクのネットワーク識別子の値は「任意」です。
The concept of an MPL4 router serves to automatically determine the MPL4 zone in which MPL messages with a scope 4 multicast address can propagate. The MPL4 router periodically executes an algorithm that determines the presence of MPL Interfaces on the links connected to its interfaces. When no MPL Interfaces are present on a given link, the corresponding MPL Interface is signaled as not being part of the MPL4 zone.
MPL4ルーターの概念は、スコープ4マルチキャストアドレスを持つMPLメッセージが伝搬できるMPL4ゾーンを自動的に決定するのに役立ちます。 MPL4ルーターは、そのインターフェースに接続されたリンク上のMPLインターフェースの存在を判別するアルゴリズムを定期的に実行します。特定のリンクにMPLインターフェースが存在しない場合、対応するMPLインターフェースはMPL4ゾーンの一部ではないことを通知されます。
One parameter is associated with every MPL Interface in the MPL4 router, and two parameters are associated with the behavior of the MPL4 router as a whole.
1つのパラメーターはMPL4ルーターのすべてのMPLインターフェイスに関連付けられ、2つのパラメーターはMPL4ルーター全体の動作に関連付けられます。
o MPL_BLOCKED: Boolean value that indicates whether or not the associated interface belongs to the MPL4 zone.
o MPL_BLOCKED：関連付けられたインターフェイスがMPL4ゾーンに属しているかどうかを示すブール値。
o MPL_CHECK_INT: Integer that indicates the time interval between successive activations of the MPL4 router algorithm, in seconds.
o MPL_CHECK_INT：MPL4ルーターアルゴリズムの連続したアクティブ化の間の時間間隔を秒単位で示す整数。
o MPL_TO: Integer that indicates the interval in which MPL messages are expected to be received, in seconds.
o MPL_TO：MPLメッセージの受信が予想される間隔（秒単位）を示す整数。
All interfaces of the MPL4 router MUST be associated with the following MPL protocol parameters, as described in [RFC7731]: PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX, DATA_MESSAGE_K, and DATA_MESSAGE_TIMER_EXPIRATIONS. Upon startup of the MPL4 router, the parameters associated with all interfaces are assigned the following values: PROACTIVE_FORWARDING = TRUE, MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast addresses ALL_MPL_FORWARDERS scope 3 and scope 4.
[RFC7731]で説明されているように、MPL4ルーターのすべてのインターフェースは、次のMPLプロトコルパラメータに関連付けられている必要があります。 MPL4ルーターの起動時に、すべてのインターフェイスに関連付けられているパラメーターに次の値が割り当てられます。PROACTIVE_FORWARDING= TRUE、MPL_BLOCKED = false。すべてのインターフェイスは、マルチキャストアドレスALL_MPL_FORWARDERSスコープ3およびスコープ4にサブスクライブする必要があります。
The MPL4 router executes the following algorithm for each interface:
MPL4ルーターは、インターフェイスごとに次のアルゴリズムを実行します。
o With a frequency determined by the value of MPL_CHECK_INT, the MPL4 router sends an MPL4 message on each interface with a header that includes the MPL Option [RFC7731]; the message is sent to multicast address ALL_MPL_FORWARDERS with scope 4.
o MPL_CHECK_INTの値によって決定される頻度で、MPL4ルーターは、MPLオプション[RFC7731]を含むヘッダーを持つ各インターフェイスでMPL4メッセージを送信します。メッセージは、スコープ4のマルチキャストアドレスALL_MPL_FORWARDERSに送信されます。
o When, within an interval determined by the value of MPL_TO no MPL message is received, the value of MPL_BLOCKED is set to TRUE.
o MPL_TOの値によって決定される間隔内にMPLメッセージが受信されない場合、MPL_BLOCKEDの値はTRUEに設定されます。
o On reception of an MPL4 message, the value of MPL_BLOCKED of the receiving interface is set to false.
o MPL4メッセージを受信すると、受信インターフェースのMPL_BLOCKEDの値がfalseに設定されます。
This protocol leads to a state where for each interface MPL_BLOCKED is set to false if and only if MPL-enabled interfaces are connected to the link associated with the interface. When an MPL message is submitted to an MPL-enabled interface called "Interface A" in the MPL router, the Trickle algorithm [RFC6206] is activated to send the MPL message. The MPL4 message with multicast address ALL_MPL_FORWARDERS scope 4 is accepted by every interface connected to the link that has subscribed to ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 message by an interface called "Interface B", the MPL4 message is returned with Trickle over Interface B. Consequently, the MPL4 message is received by the originating Interface A, after which MPL_BLOCKED is set to false.
このプロトコルは、MPL対応のインターフェースがインターフェースに関連付けられたリンクに接続されている場合にのみ、各インターフェースについてMPL_BLOCKEDがfalseに設定される状態を導きます。 MPLルーターの「インターフェースA」と呼ばれるMPL対応インターフェースにMPLメッセージが送信されると、トリクルアルゴリズム[RFC6206]がアクティブになり、MPLメッセージが送信されます。マルチキャストアドレスALL_MPL_FORWARDERSスコープ4のMPL4メッセージは、スコープ4のALL_MPL_FORWARDERSにサブスクライブしているリンクに接続されているすべてのインターフェースによって受け入れられます。「インターフェースB」と呼ばれるインターフェースがMPL4メッセージを受け入れると、MPL4メッセージはトリックルオーバーで返されますインターフェースB。その結果、MPL4メッセージは発信インターフェースAによって受信され、その後MPL_BLOCKEDがfalseに設定されます。
When a new node is connected to the link, it can immediately send an MPL4 message, or it can wait for the reception of an MPL4 message to announce its intention to be part of the MPL4 zone.
新しいノードがリンクに接続されると、すぐにMPL4メッセージを送信したり、MPL4メッセージの受信を待って、MPL4ゾーンの一部である旨を通知したりできます。
This section begins by specifying what types of multicast messages arriving at an interface are legal. It continues with a description of forwarding legal Admin-Local multicast messages over other MPL Interfaces.
このセクションでは、まず、インターフェイスに到着するマルチキャストメッセージのタイプを指定することから始めます。次に、他のMPLインターフェースを介した正当な管理ローカルマルチキャストメッセージの転送について説明します。
The policy for forwarding Admin-Local multicast messages automatically to an MPL Interface is specified as a function of the state of the MPL Interface and the multicast message. The state of the multicast message is determined by the presence of the MPL Option [RFC7731] and the destination multicast address. The state of the MPL Interface is determined by the subscribed multicast addresses, the zone index [RFC4007], and the values of the PROACTIVE_FORWARDING parameter and the MPL_BLOCKED parameter of the MPL Interface.
管理ローカルマルチキャストメッセージを自動的にMPLインターフェースに転送するためのポリシーは、MPLインターフェースとマルチキャストメッセージの状態の関数として指定されます。マルチキャストメッセージの状態は、MPLオプション[RFC7731]の存在と宛先マルチキャストアドレスによって決定されます。 MPLインターフェイスの状態は、サブスクライブされたマルチキャストアドレス、ゾーンインデックス[RFC4007]、およびMPLインターフェイスのPROACTIVE_FORWARDINGパラメータとMPL_BLOCKEDパラメータの値によって決定されます。
When the zone is undefined or not enabled, all interfaces have the same zone index.
ゾーンが未定義または有効でない場合、すべてのインターフェースは同じゾーンインデックスを持ちます。
Multicast messages can be created within the node by an application or can arrive at an interface.
マルチキャストメッセージは、アプリケーションによってノード内で作成することも、インターフェイスに到達することもできます。
A multicast message created at a source (MPL Seed) is legal when it conforms to the properties described in Section 9.1 of [RFC7731].
[RFC7731]のセクション9.1で説明されているプロパティに準拠している場合、ソース（MPLシード）で作成されたマルチキャストメッセージは有効です。
A multicast message received at a given interface is legal when:
特定のインターフェイスで受信したマルチキャストメッセージは、次の場合に有効です。
o The message carries an MPL Option (MPL message) and the incoming MPL Interface is subscribed to the destination multicast address.
o メッセージにはMPLオプション（MPLメッセージ）が含まれ、着信MPLインターフェイスは宛先マルチキャストアドレスにサブスクライブされます。
o The message does not carry an MPL Option and the interface has expressed interest in receiving messages with the specified multicast address via Multicast Listener Discovery (MLD) [RFC3810] or IGMP [RFC3376]. The message was forwarded according to Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] or Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601].
o メッセージにMPLオプションが含まれておらず、インターフェイスは、マルチキャストリスナ探索（MLD）[RFC3810]またはIGMP [RFC3376]を介して、指定されたマルチキャストアドレスを持つメッセージを受信することに関心を示しています。メッセージは、プロトコルに依存しないマルチキャスト-高密度モード（PIM-DM）[RFC3973]またはプロトコルに依存しないマルチキャスト-スパースモード（PIM-SM）[RFC4601]に従って転送されました。
Illegal multicast messages are discarded.
不正なマルチキャストメッセージは破棄されます。
A legal multicast message received at a given interface is assigned the network identifier of the interface of the incoming link. A message that is created within the node is assigned the network identifier "any".
特定のインターフェイスで受信された正当なマルチキャストメッセージには、着信リンクのインターフェイスのネットワーク識別子が割り当てられます。ノード内で作成されるメッセージには、ネットワーク識別子「any」が割り当てられます。
Two types of legal multicast messages are considered in Section 4.1: (1) MPL messages and (2) multicast messages that do not carry the MPL Option.
セクション4.1では、2つのタイプの正当なマルチキャストメッセージが考慮されます。（1）MPLメッセージと（2）MPLオプションを伝送しないマルチキャストメッセージです。
MPL messages are forwarded on MPL Interfaces using the Trickle parameter values assigned to the MPL Interface according to the following rules:
MPLメッセージは、次のルールに従ってMPLインターフェイスに割り当てられたトリクルパラメータ値を使用して、MPLインターフェイスで転送されます。
o Link-Local (scope 2) MPL messages are not forwarded.
o リンクローカル（スコープ2）MPLメッセージは転送されません。
o Realm-Local (scope 3) MPL messages are forwarded on all MPL Interfaces where all of the following are true:
o レルムローカル（スコープ3）MPLメッセージは、次のすべてが当てはまるすべてのMPLインターフェースで転送されます。
* The multicast address to which the MPL Interface subscribes is the same as the multicast address of the MPL message.
* MPLインターフェイスがサブスクライブするマルチキャストアドレスは、MPLメッセージのマルチキャストアドレスと同じです。
* The zone index of the MPL Interface is the same as the zone index of the MPL Interface on which the MPL message was received.
* MPLインターフェイスのゾーンインデックスは、MPLメッセージが受信されたMPLインターフェイスのゾーンインデックスと同じです。
* The MPL Interface has PROACTIVE_FORWARDING set to TRUE.
* MPLインターフェースでは、PROACTIVE_FORWARDINGがTRUEに設定されています。
* The assigned network identifier of the MPL message is "any", or the assigned network identifier of the MPL message is equal to the network identifier of the MPL Interface.
* MPLメッセージの割り当てられたネットワーク識別子が「任意」であるか、MPLメッセージの割り当てられたネットワーク識別子がMPLインターフェースのネットワーク識別子と等しい。
o Admin-Local (scope 4) MPL messages are forwarded on all MPL Interfaces that are subscribed to the same multicast address, have the same zone index, have PROACTIVE_FORWARDING set to TRUE, and have MPL_BLOCKED set to false.
o Admin-Local（スコープ4）MPLメッセージは、同じマルチキャストアドレスにサブスクライブされ、同じゾーンインデックスを持ち、PROACTIVE_FORWARDINGがTRUEに設定され、MPL_BLOCKEDがfalseに設定されているすべてのMPLインターフェースで転送されます。
o MPL messages that encapsulate a message with a multicast scope of 5 or higher are decapsulated and forwarded over the interface when the interface is subscribed to the multicast address of the decapsulated message.
o マルチキャストスコープが5以上のメッセージをカプセル化するMPLメッセージは、カプセル化が解除されたメッセージのマルチキャストアドレスにインターフェイスがサブスクライブされると、カプセル化が解除され、インターフェイスを介して転送されます。
Multicast messages without the MPL Option are forwarded on MPL Interfaces according to the following rules:
MPLオプションのないマルチキャストメッセージは、次のルールに従ってMPLインターフェイスで転送されます。
o Link-Local (scope 2), Realm-Local (scope 3), and Admin-Local (scope 4) multicast messages are not forwarded.
o Link-Local（スコープ2）、Realm-Local（スコープ3）、およびAdmin-Local（スコープ4）マルチキャストメッセージは転送されません。
o Multicast messages with a multicast scope of 5 or higher are encapsulated in an MPL message with destination address ALL_MPL_FORWARDERS with scope 4. The resulting message is then treated as described in Section 4.2.1.
o マルチキャストスコープが5以上のマルチキャストメッセージは、スコープ4の宛先アドレスALL_MPL_FORWARDERSを持つMPLメッセージにカプセル化されます。結果のメッセージは、セクション4.2.1で説明されているように処理されます。
An incoming message protected at Layer 2 MUST be subsequently re-protected at Layer 2 at all outgoing interfaces. Incoming messages are integrity checked and optionally decrypted at the incoming interface at Layer 2 using the keys and protection algorithm appropriate to the incoming interface's network and are re-protected at the outgoing interface using the keys and protection algorithm appropriate to the outgoing interface's network. It may be necessary to assess the relative levels of protection on the respective interfaces and apply policy rules -- for example, to avoid downgrading security where one network has a lower level of security than another.
レイヤー2で保護された着信メッセージは、その後すべての発信インターフェイスのレイヤー2で再保護される必要があります。着信メッセージは整合性チェックされ、オプションで、レイヤ2の着信インターフェイスで、着信インターフェイスのネットワークに適切なキーと保護アルゴリズムを使用して復号化され、発信インターフェイスで、発信インターフェイスのネットワークに適切なキーと保護アルゴリズムを使用して再保護されます。それぞれのインターフェイスの相対的な保護レベルを評価し、ポリシールールを適用することが必要な場合があります。たとえば、あるネットワークのセキュリティレベルが他のネットワークよりも低い場合、セキュリティのダウングレードを回避します。
An incoming MPL4 message that is not protected at Layer 2 MUST NOT be re-protected at Layer 2 at all outgoing interfaces.
レイヤー2で保護されていない着信MPL4メッセージは、すべての発信インターフェイスのレイヤー2で再保護してはなりません（MUST NOT）。
An MPL Domain is a scope zone in which MPL Interfaces subscribe to the same MPL Domain Address [RFC7731]. In accordance with [RFC4007], a zone boundary passes through a node. For example, a small Low-Power and Lossy Network (LLN) node usually has one MPL mesh interface that is subscribed to the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [RFC7346]. The node interface belongs to the zone, and the corresponding zone boundary does not pass through this node. In the border router with MPL Interfaces subscribed to the multicast address ALL_MPL_FORWARDERS with scope value 3, the zone usually includes this single interface and excludes all other interfaces. A notable exception is provided by a node where MPL Interfaces of the same technology share the same network identifier. These interfaces belong to the same MPL4 zone when the interfaces share the same zone index.
MPLドメインは、MPLインターフェイスが同じMPLドメインアドレス[RFC7731]にサブスクライブするスコープゾーンです。 [RFC4007]に従って、ゾーン境界はノードを通過します。たとえば、小規模な低電力および損失の多いネットワーク（LLN）ノードには、通常、スコープ値が3（レルムローカル）[RFC7346]のALL_MPL_FORWARDERSマルチキャストアドレスにサブスクライブされている1つのMPLメッシュインターフェイスがあります。ノードインターフェイスはゾーンに属しており、対応するゾーン境界はこのノードを通過しません。スコープ値3のマルチキャストアドレスALL_MPL_FORWARDERSにサブスクライブされたMPLインターフェイスを持つ境界ルーターでは、ゾーンは通常、この単一のインターフェイスを含み、他のすべてのインターフェイスを除外します。注目すべき例外は、同じテクノロジーのMPLインターフェースが同じネットワーク識別子を共有するノードによって提供されます。インターフェイスが同じゾーンインデックスを共有する場合、これらのインターフェイスは同じMPL4ゾーンに属します。
In an MPL4 router, every MPL Interface subscribes to the Admin-Local ALL_MPL_FORWARDERS multicast address in addition to the Realm-Local ALL_MPL_FORWARDERS address.
MPL4ルーターでは、すべてのMPLインターフェースが、レルムローカルALL_MPL_FORWARDERSアドレスに加えて、アドミンローカルALL_MPL_FORWARDERSマルチキャストアドレスにサブスクライブします。
Every interface that belongs to an MPL Domain that extends over border routers MUST be subscribed to the Admin-Local ALL_MPL_FORWARDERS address.
境界ルーターを越えて拡張するMPLドメインに属するすべてのインターフェースは、Admin-Local ALL_MPL_FORWARDERSアドレスにサブスクライブする必要があります。
The MPL4 zone corresponding with the MPL multicast address ALL_MPL_FORWARDERS with scope 4 (Admin-Local) applies to border routers with multiple interfaces, of which at least one interface is MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS with scope 4. In a border router, all MPL-enabled interfaces that subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for which MPL_BLOCKED is false belong to the same MPL4 zone when the interfaces share the same zone index.
スコープ4（Admin-Local）のMPLマルチキャストアドレスALL_MPL_FORWARDERSに対応するMPL4ゾーンは、複数のインターフェイスを持つ境界ルーターに適用され、そのうち少なくとも1つのインターフェイスはMPLが有効で、スコープ4のマルチキャストアドレスALL_MPL_FORWARDERSにサブスクライブされています。 、スコープ4でALL_MPL_FORWARDERSアドレスにサブスクライブし、MPL_BLOCKEDがfalseであるすべてのMPL対応インターフェースは、インターフェースが同じゾーンインデックスを共有する場合、同じMPL4ゾーンに属します。
MPL4 messages remain bounded within a zone as defined in [RFC4007]. Consequently, MPL4 messages cannot be routed between interfaces belonging to different zones. When the concept of zone is unknown or disabled in a router, all interfaces belong to the same zone. For example, consider a router with five interfaces, where Interfaces A and B belong to zone 1 and Interfaces C, D, and E belong to zone 2. MPL4 messages can be routed freely between Interfaces A and B, and freely between Interfaces C, D, and E. However, an MPL4 message MUST NOT be routed from Interface A to Interface D.
[RFC4007]で定義されているように、MPL4メッセージはゾーン内で制限されたままです。したがって、MPL4メッセージは、異なるゾーンに属するインターフェース間でルーティングできません。ゾーンの概念が不明またはルーターで無効になっている場合、すべてのインターフェースは同じゾーンに属します。たとえば、5つのインターフェイスを持つルーターを考えてみます。インターフェイスAとBはゾーン1に属し、インターフェイスC、D、Eはゾーン2に属しています。MPL4メッセージは、インターフェイスAとBの間、およびインターフェイスCの間を自由にルーティングできます。 D、およびE。ただし、MPL4メッセージをインターフェイスAからインターフェイスDにルーティングしてはなりません（MUST NOT）。
Three parameters are created by this document. Their values are related to the Trickle timer intervals.
このドキュメントでは、3つのパラメータが作成されます。それらの値は、トリクルタイマー間隔に関連しています。
o MPL_TO = DATA_MESSAGE_IMAX times 2, which leaves enough time to receive the second response message.
o MPL_TO = DATA_MESSAGE_IMAX×2。これは、2番目の応答メッセージを受信するのに十分な時間を残します。
o MPL_CHECK_INT = 5 minutes, which means that a reaction to a network malfunction happens within 5 minutes.
o MPL_CHECK_INT = 5分。これは、ネットワークの誤動作に対する反応が5分以内に発生することを意味します。
o MPL_BLOCKED = TRUE, which means that the interface has not received MPL-enabled messages to include the interface in the MPL4 zone.
o MPL_BLOCKED = TRUE。これは、インターフェイスがMPL対応ゾーンにインターフェイスを含めるためのMPL対応メッセージを受信していないことを意味します。
The security considerations of [RFC7731] also apply to MPL4 routers.
[RFC7731]のセキュリティに関する考慮事項は、MPL4ルーターにも適用されます。
The sending of MPL4 messages by a malicious node can have unwanted consequences, as explained by the following example. It is not unusual for a wired (e.g., Ethernet) link to be used between two floors or sections of an LLN, as radio propagation through reinforced concrete is generally poor. The MPL4 zone can thus envelop multiple routers, meshes, and links. It is possible that a malicious node could connect to a wired link on which no MPL-enabled nodes are foreseen. In this example configuration, the malicious node can send MPL4 messages to the MPL4 router interfaces. When nothing is done, the MPL4 routers will consequently distribute MPL4 messages from one mesh over the wired link to the next mesh, although the wired link was not expected to transport MPL4 messages.
悪意のあるノードがMPL4メッセージを送信すると、次の例で説明するように、望ましくない結果が生じる可能性があります。鉄筋コンクリートを介した無線伝搬は一般的に貧弱であるため、LLNの2つのフロアまたはセクション間で有線（イーサネットなど）リンクを使用することは珍しいことではありません。したがって、MPL4ゾーンは複数のルーター、メッシュ、リンクを包み込むことができます。悪意のあるノードが、MPL対応ノードが予測されていない有線リンクに接続する可能性があります。この構成例では、悪意のあるノードがMPL4メッセージをMPL4ルーターインターフェイスに送信できます。何も行われなかった場合、有線リンクはMPL4メッセージを転送することは想定されていませんでしたが、MPL4ルーターはその結果、有線リンクを介して1つのメッシュから次のメッシュにMPL4メッセージを配信します。
To understand the consequences of this unwanted behavior, the following cases should be distinguished:
この望ましくない動作の結果を理解するには、次のケースを区別する必要があります。
o The source mesh uses Layer 2 encryption.
o ソースメッシュはレイヤー2暗号化を使用します。
o The MPL4 router can be managed.
o MPL4ルーターを管理できます。
The four possible combinations are discussed below:
4つの可能な組み合わせについて、以下で説明します。
Layer 2 unsecured, router unmanaged: In this case, MPL4 messages are freely distributed over meshes and links that are interconnected by MPL4 routers within a zone. The MPL-enabled (malicious) nodes can read all MPL4 messages and distribute MPL4 messages over a network limited by a zone. This situation can be acceptable for an isolated network within a clearly defined space, where the connection of nodes can be tightly controlled. A completely wired LLN, e.g., such as is seen in BACnet (a protocol for building automation and control networks) [BACnet] is an example of an unencrypted LLN that would be considered physically secure.
レイヤー2のセキュリティ保護されていない、管理されていないルーター：この場合、MPL4メッセージは、ゾーン内のMPL4ルーターによって相互接続されているメッシュとリンクに自由に配信されます。 MPL対応の（悪意のある）ノードは、すべてのMPL4メッセージを読み取り、ゾーンによって制限されたネットワークを介してMPL4メッセージを配布できます。この状況は、ノードの接続を厳密に制御できる、明確に定義されたスペース内の分離されたネットワークでは許容できます。たとえば、BACnet（自動化および制御ネットワークを構築するためのプロトコル）[BACnet]に見られるような完全に有線のLLNは、物理的に安全であると見なされる暗号化されていないLLNの例です。
Layer 2 secured, router unmanaged: In this case, MPL4 messages are freely distributed over meshes and links that are interconnected by MPL4 routers within a zone. Following the rules of Section 4.3, the MPL4-enabled (malicious) nodes cannot read the MPL4 messages, and MPL4 messages sent by the malicious node are not accepted by other nodes. This situation is acceptable for a home network or managed network extending over precisely one zone, occupying a clearly defined physical space, where ease of installation is important. In such a network, the presence of the malicious node is not different from any other malicious node that tries to send messages over Layer 2 protected links. Because the network occupies exactly one zone, the MPL4 message distribution cannot be extended outside the network.
レイヤー2保護、ルーター非管理：この場合、MPL4メッセージは、ゾーン内のMPL4ルーターによって相互接続されたメッシュとリンクに自由に配信されます。セクション4.3のルールに従って、MPL4対応（悪意のある）ノードはMPL4メッセージを読み取ることができず、悪意のあるノードによって送信されたMPL4メッセージは他のノードによって受け入れられません。この状況は、インストールの容易さが重要な、明確に定義された物理スペースを占有する、正確に1つのゾーンにまたがるホームネットワークまたは管理対象ネットワークでは許容できます。このようなネットワークでは、悪意のあるノードの存在は、レイヤー2保護リンクを介してメッセージを送信しようとする他の悪意のあるノードと違いはありません。ネットワークは1つのゾーンしか占有しないため、MPL4メッセージ配信をネットワークの外部に拡張することはできません。
Layer 2 unsecured, router managed: In this case, the distribution of MPL4 messages over MPL4 router interfaces can be limited to those interfaces for which a manager has enabled MPL, as well as a set of multicast addresses. The malicious node cannot extend the distribution of MPL4 messages over unwanted interfaces. It is important that the handling of the interfaces by the manager is protected. However, MPL4 messages sent over the mesh can be interpreted by malicious nodes, and malicious messages can be injected into the set of meshes and links that are connected by the MPL4 routers for which the manager enabled the interfaces. This situation can be practical for interconnected links and meshes that are connected to a LAN over a limited period -- for example, during installation of the interconnected meshes and links.
セキュリティで保護されていないレイヤー2のルーター管理：この場合、MPL4ルーターインターフェイスを介したMPL4メッセージの配信は、マネージャーがMPLを有効にしたインターフェイスとマルチキャストアドレスのセットに制限できます。悪意のあるノードは、不要なインターフェースを介してMPL4メッセージの配信を拡張できません。マネージャーによるインターフェースの処理が保護されていることが重要です。ただし、メッシュを介して送信されたMPL4メッセージは悪意のあるノードによって解釈され、マネージャーがインターフェイスを有効にしたMPL4ルーターによって接続されたメッシュとリンクのセットに悪意のあるメッセージが挿入される可能性があります。この状況は、相互接続されたメッシュやリンクのインストール中など、限られた期間にLANに接続された相互接続されたリンクやメッシュの場合に実用的です。
Layer 2 secured, router managed: In this case, the distribution of MPL4 messages over MPL4 router interfaces can be limited to those interfaces for which a manager has enabled MPL, as well as a set of multicast addresses. Following the rules of Section 4.3, the malicious node cannot extend the distribution of MPL4 messages over unwanted interfaces, and MPL4 messages sent by the malicious node are not accepted by other nodes. It is important that the handling of the interfaces by the manager is protected. The MPL-enabled (malicious) nodes cannot read the MPL4 messages, and MPL4 messages sent by the malicious node are not accepted by other nodes. Depending on the number of managed interfaces, the network can progressively pass from autoconfigured to fully administratively controlled.
レイヤー2保護、ルーター管理：この場合、MPL4ルーターインターフェイスを介したMPL4メッセージの配信は、マネージャーがMPLを有効にしたインターフェイスと、マルチキャストアドレスのセットに制限できます。セクション4.3のルールに従い、悪意のあるノードはMPL4メッセージの配信を不要なインターフェイスに拡張できず、悪意のあるノードによって送信されたMPL4メッセージは他のノードによって受け入れられません。マネージャーによるインターフェースの処理が保護されていることが重要です。 MPL対応の（悪意のある）ノードはMPL4メッセージを読み取ることができず、悪意のあるノードによって送信されたMPL4メッセージは他のノードによって受け入れられません。管理インターフェースの数に応じて、ネットワークは自動構成から完全に管理された制御に段階的に移行できます。
[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>。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R。、編、およびL. Costa、編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<http：// www。 rfc-editor.org/info/rfc3810>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< http://www.rfc-editor.org/info/rfc3376>。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, <http://www.rfc-editor.org/info/rfc4007>.
[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6 Scoped Address Architecture」、RFC 4007、DOI 10.17487 / RFC4007、2005年3月、<http：/ /www.rfc-editor.org/info/rfc4007>。
[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, DOI 10.17487/RFC5416, March 2009, <http://www.rfc-editor.org/info/rfc5416>.
[RFC5416] Calhoun、P。、編、Montemurro、M、編、およびD. Stanley、編、「IEEE 802.11用のワイヤレスアクセスポイント（CAPWAP）プロトコルバインディングの制御とプロビジョニング」、RFC 5416、DOI 10.17487 / RFC5416、2009年3月、<http://www.rfc-editor.org/info/rfc5416>。
[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>。
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, DOI 10.17487/RFC7346, August 2014, <http://www.rfc-editor.org/info/rfc7346>.
[RFC7346] Droms、R。、「IPv6マルチキャストアドレススコープ」、RFC 7346、DOI 10.17487 / RFC7346、2014年8月、<http://www.rfc-editor.org/info/rfc7346>。
[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>。
[IEEE802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE 802.15.4, DOI 10.1109/ieeestd.2011.6012487, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>.
[IEEE802.15.4] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）」、IEEE 802.15.4、DOI 10.1109 / ieeestd.2011.6012487、<http： //ieeexplore.ieee.org/servlet/ opac？punumber = 6012485>。
[IEEE802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6178209>.
[IEEE802.11] IEEE、「IEEE Standard for Information technology-- Telecommunications and information exchange between system Local and Metropolitan Area Network--Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、 IEEE 802.11-2012、DOI 10.1109 / ieeestd.2012.6178212、<http://ieeexplore.ieee.org/servlet/ opac？punumber = 6178209>。
[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.
[G.9959]国際電気通信連合、「短距離狭帯域デジタル無線通信トランシーバー-PHY、MAC、SARおよびLLCレイヤー仕様」、ITU-T勧告G.9959、2015年1月、<http：//www.itu。 int / rec / T-REC-G.9959>。
[BTLE] Bluetooth Special Interest Group, "Bluetooth Core Specification Version 4.1", December 2013, <https://www.bluetooth.org/en-us/specification/ adopted-specifications>.
[BTLE] Bluetooth Special Interest Group、「Bluetooth Core Specification Version 4.1」、2013年12月、<https://www.bluetooth.org/en-us/specification/ expanded-specifications>。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, <http://www.rfc-editor.org/info/rfc3973>.
[RFC3973] Adams、A.、Nicholas、J。、およびW. Siadak、「Protocol Independent Multicast-Dense Mode（PIM-DM）：Protocol Specification（Revised）」、RFC 3973、DOI 10.17487 / RFC3973、2005年1月、< http://www.rfc-editor.org/info/rfc3973>。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、DOI 10.17487 / RFC4601 、2006年8月、<http://www.rfc-editor.org/info/rfc4601>。
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, <http://www.rfc-editor.org/info/rfc7576>.
[RFC7576] Jiang、S.、Carpenter、B。、およびM. Behringer、「Autonomic Networkingの一般的なギャップ分析」、RFC 7576、DOI 10.17487 / RFC7576、2015年6月、<http://www.rfc-editor.org / info / rfc7576>。
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <http://www.rfc-editor.org/info/rfc7428>.
[RFC7428] Brandt、A。およびJ. Buron、「ITU-T G.9959ネットワークを介したIPv6パケットの送信」、RFC 7428、DOI 10.17487 / RFC7428、2015年2月、<http://www.rfc-editor.org / info / rfc7428>。
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <http://www.rfc-editor.org/info/rfc7668>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z。、およびC. Gomez、「IPv6 over BLUETOOTH（R）Low Energy」、RFC 7668、DOI 10.17487 / RFC7668、2015年10月、<http://www.rfc-editor.org/info/rfc7668>。
[BACnet] "BACnet Webpage", <http://www.bacnet.org>.
[BACnet]「BACnet Webページ」、<http://www.bacnet.org>。
Acknowledgements
謝辞
This document reflects discussions and remarks from several individuals, including (in alphabetical order) Scott Bradner, Esko Dijk, Adrian Farrel, Matthew Gillmore, Joel Halpern, Steve Hanna, Michael Richardson, and Pascal Thubert.
このドキュメントは、スコットブラドナー、エスコダイク、エイドリアンファレル、マシューギルモア、ジョエルハルパーン、スティーブハンナ、マイケルリチャードソン、パスカルチューバートなど、いくつかの個人からの議論と意見を反映しています。
Authors' Addresses
著者のアドレス
Peter van der Stok Consultant
Peter van der Stokコンサルタント
Email: consultancy@vanderstok.org
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJイギリス
Email: robert.cragie@arm.com