RFC 6553

The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams

📅 published March 2012, from ietf

RFC 6553 part 1 💖

okay bestie, this one is RFC 6553, and it's giving main character energy ✨ The title is "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" 🎀 It's by J. Hui and JP. Vasseur, both at Cisco Systems. It's a Standards Track doc, ISSN 2070-1721, dated March 2012. The title block doesn't list anything it obsoletes or updates, so it's a clean slate 🧚

Abstract

RPL includes routing info inside data-plane datagrams so it can spot routing inconsistencies fast 🔥 This doc describes the RPL Option, which RPL routers use to carry that routing info around.

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6553 🦋

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) as in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶

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 🌸

okay so RPL is a distance vector IPv6 routing protocol made for Low-Power and Lossy Networks (LLNs) [RFC6550]. These networks are usually tight on energy and/or channel capacity, so every bit of resource matters ⭐ That means a routing protocol has to send control traffic sparingly. The annoying part is that it also needs to spread new routing info quickly so inconsistencies get fixed fast. Major tension, iykyk 😭

Here's how RPL handles it. It uses a slow proactive process to build and maintain the routing topology, but a reactive and dynamic process to resolve inconsistencies 💅 In the steady state, RPL keeps the topology going with a low-rate beaconing process. When RPL detects inconsistencies that might stop datagrams from being delivered properly, it temporarily ups the beacon rate so the problem gets fixed quickly 🔥 This dynamic rate control is governed by dynamic timers, also called "Trickle" timers, defined in [RFC6206] 🧚

Now the glow-up: other routing protocols (like OSPF [RFC2328]) detect routing inconsistencies in other ways, but RPL does data-path verification by putting routing info inside the datagram itself 💖 Because of this, repair mechanisms only run when they're actually needed, so the control and data planes can work on similar time scales. The main reason for data-path verification in LLNs is that control-plane traffic should be carefully bounded relative to data traffic. Honestly, there's no point fixing routing issues (which may be temporary) when there's no data traffic to care about 🙈

RPL builds a Directed Acyclic Graph (DAG) that tries to minimize path costs to the DAG root, following a set of metrics and Objective Functions 🌈 Loops can happen in some situations, so RPL is designed to use a data-path loop detection method. That's one of the known requirements of RPL, and other data-path usages might get defined later 🦋

So this doc defines a new IPv6 option, called the RPL Option, which gets carried within the IPv6 Hop-by-Hop header 👑 The RPL Option is only for use between RPL routers participating in the same RPL Instance, so it stays in its own friend group 🫶

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 gives routers a way to include routing info with each datagram they forward 💅 When RPL routers receive datagrams carrying routing info, they process it to help keep the routing topology healthy ✨

Every RPL router along a packet's delivery path processes and updates the RPL Option 🔥 If the received packet doesn't already have a RPL Option, the RPL router must insert one before forwarding it to another RPL router. This doc also specifies using IPv6-in-IPv6 tunneling [RFC2473] when attaching a RPL Option to a packet. Tunneling is the move here because it keeps the original packet unmodified, and it makes ICMP errors return to the RPL Option source instead of 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, sitting right after the IPv6 header. It has an alignment requirement of 2n. The option looks like this:

   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

Here's what each field means, babe 💜

  • Option Type: 0x63
  • Opt Data Len: an 8-bit field indicating the length of the option, in octets, excluding the Option Type and Opt Data Len fields.
  • Down 'O': a 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': a 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': a 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: an 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: a 16-bit field as defined in Section 11.2 of [RFC6550]. The processing SHALL follow the rules described in Section 11.2 of [RFC6550].

Okay, the rules for the first bits 🔥 The two high order bits of the Option Type MUST be set to '01', and the third bit is equal to '1'. Because of these bits, according to [RFC2460], nodes that don't understand this option on a received packet MUST discard the packet 😭 Also, according to [RFC2460], the values inside the RPL Option are expected to change en route. The RPL Option Data Length is variable 🌈

The action taken when using the RPL Option, and the potential set of sub-TLVs carried inside it, MUST be specified by the RFC of the protocol that uses that option. No sub-TLVs are defined in this document. An RPL device MUST skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after them 🫶

