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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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