[要約] RFC 9035は、低電力かつ損失が多いネットワーク向けのルーティングプロトコルであるRPLのための、6LoWPANルーティングヘッダーにDODAG（Destination-Oriented Directed Acyclic Graph）設定オプションを追加する内容です。この文書の目的は、効率的なデータ転送とネットワークのスケーラビリティを向上させるために、RPLネットワーク内での経路設定を最適化することにあります。主に、スマートシティ、環境モニタリング、スマートホームなどのIoTアプリケーションで利用されます。
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9035 L. Zhao
Updates: 8138 Cisco Systems
Category: Standards Track April 2021
ISSN: 2070-1721
A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header
6LOWPANルーティングヘッダの低電力および非損失ネットワーク（RPL）宛先指向無指向性非晶グラフ（DODAG）設定オプションのためのルーティングプロトコル
Abstract
概要
This document updates RFC 8138 by defining a bit in the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset.
このドキュメントは、RPLインスタンス内で圧縮が使用されているかどうかを示すために、低電力および非損失ネットワーク（RPL）宛先指向特異的非晶グラフ（DODAG）設定オプションのルーティングプロトコルのビットを定義することによって、RFC 8138を更新します。ビットが設定されているときにRFC 8138に準拠したノード。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9035.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9035で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Related Documents
2.2. Glossary
2.3. Requirements Language
3. Extending RFC 6550
4. Updating RFC 8138
5. Transition Scenarios
5.1. Coexistence
5.2. Inconsistent State While Migrating
5.3. Rolling Back
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
The design of Low-Power and Lossy Networks (LLNs) is generally focused on saving energy, which is the most constrained resource of all. The routing optimizations in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550], such as routing along a Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node and the associated routing header compression and forwarding technique specified in [RFC8138], derive from that primary concern.
低消費電力および非損失ネットワーク（LLN）の設計は一般にエネルギーを節約することに焦点を当てており、これは全部の最も拘束されたリソースです。宛先指向の指向性非巡回グラフ（DODAG）へのルーティングなど、ルートノードへのルーティングなどの「RPL：IPv6ルーティングプロトコル」のルーティング最適化、および指定された関連ルーティングヘッダー圧縮および転送手法[RFC8138]では、その主な関心事から派生しています。
Enabling [RFC8138] on a running network requires a "flag day", where the network is upgraded and rebooted. Otherwise, if acting as a leaf, a node that does not support compression per [RFC8138] would fail to communicate; if acting as a router, it would drop the compressed packets and black-hole a portion of the network. This specification enables a hot upgrade where a live network is migrated. During the migration, compression remains inactive until all nodes are upgraded.
実行中のネットワーク上の[RFC8138]を有効にするには、ネットワークがアップグレードされ再起動されている「Flag Day」が必要です。それ以外の場合、リーフとして機能している場合、[RFC8138]ごとに圧縮をサポートしないノードは通信に失敗します。ルータとして機能する場合は、圧縮パケットとブラックホールがネットワークの一部を削除します。この仕様では、ライブネットワークが移行される場所のホットアップグレードを可能にします。移行中に、すべてのノードがアップグレードされるまで圧縮は非アクティブです。
This document complements [RFC8138] and signals whether it should be used within a RPL DODAG with a new flag in the RPL DODAG Configuration option. The setting of this new flag is controlled by the Root and propagates as is in the whole network as part of the normal RPL signaling.
このドキュメントは[RFC8138]を補完し、RPDAG構成オプションの新しいフラグを持つRPDAG内で使用する必要があるかどうかを示します。この新しいフラグの設定は、ルートによって制御され、通常のRPLシグナリングの一部としてネットワーク全体のように伝播されます。
The flag is cleared to ensure that compression remains inactive during the migration phase. When the migration is complete (e.g., as known by network management and/or inventory), the flag is set and compression is globally activated in the whole DODAG.
移行フェーズ中に圧縮が非アクティブのままであることを確認するためにフラグがクリアされます。移行が完了したら（例えば、ネットワーク管理および/または在庫によって知られているように）、フラグは設定され、圧縮はDoDag全体でグローバルに活性化される。
The terminology used in this document is consistent with, and incorporates the terms provided in, "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]. Other terms in use as related to LLNs are found in "Terminology for Constrained-Node Networks" [RFC7228].
この文書で使用されている用語は、「低電力および非損失ネットワークのためのルーティングで使用される用語」[RFC7102]に記載されている用語を組み込んでいます。LLNに関連する他の用語は、「拘束ノードネットワークの用語」[RFC7228]にあります。
"RPL", "RPL Packet Information" (RPI), and "RPL Instance" (indexed by a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract information that RPL defines to be placed in data packets, e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By extension, the term "RPI" is often used to refer to the RPL Option itself. The DODAG Information Solicitation (DIS), Destination Advertisement Object (DAO), and DODAG Information Object (DIO) messages are also specified in [RFC6550].
「RPL」、「RPLパケット情報」（RPI）、および「RPLインスタンス」（RPLINSTANCEIDによって索引付けされている）は、「RPL：LOSPYネットワークのRPV6ルーティングプロトコル」で定義されています[RFC6550]。RPIは、RPLがIPv6ホップバイホップヘッダー内のRPLオプション[RFC6553]として、RPLがデータパケットに配置されることを定義する抽象情報です。拡張によって、「RPI」という用語は、RPLオプション自体を指すためによく使用されます。[RFC6550]で、DODAG情報勧誘（DIS）、宛先広告オブジェクト（DAO）、およびDODAG Information Object（DIO）メッセージも指定されています。
This document uses the terms "RPL-Unaware Leaf" (RUL) and "RPL-Aware Leaf" (RAL) consistently with "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008]. The term "RPL-Aware Node" (RAN) refers to a node that is either a RAL or a RPL router. A RAN manages the reachability of its addresses and prefixes by injecting them in RPL by itself. In contrast, a RUL leverages "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505] to obtain reachability services from its parent router(s) as specified in "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves" [RFC9010].
この文書では、用語「RPL-Unaware Leaf」（RPIオプションタイプの使用、ソースルートのルーティングヘッダー、およびRPLデータプレーンのIPv6-IN-IPv6カプセル化）という用語を使用します。「[RFC9008]。「RPL対応ノード」（RAN）という用語は、RALまたはRPLルータのいずれかであるノードを指す。RANは、RPLでそれらをそれ自体に注入することによって、アドレスとプレフィックスの到達可能性を管理します。これとは対照的に、RUPのルーティング（RPR（ルーティングプロトコル）で指定されている親ルータからの到達可能性サービスを取得するために、ルーパンの無線パーソナルディスカバリ（6lowpan）隣接ディスカバリの登録拡張機能（RFC8505]の登録拡張機能をレバレッジする。低消費電力と損失のあるネットワークは「rfc9010」を残します。
This document often uses the following abbreviations:
この文書はしばしば以下の略語を使用します。
6LoRH: 6LoWPAN Routing Header 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network DIO: DODAG Information Object (a RPL message) DODAG: Destination-Oriented Directed Acyclic Graph LLN: Low-Power and Lossy Network MOP: RPL Mode of Operation RAL: RPL-Aware Leaf RAN: RPL-Aware Node RPI: RPL Packet Information RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RUL: RPL-Unaware Leaf SRH: Source Routing Header Sub-DODAG: The sub-DODAG of a node is a DODAG rooted at that node that is a subset of a main DODAG the node belongs to. It is formed by the other nodes in the main DODAG whose paths to the main DODAG root pass through that node.
6lowpanルーティングヘッダー6lowpan：低電力無線パーソナルエリアネットワークDIO：DODAG情報オブジェクト（RPLメッセージ）DODAG：宛先指向特異的非巡回グラフLLN：低電力および非損失ネットワークMOP：RP演算モードRAL：RPL対応リーフRAN：RPL対応ノードRPI：RPLパケット情報RPL：低電力および非損失ネットワークのためのIPv6ルーティングプロトコルRUL：RPL - アンウェアリーフSRH：ソースルーティングヘッダサブダグ：ノードのサブダグはそのノードであるそのノードに根ざしたドダグは、ノードが属する。メインドダグルートへのパスがそのノードを通過するメインドダグ内の他のノードによって形成されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The DODAG Configuration option is defined in Section 6.7.6 of [RFC6550]. Its purpose is extended to distribute configuration information affecting the construction and maintenance of the DODAG, as well as operational parameters for RPL on the DODAG, through the DODAG. The DODAG Configuration option was originally designed with four bit positions reserved for future use as flags.
DODAG設定オプションは[RFC6550]の6.7.6項で定義されています。その目的は、DODAGを介してDODAGの構造と保守に影響を与える構成情報を配布するために拡張されています。DODAG設定オプションは、Flagsとして将来の使用のために予約されている4つのビット位置を使用して設計されていました。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| | |T| |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
<- flags ->
Figure 1: DODAG Configuration Option (Partial View)
図1：DODAG設定オプション（部分ビュー）
This specification defines a new flag, "Enable Compression per RFC 8138 (T)". The 'T' flag is set to turn on the use of [RFC8138] within the DODAG. The 'T' flag is encoded in position 2 of the reserved flags in the DODAG Configuration option (counting from bit 0 as the most significant bit) and set to 0 in legacy implementations as specified in Sections 20.14 and 6.7.6 of [RFC6550], respectively.
この仕様では、新しいフラグを定義します。「RFC 8138（T）ごとの圧縮を有効にする」です。'T'フラグは、DoDag内の[RFC8138]の使用をオンにするように設定されています。't'フラグは、DoDag構成オプション（最上位ビットとしてのビット0からカウントする）の予約フラグの位置2でエンコードされ、[RFC6550]のセクション20.14および6.7.6で指定されているようにレガシー実装で0に設定されています。それぞれ。
Section 4.1.2 of [RFC9008] updates [RFC6550] to indicate that the definition of the flags applies to Mode of Operation (MOP) values zero (0) to six (6) only. For a MOP value of 7, [RFC8138] MUST be used on links where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT be used otherwise.
[RFC9008]のセクション4.1.2 [RFC6550]フラグの定義が動作モード（MOP）値ゼロ（0）から6（6）のみに適用されることを示すために[RFC6550]。7のMOP値の場合、[RFC8138]は6lowpanヘッダー圧縮[RFC6282]が適用され、そうでなければ使用されてはならないリンクで使用する必要があります。
The RPL DODAG Configuration option is typically placed in a DIO message. The DIO message propagates down the DODAG to form and then maintain its structure. The DODAG Configuration option is copied unmodified from parents to children. [RFC6550] states that "Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option." Therefore, a legacy parent propagates the 'T' flag as set by the Root, and when the 'T' flag is set, it is transparently flooded to all the nodes in the DODAG.
RPDAG設定オプションは通常DIOメッセージに配置されます。DIOメッセージはDODAGを下に伝播してその構造を維持します。DoDag設定オプションは、両親から子供に変更されずにコピーされます。[RFC6550]「DoDag構成オプションを伝播するときにDoDagルート以外のノードはこの情報を変更してはいけません」と述べています。したがって、従来の親がルートによって設定されているように 'T'フラグを伝播し、 't'フラグが設定されているとき、それはDoDag内のすべてのノードに透過的にフラッディングされます。
A node SHOULD generate packets in compressed form using [RFC8138] if and only if the 'T' flag is set. This behavior can be overridden by configuration or network management. Overriding may be needed, e.g., to turn on compression in a network where all nodes support [RFC8138] but the Root does not support this specification and cannot set the 'T' flag, or to disable it locally in case of a problem.
ノードは、 't'フラグが設定されている場合に限り、[RFC8138]を使用して圧縮形式でパケットを生成する必要があります。この現象は、構成またはネットワーク管理によって上書きすることができます。オーバーライドは、例えば、すべてのノードが[RFC8138]をサポートしているが、ルートがこの仕様をサポートしておらず、問題が発生した場合にローカルでそれを無効にすることができないネットワーク内の圧縮をオンにすることが必要になる場合があります。
The decision to use [RFC8138] is made by the originator of the packet, depending on its capabilities and its knowledge of the state of the 'T' flag. A router encapsulating a packet is the originator of the resulting packet and is responsible for compressing the outer headers per [RFC8138], but it MUST NOT perform compression on the encapsulated packet.
[RFC8138]を使用する決定は、その機能とそのフラグの状態に関するその能力とその知識に応じて、パケットの発信者によって行われます。パケットをカプセル化するルータは、結果のパケットの発信者であり、[RFC8138]ごとに外部ヘッダーを圧縮する責任がありますが、カプセル化されたパケットで圧縮を実行してはなりません。
An external target [RFC9008] is not expected to support [RFC8138]. In most cases, packets to and from an external target are tunneled back and forth between the border router (referred to as a 6LoWPAN Router (6LR)) that serves the external target and the Root, regardless of the MOP used in the RPL DODAG. The inner packet is typically not compressed per [RFC8138], so for outgoing packets, the border router just needs to decapsulate the (compressed) outer header and forward the (uncompressed) inner packet towards the external target.
外部ターゲット[RFC9008]は[RFC8138]をサポートすることは期待されていません。ほとんどの場合、外部ターゲットとの間のパケットは、RPLドダグで使用されるモップに関係なく、外部ターゲットとルートを処理する境界ルータ（6LOWPANルータ（6LR）と呼ばれます）の間でトンネリングされます。内側のパケットは通常[RFC8138]ごとに圧縮されていないので、発信パケットには（圧縮）外部ヘッダーをカプセル化し、（圧縮されていない）内部パケットを外部のターゲットに向けて転送するだけです。
A border router that forwards a packet to an external target MUST uncompress the packet first. In all other cases, a router MUST forward a packet in the form that the source used, either compressed or uncompressed.
パケットを外部ターゲットに転送する境界ルータは、最初にパケットを解凍する必要があります。他のすべての場合では、ルータは、ソースが使用されている形式で圧縮または非圧縮の形式でパケットを転送する必要があります。
A RUL [RFC9010] is both a leaf and an external target. A RUL does not participate in RPL and depends on the parent router to obtain connectivity. In the case of a RUL, forwarding towards an external target actually means delivering the packet.
RFC9010は、葉と外部ターゲットの両方です。RULはRPLに参加しておらず、接続性を取得するために親ルータによって異なります。規則の場合、外部ターゲットに向かって転送は実際にはパケットを配信することを意味します。
A node that supports [RFC8138] but not this specification can only be used in a homogeneous network. Enabling compression per [RFC8138] without a turn-on signaling method requires a flag day, by which time all nodes must be upgraded and at which point the network can be rebooted with 6LoRH compression [RFC8138] turned on.
[RFC8138]をサポートしているが、この仕様はサポートされていないノードは、均質なネットワークでのみ使用できます。ターンオンシグナリング方法のない[RFC8138]ごとに圧縮を有効にするには、フラグの日が必要です。この時点ですべてのノードをアップグレードする必要があります。
The intent of this specification is to perform a migration once and for all, without the need for a flag day. In particular, the intent is not to undo the setting of the 'T' flag. Though it is possible to roll back (see Section 5.3), the rollback operation SHOULD be complete before the network operator adds nodes that do not support [RFC8138].
この仕様の目的は、フラグの日を必要とせずに、一度移行を一度実行することです。特に、インテントは 'T'フラグの設定を元に戻すことではありません。ロールバックすることは可能です（セクション5.3を参照）、ネットワークオペレータがサポートされていないノードを追加する前に、ロールバック操作は完了してください[RFC8138]。
A node that supports this specification can operate in a network with 6LoRH compression [RFC8138] turned on or off with the 'T' flag set accordingly and in a network in transition from off to on or on to off (see Section 5.2).
この仕様をサポートするノードは、6llh圧縮[RFC8138]が、それに応じて設定され、ネットワーク内でOFFからOFFへの移行からOFFへのネットワークでオンまたはオフになっているネットワークで動作できます（セクション5.2を参照）。
A node that does not support [RFC8138] can interoperate with nodes that do in a network with 6LoRH compression [RFC8138] turned off. If compression is turned on, all the RANs are expected to be able to handle packets in compressed form. A node that cannot do so may remain connected to the network as a RUL as described in [RFC9010].
[RFC8138]をサポートしていないノードは、6llh圧縮[RFC8138]がオフになっているネットワークで行うノードと相互運用できます。圧縮がオンになっている場合、すべてのRANは圧縮形式でパケットを処理できると予想されます。[RFC9010]に記載されているように、ネットワークに接続できないままである可能性があります。
When the 'T' flag is turned on by the Root, the information slowly percolates through the DODAG as the DIO gets propagated. Some nodes will see the flag and start sourcing packets in compressed form, while other nodes in the same RPL DODAG will still not be aware of it. In Non-Storing mode, the Root will start using [RFC8138] with a Source Routing Header 6LoRH (SRH-6LoRH) that routes all the way to the parent router or to the leaf.
「T」フラグがrootによってオンにされると、DIOが伝播するにつれてDODAGをゆっくりとゆっくりとパーコレートします。いくつかのノードはフラグを圧縮形式で開始し、同じRPDAGの他のノードがまだ認識していないことを確認します。保存されていないモードでは、ルートは[RFC8138]を[RFC8138]の使用を開始します。ソースルーティングヘッダー6LLOLH（SRH-6LLO）（SRH-6LLOLH）は、親ルータまたはリーフにルーティングします。
To ensure that a packet is forwarded across the RPL DODAG in the form in which it was generated, it is required that all the RPL nodes support [RFC8138] at the time of the switch.
パケットが生成された形式でPACKEDがRPDAGに転送されるようにするためには、スイッチの時点ですべてのRPLノードが[RFC8138]をサポートすることが必要です。
Setting the 'T' flag is ultimately the responsibility of the network administrator. The expectation is that the network management or upgrading tools in place enable the network administrator to know when all the nodes that may join a DODAG were migrated. In the case of a RPL Instance with multiple Roots, all nodes that participate in the RPL Instance may potentially join any DODAG. The network MUST be operated with the 'T' flag unset until all nodes in the RPL Instance are upgraded to support this specification.
't'フラグを設定することは、最終的にはネットワーク管理者の責任です。期待は、ネットワーク管理またはアップグレードツールが、DODAGに参加する可能性があるすべてのノードが移行されたときにネットワーク管理者が知ることができます。複数の根を持つRPLインスタンスの場合、RPLインスタンスに参加するすべてのノードがDODAGに参加する可能性があります。この仕様をサポートするためにRPLインスタンス内のすべてのノードがアップグレードされるまで、ネットワークは 't'フラグを設定解除する必要があります。
When turning 6LoRH compression [RFC8138] off in the network, the network administrator MUST wait until each node has its 'T' flag unset before allowing nodes that do not support compression in the network. Information regarding whether compression is active in a node SHOULD be exposed in the node's management interface.
ネットワーク内で6lllh圧縮[RFC8138]をオフにすると、ネットワーク内で圧縮をサポートしないノードを許可する前に、ネットワーク管理者が設定解除されるまで待つ必要があります。ノード内で圧縮がアクティブかどうかに関する情報は、ノードの管理インターフェイスに公開されるべきです。
Nodes that do not support [RFC8138] SHOULD NOT be deployed in a network where compression is turned on. If that is done, the node can only operate as a RUL.
[RFC8138]をサポートしていないノードは、圧縮がオンになっているネットワークに展開しないでください。それが完了した場合、ノードはルーとしてのみ操作できます。
This specification updates the "DODAG Configuration Option Flags for MOP 0..6" registry [RFC9008] (formerly the "DODAG Configuration Option Flags" registry, which was created for [RFC6550]), by allocating one new flag as follows:
この仕様は、次のように1つの新しいフラグを割り当てることによって、[RFC6550]に対して作成された[RFC9008]の「DoDag構成オプションフラグ」（以前は、RFC6550]に対して作成された「DoDag構成オプションフラグ」レジストリを更新します。
+------------+-------------------------------------+-----------+
| Bit Number | Capability Description | Reference |
+------------+-------------------------------------+-----------+
| 2 | Enable Compression per RFC 8138 (T) | RFC 9035 |
+------------+-------------------------------------+-----------+
Table 1: New DODAG Configuration Option Flag
表1：新しいDoDag設定オプションのフラグ
IANA has added this document as a reference for MOP 7 in the RPL "Mode of Operation" registry.
IANAはこの文書をRPLの「操作モード」レジストリのMOP 7の参照として追加しました。
It is worth noting that in RPL [RFC6550], every node in the LLN that is RPL aware and has access to the RPL domain can inject any RPL-based attack in the network; see [RFC7416] for details. This document typically applies to an existing deployment and does not change its security requirements and operations. It is assumed that the security mechanisms as defined for RPL are followed.
RPL [RFC6550]では、RPL認識でRPLドメインにアクセスできるLLN内のすべてのノードでは、ネットワーク内で任意のRPLベースの攻撃を注入できます。詳細については[RFC7416]を参照してください。この文書は通常、既存の展開に適用され、そのセキュリティ要件と操作を変更しません。RPLに定義されたセキュリティメカニズムに従うと仮定されます。
Setting the 'T' flag before all routers are upgraded may cause a loss of packets. The new bit benefits from the same protection as the rest of the information in the DODAG Configuration option that transports it. Touching the new bit is just one of the many attacks that can happen if an attacker manages to inject a corrupted configuration option in the network.
すべてのルータがアップグレードされる前に 't'フラグを設定すると、パケットが損失する可能性があります。新しいビットは、それを転送するDoDag設定オプションの残りの情報と同じ保護から利益を得ます。新しいビットに触れることは、攻撃者がネットワーク内の破損した構成オプションを注入するために管理されている場合に発生する可能性がある多くの攻撃の1つです。
Setting and unsetting the 'T' flag may create inconsistencies in the network, but as long as all nodes are upgraded to provide support for [RFC8138], they will be able to forward both forms. The source is responsible for selecting whether the packet is compressed or not, and all routers must use the format that the source selected. So, the result of an inconsistency is merely that both forms will be present in the network, at an additional cost of bandwidth for packets in uncompressed form.
設定と設定解除 'T'フラグがネットワーク内で矛盾を生み出す可能性があるが、すべてのノードが[RFC8138]のサポートを提供するためにアップグレードされる限り、それらは両方の形式を転送することができる。ソースは、パケットが圧縮されているかどうかを選択する責任があり、すべてのルーターはソースが選択されたフォーマットを使用する必要があります。したがって、矛盾の結果は、非圧縮形式のパケットの帯域幅の追加コストで、両方のフォームがネットワーク内に存在することであるということです。
An attacker may unset the 'T' flag to force additional energy consumption of child or descendant nodes in its sub-DODAG. Conversely, it may set the 'T' flag so that nodes located downstream would compress packets even when compression is not desired, potentially causing packet loss. In a tree structure, the attacker would be in a position to drop the packets from and to the attacked nodes. So, the attacks mentioned above would be more complex and more visible than simply dropping selected packets. The downstream node may have other parents and see the bit with both settings; such a situation may be detected, and an alert may be triggered.
攻撃者は、「T」のフラグを設定して、そのサブダグ内の子または子孫ノードの追加のエネルギー消費を強制することができます。逆に、圧縮が望まれていなくてもダウンストリームにあるノードがパケットを圧縮し、パケット損失を引き起こす可能性があるように、 't'フラグを設定することができる。ツリー構造では、攻撃者はパケットを攻撃されたノードとの間でドロップする位置にあります。したがって、上記の攻撃は、選択されたパケットを単にドロップするよりも複雑で見やすくなるでしょう。ダウンストリームノードは他の両親を持ち、両方の設定でビットを見てください。そのような状況を検出し、警告を引き起こすことができる。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7102] Vasseur、JP。、「低電力および非損失ネットワークのためのルーティングで使用される用語」、RFC 7102、DOI 10.17487 / RFC7102、2014年1月、<https：//www.rfc-editor.org/info/rfc7102>。
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8138] Thubert、P.、ED。、Bormann、C、Toutain、L.、R. Cragie、R.Cragie、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングヘッダ」、RFC 8138、DOI 10.17487 / RFC8138、2017年4月、<https://www.rfc-editor.org/info/rfc8138>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S.およびPerkins、「低電力無線パーソナルエリアネットワーク（6lowpan）隣接ディスカバリーに関するIPv6の登録拡張」、RFC 8505、DOI10.17487 / RFC8505、2018年11月、<https：//www.rfc-editor.org/info/rfc8505>。
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, <https://www.rfc-editor.org/info/rfc9010>.
[RFC9010] Thubert、P、ED。M. RiChardson「RPLのルーティング（低消費電力ネットワークのためのルーティングプロトコル）葉」、RFC 9010、DOI 10.17487 / RFC9010、2021年4月、<https://www.rfc-editor.org/info/rfc9010>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、2011年9月、2011年9月、<https：//www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282>。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, <https://www.rfc-editor.org/info/rfc6553>.
[RFC6553] HUI、J.およびJP。「データプレーンデータグラム」、RFC 6553、DOI 10.17487 / RFC6553、2012年3月、<https：///www.rfc-editorのvasseur、 "RPL情報のためのルーティングプロトコル）。ORG / INFO / RFC6553>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Eresut、M.およびA.ケラネン、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, <https://www.rfc-editor.org/info/rfc7416>.
[RFC7416] TSAO、T.、Alexander、R.、Dohler、M.、Daza、V.、Lozano、A.、およびM. Richardson、「低電力のためのルーティングプロトコルのセキュリティ脅威分析」2015年1月、<https：//www.rfc-editor.org/info/rfc7416>。
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI Option Type, Routing Header for Source Routes, and IPv6- in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, DOI 10.17487/RFC9008, April 2021, <https://www.rfc-editor.org/info/rfc9008>.
[RFC9008] ROBLES、MI、Richardson、M.、およびP.Thubert、「RPIオプションタイプの使用、ソースルートのルーティングヘッダー、RPLデータプレーンにおけるIPv6-in-IPv6カプセル化」、RFC 9008、DOI 10.17487 / RFC9008、2021年4月、<https：//www.rfc-editor.org/info/rfc9008>。
Acknowledgments
謝辞
The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant, Carles Gomez, Éric Vyncke, Roman Danyliw, and especially Benjamin Kaduk, Alvaro Retana, Dominique Barthel, and Rahul Jadhav for their in-depth reviews and constructive suggestions.
著者らは、Murray Kucherawy、Meral Shirazipour、Barry Leiba、Tirumaleswar Reddy、Nagendra Kumar Nainar、Stewart Bryant、Carles Gomez、Eric Vyncke、Roman Danyliw、および特にベンジャミン・カドゥー、Alvaro Retana、Dominique Barthel、Rahul Jadhav - デップスのレビューと建設的な提案。
Also, many thanks to Michael Richardson for always being helpful and responsive when the need arises.
また、マイケル・リチャードソンに常に有用であり、必要に応じて答えることができます。
Authors' Addresses
著者の住所
Pascal Thubert (editor) Cisco Systems, Inc. Building D 45 Allee des Ormes - BP1200 06254 MOUGINS - Sophia Antipolis France
Pascal Thubert（編集）Cisco Systems、Inc。Cisco Systems、Inc。建物D 45 Allee Des Ormes - BP1200 06254 Mougins - Sophia Antipolis France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Li Zhao Cisco Systems, Inc. Xinsi Building No. 926 Yi Shan Rd Shanghai 200233 China
Li Zhao Cisco Systems、Inc。XINSIビルディングNo. 926 Yi Shan RD Shanghai 200233中国
Email: liz3@cisco.com