tech-invite   World Map     

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

RFC 6550

 
 
 

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

Part 6 of 6, p. 126 to 157
Prev RFC Part

 


prevText      Top      Up      ToC       Page 126 
19.  Security Considerations

19.1.  Overview

   From a security perspective, RPL networks are no different from any
   other network.  They are vulnerable to passive eavesdropping attacks
   and, potentially, even active tampering when physical access to a
   wire is not required to participate in communications.  The very
   nature of ad hoc networks and their cost objectives impose additional
   security constraints, which perhaps make these networks the most
   difficult environments to secure.  Devices are low-cost and have
   limited capabilities in terms of computing power, available storage,
   and power drain; it cannot always be assumed they have a trusted
   computing base or a high-quality random number generator aboard.

Top      Up      ToC       Page 127 
   Communications cannot rely on the online availability of a fixed
   infrastructure and might involve short-term relationships between
   devices that may never have communicated before.  These constraints
   might severely limit the choice of cryptographic algorithms and
   protocols and influence the design of the security architecture
   because the establishment and maintenance of trust relationships
   between devices need to be addressed with care.  In addition, battery
   lifetime and cost constraints put severe limits on the security
   overhead these networks can tolerate, something that is of far less
   concern with higher bandwidth networks.  Most of these security
   architectural elements can be implemented at higher layers and may,
   therefore, be considered to be out of scope for this specification.
   Special care, however, needs to be exercised with respect to
   interfaces to these higher layers.

   The security mechanisms in this standard are based on symmetric-key
   and public-key cryptography and use keys that are to be provided by
   higher-layer processes.  The establishment and maintenance of these
   keys are out of scope for this specification.  The mechanisms assume
   a secure implementation of cryptographic operations and secure and
   authentic storage of keying material.

   The security mechanisms specified provide particular combinations of
   the following security services:

   Data confidentiality: Assurance that transmitted information is only
         disclosed to parties for which it is intended.

   Data authenticity: Assurance of the source of transmitted information
         (and, hereby, that information was not modified in transit).

   Replay protection: Assurance that a duplicate of transmitted
         information is detected.

   Timeliness (delay protection):  Assurance that transmitted
         information was received in a timely manner.

   The actual protection provided can be adapted on a per-packet basis
   and allows for varying levels of data authenticity (to minimize
   security overhead in transmitted packets where required) and for
   optional data confidentiality.  When nontrivial protection is
   required, replay protection is always provided.

   Replay protection is provided via the use of a non-repeating value
   (CCM nonce) in the packet protection process and storage of some
   status information (originating device and the CCM nonce counter last
   received from that device), which allows detection of whether this
   particular CCM nonce value was used previously by the originating

Top      Up      ToC       Page 128 
   device.  In addition, so-called delay protection is provided amongst
   those devices that have a loosely synchronized clock on board.  The
   acceptable time delay can be adapted on a per-packet basis and allows
   for varying latencies (to facilitate longer latencies in packets
   transmitted over a multi-hop communication path).

   Cryptographic protection may use a key shared between two peer
   devices (link key) or a key shared among a group of devices (group
   key), thus allowing some flexibility and application-specific trade-
   offs between key storage and key maintenance costs versus the
   cryptographic protection provided.  If a group key is used for peer-
   to-peer communication, protection is provided only against outsider
   devices and not against potential malicious devices in the key-
   sharing group.

   Data authenticity may be provided using symmetric-key-based or
   public-key-based techniques.  With public-key-based techniques (via
   signatures), one corroborates evidence as to the unique originator of
   transmitted information, whereas with symmetric-key-based techniques,
   data authenticity is only provided relative to devices in a key-
   sharing group.  Thus, public-key-based authentication may be useful
   in scenarios that require a more fine-grained authentication than can
   be provided with symmetric-key-based authentication techniques alone,
   such as with group communications (broadcast, multicast) or in
   scenarios that require non-repudiation.

20.  IANA Considerations

20.1.  RPL Control Message

   The RPL control message is an ICMP information message type that is
   to be used carry DODAG Information Objects, DODAG Information
   Solicitations, and Destination Advertisement Objects in support of
   RPL operation.

   IANA has defined an ICMPv6 Type Number Registry.  The type value for
   the RPL control message is 155.

20.2.  New Registry for RPL Control Codes

   IANA has created a registry, RPL Control Codes, for the Code field of
   the ICMPv6 RPL control message.

   New codes may be allocated only by an IETF Review.  Each code is
   tracked with the following qualities:

   o  Code

