[要約] RFC 8138は、6LoWPANルーティングヘッダーを使用したIPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）の仕様を定義しています。このRFCの目的は、6LoWPANネットワークでのIPv6通信を効率的に行うためのルーティングヘッダーの使用方法を提供することです。
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 8138 Cisco
Category: Standards Track C. Bormann
ISSN: 2070-1721 Uni Bremen TZI
L. Toutain
IMT Atlantique
R. Cragie
ARM
April 2017
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header
IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Routing Header
Abstract
概要
This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.
この仕様では、6LoWPANルートオーバートポロジで使用する新しいIPv6 over Low-Powerワイヤレスパーソナルエリアネットワーク（6LoWPAN）ディスパッチタイプが導入されています。これは、当初、低電力および損失ネットワーク（RPL）データパケット圧縮のルーティングプロトコルのニーズをカバーします（ RFC 6550）。この仕様では、このディスパッチタイプを使用して、RPLオプション（RFC 6553）情報と効率的なIP-in-IPテクニックであるルーティングヘッダータイプ3（RFC 6554）情報を圧縮する方法を定義し、より多くのアプリケーションに拡張できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8138.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8138で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Using the Page Dispatch . . . . . . . . . . . . . . . . . . . 7
3.1. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 7
3.2. Placement of 6LoRH Headers . . . . . . . . . . . . . . . 8
3.2.1. Relative to Non-6LoRH Headers . . . . . . . . . . . . 8
3.2.2. Relative to Other 6LoRH Headers . . . . . . . . . . . 8
4. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 9
4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 10
4.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 10
4.3. Compressing Addresses . . . . . . . . . . . . . . . . . . 11
4.3.1. Coalescence . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. DODAG Root Address Determination . . . . . . . . . . 12
5. The SRH-6LoRH Header . . . . . . . . . . . . . . . . . . . . 13
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. SRH-6LoRH General Operation . . . . . . . . . . . . . . . 14
5.2.1. Uncompressed SRH Operation . . . . . . . . . . . . . 14
5.2.2. 6LoRH-Compressed SRH Operation . . . . . . . . . . . 15
5.2.3. Inner LOWPAN_IPHC Compression . . . . . . . . . . . . 15
5.3. The Design Point of Popping Entries . . . . . . . . . . . 16
5.4. Compression Reference for SRH-6LoRH Header Entries . . . 17
5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 18
5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 19
6. The RPL Packet Information 6LoRH (RPI-6LoRH) . . . . . . . . 19
6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 21
6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 21
6.3. The Overall RPI-6LoRH Encoding . . . . . . . . . . . . . 21
7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 24
8. Management Considerations . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 27
10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 28
10.3. New Elective 6LoWPAN Routing Header Type Registry . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 31
A.1. Examples Compressing the RPI . . . . . . . . . . . . . . 31
A.2. Example of a Downward Packet in Non-Storing Mode . . . . 32
A.3. Example of SRH-6LoRH Life Cycle . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
The design of Low-Power and Lossy Networks (LLNs) is generally focused on saving energy, a very constrained resource in most cases. The other constraints, such as the memory capacity and the duty cycling of the LLN devices, derive from that primary concern. Energy is often available from primary batteries that are expected to last for years, or it is scavenged from the environment in very limited quantities. Any protocol that is intended for use in LLNs must be designed with the primary concern of saving energy as a strict requirement.
低電力および損失の多いネットワーク（LLN）の設計は、通常、ほとんどの場合非常に制約のあるリソースであるエネルギーの節約に焦点を当てています。メモリ容量やLLNデバイスのデューティサイクルなどの他の制約は、その主な懸念から派生しています。エネルギーは、何年も続くと予想される一次電池から利用できることがよくあります。または、非常に限られた量で環境から排出されます。 LLNでの使用を目的としたプロトコルは、厳密な要件としてエネルギー節約を主な関心事として設計する必要があります。
Controlling the amount of data transmission is one possible venue to save energy. In a number of LLN standards, the frame size is limited to much smaller values than the guaranteed IPv6 Maximum Transmission Unit (MTU) of 1280 bytes. In particular, an LLN that relies on the classical Physical Layer (PHY) of IEEE 802.15.4 [IEEE.802.15.4] is limited to 127 bytes per frame. The need to compress IPv6 packets over IEEE 802.15.4 led to the writing of "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC6282].
データ送信量の制御は、エネルギーを節約するための1つの可能な場です。多くのLLN標準では、フレームサイズは、保証されている1280バイトのIPv6最大伝送ユニット（MTU）よりもはるかに小さい値に制限されています。特に、IEEE 802.15.4 [IEEE.802.15.4]の従来の物理層（PHY）に依存するLLNは、フレームあたり127バイトに制限されています。 IEEE 802.15.4を介してIPv6パケットを圧縮する必要性から、「IEEE 802.15.4ベースのネットワークを介したIPv6データグラムの圧縮形式」[RFC6282]が作成されました。
Innovative route-over techniques have been and still are being developed for routing inside an LLN. Generally, such techniques require additional information in the packet to provide loop prevention and to indicate information such as flow identification, source routing information, etc.
LLN内のルーティングのために、革新的なルートオーバーテクニックが開発され続けています。一般に、このような技術では、ループ防止を提供し、フロー識別、ソースルーティング情報などの情報を示すために、パケットに追加情報が必要です。
For reasons such as security and the capability to send ICMPv6 errors (see "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" [RFC4443]) back to the source, an original packet must not be tampered with, and any information that must be inserted in or removed from an IPv6 packet must be placed in an extra IP-in-IP encapsulation.
セキュリティやICMPv6エラー（「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」[RFC4443]を参照）を送信元に戻す機能などの理由により、元のパケットが改ざんされてはなりません。 、およびIPv6パケットに挿入またはIPv6パケットから削除する必要がある情報は、追加のIP-in-IPカプセル化に配置する必要があります。
This is the case when the additional routing information is inserted by a router on the path of a packet, for instance, the root of a mesh, as opposed to the source node, with the Non-Storing mode of the "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550].
これは、「RPL：IPv6ルーティングの非保存モードで、ソースノードではなく、メッシュのルートなど、パケットのパス上のルーターによって追加のルーティング情報が挿入される場合です。低電力および損失の多いネットワークのためのプロトコル」[RFC6550]。
This is also the case when some routing information must be removed from a packet that flows outside the LLN.
これは、LLNの外部を流れるパケットから一部のルーティング情報を削除する必要がある場合にも当てはまります。
"When to use RFC 6553, RFC 6554 and IPv6-in-IPv6" [RPL-INFO] details different cases where IPv6 headers defined in the RPL Option for Carrying RPL Information in Data-Plane Datagrams [RFC6553], Header for Source Routes with RPL [RFC6554], and IPv6-in-IPv6 encapsulation, are inserted or removed from packets in LLN environments operating RPL.
「RFC 6553、RFC 6554およびIPv6-in-IPv6を使用する場合」[RPL-INFO]は、データプレーンデータグラム[RFC6553]でRPL情報を伝送するためのRPLオプションで定義されたIPv6ヘッダーが、 RPL [RFC6554]、およびIPv6-in-IPv6カプセル化は、RPLが動作するLLN環境でパケットに挿入またはパケットから削除されます。
When using RFC 6282 [RFC6282], the outer IP header of an IP-in-IP encapsulation may be compressed down to 2 octets in stateless compression and down to 3 octets in stateful compression when context information must be added.
RFC 6282 [RFC6282]を使用する場合、IP-in-IPカプセル化の外部IPヘッダーは、コンテキスト情報を追加する必要がある場合、ステートレス圧縮では2オクテットに、ステートフル圧縮では3オクテットに圧縮されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: LOWPAN_IPHC Base Encoding (RFC 6282)
図1：LOWPAN_IPHCベースエンコーディング（RFC 6282）
The stateless compression of an IPv6 address can only happen if the IPv6 address can de deduced from the Media Access Control (MAC) addresses, meaning that the IP endpoint is also the MAC-layer endpoint. This is usually not the case in a RPL network, which is generally a multi-hop route-over (i.e., operated at Layer 3) network. A better compression, which does not involve variable compressions depending on the hop in the mesh, can be achieved based on the fact that the outer encapsulation is usually between the source (or destination) of the inner packet and the root. Also, the inner IP header can only be compressed by RFC 6282 [RFC6282] if all the fields preceding it are also compressed. This specification makes the inner IP header the first header to be compressed by RFC 6282 [RFC6282], and it keeps the inner packet encoded the same way whether or not it is encapsulated, thus preserving existing implementations.
IPv6アドレスのステートレス圧縮は、IPv6アドレスがメディアアクセスコントロール（MAC）アドレスから推定できる場合にのみ発生します。つまり、IPエンドポイントはMACレイヤーエンドポイントでもあります。これは通常、RPLネットワークには当てはまりません。RPLネットワークは、通常、マルチホップルートオーバー（つまり、レイヤー3で動作）ネットワークです。メッシュ内のホップに応じた可変圧縮を含まないより良い圧縮は、外部カプセル化が通常内部パケットのソース（または宛先）とルートの間にあるという事実に基づいて達成できます。また、内部のIPヘッダーは、RFC 6282 [RFC6282]で圧縮できます。その前にあるすべてのフィールドも圧縮されている場合のみです。この仕様により、内部IPヘッダーがRFC 6282 [RFC6282]によって圧縮される最初のヘッダーになり、内部パケットがカプセル化されているかどうかにかかわらず同じ方法でエンコードされたままになるため、既存の実装が保持されます。
As an example, RPL [RFC6550] is designed to optimize the routing operations in constrained LLNs. As part of this optimization, RPL requires the addition of RPL Packet Information (RPI) in every packet, as defined in Section 11.2 of RFC 6550 [RFC6550].
例として、RPL [RFC6550]は、制約付きLLNでのルーティング操作を最適化するように設計されています。この最適化の一環として、RPLではRFC 6550 [RFC6550]のセクション11.2で定義されているように、すべてのパケットにRPLパケット情報（RPI）を追加する必要があります。
"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] specification indicates how the RPI can be placed in a RPL Option (RPL-OPT) that is placed in an IPv6 Hop-by-Hop header.
「データプレーンデータグラムでRPL情報を伝送するための低電力および損失の多いネットワーク（RPL）オプションのルーティングプロトコル」[RFC6553]仕様は、RPIをRPLオプション（RPL-OPT）に配置する方法を示しています。 IPv6ホップバイホップヘッダー。
This representation demands a total of 8 bytes, while, in most cases, the actual RPI payload requires only 19 bits. Since the Hop-by-Hop header must not flow outside of the RPL domain, it must be inserted in packets entering the domain and be removed from packets that leave the domain. In both cases, this operation implies an IP-in-IP encapsulation.
この表現は合計8バイトを必要としますが、ほとんどの場合、実際のRPIペイロードは19ビットしか必要としません。 Hop-by-HopヘッダーはRPLドメインの外に流れてはならないため、ドメインに入るパケットに挿入し、ドメインを離れるパケットから削除する必要があります。どちらの場合も、この操作はIP-in-IPカプセル化を意味します。
Additionally, in the case of the Non-Storing Mode of Operation (MOP), RPL requires a Source Routing Header (SRH) in all packets that are routed down a RPL graph. For that purpose, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)" [RFC6554] defines the type 3 Routing Header for IPv6 (RH3).
さらに、非保存動作モード（MOP）の場合、RPLは、RPLグラフにルーティングされるすべてのパケットにソースルーティングヘッダー（SRH）を必要とします。そのために、「低電力および損失の多いネットワーク（RPL）のルーティングプロトコルを使用したソースルートのIPv6ルーティングヘッダー」[RFC6554]は、IPv6（RH3）のタイプ3ルーティングヘッダーを定義しています。
------+--------- ^
| Internet |
| | Native IPv6
+-----+ |
| | Border Router (RPL Root) + | +
| | | | |
+-----+ | | | tunneled
| | | | using
o o o o | | | IPv6-in-
o o o o o o o o o | | | IPv6 and
o o o o o o o o o o | | | RPL SRH
o o o o o o o o o | | |
o o o o o o o o | | |
o o o o + v +
LLN
Figure 2: IP-in-IP Encapsulation within the LLN
図2：LLN内のIP-in-IPカプセル化
With Non-Storing RPL, even if the source is a node in the same LLN, the packet must first reach up the graph to the root so that the root can insert the SRH to go down the graph. In any fashion, whether the packet was originated in a node in the LLN or outside the LLN, and regardless of whether or not the packet stays within the LLN, as long as the source of the packet is not the root itself, the source-routing operation also implies an IP-in-IP encapsulation at the root in order to insert the SRH.
Non-Storing RPLを使用すると、ソースが同じLLN内のノードである場合でも、ルートがSRHを挿入してグラフを下がれるように、パケットは最初にグラフまでルートに到達する必要があります。いずれにせよ、パケットがLLN内のノードで発信されたか、LLNの外部で発信されたかに関係なく、パケットの送信元がルート自体でない限り、パケットがLLN内にとどまるかどうかに関係なく、送信元ルーティング操作には、SRHを挿入するためのルートでのIP-in-IPカプセル化も含まれます。
"An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4" [IPv6-ARCH] specifies the operation of IPv6 over the mode of operation described in "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement" [RFC7554]. The architecture requires the use of both RPL and the 6lo adaptation layer over IEEE 802.15.4. Because it inherits the constraints on frame size from the MAC layer, 6TiSCH cannot afford to allocate 8 bytes per packet on the RPI, hence the requirement for 6LoWPAN header compression of the RPI.
「IEEE 802.15.4のTSCHモードでのIPv6のアーキテクチャ」[IPv6-ARCH]は、インターネットのIEEE 802.15.4eタイムスロットチャネルホッピング（TSCH）の使用で説明されている動作モードでのIPv6の動作を指定します。モノ（IoT）：問題の説明」[RFC7554]。このアーキテクチャでは、IEEE 802.15.4でRPLと6loアダプテーションレイヤーの両方を使用する必要があります。 6TiSCHはMACレイヤーからフレームサイズの制約を継承するため、RPIでパケットごとに8バイトを割り当てる余裕がないため、RPIの6LoWPANヘッダー圧縮が必要になります。
An extensible compression technique is required that simplifies IP-in-IP encapsulation when it is needed and optimally compresses existing routing artifacts found in RPL LLNs.
必要なときにIP-in-IPカプセル化を簡素化し、RPL LLNにある既存のルーティングアーティファクトを最適に圧縮する拡張可能な圧縮技術が必要です。
This specification extends the 6lo adaptation layer framework ([RFC4944] [RFC6282]) so as to carry routing information for route-over networks based on RPL. It includes the formats necessary for RPL and is extensible for additional formats.
この仕様は、RPOに基づくルートオーバーネットワークのルーティング情報を伝送できるように、6loアダプテーションレイヤーフレームワーク（[RFC4944] [RFC6282]）を拡張しています。 RPLに必要なフォーマットが含まれており、追加のフォーマットに拡張可能です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the terms from, and is consistent with, "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102] and RPL [RFC6550].
このドキュメントは、「低電力および損失の多いネットワークのルーティングで使用される用語」[RFC7102]およびRPL [RFC6550]の用語を使用し、それらと一貫しています。
The terms "route-over" and "mesh-under" are defined in RFC 6775 [RFC6775].
「ルートオーバー」と「メッシュアンダー」という用語は、RFC 6775 [RFC6775]で定義されています。
Other terms in use in LLNs are found in "Terminology for Constrained-Node Networks" [RFC7228].
LLNで使用されている他の用語は、「制約付きノードネットワークの用語」[RFC7228]にあります。
The term "byte" is used in its now customary sense as a synonym for "octet".
「バイト」という用語は、今では慣習的な意味で「オクテット」の同義語として使用されています。
The "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] specification extends the 6lo adaptation layer framework ([RFC4944] [RFC6282]) by introducing a concept of "context" in the 6LoWPAN parser, a context being identified by a Page number. The specification defines 16 Pages.
「IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Paging Dispatch」[RFC8025]仕様は、6LoWPANパーサー、コンテキストに「コンテキスト」の概念を導入することにより、6loアダプテーションレイヤーフレームワーク（[RFC4944] [RFC6282]）を拡張しますページ番号で識別されます。仕様では16ページが定義されています。
This document operates within Page 1, which is indicated by a dispatch value of binary 11110001.
このドキュメントは、ページ1内で動作します。これは、バイナリ11110001のディスパッチ値によって示されます。
This specification introduces a new 6LoWPAN Routing Header (6LoRH) to carry IPv6 routing information. The 6LoRH may contain source routing information such as a compressed form of SRH, as well as other sorts of routing information such as the RPI and IP-in-IP encapsulation.
この仕様では、IPv6ルーティング情報を伝達するための新しい6LoWPANルーティングヘッダー（6LoRH）が導入されています。 6LoRHには、圧縮形式のSRHなどのソースルーティング情報や、RPIやIP-in-IPカプセル化などの他の種類のルーティング情報が含まれる場合があります。
The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value (TLV) field, which is extensible for future use.
6LoRHは6loWPANパケットでType-Length-Value（TLV）フィールドとして表され、将来の使用のために拡張可能です。
It is expected that a router that does not recognize the 6LoRH general format detailed in Section 4 will drop the packet when a 6LoRH is present.
セクション4で説明されている6LoRHの一般的な形式を認識しないルーターは、6LoRHが存在する場合にパケットをドロップすることが予想されます。
This specification uses the bit pattern 10xxxxxx in Page 1 for the new 6LoRH Dispatch. Section 4 describes how RPL artifacts in data packets can be compressed as 6LoRH headers.
この仕様では、新しい6LoRHディスパッチの1ページ目でビットパターン10xxxxxxを使用しています。セクション4では、データパケットのRPLアーティファクトを6LoRHヘッダーとして圧縮する方法について説明します。
In a zone of a packet where Page 1 is active (that is, once the Page 1 Paging Dispatch is parsed, and until another Paging Dispatch is parsed as described in the 6LoWPAN Paging Dispatch specification [RFC8025]), the parsing of the packet MUST follow this specification if the 6LoRH Bit Pattern (see Section 3.1) is found.
ページ1がアクティブであるパケットのゾーンでは（つまり、ページ1ページングディスパッチが解析された後、6LoWPANページングディスパッチ仕様[RFC8025]で説明されているように別のページングディスパッチが解析されるまで）、パケットの解析は6LoRHビットパターン（セクション3.1を参照）が見つかった場合は、この仕様に従ってください。
With this specification, the 6LoRH Dispatch is only defined in Page 1, so it MUST be placed in the packet in a zone where the Page 1 context is active.
この仕様では、6LoRHディスパッチはページ1でのみ定義されるため、ページ1コンテキストがアクティブなゾーンのパケットに配置する必要があります。
Because a 6LoRH header requires a Page 1 context, it MUST always be placed after any Fragmentation Header and/or Mesh Header as defined in RFC 4944 [RFC4944].
6LoRHヘッダーはページ1コンテキストを必要とするため、RFC 4944 [RFC4944]で定義されているように、常にフラグメンテーションヘッダーやメッシュヘッダーの後に配置する必要があります。
A 6LoRH header MUST always be placed before the LOWPAN_IPHC as defined in RFC 6282 [RFC6282]. It is designed in such a fashion that placing or removing a header that is encoded with 6LoRH does not modify the part of the packet that is encoded with LOWPAN_IPHC, whether or not there is an IP-in-IP encapsulation. For instance, the final destination of the packet is always the one in the LOWPAN_IPHC, whether or not there is a Routing Header.
RFC 6282 [RFC6282]で定義されているように、6LoRHヘッダーは常にLOWPAN_IPHCの前に配置する必要があります。これは、6LoRHでエンコードされたヘッダーを配置または削除しても、IP-in-IPカプセル化の有無にかかわらず、LOWPAN_IPHCでエンコードされたパケットの一部が変更されないように設計されています。たとえば、パケットの最終的な宛先は、ルーティングヘッダーがあるかどうかに関係なく、常にLOWPAN_IPHC内の宛先です。
The "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460] defines chains of headers that are introduced by an IPv6 header and terminated by either another IPv6 header (IP-in-IP) or an Upper-Layer Protocol (ULP) header. When an outer header is stripped from the packet, the whole chain goes with it. When one or more headers are inserted by an intermediate router, that router normally chains the headers and encapsulates the result in IP-in-IP.
「インターネットプロトコル、バージョン6（IPv6）仕様」[RFC2460]は、IPv6ヘッダーによって導入され、別のIPv6ヘッダー（IP-in-IP）または上位層プロトコル（ULP）ヘッダーによって終了するヘッダーのチェーンを定義します。パケットから外部ヘッダーが削除されると、チェーン全体がそれに対応します。中間ルーターによって1つ以上のヘッダーが挿入されると、そのルーターは通常、ヘッダーをチェーン化し、結果をIP-in-IPにカプセル化します。
With this specification, the chains of headers MUST be compressed in the same order as they appear in the uncompressed form of the packet. This means that if there is more than one nested IP-in-IP encapsulation, the first IP-in-IP encapsulation, with all its chain of headers, is encoded first in the compressed form.
この仕様では、ヘッダーのチェーンは、パケットの非圧縮形式で表示されるのと同じ順序で圧縮する必要があります。つまり、ネストされたIP-in-IPカプセル化が複数ある場合、最初のIP-in-IPカプセル化は、すべてのヘッダーチェーンとともに、最初に圧縮形式でエンコードされます。
In the compressed form of a packet that has a Source Route or a Hop-by-Hop (HbH) Options Header [RFC2460] after the inner IPv6 header (e.g., if there is no IP-in-IP encapsulation), these headers are placed in the 6LoRH form before the 6LOWPAN_IPHC that represents the IPv6 header (see Section 3.2.1). If this packet gets encapsulated and some other SRH or HbH Options Headers are added as part of the encapsulation, placing the 6LoRH headers next to one another may present an ambiguity on which header belongs to which chain in the uncompressed form.
内部IPv6ヘッダーの後にソースルートまたはホップバイホップ（HbH）オプションヘッダー[RFC2460]があるパケットの圧縮形式（たとえば、IP-in-IPカプセル化がない場合）では、これらのヘッダーはIPv6ヘッダーを表す6LOWPAN_IPHCの前に6LoRH形式で配置されます（セクション3.2.1を参照）。このパケットがカプセル化され、カプセル化の一部として他のいくつかのSRHまたはHbHオプションヘッダーが追加された場合、6LoRHヘッダーを互いに隣接して配置すると、どのヘッダーが非圧縮形式のどのチェーンに属しているかが曖昧になる可能性があります。
In order to disambiguate the headers that follow the inner IPv6 header in the uncompressed form from the headers that follow the outer IP-in-IP header, it is REQUIRED that the compressed IP-in-IP header is placed last in the encoded chain. This means that the 6LoRH headers that are found after the last compressed IP-in-IP header are to be inserted after the IPv6 header that is encoded with the 6LOWPAN_IPHC when decompressing the packet.
非圧縮形式の内部IPv6ヘッダーに続くヘッダーを外部IP-in-IPヘッダーに続くヘッダーから明確にするために、圧縮されたIP-in-IPヘッダーがエンコードされたチェーンの最後に配置されることが必要です。これは、最後に圧縮されたIP-in-IPヘッダーの後にある6LoRHヘッダーが、パケットの解凍時に6LOWPAN_IPHCでエンコードされたIPv6ヘッダーの後に挿入されることを意味します。
With regard to the relative placement of the SRH and the RPI in the compressed form, it is a design point for this specification that the SRH entries are consumed as the packet progresses down the LLN (see Section 5.3). In order to make this operation simpler in the compressed form, it is REQUIRED that in the compressed form, the addresses along the source route path are encoded in the order of the path, and that the compressed SRH are placed before the compressed RPI.
圧縮形式でのSRHとRPIの相対的な配置については、パケットがLLNを下っていくときにSRHエントリが消費されることが、この仕様の設計上のポイントです（セクション5.3を参照）。圧縮形式でこの操作を簡単にするために、圧縮形式では、ソースルートパスに沿ったアドレスがパスの順序でエンコードされ、圧縮SRHが圧縮RPIの前に配置されることが必要です。
The 6LoRH uses the Dispatch Value Bit Pattern of 10xxxxxx in Page 1.
6LoRHは、ページ1のディスパッチ値ビットパターン10xxxxxxを使用します。
The Dispatch Value Bit Pattern is split in two forms of 6LoRH:
ディスパッチ値ビットパターンは、6LoRHの2つの形式に分割されます。
Elective (6LoRHE), which may skipped if not understood
選択科目（6LoRHE）、理解できない場合はスキップされます
Critical (6LoRHC), which may not be ignored
重要（6LoRHC）、無視できない
For each form, a Type field is used to encode the type of 6LoRH.
フォームごとに、Typeフィールドを使用して6LoRHのタイプをエンコードします。
Note that there is a different registry for the Type field of each form of 6LoRH.
6LoRHの各フォームのTypeフィールドには異なるレジストリがあることに注意してください。
This means that a value for the Type that is defined for one form of 6LoRH may be redefined in the future for the other form.
これは、6LoRHの1つのフォームに対して定義されているタイプの値が、将来、他のフォームに対して再定義される可能性があることを意味します。
The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx. A 6LoRHE may be ignored and skipped in parsing. If it is ignored, the 6LoRHE is forwarded with no change inside the LLN.
6LoRHEは、101xxxxxのディスパッチ値ビットパターンを使用します。 6LoRHEは無視され、解析でスキップされます。無視された場合、6LoRHEはLLN内で変更されずに転送されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length -->
Figure 3: Elective 6LoWPAN Routing Header
図3：選択的6LoWPANルーティングヘッダー
Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE header that it does not support and/or cannot parse, for instance, if the Type is not recognized.
長さ：6LoRHEの長さ（最初の2バイトを除く、バイト単位）。これにより、たとえば、タイプが認識されない場合、ノードがサポートしていない、または解析できない6LoRHEヘッダーをスキップすることができます。
Type: Type of the 6LoRHE
タイプ：6LoRHEのタイプ
The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx.
6LoRHCは、100xxxxxのディスパッチ値ビットパターンを使用します。
A node that does not support the 6LoRHC Type MUST silently discard the packet.
6LoRHCタイプをサポートしないノードは、静かにパケットを破棄する必要があります。
Note: A situation where a node receives a message with a Critical 6LoWPAN Routing Header that it does not understand should not occur and is an administrative error, see Section 8.
注：ノードが、理解できないクリティカル6LoWPANルーティングヘッダーを含むメッセージを受信する状況は発生しないはずであり、管理エラーです。セクション8を参照してください。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|0| TSE | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length implied by Type/TSE -->
Figure 4: Critical 6LoWPAN Routing Header
図4：重要な6LoWPANルーティングヘッダー
Type-Specific Extension (TSE): The meaning depends on the Type, which must be known in all of the nodes. The interpretation of the TSE depends on the Type field that follows. For instance, it may be used to transport control bits, the number of elements in an array, or the length of the remainder of the 6LoRHC expressed in a unit other than bytes.
タイプ固有の拡張（TSE）：意味は、すべてのノードで認識されている必要があるタイプに依存します。 TSEの解釈は、続くTypeフィールドに依存します。たとえば、制御ビット、配列の要素数、またはバイト以外の単位で表された6LoRHCの残りの長さを転送するために使用できます。
Type: Type of the 6LoRHC
タイプ：6LoRHCのタイプ
The general technique used in this document to compress an address is first to determine a reference that has a long prefix match with this address and then elide that matching piece. In order to reconstruct the compressed address, the receiving node will perform the process of coalescence described in Section 4.3.1.
このドキュメントでアドレスを圧縮するために使用される一般的な手法は、最初にこのアドレスと長いプレフィックスが一致する参照を決定し、次にその一致する部分を除外することです。圧縮されたアドレスを再構築するために、受信ノードはセクション4.3.1で説明されている結合のプロセスを実行します。
One possible reference is the root of the RPL Destination-Oriented Directed Acyclic Graph (DODAG) that is being traversed. It is used by 6LoRH as the reference to compress an outer IP header in case of an IP-in-IP encapsulation. If the root is the source of the packet, this technique allows one to fully elide the source address in the compressed form of the IP header. If the root is not the encapsulator, then the Encapsulator Address may still be compressed using the root as a reference. How the address of the root is determined is discussed in Section 4.3.2.
考えられる1つの参照は、走査されているRPL宛先指向有向非巡回グラフ（DODAG）のルートです。これは、IP-in-IPカプセル化の場合に外部IPヘッダーを圧縮するための参照として6LoRHによって使用されます。ルートがパケットの送信元である場合、この手法により、IPヘッダーの圧縮形式で送信元アドレスを完全に取り除くことができます。ルートがカプセル化されていない場合でも、ルートを参照として使用して、カプセル化アドレスを圧縮できます。ルートのアドレスを決定する方法については、4.3.2で説明します。
Once the address of the source of the packet is determined, it becomes the reference for the compression of the addresses that are located in compressed SRH headers that are present inside the IP-in-IP encapsulation in the uncompressed form.
パケットの送信元のアドレスが決定されると、それは非圧縮形式のIP-in-IPカプセル化内に存在する圧縮SRHヘッダーにあるアドレスの圧縮の参照になります。
An IPv6 compressed address is coalesced with a reference address by overriding the N rightmost bytes of the reference address with the compressed address, where N is the length of the compressed address, as indicated by the Type of the SRH-6LoRH header in Figure 7.
図7のSRH-6LoRHヘッダーのタイプで示されるように、IPv6圧縮アドレスは、参照アドレスの右端のNバイトを圧縮アドレスで上書きすることにより、参照アドレスと結合されます。Nは圧縮アドレスの長さです。
The reference address MAY be a compressed address as well, in which case, it MUST be compressed in a form that is of an equal or greater length than the address that is being coalesced.
参照アドレスも圧縮されたアドレスであるかもしれません、その場合、それは合体されているアドレスと同じかそれ以上の長さの形式で圧縮されなければなりません。
A compressed address is expanded by coalescing it with a reference address. In the particular case of a Type 4 SRH-6LoRH, the address is expressed in full and the coalescence is a complete override as illustrated in Figure 5.
圧縮されたアドレスは、参照アドレスと結合することによって拡張されます。タイプ4 SRH-6LoRHの特定のケースでは、アドレスは完全に表現され、図5に示すように、合体は完全なオーバーライドです。
RRRRRRRRRRRRRRRRRRR A reference address, which may be compressed or not
RRRRRRRRRRRRRRRRRRR参照アドレス。圧縮されている場合とされていない場合があります。
CCCCCCC A compressed address, which may be shorter or the same as the reference
CCCCCCC圧縮されたアドレス。参照と同じかそれよりも短い場合があります。
RRRRRRRRRRRRCCCCCCC A coalesced address, which may be the same compression as the reference
RRRRRRRRRRRRCCCCCCC結合されたアドレス。参照と同じ圧縮になる場合があります。
Figure 5: Coalescing Addresses
図5：アドレスの結合
Stateful address compression requires that some state is installed in the devices to store the compression information that is elided from the packet. That state is stored in an abstract context table, and some form of index is found in the packet to obtain the compression information from the context table.
ステートフルアドレス圧縮では、パケットから除外された圧縮情報を格納するために、デバイスに何らかの状態がインストールされている必要があります。その状態は抽象コンテキストテーブルに格納され、コンテキストテーブルから圧縮情報を取得するためにパケットに何らかの形式のインデックスが見つかります。
With RFC 6282 [RFC6282], the state is provided to the stack by the 6LoWPAN Neighbor Discovery Protocol (NDP) [RFC6775]. NDP exchanges the context through the 6LoWPAN Context Option in Router Advertisement (RA) messages. In the compressed form of the packet, the context can be signaled in a Context Identifier Extension.
RFC 6282 [RFC6282]では、6LoWPAN近隣探索プロトコル（NDP）[RFC6775]によってスタックに状態が提供されます。 NDPは、ルーターアドバタイズ（RA）メッセージの6LoWPAN Context Optionを介してコンテキストを交換します。パケットの圧縮形式では、コンテキストをコンテキスト識別子拡張で通知できます。
With this specification, the compression information is provided to the stack by RPL, and RPL exchanges it through the DODAGID field in the DAG Information Object (DIO) messages, as described in more detail below. In the compressed form of the packet, the context can be signaled by the RPLInstanceID in the RPI.
この仕様では、圧縮情報はRPLによってスタックに提供され、RPLは、以下で詳しく説明するように、DAG情報オブジェクト（DIO）メッセージのDODAGIDフィールドを介してそれを交換します。パケットの圧縮形式では、RPIのRPLInstanceIDによってコンテキストを通知できます。
With RPL [RFC6550], the address of the DODAG root is known from the DODAGID field of the DIO messages. For a Global Instance, the RPLInstanceID that is present in the RPI is enough information to identify the DODAG that this node participates with and its associated root. But, for a Local Instance, the address of the root MUST be explicit, either in some device configuration or signaled in the packet, as the source or the destination address, respectively.
RPL [RFC6550]を使用すると、DODAGルートのアドレスは、DIOメッセージのDODAGIDフィールドからわかります。グローバルインスタンスの場合、RPIに存在するRPLInstanceIDは、このノードが参加するDODAGとその関連ルートを識別するのに十分な情報です。ただし、ローカルインスタンスの場合、ルートのアドレスは、いくつかのデバイス構成で、またはそれぞれ送信元アドレスまたは宛先アドレスとしてパケットで通知されて、明示的である必要があります。
When implicit, the address of the DODAG root MUST be determined as follows:
暗黙の場合、DODAGルートのアドレスは次のように決定する必要があります。
If the whole network is a single DODAG, then the root can be well-known and does not need to be signaled in the packets. But, since RPL does not expose that property, it can only be known by a configuration applied to all nodes.
ネットワーク全体が単一のDODAGである場合、ルートは既知である可能性があり、パケットでシグナリングする必要はありません。ただし、RPLはそのプロパティを公開しないため、すべてのノードに適用された構成によってのみ認識されます。
Else, the router that encapsulates the packet and compresses it with this specification MUST also place an RPI in the packet as prescribed by RPL to enable the identification of the DODAG. The RPI must be present even in the case when the router also places an SRH header in the packet.
そうでない場合、パケットをカプセル化し、この仕様で圧縮するルーターは、RPDで規定されているとおりにRPIをパケットに配置して、DODAGの識別を可能にする必要があります。ルータがパケットにSRHヘッダーも配置する場合でも、RPIが存在する必要があります。
It is expected that the RPL implementation maintains an abstract context table, indexed by Global RPLInstanceID, that provides the address of the root of the DODAG that this node participates in for that particular RPL Instance.
RPL実装は、この特定のRPLインスタンスに対してこのノードが参加するDODAGのルートのアドレスを提供する、グローバルRPLInstanceIDによってインデックスが付けられた抽象コンテキストテーブルを維持することが期待されています。
A Source Routing Header 6LoRH (SRH-6LoRH) provides a compressed form for the SRH, as defined in RFC 6554 [RFC6554], for use by RPL routers.
ソースルーティングヘッダー6LoRH（SRH-6LoRH）は、RFL 6554 [RFC6554]で定義されているように、RPLルーターが使用するSRHの圧縮形式を提供します。
One or more SRH-6LoRH header(s) MAY be placed in a 6LoWPAN packet.
1つ以上のSRH-6LoRHヘッダーが6LoWPANパケットに配置される場合があります。
If a non-RPL router receives a packet with an SRH-6LoRH header, there was a routing or a configuration error (see Section 8).
非RPLルーターがSRH-6LoRHヘッダーを持つパケットを受信した場合は、ルーティングエラーまたは構成エラーが発生しています（セクション8を参照）。
The desired reaction for the non-RPL router is to drop the packet, as opposed to skipping the header and forwarding the packet.
非RPLルーターの望ましい反応は、ヘッダーをスキップしてパケットを転送するのではなく、パケットをドロップすることです。
The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates it is Critical. Routers that understand the 6LoRH general format detailed in Section 4 cannot ignore a 6LoRH header of this type and will drop the packet if it is unknown to them.
SRH-6LoRHヘッダーのディスパッチ値ビットパターンは、クリティカルであることを示しています。セクション4で説明されている6LoRHの一般的な形式を理解するルーターは、このタイプの6LoRHヘッダーを無視することはできず、パケットが不明な場合はパケットをドロップします。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Where N = Size + 1
ここで、N =サイズ+ 1
Figure 6: The SRH-6LoRH
図6：SRH-6LoRH
The 6LoRH Type of an SRH-6LoRH header indicates the compression level used for that header.
SRH-6LoRHヘッダーの6LoRHタイプは、そのヘッダーに使用される圧縮レベルを示します。
The fields following the 6LoRH Type are compressed addresses indicating the consecutive hops and are ordered from the first to the last hop.
6LoRHタイプに続くフィールドは、連続したホップを示す圧縮アドレスであり、最初のホップから最後のホップへと順序付けられます。
All the addresses in a given SRH-6LoRH header MUST be compressed in an identical fashion, so the Length of the compressed form is the same for all.
特定のSRH-6LoRHヘッダーのすべてのアドレスは同じ方法で圧縮する必要があるため、圧縮形式の長さはすべて同じです。
In order to get different degrees of compression, multiple consecutive SRH-6LoRH headers MUST be used.
異なる程度の圧縮を取得するには、複数の連続したSRH-6LoRHヘッダーを使用する必要があります。
Type 0 means that the address is compressed down to one byte, whereas Type 4 means that the address is provided in full in the SRH-6LoRH with no compression. The complete list of Types of SRH-6LoRH and the corresponding compression level are provided in Figure 7:
タイプ0はアドレスが1バイトに圧縮されることを意味し、タイプ4はアドレスがSRH-6LoRHで完全に提供され、圧縮されないことを意味します。 SRH-6LoRHのタイプの完全なリストと対応する圧縮レベルを図7に示します。
+-----------+----------------------+
| 6LoRH | Length of compressed |
| Type | IPv6 address (bytes) |
+-----------+----------------------+
| 0 | 1 |
| 1 | 2 |
| 2 | 4 |
| 3 | 8 |
| 4 | 16 |
+-----------+----------------------+
Figure 7: The SRH-6LoRH Types
図7：SRH-6LoRHタイプ
In the case of an SRH-6LoRH header, the TSE field is used as a Size, which encodes the number of hops minus 1; so a Size of 0 means one hop, and the maximum that can be encoded is 32 hops. (If more than 32 hops need to be expressed, a sequence of SRH-6LoRH elements can be employed.) The result is that the Length, in bytes, of an SRH-6LoRH header is:
SRH-6LoRHヘッダーの場合、TSEフィールドはサイズとして使用され、ホップ数から1を引いたものをエンコードします。したがって、サイズ0は1ホップを意味し、エンコードできる最大値は32ホップです。 （32を超えるホップを表現する必要がある場合は、SRH-6LoRH要素のシーケンスを使用できます。）その結果、SRH-6LoRHヘッダーの長さ（バイト単位）は次のようになります。
2 + Length_of_compressed_IPv6_address * (Size + 1)
In the uncompressed form, when the root generates or forwards a packet in Non-Storing mode, it needs to include a Source Routing Header [RFC6554] to signal a strict source route path to a final destination down the DODAG.
非圧縮形式では、ルートが非格納モードでパケットを生成または転送するときに、ソースルーティングヘッダー[RFC6554]を含めて、厳密なソースルートパスをDODAGの下の最終宛先に通知する必要があります。
All the hops along the path, except the first one, are encoded in order in the SRH. The last entry in the SRH is the final destination; the destination in the IPv6 header is the first hop along the source route path. The intermediate hops perform a swap and the Segments Left field indicates the active entry in the Routing Header [RFC2460].
パスに沿ったすべてのホップは、最初のものを除いて、SRHで順番にエンコードされます。 SRHの最後のエントリが最終的な宛先です。 IPv6ヘッダーの宛先は、ソースルートパス上の最初のホップです。中間ホップはスワップを実行し、Segments Leftフィールドはルーティングヘッダー[RFC2460]のアクティブなエントリを示します。
The current destination of the packet, which is the termination of the current segment, is indicated at all times by the destination address of the IPv6 header.
現在のセグメントの終端であるパケットの現在の宛先は、常にIPv6ヘッダーの宛先アドレスによって示されます。
The handling of the SRH-6LoRH is different: there is no swap, and a forwarding router that corresponds to the first entry in the first SRH-6LoRH, upon reception of a packet, effectively consumes that entry when forwarding. This means that the size of a compressed source-routed packet decreases as the packet progresses along its path and that the routing information is lost along the way. This also means that an SRH encoded with 6LoRH is not recoverable and cannot be protected.
SRH-6LoRHの処理は異なります。スワップはなく、最初のSRH-6LoRHの最初のエントリに対応する転送ルーターは、パケットを受信すると、転送時にそのエントリを効率的に消費します。これは、パケットがパスに沿って進むにつれて、圧縮されたソースルートパケットのサイズが減少し、ルーティング情報が途中で失われることを意味します。これは、6LoRHでエンコードされたSRHは回復できず、保護できないことも意味します。
When compressed with this specification, all the remaining hops MUST be encoded in order in one or more consecutive SRH-6LoRH headers. Whether or not there is an SRH-6LoRH header present, the address of the final destination is indicated in the LOWPAN_IPHC at all times along the path. Examples of this are provided in Appendix A.
この仕様で圧縮された場合、残りのすべてのホップは、1つ以上の連続したSRH-6LoRHヘッダーで順番にエンコードされる必要があります。 SRH-6LoRHヘッダーが存在するかどうかに関係なく、最終宛先のアドレスは、パスに沿って常にLOWPAN_IPHCに示されます。この例は、付録Aにあります。
The current destination (termination of the current segment) for a compressed source-routed packet is indicated in the first entry of the first SRH-6LoRH. In strict source routing, that entry MUST match an address of the router that receives the packet.
圧縮されたソースルートパケットの現在の宛先（現在のセグメントの終了）は、最初のSRH-6LoRHの最初のエントリに示されています。厳密なソースルーティングでは、そのエントリはパケットを受信するルーターのアドレスと一致する必要があります。
The last entry in the last SRH-6LoRH is the last router on the way to the final destination in the LLN. This router can be the final destination if it is found desirable to carry a whole IP-in-IP encapsulation all the way. Else, it is the RPL parent of the final destination, or a router acting at 6LoWPAN Router (6LR) [RFC6775] for the destination host, and it is advertising the host as an external route to RPL.
最後のSRH-6LoRHの最後のエントリは、LLNの最終宛先に向かう途中の最後のルーターです。このルータは、IP-in-IPカプセル化全体を運ぶことが望ましい場合、最終的な宛先になる可能性があります。それ以外の場合は、最終宛先のRPL親、または宛先ホストの6LoWPANルーター（6LR）[RFC6775]で機能するルーターであり、RPLへの外部ルートとしてホストをアドバタイズしています。
If the SRH-6LoRH header is contained in an IP-in-IP encapsulation, the last router removes the whole chain of headers. Otherwise, it removes the SRH-6LoRH header only.
SRH-6LoRHヘッダーがIP-in-IPカプセル化に含まれている場合、最後のルーターはヘッダーのチェーン全体を削除します。それ以外の場合は、SRH-6LoRHヘッダーのみが削除されます。
6LoWPAN ND [RFC6282] is designed to support more than one IPv6 address per node and per Interface Identifier (IID); an IID is typically derived from a MAC address to optimize the LOWPAN_IPHC compression.
6LoWPAN ND [RFC6282]は、ノードごとおよびインターフェイス識別子（IID）ごとに複数のIPv6アドレスをサポートするように設計されています。 IIDは通常、LOWPAN_IPHC圧縮を最適化するためにMACアドレスから取得されます。
Link-local addresses are compressed with stateless address compression (S/DAC=0). The other addresses are derived from different prefixes, and they can be compressed with stateful address compression based on a context (S/DAC=1).
リンクローカルアドレスは、ステートレスアドレス圧縮（S / DAC = 0）で圧縮されます。他のアドレスはさまざまなプレフィックスから派生し、コンテキストに基づいたステートフルアドレス圧縮（S / DAC = 1）で圧縮できます。
But, stateless compression is only defined for the specific link-local prefix as opposed to the prefix in an encapsulating header. And with stateful compression, the compression reference is found in a context, as opposed to an encapsulating header.
ただし、ステートレス圧縮は、カプセル化ヘッダーのプレフィックスとは対照的に、特定のリンクローカルプレフィックスに対してのみ定義されます。ステートフル圧縮では、圧縮参照はカプセル化ヘッダーとは対照的に、コンテキスト内にあります。
The result is that, in the case of an IP-in-IP encapsulation, it is possible to compress an inner source (respective destination) IP address in a LOWPAN_IPHC based on the encapsulating IP header only if stateful (context-based) compression is used. The compression will operate only if the IID in the source (respective destination) IP address in the outer and inner headers match, which usually means that they refer to the same node. This is encoded as S/DAC = 1 and S/AM=11. It must be noted that the outer destination address that is used to compress the inner destination address is the last entry in the last SRH-6LoRH header.
その結果、IP-in-IPカプセル化の場合、ステートフル（コンテキストベース）圧縮が使用されている場合にのみ、カプセル化IPヘッダーに基づいてLOWPAN_IPHCの内部ソース（それぞれの宛先）IPアドレスを圧縮できます。中古。圧縮は、外部ヘッダーと内部ヘッダーのソース（それぞれの宛先）IPアドレスのIIDが一致する場合にのみ機能します。これは、通常、それらが同じノードを参照することを意味します。これは、S / DAC = 1およびS / AM = 11としてエンコードされます。内部宛先アドレスの圧縮に使用される外部宛先アドレスは、最後のSRH-6LoRHヘッダーの最後のエントリであることに注意する必要があります。
In order to save energy and to optimize the chances of transmission success on lossy media, it is a design point for this specification that the entries in the SRH that have been used are removed from the packet. This creates a discrepancy from the art of IPv6, where Routing Headers are mutable but recoverable.
エネルギーを節約し、損失の多いメディアでの送信成功の可能性を最適化するために、使用されたSRHのエントリがパケットから削除されることが、この仕様の設計ポイントです。これにより、ルーティングヘッダーは変更可能ですが回復可能であるIPv6の技術との矛盾が生じます。
With this specification, the packet can be expanded at any hop into a valid IPv6 packet, including an SRH, and compressed back. But the packet, as decompressed along the way, will not carry all the consumed addresses that packet would have if it had been forwarded in the uncompressed form.
この仕様では、パケットを任意のホップでSRHを含む有効なIPv6パケットに拡張し、圧縮して戻すことができます。ただし、途中で圧縮解除されたパケットは、圧縮されていない形式で転送された場合にパケットで使用されるすべてのアドレスを運ぶわけではありません。
It is noted that:
次のことに注意してください。
The value of keeping the whole RH in an IPv6 header is for the receiver to reverse it to use the symmetrical path on the way back.
RH全体をIPv6ヘッダーに保持することの価値は、レシーバーがそれを逆にして、対称パスを使用して戻すことです。
It is generally not a good idea to reverse a Routing Header. The RH may have been used to stay away from the shortest path for some reason that is only valid on the way in (segment routing).
通常、ルーティングヘッダーを元に戻すことはお勧めできません。 RHは、何らかの理由で（セグメントルーティング）途中でのみ有効である最短パスから離れて使用された可能性があります。
There is no use in reversing an RH in the present RPL specifications.
現在のRPL仕様では、RHを逆にする意味はありません。
Point-to-Point (P2P) RPL reverses a path that was learned reactively as a part of the protocol operation, which is probably a cleaner way than a reversed echo on the data path.
ポイントツーポイント（P2P）RPLは、プロトコル操作の一部として反応的に学習されたパスを逆にします。これは、おそらくデータパスの逆エコーよりもクリーンな方法です。
Reversing a header is discouraged (by RFC 2460 [RFC2460]) for Redirected Header Option (RHO) unless it is authenticated, which requires an Authentication Header (AH). There is no definition of an AH operation for SRH, and there is no indication that the need exists in LLNs.
認証ヘッダー（AH）を必要とする認証されていない限り、リダイレクトヘッダーオプション（RHO）ではヘッダーの反転は（RFC 2460 [RFC2460]によって）推奨されていません。 SRHのAH操作の定義はなく、LLNに必要性があることを示すものもありません。
AH does not protect the RH on the way. AH is a validation at the receiver with the sole value of enabling the receiver to reverse it.
AHは途中でRHを保護しません。 AHは受信側での検証であり、受信側がそれを元に戻すことができるようにするという唯一の価値があります。
A RPL domain is usually protected by L2 security, which secures both RPL itself and the RH in the packets at every hop. This is a better security than that provided by AH.
RPLドメインは通常、すべてのホップでパケット内のRPL自体とRHの両方を保護するL2セキュリティによって保護されます。これは、AHが提供するセキュリティよりも優れたセキュリティです。
In summary, the benefit of saving energy and lowering the chances of loss by sending smaller frames over the LLN are seen as overwhelming compared to the value of possibly reversing the header.
要約すると、LLNを介してより小さなフレームを送信することによってエネルギーを節約し、損失の可能性を低くすることの利点は、ヘッダーを逆にする可能性のある値に比べて圧倒的であると見なされます。
In order to optimize the compression of IP addresses present in the SRH headers, this specification requires that the 6LoWPAN layer identifies an address that is used as a reference for the compression.
SRHヘッダーに存在するIPアドレスの圧縮を最適化するために、この仕様では、6LoWPANレイヤーが圧縮の参照として使用されるアドレスを識別する必要があります。
With this specification, the Compression Reference for the first address found in an SRH header is the source of the IPv6 packet, and then the reference for each subsequent entry is the address of its predecessor once it is uncompressed.
この仕様では、SRHヘッダーで見つかった最初のアドレスの圧縮参照がIPv6パケットのソースであり、圧縮解除されると、後続の各エントリの参照はその先行のアドレスになります。
With RPL [RFC6550], an SRH header may only be present in Non-Storing mode, and it may only be placed in the packet by the root of the DODAG, which must be the source of the resulting IPv6 packet [RFC2460]. In this case, the address used as Compression Reference is the address of the root.
RPL [RFC6550]を使用すると、SRHヘッダーは非保存モードでのみ存在でき、DODAGのルートによってのみパケットに配置できます。これは、結果のIPv6パケットのソースである必要があります[RFC2460]。この場合、圧縮参照として使用されるアドレスはルートのアドレスです。
The Compression Reference MUST be determined as follows:
圧縮参照は次のように決定する必要があります。
The reference address may be obtained by configuration. The configuration may indicate either the address in full or the identifier of a 6LoWPAN Context that carries the address [RFC6775], for instance, one of the 16 Context Identifiers used in LOWPAN_IPHC [RFC6282].
参照アドレスは構成によって取得できます。設定は、完全なアドレス、またはアドレスを運ぶ6LoWPANコンテキストの識別子[RFC6775]、たとえば、LOWPAN_IPHCで使用される16のコンテキスト識別子[RFC6282]のいずれかを示します。
Else, if there is no IP-in-IP encapsulation, the source address in the IPv6 header that is compressed with LOWPAN_IPHC is the reference for the compression.
それ以外の場合、IP-in-IPカプセル化がない場合、LOWPAN_IPHCで圧縮されたIPv6ヘッダーの送信元アドレスが圧縮の参照になります。
Else, if the IP-in-IP compression specified in this document is used and the Encapsulator Address is provided, then the Encapsulator Address is the reference.
そうでない場合、このドキュメントで指定されているIP-in-IP圧縮が使用され、カプセル化アドレスが指定されている場合、カプセル化アドレスが参照になります。
Else, meaning that the IP-in-IP compression specified in this document is used and the encapsulator is implicitly the root, the address of the root is the reference.
それ以外の場合は、このドキュメントで指定されているIP-in-IP圧縮が使用され、カプセル化装置が暗黙的にルートであり、ルートのアドレスが参照です。
Upon reception, the router checks whether the address in the first entry of the first SRH-6LoRH is one of its own addresses. If that is the case, the router MUST consume that entry before forwarding, which is an action of popping from a stack, where the stack is effectively the sequence of entries in consecutive SRH-6LoRH headers.
受信すると、ルーターは最初のSRH-6LoRHの最初のエントリのアドレスが自身のアドレスの1つであるかどうかを確認します。その場合、ルーターは転送前にそのエントリを消費する必要があります。これはスタックからポップするアクションであり、スタックは連続したSRH-6LoRHヘッダー内のエントリのシーケンスです。
Popping an entry of an SRH-6LoRH header is a recursive action performed as follows:
SRH-6LoRHヘッダーのエントリのポップは、次のように実行される再帰的なアクションです。
If the Size of the current SRH-6LoRH header is 1 or more (indicating that there are at least 2 entries in the header), the router removes the first entry and decrements the Size by 1.
現在のSRH-6LoRHヘッダーのサイズが1以上の場合（ヘッダーに少なくとも2つのエントリがあることを示します）、ルーターは最初のエントリを削除し、サイズを1だけ減らします。
If the Size of the current SRH-6LoRH header is 0 (indicating that there is only 1 entry in the header) and there is no subsequent SRH-6LoRH after this, then the current SRH-6LoRH is removed.
現在のSRH-6LoRHヘッダーのサイズが0（ヘッダーにエントリが1つしかないことを示す）で、その後にSRH-6LoRHがない場合、現在のSRH-6LoRHは削除されます。
If the Size of the current SRH-6LoRH header is 0 and there is a subsequent SRH-6LoRH and the Type of the subsequent SRH-6LoRH is equal to or greater than the Type of the current SRH-6LoRH header (indicating the same or lesser compression yielding the same or larger compressed forms), then the current SRH-6LoRH is removed.
現在のSRH-6LoRHヘッダーのサイズが0であり、後続のSRH-6LoRHがあり、後続のSRH-6LoRHのタイプが現在のSRH-6LoRHヘッダーのタイプ以上である場合（同じかそれ以下を示す）同じまたはより大きな圧縮形式を生成する圧縮）、現在のSRH-6LoRHは削除されます。
If the Size of the current SRH-6LoRH header is 0 and there is a subsequent SRH-6LoRH and the Type of the subsequent SRH-6LoRH is less the Type of the current SRH-6LoRH header, the first entry of the subsequent SRH-6LoRH is removed and coalesced with the first entry of the current SRH-6LoRH.
現在のSRH-6LoRHヘッダーのサイズが0で、後続のSRH-6LoRHがあり、後続のSRH-6LoRHのタイプが現在のSRH-6LoRHヘッダーのタイプよりも小さい場合、後続のSRH-6LoRHの最初のエントリは削除され、現在のSRH-6LoRHの最初のエントリと結合されます。
At the end of the process, if there are no more SRH-6LoRH in the packet, then the processing node is the last router along the source route path.
プロセスの最後に、パケットにSRH-6LoRHがなくなると、処理ノードがソースルートパス上の最後のルーターになります。
An example of this operation is provided in Appendix A.3.
この操作の例を付録A.3に示します。
When receiving a packet with an SRH-6LoRH, a router determines the IPv6 address of the current segment endpoint.
SRH-6LoRHでパケットを受信すると、ルーターは現在のセグメントエンドポイントのIPv6アドレスを決定します。
If strict source routing is enforced and this router is not the segment endpoint for the packet, then this router MUST drop the packet.
厳密なソースルーティングが適用され、このルーターがパケットのセグメントエンドポイントでない場合、このルーターはパケットをドロップする必要があります。
If this router is the current segment endpoint, then the router pops its address as described in Section 5.5 and continues processing the packet.
このルーターが現在のセグメントのエンドポイントである場合、ルーターはセクション5.5で説明されているようにそのアドレスをポップし、パケットの処理を続行します。
If there is still an SRH-6LoRH, then the router determines the new segment endpoint and routes the packet towards that endpoint.
それでもSRH-6LoRHがある場合、ルーターは新しいセグメントエンドポイントを決定し、そのエンドポイントに向けてパケットをルーティングします。
Otherwise, the router uses the destination in the inner IP header to forward or accept the packet.
それ以外の場合、ルーターは内部IPヘッダーの宛先を使用して、パケットを転送または受け入れます。
The segment endpoint of a packet MUST be determined as follows:
パケットのセグメントエンドポイントは、次のように決定する必要があります。
The router first determines the Compression Reference as discussed in Section 4.3.1.
セクション4.3.1で説明したように、ルーターは最初に圧縮参照を決定します。
The router then coalesces the Compression Reference with the first entry of the first SRH-6LoRH header as discussed in Section 5.4. If the SRH-6LoRH header is Type 4, then the coalescence is a full override.
次にルーターは、セクション5.4で説明するように、圧縮参照を最初のSRH-6LoRHヘッダーの最初のエントリと結合します。 SRH-6LoRHヘッダーがタイプ4の場合、合体は完全なオーバーライドです。
Since the Compression Reference is an uncompressed address, the coalesced IPv6 address is also expressed in the full 128 bits.
圧縮参照は非圧縮アドレスであるため、結合されたIPv6アドレスも128ビットで表現されます。
Section 11.2 of the RPL document [RFC6550] specifies the RPL Packet Information (RPI) as a set of fields that are placed by RPL routers in IP packets to identify the RPL Instance, detect anomalies, and trigger corrective actions.
RPLドキュメント[RFC6550]のセクション11.2では、RPLパケット情報（RPI）をRPLルーターがIPパケットに配置してRPLインスタンスを識別し、異常を検出し、修正アクションをトリガーするフィールドのセットとして指定しています。
In particular, the SenderRank, which is the scalar metric computed by a specialized Objective Function such as described in RFC 6552 [RFC6552], indicates the Rank of the sender and is modified at each hop. The SenderRank field is used to validate that the packet progresses in the expected direction, either upwards or downwards, along the DODAG.
特に、RFC 6552 [RFC6552]で説明されているような特別な目的関数によって計算されたスカラーメトリックであるSenderRankは、送信者のランクを示し、各ホップで変更されます。 SenderRankフィールドは、パケットがDODAGに沿って上方または下方の予想される方向に進行することを検証するために使用されます。
RPL defines the "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] to transport the RPI, which is carried in an IPv6 Hop-by-Hop Options Header [RFC2460], typically consuming 8 bytes per packet.
RPLは、「データプレーンデータグラムでRPL情報を伝送するための低電力および損失の多いネットワーク（RPL）オプションのルーティングプロトコル」[RFC6553]を定義して、IPv6ホップバイホップオプションヘッダーで伝送されるRPIを転送します[ RFC2460]、通常はパケットあたり8バイトを消費します。
With RFC 6553 [RFC6553], the RPL Option is encoded as 6 octets, which must be placed in a Hop-by-Hop header that consumes two additional octets for a total of 8 octets. To limit the header's range to just the RPL domain, the Hop-by-Hop header must be added to (or removed from) packets that cross the border of the RPL domain.
RFC 6553 [RFC6553]では、RPLオプションは6オクテットとしてエンコードされ、合計8オクテットの2つの追加オクテットを消費するホップバイホップヘッダーに配置する必要があります。ヘッダーの範囲をRPLドメインのみに制限するには、RPLドメインの境界を越えるパケットにホップバイホップヘッダーを追加（またはパケットから削除）する必要があります。
The 8-byte overhead is detrimental to LLN operation, particularly with regard to bandwidth and battery constraints. These bytes may cause a containing frame to grow above maximum frame size, leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn leads to even more energy expenditure and issues discussed in "LLN Fragment Forwarding and Recovery" [FORWARD-FRAG].
8バイトのオーバーヘッドは、特に帯域幅とバッテリーの制約に関して、LLN操作に有害です。これらのバイトにより、含まれているフレームが最大フレームサイズを超えて大きくなり、レイヤー2または6LoWPAN [RFC4944]の断片化が発生する可能性があります。これにより、さらに多くのエネルギー消費と「LLNフラグメントの転送と回復」[FORWARD-FRAG]で説明されている問題が発生します。 。
An additional overhead comes from the need, in certain cases, to add an IP-in-IP encapsulation to carry the Hop-by-Hop header. This is needed when the router that inserts the Hop-by-Hop header is not the source of the packet so that an error can be returned to the router. This is also the case when a packet originated by a RPL node must be stripped from the Hop-by-Hop header to be routed outside the RPL domain.
追加のオーバーヘッドは、ホップバイホップヘッダーを伝送するためにIP-in-IPカプセル化を追加する必要がある場合から生じます。これは、Hop-by-Hopヘッダーを挿入するルーターがパケットの送信元ではないためにエラーがルーターに返される場合に必要です。これは、RPLノードによって発信されたパケットをホップバイホップヘッダーから削除してRPLドメインの外部にルーティングする必要がある場合にも当てはまります。
For that reason, this specification defines an IP-in-IP-6LoRH header in Section 7, but it must be noted that removal of a 6LoRH header does not require manipulation of the packet in the LOWPAN_IPHC, and thus, if the source address in the LOWPAN_IPHC is the node that inserted the IP-in-IP-6LoRH header, then this situation alone does not mandate an IP-in-IP-6LoRH header.
そのため、この仕様ではセクション7でIP-in-IP-6LoRHヘッダーを定義していますが、6LoRHヘッダーを削除してもLOWPAN_IPHCでパケットを操作する必要がないことに注意してください。 LOWPAN_IPHCはIP-in-IP-6LoRHヘッダーを挿入したノードであり、この状況だけではIP-in-IP-6LoRHヘッダーは必須ではありません。
Note: It was found that some implementations omit the RPI for packets going down the RPL graph in Non-Storing mode, even though RPL indicates that the RPI should be placed in the packet. With this specification, the RPI is important to indicate the RPLInstanceID, so the RPI should not be omitted.
注：RPLがRPIをパケットに配置する必要があることを示している場合でも、一部の実装では、非保存モードでRPLグラフを下がるパケットのRPIを省略していることがわかりました。この仕様では、RPLはRPLInstanceIDを示すために重要であるため、RPIを省略しないでください。
As a result, a RPL packet may bear only an RPI-6LoRH header and no IP-in-IP-6LoRH header. In that case, the source and destination of the packet are specified by the LOWPAN_IPHC.
その結果、RPLパケットにはRPI-6LoRHヘッダーのみが含まれ、IP-in-IP-6LoRHヘッダーは含まれません。その場合、パケットの送信元と宛先はLOWPAN_IPHCによって指定されます。
As with RFC 6553 [RFC6553], the fields in the RPI include an 'O', an 'R', and an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), and a 16-bit SenderRank.
RFC 6553 [RFC6553]と同様に、RPIのフィールドには、「O」、「R」、および「F」ビット、8ビットRPLInstanceID（内部構造を含む）、および16ビットSenderRankが含まれます。
The remainder of this section defines the RPI-6LoRH header, which is a Critical 6LoWPAN Routing Header that is designed to transport the RPI in 6LoWPAN LLNs.
このセクションの残りの部分では、RPI-6LoRHヘッダーを定義します。これは、6LoWPAN LLNでRPIを転送するように設計されたクリティカル6LoWPANルーティングヘッダーです。
RPL Instances are discussed in Section 5 of the RPL specification [RFC6550]. A number of simple use cases do not require more than one RPL Instance, and in such cases, the RPL Instance is expected to be the Global Instance 0. A global RPLInstanceID is encoded in a RPLInstanceID field as follows:
RPLインスタンスについては、RPL仕様[RFC6550]のセクション5で説明されています。多くの単純な使用例では、複数のRPLインスタンスは必要ありません。そのような場合、RPLインスタンスはグローバルインスタンス0であることが期待されます。グローバルRPLInstanceIDは、次のようにRPLInstanceIDフィールドにエンコードされます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLInstanceID in 0..127
+-+-+-+-+-+-+-+-+
Figure 8: RPLInstanceID Field Format for Global Instances
図8：グローバルインスタンスのRPLInstanceIDフィールド形式
For the particular case of the Global Instance 0, the RPLInstanceID field is all zeros. This specification allows the compressor to elide a RPLInstanceID field that is all zeros and defines an I flag that, when set, signals that the field is elided.
グローバルインスタンス0の特定のケースでは、RPLInstanceIDフィールドはすべてゼロです。この仕様により、コンプレッサーは、すべてゼロであるRPLInstanceIDフィールドを省略し、設定されたときにフィールドが省略されたことを通知するIフラグを定義できます。
The SenderRank is the result of the DAGRank operation on the Rank of the sender; here, the DAGRank operation is defined in Section 3.5.1 of the RPL specification [RFC6550] as:
SenderRankは、送信者のランクに対するDAGRank操作の結果です。ここで、DAGRank操作は、RPL仕様[RFC6550]のセクション3.5.1で次のように定義されています。
DAGRank(rank) = floor(rank/MinHopRankIncrease)
If MinHopRankIncrease is set to a multiple of 256, the least significant eight bits of the SenderRank will be all zeroes; by eliding those, the SenderRank can be compressed into a single byte. This idea is used in RFC 6550 [RFC6550], by defining DEFAULT_MIN_HOP_RANK_INCREASE as 256, and in RFC 6552 [RFC6552], which defaults MinHopRankIncrease to DEFAULT_MIN_HOP_RANK_INCREASE.
MinHopRankIncreaseが256の倍数に設定されている場合、SenderRankの最下位8ビットはすべてゼロになります。それらを省略することにより、SenderRankを1バイトに圧縮できます。このアイデアは、RFC 6550 [RFC6550]でDEFAULT_MIN_HOP_RANK_INCREASEを256として定義することで使用され、RFC 6552 [RFC6552]では、MinHopRankIncreaseをDEFAULT_MIN_HOP_RANK_INCREASEにデフォルト設定します。
This specification allows for the SenderRank to be encoded as either 1 or 2 bytes and defines a K flag that, when set, signals that a single byte is used.
この仕様では、SenderRankを1バイトまたは2バイトとしてエンコードすることができ、Kフラグを定義します。これを設定すると、1バイトが使用されていることを通知します。
The RPI-6LoRH header provides a compressed form for the RPL RPI. Routers that need to forward a packet with a RPI-6LoRH header are expected to be RPL routers that support this specification.
RPI-6LoRHヘッダーは、RPL RPIの圧縮形式を提供します。 RPI-6LoRHヘッダーを持つパケットを転送する必要があるルーターは、この仕様をサポートするRPLルーターであることが期待されます。
If a non-RPL router receives a packet with a RPI-6LoRH header, there was a routing or a configuration error (see Section 8).
非RPLルーターがRPI-6LoRHヘッダーを持つパケットを受信した場合は、ルーティングエラーまたは構成エラーが発生しています（セクション8を参照）。
The desired reaction for the non-RPL router is to drop the packet as opposed to skip the header and forward the packet, which could end up forming loops by reinjecting the packet in the wrong RPL Instance.
非RPLルーターの望ましい反応は、ヘッダーをスキップしてパケットを転送するのではなく、パケットをドロップすることです。これにより、誤ったRPLインスタンスにパケットを再注入することでループが形成される可能性があります。
The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates it is Critical. Routers that understand the 6LoRH general format detailed in Section 4 cannot ignore a 6LoRH header of this type and will drop the packet if it is unknown to them.
SRH-6LoRHヘッダーのディスパッチ値ビットパターンは、クリティカルであることを示しています。セクション4で説明されている6LoRHの一般的な形式を理解するルーターは、このタイプの6LoRHヘッダーを無視することはできず、パケットが不明な場合はパケットをドロップします。
Since the RPI-6LoRH header is a Critical header, the TSE field does not need to be a length expressed in bytes. Here, the field is fully reused for control bits that encode the O, R, and F flags from the RPI, as well as the I and K flags that indicate the compression format.
RPI-6LoRHヘッダーはクリティカルヘッダーであるため、TSEフィールドはバイト単位で表される長さである必要はありません。ここでは、フィールドは、RPIからのO、R、およびFフラグをエンコードする制御ビットと、圧縮形式を示すIおよびKフラグに完全に再利用されます。
The RPI-6LoRH is Type 5.
RPI-6LoRHはタイプ5です。
The RPI-6LoRH header is immediately followed by the RPLInstanceID field, unless that field is fully elided, and then the SenderRank, which is either compressed into one byte or fully in-lined as 2 bytes. The I and K flags in the RPI-6LoRH header indicate whether the RPLInstanceID is elided and/or the SenderRank is compressed. Depending on these bits, the Length of the RPI-6LoRH may vary as described hereafter.
RPI-6LoRHヘッダーの直後には、RPLInstanceIDフィールドが続きます。ただし、そのフィールドが完全に省略されていない場合は、SenderRankが1バイトに圧縮されるか、2バイトとして完全にインライン化されます。 RPI-6LoRHヘッダーのIフラグとKフラグは、RPLInstanceIDが省略されているか、SenderRankが圧縮されているかを示します。これらのビットに応じて、RPI-6LoRHの長さは、以下で説明するように異なる場合があります。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
|1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
Figure 9: The Generic RPI-6LoRH Format
図9：一般的なRPI-6LoRH形式
O, R, and F bits: The O, R, and F bits are defined in Section 11.2 of RFC 6550 [RFC6550].
O、R、およびFビット：O、R、およびFビットは、RFC 6550 [RFC6550]のセクション11.2で定義されています。
I flag: If it is set, the RPLInstanceID is elided and the RPLInstanceID is the Global RPLInstanceID 0. If it is not set, the octet immediately following the Type field contains the RPLInstanceID as specified in Section 5.1 of RFC 6550 [RFC6550].
Iフラグ：設定されている場合、RPLInstanceIDは省略され、RPLInstanceIDはグローバルRPLInstanceID 0です。設定されていない場合、タイプフィールドの直後のオクテットには、RFC 6550 [RFC6550]のセクション5.1で指定されているRPLInstanceIDが含まれます。
K flag: If it is set, the SenderRank is compressed into 1 octet, with the least significant octet elided. If it is not set, the SenderRank is fully inlined as 2 octets.
Kフラグ：設定されている場合、SenderRankは1オクテットに圧縮され、最下位オクテットが省略されます。設定されていない場合、SenderRankは2オクテットとして完全にインライン化されます。
In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256, so the least significant byte is all zeros and can be elided:
図10では、RPLInstanceIDはグローバルRPLInstanceID 0であり、MinHopRankIncreaseは256の倍数であるため、最下位バイトはすべてゼロであり、省略できます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I=1, K=1
Figure 10: The Most Compressed RPI-6LoRH
図10：最も圧縮されたRPI-6LoRH
In Figure 11, the RPLInstanceID is the Global RPLInstanceID 0, but both bytes of the SenderRank are significant so it cannot be compressed:
図11では、RPLInstanceIDはグローバルRPLInstanceID 0ですが、SenderRankの両方のバイトは重要であるため、圧縮できません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I=1, K=0
Figure 11: Eliding the RPLInstanceID
図11：RPLInstanceIDの省略
In Figure 12, the RPLInstanceID is not the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256:
図12では、RPLInstanceIDはグローバルRPLInstanceID 0ではなく、MinHopRankIncreaseは256の倍数です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I=0, K=1
Figure 12: Compressing SenderRank
図12：SenderRankの圧縮
In Figure 13, the RPLInstanceID is not the Global RPLInstanceID 0, and both bytes of the SenderRank are significant:
図13では、RPLInstanceIDはグローバルRPLInstanceID 0ではなく、SenderRankの両方のバイトが重要です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...-Rank |
+-+-+-+-+-+-+-+-+
I=0, K=0
Figure 13: The Least Compressed Form of RPI-6LoRH
図13：RPI-6LoRHの最小圧縮形式
The IP-in-IP 6LoRH (IP-in-IP-6LoRH) header is an Elective 6LoWPAN Routing Header that provides a compressed form for the encapsulating IPv6 Header in the case of an IP-in-IP encapsulation.
IP-in-IP 6LoRH（IP-in-IP-6LoRH）ヘッダーは、選択的6LoWPANルーティングヘッダーで、IP-in-IPカプセル化の場合にカプセル化IPv6ヘッダーの圧縮形式を提供します。
An IP-in-IP encapsulation is used to insert a field such as a Routing Header or an RPI at a router that is not the source of the packet. In order to send an error back regarding the inserted field, the address of the router that performs the insertion must be provided.
IP-in-IPカプセル化は、ルーティングヘッダーやRPIなどのフィールドを、パケットの送信元ではないルーターに挿入するために使用されます。挿入されたフィールドに関するエラーを返信するには、挿入を実行するルーターのアドレスを指定する必要があります。
The encapsulation can also enable the last router prior to the Destination to remove a field such as the RPI, but this can be done in the compressed form by removing the RPI-6LoRH, so an IP-in-IP-6LoRH encapsulation is not required for that sole purpose.
カプセル化により、宛先の前の最後のルーターでRPIなどのフィールドを削除することもできますが、これはRPI-6LoRHを削除することで圧縮形式で実行できるため、IP-in-IP-6LoRHカプセル化は必要ありません。その唯一の目的のために。
The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates it is Elective. This field is not Critical for routing since it does not indicate the destination of the packet, which is either encoded in an SRH-6LoRH header or in the inner IP header. A 6LoRH header of this type can be skipped if not understood (per Section 4), and the 6LoRH header indicates the Length in bytes.
SRH-6LoRHヘッダーのディスパッチ値ビットパターンは、それが選択的であることを示します。このフィールドは、SRH-6LoRHヘッダーまたは内部IPヘッダーのいずれかにエンコードされているパケットの宛先を示していないため、ルーティングには重要ではありません。このタイプの6LoRHヘッダーは、理解できない場合はスキップできます（セクション4に従って）。6LoRHヘッダーは、バイト単位で長さを示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 14: The IP-in-IP-6LoRH
図14：IP-in-IP-6LoRH
The Length of an IP-in-IP-6LoRH header is expressed in bytes and MUST be at least 1, to indicate a Hop Limit (HL) that is decremented at each hop. When the HL reaches 0, the packet is dropped per RFC 2460 [RFC2460].
IP-in-IP-6LoRHヘッダーの長さはバイトで表され、各ホップでデクリメントされるホップ制限（HL）を示すために、少なくとも1である必要があります。 HLが0に達すると、パケットはRFC 2460 [RFC2460]に従ってドロップされます。
If the Length of an IP-in-IP-6LoRH header is exactly 1, then the Encapsulator Address is elided, which means that the encapsulator is a well-known router, for instance, the root in a RPL graph.
IP-in-IP-6LoRHヘッダーの長さが正確に1の場合、カプセル化アドレスは省略されます。これは、カプセル化が既知のルーター、たとえばRPLグラフのルートであることを意味します。
The most efficient compression of an IP-in-IP encapsulation that can be achieved with this specification is obtained when an endpoint of the packet is the root of the RPL DODAG associated to the RPL Instance that is used to forward the packet, and the root address is known implicitly as opposed to signaled explicitly in the data packets.
この仕様で達成できるIP-in-IPカプセル化の最も効率的な圧縮は、パケットのエンドポイントが、パケットの転送に使用されるRPLインスタンスに関連付けられたRPL DODAGのルートであり、ルートである場合に得られます。アドレスは、データパケットで明示的に通知されるのではなく、暗黙的に知られています。
If the Length of an IP-in-IP-6LoRH header is greater than 1, then an Encapsulator Address is placed in a compressed form after the Hop Limit field. The value of the Length indicates which compression is performed on the Encapsulator Address. For instance, a Length of 3 indicates that the Encapsulator Address is compressed to 2 bytes. The reference for the compression is the address of the root of the DODAG. The way the address of the root is determined is discussed in Section 4.3.2.
IP-in-IP-6LoRHヘッダーの長さが1より大きい場合、カプセル化アドレスはホップ制限フィールドの後に圧縮形式で配置されます。長さの値は、カプセル化アドレスで実行される圧縮を示します。たとえば、長さ3は、カプセル化アドレスが2バイトに圧縮されていることを示します。圧縮の参照はDODAGのルートのアドレスです。ルートのアドレスを決定する方法については、4.3.2で説明します。
With RPL, the destination address in the IP-in-IP header is implicitly the root in the RPL graph for packets going upwards; in Storing mode, it is the destination address in the LOWPAN_IPHC for packets going downwards. In Non-Storing mode, there is no implicit value for packets going downwards.
RPLを使用すると、IP-in-IPヘッダーの宛先アドレスは、上方に向かうパケットのRPLグラフの暗黙のルートになります。 Storingモードでは、これはLOWPAN_IPHCの宛先アドレスであり、パケットは下向きになります。非保存モードでは、パケットが下向きになる暗黙の値はありません。
If the implicit value is correct, the destination IP address of the IP-in-IP encapsulation can be elided. Else, the destination IP address of the IP-in-IP header is transported in an SRH-6LoRH header as the first entry of the first of these headers.
暗黙の値が正しい場合は、IP-in-IPカプセル化の宛先IPアドレスを省略できます。そうでない場合、IP-in-IPヘッダーの宛先IPアドレスは、これらのヘッダーの最初の最初のエントリーとしてSRH-6LoRHヘッダーで転送されます。
If the final destination of the packet is a leaf that does not support this specification, then the chain of 6LoRH headers must be stripped by the RPL/6LR router to which the leaf is attached. In that example, the destination IP address of the IP-in-IP header cannot be elided.
パケットの最終的な宛先がこの仕様をサポートしないリーフである場合、6LoRHヘッダーのチェーンは、リーフが接続されているRPL / 6LRルーターによって削除される必要があります。その例では、IP-in-IPヘッダーの宛先IPアドレスを省略できません。
In the special case where a 6LoRH header is used to route 6LoWPAN fragments, the destination address is not accessible in the LOWPAN_IPHC on all fragments and can be elided only for the first fragment and for packets going upwards.
6LoRHヘッダーを使用して6LoWPANフラグメントをルーティングする特殊なケースでは、宛先アドレスはすべてのフラグメントのLOWPAN_IPHCでアクセスできず、最初のフラグメントとそれ以上のパケットに対してのみ除外できます。
Though it is possible to decompress a packet at any hop, this specification is optimized to enable that a packet is forwarded in its compressed form all the way, and it makes sense to deploy homogeneous networks where all nodes, or no nodes at all, use the compression technique detailed therein.
パケットを任意のホップで解凍することは可能ですが、この仕様は、パケットが圧縮された形式で転送されるように最適化されており、すべてのノードを使用する、またはノードをまったく使用しない同種ネットワークを展開することは理にかなっていますそこに詳述されている圧縮技術。
This specification aims at a simple implementation running in constrained nodes, so it does indeed expect a homogeneous network and, as a consequence, it does not provide a method to determine the level of support by the next hops at forwarding time.
この仕様は、制約されたノードで実行される単純な実装を目的としているため、確かに同種のネットワークを想定しているため、転送時にネクストホップによるサポートのレベルを決定する方法は提供していません。
Should an extension to this specification provide such a method, forwarding nodes could compress or decompress the RPL artifacts appropriately and enable a backward compatibility between nodes that support this specification and nodes that do not.
この仕様の拡張がこのような方法を提供する場合、転送ノードはRPLアーティファクトを適切に圧縮または解凍し、この仕様をサポートするノードとサポートしないノード間の下位互換性を有効にすることができます。
It results that this specification does not attempt to enable such backwards compatibility. It does not require extraneous code to exchange and handle error messages to automatically correct mismatch situations either.
その結果、この仕様では、このような下位互換性を有効にしようとはしていません。エラーメッセージを交換して処理し、不一致の状況を自動的に修正するために、無関係なコードを必要としません。
When a packet is expected to carry a 6LoRH header but does not, the node that discovers the issue is expected to send an ICMPv6 error message to the root. It should be sent at an adapted rate-limitation and with a type 4 (indicating a "Parameter Problem") and a code 0 (indicating an "Unrecognized Next Header field encountered"). The relevant portion of the received packet should be embedded and the offset therein where the 6LoRH header was expected should be pointed out.
パケットが6LoRHヘッダーを運ぶことが期待されているがそうではない場合、問題を発見したノードは、ICMPv6エラーメッセージをルートに送信することが期待されています。これは、適応されたレート制限で、タイプ4（「パラメーターの問題」を示す）およびコード0（「認識されない次のヘッダーフィールドが検出された」を示す）で送信する必要があります。受信したパケットの関連部分を埋め込んで、6LoRHヘッダーが予期されていたオフセットを指摘する必要があります。
When a packet is received with a 6LoRH header that is not recognized, the node that discovers the issue is expected to send an ICMPv6 error message to the root. It should be sent at an adapted rate-limitation and with a type 4 (indicating a "Parameter Problem") and a code 1 (indicating an "Unrecognized Next Header type encountered"). The relevant portion of the received packet should be embedded and the offset therein where the 6LoRH header was expected should be pointed out.
認識されない6LoRHヘッダーを含むパケットを受信すると、問題を発見したノードは、ICMPv6エラーメッセージをルートに送信することが期待されます。これは、適応されたレート制限で、タイプ4（「パラメーターの問題」を示す）およびコード1（「認識されない次のヘッダータイプが検出された」を示す）で送信する必要があります。受信したパケットの関連部分を埋め込んで、6LoRHヘッダーが予期されていたオフセットを指摘する必要があります。
In both cases, the node SHOULD NOT place a 6LoRH header as defined in this specification in the resulting message, and the node should either omit the RPI or place it uncompressed after the IPv6 header.
どちらの場合も、ノードは、この仕様で定義されている6LoRHヘッダーを結果のメッセージに配置するべきではなく（SHOULD NOT）、ノードはRPIを省略するか、IPv6ヘッダーの後に非圧縮で配置する必要があります。
Additionally, in both cases, an alternate management method may be preferred in order to notify the network administrator that there is a configuration error.
さらに、どちらの場合も、構成エラーがあることをネットワーク管理者に通知するために、別の管理方法が推奨される場合があります。
Keeping the network homogeneous is either a deployment issue, by deploying only devices with a same capability, or a management issue, by configuring all devices to either use or not use a certain level of this compression technique and its future additions.
ネットワークを均一に保つことは、同じ機能を持つデバイスのみを展開することによる展開の問題、または特定のレベルのこの圧縮技術とその将来の追加を使用するか使用しないようにすべてのデバイスを構成することによる管理の問題のいずれかです。
In particular, the situation where a node receives a message with a Critical 6LoWPAN Routing Header that it does not understand is an administrative error whereby the wrong device is placed in a network, or the device is misconfigured.
特に、ノードが理解できないクリティカル6LoWPANルーティングヘッダーを含むメッセージを受信する状況は、誤ったデバイスがネットワークに配置されているか、デバイスが正しく構成されていないという管理上のエラーです。
When a mismatch situation is detected, it is expected that the device raises some management alert indicating the issue, e.g., that it has to drop a packet with a Critical 6LoRH.
不一致の状況が検出された場合、デバイスは問題を示す何らかの管理アラートを生成することが予想されます。たとえば、Critical 6LoRHのパケットをドロップする必要があるなどです。
The security considerations of RFC 4944 [RFC4944], RFC 6282 [RFC6282], and RFC 6553 [RFC6553] apply.
RFC 4944 [RFC4944]、RFC 6282 [RFC6282]、およびRFC 6553 [RFC6553]のセキュリティに関する考慮事項が適用されます。
Using a compressed format as opposed to the full in-line format is logically equivalent and is believed not to create an opening for a new threat when compared to RFC 6550 [RFC6550], RFC 6553 [RFC6553], and RFC 6554 [RFC6554], noting that, even though intermediate hops are removed from the SRH header as they are consumed, a node may still identify that the rest of the source-routed path includes a loop or not (see the "Security" section of RFC 6554). It must be noted that if the attacker is not part of the loop, then there is always a node at the beginning of the loop that can detect it and remove it.
完全なインライン形式とは対照的に圧縮形式を使用することは論理的には同等であり、RFC 6550 [RFC6550]、RFC 6553 [RFC6553]、およびRFC 6554 [RFC6554]と比較した場合、新しい脅威の切り口とはならないと考えられています。中間ホップが消費されるときにSRHヘッダーから削除されても、ノードは、ソースルートパスの残りにループが含まれているかどうかを識別できます（RFC 6554の「セキュリティ」セクションを参照）。攻撃者がループの一部ではない場合、ループの最初に常にそれを検出して削除できるノードがあることに注意する必要があります。
This specification reserves Dispatch Value Bit Patterns within the 6LoWPAN Dispatch Page 1 as follows:
この仕様では、6LoWPANディスパッチページ1内のディスパッチ値ビットパターンを次のように予約しています。
10 1xxxxx: for Elective 6LoWPAN Routing Headers
10 1xxxxx：選択的6LoWPANルーティングヘッダー用
10 0xxxxx: for Critical 6LoWPAN Routing Headers
10 0xxxxx：重要な6LoWPANルーティングヘッダー用
Additionally, this document creates two IANA registries: one for the Critical 6LoWPAN Routing Header Type and one for the Elective 6LoWPAN Routing Header Type, each with 256 possible values, from 0 to 255, as described below.
さらに、このドキュメントは2つのIANAレジストリを作成します。1つはクリティカル6LoWPANルーティングヘッダータイプ用で、もう1つは選択的6LoWPANルーティングヘッダータイプ用で、以下で説明するように、それぞれ0〜255の256の可能な値があります。
Future assignments are made by IANA using the "RFC Required" procedure [RFC5226].
将来の割り当ては、「RFC必須」の手順[RFC5226]を使用してIANAによって行われます。
This document creates an IANA registry titled "Critical 6LoWPAN Routing Header Type" and assigns the following values:
このドキュメントは、「Critical 6LoWPAN Routing Header Type」というタイトルのIANAレジストリを作成し、次の値を割り当てます。
0-4: SRH-6LoRH [RFC8138]
0-4：SRH-6LoRH [RFC8138]
5: RPI-6LoRH [RFC8138]
5：RPI-6LoRH [RFC8138]
This document creates an IANA registry titled "Elective 6LoWPAN Routing Header Type" and assigns the following value:
このドキュメントは、「Elective 6LoWPAN Routing Header Type」というタイトルのIANAレジストリを作成し、次の値を割り当てます。
6: IP-in-IP-6LoRH [RFC8138]
6：IP-in-IP-6LoRH [RFC8138]
[IEEE.802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, <http://ieeexplore.ieee.org/document/7460875/>.
[IEEE.802.15.4] IEEE、「低速無線ネットワークのIEEE規格」、IEEE 802.15.4-2015、DOI 10.1109 / IEEESTD.2016.7460875、<http://ieeexplore.ieee.org/document/7460875/> 。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、DOI 10.17487 / RFC4443、3月2006、<http://www.rfc-editor.org/info/rfc4443>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]ホイ、J。、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T。、編、Thubert、P。、編、Brandt、A。、ホイ、J。、ケルシー、R。、リーバイス、P。、ピスター、K。、ストルーク、R。、ヴァッサー、JP、およびR.アレクサンダー、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<http://www.rfc-editor.org/info/ rfc6550>。
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, <http://www.rfc-editor.org/info/rfc6552>.
[RFC6552] Thubert、P。、編、「低電力および損失の多いネットワーク（RPL）のルーティングプロトコルの目的関数ゼロ」、RFC 6552、DOI 10.17487 / RFC6552、2012年3月、<http：//www.rfc -editor.org/info/rfc6552>。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, <http://www.rfc-editor.org/info/rfc6553>.
[RFC6553] Hui、J.、JP。 Vasseur、「データプレーンデータグラムでRPL情報を伝送するための低電力および損失の多いネットワーク（RPL）オプションのルーティングプロトコル」、RFC 6553、DOI 10.17487 / RFC6553、2012年3月、<http：//www.rfc-editor。 org / info / rfc6553>。
[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, DOI 10.17487/RFC6554, March 2012, <http://www.rfc-editor.org/info/rfc6554>.
[RFC6554] Hui、J.、Vasseur、JP。、Culler、D.、and V. Manral、 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Routing-Power and Lossy Networks（RPL）"、RFC 6554、 DOI 10.17487 / RFC6554、2012年3月、<http://www.rfc-editor.org/info/rfc6554>。
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <http://www.rfc-editor.org/info/rfc8025>.
[RFC8025] Thubert、P.、Ed。およびR. Cragie、「IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Paging Dispatch」、RFC 8025、DOI 10.17487 / RFC8025、2016年11月、<http://www.rfc-editor.org/info/rfc8025> 。
[FORWARD-FRAG] Thubert, P., Ed. and J. Hui, "LLN Fragment Forwarding and Recovery", Work in Progress, draft-thubert-6lo-forwarding-fragments-05, April 2017.
[FORWARD-FRAG]チューバート、P。、エド。およびJ. Hui、「LLN Fragment Forwarding and Recovery」、Work in Progress、draft-thubert-6lo-forwarding-fragments-05、2017年4月。
[IPv6-ARCH] Thubert, P., Ed., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-11, January 2017.
[IPv6-ARCH] Thubert、P。、編、「IEEE 802.15.4のTSCHモードを介したIPv6のアーキテクチャ」、作業中、draft-ietf-6tisch-architecture-11、2017年1月。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]シェルビー、Z。、編、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「ローパワーワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年11月、<http://www.rfc-editor.org/info/rfc6775>。
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7102] Vasseur、JP。、「低電力および損失の多いネットワークのルーティングに使用される用語」、RFC 7102、DOI 10.17487 / RFC7102、2014年1月、<http://www.rfc-editor.org/info/rfc7102> 。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <http://www.rfc-editor.org/info/rfc7554>.
[RFC7554] Watteyne、T。、編、Palattella、M。、およびL. Grieco、「モノのインターネット（IoT）でのIEEE 802.15.4eタイムスロットチャネルホッピング（TSCH）の使用：問題ステートメント」、RFC 7554 、DOI 10.17487 / RFC7554、2015年5月、<http://www.rfc-editor.org/info/rfc7554>。
[RPL-INFO] Robles, M., Richardson, M., and P. Thubert, "When to use RFC 6553, 6554 and IPv6-in-IPv6", Work in Progress, draft-ietf-roll-useofrplinfo-14, April 2017.
[RPL-INFO] Robles、M.、Richardson、M。、およびP. Thubert、「RFC 6553、6554およびIPv6-in-IPv6を使用する場合」、Work in Progress、draft-ietf-roll-useofrplinfo-14、 2017年4月。
The example in Figure 15 illustrates the 6LoRH compression of a classical packet in Storing mode in all directions, as well as in Non-Storing mode for a packet going up the DODAG following the default route to the root. In this particular example, a fragmentation process takes place per RFC 4944 [RFC4944], and the fragment headers must be placed in Page 0 before switching to Page 1:
図15の例は、すべての方向の格納モードでの従来のパケットの6LoRH圧縮と、ルートへのデフォルトルートに従ってDODAGを上るパケットの非格納モードを示しています。この特定の例では、断片化プロセスはRFC 4944 [RFC4944]に従って行われ、フラグメントヘッダーはページ1に切り替える前にページ0に配置する必要があります。
+- ... -+- ... -+-+ ... -+- ... +-+-+ ... -+-+-+-+-+-+-+-+-+-+...
|Frag type|Frag hdr |11110001| RPI- |IP-in-IP| LOWPAN_IPHC | ...
|RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | |
+- ... -+- ... -+-+ ... -+- ... +-+-+ ... -+-+-+-+-+-+-+-+-+-+...
<- RFC 6282 ->
No RPL artifact
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
|Frag type|Frag hdr |
|RFC 4944 |RFC 4944 | Payload (cont)
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
|Frag type|Frag hdr |
|RFC 4944 |RFC 4944 | Payload (cont)
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
Figure 15: Example Compressed Packet with RPI
図15：RPIを使用した圧縮パケットの例
In Storing mode, if the packet stays within the RPL domain, then it is possible to save the IP-in-IP encapsulation, in which case, only the RPI is compressed with a 6LoRH, as illustrated in Figure 16 in the case of a non-fragmented ICMP packet:
Storingモードでは、パケットがRPLドメイン内に留まる場合、IP-in-IPカプセル化を保存できます。その場合、RPIのみが6LoRHで圧縮されます（図16の場合）。断片化されていないICMPパケット：
+- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
|11110001| RPI-6LoRH | NH = 0 | NH = 58 | ICMP message ...
|Page 1 | Type 5 | 6LOWPAN_IPHC | (ICMP) | (no compression)
+- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
<- RFC 6282 ->
No RPL artifact
Figure 16: Example ICMP Packet with RPI in Storing Mode
図16：保管モードのRPIを使用したICMPパケットの例
The format in Figure 16 is logically equivalent to the uncompressed format illustrated in Figure 17:
図16の形式は、図17に示す非圧縮形式と論理的に同等です。
+-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| IPv6 Header | Hop-by-Hop | RPI in | ICMP message ...
| NH = 58 | Header | RPL Option |
+-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 17: Uncompressed ICMP Packet with RPI
図17：RPIを使用した非圧縮ICMPパケット
For a UDP packet, the transport header can be compressed with 6LoWPAN HC [RFC6282] as illustrated in Figure 18:
UDPパケットの場合、図18に示すように、トランスポートヘッダーを6LoWPAN HC [RFC6282]で圧縮できます。
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
|11110001| RPI- | NH=1 |11110CPP| Compressed | UDP
|Page 1 | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payload
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
<- RFC 6282 ->
No RPL artifact
Figure 18: Uncompressed ICMP Packet with RPI
図18：RPIを使用した非圧縮ICMPパケット
If the packet is received from the Internet in Storing mode, then the root is supposed to encapsulate the packet to insert the RPI. The resulting format would be as represented in Figure 19:
パケットがStoringモードでインターネットから受信された場合、ルートはRPIを挿入するためにパケットをカプセル化することになっています。結果のフォーマットは、図19のようになります。
+-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...
|11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP
|Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld
+-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...
<- RFC 6282 ->
No RPL artifact
Figure 19: RPI Inserted by the Root in Storing Mode
図19：保管モードでルートによって挿入されたRPI
The example illustrated in Figure 20 is a classical packet in Non-Storing mode for a packet going down the DODAG following a source-routed path from the root. Say that we have four forwarding hops to reach a destination. In the uncompressed form, when the root generates the packet, the last 3 hops are encoded in a Routing Header Type 3 (SRH) and the first hop is the destination of the packet. The intermediate hops perform a swap; the hop count indicates the current active hop as defined in RFC 2460 [RFC2460] and RFC 6554 [RFC6554].
図20に示す例は、ルートからのソースルートパスに続いてDODAGを下るパケットの非保存モードの従来のパケットです。宛先に到達するために4つの転送ホップがあるとします。非圧縮形式では、ルートがパケットを生成すると、最後の3つのホップがルーティングヘッダータイプ3（SRH）にエンコードされ、最初のホップがパケットの宛先になります。中間ホップはスワップを実行します。ホップカウントは、RFC 2460 [RFC2460]およびRFC 6554 [RFC6554]で定義されている現在のアクティブホップを示します。
When compressed with this specification, the 4 hops are encoded in SRH-6LoRH when the root generates the packet, and the final destination is left in the LOWPAN_IPHC. There is no swap; the forwarding node that corresponds to the first entry effectively consumes it when forwarding, which means that the size of the encoded packet decreases and that the hop information is lost.
この仕様で圧縮すると、ルートがパケットを生成するときに4ホップがSRH-6LoRHでエンコードされ、最終宛先がLOWPAN_IPHCに残ります。スワップはありません。最初のエントリに対応する転送ノードは、転送時にそれを効果的に消費します。つまり、エンコードされたパケットのサイズが減少し、ホップ情報が失われます。
If the last hop in an SRH-6LoRH is not the final destination, then it removes the SRH-6LoRH before forwarding.
SRH-6LoRHの最後のホップが最終宛先ではない場合、転送する前にSRH-6LoRHを削除します。
In the particular example illustrated in Figure 20, all addresses in the DODAG are assigned from the same /112 prefix and the last 2 octets encoding an identifier such as an IEEE 802.15.4 short address. In that case, all addresses can be compressed to 2 octets, using the root address as reference. There will be one SRH_6LoRH header with, in this example, three compressed addresses:
図20に示す特定の例では、DODAG内のすべてのアドレスは、同じ/ 112プレフィックスと、IEEE 802.15.4ショートアドレスなどの識別子をエンコードする最後の2オクテットから割り当てられます。その場合、ルートアドレスを参照として使用して、すべてのアドレスを2オクテットに圧縮できます。この例では、3つの圧縮されたアドレスを持つ1つのSRH_6LoRHヘッダーがあります。
+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-8bytes-> <- RFC 6282 ->
No RPL artifact
Figure 20: Example Compressed Packet with SRH
図20：SRHを使用した圧縮パケットの例
One may note that the RPI is provided. This is because the address of the root that is the source of the IP-in-IP header is elided and inferred from the RPLInstanceID in the RPI. Once found from a local context, that address is used as a Compression Reference to expand addresses in the SRH-6LoRH.
RPIが提供されていることに注意してください。これは、IP-in-IPヘッダーのソースであるルートのアドレスが省略され、RPIのRPLInstanceIDから推測されるためです。ローカルコンテキストから見つかると、そのアドレスは圧縮参照として使用され、SRH-6LoRHのアドレスを展開します。
With the RPL specifications available at the time of writing, the root is the only node that may incorporate an SRH in an IP packet. When the root forwards a packet that it did not generate, it has to encapsulate the packet with IP-in-IP.
執筆時点で利用可能なRPL仕様では、ルートはSRHをIPパケットに組み込むことができる唯一のノードです。ルートが生成しなかったパケットを転送するとき、ルートはIP-in-IPでパケットをカプセル化する必要があります。
But, if the root generates the packet towards a node in its DODAG, then it should avoid the extra IP-in-IP as illustrated in Figure 21:
ただし、ルートがそのDODAGのノードに向けてパケットを生成する場合、図21に示すように、余分なIP-in-IPを回避する必要があります。
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
|11110001| SRH-6LoRH | NH=1 | 11110CPP | Compressed | UDP
|Page 1 | Type1 S=3 | LOWPAN_IPHC| LOWPAN-NHC| UDP header | Payload
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
<- RFC 6282 ->
Figure 21: Compressed SRH 4*2bytes Entries Sourced by Root
図21：ルートをソースとする圧縮されたSRH 4 * 2bytesエントリ
Note: The RPI is not represented, though RPL [RFC6550] generally expects it. In this particular case, since the Compression Reference for the SRH-6LoRH is the source address in the LOWPAN_IPHC, and the routing is strict along the source route path, the RPI does not appear to be absolutely necessary.
注：RPI [RFC6550]は一般的にRPIがそれを期待しているが、RPIは表されていません。この特定のケースでは、SRH-6LoRHの圧縮参照はLOWPAN_IPHCのソースアドレスであり、ルーティングはソースルートパスに沿って厳密であるため、RPIは絶対に必要であるようには見えません。
In Figure 21, all the nodes along the source route path share the same /112 prefix. This is typical of IPv6 addresses derived from an IEEE802.15.4 short address, as long as all the nodes share the same PAN-ID. In that case, a Type 1 SRH-6LoRH header can be used for encoding. The IPv6 address of the root is taken as reference, and only the last 2 octets of the address of the intermediate hops are encoded. The Size of 3 indicates 4 hops, resulting in an SRH-6LoRH of 10 bytes.
図21では、ソースルートパスに沿ったすべてのノードが同じ/ 112プレフィックスを共有しています。これは、すべてのノードが同じPAN-IDを共有している限り、IEEE802.15.4ショートアドレスから派生した典型的なIPv6アドレスです。その場合、Type 1 SRH-6LoRHヘッダーをエンコードに使用できます。ルートのIPv6アドレスが参照として使用され、中間ホップのアドレスの最後の2オクテットのみがエンコードされます。サイズ3は4ホップを示し、SRH-6LoRHは10バイトになります。
This section illustrates the operation specified in Section 5.6 of forwarding a packet with a compressed SRH along an A->B->C->D source route path. The operation of popping addresses is exemplified at each hop.
このセクションでは、セクション5.6で指定されている、圧縮されたSRHを使用してパケットをA-> B-> C-> Dソースルートパスに沿って転送する操作について説明します。アドレスをポップする操作は、各ホップで例示されています。
Packet as received by node A
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA AAAA
Type 1 SRH-6LoRH Size = 0 BBBB
Type 2 SRH-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 1: Popping BBBB, the first entry of the next SRH-6LoRH Step 2: If larger value (2 vs. 1), the SRH-6LoRH is removed
ステップ1：次のSRH-6LoRHの最初のエントリーであるBBBBのポップステップ2：値が大きい場合（2対1）、SRH-6LoRHは削除されます
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA AAAA Type 2 SRH-6LoRH Size = 1 CCCC CCCC DDDD DDDD
タイプ3 SRH-6LoRHサイズ= 0 AAAA AAAA AAAA AAAAタイプ2 SRH-6LoRHサイズ= 1 CCCC CCCC DDDD DDDD
Step 3: Recursion ended; coalescing BBBB with the first entry Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB
ステップ3：再帰が終了しました。最初のエントリタイプ3 SRH-6LoRHとBBBBを合体サイズ= 0 AAAA AAAA AAAA BBBB
Step 4: Routing based on next segment endpoint to B
手順4：Bへの次のセグメントエンドポイントに基づくルーティング
Figure 22: Processing at Node A
図22：ノードAでの処理
Packet as received by node B
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB
Type 2 SRH-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 1: Popping CCCC CCCC, the first entry of the next SRH-6LoRH Step 2: Removing the first entry and decrementing the Size (by 1)
ステップ1：次のSRH-6LoRHの最初のエントリーであるCCCC CCCCのポップステップ2：最初のエントリーの削除とサイズの減少（1）
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB Type 2 SRH-6LoRH Size = 0 DDDD DDDD
タイプ3 SRH-6LoRHサイズ= 0 AAAA AAAA AAAA BBBBタイプ2 SRH-6LoRHサイズ= 0 DDDD DDDD
Step 3: Recursion ended; coalescing CCCC CCCC with the first entry Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC
ステップ3：再帰が終了しました。 CCCC CCCCと最初のエントリType 3 SRH-6LoRH Size = 0を合体させたAAAA AAAA CCCC CCCC
Step 4: Routing based on next segment endpoint to C
ステップ4：Cへの次のセグメントエンドポイントに基づくルーティング
Figure 23: Processing at Node B
図23：ノードBでの処理
Packet as received by node C
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC Type 2 SRH-6LoRH Size = 0 DDDD DDDD
タイプ3 SRH-6LoRHサイズ= 0 AAAA AAAA CCCC CCCCタイプ2 SRH-6LoRHサイズ= 0 DDDD DDDD
Step 1: Popping DDDD DDDD, the first entry of the next SRH-6LoRH Step 2: The SRH-6LoRH is removed
ステップ1：DDDDをポップするDDDD、次のSRH-6LoRHの最初のエントリーステップ2：SRH-6LoRHが削除されます
Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC
Tipe2sarh-2 lorah cz = 0 aaaa aaaa ccccc ccccc
Step 3: Recursion ended; coalescing DDDD DDDDD with the first entry Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD
ステップ3：再帰が終了しました。 DDDD DDDDDと最初のエントリを組み合わせたタイプ3 SRH-6LoRHサイズ= 0 AAAA AAAA DDDD DDDD
Step 4: Routing based on next segment endpoint to D
ステップ4：Dへの次のセグメントエンドポイントに基づくルーティング
Figure 24: Processing at Node C
図24：ノードCでの処理
Packet as received by node D
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD
Step 1: The SRH-6LoRH is removed Step 2: No more header; routing based on inner IP header
ステップ1：SRH-6LoRHが削除されます。ステップ2：ヘッダーがなくなります。内部IPヘッダーに基づくルーティング
Figure 25: Processing at Node D
図25：ノードDでの処理
Acknowledgements
謝辞
The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel Montenegro, and Ralph Droms for constructive reviews to the design in the 6lo working group. The overall discussion involved participants to the 6MAN, 6TiSCH, and ROLL WGs; thank you all. Special thanks to Michael Richardson and Ines Robles (the Chairs of the ROLL WG), Brian Haberman (the Internet Area AD), and Alvaro Retana and Adrian Farrel (Routing Area ADs) for driving this complex effort across working groups and areas.
著者は、6loワーキンググループの設計に対する建設的なレビューを提供してくれたTom Phinney、Thomas Watteyne、Tengfei Chang、Martin Turon、James Woodyatt、Samita Chakrabarti、Jonathan Hui、Ralph Dromsに感謝します。全体的な議論には、6MAN、6TiSCH、およびROLL WGの参加者が含まれていました。皆さん、ありがとうございました。マイケルリチャードソンとイネスロブルス（ROLL WGの議長）、ブライアンハーバーマン（インターネットエリアAD）、アルバロレタナとエイドリアンファレル（ルーティングエリアAD）に、ワーキンググループとエリア全体でこの複雑な取り組みを推進してくれたことに感謝します。
Authors' Addresses
著者のアドレス
Pascal Thubert (editor) Cisco Systems Building D - Regus 45 Allee des Ormes BP1200 MOUGINS - Sophia Antipolis 06254 France
Pascal Thubert（編集者）Cisco Systems Building D-Regus 45 Allee des Ormes BP1200 MOUGINS-Sophia Antipolis 06254 France
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Carsten Bormann Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org
Laurent Toutain IMT Atlantique 2 rue de la Chataigneraie CS 17607 Cesson-Sevigne Cedex 35576 France
Laurent Toutain IMT Atlantique 2 rue de la Chataigneraie CS 17607セッソンセビニェセデックス35576フランス
Email: Laurent.Toutain@IMT-Atlantique.fr
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJイギリス
Email: robert.cragie@arm.com