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)
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.
低消費電力とロッシーネットワーク（LLNs）では、ルータ上のメモリの制約はほとんど、いくつかのルートで、維持するためにそれらを制限する可能性があります。いくつかの構成では、LLN内のノードにデータグラムを配信するためにこれらのメモリ制約ルータを使用する必要があります。低消費電力とロッシーネットワークのルーティングプロトコル（RPL）は、ほとんどを保存するために、いくつかの展開で使用、全てではないが、1（例えば、有向非巡回グラフ（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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の展開モデルでは、より多くの可能なルータは、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、すべてのエントリがSRH、ソースルーティングを使用してLLNsにおける典型的なシナリオを運ぶパケットの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境界ルータは、既に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インのIPv6トンネリング[RFC2473]を使用し、外側のIPv6ヘッダ内SRHを置きます。トンネリングの使用は、データグラムが修飾されていない配信されることを保証し、その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ネットワークにおいて、ケース1は、送信元と宛先の両方がRPLルーティングドメイン内にあり、単一SRHは、以下の図に示すように、ソースから宛先へのパス全体を指定するために使用されるときに発生します。
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
RPL Routing Domain
In the above scenario, datagrams traveling from source, S, to destination, D, have the following packet structure:
上記のシナリオでは、先に、ソースSから走行データグラム、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'sのアドレスはSRHを運ぶパケットのIPv6ヘッダの宛先アドレスフィールドに運ばれたときD'sのアドレスは、すべてが、最後のホップのための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ネットワークでは、ケース2は、以下の図に示すように、RPLルーティングドメイン外のソースおよび/または宛先を持つすべてのデータグラムのために発生します。
+-----------------+
| |
| (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.
RPLのルータはデータグラムを転送するときにソースルートを挿入する必要があるときにケース2にも発生します。 RPLを有するそのようなユースケースは、ボーダルータを介してすべてのRPLトラフィックフローを有し、その最終的な宛先にデータグラムを配信する境界ルータ利用ソース経路を有することです。トンネリングモードを使用してSRHを含む場合に、ボーダールータで、IPv6の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.
上記のシナリオでは、データグラムは、低電力およびロッシーネットワーク境界ルータ（LBR）を介してDにSから移動します。 SとLBRの間で、データグラムはRPLによって構築されたDAGを使用してルーティングされ、SRHを含んでいません。 LBRは、受信したデータグラムがIPv6イン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ビットセレクタ。直ちにルーティングヘッダの次ヘッダのタイプを識別する。 [RFC2460] IPv6の次のヘッダフィールドと同じ値を使用します。
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拡張レン8ビットの符号なし整数。最初の8つのオクテットを含まない8オクテット単位でルーティングヘッダの長さ。アドレスは[1..nの】圧縮されたときことに注意してください（すなわち、CmprI又はCmprEの値が0ではない）、HDR拡張レン、アドレスの数倍に等しくありません。
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ビットの符号なし整数。各セグメントから、省略されている最後のセグメント（N-1を介して、すなわち、セグメント1）より除いプレフィックスオクテットの数。例えば、アドレスに完全なIPv6アドレスを運ぶSRH [1..nの-1]は0にCmprIを設定します。
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）からプレフィックスオクテットの数。例えば、SRH [n]は0にCmprEを設定するアドレスで完全なIPv6アドレスを運びます。
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]).
nに1番のアドレスの[1..nの】ベクターに対処。 [1..nの-1]内の各ベクトル要素は、サイズ（16 - CmprI）を有し、要素[n]は（16-CmprE）サイズを有します。 SRHの発信元（すなわち、[1]アドレス）[1..nの】アドレスの最初のアドレスとしてIPv6ヘッダのIPv6宛先アドレスと第2のホップのIPv6アドレス内の次の（最初の）ホップのIPv6アドレスを置きます。
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、およびパッドフィールドは0に設定され、SRH及びタイプ0エンコーディングの間の唯一の違いは、ルーティングTypeフィールドの値です。
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 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.
RPLルーティングドメインのための一般的なネットワーク構成があるRPLルーティングドメインを共有内のすべてのルータが共通のプレフィックスいます。 SRHは、すべてのエントリがSRHを運ぶパケットのIPv6宛先アドレスフィールドと同じプレフィックスを共有する場合に、アドレス[1..nの]ベクトルの圧縮を可能にしCmprI、CmprE、およびパッドフィールドを紹介します。 CmprIとCmprEフィールドはSRHを運ぶパケットのIPv6宛先アドレスと共有されているプレフィックスオクテットの数を示します。共有プレフィックスオクテットは、ルーティングヘッダ内に運ばれ、アドレス内の各エントリ[1..nの-1]されていないサイズ（16 - CmprI）を有するオクテットと[n]をアドレスサイズ（16 - CmprE）を有するオクテット。 CmprI又はCmprEが非ゼロである場合、最後のエントリとの間の未使用オクテットが存在してもよい、[n]のアドレス、ルーティングヘッダの終わり。 Padフィールドは、パディングのために使用されている未使用のオクテットの数を示します。 CmprIとCmprEが共に0である場合、パッドは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インのIPv6トンネリング[RFC2473]を使用し、トンネルヘッダにSRHを配置しなければなりません。 IPv6のインの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のインのIPv6トンネリングを使用する場合、元のデータグラムのIPv6のホップ制限値を尊重するために、SRHを生成RPLルータは、転送時に元のデータグラムのIPv6ホップリミット値以下に左セグメントを設定しなければなりません。ソースルートが長く、元のデータグラムのIPv6ホップ制限を超えている場合には、（元のデータグラムのIPv6ホップ限界によって決定される）のみ初期ホップはSRHに含まれるべきです。 RPLのルータは、元のデータグラムの送信元でない場合は、元のデータグラムのIPv6ホップ制限フィールドは、SRHを生成する前に減算されます。 SRHを生成した後、RPLルータは、値を左SRHセグメントによって、元のデータグラムの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.
左とこのように元のデータグラムのIPv6ホップ制限フィールドは、ICMPv6の時間は、トンネリングなしでデータグラムを転送し、より伝統的なIPv6ネットワーク上で予想されるようにエラーが発生した超過することを保証します。
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.
断片化を回避するために、SRH_MAX_SIZEが所定RPLネットワークの最大経路長でヘッダ伸張（すなわち、少なくとも1280 + 40（外側IPヘッダ）+ SRH_MAX_SIZE）を可能にするMTUサイズを使用することが望ましいです。これを活用するために、しかし、通信エンドポイント（すなわち、パスMTU探索を介して）経路に沿ってMTUを認識する必要があります。残念ながら、より大きなMTUサイズは、すべてのリンク（例えば、IPv6の低電力無線パーソナルエリアネットワーク上の1280個のオクテット（6LoWPAN）リンク）上で利用できない場合があります。しかし、断片化によるパフォーマンスの低下は限定的になるように、これらのタイプのネットワーク上のトラフィックの多くは、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宛先アドレスは、次のホップのアドレスを含みます。 IPv6宛先アドレスがオンリンクである場合は、ゼロ以外のセグメント左値とSRHが含まれているIPv6データグラムを転送する場合、ルータはデータグラムをドロップしなければならないとのICMPv6で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
セグメント左= 0、N =（（（によって他{計算N、ルーティングヘッダ内のアドレスの数、{型がルーティングヘッダに次ヘッダフィールドによって識別され、パケットの次のヘッダを処理するように進む}場合HDR拡張レン* 8） - パッド - （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
左セグメントはnよりも大きい場合、{フィールドを左セグメントを指し、ICMPパラメータ問題、元アドレスにコード0、メッセージを送信し、パケットを破棄} {デクリメントセグメントは1だけ左他
compute i, the index of the next address to be visited in the address vector, by subtracting Segments Left from n
iを計算し、次のアドレスのインデックスは、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]
アドレス[I]またはIPv6宛先アドレスがマルチキャストである場合、アドレス[1..nの】2つの以上のエントリがローカルインタフェースに割り当てられ、ローカルインタフェースに割り当てられていない少なくとも1つのアドレスによって分離されている場合に他{パケットを破棄} { ICMPパラメータ問題（コード0）を送信し、他}パケットを破棄{[i]のIPv6宛先アドレスを交換し、アドレス
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
IPv6のホップリミットが1以下である場合{ICMP時間超過送信 - ソースアドレスに遷移メッセージに超過ホップリミット、パケットを破棄}他{1によってホップリミットをデクリメント
resubmit the packet to the IPv6 module for transmission to the new destination } } } }
}}}}新しい宛先への伝送のためのIPv6モジュールにパケットを再送信
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.
RPLルータ宛のデータグラムの1、ルータは通常の方法でパケットを処理します。 SRHは、トンネリングモードを使用して含まれていたとRPLルーターは、トンネルエンドポイントとして機能する場合、例えば、ルータは、同様SRHを除去すると同時に、外側のIPv6ヘッダを除去します。
2. Datagrams destined elsewhere within the same RPL routing domain are forwarded to the correct interface.
同じRPLルーティングドメイン内の他の場所宛て2データグラムが正しいインターフェイスに転送されます。
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.
最も外側のIPv6ヘッダがデータグラムを転送RPLルータによって生成されないSRHが含まれている場合RPLルーティングドメイン外ノード宛3データグラムは廃棄されます。
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ルーティングヘッダを非難します。このような攻撃は、フィルタリング・デバイスをバイパスそうでない場合は、到達不能インターネットシステム、ネットワークトポロジディスカバリ、帯域幅の枯渇、そして敗北エニーキャストに達しています。
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ルーティングドメイン内からマウントすることができます。帯域幅の枯渇攻撃を軽減するために、この仕様は、このようなループが含まれているSRHのループやドロップデータグラムをチェックするためにRPLルーターが必要です。トポロジは、その性質により、非常に動的であるため、フィルタ装置を迂回し、そうでなければ到達できないインターネットシステムに到達含む攻撃は、メッシュネットワークのような関係がありません。 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.
この仕様を使用する場合であってもそう、（例えば、エニーキャストルーティングトポロジディスカバリを破って）これらの攻撃などが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を送信することにより、サービス拒否攻撃を試みるために使用することができます。正しく[RFC4443]の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.
著者は、この文書を形作る助けた彼らのコメントや提案のためにヤリArkko、ラルフDroms、エードリアンファレル、スティーブン・ファレル、リチャード・ケルシー、スレシュクリシュナン、エリックNordmarkと、パスカルThubert、ショーン・ターナー、とティム・冬に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン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] Abley、J.、Savola、P.、およびG.ネビル・ニール、 "ルーティングヘッダ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]冬、T.、エド。、Thubert、P.、エド。、ブラント、A.、ホイ、J.、ケルシー、R.、リーバイス、P.、ピスター教授、K.、Struik、R.、Vasseur 、JP、およびR.アレクサンダー、 "RPL：低消費電力とロッシーネットワークのためのIPv6ルーティングプロトコル"、RFC 6550、2012月。
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
電話：+408 424 1547 Eメール：jonhui@cisco.com
JP. Vasseur Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。シスコシステムズVasseur 11、ルーカミーユ・デムーラン92782イシレムリノーフランス
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
David E. Culler UC Berkeley 465 Soda Hall Berkeley, California 94720 USA
デイビット・E・カラーUCバークレー校465ソーダホールバークレー、カリフォルニア94720 USA
Phone: +510 643 7572 EMail: culler@cs.berkeley.edu
電話：+510 643 7572 Eメール：culler@cs.berkeley.edu
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave. Cupertino, California 95014 USA
信仰Mnrlヒューレット・パッカード株式会社。 19111 Prunerijイチイ。クパチーノ、カリフォルニア州95014、彼
EMail: vishwas.manral@hp.com
メールアドレス：vishwas.manral@hp.com