RPL源路由的IPv6路由头[RFC6554译文]

RPL源路由的IPv6路由头

An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Network (RPL)

摘要

在低功耗有损网络（LLNs）中，路由器上内存限制会会导致他们最多只能维持几个路由。在一些配置中，使用这些内存受限的路由器转发数据到LLN内的节点是必要的。在一些部署中，低功耗有损网络路由协议（RPL）可以用一个（如有向无环图（DAG）的根）或几个路由器来存储大部分的路由并转发IPv6数据包，采用源路由技术以避免在内存受限的路由器上存储大量的路由表。本文档描述了一种在RPL路由域内发送数据的新的IPb6路由头部类型。

1、引言

低功耗有损网络路由协议（RPL）是一种为低功耗有损网络（LLNs）[RFC6550]设计的距离矢量IPv6路由协议。这些网络通常是资源受限的（有限的数据率、处理能力、能源、内存等）。尤其是在一些LLN配置中使用LLN路由器：受限的内存会导致节点只能维持几个默认路由，没有到其他目的地的路由。但是，使用这些内存受限的路由器来转发数据包并维持到LLN内的节点的可达性是必须的。

为了使用内存受限的路由器的路径，RPL依赖源路由。在RPL一种部署模式中，性能较好的路由器手机路由信息并形成到RPL路由域内任意目的地的路径。为了发送数据，需要一种IPv6支持的源路由机制。

本文档描述了一种严格用于相同RPL路由域内RPL路由器之间的源路由头部（SRH）;RPL路由域是指在一个单一管理者下的RPL路由器集合。路由域的边界是网络管理员通过设置与外部链接或域内链接定义的。

1.1 要求语言

本文中的关键词"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" RFC2119的解释相同

2、概述

SRH的格式来源于类型为0的源路由【RFC2460】. 然而,当一个带有SRH数据包其所有的IPv6目的地址都带有相同的前缀时，SRH引入了解压缩源路由实体的机制，这是在LLNs中使用源路由的典型场景。压缩机制减少了稀有资源的消耗，如信道能力等。

SRH在处理规则上也与RH0不同，这减轻了导致RH0被弃用【5095】的安全问题。首先，RPL实行严格的源路由策略：源和目的之间的每一个和每一跳的源路由都在SRH中指定。注意源路由可能是实际源和目的之间路径的子集。这在下面将详细讨论。二是源路由仅用于RPL路由域中的RPL路由器上。RPL边缘路由器负责连接其他RPL路由域和使用其他路由协议的IP域。边缘路由器不允许已经带有SRH头的报文进入或退出RPL路由域。三是RPL路由器丢弃带有多个IP地址被放置在任意一个接口上的报文，以此来避免回路发生。

在RPL路由器需要使用SRH来转发报文到它的目的节点时，有两种场景来决定如何包含SRH：

1、如果SRH指定了从源到目的的完整路径，那么路由器将SRH直接放在报文中；

2、如果SRH仅仅指定了从源到目的路径的一部分，路由器使用IPv6-in-IPv6隧道技术并且将SRH放置在外部IPv6头部。隧道技术的使用保证了报文发送不被修改和ICMP错误返回给SRH的源而不是原始数据包的源。

在RPL网络中，场景1发生在当源和目的都在RPL路由域内并且单个SRH指定了从源到地址的整个路径，如下图所示：

RPL 路由域

在上面的场景中，从源S到目的D发送的报文有如下的包结构：

S的地址放在IPv6头的源地址字段。

携带SRH的数据包，D的地址放在SRH的（Address[1..n]的）最后一个实体上，当到达最后一跳时，D的地址被放置在被放在IPv6头的目的地址字段上。

在RPL网络中，场景2发生在所有的报文中，源或目的至少有一个在RPL路由域外，如下图所示：

在上述场景中，R可能指一个RPL边界路由器或（当连接其他RPL域时）或一个RPL路由器（当连接到hosts时）.当报文在RPL路由域内转发时，具有如下的结构

注意外头部（包括SRH）的添加和删除应由RPL路由器完成。

