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
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
低功耗无线个人区域网（6LoWPAN）上的IPv6路由头
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.
本规范介绍了一种新的IPv6 over Low Power Wireless Personal Area Network（6LoWPAN）调度类型，用于6LoWPAN over Topology路由，该类型最初涵盖了低功耗和有损网络（RPL）数据包压缩（RFC 6550）的路由协议需求。使用此分派类型，本规范定义了一种压缩RPL选项（RFC 6553）信息和路由头类型3（RFC 6554）的方法，这是一种高效的IP-in-IP技术，可扩展用于更多应用程序。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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].
控制数据传输量是节约能源的一个可能途径。在许多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错误发送回源的能力等原因（请参阅“Internet协议版本6（IPv6）规范的Internet控制消息协议（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]详细说明了在运行RPL的LLN环境中从数据包中插入或删除RPL选项中定义的用于在数据平面数据报[RFC6553]中承载RPL信息的IPv6头、带有RPL的源路由的头[RFC6554]和IPv6-in-IPv6封装的不同情况。
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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要求在每个数据包中添加RPL数据包信息（RPI），如RFC 6550[RFC6550]第11.2节所定义。
"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
此表示总共需要8个字节，而在大多数情况下，实际RPI负载只需要19位。由于逐跳标头不能流到RPL域之外，因此必须插入它
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.
在进入域的数据包中，可以从离开域的数据包中删除。在这两种情况下，此操作都意味着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
------+--------- ^
| 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.
对于非存储RPL，即使源是同一LLN中的节点，数据包也必须首先到达图的根，以便根可以插入SRH以进入图。以任何方式，无论包是起源于LLN中的节点还是在LLN之外，并且无论包是否留在LLN内，只要包的源不是根本身，源路由操作也意味着在根处进行IP-In-IP封装以插入SRH。
"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]指定了基于“在物联网（IoT）中使用IEEE 802.15.4e时隙信道跳频（TSCH）：问题陈述”[RFC7554]中描述的操作模式的IPv6操作。该体系结构要求在IEEE 802.15.4上同时使用RPL和6lo适配层。由于6TiSCH继承了MAC层对帧大小的限制，因此6TiSCH无法在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.
本规范扩展了6lo适配层框架（[RFC4944][RFC6282]），以承载基于RPL的网络路由的路由信息。它包括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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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".
术语“byte”在现在的习惯意义上被用作“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）寻呼调度”[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.
本规范介绍了一种新的6LoWPAN路由头（6LoRH），用于承载IPv6路由信息。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数据包中表示为类型长度值（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.
当存在6LoRH时，不识别第4节详述的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.
本规范使用第1页中的位模式10xxxxxx进行新6LoRH调度。第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编码的报头不会修改使用LOWPAN_IPHC编码的数据包部分，无论是否存在IP-in-IP封装。例如，无论是否存在路由报头，数据包的最终目的地始终是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中的IP）或上层协议（ULP）报头终止的报头链。当从数据包中剥离一个外部头时，整个链都会随之移动。当中间路由器插入一个或多个报头时，该路由器通常会链接报头并将结果封装在IP中的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封装中有多个嵌套IP，则IP封装中的第一个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报头（例如，如果IP封装中没有IP）之后具有源路由或逐跳（HbH）选项报头[RFC2460]的数据包压缩形式中，这些报头以6LoRH形式放置在表示IPv6报头的6LOWPAN_IPHC之前（参见第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：
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.
对于每个表单，类型字段用于编码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的一种形式定义的类型值将来可能会为另一种形式重新定义。
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可能会被忽略和跳过。如果忽略此选项，则在LLN内转发6LoRHE时不会发生任何更改。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length -->
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.
长度：6字节的长度，以字节表示，不包括前2个字节。这使节点能够跳过它不支持和/或无法解析的6或标头，例如，如果类型无法识别。
Type: Type of the 6LoRHE
类型：6LoRHE的类型
The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx.
6LORCH使用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 -->
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的解释取决于后面的类型字段。例如，它可用于传输控制位、数组中的元素数或6LoRHC剩余部分的长度（以字节以外的单位表示）。
Type: Type of the 6LoRHC
类型：6LORCH的类型
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.
一个可能的引用是正在遍历的面向RPL目的地的有向无环图（DODAG）的根。6LoRH使用它作为参考，在IP-in-IP封装的情况下压缩外部IP报头。如果根是数据包的源，这种技术允许以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.
一旦确定了数据包的源地址，它就成为压缩地址的参考，这些地址位于压缩SRH报头中，这些压缩SRH报头以未压缩形式存在于IP-in-IP封装中。
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.
IPv6压缩地址通过用压缩地址覆盖参考地址最右边的N个字节与参考地址合并，其中N是压缩地址的长度，如图7中SRH-6LoRH头的类型所示。
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
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
CCCCCCC A compressed address, which may be shorter or the same as the reference
一个压缩地址，可以更短，也可以与引用相同
RRRRRRRRRRRRCCCCCCC A coalesced address, which may be the same compression as the reference
RRRRRRRRCCCCC合并地址，可能与引用相同的压缩
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上下文选项交换上下文。在数据包的压缩形式中，可以在上下文标识符扩展中用信号通知上下文。
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]，从DIO消息的DODAGID字段中可以知道DODAG根的地址。对于全局实例，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.
否则，封装数据包并使用此规范压缩数据包的路由器还必须按照RPL的规定在数据包中放置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实现需要维护一个抽象上下文表，该表由全局RPLInstanceID索引，该表提供该节点为特定RPL实例参与的DODAG根的地址。
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）为SRH提供压缩形式，如RFC 6554[RFC6554]中所定义，供RPL路由器使用。
One or more SRH-6LoRH header(s) MAY be placed in a 6LoWPAN packet.
一个或多个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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
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表示地址压缩为一个字节，而类型4表示地址在SRH-6LoRH中完整提供，无需压缩。SRH-6LoRH类型的完整列表和相应的压缩等级如图7所示：
+-----------+----------------------+
| 6LoRH | Length of compressed |
| Type | IPv6 address (bytes) |
+-----------+----------------------+
| 0 | 1 |
| 1 | 2 |
| 2 | 4 |
| 3 | 8 |
| 4 | 16 |
+-----------+----------------------+
+-----------+----------------------+
| 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意味着一个跃点，可以编码的最大值是32个跃点。（如果需要表示超过32个跃点，则可以使用一系列SRH-6LoRH元素。）结果是，SRH-6LoRH头的长度（以字节为单位）为：
2 + Length_of_compressed_IPv6_address * (Size + 1)
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.
在未压缩形式中，当root在非存储模式下生成或转发数据包时，它需要包括一个源路由头[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
除第一个跳外，沿路径的所有跳在SRH中按顺序编码。SRH中的最后一个条目是最终目的地；IPv6标头中的目标是沿源路由路径的第一个跃点。中间跃点执行交换
and the Segments Left field indicates the active entry in the Routing Header [RFC2460].
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.
使用本规范压缩时，所有剩余的跃点必须按顺序编码到一个或多个连续的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封装过程中承载整个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通常从MAC地址派生，以优化LOWPAN_IPHC压缩。
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的技术不同，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.
有了这个规范，数据包可以在任何一个跃点扩展为一个有效的IPv6数据包，包括SRH，并压缩回。但是，数据包在解压过程中不会携带以未压缩形式转发的数据包所拥有的所有消耗地址。
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规范中，将右转向是没有用的。
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.
对于重定向头选项（RHO），不鼓励（RFC 2460[RFC2460]）反转头，除非它经过身份验证，这需要身份验证头（AH）。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域通常由L2安全性保护，该安全性在每个跃点保护RPL本身和数据包中的RH。这比啊提供的安全性好。
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的根放入数据包中，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].
可通过配置获得参考地址。该配置可指示完整地址或承载地址[RFC6775]的6LoWPAN上下文标识符，例如，LOWPAN_IPHC[RFC6282]中使用的16个上下文标识符之一。
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封装中没有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的第一个条目中的地址是否是它自己的地址之一。如果是这种情况，路由器必须在转发之前使用该条目，这是从堆栈弹出的动作，其中堆栈实际上是连续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（表示收割台中只有一个条目），且此后没有后续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.
然后，路由器将压缩参考与第一个SRH-6LoRH报头的第一个条目合并，如第5.4节所述。如果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.
具体而言，senderrak是由专用目标函数（如RFC 6552[RFC6552]中所述）计算的标量度量，它指示发送方的秩，并在每个跃点处修改。SenderRak字段用于验证数据包是否沿着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]以传输RPI，该RPI在IPv6逐跳选项头[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个八位字节的两个额外八位字节。若要将头的范围仅限于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封装来携带逐跳报头。当插入逐跳报头的路由器不是数据包的源时，需要这样做，以便将错误返回到路由器。当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应该放在数据包中。在本规范中，RPI对于指示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位SenderRak。
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路由收割台，用于在6LoWPAN LLN中运输RPI。
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规范[RFC6550]第5节讨论了RPL实例。许多简单用例不需要多个RPL实例，在这种情况下，RPL实例应该是全局实例0。全局RPLInstanceID在RPLInstanceID字段中编码如下：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLInstanceID in 0..127
+-+-+-+-+-+-+-+-+
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操作的结果；此处，RPL规范[RFC6550]第3.5.1节将DAGRank操作定义为：
DAGRank(rank) = floor(rank/MinHopRankIncrease)
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的倍数，则senderrak的最低有效8位将全部为零；通过省略这些，senderrak可以压缩为单个字节。在RFC 6550[RFC6550]中，通过将默认的_MIN _-HOP _-RANK _-INCREASE定义为256，以及在RFC 6552[RFC6552]中，该思想被使用。RFC 6552[RFC6552]将默认的"MIN _-HOP _-RANK"INCREASE定义为默认的_-MIN _-HOP。
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.
该规范允许将senderrak编码为1或2个字节，并定义了一个K标志，当设置该标志时，该标志表示使用了单个字节。
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字段，除非该字段完全省略，然后是senderrak，它要么压缩为一个字节，要么完全以两个字节的形式排列。RPI-6LoRH标头中的I和K标志指示是否省略RPLINTanceID和/或压缩SenderRak。根据这些位的不同，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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
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标志：如果设置了该标志，则将SenderRak压缩为1个八位字节，并省略最低有效八位字节。如果未设置，SenderRak将作为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
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，但senderrak的两个字节都是有效的，因此无法压缩：
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
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
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：压缩senderrak
In Figure 13, the RPLInstanceID is not the Global RPLInstanceID 0, and both bytes of the SenderRank are significant:
在图13中，RPLInstanceID不是全局RPLInstanceID 0，senderrak的两个字节都是有效的：
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
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报头的长度以字节表示，必须至少为1，以表示在每个跃点处递减的跃点限制（HL）。当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.
当包的端点是与用于转发包的RPL实例相关联的RPL DODAG的根，并且根地址是隐式已知的，而不是在数据包中显式地发信号时，可以通过本规范实现IP-in-IP封装的最有效压缩。
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图中向上传输数据包的根地址；在存储模式下，它是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封装中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.
如果数据包的最终目的地是不支持此规范的叶，则叶所连接的RPL/6LR路由器必须剥离6LoRH头链。在该示例中，IP报头中的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报头，并且节点应省略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.
当检测到不匹配情况时，预计该设备会发出一些管理警报，指示问题，例如，它必须丢弃具有临界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.
此外，本文档还创建了两个IANA注册表：一个用于关键6LoWPAN路由标头类型，另一个用于可选6LoWPAN路由标头类型，每个注册表都有256个可能的值，从0到255，如下所述。
Future assignments are made by IANA using the "RFC Required" procedure [RFC5226].
IANA使用“RFC要求”程序[RFC5226]进行未来分配。
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:
本文档创建一个名为“可选6LoWPAN路由标头类型”的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]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，DOI 10.17487/RFC4443，2006年3月<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.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过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，“在RFCs中编写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]Hui，J.，Ed.和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.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“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.，Ed.“低功耗和有损网络路由协议（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.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，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，“低功率无线个人区域网（6LoWPAN）上的IPv6寻呼调度”，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]Thubert，P.，Ed.和J.Hui，“LLN碎片转发和恢复”，正在进行的工作，草稿-Thubert-6lo-Forwarding-fragments-052017年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.，Ed.“基于IEEE 802.15.4 TSCH模式的IPv6架构”，正在进行的工作，草稿-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]Shelby，Z.，Ed.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功率无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 6775，DOI 10.17487/RFC67752012年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.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<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.，Ed.，Palatella，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”，正在进行的工作，草稿-ietf-roll-UseofPRINFO-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压缩，以及在非存储模式下对沿着默认路径向上到达根的数据包进行6LoRH压缩。在此特定示例中，按照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 |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)
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
|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:
在存储模式下，如果数据包停留在RPL域内，则可以在IP封装中保存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
+- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
|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 |
+-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
+-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| 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数据包，可以使用6LoWPAN HC[RFC6282]压缩传输头，如图18所示：
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
|11110001| RPI- | NH=1 |11110CPP| Compressed | UDP
|Page 1 | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payload
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
<- RFC 6282 ->
No RPL artifact
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
|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:
如果数据包是以存储模式从Internet接收的，那么根用户应该封装数据包以插入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
+-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...
|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下行。假设我们有四个转发跃点到达目的地。在未压缩形式中，当根生成分组时，最后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个八位字节。在本例中，将有一个SRH6lorh标头，其中包含三个压缩地址：
+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|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
+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|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报头中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数据包中的节点。当root转发它没有生成的数据包时，它必须用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中的节点生成数据包，则应避免IP中的额外IP，如图21所示：
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
|11110001| SRH-6LoRH | NH=1 | 11110CPP | Compressed | UDP
|Page 1 | Type1 S=3 | LOWPAN_IPHC| LOWPAN-NHC| UDP header | Payload
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
<- RFC 6282 ->
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
|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*2字节条目
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.
注意：虽然RPL[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前缀。这是从IEEE802.15.4短地址派生的典型IPv6地址，只要所有节点共享相同的PAN-ID。在这种情况下，可以使用类型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节中指定的操作，即沿a->B->C->D源路由路径使用压缩SRH转发数据包。弹出地址的操作在每个跃点都有示例。
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
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：弹出BBBB，下一个SRH-6LoRH的第一个条目步骤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：递归结束；将BBBBBB与第一个入口类型3 SRH-6LoRH尺寸=0 AAAA AAAA BBBBBB合并
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
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：弹出CCCC CCCC，下一个SRH-6LoRH的第一个条目步骤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与第一入口类型3的CCCC SRH-6LoRH尺寸=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
----------------------------
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
类型3 SRH-6LoRH尺寸=0 AAAA AAAA CCCC CCCC
Step 3: Recursion ended; coalescing DDDD DDDDD with the first entry Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD
步骤3：递归结束；将DDDD与第一个入口类型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
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.
作者希望感谢Tom Phinney、Thomas Watteyne、Tengfei Chang、Martin Turon、James Woodyatt、Samita Chakrabarti、Jonathan Hui、Gabriel Montegon和Ralph Droms对6lo工作组设计的建设性审查。整个讨论涉及6MAN、6TiSCH和ROLL工作组的参与者；谢谢大家。特别感谢Michael Richardson和Ines Robles（滚动工作组主席）、Brian Haberman（互联网区域广告）、Alvaro Retana和Adrian Farrel（路由区域广告），他们在工作组和区域之间推动了这项复杂的工作。
Authors' Addresses
作者地址
Pascal Thubert (editor) Cisco Systems Building D - Regus 45 Allee des Ormes BP1200 MOUGINS - Sophia Antipolis 06254 France
Pascal Thubert（编辑）思科系统D大楼-雷格斯45 Allee des Ormes BP1200 MOUGINS-索菲亚安提波利斯06254法国
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63921
Email: cabo@tzi.org
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 Atlantice 2 rue de la Chataignarie CS 17607 Cedeson Sevigne Cedex 35576法国）
Email: Laurent.Toutain@IMT-Atlantique.fr
Email: Laurent.Toutain@IMT-Atlantique.fr
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Robert Cragie ARM Ltd.英国剑桥CB1 9NJ富尔伯恩路110号
Email: robert.cragie@arm.com
Email: robert.cragie@arm.com