tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6550

 Errata 
Proposed STD
Pages: 157
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ROLL

RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

Part 1 of 6, p. 1 to 13
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                    T. Winter, Ed.
Request for Comments: 6550
Category: Standards Track                                P. Thubert, Ed.
ISSN: 2070-1721                                            Cisco Systems
                                                               A. Brandt
                                                           Sigma Designs
                                                                  J. Hui
                                                   Arch Rock Corporation
                                                               R. Kelsey
                                                       Ember Corporation
                                                                P. Levis
                                                     Stanford University
                                                               K. Pister
                                                           Dust Networks
                                                               R. Struik
                                             Struik Security Consultancy
                                                             JP. Vasseur
                                                           Cisco Systems
                                                            R. Alexander
                                                    Cooper Power Systems
                                                              March 2012


      RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

Abstract

   Low-Power and Lossy Networks (LLNs) are a class of network in which
   both the routers and their interconnect are constrained.  LLN routers
   typically operate with constraints on processing power, memory, and
   energy (battery power).  Their interconnects are characterized by
   high loss rates, low data rates, and instability.  LLNs are comprised
   of anything from a few dozen to thousands of routers.  Supported
   traffic flows include point-to-point (between devices inside the
   LLN), point-to-multipoint (from a central control point to a subset
   of devices inside the LLN), and multipoint-to-point (from devices
   inside the LLN towards a central control point).  This document
   specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks
   (RPL), which provides a mechanism whereby multipoint-to-point traffic
   from devices inside the LLN towards a central control point as well
   as point-to-multipoint traffic from the central control point to the
   devices inside the LLN are supported.  Support for point-to-point
   traffic is also available.

Page 2 
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/rfc6550.

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.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................8
      1.1. Design Principles ..........................................8
      1.2. Expectations of Link-Layer Type ...........................10
   2. Terminology ....................................................10
   3. Protocol Overview ..............................................13
      3.1. Topologies ................................................13
           3.1.1. Constructing Topologies ............................13
           3.1.2. RPL Identifiers ....................................14
           3.1.3. Instances, DODAGs, and DODAG Versions ..............14
      3.2. Upward Routes and DODAG Construction ......................16
           3.2.1. Objective Function (OF) ............................17
           3.2.2. DODAG Repair .......................................17
           3.2.3. Security ...........................................17
           3.2.4. Grounded and Floating DODAGs .......................18
           3.2.5. Local DODAGs .......................................18
           3.2.6. Administrative Preference ..........................18
           3.2.7. Data-Path Validation and Loop Detection ............18
           3.2.8. Distributed Algorithm Operation ....................19
      3.3. Downward Routes and Destination Advertisement .............19
      3.4. Local DODAGs Route Discovery ..............................20
      3.5. Rank Properties ...........................................20
           3.5.1. Rank Comparison (DAGRank()) ........................21
           3.5.2. Rank Relationships .................................22
      3.6. Routing Metrics and Constraints Used by RPL ...............23
      3.7. Loop Avoidance ............................................24
           3.7.1. Greediness and Instability .........................24
           3.7.2. DODAG Loops ........................................26
           3.7.3. DAO Loops ..........................................27
   4. Traffic Flows Supported by RPL .................................27
      4.1. Multipoint-to-Point Traffic ...............................27
      4.2. Point-to-Multipoint Traffic ...............................27
      4.3. Point-to-Point Traffic ....................................27
   5. RPL Instance ...................................................28
      5.1. RPL Instance ID ...........................................29
   6. ICMPv6 RPL Control Message .....................................30
      6.1. RPL Security Fields .......................................32
      6.2. DODAG Information Solicitation (DIS) ......................38
           6.2.1. Format of the DIS Base Object ......................38
           6.2.2. Secure DIS .........................................38
           6.2.3. DIS Options ........................................38
      6.3. DODAG Information Object (DIO) ............................38
           6.3.1. Format of the DIO Base Object ......................39
           6.3.2. Secure DIO .........................................41
           6.3.3. DIO Options ........................................41
      6.4. Destination Advertisement Object (DAO) ....................41
           6.4.1. Format of the DAO Base Object ......................42