只要RPL路由器在转发报文时需要插入源路由时，场景2也会发生。在RPL中一个这样的例子是所有的RPL流量都会经过边缘路由器并且使用边缘路由器当报文发送到最终的目的节点。当使用隧道模式包含SRH时，边界路由器将使用IPv6-in-IPv6并在外IPv6头部包含SRH来无修改地封装收到的报文。

RPL 路由域

在上述场景中，数据包从S经过低功耗有损网络边界路由器（LBR）发送到D.在S和LBR之间，报文用RPL建立起的DAG来寻路，不包含SRH。 LBR使用IPv6-in-IPv6技术来无修改地封装收到的报文，并将SRH放在外IPv6头部。

3. RPL路由头格式

源路由头有如下的格式：

Next Header 9位选择器。标识紧跟路由头的头类型。与【RFC2460】中IPv6下一个头部的值相同

Hdr Ext Len 8位无符号整数。路由头的字节长度（8位一个字节），不包括第一个字节。注意当Adress[1..n]压缩时（CmprI或CmprE的值不为0），Hdr Ext Len 不等于地址数量的2倍。

Routing Type 8位选择器。标识特定的路由头变量。 SRH应该设置路由类型为3.

Segments Left 8为无符号整数。路由部分剩余的数量。即在到达目的地之前明确列出的仍需要经过的路由数量。 SRH的发出者设置该字段为n, 包含在Adress[1..n]中的地址数量。

CmprI 4位无符号整数。每一段前缀的字节数量（即1到n-1段），除了被忽略的最后一段。例如，在Adress[1..n-1]中，SRH带有完整的IPv6地址时设置CmprI为0.

CmprE 4位无符号整数。被忽略的最后一段前缀的字节数量（即段n）, 例如：在Address[n]中，SRH携带完整的IPv6地址。

Pad 4位无符号整数。在SRH的结尾Address[n]后用于扩展的字节数量。

Reserved 字段未使用。发送者必须将其初始化为0 ，接收者必须忽略它。

Address[1..n] 从1到n编码的地址矢量， [1..n-1]中每个矢量元素的大小是（16-CmprI）,元素[n]的大小是（16-CmprE）. SRH的发出者将下一跳IPv6地址(第一个)放在IPv6头的IPv6目的地址字段中，将第二跳IPv6地址作为Address[1..n]中的第一个地址（即Address[n]）.

SRH和类型0路由头具有相同的基本结构。当带有完整的IPv6地址时，CmprI, CmprE, 和 Pad字段的值位0。类型0路由头和SRH编码唯一不同的是路由类型字段的值。

对于一个RPL路由域，常见的网路的配置是RPL路由域内所有的路由器共享一个前缀。为了当所有地址实体共享的前缀作为携带SRH的数据包的IPv6目的地址字段时，允许节点压缩Address[1..n]矢量， SRH引入了CmprI, CmprE, 和 Pad 字段。 CmprI 和 CmprE 标识了与携带SRH数据包IPv6目的字段共享的前缀的字节数据。共享的前缀字节数量并不在路由头中携带并且Address[1..n-1]中每个实体的大小是（16-CmprI）,Address[n]的大小是（16-CmprE）个字节。当CmprI或CmprE非0时，最后一个实体Address[n]和路由头的结尾处可能会存在没用到的字节。 Pad字段标识了用于填充的未使用的字节数。注意，当CmprI和CmprE都为0时，Pad必须设置为0.

SRH禁止在一个路径中经过一个节点超过一次。在产生SRH时，源节点可能并不知道IPv6地址和节点的映射关系。最低限度是源节点必须确保IPv6地址不能出现多于一次。 IPv6源和封装报文的目的地址不能出现在SRH中。

组播地址禁止出现在SRH中或携带SRH的报文的IPv6目的地址字段中。

4 RPL路由器行为

4.1 生成源路由头

为了将IPv6报文发送到目的节点，路由器可能需要生成一个新的SRH并指定严格的源路由。当路由器是原始数据的源节点并且目的节点已知在相同的RPL路由域内时，路由器应该直接在原始包中包含SRH. 否则，路由器必须使用IPv6-in-IPv6隧道【RFC2473】技术，并将SRH放在隧道的头中。使用IPv6-in-IPv6隧道技术能够确保被发送的数据包不被修改和SRH产生的ICMPv6错误会被发送到生成SRH的路由器上。

