1. IPv6 Routing Protocol for Low power
and Lossy Networks
draft-ietf-roll-rpl-19
draft-ietf-6man-rpl-routing-header-07
Andrew Williams
Sheetal Kshirsagar

2. Agenda
• Overview of RPL -
o Topology/Topology Construction
o Types of Routes
o Traffic Flows supported
o Overview of control messages (high level)
 DIS, DIO, DAO, DAO-ACK, CC
o Upward/Downward route creation and maintenance
• Overview of Source-Routing Headers for RPL
o Format of header
o RPL Router Behavior
o Security Considerations
• Initial Project Plan
o What's already been done
o List messages we will have to decode,

3. Definitions
• Low power and Lossy Networks (LLN)
o Network where routers and links are constrained
• IPv6 Routing Protocol for LLN (RPL)
o Mechanism for routing traffic flows in LLNs

4. Survey of Routing Protocols
Source: Siarhei Kuryla, Networks and Distributed Systems seminar,
http://cnds.eecs.jacobs-university.de/courses/nds-2010/kuryla-rpl.pdf

5. Topology
• Forms one or more Destination Oriented Directed Acyclic
Graphs (DODAGs) between nodes
Source: Siarhei Kuryla, Networks and Distributed Systems seminar,
http://cnds.eecs.jacobs-university.de/courses/nds-2010/kuryla-rpl.pdf

6. Topology/Topology Construction
• An LLN is divided into one or more RPL Instance
• Each instance may have one or more DODAG
• Each node joins one DODAG per RPL Instance
• Each RPL Instance has an Objective Function used to rank
nodes based on different metrics
• Rank is the distance a node is from a DODAG root
• Links established from higher rank nodes to lower rank ones
• Each DODAG has a version, when changes occur the ranks
are recalculated and version incremented (initiated by
DODAG root)

7. Topology Construction (Visually)
Source: Siarhei Kuryla, Networks and Distributed Systems seminar,
http://cnds.eecs.jacobs-university.de/courses/nds-2010/kuryla-rpl.pdf

8. Routes in RPL
• Upward Routes
o Routes from nodes towards root
o Learned during ranking/parent selection through control
messages (DIO)
• Downward Routes
o Routes away from root towards node, learned via control
messages (DAO)
o Handle according to RPL Instance mode of operation:
o Storing Mode
 Nodes may store the down routes, route packets down
o Non-Storing Mode
 Only root stores routes, all packets go to root and
source routed down

9. Traffic Flows Supported
• Multipoint-to-Point (MP2P)
o Ex: One node providing a sink for many
o Uses up routes
• Point-to-Multipoint (P2MP)
o Ex: Firmware update sent to all nodes
o Uses down routes toward destinations (prefixes,
addresses, or multicast groups), and away from roots
• Point-to-Point (P2P)
o A packet flows towards a root through up routes until it
reaches an ancestor that has a known down route to the
destination or the root.

10. Overview of Control Messages
• Uses ICMPv6 with Type = 155
• Code specifies type of control message
• Base is where the message goes

11. Control Message Bases
• DODAG Information Solicitation (DIS)
• DODAG Information Object (DIO)
• DODAG Advertisement Object (DAO)
• DODAG Advertisement Object ACK (DAO-ACK)
• Consistency Check (CC)

12. Overview of Control Messages - DIS
• DODAG Information Solicitation (DIS)
• Used to probe neighbors for nearby DODAGs
• Can be used to solicit DIO messages

13. Overview of Control Messages - DIO
• DODAG Information Object (DIO)
• Allows nodes to discover an RPL Instance, learn the
configuration parameters, select a DODAG parent, and
maintain the DODAG

14. Overview of Control Messages - DAO
• Destination Advertisement Object (DAO)
• Sends node information to the DODAG root
• K - A DAO-ACK is expected
• D - DODAGID field is present

15. Overview of Control Messages -
DAO-ACK
• Destination Advertisement Object ACK (DAO-ACK)
• DAOSequence - Corresponds to DAO message

16. Overview of Control Messages - CC
• Consistency Check
• Used for challenges/responses and for checking secure
message counters
• Must be sent using the Secure RPL Message format

17. Secure Control Messages
• Each control message also has a secure version
• Security section above included in message (before base)
• Provides integrity and replay protection, with optional
confidentiality and delay protection

18. Control Message Options
• PAD1
o Add single octet of padding for option alignment
• PADN
o Add two or more octets for padding
• Metric Container (DIO, DAO)
o Pass node, link, and aggregate path metrics
• Route Information (DIO)
o Indicates that the DODAG root has connectivity to a
destination prefix
• DODAG Configuration (DIO)
o Distributes information about the DODAG
o Usually static, so doesn't need to be sent with each DIO

19. Control Message Options (2)
• RPL Target (DAO)
o Indicates a specified target IPv6 address, prefix, or
multicast group is reachable along the DODAG
• Transit Information (DAO)
o Indicates attributes for paths to one or more destination
• Solicited Information (DIS)
o Used for a node to request DIO messages from a subset
of neighbor nodes
• Prefix Information (DIO)
o Propagates prefix information for State-Less Address
Auto-Conf
• RPL Target Descriptor (DAO)
o Used to qualify/tag a target