Top      ToC       Page 4 
           6.4.2. Secure DAO .........................................43
           6.4.3. DAO Options ........................................43
      6.5. Destination Advertisement Object Acknowledgement
           (DAO-ACK) .................................................43
           6.5.1. Format of the DAO-ACK Base Object ..................44
           6.5.2. Secure DAO-ACK .....................................45
           6.5.3. DAO-ACK Options ....................................45
      6.6. Consistency Check (CC) ....................................45
           6.6.1. Format of the CC Base Object .......................46
           6.6.2. CC Options .........................................47
      6.7. RPL Control Message Options ...............................47
           6.7.1. RPL Control Message Option Generic Format ..........47
           6.7.2. Pad1 ...............................................48
           6.7.3. PadN ...............................................48
           6.7.4. DAG Metric Container ...............................49
           6.7.5. Route Information ..................................50
           6.7.6. DODAG Configuration ................................52
           6.7.7. RPL Target .........................................54
           6.7.8. Transit Information ................................55
           6.7.9. Solicited Information ..............................58
           6.7.10. Prefix Information ................................59
           6.7.11. RPL Target Descriptor .............................63
   7. Sequence Counters ..............................................63
      7.1. Sequence Counter Overview .................................63
      7.2. Sequence Counter Operation ................................64
   8. Upward Routes ..................................................66
      8.1. DIO Base Rules ............................................67
      8.2. Upward Route Discovery and Maintenance ....................67
           8.2.1. Neighbors and Parents within a DODAG Version .......67
           8.2.2. Neighbors and Parents across DODAG Versions ........68
           8.2.3. DIO Message Communication ..........................73
      8.3. DIO Transmission ..........................................74
           8.3.1. Trickle Parameters .................................75
      8.4. DODAG Selection ...........................................75
      8.5. Operation as a Leaf Node ..................................75
      8.6. Administrative Rank .......................................76
   9. Downward Routes ................................................77
      9.1. Destination Advertisement Parents .........................77
      9.2. Downward Route Discovery and Maintenance ..................78
           9.2.1. Maintenance of Path Sequence .......................79
           9.2.2. Generation of DAO Messages .........................79
      9.3. DAO Base Rules ............................................80
      9.4. Structure of DAO Messages .................................80
      9.5. DAO Transmission Scheduling ...............................83
      9.6. Triggering DAO Messages ...................................83
      9.7. Non-Storing Mode ..........................................84
      9.8. Storing Mode ..............................................85
      9.9. Path Control ..............................................86

