Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6550

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

Pages: 157
Proposed Standard
Errata
Updated by:  90089010
Part 6 of 6 – Pages 126 to 157
First   Prev   None

Top   ToC   RFC6550 - Page 126   prevText

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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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   ToC   RFC6550 - 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