20. Upward Route Creation / Node
Joining
• Node determines which DODAG is most preferred
• Builds a set of potential neighbors using DIO messages
o Must be reachable via link-local multicast
• Determines a subset of neighbors that are potential parents
• Determines one or more preferred parents
• Sets it's rank as being greater than the parent's rank
• Upward route is through the parent

21. Downward Route Creation
• Nodes send DAO messages upward
• In storing mode, nodes along the upward path can store
routes to these destinations and send DAO upward
• Downward Routes constructed by recursively looking up
parent nodes until the node is found

22. Security Mechanisms
• 3 Security modes for an RPL Instance:
o Unsecured - Regular control messages, no security
provided by RPL
o Pre-Installed - Secure control messages using a pre-
shared key
o Authenticated - Secure control messages using a pre-
shared key, must obtain a second key from a key
authority to be a router
• MAC or Signature used to provide message
integrity/authentication
• Optional encryption using CCM with AES-128 encryption
• Counters and Timestamps to prevent replay/timing attacks

23. Loop Avoidance
• Detects DAG inconsistencies at each node if:
o downward packet received from higher ranked node
o upward packet received from lower ranked node
• Detects DAO inconsistencies (incorrect down routes stored
at nodes) if:
o node receives a packet for which it is no longer the
parent

24. Agenda
• Overview of RPL -
o Topology/Topology Construction
o Types of Routes
o Traffic Flows supported
o Overview of control messages (high level)
 DIS, DIO, DAO, DAO-ACK, CC
o Upward/Downward route creation and maintenance
• Overview of Source-Routing Headers for RPL
o Format of header
o RPL Router Behavior
o Security Considerations
• Initial Project Plan
o What's already been done
o List messages we will have to decode,

25. IPv6 Routing Header for Source
Routes
• RPL relies on source routing to utilize paths that include
memory constrained routers
• Needed to support downward routes in RPL instances using
Non-Storing Mode
o source routes populated by DODAG root
• SRH header is similar to the IPv6 header described in
RFC2460
• SRH allows compaction of source route entries when all
entries share same prefix

26. Source Routing for RPL
• Source routes specified can be:
o The entire path from source to destination
o Subset of actual path between Source to Destination
• SRH can only be used between RPL Instances
• RPL Border routers responsible for connecting to other RPL
Routers
o IPv6-in-IPv6
• RPL Router drops datagram if
o multiple addresses assigned to any interface on that
router

27. SRH Case 1
• SRH specifies complete path between source to destination
• Router places source header directly in datagram

28. SRH Case 2
• Occurs when source and/or destination are outside RPL
instance
• R is the RPL Border Router

29. Format of RPL Routing Header

30. Generating Source Route Headers
• if source and destination in same instance
o router includes SRH header in original packet
• if source and/or destination in different instance
o router uses IPv6-in-IPv6
• RPL router must set segments left to no greater than original
datagram's Hop Limit
o what is source route is longer than IPv6 hop limit?
• If RPL router is not a source of the datagram, it first
decrements Hop Count and then generates SRH
• Desirable to consider path MTU size to prevent performance
degradation due to fragmentation
o data size + 40(outer IP header) + SRH_MAX_SIZE

31. Processing Source Route Headers
• Processed when packet reaches node identified by
•
destination address field.
• Processing header:
o destination address = next hop's address
o if segments left non-zero and destination address not on
link
packet must be dropped
send ICMP destination unreachable error message
else
packet is forwarded
o detect loop
d
 If SRH contains multiple address assigned to any
interface on that router, drop packet
 send ICMP parameter problem error message

32. Security Considerations
• Does not specify any confidentiality, integrity or authenticity
mechanism.
• RPL routers must drop datagram containing SRH in the IPv6
extention header.
• Vulnerable to attacks from inside RPL instance.
• Bandwidth exhaustion attack handled by loop detection
mechanism
• Possible attacks
o Bypassing filtering devices
o reaching otherwise unreachable internet system
o defeating anycast
o routing topology discovery

33. IANA Consideration
• New source routing type "RPL Source Route Header"
defined
o assigned number TBD by IANA
• New ICMPv6 Destination unreachable code defined
o Strict Source Routing Failed
o assigned number TBD by IANA

34. What's already been done
• Wireshark filters for the control messages (ICMPv6) from
the main RFC
• Support for version 3 of the SRH RFC
(currently version 7)

35. What we plan to implement
• Update Source Route Header (SRH) dissecting capabilities
• Ensure decoding works with IPv6-in-IPv6 encapsulated
packets where SRH is in the outer IPv6 packet
• Show errors visually
o IPv6 addresses must not appear more than once in the SRH
o IPv6 source and destination must not appear in the SRH
o Multicast IPv6 addresses must not appear in the SRH or as the destination
of a IPv6 packet with a SRH
o If CmprI == 0 and CmprE == 0, Pad must == 0
• Highlight circumstances where messages must be dropped
and ICMPv6 error messages should be generated
o non-zero segments left value and destination not on link
o SRH includes multiple addresses assigned to interfaces on a given router
and messages are seperated by at least one interface

36. Questions?

37. Sources
http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-07
http://tools.ietf.org/html/draft-ietf-roll-rpl-19
http://cnds.eecs.jacobs-university.de/courses/nds-2010/kuryla-
rpl.pdf