Top      ToC       Page 5 
           9.9.1. Path Control Example ...............................88
      9.10. Multicast Destination Advertisement Messages .............89
   10. Security Mechanisms ...........................................90
      10.1. Security Overview ........................................90
      10.2. Joining a Secure Network .................................91
      10.3. Installing Keys ..........................................92
      10.4. Consistency Checks .......................................93
      10.5. Counters .................................................93
      10.6. Transmission of Outgoing Packets .........................94
      10.7. Reception of Incoming Packets ............................95
           10.7.1. Timestamp Key Checks ..............................97
      10.8. Coverage of Integrity and Confidentiality ................97
      10.9. Cryptographic Mode of Operation ..........................98
           10.9.1. CCM Nonce .........................................98
           10.9.2. Signatures ........................................99
   11. Packet Forwarding and Loop Avoidance/Detection ................99
      11.1. Suggestions for Packet Forwarding ........................99
      11.2. Loop Avoidance and Detection ............................101
           11.2.1. Source Node Operation ............................102
           11.2.2. Router Operation .................................102
   12. Multicast Operation ..........................................104
   13. Maintenance of Routing Adjacency .............................105
   14. Guidelines for Objective Functions ...........................106
      14.1. Objective Function Behavior .............................106
   15. Suggestions for Interoperation with Neighbor Discovery .......108
   16. Summary of Requirements for Interoperable Implementations ....109
      16.1. Common Requirements .....................................109
      16.2. Operation as a RPL Leaf Node (Only) .....................110
      16.3. Operation as a RPL Router ...............................110
           16.3.1. Support for Upward Routes (Only) .................110
           16.3.2. Support for Upward Routes and Downward
                   Routes in Non-Storing ............................110
           16.3.3. Support for Upward Routes and Downward
                   Routes in Storing Mode ...........................111
      16.4. Items for Future Specification ..........................111
   17. RPL Constants and Variables ..................................112
   18. Manageability Considerations .................................113
      18.1. Introduction ............................................114
      18.2. Configuration Management ................................115
           18.2.1. Initialization Mode ..............................115
           18.2.2. DIO and DAO Base Message and Options
                   Configuration ....................................115
           18.2.3. Protocol Parameters to Be Configured on
                   Every Router in the LLN ..........................116
           18.2.4. Protocol Parameters to Be Configured on
                   Every Non-DODAG-Root .............................117
           18.2.5. Parameters to Be Configured on the DODAG Root ....117

Top      ToC       Page 6 
           18.2.6. Configuration of RPL Parameters Related
                   to DAO-Based Mechanisms ..........................118
           18.2.7. Configuration of RPL Parameters Related
                   to Security Mechanisms ...........................119
           18.2.8. Default Values ...................................119
      18.3. Monitoring of RPL Operation .............................120
           18.3.1. Monitoring a DODAG Parameters ....................120
           18.3.2. Monitoring a DODAG Inconsistencies and
                   Loop Detection ...................................121
      18.4. Monitoring of the RPL Data Structures ...................121
           18.4.1. Candidate Neighbor Data Structure ................121
           18.4.2. Destination-Oriented Directed Acyclic
                   Graph (DODAG) Table ..............................122
           18.4.3. Routing Table and DAO Routing Entries ............122
      18.5. Fault Management ........................................123
      18.6. Policy ..................................................124
      18.7. Fault Isolation .........................................125
      18.8. Impact on Other Protocols ...............................125
      18.9. Performance Management ..................................126
      18.10. Diagnostics ............................................126
   19. Security Considerations ......................................126
      19.1. Overview ................................................126
   20. IANA Considerations ..........................................128
      20.1. RPL Control Message .....................................128
      20.2. New Registry for RPL Control Codes ......................128
      20.3. New Registry for the Mode of Operation (MOP) ............129
      20.4. RPL Control Message Option ..............................130
      20.5. Objective Code Point (OCP) Registry .....................131
      20.6. New Registry for the Security Section Algorithm .........131
      20.7. New Registry for the Security Section Flags .............132
      20.8. New Registry for Per-KIM Security Levels ................132
      20.9. New Registry for DODAG Informational
            Solicitation (DIS) Flags ................................133
      20.10. New Registry for the DODAG Information Object
             (DIO) Flags ............................................134
      20.11. New Registry for the Destination Advertisement
             Object (DAO) Flags .....................................134
      20.12. New Registry for the Destination Advertisement
             Object (DAO) Flags .....................................135
      20.13. New Registry for the Consistency Check (CC) Flags ......135
      20.14. New Registry for the DODAG Configuration Option Flags ..136
      20.15. New Registry for the RPL Target Option Flags ...........136
      20.16. New Registry for the Transit Information Option Flags ..137
      20.17. New Registry for the Solicited Information
             Option Flags ...........................................137
      20.18. ICMPv6: Error in Source Routing Header .................138
      20.19. Link-Local Scope Multicast Address .....................138
   21. Acknowledgements .............................................138

