Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6553 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 March 2012
Internet Engineering Task Force (IETF) J. Hui
Request for Comments: 6553 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 March 2012
The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
低功耗有损网络路由协议（RPL）选项，用于在数据平面数据报中承载RPL信息
Abstract
摘要
The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information.
低功耗有损网络路由协议（RPL）在数据平面数据报中包含路由信息，以快速识别路由拓扑中的不一致性。本文档描述了RPL路由器中使用的RPL选项，以包含此类路由信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6553.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6553.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（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 Option ........................................3
4. RPL Router Behavior .............................................5
5. Security Considerations .........................................6
5.1. DAG Inconsistency Attacks ..................................6
5.2. Destination Advertisement Object (DAO)
Inconsistency Attacks ......................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Overview ........................................................3
3. Format of the RPL Option ........................................3
4. RPL Router Behavior .............................................5
5. Security Considerations .........................................6
5.1. DAG Inconsistency Attacks ..................................6
5.2. Destination Advertisement Object (DAO)
Inconsistency Attacks ......................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
RPL is a distance vector IPv6 routing protocol designed for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are typically constrained in energy and/or channel capacity. To conserve precious resources, a routing protocol must generate control traffic sparingly. However, this is at odds with the need to quickly propagate any new routing information to resolve routing inconsistencies quickly.
RPL是一种距离向量IPv6路由协议，设计用于低功耗和有损网络（LLN）[RFC6550]。此类网络通常在能量和/或信道容量方面受到限制。为了节省宝贵的资源，路由协议必须节省生成控制流量。然而，这与快速传播任何新路由信息以快速解决路由不一致的需要是不一致的。
To help minimize resource consumption, RPL uses a slow proactive process to construct and maintain a routing topology but a reactive and dynamic process to resolving routing inconsistencies. In the steady state, RPL maintains the routing topology using a low-rate beaconing process. However, when RPL detects inconsistencies that may prevent proper datagram delivery, RPL temporarily increases the beacon rate to quickly resolve those inconsistencies. This dynamic rate control operation is governed by the use of dynamic timers also referred to as "Trickle" timers and defined in [RFC6206]. In contrast to other routing protocols (e.g., OSPF [RFC2328]), RPL detects routing inconsistencies using data-path verification, by including routing information within the datagram itself. In doing so, repair mechanisms operate only as needed, allowing the control and data planes to operate on similar time scales. The main motivation for data-path verification in LLNs is that control-plane traffic should be carefully bounded with respect to the data traffic. Intuitively, there is no need to solve routing issues (which may be temporary) in the absence of data traffic.
为了帮助最小化资源消耗，RPL使用缓慢的主动过程来构建和维护路由拓扑，但使用反应式动态过程来解决路由不一致性。在稳定状态下，RPL使用低速信标过程维护路由拓扑。但是，当RPL检测到可能妨碍正确数据报传递的不一致时，RPL会临时增加信标速率以快速解决这些不一致。此动态速率控制操作由动态计时器（也称为“涓流”计时器）的使用控制，并在[RFC6206]中定义。与其他路由协议（例如OSPF[RFC2328]）不同，RPL通过在数据报本身中包含路由信息，使用数据路径验证来检测路由不一致。在这样做时，修复机制只在需要时运行，从而允许控制和数据平面在类似的时间尺度上运行。LLN中数据路径验证的主要动机是控制平面通信量应仔细限制在数据通信量的范围内。直观地说，在没有数据流量的情况下，不需要解决路由问题（可能是暂时的）。
RPL constructs a Directed Acyclic Graph (DAG) that attempts to minimize path costs to the DAG root according to a set of metrics and Objective Functions. There are circumstances where loops may occur, and RPL is designed to use a data-path loop detection method. This is one of the known requirements of RPL, and other data-path usage might be defined in the future.
RPL构造了一个有向无环图（DAG），该图试图根据一组度量和目标函数最小化DAG根的路径开销。有些情况下可能会发生循环，RPL设计为使用数据路径循环检测方法。这是RPL的已知需求之一，将来可能会定义其他数据路径使用。
To that end, this document defines a new IPv6 option, called the RPL Option, to be carried within the IPv6 Hop-by-Hop header. The RPL Option is only for use between RPL routers participating in the same RPL Instance.
为此，本文档定义了一个新的IPv6选项，称为RPL选项，将在IPv6逐跳标头中携带。RPL选项仅用于参与同一RPL实例的RPL路由器之间。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The RPL Option provides a mechanism to include routing information with each datagram that a router forwards. When receiving datagrams that include routing information, RPL routers process the routing information to help maintain the routing topology.
RPL选项提供了一种机制，可以在路由器转发的每个数据报中包含路由信息。当接收包含路由信息的数据报时，RPL路由器处理路由信息以帮助维护路由拓扑。
Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router. This document also specifies the use of IPv6-in-IPv6 tunneling [RFC2473] when attaching a RPL option to a packet. Use of tunneling ensures that the original packet remains unmodified and that ICMP errors return to the RPL Option source rather than the source of the original packet.
沿着数据包传递路径的每个RPL路由器处理并更新RPL选项。如果收到的数据包尚未包含RPL选项，RPL路由器必须在将其转发到另一个RPL路由器之前插入RPL选项。本文档还规定了在将RPL选项附加到数据包时使用IPv6-in-IPv6隧道[RFC2473]。隧道的使用确保原始数据包保持不变，ICMP错误返回到RPL选项源，而不是原始数据包的源。
The RPL Option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. This option has an alignment requirement of 2n. The option has the following format:
RPL选项位于IPv6逐跳选项标头中，紧跟在IPv6标头之后。该选项的对齐要求为2n。该选项具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RPL Option
图1:RPL选项
Option Type: 0x63
选项类型：0x63
Opt Data Len: 8-bit field indicating the length of the option, in octets, excluding the Option Type and Opt Data Len fields.
Opt Data Len：表示选项长度的8位字段，以八位字节为单位，不包括选项类型和Opt Data Len字段。
Down 'O': 1-bit flag as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
向下“O”：1位标志，如[RFC6550]第11.2节所定义。处理应遵循[RFC6550]第11.2节所述的规则。
Rank-Error 'R': 1-bit flag as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
秩错误“R”：1位标志，如[RFC6550]第11.2节所定义。处理应遵循[RFC6550]第11.2节所述的规则。
Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
转发错误“F”：1位标志，定义见[RFC6550]第11.2节。处理应遵循[RFC6550]第11.2节所述的规则。
RPLInstanceID: 8-bit field as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
RPLInstanceID:8位字段，如[RFC6550]第11.2节所定义。处理应遵循[RFC6550]第11.2节所述的规则。
SenderRank: 16-bit field as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].
SenderRak:16位字段，定义见[RFC6550]第11.2节。处理应遵循[RFC6550]第11.2节所述的规则。
The two high order bits of the Option Type MUST be set to '01' and the third bit is equal to '1'. With these bits, according to [RFC2460], nodes that do not understand this option on a received packet MUST discard the packet. Also, according to [RFC2460], the values within the RPL Option are expected to change en route. The RPL Option Data Length is variable.
选项类型的两个高位必须设置为“01”，第三位等于“1”。根据[RFC2460]，对于这些位，不理解接收到的数据包上的该选项的节点必须丢弃该数据包。此外，根据[RFC2460]，RPL选项内的值预计会在途中发生变化。RPL选项数据长度是可变的。
The action taken by using the RPL Option and the potential set of sub-TLVs carried within the RPL Option MUST be specified by the RFC of the protocol that uses that option. No sub-TLVs are defined in this document. A RPL device MUST skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after.
通过使用RPL选项所采取的行动以及RPL选项内携带的潜在子TLV集必须由使用该选项的协议的RFC指定。本文件中未定义子TLV。RPL设备必须跳过任何无法识别的子TLV，并尝试处理可能在之后出现的任何其他子TLV。
Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([RFC6554]) and MAY include both. A datagram including a Source Routing Header (SRH) does not need to include a RPL Option since both the source and intermediate routers ensure that the SRH does not contain loops.
在RPL路由器之间发送的数据报必须包含RPL选项或RPL源路由头（[RFC6554]），并且可能同时包含两者。包含源路由报头（SRH）的数据报不需要包含RPL选项，因为源路由器和中间路由器都确保SRH不包含循环。
When the router is the source of the original packet and the destination is known to be within the same RPL Instance, the router SHOULD include the RPL Option directly within the original packet. Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL Option in the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by a RPL Option are sent back to the router that generated the RPL Option.
当路由器是原始数据包的源并且已知目的地在同一RPL实例中时，路由器应直接在原始数据包中包含RPL选项。否则，路由器必须使用IPv6-in-IPv6隧道[RFC2473]，并将RPL选项置于隧道头中。使用IPv6-in-IPv6隧道可以确保传递的数据报保持不变，并且由RPL选项生成的ICMPv6错误被发送回生成RPL选项的路由器。
A RPL router chooses the next RPL router that should process the original packet as the tunnel exit-point. In some cases, the tunnel exit-point will be the final RPL router along a path towards the original packet's destination, and the original packet will only traverse a single tunnel. One example is when the final destination or the destination's attachment router is known to be within the same RPL Instance.
RPL路由器选择下一个应处理原始数据包的RPL路由器作为隧道出口点。在某些情况下，隧道出口点将是沿着通向原始数据包目的地的路径的最终RPL路由器，并且原始数据包将仅穿过单个隧道。一个例子是，已知最终目的地或目的地的附件路由器位于同一RPL实例中。
In other cases, the tunnel exit-point will not be the final RPL router along a path and the original packet may traverse multiple tunnels to reach the destination. One example is when a RPL router is simply forwarding a packet to one of its Destination-Oriented DAG (DODAG) parents. In this case, the RPL router sets the tunnel exit-point to a DODAG parent. When forwarding the original packet hop-by-hop, the RPL router only makes a determination on the next hop towards the destination.
在其他情况下，隧道出口点将不是沿路径的最终RPL路由器，并且原始分组可以穿过多个隧道到达目的地。一个例子是，RPL路由器只是将数据包转发给其面向目的地的DAG（DODAG）双亲之一。在这种情况下，RPL路由器将隧道出口点设置为DODAG父级。当逐跳转发原始数据包时，RPL路由器仅确定下一跳到目的地。
A RPL router receiving an IPv6-in-IPv6 packet destined to it processes the tunnel packet as described in Section 3 of [RFC2473]. Before IPv6 decapsulation, the RPL router MUST process the RPL Option, if one exists. After IPv6 decapsulation, if the router determines that it should forward the original packet to another RPL router, it MUST encapsulate the packet again using IPv6-in-IPv6
接收以其为目的地的IPv6-in-IPv6数据包的RPL路由器按照[RFC2473]第3节中的描述处理隧道数据包。在IPv6解除封装之前，RPL路由器必须处理RPL选项（如果存在）。IPv6解除封装后，如果路由器确定应将原始数据包转发给另一个RPL路由器，则必须使用IPv6-in-IPv6再次封装数据包
tunneling to include the RPL Option. Fields within the RPL Option that do not change hop-by-hop MUST remain the same as those received from the prior tunnel.
隧道以包括RPL选项。RPL选项中不逐跳更改的字段必须与从先前隧道接收的字段保持相同。
RPL routers are responsible for ensuring that a RPL Option is only used between RPL routers:
RPL路由器负责确保RPL选项仅在RPL路由器之间使用：
1. For datagrams destined to a RPL router, the router processes the packet in the usual way. For instance, if the RPL Option was included using tunneled mode and the RPL router serves as the tunnel endpoint, the router removes the outer IPv6 header, at the same time removing the RPL Option as well.
1. 对于发送到RPL路由器的数据报，路由器以通常的方式处理数据包。例如，如果使用隧道模式包括RPL选项，并且RPL路由器用作隧道端点，则路由器将删除外部IPv6标头，同时也删除RPL选项。
2. Datagrams destined elsewhere within the same RPL Instance are forwarded to the correct interface.
2. 发送到同一RPL实例中其他地方的数据报被转发到正确的接口。
3. Datagrams destined to nodes outside the RPL Instance are dropped if the outermost IPv6 header contains a RPL Option not generated by the RPL router forwarding the datagram.
3. 如果最外层的IPv6标头包含RPL选项，而该选项不是由转发数据报的RPL路由器生成的，则将丢弃发送到RPL实例外部节点的数据报。
To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion (i.e., at least 1280 + 40 (outer IP header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the maximum RPL Option header size for a given RPL network. To take advantage of this, however, the communicating endpoints need to be aware of the MTU along the path (i.e., through Path MTU Discovery). Unfortunately, the larger MTU size may not be available on all links (e.g., 1280 octets on IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) links). However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU, so performance degradation through fragmentation would be limited.
为了避免碎片，希望使用允许报头扩展的MTU大小（即，至少1280+40（外部IP报头）+RPL_选项_最大_大小），其中RPL_选项_最大_大小是给定RPL网络的最大RPL选项报头大小。然而，为了利用这一点，通信端点需要知道路径上的MTU（即，通过路径MTU发现）。不幸的是，并非所有链路上都可以使用较大的MTU（例如，IPv6低功耗无线个人区域网络（6LoWPAN）链路上的1280个八位字节）。但是，预计这些类型的网络上的大部分流量包含的消息比MTU小得多，因此通过碎片化导致的性能下降将受到限制。
The RPL Option assists RPL routers in detecting routing inconsistencies. The RPL message security mechanisms defined in [RFC6550] do not apply to the RPL Option.
RPL选项帮助RPL路由器检测路由不一致。[RFC6550]中定义的RPL消息安全机制不适用于RPL选项。
Using the Down 'O' flag and SenderRank field, an attacker can cause RPL routers to believe that a DAG inconsistency exists within the RPL Instance identified by the RPLInstanceID field. This attack would cause a RPL router to reset its DODAG Information Object (DIO) Trickle timer and begin transmitting DIO messages more frequently.
使用Down“O”标志和senderrak字段，攻击者可以使RPL路由器相信RPLINTanceId字段标识的RPL实例中存在DAG不一致。此攻击将导致RPL路由器重置其DODAG信息对象（DIO）涓流计时器，并开始更频繁地传输DIO消息。
In order to avoid any unacceptable impact on network operations, an implementation MAY limit the rate of Trickle timer resets caused by receiving a RPL Option to no greater than MAX_RPL_OPTION_RANK_ERRORS per hour. A RECOMMENDED value for MAX_RPL_OPTION_RANK_ERRORS is 20.
为了避免对网络操作造成任何不可接受的影响，实现可以将接收RPL选项导致的涓流计时器重置速率限制为不大于每小时最大RPL选项排名错误数。最大RPL选项排名错误的建议值为20。
In Storing mode, RPL routers maintain Downward routing state. Under normal operation, the RPL Option assists RPL routers in cleaning up stale Downward routing state by using the Forwarding-Error 'F' flag to indicate that a datagram could not be delivered by a child and is being sent back to try a different child. Using this flag, an attacker can cause a RPL router to discard Downward routing state.
在存储模式下，RPL路由器保持下行路由状态。在正常操作下，RPL选项通过使用转发错误“F”标志来指示数据报无法由子级传递，并且正在发送回以尝试其他子级，从而帮助RPL路由器清除过时的向下路由状态。使用此标志，攻击者可以使RPL路由器放弃向下路由状态。
In order to avoid any unacceptable impact on network operations, an implementation MAY limit the rate of discarding Downward routing state caused by receiving a RPL Option to no greater than MAX_RPL_OPTION_FORWARD_ERRORS per hour. A RECOMMENDED value for MAX_RPL_OPTION_FORWARD_ERRORS is 20.
为了避免对网络操作造成任何不可接受的影响，实现可以将接收RPL选项导致的丢弃向下路由状态的速率限制为不大于每小时最大RPL选项转发错误数。最大RPL选项向前错误的建议值为20。
In Non-Storing mode, only the Low-Power and Lossy Network Border Router (LBR) maintains Downward routing state. Because RPL routers do not maintain Downward routing state, the RPL Option cannot be used to mount such attacks.
在非存储模式下，只有低功耗有损网络边界路由器（LBR）保持下行路由状态。由于RPL路由器不保持向下路由状态，因此不能使用RPL选项装载此类攻击。
IANA has assigned a new value in the Destination Options and Hop-by-Hop Options registry. The value is as follows:
IANA已在目标选项和逐跳选项注册表中分配了一个新值。该值如下所示：
Hex Value Binary Value
act chg rest Description Reference
--------- --- --- ------- ----------------- ----------
0x63 01 1 00011 RPL Option [RFC6553]
Hex Value Binary Value
act chg rest Description Reference
--------- --- --- ------- ----------------- ----------
0x63 01 1 00011 RPL Option [RFC6553]
As specified in [RFC2460], the first two bits indicate that the IPv6 node MUST discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data may change en route. The remaining bits serve as the option type.
如[RFC2460]中所述，前两位表示如果IPv6节点无法识别选项类型，则必须丢弃该数据包，第三位表示选项数据可能在路由过程中发生变化。其余的位用作选项类型。
IANA has created a registry called RPL-option-TLV, for the sub-TLVs carried in the RPL Option header. New codes may be allocated only by IETF Review [RFC5226]. The type field is an 8-bit field whose value be between 0 and 255, inclusive.
IANA已经为RPL选项标题中包含的子TLV创建了一个名为RPL option TLV的注册表。新代码只能由IETF评审[RFC5226]分配。类型字段是一个8位字段，其值介于0和255之间（包括0和255）。
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen Farrell, Richard Kelsey, Suresh Krishnan, Vishwas Manral, Erik Nordmark, Pascal Thubert, Sean Turner, and Tim Winter, for their comments and suggestions that helped shape this document.
作者感谢Jari Arkko、Ralph Droms、Adrian Farrel、Stephen Farrell、Richard Kelsey、Suresh Krishnan、Vishwas Manral、Erik Nordmark、Pascal Thubert、Sean Turner和Tim Winter提出的意见和建议，这些意见和建议有助于形成本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6206]Levis，P.，Clausen，T.，Hui，J.，Gnawali，O.，和J.Ko，“涓流算法”，RFC 62062011年3月。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]温特，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月。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012.
[RFC6554]Hui，J.，Vasseur，JP.，Culler，D.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，RFC 65542012年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