Top      Up      ToC       Page 129 
   o  Description

   o  Defining RFC

   The following codes are currently defined:

   +------+----------------------------------------------+-------------+
   | Code | Description                                  | Reference   |
   +------+----------------------------------------------+-------------+
   | 0x00 | DODAG Information Solicitation               | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x01 | DODAG Information Object                     | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x02 | Destination Advertisement Object             | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x03 | Destination Advertisement Object             | This        |
   |      | Acknowledgment                               | document    |
   |      |                                              |             |
   | 0x80 | Secure DODAG Information Solicitation        | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x81 | Secure DODAG Information Object              | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x82 | Secure Destination Advertisement Object      | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x83 | Secure Destination Advertisement Object      | This        |
   |      | Acknowledgment                               | document    |
   |      |                                              |             |
   | 0x8A | Consistency Check                            | This        |
   |      |                                              | document    |
   +------+----------------------------------------------+-------------+

                             RPL Control Codes

20.3.  New Registry for the Mode of Operation (MOP)

   IANA has created a registry for the 3-bit Mode of Operation (MOP),
   which is contained in the DIO Base.

   New values may be allocated only by an IETF Review.  Each value is
   tracked with the following qualities:

   o  Mode of Operation Value

Top      Up      ToC       Page 130 
   o  Capability description

   o  Defining RFC

   Four values are currently defined:

   +----------+------------------------------------------+-------------+
   |    MOP   | Description                              | Reference   |
   |   value  |                                          |             |
   +----------+------------------------------------------+-------------+
   |     0    | No Downward routes maintained by RPL     | This        |
   |          |                                          | document    |
   |          |                                          |             |
   |     1    | Non-Storing Mode of Operation            | This        |
   |          |                                          | document    |
   |          |                                          |             |
   |     2    | Storing Mode of Operation with no        | This        |
   |          | multicast support                        | document    |
   |          |                                          |             |
   |     3    | Storing Mode of Operation with multicast | This        |
   |          | support                                  | document    |
   +----------+------------------------------------------+-------------+

                           DIO Mode of Operation

   The rest of the range, decimal 4 to 7, is currently unassigned.

20.4.  RPL Control Message Options

   IANA has created a registry for the RPL Control Message Options.

   New values may be allocated only by an IETF Review.  Each value is
   tracked with the following qualities:

   o  Value

   o  Meaning

   o  Defining RFC

Top      Up      ToC       Page 131 
             +-------+-----------------------+---------------+
             | Value | Meaning               | Reference     |
             +-------+-----------------------+---------------+
             |  0x00 | Pad1                  | This document |
             |       |                       |               |
             |  0x01 | PadN                  | This document |
             |       |                       |               |
             |  0x02 | DAG Metric Container  | This Document |
             |       |                       |               |
             |  0x03 | Routing Information   | This Document |
             |       |                       |               |
             |  0x04 | DODAG Configuration   | This Document |
             |       |                       |               |
             |  0x05 | RPL Target            | This Document |
             |       |                       |               |
             |  0x06 | Transit Information   | This Document |
             |       |                       |               |
             |  0x07 | Solicited Information | This Document |
             |       |                       |               |
             |  0x08 | Prefix Information    | This Document |
             |       |                       |               |
             |  0x09 | Target Descriptor     | This Document |
             +-------+-----------------------+---------------+

                        RPL Control Message Options

20.5.  Objective Code Point (OCP) Registry

   IANA has created a registry to manage the codespace of the Objective
   Code Point (OCP) field.

   No OCPs are defined in this specification.

   New codes may be allocated only by an IETF Review.  Each code is
   tracked with the following qualities:

   o  Code

   o  Description

   o  Defining RFC

20.6.  New Registry for the Security Section Algorithm

   IANA has created a registry for the values of the 8-bit Algorithm
   field in the Security section.

Top      Up      ToC       Page 132 
   New values may be allocated only by an IETF Review.  Each value is
   tracked with the following qualities:

   o  Value

   o  Encryption/MAC

   o  Signature

   o  Defining RFC

   The following value is currently defined:

      +-------+------------------+------------------+---------------+
      | Value | Encryption/MAC   | Signature        | Reference     |
      +-------+------------------+------------------+---------------+
      |   0   | CCM with AES-128 | RSA with SHA-256 | This document |
      +-------+------------------+------------------+---------------+

                        Security Section Algorithm

20.7.  New Registry for the Security Section Flags

   IANA has created a registry for the 8-bit Security Section Flags
   field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bit is currently defined for the Security Section Flags field.

20.8.  New Registry for Per-KIM Security Levels

   IANA has created one registry for the 3-bit Security Level (LVL)
   field per allocated KIM value.

   For a given KIM value, new levels may be allocated only by an IETF
   Review.  Each level is tracked with the following qualities:

   o  Level

   o  KIM value