4. RPL Router Behavior 🦋

okay so datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([RFC6554]), and they MAY include both 💅. a datagram with a Source Routing Header (SRH) doesn't need a RPL Option, bc both the source and the intermediate routers make sure the SRH has no loops 🔁✨.

when the router is the source of the original packet and the destination is known to be in the same RPL Instance, the router SHOULD put the RPL Option directly in the original packet 🎀. otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and put the RPL Option in the tunnel header 🫶. tunneling is giving because the delivered datagram stays unmodified, and ICMPv6 errors caused by a RPL Option get sent back to the router that made the RPL Option 😭🔥.

a RPL router picks the next RPL router that should handle the original packet as the tunnel exit-point 🧚. sometimes the exit-point is the final RPL router on the path to the destination, so the original packet only goes through one tunnel. one example is when the final destination or its attachment router is known to be in the same RPL Instance 👑.

other times the exit-point is NOT the final RPL router, so the packet might go through multiple tunnels to reach its destination 🌈. one example is when a RPL router is just forwarding a packet to one of its Destination-Oriented DAG (DODAG) parents 💜. in that case the RPL router sets the tunnel exit-point to a DODAG parent. when it forwards the original packet hop-by-hop, the RPL router only decides the next hop toward the destination 🍓.

a RPL router that gets an IPv6-in-IPv6 packet destined to it handles the tunnel packet the way Section 3 of [RFC2473] describes ✨. before IPv6 decapsulation, the RPL router MUST process the RPL Option, if there is one 🙈. after decapsulation, if the router decides to forward the original packet to another RPL router, it MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to include the RPL Option 💖. fields in the RPL Option that don't change hop-by-hop MUST stay the same as what came in from the prior tunnel 🌸.

RPL routers are responsible for making sure a RPL Option is only used between RPL routers 👑:

  1. for datagrams destined to a RPL router, the router handles the packet in the usual way 💅. like, if the RPL Option was included in tunneled mode and the RPL router is the tunnel endpoint, it removes the outer IPv6 header and the RPL Option at the same time 🎀.
  2. datagrams destined elsewhere in the same RPL Instance get forwarded out the correct interface 🦋.
  3. datagrams destined to nodes outside the RPL Instance get dropped if the outermost IPv6 header has a RPL Option that the forwarding RPL router didn't generate 😭.

to avoid fragmentation, it's desirable to use 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 actually take advantage of this, though, the communicating endpoints need to know the MTU along the path (i.e., through Path MTU Discovery) 🔍. unfortunately the larger MTU may not be available on every link (e.g., 1280 octets on IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) links) 🥺. still, a lot of traffic on these networks is way smaller than the MTU, so the performance hit from fragmentation would be limited 💜✨.

5. Security Considerations 💀

The RPL Option helps RPL routers spot 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 make RPL routers think a DAG inconsistency exists within the RPL Instance identified by the RPLInstanceID field 👀. this attack would make a RPL router reset its DODAG Information Object (DIO) Trickle timer and start sending DIO messages more often 🚨.

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 more 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 helps RPL routers clean up stale Downward routing state by using the Forwarding-Error 'F' flag to say a datagram couldn't be delivered by a child and is being sent back to try a different child 🔄. but using this flag, an attacker can make a RPL router throw away Downward routing state 💀.

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 more 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 don't keep Downward routing state, the RPL Option CANNOT be used to mount these attacks 🙅‍♀️✨.

6. IANA Considerations 🎀

IANA has assigned a new value in the Destination Options and Hop-by-Hop Options registry 📋. the value is:

Hex Value     Binary Value
              act  chg  rest     Description        Reference
---------     ---  ---  -------  -----------------  ----------
  0x63         01    1   00011   RPL Option         [RFC6553]

as specified in [RFC2460], the first two bits mean the IPv6 node MUST discard the packet if it doesn't recognize the option type, and the third bit says 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 MUST be between 0 and 255, inclusive 🔢.

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.

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
📦 where this page comes from