Top      ToC       Page 7 
   22. Contributors .................................................139
   23. References ...................................................139
      23.1. Normative References ....................................139
      23.2. Informative References ..................................140
   Appendix A. Example Operation ....................................143
      A.1. Example Operation in Storing Mode with Node-Owned
           Prefixes .................................................143
           A.1.1. DIO Messages and PIO ..............................144
           A.1.2. DAO Messages ......................................145
           A.1.3. Routing Information Base ..........................145
      A.2. Example Operation in Storing Mode with Subnet-Wide
           Prefix ...................................................146
           A.2.1. DIO Messages and PIO ..............................147
           A.2.2. DAO Messages ......................................148
           A.2.3. Routing Information Base ..........................148
      A.3. Example Operation in Non-Storing Mode with Node-Owned
           Prefixes .................................................149
           A.3.1. DIO Messages and PIO ..............................150
           A.3.2. DAO Messages ......................................150
           A.3.3. Routing Information Base ..........................151
      A.4. Example Operation in Non-Storing Mode with
           Subnet-Wide Prefix .......................................151
           A.4.1. DIO Messages and PIO ..............................152
           A.4.2. DAO Messages ......................................153
           A.4.3. Routing Information Base ..........................153
      A.5. Example with External Prefixes ...........................154

Top      ToC       Page 8 
1.  Introduction

   Low-power and Lossy Networks (LLNs) consist largely of constrained
   nodes (with limited processing power, memory, and sometimes energy
   when they are battery operated or energy scavenging).  These routers
   are interconnected by lossy links, typically supporting only low data
   rates, that are usually unstable with relatively low packet delivery
   rates.  Another characteristic of such networks is that the traffic
   patterns are not simply point-to-point, but in many cases point-to-
   multipoint or multipoint-to-point.  Furthermore, such networks may
   potentially comprise up to thousands of nodes.  These characteristics
   offer unique challenges to a routing solution: the IETF ROLL working
   group has defined application-specific routing requirements for a
   Low-power and Lossy Network (LLN) routing protocol, specified in
   [RFC5867], [RFC5826], [RFC5673], and [RFC5548].

   This document specifies the IPv6 Routing Protocol for LLNs (RPL).
   Note that although RPL was specified according to the requirements
   set forth in the aforementioned requirement documents, its use is in
   no way limited to these applications.

1.1.  Design Principles

   RPL was designed with the objective to meet the requirements spelled
   out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].

   A network may run multiple instances of RPL concurrently.  Each such
   instance may serve different and potentially antagonistic constraints
   or performance criteria.  This document defines how a single instance
   operates.

   In order to be useful in a wide range of LLN application domains, RPL
   separates packet processing and forwarding from the routing
   optimization objective.  Examples of such objectives include
   minimizing energy, minimizing latency, or satisfying constraints.
   This document describes the mode of operation of RPL.  Other
   companion documents specify routing Objective Functions.  A RPL
   implementation, in support of a particular LLN application, will
   include the necessary Objective Function(s) as required by the
   application.

   RPL operations require bidirectional links.  In some LLN scenarios,
   those links may exhibit asymmetric properties.  It is required that
   the reachability of a router be verified before the router can be
   used as a parent.  RPL expects an external mechanism to be triggered
   during the parent selection phase in order to verify link properties
   and neighbor reachability.  Neighbor Unreachability Detection (NUD)
   is such a mechanism, but alternates are possible, including