Top      Up      ToC       Page 133 
   o  Description

   o  Defining RFC

   The following levels per KIM value are currently defined:

           +-------+-----------+---------------+---------------+
           | Level | KIM value | Description   | Reference     |
           +-------+-----------+---------------+---------------+
           |   0   |     0     | See Figure 11 | This document |
           |       |           |               |               |
           |   1   |     0     | See Figure 11 | This document |
           |       |           |               |               |
           |   2   |     0     | See Figure 11 | This document |
           |       |           |               |               |
           |   3   |     0     | See Figure 11 | This document |
           |       |           |               |               |
           |   0   |     1     | See Figure 11 | This document |
           |       |           |               |               |
           |   1   |     1     | See Figure 11 | This document |
           |       |           |               |               |
           |   2   |     1     | See Figure 11 | This document |
           |       |           |               |               |
           |   3   |     1     | See Figure 11 | This document |
           |       |           |               |               |
           |   0   |     2     | See Figure 11 | This document |
           |       |           |               |               |
           |   1   |     2     | See Figure 11 | This document |
           |       |           |               |               |
           |   2   |     2     | See Figure 11 | This document |
           |       |           |               |               |
           |   3   |     2     | See Figure 11 | This document |
           |       |           |               |               |
           |   0   |     3     | See Figure 11 | This document |
           |       |           |               |               |
           |   1   |     3     | See Figure 11 | This document |
           |       |           |               |               |
           |   2   |     3     | See Figure 11 | This document |
           |       |           |               |               |
           |   3   |     3     | See Figure 11 | This document |
           +-------+-----------+---------------+---------------+

                          Per-KIM Security Levels

20.9.  New Registry for DODAG Informational Solicitation (DIS) Flags

   IANA has created a registry for the DIS (DODAG Informational
   Solicitation) Flags field.

Top      Up      ToC       Page 134 
   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bit is currently defined for the DIS (DODAG Informational
   Solicitation) Flags field.

20.10.  New Registry for the DODAG Information Object (DIO) Flags

   IANA has created a registry for the 8-bit DODAG Information Object
   (DIO) Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bit is currently defined for the DIS (DODAG Informational
   Solicitation) Flags.

20.11.  New Registry for the Destination Advertisement Object (DAO)
        Flags

   IANA has created a registry for the 8-bit Destination Advertisement
   Object (DAO) Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

Top      Up      ToC       Page 135 
   The following bits are currently defined:

       +------------+------------------------------+---------------+
       | Bit number | Description                  | Reference     |
       +------------+------------------------------+---------------+
       |      0     | DAO-ACK request (K)          | This document |
       |            |                              |               |
       |      1     | DODAGID field is present (D) | This document |
       +------------+------------------------------+---------------+

                              DAO Base Flags

20.12.  New Registry for the Destination Advertisement Object (DAO)
        Acknowledgement Flags

   IANA has created a registry for the 8-bit Destination Advertisement
   Object (DAO) Acknowledgement Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following bit is currently defined:

       +------------+------------------------------+---------------+
       | Bit number | Description                  | Reference     |
       +------------+------------------------------+---------------+
       |      0     | DODAGID field is present (D) | This document |
       +------------+------------------------------+---------------+

                            DAO-ACK Base Flags

20.13.  New Registry for the Consistency Check (CC) Flags

   IANA has created a registry for the 8-bit Consistency Check (CC)
   Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

Top      Up      ToC       Page 136 
   o  Defining RFC

   The following bit is currently defined:

             +------------+-----------------+---------------+
             | Bit number | Description     | Reference     |
             +------------+-----------------+---------------+
             |      0     | CC Response (R) | This document |
             +------------+-----------------+---------------+

                       Consistency Check Base Flags

20.14.  New Registry for the DODAG Configuration Option Flags

   IANA has created a registry for the 8-bit DODAG Configuration Option
   Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following bits are currently defined:

        +------------+----------------------------+---------------+
        | Bit number | Description                | Reference     |
        +------------+----------------------------+---------------+
        |      4     | Authentication Enabled (A) | This document |
        |     5-7    | Path Control Size (PCS)    | This document |
        +------------+----------------------------+---------------+

                     DODAG Configuration Option Flags

20.15.  New Registry for the RPL Target Option Flags

   IANA has created a registry for the 8-bit RPL Target Option Flags
   field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

Top      Up      ToC       Page 137 
   o  Defining RFC

   No bit is currently defined for the RPL Target Option Flags.

20.16.  New Registry for the Transit Information Option Flags

   IANA has created a registry for the 8-bit Transit Information Option
   (TIO) Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following bits are currently defined:

               +------------+--------------+---------------+
               | Bit number | Description  | Reference     |
               +------------+--------------+---------------+
               |      0     | External (E) | This document |
               +------------+--------------+---------------+

                     Transit Information Option Flags

20.17.  New Registry for the Solicited Information Option Flags

   IANA has created a registry for the 8-bit Solicited Information
   Option (SIO) Flags field.

   New bit numbers may be allocated only by an IETF Review.  Each bit is
   tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

