Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6554 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 D. Culler
UC Berkeley
V. Manral
Hewlett Packard Co.
March 2012
Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6554 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 D. Culler
UC Berkeley
V. Manral
Hewlett Packard Co.
March 2012
An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
使用低功耗有损网络（RPL）路由协议的源路由的IPv6路由头
Abstract
摘要
In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain.
在低功耗和有损网络（LLN）中，路由器上的内存限制可能会限制它们最多只能维持几个路由。在某些配置中，有必要使用这些内存受限的路由器将数据报传送到LLN内的节点。低功耗和有损网络的路由协议（RPL）可在某些部署中用于将大部分（如果不是全部）路由存储在一个（例如，有向无环图（DAG）根）或几个路由器上，并使用源路由技术转发IPv6数据报，以避免内存受限路由器上的大型路由表。本文档指定了一种新的IPv6路由头类型，用于在RPL路由域内传递数据报。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6554.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6554.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Overview ........................................................3
3. Format of the RPL Routing Header ................................6
4. RPL Router Behavior .............................................8
4.1. Generating Source Routing Headers ..........................8
4.2. Processing Source Routing Headers ..........................9
5. Security Considerations ........................................11
5.1. Source Routing Attacks ....................................11
5.2. ICMPv6 Attacks ............................................12
6. IANA Considerations ............................................12
7. Acknowledgements ...............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Overview ........................................................3
3. Format of the RPL Routing Header ................................6
4. RPL Router Behavior .............................................8
4.1. Generating Source Routing Headers ..........................8
4.2. Processing Source Routing Headers ..........................9
5. Security Considerations ........................................11
5.1. Source Routing Attacks ....................................11
5.2. ICMPv6 Attacks ............................................12
6. IANA Considerations ............................................12
7. Acknowledgements ...............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
The Routing Protocol for Low-Power and Lossy Networks (RPL) is a distance vector IPv6 routing protocol designed for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are typically constrained in resources (limited communication data rate, processing power, energy capacity, memory). In particular, some LLN configurations may utilize LLN routers where memory constraints limit nodes to maintaining only a small number of default routes and no other destinations. However, it may be necessary to utilize such memory-constrained routers to forward datagrams and maintain reachability to destinations within the LLN.
低功耗有损网络路由协议（RPL）是一种为低功耗有损网络（LLN）设计的距离向量IPv6路由协议[RFC6550]。此类网络通常在资源方面受到限制（有限的通信数据速率、处理能力、能量容量、内存）。特别地，一些LLN配置可以利用LLN路由器，其中内存限制将节点限制为仅维护少量默认路由而不维护其他目的地。然而，可能需要利用这种内存受限的路由器来转发数据报并保持到LLN内的目的地的可达性。
To utilize paths that include memory-constrained routers, RPL relies on source routing. In one deployment model of RPL, more-capable routers collect routing information and form paths to arbitrary destinations within a RPL routing domain. However, a source routing mechanism supported by IPv6 is needed to deliver datagrams.
为了利用包含内存受限路由器的路径，RPL依赖于源路由。在RPL的一个部署模型中，更多功能路由器收集路由信息并形成到RPL路由域内任意目的地的路径。然而，需要IPv6支持的源路由机制来传递数据报。
This document specifies the Source Routing Header (SRH) for use strictly between RPL routers in the same RPL routing domain. A RPL routing domain is a collection of RPL routers under the control of a single administration. The boundaries of routing domains are defined by network management by setting some links to be exterior, or inter-domain, links.
本文档指定了源路由头（SRH），以便在同一RPL路由域中的RPL路由器之间严格使用。RPL路由域是由单一管理控制的RPL路由器的集合。网络管理通过将某些链路设置为外部或域间链路来定义路由域的边界。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The format of the SRH draws from that of the Type 0 Routing header (RH0) [RFC2460]. However, the SRH introduces mechanisms to compact the source route entries when all entries share the same prefix with the IPv6 Destination Address of a packet carrying an SRH, a typical scenario in LLNs using source routing. The compaction mechanism reduces consumption of scarce resources such as channel capacity.
SRH的格式取自类型0路由报头（RH0）[RFC2460]的格式。然而，当所有条目与承载SRH的数据包的IPv6目标地址共享相同前缀时，SRH引入了压缩源路由条目的机制，这是使用源路由的LLN中的典型场景。压缩机制减少了稀缺资源（如信道容量）的消耗。
The SRH also differs from RH0 in the processing rules to alleviate security concerns that led to the deprecation of RH0 [RFC5095]. First, RPL routers implement a strict source route policy where each and every IPv6 hop between the source and destination of the source route is specified within the SRH. Note that the source route may be a subset of the path between the actual source and destination and is discussed further below. Second, an SRH is only used between RPL routers within a RPL routing domain. RPL Border Routers, responsible for connecting other RPL routing domains and IP domains that use other routing protocols, do not allow datagrams already carrying an SRH header to enter or exit a RPL routing domain. Third, a RPL router drops datagrams that include multiple addresses assigned to any interfaces on that router to avoid forwarding loops.
SRH在处理规则方面也不同于RH0，以减轻导致RH0被弃用的安全问题[RFC5095]。首先，RPL路由器实施严格的源路由策略，其中源路由的源和目标之间的每个IPv6跃点都在SRH中指定。注意，源路由可以是实际源和目的地之间的路径的子集，下面将进一步讨论。第二，SRH仅在RPL路由域内的RPL路由器之间使用。RPL边界路由器负责连接其他RPL路由域和使用其他路由协议的IP域，不允许已经携带SRH头的数据报进入或退出RPL路由域。第三，RPL路由器丢弃包含分配给该路由器上任何接口的多个地址的数据报，以避免转发循环。
There are two cases that determine how to include an SRH when a RPL router requires the use of an SRH to deliver a datagram to its destination.
当RPL路由器需要使用SRH将数据报传送到其目的地时，有两种情况决定如何包括SRH。
1. If the SRH specifies the complete path from source to destination, the router places the SRH directly in the datagram itself.
1. 如果SRH指定了从源到目标的完整路径，路由器将SRH直接放在数据报本身中。
2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram.
2. 如果SRH仅指定从源到目标的路径子集，路由器将使用IPv6-in-IPv6隧道[RFC2473]并将SRH放置在外部IPv6报头中。隧道的使用确保了数据报未经修改的交付，并且ICMP错误返回到SRH源而不是原始数据报源。
In a RPL network, Case 1 occurs when both source and destination are within a RPL routing domain and a single SRH is used to specify the entire path from source to destination, as shown in the following figure:
在RPL网络中，当源和目标都位于RPL路由域内，并且使用单个SRH指定从源到目标的整个路径时，会出现情况1，如下图所示：
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
RPL Routing Domain
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
RPL Routing Domain
In the above scenario, datagrams traveling from source, S, to destination, D, have the following packet structure:
在上述场景中，从源S到目的地D的数据报具有以下分组结构：
+--------+---------+-------------//-+
| IPv6 | Source | IPv6 |
| Header | Routing | Payload |
| | Header | |
+--------+---------+-------------//-+
+--------+---------+-------------//-+
| IPv6 | Source | IPv6 |
| Header | Routing | Payload |
| | Header | |
+--------+---------+-------------//-+
S's address is carried in the IPv6 header's Source Address field.
的地址在IPv6标头的源地址字段中携带。
D's address is carried in the last entry of the SRH for all but the last hop, when D's address is carried in the IPv6 header's Destination Address field of the packet carrying the SRH.
当D的地址在承载SRH的数据包的IPv6报头的目的地地址字段中携带时，D的地址在除最后一个跃点之外的所有SRH的最后一个条目中携带。
In a RPL network, Case 2 occurs for all datagrams that have a source and/or destination outside the RPL routing domain, as shown in the following diagram:
在RPL网络中，对于源和/或目标位于RPL路由域之外的所有数据报，都会出现情况2，如下图所示：
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) ------------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) ------------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
In the scenarios above, R may indicate a RPL Border Router (when connecting to other routing domains) or a RPL Router (when connecting to hosts). The datagrams have the following structure when traveling within the RPL routing domain:
在上述场景中，R可能表示RPL边界路由器（连接到其他路由域时）或RPL路由器（连接到主机时）。在RPL路由域内传输时，数据报具有以下结构：
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
Note that the outer header (including the SRH) is added and removed by the RPL router.
请注意，外部标头（包括SRH）由RPL路由器添加和删除。
Case 2 also occurs whenever a RPL router needs to insert a source route when forwarding a datagram. One such use case with RPL is to have all RPL traffic flow through a Border Router and have the Border Router use source routes to deliver datagrams to their final destination. When including the SRH using tunneled mode, the Border Router would encapsulate the received datagram unmodified using IPv6- in-IPv6 and include an SRH in the outer IPv6 header.
当RPL路由器在转发数据报时需要插入源路由时，情况2也会发生。RPL的一个这样的用例是让所有RPL通信流通过边界路由器，并让边界路由器使用源路由将数据报传送到其最终目的地。当使用隧道模式包括SRH时，边界路由器将封装未使用IPv6-in-IPv6修改的接收数据报，并在外部IPv6报头中包括SRH。
+-----------------+
| |
| (S) -------\ |
| \ |
| (LBR)
| / |
| (D) <------/ |
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
| (S) -------\ |
| \ |
| (LBR)
| / |
| (D) <------/ |
| |
+-----------------+
RPL Routing Domain
In the above scenario, datagrams travel from S to D through the Low-Power and Lossy Network Border Router (LBR). Between S and the LBR, the datagrams are routed using the DAG built by the RPL and do not contain an SRH. The LBR encapsulates received datagrams unmodified using IPv6-in-IPv6 and the SRH is included in the outer IPv6 header.
在上述场景中，数据报通过低功耗有损网络边界路由器（LBR）从S传输到D。在S和LBR之间，数据报使用RPL构建的DAG进行路由，并且不包含SRH。LBR封装未使用IPv6-in-IPv6修改的接收数据报，SRH包含在外部IPv6报头中。
The Source Routing Header has the following format:
源路由标头具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv6 Next Header field [RFC2460].
下一个标题8位选择器。标识紧接路由标头之后的标头类型。使用与IPv6下一个标头字段[RFC2460]相同的值。
Hdr Ext Len 8-bit unsigned integer. Length of the Routing header in 8-octet units, not including the first 8 octets. Note that when Addresses[1..n] are compressed (i.e., value of CmprI or CmprE is not 0), Hdr Ext Len does not equal twice the number of Addresses.
Hdr Ext Len 8位无符号整数。路由头的长度，以8个八位字节为单位，不包括前8个八位字节。请注意，当压缩地址[1..n]时（即，CmprI或CmprE的值不为0），Hdr Ext Len不等于地址数的两倍。
Routing Type 8-bit selector. Identifies the particular Routing header variant. An SRH should set the Routing Type to 3.
路由类型8位选择器。标识特定路由标头变量。SRH应将路由类型设置为3。
Segments Left 8-bit unsigned integer. Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. The originator of an SRH sets this field to n, the number of addresses contained in Addresses[1..n].
段左8位无符号整数。剩余的路由段数，即在到达最终目的地之前仍要访问的明确列出的中间节点数。SRH的发起人将此字段设置为n，即地址[1..n]中包含的地址数。
CmprI 4-bit unsigned integer. Number of prefix octets from each segment, except than the last segment, (i.e., segments 1 through n-1) that are elided. For example, an SRH carrying full IPv6 addresses in Addresses[1..n-1] sets CmprI to 0.
CmprI 4位无符号整数。除最后一段（即，段1到n-1）外，每个段的前缀八位字节数被省略。例如，地址[1..n-1]中包含完整IPv6地址的SRH将CmprI设置为0。
CmprE 4-bit unsigned integer. Number of prefix octets from the last segment (i.e., segment n) that are elided. For example, an SRH carrying a full IPv6 address in Addresses[n] sets CmprE to 0.
CmprE 4位无符号整数。最后一段（即n段）中省略的前缀八位字节数。例如，地址[n]中包含完整IPv6地址的SRH将CmprE设置为0。
Pad 4-bit unsigned integer. Number of octets that are used for padding after Address[n] at the end of the SRH.
填充4位无符号整数。在SRH末尾的地址[n]之后用于填充的八位字节数。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Address[1..n] Vector of addresses, numbered 1 to n. Each vector element in [1..n-1] has size (16 - CmprI) and element [n] has size (16-CmprE). The originator of an SRH places the next (first) hop's IPv6 address in the IPv6 header's IPv6 Destination Address and the second hop's IPv6 address as the first address in Address[1..n] (i.e., Address[1]).
地址[1..n]地址向量，编号为1到n。[1..n-1]中的每个向量元素都有大小（16-CmprI），元素[n]有大小（16-CmprE）。SRH的发起人将下一（第一）跳的IPv6地址放在IPv6报头的IPv6目标地址中，将第二跳的IPv6地址作为地址[1..n]（即地址[1]）中的第一个地址。
The SRH shares the same basic format as the Type 0 Routing header [RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and Pad fields are set to 0 and the only difference between the SRH and Type 0 encodings is the value of the Routing Type field.
SRH与类型0路由头[RFC2460]共享相同的基本格式。承载完整IPv6地址时，CmprI、CmprE和Pad字段设置为0，SRH编码和类型0编码之间的唯一区别是路由类型字段的值。
A common network configuration for a RPL routing domain is that all routers within a RPL routing domain share a common prefix. The SRH introduces the CmprI, CmprE, and Pad fields to allow compaction of the Address[1..n] vector when all entries share the same prefix as
RPL路由域的常见网络配置是，RPL路由域中的所有路由器共享一个公共前缀。SRH引入了CmprI、CmprE和Pad字段，以便在所有条目共享相同的前缀时压缩地址[1..n]向量
the IPv6 Destination Address field of the packet carrying the SRH. The CmprI and CmprE fields indicate the number of prefix octets that are shared with the IPv6 Destination Address of the packet carrying the SRH. The shared prefix octets are not carried within the Routing header and each entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n] has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there may exist unused octets between the last entry, Address[n], and the end of the Routing header. The Pad field indicates the number of unused octets that are used for padding. Note that when CmprI and CmprE are both 0, Pad MUST carry a value of 0.
承载SRH的数据包的IPv6目标地址字段。CmprI和CmprE字段表示与承载SRH的数据包的IPv6目标地址共享的前缀八位字节数。共享前缀八位字节不在路由报头中携带，地址[1..n-1]中的每个条目都有大小（16-CmprI）八位字节，地址[n]有大小（16-CmprE）八位字节。当CmprI或CmprE为非零时，在最后一个条目地址[n]和路由报头末尾之间可能存在未使用的八位字节。Pad字段表示用于填充的未使用的八位字节数。请注意，当CmprI和CmprE都为0时，Pad必须携带值0。
The SRH MUST NOT specify a path that visits a node more than once. When generating an SRH, the source may not know the mapping between IPv6 addresses and nodes. Minimally, the source MUST ensure that IPv6 addresses do not appear more than once and the IPv6 Source and Destination addresses of the encapsulating datagram do not appear in the SRH.
SRH不得指定多次访问节点的路径。生成SRH时，源可能不知道IPv6地址和节点之间的映射。至少，源必须确保IPv6地址不会出现多次，并且封装数据报的IPv6源地址和目标地址不会出现在SRH中。
Multicast addresses MUST NOT appear in an SRH or in the IPv6 Destination Address field of a datagram carrying an SRH.
多播地址不得出现在SRH或承载SRH的数据报的IPv6目标地址字段中。
To deliver an IPv6 datagram to its destination, a router may need to generate a new SRH and specify a strict source route. When the router is the source of the original packet and the destination is known to be within the same RPL routing domain, the router SHOULD include the SRH directly within the original packet. Otherwise, the router MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the SRH in the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by an SRH are sent back to the router that generated the SRH.
为了将IPv6数据报传送到目的地，路由器可能需要生成新的SRH并指定严格的源路由。当路由器是原始数据包的源且已知目的地在同一RPL路由域内时，路由器应将SRH直接包含在原始数据包内。否则，路由器必须使用IPv6-in-IPv6隧道[RFC2473]并将SRH放置在隧道头中。使用IPv6-in-IPv6隧道可以确保传递的数据报保持不变，并且SRH生成的ICMPv6错误会发送回生成SRH的路由器。
When using IPv6-in-IPv6 tunneling, in order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to less than the original datagram's IPv6 Hop Limit value upon forwarding. In the case that the source route is longer than the original datagram's IPv6 Hop Limit, only the initial hops (determined by the original datagram's IPv6 Hop Limit) should be included in the SRH. If the RPL router is not the source of the original datagram, the original datagram's IPv6 Hop Limit field is decremented before generating the SRH. After generating the SRH, the RPL router decrements the original datagram's IPv6 Hop Limit value by the SRH Segments Left value. Processing the SRH Segments
使用IPv6-in-IPv6隧道时，为了遵守原始数据报的IPv6跃点限制值，生成SRH的RPL路由器必须在转发时将剩余的段设置为小于原始数据报的IPv6跃点限制值。如果源路由长于原始数据报的IPv6跃点限制，则SRH中只应包括初始跃点（由原始数据报的IPv6跃点限制确定）。如果RPL路由器不是原始数据报的源，则在生成SRH之前，原始数据报的IPv6跃点限制字段将递减。生成SRH后，RPL路由器将原始数据报的IPv6跃点限制值减去SRH段左值。处理SRH段
Left and original datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time Exceeded errors occur as would be expected on more traditional IPv6 networks that forward datagrams without tunneling.
左数据报和原始数据报的IPv6跃点限制字段以这种方式确保ICMPv6超出时间的错误发生，这在转发数据报而不进行隧道传输的更传统的IPv6网络上是可以预期的。
To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion (i.e., at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path length for a given RPL network. To take advantage of this, however, the communicating endpoints need to be aware of the MTU along the path (i.e., through Path MTU Discovery). Unfortunately, the larger MTU size may not be available on all links (e.g., 1280 octets on IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) links). However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU, so performance degradation through fragmentation would be limited.
为了避免碎片化，希望使用允许报头扩展的MTU大小（即，至少1280+40（外部IP报头）+SRH_MAX_大小），其中SRH_MAX_大小是给定RPL网络的最大路径长度。然而，为了利用这一点，通信端点需要知道路径上的MTU（即，通过路径MTU发现）。不幸的是，并非所有链路上都可以使用较大的MTU（例如，IPv6低功耗无线个人区域网络（6LoWPAN）链路上的1280个八位字节）。但是，预计这些类型的网络上的大部分流量包含的消息比MTU小得多，因此通过碎片化导致的性能下降将受到限制。
As specified in [RFC2460], a routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. In that node, dispatching on the Next Header field of the immediately preceding header causes the Routing header module to be invoked.
如[RFC2460]中所述，路由报头在到达IPv6报头的目标地址字段中标识的节点之前不会被检查或处理。在该节点中，在紧接前一个报头的下一个报头字段上进行调度将导致调用路由报头模块。
The function of the SRH is intended to be very similar to the Type 0 Routing header defined in [RFC2460]. After the routing header has been processed and the IPv6 datagram resubmitted to the IPv6 module for processing, the IPv6 Destination Address contains the next hop's address. When forwarding an IPv6 datagram that contains an SRH with a non-zero Segments Left value, if the IPv6 Destination Address is not on-link, a router MUST drop the datagram and SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to 7 to the packet's Source Address. This ICMPv6 Code indicates that the IPv6 Destination Address is not on-link and the router cannot satisfy the strict source route requirement. When generating ICMPv6 error messages, the rules in Section 2.4 of [RFC4443] MUST be observed.
SRH的功能与[RFC2460]中定义的0型路由报头非常相似。处理路由头并将IPv6数据报重新提交到IPv6模块进行处理后，IPv6目标地址包含下一个跃点的地址。转发包含非零剩余段值SRH的IPv6数据报时，如果IPv6目标地址不在链路上，路由器必须丢弃该数据报，并应向数据包的源地址发送ICMPv6代码设置为7的ICMP Destination Unreachable（ICMPv6 Type 1）消息。此ICMPv6代码表示IPv6目标地址不在链路上，路由器无法满足严格的源路由要求。生成ICMPv6错误消息时，必须遵守[RFC4443]第2.4节中的规则。
To detect loops in the SRH, a router MUST determine if the SRH includes multiple addresses assigned to any interface on that router. If such addresses appear more than once and are separated by at least one address not assigned to that router, the router MUST drop the packet and SHOULD send an ICMP Parameter Problem, Code 0, to the Source Address. While this loop check does add significant per-packet processing overhead, it is required to mitigate bandwidth exhaustion attacks that led to the deprecation of RH0 [RFC5095].
要检测SRH中的环路，路由器必须确定SRH是否包含分配给该路由器上任何接口的多个地址。如果这些地址出现不止一次，并且被至少一个未分配给该路由器的地址隔开，则路由器必须丢弃该数据包，并应向源地址发送ICMP参数问题代码0。虽然此循环检查确实增加了显著的每个数据包处理开销，但需要减轻导致RH0[RFC5095]被弃用的带宽耗尽攻击。
The following describes the algorithm performed when processing an SRH:
以下描述了处理SRH时执行的算法：
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else {
compute n, the number of addresses in the Routing header, by
n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else {
compute n, the number of addresses in the Routing header, by
n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1
compute i, the index of the next address to be visited in the address vector, by subtracting Segments Left from n
计算i，地址向量中要访问的下一个地址的索引，从n中减去剩余的段
if Address[i] or the IPv6 Destination Address is multicast {
discard the packet
}
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
send an ICMP Parameter Problem (Code 0) and discard the
packet
}
else {
swap the IPv6 Destination Address and Address[i]
if Address[i] or the IPv6 Destination Address is multicast {
discard the packet
}
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
send an ICMP Parameter Problem (Code 0) and discard the
packet
}
else {
swap the IPv6 Destination Address and Address[i]
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
RPL routers are responsible for ensuring that an SRH is only used between RPL routers:
RPL路由器负责确保SRH仅在RPL路由器之间使用：
1. For datagrams destined to a RPL router, the router processes the packet in the usual way. For instance, if the SRH was included using tunneled mode and the RPL router serves as the tunnel endpoint, the router removes the outer IPv6 header, at the same time removing the SRH as well.
1. 对于发送到RPL路由器的数据报，路由器以通常的方式处理数据包。例如，如果SRH是使用隧道模式包含的，并且RPL路由器用作隧道端点，则路由器将删除外部IPv6报头，同时也删除SRH。
2. Datagrams destined elsewhere within the same RPL routing domain are forwarded to the correct interface.
2. 发送到同一RPL路由域中其他地方的数据报被转发到正确的接口。
3. Datagrams destined to nodes outside the RPL routing domain are dropped if the outermost IPv6 header contains an SRH not generated by the RPL router forwarding the datagram.
3. 如果最外面的IPv6标头包含转发数据报的RPL路由器未生成的SRH，则将丢弃发送到RPL路由域之外的节点的数据报。
The RPL message security mechanisms defined in [RFC6550] do not apply to the RPL Source Route Header. This specification does not provide any confidentiality, integrity, or authenticity mechanisms to protect the SRH.
[RFC6550]中定义的RPL消息安全机制不适用于RPL源路由头。本规范不提供任何保密性、完整性或真实性机制来保护SRH。
[RFC5095] deprecates the Type 0 Routing header due to a number of significant attacks that are referenced in that document. Such attacks include bypassing filtering devices, reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.
[RFC5095]由于该文档中引用了大量重大攻击，因此不推荐类型0路由标头。此类攻击包括绕过过滤设备、到达其他无法访问的Internet系统、网络拓扑发现、带宽耗尽以及击败选播。
Because this document specifies that the SRH is only for use within a RPL routing domain, such attacks cannot be mounted from outside a RPL routing domain. As specified in this document, RPL routers MUST drop datagrams entering or exiting a RPL routing domain that contain an SRH in the IPv6 Extension headers.
由于本文档指定SRH仅在RPL路由域内使用，因此无法从RPL路由域外装载此类攻击。如本文档所述，RPL路由器必须丢弃进入或退出在IPv6扩展头中包含SRH的RPL路由域的数据报。
Such attacks, however, can be mounted from within a RPL routing domain. To mitigate bandwidth exhaustion attacks, this specification requires RPL routers to check for loops in the SRH and drop datagrams that contain such loops. Attacks that include bypassing filtering devices and reaching otherwise unreachable Internet systems are not as relevant in mesh networks since the topologies are, by their very nature, highly dynamic. The RPL routing protocol is designed to provide reachability to all devices within a RPL routing domain and may utilize routes that traverse any number of devices in any order.
但是，此类攻击可以从RPL路由域中装载。为了减轻带宽耗尽攻击，该规范要求RPL路由器检查SRH中的环路，并丢弃包含此类环路的数据报。包括绕过过滤设备和到达其他无法访问的Internet系统的攻击在网状网络中并不相关，因为拓扑结构本质上是高度动态的。RPL路由协议旨在为RPL路由域内的所有设备提供可达性，并可利用以任何顺序遍历任意数量设备的路由。
Even so, these attacks and others (e.g., defeating anycast and routing topology discovery) can occur within a RPL routing domain when using this specification.
即使如此，当使用此规范时，这些攻击和其他攻击（例如，击败选播和路由拓扑发现）也可能发生在RPL路由域中。
The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing SRH in back-to-back datagrams. An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism.
生成ICMPv6错误消息可通过在背对背数据报中发送导致SRH的错误来尝试拒绝服务攻击。正确遵循[RFC4443]第2.4节的实现将受到ICMPv6速率限制机制的保护。
This document defines a new IPv6 Routing Type, the "RPL Source Route Header", and has been assigned number 3 by IANA.
本文档定义了一种新的IPv6路由类型，即“RPL源路由头”，并已由IANA分配编号3。
This document defines a new ICMPv6 Destination Unreachable Code, "Error in Source Routing Header", and has been assigned number 7 by IANA.
本文档定义了一个新的ICMPv6目的地不可访问代码“源路由头中的错误”，IANA已为其分配了编号7。
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal Thubert, Sean Turner, and Tim Winter for their comments and suggestions that helped shape this document.
作者感谢Jari Arkko、Ralph Droms、Adrian Farrel、Stephen Farrell、Richard Kelsey、Suresh Krishnan、Erik Nordmark、Pascal Thubert、Sean Turner和Tim Winter提出的意见和建议，这些意见和建议有助于形成本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月。
Authors' Addresses
作者地址
Jonathan W. Hui Cisco Systems 170 West Tasman Drive San Jose, California 95134 USA
Jonathan W.Hui Cisco Systems 170美国加利福尼亚州圣何塞西塔斯曼大道95134号
Phone: +408 424 1547
EMail: jonhui@cisco.com
Phone: +408 424 1547
EMail: jonhui@cisco.com
JP. Vasseur Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。法国卡米尔·德斯穆林斯街11号瓦瑟尔思科系统公司Issy Les Moulineaux 92782
EMail: jpv@cisco.com
EMail: jpv@cisco.com
David E. Culler UC Berkeley 465 Soda Hall Berkeley, California 94720 USA
David E.Culler加州大学伯克利分校465苏打厅伯克利，加利福尼亚94720美国
Phone: +510 643 7572
EMail: culler@cs.berkeley.edu
Phone: +510 643 7572
EMail: culler@cs.berkeley.edu
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave. Cupertino, California 95014 USA
维希瓦斯·曼拉尔·惠普公司，美国加利福尼亚州库比蒂诺市普雷内里奇大道19111号，邮编95014
EMail: vishwas.manral@hp.com
EMail: vishwas.manral@hp.com