[要約] RFC 6554は、低消費電力および損失の多いネットワーク向けのルーティングプロトコル（RPL）におけるソースルート用のIPv6ルーティングヘッダに関するものです。このRFCの目的は、RPLネットワークでのソースルーティングをサポートするためのIPv6ルーティングヘッダの仕様を提供することです。
Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6554 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 D. Culler
UC Berkeley
V. Manral
Hewlett Packard Co.
March 2012
An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
低電力および損失ネットワーク用のルーティングプロトコルを備えたソースルート用のIPv6ルーティングヘッダー（RPL）
Abstract
概要
In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain.
低電力および損失のあるネットワーク（LLN）では、ルーターのメモリの制約により、せいぜいいくつかのルートの維持に制限される場合があります。一部の構成では、これらのメモリが制約したルーターを使用して、LLN内のノードにデータグラムを配信する必要があります。低電力および損失ネットワーク（RPL）のルーティングプロトコルは、一部ではないにしてもほとんどではないにしても、ほとんどのルート（たとえば、指向性環状グラフ（DAG）ルート）またはいくつかのルーターを保存し、IPv6を転送するために、一部の展開で使用できます。データグラムは、メモリが制約されたルーター上の大きなルーティングテーブルを回避するために、ソースルーティング手法を使用しています。このドキュメントは、RPLルーティングドメイン内でデータグラムを配信するための新しいIPv6ルーティングヘッダータイプを指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6554.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6554で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Overview ........................................................3
3. Format of the RPL Routing Header ................................6
4. RPL Router Behavior .............................................8
4.1. Generating Source Routing Headers ..........................8
4.2. Processing Source Routing Headers ..........................9
5. Security Considerations ........................................11
5.1. Source Routing Attacks ....................................11
5.2. ICMPv6 Attacks ............................................12
6. IANA Considerations ............................................12
7. Acknowledgements ...............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
The Routing Protocol for Low-Power and Lossy Networks (RPL) is a distance vector IPv6 routing protocol designed for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are typically constrained in resources (limited communication data rate, processing power, energy capacity, memory). In particular, some LLN configurations may utilize LLN routers where memory constraints limit nodes to maintaining only a small number of default routes and no other destinations. However, it may be necessary to utilize such memory-constrained routers to forward datagrams and maintain reachability to destinations within the LLN.
低電力および損失ネットワーク（RPL）のルーティングプロトコルは、低電力および損失ネットワーク（LLNS）[RFC6550]向けに設計された距離ベクトルIPv6ルーティングプロトコルです。このようなネットワークは通常、リソースに制約されています（制限された通信データレート、処理能力、エネルギー容量、メモリ）。特に、一部のLLN構成では、メモリの制約が少数のデフォルトルートのみを維持し、その他の宛先は維持することにノードを制限するLLNルーターを利用する場合があります。ただし、このようなメモリ制約のあるルーターを利用して、データグラムを転送し、LLN内の目的地への到達可能性を維持する必要がある場合があります。
To utilize paths that include memory-constrained routers, RPL relies on source routing. In one deployment model of RPL, more-capable routers collect routing information and form paths to arbitrary destinations within a RPL routing domain. However, a source routing mechanism supported by IPv6 is needed to deliver datagrams.
メモリが制約したルーターを含むパスを利用するために、RPLはソースルーティングに依存しています。RPLの1つの展開モデルでは、より対応可能なルーターがルーティング情報を収集し、RPLルーティングドメイン内の任意の宛先へのパスを形成します。ただし、データグラムを配信するには、IPv6によってサポートされるソースルーティングメカニズムが必要です。
This document specifies the Source Routing Header (SRH) for use strictly between RPL routers in the same RPL routing domain. A RPL routing domain is a collection of RPL routers under the control of a single administration. The boundaries of routing domains are defined by network management by setting some links to be exterior, or inter-domain, links.
このドキュメントは、同じRPLルーティングドメインのRPLルーター間で厳密に使用するためのソースルーティングヘッダー（SRH）を指定します。RPLルーティングドメインは、単一の投与の制御下にあるRPLルーターのコレクションです。ルーティングドメインの境界は、いくつかのリンクを外装またはドメイン間リンクに設定することにより、ネットワーク管理によって定義されます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The format of the SRH draws from that of the Type 0 Routing header (RH0) [RFC2460]. However, the SRH introduces mechanisms to compact the source route entries when all entries share the same prefix with the IPv6 Destination Address of a packet carrying an SRH, a typical scenario in LLNs using source routing. The compaction mechanism reduces consumption of scarce resources such as channel capacity.
SRHの形式は、タイプ0ルーティングヘッダー（RH0）[RFC2460]の形式から引き出されます。ただし、SRHは、ソースルーティングを使用したLLNの典型的なシナリオであるSRHを運ぶパケットのIPv6宛先アドレスと同じプレフィックスをすべての接頭辞を共有したときに、ソースルートエントリをコンパクトするメカニズムを導入します。圧縮メカニズムは、チャネル容量などの希少な資源の消費を削減します。
The SRH also differs from RH0 in the processing rules to alleviate security concerns that led to the deprecation of RH0 [RFC5095]. First, RPL routers implement a strict source route policy where each and every IPv6 hop between the source and destination of the source route is specified within the SRH. Note that the source route may be a subset of the path between the actual source and destination and is discussed further below. Second, an SRH is only used between RPL routers within a RPL routing domain. RPL Border Routers, responsible for connecting other RPL routing domains and IP domains that use other routing protocols, do not allow datagrams already carrying an SRH header to enter or exit a RPL routing domain. Third, a RPL router drops datagrams that include multiple addresses assigned to any interfaces on that router to avoid forwarding loops.
また、SRHは、RH0 [RFC5095]の非難につながったセキュリティの懸念を軽減するために、処理ルールのRH0とは異なります。まず、RPLルーターは、ソースルートのソースと宛先の間のすべてのIPv6ホップがSRH内で指定される厳格なソースルートポリシーを実装します。ソースルートは、実際のソースと宛先の間のパスのサブセットであり、以下でさらに説明することに注意してください。第二に、SRHはRPLルーティングドメイン内のRPLルーター間でのみ使用されます。他のルーティングプロトコルを使用する他のRPLルーティングドメインおよびIPドメインを接続するRPL Border Routersは、既にSRHヘッダーを運ぶデータグラムがRPLルーティングドメインを入力または終了することを許可しません。第三に、RPLルーターは、ループを転送しないように、そのルーターの任意のインターフェイスに割り当てられた複数のアドレスを含むデータグラムをドロップします。
There are two cases that determine how to include an SRH when a RPL router requires the use of an SRH to deliver a datagram to its destination.
RPLルーターがSRHを使用してデータグラムを宛先に配信する必要がある場合にSRHを含める方法を決定する2つのケースがあります。
1. If the SRH specifies the complete path from source to destination, the router places the SRH directly in the datagram itself.
1. SRHがソースから宛先への完全なパスを指定する場合、ルーターはSRHをデータグラム自体に直接配置します。
2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram.
2. SRHがソースから宛先までのパスのサブセットのみを指定する場合、ルーターはIPv6-in-IPV6トンネリング[RFC2473]を使用し、SRHを外側のIPv6ヘッダーに配置します。トンネリングの使用により、データグラムが変更されずに配信され、ICMPエラーが元のデータグラムのソースではなくSRHのソースに戻ることが保証されます。
In a RPL network, Case 1 occurs when both source and destination are within a RPL routing domain and a single SRH is used to specify the entire path from source to destination, as shown in the following figure:
RPLネットワークでは、ソースと宛先の両方がRPLルーティングドメイン内にある場合にケース1が発生し、次の図に示すように、ソースから宛先へのパス全体を指定するために単一のSRHが使用されます。
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
RPL Routing Domain
In the above scenario, datagrams traveling from source, S, to destination, D, have the following packet structure:
上記のシナリオでは、Source、S、S、Destination D、D、次のパケット構造を持っているデータグラムが次のとおりです。
+--------+---------+-------------//-+
| IPv6 | Source | IPv6 |
| Header | Routing | Payload |
| | Header | |
+--------+---------+-------------//-+
S's address is carried in the IPv6 header's Source Address field.
Sのアドレスは、IPv6ヘッダーのソースアドレスフィールドに掲載されています。
D's address is carried in the last entry of the SRH for all but the last hop, when D's address is carried in the IPv6 header's Destination Address field of the packet carrying the SRH.
Dのアドレスは、DのアドレスがSRHを運ぶパケットのIPv6ヘッダーの宛先アドレスフィールドに掲載されている場合、最後のホップを除くすべてのすべてのSRHの最後のエントリで運ばれます。
In a RPL network, Case 2 occurs for all datagrams that have a source and/or destination outside the RPL routing domain, as shown in the following diagram:
RPLネットワークでは、次の図に示すように、RPLルーティングドメインの外側にソースおよび/または宛先を持つすべてのデータグラムに対してケース2が発生します。
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) ------------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
In the scenarios above, R may indicate a RPL Border Router (when connecting to other routing domains) or a RPL Router (when connecting to hosts). The datagrams have the following structure when traveling within the RPL routing domain:
上記のシナリオでは、RはRPLボーダールーター（他のルーティングドメインに接続するとき）またはRPLルーター（ホストに接続するとき）を示す場合があります。データグラムには、RPLルーティングドメイン内を移動するときに次の構造があります。
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
Note that the outer header (including the SRH) is added and removed by the RPL router.
外側ヘッダー（SRHを含む）がRPLルーターによって追加および削除されることに注意してください。
Case 2 also occurs whenever a RPL router needs to insert a source route when forwarding a datagram. One such use case with RPL is to have all RPL traffic flow through a Border Router and have the Border Router use source routes to deliver datagrams to their final destination. When including the SRH using tunneled mode, the Border Router would encapsulate the received datagram unmodified using IPv6- in-IPv6 and include an SRH in the outer IPv6 header.
ケース2は、RPLルーターがデータグラムを転送するときにソースルートを挿入する必要がある場合でも発生します。RPLのそのようなユースケースの1つは、すべてのRPLトラフィックフローをボーダールーターに通し、ボーダールーターを使用してソースルートを使用してデータグラムを最終目的地に配信することです。トンネルモードを使用してSRHを含めると、ボーダールーターは、IPv6-in-IPv6を使用して未修飾化のないデータグラムをカプセル化し、外側のIPv6ヘッダーにSRHを含めます。
+-----------------+
| |
| (S) -------\ |
| \ |
| (LBR)
| / |
| (D) <------/ |
| |
+-----------------+
RPL Routing Domain
In the above scenario, datagrams travel from S to D through the Low-Power and Lossy Network Border Router (LBR). Between S and the LBR, the datagrams are routed using the DAG built by the RPL and do not contain an SRH. The LBR encapsulates received datagrams unmodified using IPv6-in-IPv6 and the SRH is included in the outer IPv6 header.
上記のシナリオでは、データグラムはSからD、Dow PowerおよびLosy Network Border Router（LBR）を通過します。SとLBRの間で、データグラムはRPLによって構築されたDAGを使用してルーティングされ、SRHは含まれていません。LBRは、IPv6-in-IPv6を使用して未修飾のデータグラムをカプセル化し、SRHは外側のIPv6ヘッダーに含まれています。
The Source Routing Header has the following format:
ソースルーティングヘッダーには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv6 Next Header field [RFC2460].
次のヘッダー8ビットセレクター。ルーティングヘッダーの直後のヘッダーのタイプを識別します。IPv6 Next Headerフィールド[RFC2460]と同じ値を使用します。
Hdr Ext Len 8-bit unsigned integer. Length of the Routing header in 8-octet units, not including the first 8 octets. Note that when Addresses[1..n] are compressed (i.e., value of CmprI or CmprE is not 0), Hdr Ext Len does not equal twice the number of Addresses.
HDR ext len 8ビット符号なし整数。最初の8オクテットを含まない8オクテット単位のルーティングヘッダーの長さ。アドレスが圧縮されている場合（つまり、CMPRIまたはCMPREの値は0ではない）、HDR ext Lenはアドレスの数の2倍に等しくないことに注意してください。
Routing Type 8-bit selector. Identifies the particular Routing header variant. An SRH should set the Routing Type to 3.
ルーティングタイプ8ビットセレクター。特定のルーティングヘッダーバリアントを識別します。SRHはルーティングタイプを3に設定する必要があります。
Segments Left 8-bit unsigned integer. Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. The originator of an SRH sets this field to n, the number of addresses contained in Addresses[1..n].
セグメントは8ビットの署名のない整数を残しました。残りのルートセグメントの数、つまり、最終目的地に到達する前にまだ訪問されている明示的にリストされている中間ノードの数。SRHの創始者は、このフィールドをnに設定します。これは、アドレス[1..n]に含まれるアドレスの数です。
CmprI 4-bit unsigned integer. Number of prefix octets from each segment, except than the last segment, (i.e., segments 1 through n-1) that are elided. For example, an SRH carrying full IPv6 addresses in Addresses[1..n-1] sets CmprI to 0.
CMPRI 4ビット符号なし整数。排除される最後のセグメント（つまり、セグメント1からN-1）を除く、各セグメントからの接頭辞オクテットの数。たとえば、アドレス[1..N-1]に完全なIPv6アドレスを運ぶSRHは、CMPRIを0に設定します。
CmprE 4-bit unsigned integer. Number of prefix octets from the last segment (i.e., segment n) that are elided. For example, an SRH carrying a full IPv6 address in Addresses[n] sets CmprE to 0.
CMPRE 4ビット符号なし整数。排除される最後のセグメント（つまり、セグメントN）からのプレフィックスオクテットの数。たとえば、アドレス[n]に完全なIPv6アドレスを運ぶSRHは、CMPREを0に設定します。
Pad 4-bit unsigned integer. Number of octets that are used for padding after Address[n] at the end of the SRH.
パッド4ビットの符号なし整数。SRHの終わりに住所[n]の後にパディングに使用されるオクテットの数。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約されたこのフィールドは未使用です。送信者はゼロに初期化する必要があり、受信機は無視する必要があります。
Address[1..n] Vector of addresses, numbered 1 to n. Each vector element in [1..n-1] has size (16 - CmprI) and element [n] has size (16-CmprE). The originator of an SRH places the next (first) hop's IPv6 address in the IPv6 header's IPv6 Destination Address and the second hop's IPv6 address as the first address in Address[1..n] (i.e., Address[1]).
アドレス[1..n]アドレスのベクトル、番号1からn。[1..N-1]の各ベクトル要素にはサイズ（16-CMPRI）、要素[n]のサイズ（16-cmpre）があります。SRHのオリジネーターは、次の（最初の）ホップのIPv6アドレスをIPv6ヘッダーのIPv6宛先アドレスに配置し、2番目のホップのIPv6アドレスをアドレスの最初のアドレス[1..N]（つまり、アドレス[1]）の最初のアドレスとして配置します。
The SRH shares the same basic format as the Type 0 Routing header [RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and Pad fields are set to 0 and the only difference between the SRH and Type 0 encodings is the value of the Routing Type field.
SRHは、タイプ0ルーティングヘッダー[RFC2460]と同じ基本形式を共有します。完全なIPv6アドレスを運ぶ場合、CMPRI、CMPRE、およびPADフィールドは0に設定されており、SRHとタイプ0のエンコーディングの唯一の違いはルーティング型フィールドの値です。
A common network configuration for a RPL routing domain is that all routers within a RPL routing domain share a common prefix. The SRH introduces the CmprI, CmprE, and Pad fields to allow compaction of the Address[1..n] vector when all entries share the same prefix as
RPLルーティングドメインの共通ネットワーク構成は、RPLルーティングドメイン内のすべてのルーターが共通のプレフィックスを共有することです。SRHは、すべてのエントリが同じプレフィックスを共有している場合、アドレス[1..n]ベクトルを圧縮できるように、CMPRI、CMPRE、およびPADフィールドを導入します。
the IPv6 Destination Address field of the packet carrying the SRH. The CmprI and CmprE fields indicate the number of prefix octets that are shared with the IPv6 Destination Address of the packet carrying the SRH. The shared prefix octets are not carried within the Routing header and each entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n] has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there may exist unused octets between the last entry, Address[n], and the end of the Routing header. The Pad field indicates the number of unused octets that are used for padding. Note that when CmprI and CmprE are both 0, Pad MUST carry a value of 0.
SRHを運ぶパケットのIPv6宛先アドレスフィールド。CMPRIおよびCMPREフィールドは、SRHを運ぶパケットのIPv6宛先アドレスと共有されるプレフィックスオクテットの数を示しています。共有プレフィックスのオクテットはルーティングヘッダー内には携帯されておらず、アドレス[1..n -1]の各エントリにはサイズ（16 -cmpri）オクテットがあり、アドレス[n]のサイズ（16 -cmpre）オクテットがあります。CMPRIまたはCMPREが非ゼロの場合、最後のエントリ、アドレス[n]、およびルーティングヘッダーの終了の間に未使用のオクテットが存在する可能性があります。パッドフィールドは、パディングに使用される未使用のオクテットの数を示します。CMPRIとCMPREの両方が0の場合、PADは0の値を持つ必要があることに注意してください。
The SRH MUST NOT specify a path that visits a node more than once. When generating an SRH, the source may not know the mapping between IPv6 addresses and nodes. Minimally, the source MUST ensure that IPv6 addresses do not appear more than once and the IPv6 Source and Destination addresses of the encapsulating datagram do not appear in the SRH.
SRHは、ノードを複数回訪問するパスを指定してはなりません。SRHを生成するとき、ソースはIPv6アドレスとノードの間のマッピングを知らない場合があります。最終的に、ソースは、IPv6アドレスが複数以上表示されないことを確認する必要があり、カプセル化データグラムのIPv6ソースと宛先アドレスがSRHに表示されないことを確認する必要があります。
Multicast addresses MUST NOT appear in an SRH or in the IPv6 Destination Address field of a datagram carrying an SRH.
マルチキャストアドレスは、SRHまたはSRHを運ぶデータグラムのIPv6宛先アドレスフィールドに表示されてはなりません。
To deliver an IPv6 datagram to its destination, a router may need to generate a new SRH and specify a strict source route. When the router is the source of the original packet and the destination is known to be within the same RPL routing domain, the router SHOULD include the SRH directly within the original packet. Otherwise, the router MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the SRH in the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by an SRH are sent back to the router that generated the SRH.
IPv6データグラムを宛先に配信するには、ルーターが新しいSRHを生成し、厳密なソースルートを指定する必要がある場合があります。ルーターが元のパケットのソースであり、宛先が同じRPLルーティングドメイン内にあることが知られている場合、ルーターには元のパケット内にSRHを直接含める必要があります。それ以外の場合、ルーターはIPv6-in-IPV6トンネリング[RFC2473]を使用し、SRHをトンネルヘッダーに配置する必要があります。IPv6-in-IPV6トンネリングを使用すると、配信されたデータグラムが変更されていないままであり、SRHによって生成されたICMPV6エラーがSRHを生成したルーターに送り返されます。
When using IPv6-in-IPv6 tunneling, in order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to less than the original datagram's IPv6 Hop Limit value upon forwarding. In the case that the source route is longer than the original datagram's IPv6 Hop Limit, only the initial hops (determined by the original datagram's IPv6 Hop Limit) should be included in the SRH. If the RPL router is not the source of the original datagram, the original datagram's IPv6 Hop Limit field is decremented before generating the SRH. After generating the SRH, the RPL router decrements the original datagram's IPv6 Hop Limit value by the SRH Segments Left value. Processing the SRH Segments
IPv6-in-IPV6トンネリングを使用する場合、元のデータグラムのIPv6ホップ制限値を尊重するために、SRHを生成するRPLルーターは、フォワーディング時に元のデータグラムのIPv6ホップ制限値よりも少ないセグメントを設定する必要があります。ソースルートが元のDatagramのIPv6ホップ制限よりも長い場合、初期ホップ（元のDatagramのIPv6ホップ制限で決定）のみをSRHに含める必要があります。RPLルーターが元のデータグラムのソースではない場合、SRHを生成する前に、元のデータグラムのIPv6ホップ制限フィールドが減少します。SRHを生成した後、RPLルーターは、SRHセグメントの残された値によって元のDatagramのIPv6ホップ制限値を減少させます。SRHセグメントの処理
Left and original datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time Exceeded errors occur as would be expected on more traditional IPv6 networks that forward datagrams without tunneling.
このようにして、左および元のDatagramのIPv6ホップ制限フィールドは、トンネルなしでデータグラムを転送する従来のIPv6ネットワークで予想されるように、ICMPV6時間を超えるエラーを超えることを保証します。
To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion (i.e., at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path length for a given RPL network. To take advantage of this, however, the communicating endpoints need to be aware of the MTU along the path (i.e., through Path MTU Discovery). Unfortunately, the larger MTU size may not be available on all links (e.g., 1280 octets on IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) links). However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU, so performance degradation through fragmentation would be limited.
断片化を回避するには、ヘッダーの拡張を可能にするMTUサイズ（つまり、少なくとも1280 40（外側IPヘッダー）SRH_MAX_SIZE）を使用することが望ましいです。ここで、SRH_MAX_SIZEは特定のRPLネットワークの最大パス長です。ただし、これを活用するには、通信エンドポイントは、パスに沿ったMTUを認識する必要があります（つまり、PATH MTU発見を介して）。残念ながら、すべてのリンクでより大きなMTUサイズは使用できない場合があります（たとえば、IPv6の低電力ワイヤレスパーソナルエリアネットワーク（6lowpan）リンクの1280オクテット）。ただし、これらのタイプのネットワークのトラフィックの多くは、MTUよりもはるかに小さなメッセージで構成されているため、断片化によるパフォーマンスの低下は制限されると予想されます。
As specified in [RFC2460], a routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. In that node, dispatching on the Next Header field of the immediately preceding header causes the Routing header module to be invoked.
[RFC2460]で指定されているように、ルーティングヘッダーは、IPv6ヘッダーの宛先アドレスフィールドで識別されたノードに到達するまで調べたり処理されたりしません。そのノードでは、直前のヘッダーの次のヘッダーフィールドにディスパッチすると、ルーティングヘッダーモジュールが呼び出されます。
The function of the SRH is intended to be very similar to the Type 0 Routing header defined in [RFC2460]. After the routing header has been processed and the IPv6 datagram resubmitted to the IPv6 module for processing, the IPv6 Destination Address contains the next hop's address. When forwarding an IPv6 datagram that contains an SRH with a non-zero Segments Left value, if the IPv6 Destination Address is not on-link, a router MUST drop the datagram and SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to 7 to the packet's Source Address. This ICMPv6 Code indicates that the IPv6 Destination Address is not on-link and the router cannot satisfy the strict source route requirement. When generating ICMPv6 error messages, the rules in Section 2.4 of [RFC4443] MUST be observed.
SRHの機能は、[RFC2460]で定義されているタイプ0ルーティングヘッダーと非常によく似ていることを目的としています。ルーティングヘッダーが処理され、IPv6データグラムが処理のためにIPv6モジュールに再提出された後、IPv6宛先アドレスには次のホップのアドレスが含まれています。ゼロ以外のセグメントの残り値を持つSRHを含むIPv6データグラムを転送する場合、IPv6宛先アドレスがオンリンクでない場合、ルーターはデータグラムをドロップする必要があり、ICMP66のICMP宛先が到達不能（ICMPV6タイプ1）メッセージを送信する必要があります。パケットのソースアドレスに7に設定されています。このICMPV6コードは、IPv6宛先アドレスがオンリンクではなく、ルーターが厳密なソースルート要件を満たすことができないことを示しています。ICMPV6エラーメッセージを生成する場合、[RFC4443]のセクション2.4のルールを観察する必要があります。
To detect loops in the SRH, a router MUST determine if the SRH includes multiple addresses assigned to any interface on that router. If such addresses appear more than once and are separated by at least one address not assigned to that router, the router MUST drop the packet and SHOULD send an ICMP Parameter Problem, Code 0, to the Source Address. While this loop check does add significant per-packet processing overhead, it is required to mitigate bandwidth exhaustion attacks that led to the deprecation of RH0 [RFC5095].
SRHのループを検出するには、ルーターがSRHにそのルーターの任意のインターフェイスに割り当てられた複数のアドレスを含めるかどうかを判断する必要があります。そのようなアドレスが複数回表示され、そのルーターに割り当てられていない少なくとも1つのアドレスによって分離されている場合、ルーターはパケットをドロップする必要があり、ICMPパラメーター問題、コード0をソースアドレスに送信する必要があります。このループチェックは、パケットごとの重要な処理オーバーヘッドを追加しますが、RH0 [RFC5095]の非推奨につながる帯域幅の消耗攻撃を緩和する必要があります。
The following describes the algorithm performed when processing an SRH:
以下は、SRHを処理するときに実行されるアルゴリズムを説明しています。
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else {
compute n, the number of addresses in the Routing header, by
n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1
compute i, the index of the next address to be visited in the address vector, by subtracting Segments Left from n
nから残されたセグメントを差し引くことにより、アドレスベクトルにアクセスする次のアドレスのインデックスを計算します
if Address[i] or the IPv6 Destination Address is multicast {
discard the packet
}
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
send an ICMP Parameter Problem (Code 0) and discard the
packet
}
else {
swap the IPv6 Destination Address and Address[i]
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
RPL routers are responsible for ensuring that an SRH is only used between RPL routers:
RPLルーターは、SRHがRPLルーター間でのみ使用されることを保証する責任があります。
1. For datagrams destined to a RPL router, the router processes the packet in the usual way. For instance, if the SRH was included using tunneled mode and the RPL router serves as the tunnel endpoint, the router removes the outer IPv6 header, at the same time removing the SRH as well.
1. RPLルーターに導かれるデータグラムの場合、ルーターは通常の方法でパケットを処理します。たとえば、SRHがトンネルモードを使用して含まれ、RPLルーターがトンネルエンドポイントとして機能する場合、ルーターは外側のIPv6ヘッダーを削除し、同時にSRHも削除します。
2. Datagrams destined elsewhere within the same RPL routing domain are forwarded to the correct interface.
2. 同じRPLルーティングドメイン内の他の場所で運命づけられているデータグラムは、正しいインターフェイスに転送されます。
3. Datagrams destined to nodes outside the RPL routing domain are dropped if the outermost IPv6 header contains an SRH not generated by the RPL router forwarding the datagram.
3. RPLルーティングドメインの外側のノードに向けられたデータグラムは、Datagramを転送するRPLルーターによって生成されていないSRHが含まれている場合に、RPLルーティングドメインの外側のノードに向かって削除されます。
The RPL message security mechanisms defined in [RFC6550] do not apply to the RPL Source Route Header. This specification does not provide any confidentiality, integrity, or authenticity mechanisms to protect the SRH.
[RFC6550]で定義されているRPLメッセージセキュリティメカニズムは、RPLソースルートヘッダーには適用されません。この仕様は、SRHを保護するための機密性、完全性、または信頼性メカニズムを提供しません。
[RFC5095] deprecates the Type 0 Routing header due to a number of significant attacks that are referenced in that document. Such attacks include bypassing filtering devices, reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.
[RFC5095]は、そのドキュメントで参照されている多くの重要な攻撃のために、タイプ0ルーティングヘッダーを非難します。このような攻撃には、フィルタリングデバイスのバイパス、到達不可能なインターネットシステムへの到達、ネットワークトポロジの発見、帯域幅の疲労、およびAnycastの敗北が含まれます。
Because this document specifies that the SRH is only for use within a RPL routing domain, such attacks cannot be mounted from outside a RPL routing domain. As specified in this document, RPL routers MUST drop datagrams entering or exiting a RPL routing domain that contain an SRH in the IPv6 Extension headers.
このドキュメントは、SRHがRPLルーティングドメイン内でのみ使用するためのものであることを指定しているため、そのような攻撃はRPLルーティングドメインの外部から取り付けることはできません。このドキュメントで指定されているように、RPLルーターは、IPv6拡張ヘッダーにSRHを含むRPLルーティングドメインを入力または終了するデータグラムをドロップする必要があります。
Such attacks, however, can be mounted from within a RPL routing domain. To mitigate bandwidth exhaustion attacks, this specification requires RPL routers to check for loops in the SRH and drop datagrams that contain such loops. Attacks that include bypassing filtering devices and reaching otherwise unreachable Internet systems are not as relevant in mesh networks since the topologies are, by their very nature, highly dynamic. The RPL routing protocol is designed to provide reachability to all devices within a RPL routing domain and may utilize routes that traverse any number of devices in any order.
ただし、このような攻撃は、RPLルーティングドメイン内から取り付けることができます。帯域幅の消耗攻撃を緩和するには、この仕様では、RPLループがSRHのループをチェックし、そのようなループを含むデータグラムをドロップする必要があります。フィルタリングデバイスのバイパスや到達不可能なインターネットシステムへの到達を含む攻撃は、トポロジーが非常にダイナミックであるため、メッシュネットワークにはそれほど関連性がありません。RPLルーティングプロトコルは、RPLルーティングドメイン内のすべてのデバイスに到達可能性を提供するように設計されており、任意の数のデバイスを任意の数のデバイスを横断するルートを使用する場合があります。
Even so, these attacks and others (e.g., defeating anycast and routing topology discovery) can occur within a RPL routing domain when using this specification.
それでも、これらの攻撃やその他（例えば、Anycastおよびルーティングトポロジの発見を打ち負かす）は、この仕様を使用する際にRPLルーティングドメイン内で発生する可能性があります。
The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing SRH in back-to-back datagrams. An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism.
ICMPV6エラーメッセージの生成は、バックツーバックデータグラムでエラーを引き起こすSRHを送信することにより、サービス拒否攻撃を試みるために使用できます。[RFC443]のセクション2.4に正確に従う実装は、ICMPV6レート制限メカニズムによって保護されます。
This document defines a new IPv6 Routing Type, the "RPL Source Route Header", and has been assigned number 3 by IANA.
このドキュメントでは、新しいIPv6ルーティングタイプ、「RPLソースルートヘッダー」を定義し、IANAによって3番目の番号が割り当てられています。
This document defines a new ICMPv6 Destination Unreachable Code, "Error in Source Routing Header", and has been assigned number 7 by IANA.
このドキュメントでは、新しいICMPV6宛先の到達不可能なコード「ソースルーティングヘッダーのエラー」を定義し、IANAによって7番を割り当てられています。
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal Thubert, Sean Turner, and Tim Winter for their comments and suggestions that helped shape this document.
著者は、Jari Arkko、Ralph Droms、Adrian Farrel、Stephen Farrell、Richard Kelsey、Suresh Krishnan、Erik Nordmark、Pascal Thubert、Sean Turner、Tim Winterに、この文書を形作るのに役立ったコメントと提案に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095] Eabley、J.、Savola、P。、およびG. Neville-Neil、「IPv6のタイプ0ルーティングヘッダーの非難」、RFC 5095、2007年12月。
[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, March 2012.
[RFC6550] Winter、T.、Ed。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR. Alexander、「RPL：IPv6 Routing Protocol for Low-Power and Losy Networks」、RFC 6550、2012年3月。
Authors' Addresses
著者のアドレス
Jonathan W. Hui Cisco Systems 170 West Tasman Drive San Jose, California 95134 USA
ジョナサン・W・フイ・シスコ・システム170ウェスト・タスマン・ドライブ・サンノゼ、カリフォルニア95134 USA
Phone: +408 424 1547
EMail: jonhui@cisco.com
JP. Vasseur Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。Vasseur Cisco Systems 11、Rue Camille Desmoulins Issy Les Moulineaux 92782 France
EMail: jpv@cisco.com
David E. Culler UC Berkeley 465 Soda Hall Berkeley, California 94720 USA
David E. Culler UC Berkeley 465 Soda Hall Berkeley、California 94720 USA
Phone: +510 643 7572
EMail: culler@cs.berkeley.edu
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave. Cupertino, California 95014 USA
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave. Cupertino、California 95014 USA
EMail: vishwas.manral@hp.com