Top      Up      ToC       Page 138 
   The following bits are currently defined:

      +------------+--------------------------------+---------------+
      | Bit number | Description                    | Reference     |
      +------------+--------------------------------+---------------+
      |      0     | Version Predicate match (V)    | This document |
      |            |                                |               |
      |      1     | InstanceID Predicate match (I) | This document |
      |            |                                |               |
      |      2     | DODAGID Predicate match (D)    | This document |
      +------------+--------------------------------+---------------+

                    Solicited Information Option Flags

20.18.  ICMPv6: Error in Source Routing Header

   In some cases RPL will return an ICMPv6 error message when a message
   cannot be delivered as specified by its source routing header.  This
   ICMPv6 error message is "Error in Source Routing Header".

   IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
   Types.  ICMPv6 Message Type 1 describes "Destination Unreachable"
   codes.  The "Error in Source Routing Header" code is has been
   allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message
   Type 1, with a code value of 7.

20.19.  Link-Local Scope Multicast Address

   The rules for assigning new IPv6 multicast addresses are defined in
   [RFC3307].  This specification requires the allocation of a new
   permanent multicast address with a link-local scope for RPL nodes
   called all-RPL-nodes, with a value of ff02::1a.

21.  Acknowledgements

   The authors would like to acknowledge the review, feedback, and
   comments from Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir,
   Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa Dohler, Mathilde
   Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Mukul
   Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Ajay Kumar,
   Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu,
   Joseph Reddy, Michael Richardson, Don Sturek, Joydeep Tripathi, and
   Nicolas Tsiftes.

   The authors would like to acknowledge the guidance and input provided
   by the ROLL Chairs, David Culler and JP. Vasseur, and the Area
   Director, Adrian Farrel.

Top      Up      ToC       Page 139 
   The authors would like to acknowledge prior contributions of Robert
   Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
   Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
   Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon,
   Jim Bound, Yanick Pouffary, Henning Rogge, and Arsalan Tavakoli, who
   have provided useful design considerations to RPL.

   RPL Security Design, found in Section 10, Section 19, and elsewhere
   throughout the document, is primarily the contribution of the
   Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
   Levis, Kris Pister, Rene Struik, and Adrian Farrel.

   Thanks also to Jari Arkko and Ralph Droms for their attentive
   reviews, especially with respect to interoperability considerations
   and integration with other IETF specifications.

22.  Contributors

   Stephen Dawson-Haggerty
   UC Berkeley
   Soda Hall
   Berkeley, CA  94720
   USA

   EMail: stevedh@cs.berkeley.edu

23.  References

