RFC 6550
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
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.
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
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
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
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
+-------+-----------------------+---------------+
| 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.
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
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.
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
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
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
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 Flags20.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
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.
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.edu23. 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.
[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>.
[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.
[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.
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.
+-------------+ | 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 PrefixesA.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
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::DA.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::/64A.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
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.
+-------------+ | Root | | | | Node A | | A::A | | | +------+------+ | | | +------+------+ | | | Node B | | A::B | | | +------+------+ | | .--------------+--------------. / \ / \ +------+------+ +------+------+ | | | | | Node C | | Node D | | A::C | | A::D | | | | | +-------------+ +-------------+ Figure 33: Storing Mode with Subnet-Wide PrefixA.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
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::DA.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/128A.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
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.
+-------------+ | 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 PrefixesA.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
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.
+-------------+ | 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 PrefixA.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
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::DA.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::BA.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
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.
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.
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
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