Top      ToC       Page 9 
   Bidirectional Forwarding Detection (BFD) [RFC5881] and hints from
   lower layers via Layer 2 (L2) triggers like [RFC5184].  In a general
   fashion, a detection mechanism that is reactive to traffic is favored
   in order to minimize the cost of monitoring links that are not being
   used.

   RPL also expects an external mechanism to access and transport some
   control information, referred to as the "RPL Packet Information", in
   data packets.  The RPL Packet Information is defined in Section 11.2
   and enables the association of a data packet with a RPL Instance and
   the validation of RPL routing states.  The RPL option [RFC6553] is an
   example of such mechanism.  The mechanism is required for all packets
   except when strict source routing is used (that is for packets going
   Downward in Non-Storing mode as detailed further in Section 9), which
   by nature prevents endless loops and alleviates the need for the RPL
   Packet Information.  Future companion specifications may propose
   alternate ways to carry the RPL Packet Information in the IPv6
   packets and may extend the RPL Packet Information to support
   additional features.

   RPL provides a mechanism to disseminate information over the
   dynamically formed network topology.  This dissemination enables
   minimal configuration in the nodes, allowing nodes to operate mostly
   autonomously.  This mechanism uses Trickle [RFC6206] to optimize the
   dissemination as described in Section 8.3.

   In some applications, RPL assembles topologies of routers that own
   independent prefixes.  Those prefixes may or may not be aggregatable
   depending on the origin of the routers.  A prefix that is owned by a
   router is advertised as on-link.

   RPL also introduces the capability to bind a subnet together with a
   common prefix and to route within that subnet.  A source can inject
   information about the subnet to be disseminated by RPL, and that
   source is authoritative for that subnet.  Because many LLN links have
   non-transitive properties, a common prefix that RPL disseminates over
   the subnet must not be advertised as on-link.

   In particular, RPL may disseminate IPv6 Neighbor Discovery (ND)
   information such as the [RFC4861] Prefix Information Option (PIO) and
   the [RFC4191] Route Information Option (RIO).  ND information that is
   disseminated by RPL conserves all its original semantics for router
   to host, with limited extensions for router to router, though it is
   not to be confused with routing advertisements and it is never to be
   directly redistributed in another routing protocol.  A RPL node often
   combines host and router behaviors.  As a host, it will process the
   options as specified in [RFC4191], [RFC4861], [RFC4862], and
   [RFC6275].  As a router, the RPL node may advertise the information

Top      ToC       Page 10 
   from the options as required for the specific link, for instance, in
   an ND Router Advertisement (RA) message, though the exact operation
   is out of scope.

   A set of companion documents to this specification will provide
   further guidance in the form of applicability statements specifying a
   set of operating points appropriate to the Building Automation, Home
   Automation, Industrial, and Urban application scenarios.

1.2.  Expectations of Link-Layer Type

   In compliance with the layered architecture of IP, RPL does not rely
   on any particular features of a specific link-layer technology.  RPL
   is designed to be able to operate over a variety of different link
   layers, including ones that are constrained, potentially lossy, or
   typically utilized in conjunction with highly constrained host or
   router devices, such as but not limited to, low-power wireless or PLC
   (Power Line Communication) technologies.

   Implementers may find [RFC3819] a useful reference when designing a
   link-layer interface between RPL and a particular link-layer
   technology.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   Additionally, this document uses terminology from [ROLL-TERMS], and
   introduces the following terminology:

   DAG: Directed Acyclic Graph.  A directed graph having the property
         that all edges are oriented in such a way that no cycles exist.
         All edges are contained in paths oriented toward and
         terminating at one or more root nodes.

   DAG root: A DAG root is a node within the DAG that has no outgoing
         edge.  Because the graph is acyclic, by definition, all DAGs
         must have at least one DAG root and all paths terminate at a
         DAG root.

   Destination-Oriented DAG (DODAG): A DAG rooted at a single
         destination, i.e., at a single DAG root (the DODAG root) with
         no outgoing edges.