在使用IPv6-in-IPv6隧道技术时，为了尊重原始报文的IPv6 跳数限制值，生成SRH的路由器在转发数据时必须设置 Segments Left的值小于原始报文的IPv6 跳数限制值。在源路由比原始报文的IPv6跳数多的情况下，在SRH只能包含初始跳数（有原始报文的IPv6跳数限制决定）。如果RPL路由器不是原始报文的源节点，原始报文的IPv6跳数限制字段在生成SRH之前是递减的。在生成源路由后，RPL路由器通过Segments Left 值来减少原始报文的跳数限制的值。以这种方式处理Segments Left和原始报文的IPv6跳数字段可以确在没有隧道技术上的传统网络转发报文时按照预期发生保ICMPv6 Time Exceeded 错误。

为了避免分片，希望采用的MTU的大小可以允许头部扩展（即至少1280+40（外IP头部）+ SRH_MAX_SIZE），SRH_MAX_SIZE是在给定的RPL网络中最大路径长度。然而，为了利用这一点，通信端点需要知道沿路（如通过路径MTU发现）MTU的大小。不幸的是比较大的MTU大小并不是在所有的连接上都支持（如在IPv6低功耗无线个域网（6LowPAN）链路上是1280字节）。然而，可以预期的是在这些类型的网路上的流量大部分都小于MTU。所以由分片带来的性能下降将被限制。

4.2 处理源路由头部

正如【RFC2460】中描述，路由头部在到达能识别IPv6头的目的地址字段的节点之前是不会被检查和处理的。在该节点上，先前头部的下一个头部字段的处理会触发的路由头部模块的调用。

SRH的功能和【RFC2460】定义的路由头类型0 非常相似。在路由头被处理和IPv6报文重新提交给IPv6 模块处理后，IPv6目的地址包含下一跳地址。当转发一个带有Segments Left值不为0的SRH的IPv6报文时，如果IPv6目的地址不在线，路由器必须丢弃该报文并且应该发送一个ICMP目的不可达（ICMPv6的类型为1，Code为7）的消息给包的源地址。该ICMPv6 Code表示 IPv6目的地址不在线并且路由器不能满足严格源路由的要求。在生成ICMPv6错误信息时，必须遵守[RFC4443]的2.4章节

为了检测SRH中的环路，路由器必须确定在是否有多个地址被放在该路由器的任意的接口上。如果这样的地址出现多次并且被至少一个不是该路由器上的地址分开，路由器必须丢弃该数据包并回复ICMP 参数问题，Code为0 的消息给源地址。尽管环路检测确实增加了重要的数据包处理开销，但是却是减少带宽耗尽攻击的需要，带宽耗尽攻击导致了RH0被弃用【RFC5095】。

下面描述了处理SRH时执行的算法

if （Segments Left = 0） {

继续处理数据包中的下一个头，其类型由路由头部中的下一个头部标识；

}

