I pv6 routing_protocol_for_low_power_and_lossy_

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

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,

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

Survey of Routing Protocols

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

Topology
• Forms one or more Destination Oriented Directed Acyclic
Graphs (DODAGs) between nodes


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)

Topology Construction (Visually)


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

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.

Overview of Control Messages

• Uses ICMPv6 with Type = 155
• Code specifies type of control message
• Base is where the message goes

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

Overview of Control Messages - DIS

• DODAG Information Solicitation (DIS)
• Used to probe neighbors for nearby DODAGs
• Can be used to solicit DIO messages

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

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

Overview of Control Messages -
DAO-ACK

• Destination Advertisement Object ACK (DAO-ACK)
• DAOSequence - Corresponds to DAO message

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

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

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

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

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

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

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

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

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

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

SRH Case 1
• SRH specifies complete path between source to destination

• Router places source header directly in datagram

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

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

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

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

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

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)

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

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

I pv6 routing_protocol_for_low_power_and_lossy_

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à I pv6 routing_protocol_for_low_power_and_lossy_

Similaire à I pv6 routing_protocol_for_low_power_and_lossy_ (20)

Dernier

Dernier (20)

I pv6 routing_protocol_for_low_power_and_lossy_