Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6553 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 March 2012
The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
低消費電力とロッシーネットワークのルーティングプロトコル（RPL）データプレーンデータグラムにRPL情報を運ぶためのオプション
Abstract
抽象
The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information.
低消費電力と非可逆ネットワークのためのルーティングプロトコル（RPL）は迅速にルーティングトポロジ内の不整合を識別するためにデータプレーンデータグラム内のルーティング情報を含んでいます。この文書では、そのようなルーティング情報を含むようにRPLルータ間で使用するためのRPLオプションを記述する。
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/rfc6553.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6553で取得することができます。
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 Option ........................................3
4. RPL Router Behavior .............................................5
5. Security Considerations .........................................6
5.1. DAG Inconsistency Attacks ..................................6
5.2. Destination Advertisement Object (DAO)
Inconsistency Attacks ......................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
RPL is a distance vector IPv6 routing protocol designed for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are typically constrained in energy and/or channel capacity. To conserve precious resources, a routing protocol must generate control traffic sparingly. However, this is at odds with the need to quickly propagate any new routing information to resolve routing inconsistencies quickly.
RPLは、低電力およびロッシーネットワーク（LLNs）[RFC6550]のために設計された距離ベクトルのIPv6ルーティングプロトコルです。そのようなネットワークは、典型的には、エネルギーおよび/またはチャネル容量に制約されます。貴重な資源を節約するために、ルーティングプロトコルは、控えめに制御トラフィックを生成する必要があります。しかし、これはすぐにすぐにルーティング矛盾を解決するために、新しいルーティング情報を伝播させる必要性と対立しています。
To help minimize resource consumption, RPL uses a slow proactive process to construct and maintain a routing topology but a reactive and dynamic process to resolving routing inconsistencies. In the steady state, RPL maintains the routing topology using a low-rate beaconing process. However, when RPL detects inconsistencies that may prevent proper datagram delivery, RPL temporarily increases the beacon rate to quickly resolve those inconsistencies. This dynamic rate control operation is governed by the use of dynamic timers also referred to as "Trickle" timers and defined in [RFC6206]. In contrast to other routing protocols (e.g., OSPF [RFC2328]), RPL detects routing inconsistencies using data-path verification, by including routing information within the datagram itself. In doing so, repair mechanisms operate only as needed, allowing the control and data planes to operate on similar time scales. The main motivation for data-path verification in LLNs is that control-plane traffic should be carefully bounded with respect to the data traffic. Intuitively, there is no need to solve routing issues (which may be temporary) in the absence of data traffic.
リソースの消費を最小限に抑えるために、RPLは、ルーティング矛盾を解決するには、ルーティングトポロジが、反応性とダイナミックなプロセスを構築し、維持するために、ゆっくりと積極的なプロセスを使用しています。定常状態では、RPLは、低レートビーコンプロセスを使用してルーティングトポロジを維持します。 RPLは、適切なデータグラムの配信を防止することができる不整合を検出した場合しかし、RPLは一時すばやくそれらの矛盾を解決するために、ビーコン・レートを増加させます。この動的レート制御動作は、「トリクル」タイマーと呼ばれ、[RFC6206]で定義された動的タイマの使用によって支配されます。他のルーティングプロトコル（例えば、OSPF [RFC2328]）とは対照的に、RPLは、データグラム自体の内部ルーティング情報を含めることにより、データパスの検証を使用して、ルーティングの不整合を検出します。必要に応じて、そうすることで、修復機構は、コントロールプレーンとデータプレーンは、同様の時間スケールで動作することができ、のみ動作します。 LLNsにおけるデータパス検証のための主な動機は、制御プレーントラフィックを慎重にデータトラフィックに対して囲まなければならないということです。直感的には、データトラフィックが存在しない場合に（一時的でもよい）、ルーティングの問題を解決する必要はありません。
RPL constructs a Directed Acyclic Graph (DAG) that attempts to minimize path costs to the DAG root according to a set of metrics and Objective Functions. There are circumstances where loops may occur, and RPL is designed to use a data-path loop detection method. This is one of the known requirements of RPL, and other data-path usage might be defined in the future.
RPLは、メトリクスと目的関数のセットに従ってDAGルートへのパスコストを最小化しようとする有向非循環グラフ（DAG）を構成します。そこにループが発生すること状況であり、RPLは、データパスループ検出方法を使用するように設計されています。これは、RPLの既知の要件の一つであり、他のデータ・パスの利用は、将来的に定義される可能性があります。
To that end, this document defines a new IPv6 option, called the RPL Option, to be carried within the IPv6 Hop-by-Hop header. The RPL Option is only for use between RPL routers participating in the same RPL Instance.
そのため、この文書では、RPLオプションと呼ばれる新しいIPv6オプションは、IPv6のホップバイホップヘッダ内で実施することを定義します。 RPLオプションは、同じ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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The RPL Option provides a mechanism to include routing information with each datagram that a router forwards. When receiving datagrams that include routing information, RPL routers process the routing information to help maintain the routing topology.
RPLオプションは、各データグラムルータの転送とルーティング情報を含むように機構を提供します。ルーティング情報を含むデータグラムを受信した場合、RPLルータはルーティングトポロジを維持するためにルーティング情報を処理します。
Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router. This document also specifies the use of IPv6-in-IPv6 tunneling [RFC2473] when attaching a RPL option to a packet. Use of tunneling ensures that the original packet remains unmodified and that ICMP errors return to the RPL Option source rather than the source of the original packet.
パケットの配信パスに沿ってすべてのRPLルータは、RPLオプションを処理し、更新します。受信したパケットが既にRPLオプションが含まれていない場合は、RPLルータは、他のRPLルータに転送する前にRPLオプションを挿入する必要があります。パケットにRPLオプションを取り付ける場合は、このドキュメントでは、IPv6のインIPv6トンネリング[RFC2473]を使用することを指定します。トンネリングを使用すると、元のパケットがそのまま残り、そのICMPエラーはRPLオプションのソースではなく、元のパケットの送信元に戻ることを保証します。
The RPL Option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. This option has an alignment requirement of 2n. The option has the following format:
RPLオプションを直ちにIPv6ヘッダ以下、IPv6のホップバイホップオプションヘッダで運ばれます。このオプションは、2n個の整列要求があります。オプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RPL Option
図1：RPLオプション
Option Type: 0x63
オプションタイプ：は0x63
Opt Data Len: 8-bit field indicating the length of the option, in octets, excluding the Option Type and Opt Data Len fields.
オプトデータレン：オプションタイプとOPTデータレンフィールドを除くオクテット内のオプションの長さを示す8ビットのフィールド、、。
Down 'O': 1-bit flag as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
「O」ダウン：1ビットのフラグ[RFC6550]のセクション11.2で定義された通りです。処理は、[RFC6550]のセクション11.2で説明された規則に従わなければなりません。
Rank-Error 'R': 1-bit flag as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
ランクエラー「R」：[RFC6550]のセクション11.2で定義されるように1ビットのフラグ。処理は、[RFC6550]のセクション11.2で説明された規則に従わなければなりません。
Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
[RFC6550]のセクション11.2で定義されるように1ビットのフラグ「F」 - エラーを転送します。処理は、[RFC6550]のセクション11.2で説明された規則に従わなければなりません。
RPLInstanceID: 8-bit field as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
RPLInstanceID：8ビットのフィールド[RFC6550]のセクション11.2で定義された通りです。処理は、[RFC6550]のセクション11.2で説明された規則に従わなければなりません。
SenderRank: 16-bit field as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
SenderRank：16ビットのフィールドは、[RFC6550]のセクション11.2で定義された通りです。処理は、[RFC6550]のセクション11.2で説明された規則に従わなければなりません。
The two high order bits of the Option Type MUST be set to '01' and the third bit is equal to '1'. With these bits, according to [RFC2460], nodes that do not understand this option on a received packet MUST discard the packet. Also, according to [RFC2460], the values within the RPL Option are expected to change en route. The RPL Option Data Length is variable.
オプションタイプの2つの上位ビットが「01」に設定しなければならなくて、3番目のビットは「1」に等しいです。これらのビットでは、[RFC2460]によると、受信したパケットには、このオプションを理解していないノードがパケットを捨てなければなりません。また、[RFC2460]によれば、RPLオプション内の値が途中で変化することが予想されます。 RPLオプションのデータ長は可変です。
The action taken by using the RPL Option and the potential set of sub-TLVs carried within the RPL Option MUST be specified by the RFC of the protocol that uses that option. No sub-TLVs are defined in this document. A RPL device MUST skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after.
RPLオプション及びRPLオプション内で運ばサブのTLVの電位組を使用することによって実行されるアクションは、そのオプションを使用するプロトコルのRFCで指定されなければなりません。いいえサブのTLVは、このドキュメントで定義されていません。 RPLデバイスは認識されないサブTLVをスキップした後に現れる可能性のある追加のサブTLVを処理しようとしなければなりません。
Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([RFC6554]) and MAY include both. A datagram including a Source Routing Header (SRH) does not need to include a RPL Option since both the source and intermediate routers ensure that the SRH does not contain loops.
RPLルータ間で送信されるデータグラムは、RPLオプションまたはRPLソースルートヘッダ（[RFC6554]）を含まなければなりませんとの両方を含むことができます。ソースルーティングヘッダ（SRH）を含むデータグラムがソースと中間ルータの両方がSRHがループを含んでいないことを保証するのでRPLオプションを含める必要はありません。
When the router is the source of the original packet and the destination is known to be within the same RPL Instance, the router SHOULD include the RPL Option directly within the original packet. Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL Option in the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by a RPL Option are sent back to the router that generated the RPL Option.
ルータは、元のパケットのソースと宛先が同じRPLインスタンス内であることが知られている場合、ルータは、元のパケット内で直接RPLオプションを含めるべきです。そうでない場合は、ルータは、IPv6インのIPv6トンネリング[RFC2473]を使用し、トンネルヘッダにRPLオプションを配置しなければなりません。 IPv6のインのIPv6トンネリングを使用して送達されるデータグラムは、未修飾のままであり、RPLオプションによって生成されるICMPv6のエラーがRPLオプションを生成したルータに返送されることを保証します。
A RPL router chooses the next RPL router that should process the original packet as the tunnel exit-point. In some cases, the tunnel exit-point will be the final RPL router along a path towards the original packet's destination, and the original packet will only traverse a single tunnel. One example is when the final destination or the destination's attachment router is known to be within the same RPL Instance.
RPLルーターは、トンネル出口ポイントとして元のパケットを処理すべき次RPLルータを選択します。いくつかのケースでは、トンネル出口ポイントは、元のパケットの宛先に向かう経路に沿って最終的なRPLルータとなり、元のパケットは、単一のトンネルを通過します。一例では、最終的な宛先または宛先の取り付けルータが同じRPLインスタンス内であることが知られている場合です。
In other cases, the tunnel exit-point will not be the final RPL router along a path and the original packet may traverse multiple tunnels to reach the destination. One example is when a RPL router is simply forwarding a packet to one of its Destination-Oriented DAG (DODAG) parents. In this case, the RPL router sets the tunnel exit-point to a DODAG parent. When forwarding the original packet hop-by-hop, the RPL router only makes a determination on the next hop towards the destination.
他の場合には、トンネル出口ポイントは、パスと元のパケットに沿って、最終的なRPLルータが宛先に到達するために複数のトンネルを横断してもよいことはないであろう。 RPLルータは、単にその先指向DAG（DODAG）両親のいずれかにパケットを転送しているとき、一例です。この場合には、RPLルータはDODAG親にトンネル出口ポイントを設定します。元のパケットのホップバイホップを転送するとき、RPLルータは、宛先に向かう次ホップに判定を行います。
A RPL router receiving an IPv6-in-IPv6 packet destined to it processes the tunnel packet as described in Section 3 of [RFC2473]. Before IPv6 decapsulation, the RPL router MUST process the RPL Option, if one exists. After IPv6 decapsulation, if the router determines that it should forward the original packet to another RPL router, it MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to include the RPL Option. Fields within the RPL Option that do not change hop-by-hop MUST remain the same as those received from the prior tunnel.
[RFC2473]のセクション3に記載されているように、それ宛てのIPv6インのIPv6パケットを受信RPLルータがトンネルパケットを処理します。が存在する場合のIPv6カプセル化解除する前に、RPLルータは、RPLオプションを処理しなければなりません。ルータは、それが別のRPLルータに元のパケットを転送すべきであると判断した場合のIPv6デカプセル化した後、それはRPLオプションを含むようにIPv6のインのIPv6トンネリングを使用して再びパケットをカプセル化しなければなりません。ホップバイホップを変更しないRPLオプション内のフィールドは、先行トンネルから受信したものと同じままでなければなりません。
RPL routers are responsible for ensuring that a RPL Option is only used between RPL routers:
RPLルータはRPLオプションのみRPLルータ間で使用されることを保証する責任があります。
1. For datagrams destined to a RPL router, the router processes the packet in the usual way. For instance, if the RPL Option 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 RPL Option as well.
RPLルータ宛のデータグラムの1、ルータは通常の方法でパケットを処理します。例えば、RPLオプションがトンネリングモードを使用して含まれ、RPLルーターは、トンネルエンドポイントとして機能している場合、ルータは、同様RPLオプションを除去すると同時に、外側のIPv6ヘッダを除去します。
2. Datagrams destined elsewhere within the same RPL Instance are forwarded to the correct interface.
同じRPLインスタンス内の他の場所宛て2データグラムが正しいインターフェイスに転送されます。
3. Datagrams destined to nodes outside the RPL Instance are dropped if the outermost IPv6 header contains a RPL Option not generated by the RPL router forwarding the datagram.
最も外側のIPv6ヘッダがデータグラムを転送RPLルータによって生成されないRPLオプションが含まれている場合RPLインスタンス外部ノード宛3データグラムは廃棄されます。
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) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the maximum RPL Option header size 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.
断片化を回避するために、RPL_OPTION_MAX_SIZEが所定RPLネットワークの最大RPLオプションヘッダサイズでヘッダ伸張（すなわち、少なくとも1280 + 40（外側IPヘッダ）+ RPL_OPTION_MAX_SIZE）を可能にするMTUサイズを使用することが望ましいです。これを活用するために、しかし、通信エンドポイント（すなわち、パスMTU探索を介して）経路に沿ってMTUを認識する必要があります。残念ながら、より大きなMTUサイズは、すべてのリンク（例えば、IPv6の低電力無線パーソナルエリアネットワーク上の1280個のオクテット（6LoWPAN）リンク）上で利用できない場合があります。しかし、断片化によるパフォーマンスの低下は限定的になるように、これらのタイプのネットワーク上のトラフィックの多くは、MTUよりもはるかに小さいメッセージで構成されていることを期待されています。
The RPL Option assists RPL routers in detecting routing inconsistencies. The RPL message security mechanisms defined in [RFC6550] do not apply to the RPL Option.
RPLオプションは、ルーティング矛盾を検出するにはRPLルーターを支援します。 [RFC6550]で定義されたRPLメッセージセキュリティメカニズムは、RPLオプションには適用されません。
Using the Down 'O' flag and SenderRank field, an attacker can cause RPL routers to believe that a DAG inconsistency exists within the RPL Instance identified by the RPLInstanceID field. This attack would cause a RPL router to reset its DODAG Information Object (DIO) Trickle timer and begin transmitting DIO messages more frequently.
ダウン「O」フラグとSenderRankフィールドを使用して、攻撃者は、RPLルータがDAGの矛盾がRPLInstanceIDフィールドによって識別RPLインスタンス内に存在していることを信じることがあります。この攻撃は、RPLのルータがDODAG情報オブジェクト（DIO）トリクルタイマーをリセットし、より頻繁にDIOのメッセージの送信を開始する原因となります。
In order to avoid any unacceptable impact on network operations, an implementation MAY limit the rate of Trickle timer resets caused by receiving a RPL Option to no greater than MAX_RPL_OPTION_RANK_ERRORS per hour. A RECOMMENDED value for MAX_RPL_OPTION_RANK_ERRORS is 20.
ネットワーク運用上の任意の許容できない影響を回避するために、実装は、時間当たりMAX_RPL_OPTION_RANK_ERRORSより大きくないとRPLオプションを受信することによって引き起こされるトリクルタイマーリセットの速度を制限することができます。 MAX_RPL_OPTION_RANK_ERRORSの推奨値は20です。
In Storing mode, RPL routers maintain Downward routing state. Under normal operation, the RPL Option assists RPL routers in cleaning up stale Downward routing state by using the Forwarding-Error 'F' flag to indicate that a datagram could not be delivered by a child and is being sent back to try a different child. Using this flag, an attacker can cause a RPL router to discard Downward routing state.
モードを格納する際に、RPLルータが下方ルーティング状態を維持します。通常の動作では、RPLオプションは、データグラムが、子供によって送達することができませんでしたし、別の子を試して戻って送信されていることを示すために、フォワーディングエラー「F」フラグを使用して古い下向きルーティング状態をクリーンアップするにはRPLルーターを支援します。このフラグを使用すると、攻撃者は、RPLルータが下向きのルーティング状態を破棄することがあります。
In order to avoid any unacceptable impact on network operations, an implementation MAY limit the rate of discarding Downward routing state caused by receiving a RPL Option to no greater than MAX_RPL_OPTION_FORWARD_ERRORS per hour. A RECOMMENDED value for MAX_RPL_OPTION_FORWARD_ERRORS is 20.
ネットワーク運用上の任意の許容できない影響を回避するために、実装は、時間当たりMAX_RPL_OPTION_FORWARD_ERRORSより大きくないとRPLオプションを受信することによって引き起こされる下向きのルーティング状態を廃棄する速度を制限することができます。 MAX_RPL_OPTION_FORWARD_ERRORSの推奨値は20です。
In Non-Storing mode, only the Low-Power and Lossy Network Border Router (LBR) maintains Downward routing state. Because RPL routers do not maintain Downward routing state, the RPL Option cannot be used to mount such attacks.
非保存モードでは、唯一の低消費電力とロッシーネットワーク境界ルータ（LBR）は下向きのルーティング状態を維持しています。 RPLルータが下向きのルーティング状態を維持していないので、RPLオプションは、このような攻撃をマウントするために使用することはできません。
IANA has assigned a new value in the Destination Options and Hop-by-Hop Options registry. The value is as follows:
IANAは、宛先オプションとホップバイホップオプションのレジストリに新しい値を割り当てています。次のように値は次のとおりです。
Hex Value Binary Value
act chg rest Description Reference
--------- --- --- ------- ----------------- ----------
0x63 01 1 00011 RPL Option [RFC6553]
As specified in [RFC2460], the first two bits indicate that the IPv6 node MUST discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data may change en route. The remaining bits serve as the option type.
[RFC2460]で指定されるように、最初の2ビットは、オプションタイプを認識しない場合にIPv6ノードはパケットを破棄しなければならないことを示し、第3ビットは、オプションデータが途中で変更することができることを示しています。残りのビットは、オプションタイプとして働きます。
IANA has created a registry called RPL-option-TLV, for the sub-TLVs carried in the RPL Option header. New codes may be allocated only by IETF Review [RFC5226]. The type field is an 8-bit field whose value be between 0 and 255, inclusive.
IANAは、RPLオプションヘッダで運ばサブTLVのためのRPL-オプション-TLVと呼ばれるレジストリを作成しました。新しいコードは、IETFレビュー[RFC5226]によって割り当てられることができます。タイプフィールドは、その値が0〜255までの間で8ビットのフィールドです。
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen Farrell, Richard Kelsey, Suresh Krishnan, Vishwas Manral, Erik Nordmark, Pascal Thubert, Sean Turner, and Tim Winter, for their comments and suggestions that helped shape this document.
著者は、この文書を形作る助けた彼らのコメントや提案のために、ヤリArkko、ラルフDroms、エードリアンファレル、スティーブン・ファレル、リチャード・ケルシー、スレシュクリシュナン、Vishwas Manral、エリック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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6206]リーバイス、P.、Clausenの、T.、ホイ、J.、Gnawali、O.、及びJ.コ "トリクルアルゴリズム"、RFC 6206、2011年3月。
[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月。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012.
[RFC6554]ホイ、J.、Vasseur、JP。、Culler、D.、およびV. Manral、 "低消費電力と非可逆ネットワークのためのルーティングプロトコルを有するソースルートのIPv6ルーティングヘッダ（RPL）"、RFC 6554、 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
電話：+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