else {

通过n =（（（Hdr Ext Len * 8） - Pad - （16 - CmprE））/（16 - CmprI））+ 1 公式计算路由头部中的地址数量n；

if (Segments Left > n) {

向源地址发送一个ICMP参数问题，Code为0 的消息，然后指向Segments Left，并丢弃该数据包

}

else {

Segments Left 减1

通过从n中减去Segments Left来计算i, 在地址矢量中将要被访问的下一个地址的索引

if （Address[i] 或IPv6目的地址是组播）{

丢弃该数据包

}

else if （Address[1..n]中多于一个地址在本地网口上并且被至少一个不是被安排到本地网口的地址分隔） {

回复一个ICMP参数问题（Code为0）的消息并丢弃该数据包

}

else {

交换IPv6目的地址和Address[i]

if （IPv6 跳数限制 <=1) {

发送ICMP Time Exceeded --在传输中超过跳数限制的消息给源地址并丢弃该数据包；

}

else {

跳数限制减1.

将数据包重新提交给IPv6模块并发送到新的目的地址

}

RPL路由器有责任确保SRH仅在RPL路由器之间使用：

1、对于发往RPL路由器的报文，路由器以普通方式处理该数据包。如果以隧道模式包含SRH并且RPL路由器作为隧道端点，RPL路由器在移除外部IPv6头的同时也移除掉SRH。

2、发送到同一路由域内其他地方的数据报应该被转发到正确的网口；

3、如果最外面的IPv6头包含的SRH不是由转发数据报的RPL路由器生成，则发往RPL路由域外节点的数据报应该被丢弃。

5. 安全注意事项

5.1 源路由攻击

【RFC6550】中的RPL消息安全机制并不适用于RPL源路由头部。本文档没有提供任何保密性、完整性或真实性的机制来保护SRH.

在【RFC5095】中引述了大量的重要攻击，因此不推荐使用类型0路由头部。这些攻击包括绕过过滤设备，到达其他不可达的互联网系统，网络拓扑发现，以及阻碍性anycast等

由于本文档规定SRH只在RPL路由域内使用，因此这些攻击不能从RPL路由域外装载。正如本文档指出的，报文在进入或退出RPL路由域时，RPL路由器必须丢弃这样的报文：在IPv6扩展头部内包含SRH的报文。

然而，这样的攻击可以在RPL路由域内装载。为了减轻带宽耗尽攻击，本规范要求RPL路由器在SRH中检查环路并且丢弃包含环路的报文。包括绕过过滤设备和到达其他不可达网络系统在Mesh网络中没有那么重要，因为由于该类型网络的本性，其拓扑是高度动态变化的。RPL路由协议设计的目的是为RPL路由域内的所有的设备提供可达性并且可以利用该路由以任何顺序穿过任意数量的设备。在即使如此，使用该规范时这些或其他攻击也可能在RPL路由域内发生（如阻碍性anycast以及路由拓扑发现等）。

5.2 ICMPv6攻击

ICMPv6错误消息的生成可能被用于发起拒绝服务攻击通过在回复报文中发送一个造成错误的SRH。正确遵循【RFC4443】第2.4节的实现将受到ICMPv6速率限制机制的保护。

6. IANA注意事项

本文档定义了一种新的IPv6路由类型，即“RPL源路由头部”， INAM编码为3.

本文档定义了一个新的ICMPv6目的地址不可达代码：源路由头部中的错误 IANA编码为7.

7. 致谢

作者对Jari Arkko, Ralph Droms, Adrian Farrel, Stephen

Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal

Thubert, Sean Turner, 和 Tim Winter在该文档完成过程中的建议和批评表示感谢。

8. 参考文献

8.1 规范性参考文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.

[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.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.

8.2 资料性参考文献

[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.

【RFC6554】An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Network (RPL)

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.

1. Introduction

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.

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

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.

1.1. Requirements Language

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].

2. Overview

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.

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.

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.

1. If the SRH specifies the complete path from source to estination, the router places the SRH directly in the datagram itself.

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.

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:

In the above scenario, datagrams traveling from source, S, to destination, D, have the following packet structure:

S's address is carried in the IPv6 header's Source Address field.

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.

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:

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:

Note that the outer header (including the SRH) is added and removed by the RPL router.

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 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。

3. Format of the RPL Routing Header

The Source Routing Header has the following format:

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].

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.

Routing Type 8-bit selector. Identifies the particular Routing header variant. An SRH should set the Routing Type to 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].

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.

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.

Pad 4-bit unsigned integer. Number of octets that are used for padding after Address[n] at the end of the SRH.

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]).

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.

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 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.

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.

Multicast addresses MUST NOT appear in an SRH or in the IPv6 Destination Address field of a datagram carrying an SRH.

4. RPL Router Behavior

4.1. Generating Source Routing Headers

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.

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 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.

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.

4.2. Processing Source Routing Headers

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.

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.

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].

The following describes the algorithm performed when processing an 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 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

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

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:

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.

2. Datagrams destined elsewhere within the same RPL routing domain are forwarded to the correct interface.

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.

5. Security Considerations

5.1. Source Routing Attacks

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.