Top      ToC       Page 11 
   DODAG root: A DODAG root is the DAG root of a DODAG.  The DODAG root
         may act as a border router for the DODAG; in particular, it may
         aggregate routes in the DODAG and may redistribute DODAG routes
         into other routing protocols.

   Virtual DODAG root: A Virtual DODAG root is the result of two or more
         RPL routers, for instance, 6LoWPAN Border Routers (6LBRs),
         coordinating to synchronize DODAG state and act in concert as
         if they are a single DODAG root (with multiple interfaces),
         with respect to the LLN.  The coordination most likely occurs
         between powered devices over a reliable transit link, and the
         details of that scheme are out of scope for this specification
         (to be defined in future companion specifications).

   Up:  Up refers to the direction from leaf nodes towards DODAG roots,
         following DODAG edges.  This follows the common terminology
         used in graphs and depth-first-search, where vertices further
         from the root are "deeper" or "down" and vertices closer to the
         root are "shallower" or "up".

   Down: Down refers to the direction from DODAG roots towards leaf
         nodes, in the reverse direction of DODAG edges.  This follows
         the common terminology used in graphs and depth-first-search,
         where vertices further from the root are "deeper" or "down" and
         vertices closer to the root are "shallower" or "up".

   Rank: A node's Rank defines the node's individual position relative
         to other nodes with respect to a DODAG root.  Rank strictly
         increases in the Down direction and strictly decreases in the
         Up direction.  The exact way Rank is computed depends on the
         DAG's Objective Function (OF).  The Rank may analogously track
         a simple topological distance, may be calculated as a function
         of link metrics, and may consider other properties such as
         constraints.

   Objective Function (OF): An OF defines how routing metrics,
         optimization objectives, and related functions are used to
         compute Rank.  Furthermore, the OF dictates how parents in the
         DODAG are selected and, thus, the DODAG formation.

   Objective Code Point (OCP): An OCP is an identifier that indicates
         which Objective Function the DODAG uses.

   RPLInstanceID: A RPLInstanceID is a unique identifier within a
         network.  DODAGs with the same RPLInstanceID share the same
         Objective Function.

Top      ToC       Page 12 
   RPL Instance: A RPL Instance is a set of one or more DODAGs that
         share a RPLInstanceID.  At most, a RPL node can belong to one
         DODAG in a RPL Instance.  Each RPL Instance operates
         independently of other RPL Instances.  This document describes
         operation within a single RPL Instance.

   DODAGID: A DODAGID is the identifier of a DODAG root.  The DODAGID is
         unique within the scope of a RPL Instance in the LLN.  The
         tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.

   DODAG Version: A DODAG Version is a specific iteration ("Version") of
         a DODAG with a given DODAGID.

   DODAGVersionNumber: A DODAGVersionNumber is a sequential counter that
         is incremented by the root to form a new Version of a DODAG.  A
         DODAG Version is identified uniquely by the (RPLInstanceID,
         DODAGID, DODAGVersionNumber) tuple.

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

   DODAG parent: A parent of a node within a DODAG is one of the
         immediate successors of the node on a path towards the DODAG
         root.  A DODAG parent's Rank is lower than the node's.  (See
         Section 3.5.1).

   Sub-DODAG: The sub-DODAG of a node is the set of other nodes whose
         paths to the DODAG root pass through that node.  Nodes in the
         sub-DODAG of a node have a greater Rank than that node.  (See
         Section 3.5.1).

   Local DODAG: Local DODAGs contain one and only one root node, and
         they allow that single root node to allocate and manage a RPL
         Instance, identified by a local RPLInstanceID, without

Top      ToC       Page 13 
         coordination with other nodes.  Typically, this is done in
         order to optimize routes to a destination within the LLN.  (See
         Section 5).

   Global DODAG: A Global DODAG uses a global RPLInstanceID that may be
         coordinated among several other nodes.  (See Section 5).

   DIO: DODAG Information Object (see Section 6.3)

   DAO: Destination Advertisement Object (see Section 6.4)

   DIS: DODAG Information Solicitation (see Section 6.2)

   CC: Consistency Check (see Section 6.6)

   As they form networks, LLN devices often mix the roles of host and
   router when compared to traditional IP networks.  In this document,
   "host" refers to an LLN device that can generate but does not forward
   RPL traffic; "router" refers to an LLN device that can forward as
   well as generate RPL traffic; and "node" refers to any RPL device,
   either a host or a router.



(page 13 continued on part 2)

Next RFC Part