[要約] RFC 6553は、低消費電力および損失の多いネットワーク（LLN）のためのルーティングプロトコル（RPL）オプションであり、データプレーンのデータグラムでRPL情報を運ぶためのものです。その目的は、LLN内のノード間の効率的な通信を実現するために、RPLプロトコルの拡張として機能することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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 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の既知の要件の1つであり、他のデータパス使用量は将来定義される可能性があります。
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-in-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ビットフィールドLENフィールドをOPTします。
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」：[RFC6550]のセクション11.2で定義されている1ビットフラグ。処理は、[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].
rank-error '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].
フォワーディングエラー 'F'：[RFC6550]のセクション11.2で定義されている1ビットフラグ。処理は、[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：[RFC6550]のセクション11.2で定義されている8ビットフィールド。処理は、[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：[RFC6550]のセクション11.2で定義されている16ビットフィールド。処理は、[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-in-IPV6トンネリング[RFC2473]を使用し、RPLオプションをトンネルヘッダーに配置する必要があります。IPv6-in-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ルーターになり、元のパケットは単一のトンネルを通過するだけです。1つの例は、最終目的地または宛先のアタッチメントルーターが同じ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ルーターではなく、元のパケットが宛先に到達するために複数のトンネルを通過する場合があります。1つの例は、RPLルーターが単に宛先指向のDAG（DODAG）親の1つにパケットを転送している場合です。この場合、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
[RFC2473]のセクション3で説明されているように、ITに向けたIPv6-in-IPV6パケットを受信するRPLルーターは、トンネルパケットを処理します。IPv6脱カプセル化の前に、RPLルーターが存在する場合はRPLオプションを処理する必要があります。IPv6脱カプセル化後、ルーターが元のパケットを別のRPLルーターに転送する必要があると判断した場合、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.
RPLオプションを含めるトンネリング。ホップバイホップを変更しない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.
1. RPLルーターに導かれるデータグラムの場合、ルーターは通常の方法でパケットを処理します。たとえば、RPLオプションがトンネルモードを使用して含まれ、RPLルーターがトンネルエンドポイントとして機能する場合、ルーターは外側のIPv6ヘッダーを取り外し、同時にRPLオプションも削除します。
2. Datagrams destined elsewhere within the same RPL Instance are forwarded to the correct interface.
2. 同じRPLインスタンス内の他の場所で運命づけられているデータグラムは、正しいインターフェイスに転送されます。
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.
3. RPLインスタンスの外側のノードに向けられたデータグラムは、Datagramを転送するRPLルーターによって生成されないRPLオプションが含まれている場合、RPLインスタンスの外側のノードがドロップされます。
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.
断片化を回避するには、ヘッダー拡張を可能にするMTUサイズ（つまり、少なくとも1280（外側IPヘッダー）RPL_OPTION_MAX_SIZE）を使用することが望ましいです。ここで、RPL_OPTION_MAX_SIZEは、特定のRPLネットワークの最大RPLオプションヘッダーサイズです。ただし、これを活用するには、通信エンドポイントは、パスに沿ったMTUを認識する必要があります（つまり、PATH MTU発見を介して）。残念ながら、すべてのリンクでより大きなMTUサイズは使用できない場合があります（たとえば、IPv6の低電力ワイヤレスパーソナルエリアネットワーク（6lowpan）リンクの1280オクテット）。ただし、これらのタイプのネットワークのトラフィックの多くは、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.
down 'o'フラグとセンドランクフィールドを使用して、攻撃者はRPLルーターにRPLINSTANCEIDフィールドによって識別されたRPLインスタンス内にDAGの矛盾が存在すると信じることができます。この攻撃により、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.
ネットワーク操作への容認できない影響を回避するために、実装により、RPLオプションを1時間あたり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オプションはRPLルーターが転送エラー「F」フラグを使用して古い下方ルーティング状態をクリーンアップするのを支援し、データグラムを子供が配信できず、別の子供を試すために送り返されていることを示します。このフラグを使用して、攻撃者は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.
ネットワーク操作への容認できない影響を回避するために、実装により、RPLオプションをMAX_RPL_OPTION_FORWARD_ERRORSを1時間あたりに受け取ることにより、下向きのルーティング状態を破棄するレートが制限される場合があります。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-Option-TLVと呼ばれるレジストリを作成しました。新しいコードは、IETFレビュー[RFC5226]によってのみ割り当てられる場合があります。タイプフィールドは8ビットフィールドで、その値は0〜255の間で包括的です。
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.
著者は、Jari Arkko、Ralph Droms、Adrian Farrel、Stephen Farrell、Richard Kelsey、Suresh Krishnan、Vishwas Manral、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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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] 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月。
[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] Levis、P.、Clausen、T.、Hui、J.、Gnawali、O.、およびJ. Ko、「The Trickle Algorithm」、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] 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月。
[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] Hui、J.、Vasseur、JP。、Culler、D。、およびV. Manral、「低電力および損失ネットワーク（RPL）のルーティングプロトコルを備えたソースルートのIPv6ルーティングヘッダー」、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
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