[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.

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.

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. 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.

5.2. ICMPv6 Attacks

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.

6. IANA Considerations

This document defines a new IPv6 Routing Type, the "RPL Source Route Header", and has been assigned number 3 by IANA.

This document defines a new ICMPv6 Destination Unreachable Code, "Error in Source Routing Header", and has been assigned number 7 by IANA.

7. Acknowledgements

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.

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.

[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.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.

8.2. Informative References

Authors' Addresses

Jonathan W. Hui

Cisco Systems

170 West Tasman Drive

San Jose, California 95134

USA

Phone: +408 424 1547

EMail: jonhui@cisco.com

JP. Vasseur

Cisco Systems

11, Rue Camille Desmoulins

Issy Les Moulineaux 92782

France

EMail: jpv@cisco.com

David E. Culler

UC Berkeley

465 Soda Hall

Berkeley, California 94720

USA

Phone: +510 643 7572

EMail: culler@cs.berkeley.edu

Vishwas Manral

Hewlett Packard Co.

19111 Pruneridge Ave.

Cupertino, California 95014

USA

EMail: vishwas.manral@hp.com

RPL源路由的IPv6路由头[RFC6554译文]相关推荐

ipv6下单播。组播泛播
ipv6地址可以分成三类:单播地址.组播地址和任播地址. 单播地址又可以分为单播本地链路地址(前缀为ff80::/10). 单播本地站点地址(前缀为FEC0::/10). 单播未指定地址(::/12 ...
【互联网及其应用】第2章互联网技术
一.互联网的基本技术 1.1 互联网的结构互联网具有一种独特的结构,它是以通信网络的体系结构为基础,将不同的网络技术统起来的一种高级技术,是一种解决了异种网的通信问题,可向用户提供一致的通信服务的结 ...
++实现 ipv6数据报_IPV6报文格式和IPV4有什么区别？
前言 RFC2460定义了IPv6数据报格式. 总体结构上,IPv6数据报格式与IPv4数据报格式是一样的,也是由IP报头和数据(在IPv6中称为有效载荷)这两个部分组成的. 但在IPv6数据报数据部 ...
IPv6数据报头部格式
文章摘自书籍<深入理解计算机网络王达机械工业出版社> IPv4数据报头格式请点击此处 IPv6数据报头部格式 RFC2460定义了IPv6数据报格式.总体结构上,IPv6数据报格式与I ...
IPv4与IPv6数据包格式
https://blog.csdn.net/frank_jb/article/details/45093615 本文给出IPv4与IPv6数据报格式示意图,并整理了各个字段含义,最后对比IPv4与IP ...
IPv4 和 IPv6 数据报格式详解
IPv4 报文头格式及各字段功能 IPv4 报头格式各字段功能: 1.版本号(Version):长度 4 bit .标识目前采用的 IP 协议的版本号.一般的值为 0100(IPv4),0110(I ...
IP协议（三） IPv6协议
IPv6 IPv4地址空间耗尽,需要更大的地址空间改变其首部,使其可以快速转发数据报 IPv6数据报格式 1.IPv6基本首部首部长度改为固定的40字节,称为基本首部取消了服务类型字段取消了检 ...
IPV4和IPV6报头对比分析
IPV4和IPV6报头对比分析注意:文中部分字段摘自Cisco TCP/IP路由协议卷一一.IPV4报头分析使用wireshark抓取一个ipv4的数据包 Version(版本): 该字段长度为 ...
网络知识-04 网络层-IPv6
文章目录 6 IPv6 6.1 IPv6地址表示方法 6.2 IPv6地址分类 6.2.1 全球单播地址 6.2.2 本地链路地址 6.2.3 本地站点地址 6.2.4 唯一本地地址 6.2.5 未指 ...
IPv6 时代如何防御 DDoS 攻击？
在互联网世界,每台联网的设备都被分配了一个用于标识和位置定义的 IP 地址.20 世纪 90 年代以来互联网的快速发展,联网设备所需的地址远远多于可用 IPv4 地址的数量,导致了 IPv4 地址耗尽 ...

RPL源路由的IPv6路由头[RFC6554译文]

RPL源路由的IPv6路由头[RFC6554译文]相关推荐

最新文章

热门文章