23.1.  Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC3447]     Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                 Standards (PKCS) #1: RSA Cryptography Specifications
                 Version 2.1", RFC 3447, February 2003.

   [RFC4191]     Draves, R. and D. Thaler, "Default Router Preferences
                 and More-Specific Routes", RFC 4191, November 2005.

   [RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
                 December 2005.

Top      Up      ToC       Page 140 
   [RFC4443]     Conta, A., Deering, S., and M. Gupta, "Internet Control
                 Message Protocol (ICMPv6) for the Internet Protocol
                 Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4861]     Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
                 September 2007.

   [RFC4862]     Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
                 Address Autoconfiguration", RFC 4862, September 2007.

   [RFC6206]     Levis, P., Clausen, T., Hui, J., Gnawali, O., and J.
                 Ko, "The Trickle Algorithm", RFC 6206, March 2011.

   [RFC6275]     Perkins, C., Johnson, D., and J. Arkko, "Mobility
                 Support in IPv6", RFC 6275, July 2011.

   [RFC6551]     Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean,
                 N., and D. Barthel, "Routing Metrics Used for Path
                 Calculation in Low-Power and Lossy Networks", RFC 6551,
                 March 2012.

   [RFC6552]     Thubert, P., Ed., "Objective Function Zero for the
                 Routing Protocol for Low-Power and Lossy Networks
                 (RPL)", RFC 6552, March 2012.

   [RFC6553]     Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
                 Power and Lossy Networks (RPL) Option for Carrying RPL
                 Information in Data-Plane Datagrams", RFC 6553,
                 March 2012.

   [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.

23.2.  Informative References

   [6LOWPAN-ND]  Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark,
                 "Neighbor Discovery Optimization for Low Power and
                 Lossy Networks (6LoWPAN)", Work in Progress,
                 October 2011.

   [FIPS180]     National Institute of Standards and Technology, "FIPS
                 Pub 180-3, Secure Hash Standard (SHS)", US Department
                 of Commerce , February 2008,
                 <http://www.nist.gov/itl/upload/fips180-3_final.pdf>.

Top      Up      ToC       Page 141 
   [Perlman83]   Perlman, R., "Fault-Tolerant Broadcast of Routing
                 Information", North-Holland Computer Networks,
                 Vol.7: p. 395-405, December 1983.

   [RFC1958]     Carpenter, B., "Architectural Principles of the
                 Internet", RFC 1958, June 1996.

   [RFC1982]     Elz, R. and R. Bush, "Serial Number Arithmetic",
                 RFC 1982, August 1996.

   [RFC2578]     McCloghrie, K., Ed., Perkins, D., Ed., and J.
                 Schoenwaelder, Ed., "Structure of Management
                 Information Version 2 (SMIv2)", STD 58, RFC 2578,
                 April 1999.

   [RFC3307]     Haberman, B., "Allocation Guidelines for IPv6 Multicast
                 Addresses", RFC 3307, August 2002.

   [RFC3410]     Case, J., Mundy, R., Partain, D., and B. Stewart,
                 "Introduction and Applicability Statements for
                 Internet-Standard Management Framework", RFC 3410,
                 December 2002.

   [RFC3535]     Schoenwaelder, J., "Overview of the 2002 IAB Network
                 Management Workshop", RFC 3535, May 2003.

   [RFC3610]     Whiting, D., Housley, R., and N. Ferguson, "Counter
                 with CBC-MAC (CCM)", RFC 3610, September 2003.

   [RFC3819]     Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
                 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
                 L. Wood, "Advice for Internet Subnetwork Designers",
                 BCP 89, RFC 3819, July 2004.

   [RFC4101]     Rescorla, E. and IAB, "Writing Protocol Models",
                 RFC 4101, June 2005.

   [RFC4915]     Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
                 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
                 RFC 4915, June 2007.

   [RFC5120]     Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
                 Topology (MT) Routing in Intermediate System to
                 Intermediate Systems (IS-ISs)", RFC 5120,
                 February 2008.

Top      Up      ToC       Page 142 
   [RFC5184]     Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
                 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
                 (L3)-Driven Fast Handover", RFC 5184, May 2008.

   [RFC5548]     Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
                 "Routing Requirements for Urban Low-Power and Lossy
                 Networks", RFC 5548, May 2009.

   [RFC5673]     Pister, K., Thubert, P., Dwars, S., and T. Phinney,
                 "Industrial Routing Requirements in Low-Power and Lossy
                 Networks", RFC 5673, October 2009.

   [RFC5706]     Harrington, D., "Guidelines for Considering Operations
                 and Management of New Protocols and Protocol
                 Extensions", RFC 5706, November 2009.

   [RFC5826]     Brandt, A., Buron, J., and G. Porcu, "Home Automation
                 Routing Requirements in Low-Power and Lossy Networks",
                 RFC 5826, April 2010.

   [RFC5867]     Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
                 "Building Automation Routing Requirements in Low-Power
                 and Lossy Networks", RFC 5867, June 2010.

   [RFC5881]     Katz, D. and D. Ward, "Bidirectional Forwarding
                 Detection (BFD) for IPv4 and IPv6 (Single Hop)",
                 RFC 5881, June 2010.

   [RFC6130]     Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
                 Network (MANET) Neighborhood Discovery Protocol
                 (NHDP)", RFC 6130, April 2011.

   [ROLL-TERMS]  Vasseur, J., "Terminology in Low power And Lossy
                 Networks", Work in Progress, September 2011.

Top      Up      ToC       Page 143 
Appendix A.  Example Operation

   This appendix provides some examples to illustrate the dissemination
   of addressing information and prefixes with RPL.  The examples depict
   information being distributed with PIOs and RIOs and the use of DIO
   and DAO messages.  Note that this appendix is not normative, and that
   the specific details of a RPL addressing plan and autoconfiguration
   may vary according to specific implementations.  RPL merely provides
   a vehicle for disseminating information that may be built upon and
   used by other mechanisms.

   Note that these examples illustrate use of address autoconfiguration
   schemes supported by information distributed within RPL.  However, if
   an implementation includes another address autoconfiguration scheme,
   RPL nodes might be configured not to set the 'A' flag in PIO options,
   though the PIO can still be used to distribute prefix and addressing
   information.

A.1.  Example Operation in Storing Mode with Node-Owned Prefixes

   Figure 32 illustrates the logical addressing architecture of a simple
   RPL network operating in Storing mode.  In this example, each Node,
   A, B, C, and D, owns its own prefix and makes that prefix available
   for address autoconfiguration by on-link devices.  (This is conveyed
   by setting the 'A' flag and the 'L' flag in the PIO of the DIO
   messages).  Node A owns the prefix A::/64, Node B owns B::/64, and so
   on.  Node B autoconfigures an on-link address with respect to Node A,
   A::B.  Nodes C and D similarly autoconfigure on-link addresses from
   Node B's prefix, B::C and B::D, respectively.  Nodes have the option
   of setting the 'R' flag and publishing their address within the
   Prefix field of the PIO.

Top      Up      ToC       Page 144 
                              +-------------+
                              |    Root     |
                              |             |
                              |   Node A    |
                              |             |
                              |    A::A     |
                              +------+------+
                                     |
                                     |
                                     |
                              +------+------+
                              |    A::B     |
                              |             |
                              |   Node B    |
                              |             |
                              |    B::B     |
                              +------+------+
                                     |
                                     |
                      .--------------+--------------.
                     /                               \
                    /                                 \
            +------+------+                     +------+------+
            |    B::C     |                     |    B::D     |
            |             |                     |             |
            |   Node C    |                     |   Node D    |
            |             |                     |             |
            |    C::C     |                     |    D::D     |
            +-------------+                     +-------------+


             Figure 32: Storing Mode with Node-Owned Prefixes

A.1.1.  DIO Messages and PIO

   Node A, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Set
   'R' flag:       Clear
   Prefix Length:  64
   Prefix:         A::

   Node B, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Set
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         B::B

Top      Up      ToC       Page 145 
   Node C, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Set
   'R' flag:       Clear
   Prefix Length:  64
   Prefix:         C::

   Node D, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Set
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         D::D

A.1.2.  DAO Messages

   Node B will send DAO messages to Node A with the following
   information:
       o  Target B::/64
       o  Target C::/64
       o  Target D::/64

   Node C will send DAO messages to Node B with the following
   information:
       o  Target C::/64

   Node D will send DAO messages to Node B with the following
   information:

       o  Target D::/64

A.1.3.  Routing Information Base

   Node A will conceptually collect the following information into its
   Routing Information Base (RIB):
       o  A::/64 connected
       o  B::/64 via B's link local
       o  C::/64 via B's link local
       o  D::/64 via B's link local

   Node B will conceptually collect the following information into its
   RIB:
       o  ::/0 via A's link local
       o  B::/64 connected
       o  C::/64 via C's link local
       o  D::/64 via D's link local

Top      Up      ToC       Page 146 
   Node C will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  C::/64 connected

   Node D will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  D::/64 connected

A.2.  Example Operation in Storing Mode with Subnet-Wide Prefix

   Figure 33 illustrates the logical addressing architecture of a simple
   RPL network operating in Storing mode.  In this example, the root
   Node A sources a prefix that is used for address autoconfiguration
   over the entire RPL subnet.  (This is conveyed by setting the 'A'
   flag and clearing the 'L' flag in the PIO of the DIO messages.)
   Nodes A, B, C, and D all autoconfigure to the prefix A::/64.  Nodes
   have the option of setting the 'R' flag and publishing their address
   within the Prefix field of the PIO.

Top      Up      ToC       Page 147 
                              +-------------+
                              |    Root     |
                              |             |
                              |   Node A    |
                              |    A::A     |
                              |             |
                              +------+------+
                                     |
                                     |
                                     |
                              +------+------+
                              |             |
                              |   Node B    |
                              |    A::B     |
                              |             |
                              +------+------+
                                     |
                                     |
                      .--------------+--------------.
                     /                               \
                    /                                 \
            +------+------+                     +------+------+
            |             |                     |             |
            |   Node C    |                     |   Node D    |
            |    A::C     |                     |    A::D     |
            |             |                     |             |
            +-------------+                     +-------------+

              Figure 33: Storing Mode with Subnet-Wide Prefix

A.2.1.  DIO Messages and PIO

   Node A, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Clear
   Prefix Length:  64
   Prefix:         A::

   Node B, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         A::B

Top      Up      ToC       Page 148 
   Node C, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Clear
   Prefix Length:  64
   Prefix:         A::

   Node D, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         A::D

A.2.2.  DAO Messages

   Node B will send DAO messages to Node A with the following
   information:
       o  Target A::B/128
       o  Target A::C/128
       o  Target A::D/128

   Node C will send DAO messages to Node B with the following
   information:
       o  Target A::C/128

   Node D will send DAO messages to Node B with the following
   information:
       o  Target A::D/128

A.2.3.  Routing Information Base

   Node A will conceptually collect the following information into its
   RIB:
       o  A::A/128 connected
       o  A::B/128 via B's link local
       o  A::C/128 via B's link local
       o  A::D/128 via B's link local

   Node B will conceptually collect the following information into its
   RIB:
       o  ::/0 via A's link local
       o  A::B/128 connected
       o  A::C/128 via C's link local
       o  A::D/128 via D's link local

Top      Up      ToC       Page 149 
   Node C will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  A::C/128 connected

   Node D will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  A::D/128 connected

A.3.  Example Operation in Non-Storing Mode with Node-Owned Prefixes

   Figure 34 illustrates the logical addressing architecture of a simple
   RPL network operating in Non-Storing mode.  In this example, each
   Node, A, B, C, and D, owns its own prefix, and makes that prefix
   available for address autoconfiguration by on-link devices.  (This is
   conveyed by setting the 'A' flag and the 'L' flag in the PIO of the
   DIO messages.)  Node A owns the prefix A::/64, Node B owns B::/64,
   and so on.  Node B autoconfigures an on-link address with respect to
   Node A, A::B.  Nodes C and D similarly autoconfigure on-link
   addresses from Node B's prefix, B::C and B::D, respectively.  Nodes
   have the option of setting the 'R' flag and publishing their address
   within the Prefix field of the PIO.

Top      Up      ToC       Page 150 
                              +-------------+
                              |    Root     |
                              |             |
                              |   Node A    |
                              |             |
                              |    A::A     |
                              +------+------+
                                     |
                                     |
                                     |
                              +------+------+
                              |    A::B     |
                              |             |
                              |   Node B    |
                              |             |
                              |    B::B     |
                              +------+------+
                                     |
                                     |
                      .--------------+--------------.
                     /                               \
                    /                                 \
            +------+------+                     +------+------+
            |    B::C     |                     |    B::D     |
            |             |                     |             |
            |   Node C    |                     |   Node D    |
            |             |                     |             |
            |    C::C     |                     |    D::D     |
            +-------------+                     +-------------+

           Figure 34: Non-Storing Mode with Node-Owned Prefixes

A.3.1.  DIO Messages and PIO

   The PIO contained in the DIO messages in the Non-Storing mode with
   node-owned prefixes can be considered to be identical to those in the
   Storing mode with node-owned prefixes case (Appendix A.1.1).

A.3.2.  DAO Messages

   Node B will send DAO messages to Node A with the following
   information:

       o  Target B::/64, Transit A::B

   Node C will send DAO messages to Node A with the following
   information:
       o  Target C::/64, Transit B::C

Top      Up      ToC       Page 151 
   Node D will send DAO messages to Node A with the following
   information:
       o  Target D::/64, Transit B::D

A.3.3.  Routing Information Base

   Node A will conceptually collect the following information into its
   RIB.  Note that Node A has enough information to construct source
   routes by doing recursive lookups into the RIB:
       o  A::/64 connected
       o  B::/64 via A::B
       o  C::/64 via B::C
       o  D::/64 via B::D

   Node B will conceptually collect the following information into its
   RIB:
       o  ::/0 via A's link local
       o  B::/64 connected

   Node C will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  C::/64 connected

   Node D will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  D::/64 connected

A.4.  Example Operation in Non-Storing Mode with Subnet-Wide Prefix

   Figure 35 illustrates the logical addressing architecture of a simple
   RPL network operating in Non-Storing mode.  In this example, the root
   Node A sources a prefix that is used for address autoconfiguration
   over the entire RPL subnet.  (This is conveyed by setting the 'A'
   flag and clearing the 'L' flag in the PIO of the DIO messages.)
   Nodes A, B, C, and D all autoconfigure to the prefix A::/64.  Nodes
   must set the 'R' flag and publish their address within the Prefix
   field of the PIO, in order to inform their children which address to
   use in the transit option.

Top      Up      ToC       Page 152 
                              +-------------+
                              |    Root     |
                              |             |
                              |   Node A    |
                              |    A::A     |
                              |             |
                              +------+------+
                                     |
                                     |
                                     |
                              +------+------+
                              |             |
                              |   Node B    |
                              |    A::B     |
                              |             |
                              +------+------+
                                     |
                                     |
                      .--------------+--------------.
                     /                               \
                    /                                 \
            +------+------+                     +------+------+
            |             |                     |             |
            |   Node C    |                     |   Node D    |
            |    A::C     |                     |    A::D     |
            |             |                     |             |
            +-------------+                     +-------------+

            Figure 35: Non-Storing Mode with Subnet-Wide Prefix

A.4.1.  DIO Messages and PIO

   Node A, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         A::A

   Node B, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         A::B

Top      Up      ToC       Page 153 
   Node C, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         A::C

   Node D, for example, will send DIO messages with a PIO as follows:
   'A' flag:       Set
   'L' flag:       Clear
   'R' flag:       Set
   Prefix Length:  64
   Prefix:         A::D

A.4.2.  DAO Messages

   Node B will send DAO messages to Node A with the following
   information:
       o  Target A::B/128, Transit A::A

   Node C will send DAO messages to Node A with the following
   information:
       o  Target A::C/128, Transit A::B

   Node D will send DAO messages to Node A with the following
   information:
       o  Target A::D/128, Transit A::B

A.4.3.  Routing Information Base

   Node A will conceptually collect the following information into its
   RIB.  Note that Node A has enough information to construct source
   routes by doing recursive lookups into the RIB:
       o  A::A/128 connected
       o  A::B/128 via A::A
       o  A::C/128 via A::B
       o  A::D/128 via A::B

   Node B will conceptually collect the following information into its
   RIB:
       o  ::/0 via A's link local
       o  A::B/128 connected

   Node C will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  A::C/128 connected

Top      Up      ToC       Page 154 
   Node D will conceptually collect the following information into its
   RIB:
       o  ::/0 via B's link local
       o  A::D/128 connected

A.5.  Example with External Prefixes

   Consider the simple network illustrated in Figure 36.  In this
   example, there are a group of routers participating in a RPL network:
   a DODAG root, Nodes A, Y, and Z.  The DODAG root and Node Z also have
   connectivity to different external network domains (i.e., external to
   the RPL network).  Note that those external networks could be RPL
   networks or another type of network altogether.


                          RPL Network        +-------------------+
                           RPL::/64          |                   |
                                             |     External      |
              [RPL::Root]    (Root)----------+      Prefix       |
                               |             |    EXT_1::/64     |
                               |             |                   |
                               |             +-------------------+
                 [RPL::A]     (A)
                               :
                               :
                               :
                 [RPL::Y]     (Y)
                               |             +-------------------+
                               |             |                   |
                               |             |     External      |
                 [RPL::Z]     (Z)------------+      Prefix       |
                               :             |    EXT_2::/64     |
                               :             |                   |
                               :             +-------------------+

                     Figure 36: Simple Network Example

   In this example, the DODAG root makes a prefix available to the RPL
   subnet for address autoconfiguration.  Here, the entire RPL subnet
   uses that same prefix, RPL::/64, for address autoconfiguration,
   though in other implementations more complex/hybrid schemes could be
   employed.

   The DODAG root has connectivity to an external (with respect to that
   RPL network) prefix EXT_1::/64.  The DODAG root may have learned of
   connectivity to this prefix, for example, via explicit configuration
   or IPv6 ND on a non-RPL interface.  The DODAG root is configured to
   announce information on the connectivity to this prefix.

Top      Up      ToC       Page 155 
   Similarly, Node Z has connectivity to an external prefix EXT_2::/64.
   Node Z also has a sub-DODAG underneath of it.

   1.  The DODAG root adds a RIO to its DIO messages.  The RIO contains
       the external prefix EXT_1::/64.  This information may be repeated
       in the DIO messages emitted by the other nodes within the DODAG.
       Thus, the reachability to the prefix EXT_1::/64 is disseminated
       down the DODAG.

   2.  Node Z may advertise reachability to the Target network
       EXT_2::/64 by sending DAO messages using EXT_2::/64 as a Target
       in the Target option and itself (Node Z) as a parent in the
       Transit Information option.  (In Storing mode, that Transit
       Information option does not need to contain the address of Node
       Z).  A non-storing root then becomes aware of the 1-hop link
       (Node Z -- EXT_2::/64) for use in constructing source routes.
       Node Z may additionally advertise its reachability to EXT_2::/64
       to nodes in its sub-DODAG by sending DIO messages with a PIO,
       with the 'A' flag cleared.

Top      Up      ToC       Page 156 
Authors' Addresses

   Tim Winter (editor)

   EMail: wintert@acm.org


   Pascal Thubert (editor)
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   France

   Phone: +33 497 23 26 34
   EMail: pthubert@cisco.com


   Anders Brandt
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen  DK-2100
   Denmark

   EMail: abr@sdesigns.dk


   Jonathan W. Hui
   Arch Rock Corporation
   501 2nd St., Suite 410
   San Francisco, CA  94107
   USA

   EMail: jhui@archrock.com


   Richard Kelsey
   Ember Corporation
   Boston, MA
   USA

   Phone: +1 617 951 1225
   EMail: kelsey@ember.com

Top      Up      ToC       Page 157 
   Philip Levis
   Stanford University
   358 Gates Hall, Stanford University
   Stanford, CA  94305-9030
   USA

   EMail: pal@cs.stanford.edu


   Kris Pister
   Dust Networks
   30695 Huntwood Ave.
   Hayward, CA  94544
   USA

   EMail: kpister@dustnetworks.com


   Rene Struik
   Struik Security Consultancy

   EMail: rstruik.ext@gmail.com


   JP. Vasseur
   Cisco Systems
   11, Rue Camille Desmoulins
   Issy Les Moulineaux  92782
   France

   EMail: jpv@cisco.com


   Roger K. Alexander
   Cooper Power Systems
   20201 Century Blvd., Suite 250
   Germantown, MD  20874
   USA

   Phone: +1 240 454 9817
   EMail: roger.alexander@cooperindustries.com