summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6553.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6553.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6553.txt')
-rw-r--r--doc/rfc/rfc6553.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6553.txt b/doc/rfc/rfc6553.txt
new file mode 100644
index 0000000..fb87316
--- /dev/null
+++ b/doc/rfc/rfc6553.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 1]
+
+RFC 6553 RPL Option March 2012
+
+
+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
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 2]
+
+RFC 6553 RPL Option March 2012
+
+
+ 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.
+
+ 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.
+
+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 RFC 2119 [RFC2119].
+
+2. Overview
+
+ 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.
+
+ 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.
+
+3. Format of the RPL Option
+
+ 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:
+
+
+
+
+
+
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 3]
+
+RFC 6553 RPL Option March 2012
+
+
+ 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
+
+ Option Type: 0x63
+
+ Opt Data Len: 8-bit field indicating the length of the option, in
+ octets, excluding the Option Type and Opt Data Len fields.
+
+ 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].
+
+ 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].
+
+ 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].
+
+ 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].
+
+ 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].
+
+ 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.
+
+
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 4]
+
+RFC 6553 RPL Option March 2012
+
+
+ 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.
+
+4. RPL Router Behavior
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 5]
+
+RFC 6553 RPL Option March 2012
+
+
+ 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 routers are responsible for ensuring that a RPL Option 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 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.
+
+ 2. Datagrams destined elsewhere within the same RPL Instance are
+ forwarded to the correct interface.
+
+ 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.
+
+ 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.
+
+5. Security Considerations
+
+ 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.
+
+5.1. DAG Inconsistency Attacks
+
+ 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.
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 6]
+
+RFC 6553 RPL Option March 2012
+
+
+ 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.
+
+5.2. Destination Advertisement Object (DAO) Inconsistency Attacks
+
+ 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.
+
+ 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.
+
+ 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.
+
+6. IANA Considerations
+
+ IANA has assigned a new value in the Destination Options and Hop-by-
+ Hop Options registry. The value is as follows:
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 7]
+
+RFC 6553 RPL Option March 2012
+
+
+7. Acknowledgements
+
+ 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.
+
+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.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [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.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
+ "The Trickle Algorithm", RFC 6206, March 2011.
+
+ [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.
+
+8.2. Informative References
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 8]
+
+RFC 6553 RPL Option March 2012
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hui & Vasseur Standards Track [Page 9]
+