IPv6 ND 2020

1
IPv6 ND 2020
Pascal Thubert,
Rennes
January 15th, 2020

2
• The any-to-any paradigm
Art: Any par of global addresses can reach one another
IoT: Many devices of all sorts, need isolation
GAFA: Corridors to the cloud?
• The end-to-end paradigm
Art: Intelligence at the edge, dumb routing nodes
Infinite bandwidth to all powerful clusters?
• The best-effort paradigm
Art: Stochastic packet distribution and RED
Can we make the whole Internet deterministic?

3
(1980) NCP generation with:
All Transmission Groups to L2 peers
All Physical Units type 4 nodes,
All Virtual Routes
(1990) Router CLI with:
ID, keys.
All links to L2 peers
Routes are discovered
=> Single ‘GRID’
(2000) Router only knows “self” with:
ID, certificates
Peers are discovered
Links are discovered
Routes are discovered
=>Infinity of self-centric networks

4
Open Standards vs. proprietary
COTS* suppliers drive costs down but
Reliability, Availability and Security up
IP abstraction vs. per MAC/App
802.11, 802.15.4, Sat, 3G, UWB
Keep L2 topology simple
To Infinity and Beyond… But End-to-End.
No intermediate gateway, tunnel, middle boxes & other trick
* Commercial, off-the-shelf

5
The current Internet comprises several billion
devices
Smart Objects will add tens of billions of
additional devices
IPv6 is the only viable way going forward
1~2 Billions
PCs & servers
Tens of
Billions
Smart ObjectsThings
Mobile
Fixed
2~4 Billions
Phones & cars
The RIPE NCC has run out of IPv4 Addresses
“Today, at 15:35 (UTC+1) on 25 November 2019, we made our
final /22 IPv4 allocation from the last remaining addresses in our
available pool. We have now run out of IPv4 addresses.”

6
Little work on adapting IPv4 to radios
Rather adapt radios to IPv4 e.g.WIFI infrastructure mode
« Classical » IPv6
Large, Scoped and Stateful addresses
Neighbor Discovery, RAs (L3 beacons)
SLAAC (quick and scalable)
Anycast Addresses
IPv6 evolution meetsWireless:
Mobile Routers (LISP, NEMO) (Proxy) MIPv6
6LoWPAN 6TiSCH ROLL/RPL CoAP
ISA100.11a ZigBee/IP

7
• Non-Broadcast Multi-Access network / MultiLinkL subnet
IPv6 only supports P2P and transit (ethernet) but by nature, a radio network is NBMA
WiND / RPL solves the problem in the IOT space
• L3 «VLAN »
So far only available with MPLS. New attempts (MTR, RPL instances, SR Flex Algo)
• L4/5 hints
Flow Label given away to fwd plane; DetNet Flow indication?
• Microflows / compound flows
InWSN, a flow has multiple sources
• Local and Global IP Mobility Unification
(eg MANEMO, LISP+RPL)

8
We are in for a change:
Basic Internet structures and expectations reconsidered
Revisiting classical end-to-end and any-to-any
Revisiting best effort to new levels of guarantees (deterministic)
New function placement, new operations
Merge IOT data at the Information layer,
Gossip IOT information at the knowledge layer
Impacts network, transport, security models

9
Agenda (part 1, Introduction)
IOT Standards
IEEE and LLNs
IETF and 6LoWPAN
IETF 6TiSCH
Routing Concepts
Forms of Routing
Loopless structures
Routing Over Radios

10
Agenda (part 2, IPv6 ND for P2P and transit links)
The IPv6 Neighbor Discovery Protocol
RFC 4861: Discovery and Resolution
RFC 4862: SLAAC
Applying Classical ND toWireless
Link Model
Can and cannot do

11
Agenda (part 3, Wireless ND)
Wireless Neighbor Discovery (WiND)
Registration (RFC 8505)
Backbone Router
Address Protection and SAVI
MultiLink Subnet
Classical RPL
RPL-Unware Leaves
Using RPL Packet Information

12
Agenda (part 4, RPL Route Projection and extras)
RPL Route Projection
Shortening Long SRH
Transversal Routes
In Non-Storing Mode
In Storing Mode
Fast Reroute in RPL (non standard)
Using the Data Plane
Using the Control Plane

15
Cheap Install
Deploying wire is slow and costly
Global Coverage
From Near Field to Satellite via 3/4G
Everywhere copper/fiber cannot reach
Cheap multipoint access
New types of devices (Internet Of Things)
New usages (X-automation, Mobile Internet)

16
LLNs comprise a large number of highly constrained
devices (smart objects) interconnected by predominantly
wireless links of unpredictable quality
LLNs cover a wide scope of applications
Industrial Monitoring, Building Automation, Connected Home,
Healthcare, Environmental Monitoring, Urban Sensor Networks,
Energy Management, AssetTracking, Refrigeration
Several IETF working groups and Industry Alliances and
consortiums addressing LLNs
IETF - CoRE, 6lo/LoWPAN, ROLL, ACE, LPWAN, 6TiSCH…
Alliances – IPSO,Thread, ISA, HCF
World’s smallest web server

17
LLNs operate with a hard, very small bound on state
LLNs are optimised for saving energy in the majority of cases
Traffic patterns can be MP2P, P2P and P2MP flows
Typically LLNs deployed over link layers with restricted frame-sizes
Minimise the time a packet is enroute (in the air/on the wire) hence the small frame
size
The routing protocol for LLNs should be adapted for such links
LLN routing protocols must consider efficiency versus generality
Many LLN nodes do not have resources to waste

18
IEEE Wireless Standards
802.11 Wireless
LAN
802.15 Personal
Area Network
802.16 Wireless
Broadband Access
802.22 Wireless
Regional Area Network
WiFi
802.11a/b/g/n/ah
IEEE 802
LAN/MAN
802.15.1
Bluetooth
802.15.2
Co-existence
802.15.3
High Rate WPAN
802.15.4
Low Rate WPAN
802.15.5
Mesh Networking
802.15.6 Body Area
Networking
802.15.7 Visible
Light
Communications
802.15.4e
MAC
Enhancements
802.15.4f
PHY for RFID
802.15.4g
Smart Utility Networks
TV White Space PHY
15.4 Study Group
802.15.4d
PHY for Japan
802.15.4c
PHY for China
• Industrial strength
• Minimised listening costs
• Improved security
• Improved link reliability
• Support smart-grid networks
• Up to 1 Km transmission
• >100Kbps
• Millions of fixed endpoints
• Outdoor use
• Larger frame size
• PHY Amendment
• Neighborhood Area Networks
TSCH
Amendments retrofitted in
802.15.4-2015

Cisco Confidential© 2012 Cisco and/or its affiliates. All rights reserved. 19
Initial activities focused on wearable devices “PersonalArea
Networks”
Activities have proven to be much more diverse and varied
Data rates from Kb/s to Gb/s
Ranges from tens of metres up to a Kilometre
Frequencies from MHz toTHz
Various applications not necessarily IP based
Focus is on “specialty”, typically short range,
communications
If it is wireless and not a LAN, MAN, RAN, orWAN,
it is likely to be 802.15 (PAN)
The only IEEE 802Working Group with
multiple MACs
http://www.ieee802.org/15/pub/TG4.html
IEEE 802.15 WPAN™ Task Group 4
(TG4) Charter

20
Star Topology Cluster TreeMesh Topology
P
R F
F
R
R
P
F F
F
R
F
R
All devices communicate to
PAN co-ordinator which
uses mains power
Other devices can be
battery/scavenger
Single PAN co-ordinator exists for all topologies
Devices can communicate
directly if within range
F F
F
F
P
R
R
F
R
Operates at Layer 2
R
R
RR
Higher layer protocols like
RPL may create their own
topology that do not follow
802.15.4 topologies

21
• Specifies PHY and MAC only
• Medium Access Control Sub-Layer (MAC)
Responsible for reliable communication between devices
Data framing and validation of RX frames
Device addressing
Channel access management
Device association/disassociation
Sending ACK frames
• Physical Layer (PHY)
Provides bit stream air transmission
Activation/Deactivation of radio transceiver
Frequency channel tuning
Carrier sensing
Received signal strength indication (RSSI)
Link Quality Indicator (LQI)
Data coding and modulation, Error correction
Physical Layer
(PHY)
MAC Layer
(MAC)
Upper Layers
(IEEE Std. 802.15.12, Network & App)

24
LAKE
Reuse work done here where possible
Application
General
Internet
Ops and Mgmt
Routing
Security
Transport
Core
6lo
ROLL
IETF LWIG
Constrained Restful Environments
Charter to provide a framework for resource-oriented applications
intended to run on constrained IP networks.
IPv6 over Networks of Resource-constrained Nodes
(succeeds 6LoWPAN)
Charter is to develop protocols to support IPv6 IoT networks.
Routing over Low Power Lossy Networks
Charter focusses on routing issues for low power lossy networks.
Lightweight Implementation Guidance
Charter is to provide guidance in building minimal yet interoperable IP-
capable devices for the most constrained environments.
LPWAN
IPv6 over TSCH
Charter is to develop best practice and Architecture for IPv6 over
802.15.4 TSCH.6TiSCH

25
• Gateways vs. end-to-end principle
• Hindrance from proprietary
technologies
• Vertical solutions, hard to generalize
to large scale driving costs down

26
http://dunkels.com/adam/ewsn2004.pdf
http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ipv6-sensys08.pdf
• No IP at all is sensors, deemed impossible, too expensive
• ProprietaryWSN technologies
And then …
• IEEE 802.15.4-2003 ratified December 14, 2004
• ZigBee 2004 Specification 1.0 on June 13, 2005
And then …
• Pioneer work From Adam Dunkels, and then others:

27
• IPv6 to the end node however small
• IETFWG formed in March 2005
• Chartered for IPv6 over LoWPAN (802.15.4)
• Now closed, replaced by 6lo
• Defined:
Header Compression (HC) RFC 4944 and RFC 6282
Fragmentation and mesh header (mostly unused)
Registration-based IPv6 Neighbor Discovery (ND) RFC 6775

28
• Standards such as Zigbee(IP), ISA100.11a and WirelessHART all define
whole stacks and application profiles whereas 6LoWPAN is (just) an
adaptation layer for IP (version 6)
• ISA100.11a <= 6LoWPAN Header Compression (HC) RFC 6282
• ZigbeeIP &Thread use 6LoWPAN HC + Neighbor Discovery (ND)
• Yet 6LoWPAN marks the transition forWSN towards IP
• So the popular image is that 6LoWPAN means IP in sensors
• 6LoWPAN failed to deliver routing. ROLL WG took over with RPL

29
Generalize to all technologies, provide generic abstraction
6lo now chartered to define IPv6 over IOT Links
Current work on:
6lo also handles 6LoWPAN maintenance e.g. as stimulated by
6TiSCH to improve 6LoWPAN - RPL interworking
https://tools.ietf.org/html/rfc7668
https://tools.ietf.org/html/draft-hou-6lo-plc
https://tools.ietf.org/html/draft-ietf-6lo-nfc
https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah
https://tools.ietf.org/html/draft-ietf-6tisch-architecture
Bluetooth Low Energy
DECT Ultra Low Energy
Zwave
PLC
Near Field Comms
BACNET
802.11ah
802.15.4eTSCH

30
TimeFrame 802.15.4 Other IoT links
< 2004 Non IP (zigbee…) Non IP (BACNet, Zwave…)
< 2011 IPv6 via 6LoWPAN HC Non IP
< 2013 6LoWPAN HC + 6LoWPAN ND IPv6 via 6LoWPAN HC (ongoing)
~ now 6LoWPAN + RPL stack ( that’s 6TiSCH ! ) 6LoWPAN HC + ND
< 2022 6LoWPAN + RPL stack (that will be 6IoT, generalizing 6TiSCH stack on all LLN links)
Next Reliable and Available Wireless, Call Admission control and Traffic Engineering
Notes:
• With Wireless ND we claim that Low Power Wi-Fi is an LLN link => extend to Wi-Fi and 802.11 OCB

31
Preamble SPD
PHY
Header
Auxiliary
Security
Header
Payload FCS
Frame
Control
Data
Seq.
Nbr
Addressing
Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen
in deployment
IEs
Header &
Payload
DST
PAN ID
Mesh
Address
6LoWPAN
Compressed Hdr
Payload
DST MAC
Address
SRC
PAN ID
SRC MAC
Address
11000
00
10
01
11
Not a LoWPAN frame
LoWPAN Header Dispatch (DSP)
LoWPAN mesh Hdr
LoWPAN fragmentation Hdr and other stuff
1st Frag.
6LoWPAN
Compressed Hdr
Payload
1st Frag.
6LoWPAN
Compressed
Hdr
Payload
IPHC
Other 6LoWPAN
Hdr field
Payload
Header Dispatch (DSP) – understand
what is coming
Mesh
AddressMesh + Fragmentation
Frame Fragmentation
Mesh (L2 Routing)
6LoWPAN
01
10
11000 01
01
6LoWPAN
Compressed Hdr
01
01

32 3
0 1 1 HLIM SAM DAM
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
10
TF 2 bits Traffic Class and Flow Label
NH 1 bit Next Header
HLIM 2 bits Hop Limit
CID 1 bit Context Identifier Extension
SAC 1 bit Source Address Context
SAM 2 bits Source Address Mode
M 1 bit Multicast Address Compression
DAC 1 bit Destination Address Context
DAM 2 bits Destination Address Mode
CIDTF NH SAC M DAC
DSP Addressing

33
6LoWPAN is an open standard, NOT a silo’ed solution
6LoWPAN is how you do IPv6 over low-power lossy networks
Provides an Adaptation Layer and a novel IPv6 Neighbor Discovery
6LoWPAN started small with the 802.15.4-2003 WPAN
Updated to fit in ISA100.11a, used inThread, ZigbeeIP, …
Now generalizing on all LLN technologies with IETF 6lo GW

35
Deterministic IPv6 over IEEE802.15.4TimeSlotted Channel Hopping (6TiSCH)
TheWorking Group will focus on enabling IPv6 over theTSCH mode of the IEEE802.15.4 standard.The
scope of theWG includes one or more LLNs, each one connected to a backbone through one or more
LLN Border Routers (LBRs).
6TiSCH also specifies an IPv6-over-foo for 802.15.4TSCH
but does not update 6LoWPAN (that’s pushed to 6lo).
Rather 6TiSCH defines the missing Data Link Layer.
The 6TiSCH architecture defines the Layer-3 operation.
6TiSCH builds a MultiLink Subnet (MLSN)
CombiningWiND for 6LN<->6LR and RPL for 6LR<->6LR
Also Reliable andAvailableWireless (RAW) Scheduling
=> Mostly NOT specific to 802.15.4TSCH
WG charter

36
6TiSCH has to make components work together and push new work
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd
https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery
https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves
https://tools.ietf.org/html/draft-ietf-roll-dao-projection
Active 6TiSCH drafts and RFCs
https://tools.ietf.org/html/rfc8180 (Minimal support, slotted Aloha)
https://tools.ietf.org/html/draft-ietf-6tisch-architecture
https://tools.ietf.org/html/draft-ietf-6tisch-msf
https://tools.ietf.org/html/rfc8480 (6P Protocol)
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security
https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join
WG deliveries

37
Centralized route and
track computation
and installation
Management and
Setup
Discovery
Pub/Sub
Authentication for
Network Access
Wireless ND
(NPD proxy)
Time Slot
scheduling and
track G-MPLS
forwarding
Distributed route and
track computation and
installation
Scheduling
functions
IEEE 802.15.4 TSCH
6LoWPAN HC / 6LoRH HC
IPv6
RPL
6top
TCP UDP ICMP
PCEP/PCC CoAP/OSCORE 6LoWPAN ND
}
Applications CoJP
SF

40
Next problem: Reliable and Available Wireless
• Due to uncontrolled interferences, including the self-induced multipath
fading, deterministic networking can only be approached on wireless
links.
• The radio conditions may change -way- faster than a centralized PCE
can adapt and reprogram, in particular when the controller is distant
and connectivity is slow and limited.
• RAW separates the path computation time scale at which a complex
path is recomputed from the path selection time scale at which the
forwarding decision is taken for one or a few packets.
• RAW operates at the path selection time scale. The RAW problem is to
decide, within the redundant solutions that are proposed by the PCE,
which will be used for each packet to provide a Reliable andAvailable
service while minimizing the waste of resources.
Controller
Wireless network
FAST
SLOW
LARGE
SMALL
SLOW
Reliability & Availability vs. Energy & Bandwidth

43
• Hidden terminal
• Interference domains grows faster that range
• Density => low power => multihop => routing

44
Centralized:A controller sets up the routes
Pros
God’s view, enables global optimization
Elastic resource management / NFV
Traffic Engineering, may compute per flow paths
Non Equal Cost Multipath, Replication &
Elimination
Cons
Delays learning about breakage
Delays fixing breakage
NP complete optimization => limits scalability
Distributed: A routing protocol sets up the routes
Pros
SinceARPANET, enables high resilience
Different IGPs for different needs
Installed base
Cons
Microloops
Tends to build crowded avenues, wastes bandwidth
Same costs for all, NECM difficult, manualTE
Need additions for reroute / fast reroute

45
RFC 4861 is Reactive, RFC 8505 is Proactive)
Aka
Stateful vs.
On-demand routing
Note: on-demand breaks control vs. Data plane separation
P2P-RPL
RIP
IS-IS
AODV-RPL

46
LS requires full state and convergence
Every node draws a same graph
Then run the shortest path first algorithm to get to all other nodes
Then associates node with reachable destinations
LS can be very quiet on stable topologies
DV learns costs to destination asynchronously per destination
Nodes advertise their distance to a destination
Recursively other nodes learn their best successor
and compute their own cost
DV hides topological complexities and changes
DV enables multiple NECM feasible successors
RIP
IS-IS

47
Stateful: routing decision at every hop
Pros
Resilient (DARPA), autonomic
Cons
Requires routing state in every router
Tends to concentrate flows
Routing Loops
Source Routing: The path is in the packet
Pros
Saves state in routers
Enables per flow routing (segment routing)
Cons
Larger packets / Source Route Header (SRH)

48
Optimized Routing Approach (ORA) spans
advertisements for any change
Routing overhead can be reduced if stretch
is allowed: Least Overhead Routing
Approach (LORA)
=> (Nothing to do with the LoRa LPWAN
protocol !!!)
For instance Fisheye and zone routing
provide a precise routing when closeby and
sense of direction when afar

49
• Conventional IGPs are Isotropic
Meaning that they advertise the same information in all directions
This enables shortest path but leads to intense flooding at scale
• Some Network have a sense of “North” or “Up”
Towards IOT Sinks (e.g., RPL Root)
Towards DC Superspine (e.g., RIFTToF)
Anisotropic Routing exploits that inherent structure for optimization
Different forms of advertisements
Aggregated routes Northwards, with disaggregated exceptions

50
• Conventional routing protocols are Greedy
Meaning that a packet must always “progress” towards a destination for a
particular metric
This causes issues like micro-loops or freezing when the greedy path is lost
• Fast Reroute enables lossless rerouting of packets
FR may require a step back before progressing again
Made possible by new routing approaches (see LFA, ARC and MRT)
Can also useTunnels / Source Routing around (see Segment Routing)
PLAN B can be computed centrally

52
Most classical routing structure
Typically what Internet Gateway Protocols
(IGPs) Build or each reachable destination
Only thing Link State builds, though Distance
Vector has feasible successors
Must be reconstructed upon connectivity loss,
service is interrupted
FRR techniques must be added (MRT, LFA
with SR …) on top
No inner load balancing capabilities
Walkable structure (e.g. depth first)
ROOT
5
4
4
0
1
3
1 1
2
2
2
2
23
3
3
3
3
2
4
4
5
0
6
5
4
ROOT

53
In the context of routing, a Directed Acyclic
Graph (DAG) is formed by a collection
of vertices (nodes) and edges (links).
Each edge connecting one node to another
(directed) in such a way that it is not possible to
start at Node X and follow a directed path that
cycles back to Node X (acyclic).
Greedy => Not all nodes have 2 solutions even
in biconnected networks
A DestinationOriented DAG (DODAG) is a DAG
that comprises a single root node.
Here a DAG that is partitioned in 2 DODAG
Clusterhead
5
4
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4

54
• In Green: A’s subDAG.
Impacted if A’s connectivity is
broken
Domain for routing recovery
• In Red: B’s fanout DAG
(or reverse subDAG)
Potential SPAN on B’s DAO
Thus potential return paths
Fanout must be controlled to limit
intermediate states
Clusterhead
5
4
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4
A
B

55
Clusterhead
5
Clusterhead
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
e.g. ARC of siblings
Allows more alternates
ARCs and walkable structures in general
are walked with no routing progress
Routing between DAGs of ARCs
Forwarding over DAG AND ARCs
Reduces congestions of upper links of
the DAG
Still LORA for P2P
IGP subarea (bidirectional)
Preferred parent tree
Potential link

56
Clusterhead
/ Root
5
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
Expose sibling Information to Root
Root <-> PCE over southboundAPI
Computes a redundantTrack
As aggregated Segments
=> Redundancy (PAREO)
SDN /Traffic Engineering
Install additional routes
“Projected” in the Network
RAW Forwarding Decision
Delivery SLA (PDR, latency)
Optimiez bandwidth and Energy Preferred parent tree
Potential link projected Track
SDN Controller
/ PCE
Southbound API

58
1000*scale => No leak in Internet
=> Opaque operations
Reachability => Radio (IEEE)
Addressing => IPv6 (IETF)
Density => spatial reuse
=> Routing

59
No preexisting physical topology
Can be computed by a mesh under protocol,
but…
Else Routing must infer its topology
Movement
natural and unescapable
Yet difficult to predict or detect

60
Potentially Large Peer Set
Highly Variable Capabilities
Selection Per Objective
Metrics (e.g. RSSI, ETX…)
L3 Reachability (::/0, …)
Constraints (Power …)

61
Smart object are usually
Small & Numerous
« sensor Dust »
Battery is critical
Deep Sleep
Limited memory
Small CPU
Savings are REQUIRED
Control plane
Data plane (Compression)

62
Neither transit nor P2P
More like a changing NBMA
a new paradigm for routing
Changing metrics
(tons of them!)
(but no classical cost!)
Inefficient flooding
Self interfering
Quality of Service ?
Call Admission Control =>TSCH

63
Stretch vs. Control
Optimize table sizes and updates
Optimized Routing Approach (ORA) vs
Least Overhead Routing Approach (LORA)
on-demand routes (reactive)
Forwarding and retries
Same vs. Different next hop
Validation of the Routing plane
Non Equal Cost multipath
Directed Acyclic Graphs (DAG) a MUST
Maybe also, Sibling routing
Objective Routing
Weighted Hop Count the wrong metric
Instances per constraints and metrics

66
• Replacement / Modernization of IPv4 Address Resolution Protocol
• And ICMP Router Discovery and Redirect
• Based on ICMPv6
• Reactive Protocol, heavy usage of multicast / broadcast
• Initially defined in 1998 (obsoleting 1996 version) for Ethernet wire
• Operate on one hop
• Advertises Routers and Parameters
• Resolves Layer-2 addresses and maintains a cache (NCE)

67
Unidirectional Links: Not Supported (need reflexive)
Broadcast link (e.g., Ethernet): Supported (needTransitive)
Multicast capable: benefits from multicast optimization.
Point-to-Point (P2P): Supported
Shared Media (Non-overlapping prefixes): Supported
Non-Broadcast Multi Access (NBMA): Not Supported
=> No concept of Multi-Link Subnet (MLSN) in classical IPv6

68
• ND resolves mapping of IPv6 and LLA for on-link addresses
• Advertising self with Source LLA Option (SLLAO)
provides the LLA associated to the IP source of the ND message
• Advertising third party address withTarget LLA Option (TLLAO)
Mapping the IPv6 address in theTarget field
• Source Address can be all-zero (:: aka UNSPECIFIED_ADDRESS)
Response is therefore multicast to all hosts
• Multiple tricks
Responding with RA unicast vs. multicast
using unicast MAC for mcast packet

69
Layer-3 unicast and multicast (allows IP auth)
Router Discovery included (RA messages)
Provides the router Link-Local Address
Allow router association independent of prefix
(Multiple) Prefix Information in RA msg
MTU in RA msg
StatelessAddress Autoconfiguration + DHCPv6
Target link-layer address in Redirect (on-link)
Neighbor Unreachability Detection (NUD)
Hop Limit of 255 contains IPv6 ND on link
Reactive Lookup and DAD only (in practice)
• Layer-2 broadcast
• ICMP Router Discovery and Redirect
• No LLA (initially)
• Router known only by Global address
• One Address, one Prefix per link
• Hosts may have different MTUs
• Only DHCP
• Separate resolution
• No equivalent method, half link undetected, no FSM
• Off link nodes can spoof ICMP redirect messages
• Inverse ARP and reverse ARP for NBMA

70
• Router Solicitation:
When an interface becomes enabled, hosts may send out Router Solicitations that request routers to
generate Router Advertisements immediately rather than at their next scheduled time.
• Router Advertisement:
Routers advertise their presence together with various link and Internet parameters either periodically,
or in response to a Router Solicitation message.
Router Advertisements contain prefixes that are used for determining whether another address shares
the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc.
Many options have been added since RFC 4861, e.g., RIO
• Both can be unicast or multicast, and can announce Link Layer Address
(LLA) aka MAC address

71
• Neighbor Solicitation:
DuplicateAddress Detection (DAD, S=::, D=Mcast SNMA)
Determine the link-layer address of a neighbor (Address Lookup akaAddress Resolution (S=Ucast, D=
Mcast SNMA)
Verify that a neighbor is still reachable via a cached link-layer address with Neighbor Unreachability
Detection (NUD, S=Ucast, D= Ucast).
• Neighbor Advertisement:
A response to a Neighbor Solicitation message (multicast if source is :: )
Also Unsolicited (akaGratuitous) NeighborAdvertisements to announce a LLA change.
• Redirect:
Used by routers to inform hosts of a better first hop for a destination

72
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... (SLLAO)
+-+-+-+-+-+-+-+-+-+-+-+-

73
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... (SLLAO, PIO, MTU, RIO,…, 6CIO, ABRO, 6LoWPAN Context)
+-+-+-+-+-+-+-+-+-+-+-+-

74
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... (SLLAO, note: TLLAO in RFC 8505)
+-+-+-+-+-+-+-+-+-+-+-+-

75
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... (TLLOA)
+-+-+-+-+-+-+-+-+-+-+-+-

76
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ (better first hop) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... (TLLOA, redirected header)
+-+-+-+-+-+-+-+-+-+-+-+-

78
Form one or many IPv6 LL / UL / GU Address, anytime
Controlled by A bit in PIO (vs. DHCP by M and O bits in RA)
Host in control of the address, network cannot refuse
Neighbor Caches in peers, not hard state
NS(DAD) procedure: typically wait one second
Alt: RFC 4429 Optimistic DAD Doable with limitation
NS / NA done reactively, the router keeps one packet pending!!!
Causes loss of response and bad assessment of connectivity
draft-linkova-6man-grand/ proposes to push a NA to the routers

79
• RFC 2464 (IPv6 / Eth) and 4291: Address Architecture
Defines IPv6 Adresses (LinkLocal vs. ULA vs. GUA, Unicast,Anycast, unspecified, loopback…)
Interface ID (IID) based on EUI-64 (derived from MAC address) => deprecated by RFC 8064
• RFC 5292 provides Modern AddressText Representation
e.g., 2001:db8:aaaa:bbbb:cccc:dddd::1
• RFC 4941 SLAAC Privacy Extensions (still a need for stable IIDs)
• RFC 7136 Significance of IPv6 IID (meaning none)
• RFC 7217 Stable and Opaque IIDs (enable private static IIDs)
• RFC 7721 Privacy Considerations / RFC 8065 for 6lo / IOT
• RFC 8064 Recommendation on Stable IPv6 Interface Identifier
updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121 !!!!!!!

80
Applying Classical ND
to Wireless

81
• IPv6 ND is designed for P2P andTransit Links
Wireless is usually reflexive but natively non-transitive
Requires extensions for NBMA (without MAC-layer emulated transitive properties)
• IPv6 ND over MAC-layer transit emulation is not wireless friendly
E.g., over L2R, learning bridges, Wi-Fi Infrastructure Mode
Broadcast intensive (no support for multicast)
• Other mismatches
Fast Roaming ‘11r’ (ND has no sense of order of events)
Intermittent Connectivity (fails all of NUD, DAD and lookup)
Fast Initial Link Setup ‘11ai’ (ND is reactive, causes loss of first packets)
Increased sensitivity to DoS attacks (Use ND to trigger broadcasts remotely)
A
B
C
Non transitive:
B can talk to A and C
but A and C cannot
see reach other

83
• A plain radio Interface connects to a
physical radio broadcast domain
(vs. a MAC-layer emulated broadcast domain)
• An IPv6 bidirectional Link can be created where radio
broadcast domain overlap enough that A sees B and B sees A.
• Link-Local Addresses need to be unique for a communicating pairs only
• The IPv6 Link is usually reflexive though often asymmetrical
• The IPv6 Link is usually not transitive unless special measures taken
• As a node moves, it meets other nodes and IPv6 Links are formed
Spoke_C
B::C/64
Spoke_A
B::A/64
Hub_B
B::B/64

84
B
b::b/64
C
c::c/64
• Matching source IP to router
A must with radio mobility
E.g., car A attached to RSUs B & C
Each RSU enforcing SAVI for its prefix
Providing reachability back to a CoA based on its prefix
• Aggressive DNA (Detecting Network attachment)
Rapid discovery (advertisement interval option in RA)
Permanently assess reachability of DRL and prune rapidly
May reuse a GUA if come back within reg. lifetime
A belongs to 2
subnets at a
time
A
b::a/64
c::a/64

85
SubNet models
Spoke_C
B::C/64
Spoke_A
B::A/64
Hub_B
B::B/64
Hub and Spoke
HUB_B maintains state for
visitors for their registration
lifetime and relays packet
Node_A
MESH::A/64
Node_B
MESH::B/64
Node_C
MESH::C/64
Node_D
MESH::D/64 Node_E
MESH::E/64
Route-Over Mesh,
requires a routing protocol
A
B
P2P, the simplest
subnet model

87
Multiple L3
Multicast
messages
RA
Multiple L2
Broadcast
messages
1. MAC address reachability
flooded over L2 switch fabric
2. Device sends RS to all routers
link scope mcast
3. Router answers RA (u or m)
4. Device sends mcast NS DAD
to revalidate its address(es)
5. Device sends mcast NA(O)
The backbone router limits the
broadcast domain to the
backbone
VM, NFV,Wireless or IoT device moves:
Server

88
Nbr Solicitation
L3 Multicast
L2 broadcast
Packet to Target that is
missing in router ND cache
Nbr Advertisement
Unicast
1. Router looks up ND cache (say
this is a cache miss)
2. Router sends NS multicast to
solicited-node multicast @;
here that is 3333 FF00 00A1
1. Targets answers unicast NA
2. Target revalidates ND cache for
the router, usually unicast
3. Router creates ND cache entry
IPv6 is proxied at the backbone
router on behalf of device
Packet comes in for 2001:db8::A1

89
No Multicast group, all is broadcasted, all devices must receive and filter
Energy wasted when self is not recipient of the multicast
A device sends a unicast to the AP and the AP reflects as broadcast
Unicast are acknowledged, but broadcast are not
A broadcast fromAP must reach all associated nodes:
it is sent at the lowest speed and highest energy level
Can be 100 times slower that unicast: detrimental to unicast
Maw power => Maximum interferences with other wireless transmissions
Battery operated devices (e.g. your phone) often ignore 80-90% of broadcasts
Saves battery but defeats the protocols, e.g., Duplicate Address Detection

90
Wireless Neighbor Discovery
(WiND)

91
• Solicited node multicast requires highly scalable L2 multicast
IEEE does not provide it => turns everything into broadcast
IPv6 ND appears to work with broadcast on 802.1 fabrics up to some scale ~10K nodes
• IPv6 ND requires reliable and cheap broadcast
Radios do not provide that => conserving 802.1 properties over wireless is illusory
RFC 4862 cannot operate as designed on wireless
Address uniqueness is an unguaranteed side effect of entropy
• 802.11 expects proxy operation and broadcast domain separation
802.11 provides a registration and proxy bridging at L2
Requires the same at L3, which does (well… did) not exist
Implementations provide proprietary techniques based on snooping => widely imperfect
 RFC 6775 solves the problem for DAD in one LL
 RFC 8505 enables establishing proxy services directly

92
A proactive setting of proxy/routing state to avoid multicast due to reactive Duplicate
address detection and lookup in IPv6 ND
RFC 6775 (11/2012) and RFC 8505 (11/2018 update)
RFC 6775 is the original registration mechanism, mostly for DAD and NCE proactive setting
RFC 8505 updates for registration to proxy and routing services, enables RPL unaware leaves
draft-ietf-6lo-backbone-router (RFC to be next year)
Federates 6lo meshes over a high speed backbone
ND proxy analogous to 802.11 ESS bridging but at Layer 3
draft-ietf-6lo-ap-nd (RFC to be next year)
Protects addresses against theft (Crypto ID in registration

93
6LN (as a host) proactively registers to the 6LR (as the router) with NS(ARO)
Registers the SourceAddress (not the target…)
6LR does Duplicate Address Detection using a central registrar (called 6LBR)
New Duplicate Address Request / Confirmation (DAR/DAC) 6LR to 6LBR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

94
Registers theTarget so it can be proxied (backbone router)
New ROVR field forAddress Protection (ap-nd)
Lifetime and RID to map to RPL path lifetime and sequence
+ R flag to request proxy or routing services (RPL unaware leaves)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

95
Routers within subnet have a connected route
installed over the subnet backbone.
PCE probably has a static address in which
case it also has a connected route
Connected
Route to
subnet

96
Gateway to the outside participate to some IGP
with external network and attracts all extra-
subnet traffic via protocols over the backbone
Default
Route
In RIB

97
Directly upon NS(EARO) or indirectly upon
EDAR message, the backbone router performs
DAD on behalf of the wireless device.
DAR
NS
(EARO)
DADNS DAD
(EARO)

98
NA(EARO) or EDAC message carry succeful
completion if DAD times out.
NA(Override) is optional to clean up ND cache
stale states, e.g. if node moved.
DAC
NA
(EARO)
Optional
NA(O)

99
The BR maintains a route to the WSN node for
the DAO Lifetime over instance VRF. VFR may
be mapped onto a VLAN on the backbone.
RPL
DAO
Host
Route
Optional
NA(O)

100
The BR maintains a route to the WSN node for
the DAO Lifetime over instance VRF that is
continued with RPL over backbone.
RPL
DAO
RPL DAO
Host
Route

101
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different ROVR
Newer TID
NS DAD
(EARO)
NA (EARO)
NS
(EARO)

102
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different ROVR
Newer TID
EDAR
NA
(ARO)
DAD

103
RPL
DAO
Optional
NA(EARO)
Host
Route
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different ROVR
Newer TID
NA (EARO) with
older TID (loses)

104
Packet
NS
lookup
BBR proxies the NA
in response to NS
(Optionally polls the
device if not sleeping)
NA (EARO)

105
NS
lookup
Mixed mode ND
BBR proxying over
the backbone
NA (EARO)
Packet

106
6BBR (AP) 6LBR Router/Server6LN (STA)
RA (PIO, unicast)
Router/ServerIPv6 Router /
IPv6 ServerEthernet BackboneWi-Fi
RS (mcast)
Classical NDRFC 8505RFC 8505
NS (EARO)
EDAR
EDAC
RS (no SLLAO, for ODAD)
NS DAD (EARO, multicast)
NA (EARO, optimistic, not override, EARO)
RA(unicast)
(if no fresher BCE) NS(lookup, multicast)
NA (EARO)
Traffic using optimistic address
DAD Time Out
e.g.,
Wi-Fi
FILS
flow
<DAD time out>

108
 Association allows a proactive setting of the bridging state
Allows the APs to eliminate broadcast lookups
Compares to reactive learning bridge
 WiND
Reproduces the association model at L3
Leverages the state for address protection and SAVI
Routing inside the subnet replaces bridging
Proxy ND at the wire / wireless edge

109
6LR 6LBR6LN
RA (unicast)
RA (u|mcast)
Radio 1 Hop
SLLA
6CIO
PIO
MTU
SLLA
CONTEXT
6CIO
PIO
MTU
SLLA
CONTEXT
ABRO
6CIO
RS (mcast)
RFC 8505
RFC 8505

110
6LR 6LBRLP Node
NS (EARO)
EDAR
Radio 1 Hop
SRC = 6LR *
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_LL *
DST = 6LR_LL *
TGT = LPN **
SLLA = LPN
UID = LPN
TID included
opt: AP-ND
* Global / ULA
Create binding state
* link local unique
EUI-64
** ULA or GUA
6LR 6LBR6LN
RFC 8505RFC 8505

111
6LR 6LBRLP Node
NA (EARO)
EDAC
Radio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
TLLA = LPN
UID = LPN
TID included
6LR 6LBR6LN
RFC 8505RFC 8505

112
6LR 6LBRLP Node
NS (ARO)
DAR (ARO)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN **
SLLA = LPN
UID = LPN
TID included
Collision of binding
state
within RPL
DODAG
Different UID for
addr. LPN
NA (ARO, s=1)
DAC (ARO, s=1)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
TLLA = LPN
UID = LPN
TID included
6LR 6LBR6LN

114
6LN/6LBR 6BBR
Router/Serve
r
Ethernet
Router/Serve
r
Router/Serve
r
Ethernet / Wi-Fi
PIO
MTU
RA (u|mcast)
RA (u|mcast)
PIO
MTU
SLLA
Classical ND
RFC 8505

115
6LBR 6BBR
Router/Serve
r
Ethernet
NS DAD (ARO)
NS (ARO)
Router/Serve
r
Router/Serve
r
Ethernet / Wi-Fi
SRC = UNSPEC
DST = SNMA
TGT = LPN
UID = LPN
TID included
SRC = 6LBR
DST = 6BBR *
TGT = LPN
SLLA = 6LBR
UID = LPN
TID included
* Can be
Anycast
Create binding state
Create proxy state
6LN/6LBR 6BBR
Router/Serve
r
Router/Serve
r
Router/Serve
r
Classical NDRFC 8505

116
6LBR 6BBR
Router/Serve
r
Ethernet
NA (O) *
NA (ARO)
Router/Serve
r
Router/Serve
r
Ethernet / Wi-Fi
SRC = 6BBR
DST = 6LBR
TGT = LPN
TLLA = L6BR
UID = LPN
TID included * Omitted in general
** link local
DAD time out
SRC = 6BBR_ll **
DST = NS SRC
TLLA = L6BR
TGT = LPN
6LN/6LBR 6BBR
Router/Serve
r
Router/Serve
r
Router/Serve
r
Classical NDRFC 8505

118
First come first Serve address registration
First registration for an address owns that address till it releases it
The network prevents hijacking
Source address validation (SAVI)
Address must be topologically correct
Source of the packet owns the source address
First Hop Security only?
Proxy ownership and routing advertisements not protected yet

119
6LRLP Node
NS (EARO, CIPO*, Nonce and NDPSO**)
Radio 1 Hop
6LR6LN
AP-ND
NA (EARO(status=0))
NS (EARO(ROVR=Crypto-ID))
NA (EARO(status=Validation Requested), Nonce)
* Crypto-ID Parameters Option
** NDP Signature Option
6LBR
Radio
Mesh
EDAR
6LBR
RFC 8505
Ethernet

120
• We made the size of the ROVR tunable so we can get high
security. 64 bits seems inappropriate.
• At the moment a joining 6LN is challenged from the 6LR
The 6LBR MUST trust the 6LR
A rogue 6LR may pretend that it represents a 6LN that passed the
challenge
Should we challenge all the way from the 6LBR?
Can the Crypto-ID be used in routing protocols, how?

122
IPv6 registration mechanism
Authoritative Registrar / 6LBR gives full visibility on IP
activity, address allocation and source address ownership
Layer-3 routed (non broadcast) fringe
aggregated in a single large IPv6 subnet
Centralized control for
deterministic routing
and scheduling (PCE)
Backbone router (ND proxy)
enables Multi-Link subnet
RPL distributed routing &
scheduling for best effort
Deterministic control loops including deterministic
wired, wireless, and execution of control logic
Industrial control logic
running deterministically
in carpeted floor (Fog)
For Wi-Fi: best effort fringe
using 2.4GHz band
For Wi-Fi: converged wireless
mesh Backhaul using 6TiSCH
over .11 AC PHY in 5GHz band,
shared with Factory Automation
Fully scheduled
wireless backbone
Black: standard work Green: well advanced
Orange: in progress Brick: Not started

123
Authoritative
Registrar
Authoritative
Registrar / 6LBR
Intermediate
Registrar / 6LR
Intermediate Registrar
option. ND proxy
Backbone router
(ND proxy)
- Scalable and Multi-Link
- Reliable tracking
- IP guard (admin knows what’s where)
- Reliable (link) proxy operations, layer-2 or layer-3
- Support for legacy IPv6 devices
- Support for IPv4
Multicast & broadcast suppression
Reliable Registration
Scalable registrar
Well defined link-proxy operations
…

124
• Scale an IOT subnet to the tens of thousands
With device mobility (no renumbering)
Controlled Latency and higher Reliability using a backbone
• DeterministicAddress presence
Route towards the latest location of an address
Remove stale addresses
• Deterministic Networking / Reliable and AvailableWireless
• Low Power Edge devices

125
6LR 6LBR 6BBR
Router/Serve
r
LP Node
RPL Ethernet
NA (~O)
NS (EARO)
Proxy NS (EARO)
RPL DAO
Router/Serve
r
Router/Serve
r
Ethernet / Wi-FiRadio 1 Hop
Classical NDRFC 6550RFC 8505 RFC 8505
NA (EARO)
DAO-ACK
NA (EARO)
6LR RPL Root 6BBR
Router/Serve
r
LP Node Router/Serve
r
Router/Serve
r
NS lookup
Packet

126
DCO (status)
6LR 6LBR 6BBR
Router/Serve
r
LP Node
RPLv2 Ethernet
NA (~O)
NS (EARO)
Proxy NS (EARO)
RPL DAO
Router/Serve
r
Router/Serve
r
Ethernet / Wi-FiRadio 1 Hop
Classical NDRFC 6550RFC 8505 RFC 8505
NA (EARO, status)
DAO-ACK
NA (EARO)
6LR RPL Root 6BBR
Router/Serve
r
r
Router/Serve
r
NS DAD
NA (EARO, status)

127
6LR 6LBR 6BBR
Router/Serve
r
LP Node
RPL Ethernet
NA (~O)
NS (ARO)
NS (ARO)
RPL DAO
Router/Serve
r
Router/Serve
r
EthernetRadio 1 Hop
SRC = 6BBR
DST = NS SRC
TGT = LPN
TLLA = 6LBR
SRC = 6LR
DST = Parent *
or Root
TGT = LPN
(ROVR opt.)
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
SRC = 6LBR
DST = 6BBR
TGT = LPN
SLLA = L6BR
UID = LPN *
TID included
* Parent in storing
mode
* From binding
state
NS lookup
6LR 6LBR/Root 6BBR
Router/Serve
r
r
Router/Serve
r

129
RPLv1
An extension of IPv6 ND for MLSN
Optimized for MP2P, P2MP with Root
Optional support of P2P
P2P reactive extension (AODV)
L3: agnostic to L2 though aware of radios
RPLv2 brings
SDN /TE Model with Projected Routes for P2P
RPL Unaware Leaves
Brown field updates
Sync of configuration and capabilities exchange

130
• Minimum topological awareness (DV)
• Proactive setup; lazy/reactive cleanup
• Multi-Topology Routing (RPL Instances)
Instantiation per constraints/metrics
• Autonomic Subnet G/W Protocol
• Optimized Diffusion over NBMA
• Data Path validation
• Non-Equal Cost Multipath Fwd

131
At a given point of time
connectivity is as illustrated
and rather fuzzy
Radio link

132
Clusterhead1st pass (DIO)
Establishes a logical DAG topology
Trickle Subnet/config Info
Sets default route
Self forming / self healing
This is what nay classical DV will do but for
all destinations not just the root
2nd pass (DAO, in storing mode)
paints with addresses and prefixes
Any to any reachability
But forwarding over DAG only
saturates upper links of the DAG
And does not use the full mesh properly
Link selected as parent link
Potential link
Clusterhead
0
1
1
1
4
4
4
46
3
3
3
3
3
2
2
2
2
2
2
5
5
5

133
: : A new DODAG iteration
Rebuild the DAG …Then repaint the prefixes upon changes
A new Sequence number generated by the root
A router forwards to a parent or as a host over next iteration
: find a “quick” local repair path
Only requiring local changes !
May not be optimal according to the OF
Moving UP and Jumping are cool.
Moving Down is risky: Count to Infinity Control

134
Clusterhead
A’s link to root fails
A loses connectivity
Either poisons or detaches a subdag
In black:
the potentially impacted zone
That is A’s subDAG
Potential link
Clusterhead
0
1
1
1
4
4
4
46
3
3
3
3
3
2
2
2
2
2
2
5
5
5
A
1
1
1
3
3
3
3
3
2
2
2
2
2
2
5
5
5
4
4
4
4

135
Clusterhead
B can reparent a same Rank so B’s subDAG is
safe
The rest ofA’s subDAG is isolated
Either poison or build a floating DAG as
illustrated
In the floating DAG A is root
The structure is preserved
Potential link
Clusterhead
0
1
1
4
4
4
46
3
3
3
2
2
2
2
2
2
1
5
5
5
A
B
0
1

136
Clusterhead
Once poisoned nodes are
identified
It is possible for A to reparent safely
A’s descendants inherit from Rank shift
Note: a depth dependent timer can help
order things
Potential link
Clusterhead
0
1
1
2
4
4
4
46
3
3
3
4
4
2
2
2
2
3
3
5
5
5
A

137
Clusterhead
A new DAG iteration
In Green, the new DAG
progressing
Metrics have changed, the DAG may
be different
Forwarding upwards traffic
from old to new iteration is
allowed but not the other way
around
Potential link
Clusterhead
0
1
1
1
4
4
4
46
3
3
3
3
3
3
2
2
2
2
2
5
5
5

138
• RFC 6206:TheTrickle Algorithm
• RFC 6550: RPL: IPv6 Routing Protocol for LLNs
• RFC 6551: Routing Metrics Used for Path Calculation in LLNs
• RFC 6552: Objective Function Zero for the Routing Protocol for LLNs
• RFC 6553: RPL Option for Carrying RPL Information in Data-Plane Datagrams
• RFC 6554:An IPv6 Routing Header for Source Routes with RPL
• RFC 6719: MRHOF Objective Function with hysteresis
• RFC 6997: Reactive Discovery of Point-to-Point Routes in LLNs
•

140
ZeroTrust: the RUL could be all sorts of devices in the future and can become an attack vector
against the RPL infra.With RFC 8505 and the optional AP-ND work we isolate the RUL from RPL,
and control at the interface what gets injected in RPL
Lower code / data footprint in the RUL: RUL devices supports IPv6 (RFC 8200) but not RPL
(RFC 6550).The RUL as a 6LN uses RFC 8505 as specified by RUL draft. RFC 8505 is a simple
abstraction, the complexity for in the 6LR. So a similar RUL implementation could connect to
other types of networks.
Easier upgrade of the RPL network: no need to update the RUL leaves, which could become a lot
more numerous that the routers
Less messaging:The RUL draft avoids the duplication of ND messages (NS and then DAR) and
RPL (DAO). It’s only ND at the host to router interface, and only RPL at the router to router
interface.

141
6LBRRPL Root6LR 6LBRLP Node
RPL
NS (EARO)
keepalive EDAR
RPL DAO
Radio 1 Hop
RFC 6550RFC 8505
DAO-ACK
NA (EARO)
6LRLP Node
keepalive EDAC
First EDAR
First EDAC
Proxy NS (EARO)
Proxy NA (EARO)
6BBR
Ethernet / Serial
RFC 8505
Ethernet / Wi-Fi
RFC 8505
… DAD

142
6LBRRPL Root6LR 6LBRLP Node
RPL
NS (EARO)
keepalive EDAR
RPL DAO
Radio 1 Hop
RFC 6550RFC 8505
DAO-ACK
NA (EARO)
6LRLP Node
keepalive EDAC
Proxy NS (EARO)
Proxy NA (EARO)
6BBR
Ethernet / Serial
RFC 8505
Ethernet / Wi-Fi
RFC 8505

144
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: Internet
Dest: 56
Stuff
Src: Internet
Dest: 56
Stuff
Src: Root
Dest: 56
RPI

145
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 56
Via: 13
Via: 24
Stuff
Src: X
Dest: 56
Stuff
Via: 35
Via: 46
Src: Root
Dest: 56
RPI

146
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: 51
Dest: Root
Stuff
RPI
Same packet
format from RAL to:
• Other RAL
• Root
• The Internet
Due to RPI option
type now 0x23
Src: 51
Dest: Internet
Stuff
RPI
Src: 51
Dest: 52
Stuff
RPI
Src: Root
Dest: 56
Stuff
RPI

147
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 52
Via: 11
Via: 22
Stuff
Via: 32
Via: 42
Src: Root
Dest: 52
RPI
Src: 51
Dest: 52
Stuff
RPIRPI

148
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 52
Via: 11
Via: 22
Stuff
Src: 51
Dest: 52
Stuff
Via: 32
Via: 42
Src: 51
Dest: Root
RPI
Src: Root
Dest: 52
RPI

149
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: Root
Dest: 56
RPI
Dest:
Src: 51
Stuff
Src: 41
Dest: Root
RPI
Dest: Internet
Src: 51
Stuff
Dest: 56
Src: 51
Stuff
Dest:
Src: 51
Stuff

150
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src:
Dest: 56
Stuff
Src: Internet
Dest: 56
Stuff
Src: Root
Dest: 46
RPI
Src: 51
Dest: 56
Stuff
Src: Root
Dest: 56
Stuff
RUL addresses injected
in non-storing mode so
packet flies to the Root
which encapsulated
Src:
Dest: 56
Stuff

151
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src:
Dest: 56
Stuff
Src: Internet
Dest: 56
Stuff
Src: Root
Dest: 46
RPI
Src: 51
Dest: 56
Stuff
Src: Root
Dest: 56
Stuff
RUL addresses injected
in non-storing mode so
packet flies to the Root
which encapsulated
Src:
Dest: 56
Stuff
Via: 13
Via: 24
Via: 35

153
• Adds Centralized routing (Traffic Engineering) to RPL
E.g. Root coordinates with PCE
• Add limited Storing in Non-Storing mode and vice versa
Enough topology info in non-storing route optimization at the root
Local compression; RPL source route header becomes loose
• Also support for transversal route in Storing Mode
Works for storing and non storing routes
• Need topological information and / or device constraints
e.g. how many routes can a given RPL router store?

155
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 56
Via: 13
Via: 24
Stuff
Src: X
Dest: 56
Stuff
Via: 35
Via: 46
Src: Root
Dest: 56
RPI

156
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55
New (projected)
DAO with path
segment unicast
to target 56 via
35 (ingress) and
46 (egress)
56

157
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Storing mode
DAO with
lifetime along
segment

158
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
DAO-ACK (alt:
non storing DAO)
unicast, self 35
as parent, final
destination 56 as
target

159
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
DAO from 46 installs a
route to 56 in 35
(all nodes in projected
route from ingress
included to egress
excluded)
=> egress should
already have a route to
target
56 via 46
Preexisting
connected route to 56

160
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Non
source
routed
DATA
Path

161
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Non
source
routed
DATA
Path
Loose Source
routed DATA Path
Packet to 13,
RH 24, 35, 56

162
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 56
Via: 13
Via: 24
Stuff
Src: X
Dest: 56
Stuff
Via: 35
Src: Root
Dest: 56
RPI
Via: 46

163
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55
Adding New
(projected) DAO
with path
segment unicast
to target 56 via
13 (ingress), 24,
and 35 (egress)
56

164
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Storing mode
DAO (forced)
with lifetime
along
segment
Storing mode
DAO with
lifetime along
segment

165
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
DAO-ACK
unicast, self 13
as parent, final
destination 56 as
target

166
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
56 via 46
Preexisting
56 via 35
56 via 24

167
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Non source
routed
DATA Path

168
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 56
Via: 13
Via: 24
Stuff
Src: X
Dest: 56
Stuff
Via: 35
Src: Root
Dest: 56
RPI
Via: 46

169
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55
ALT: Adding New
(projected) DAO
with path
segment unicast
to target 35 via
13 (ingress) and
24 (egress)
56

170
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Storing mode
DAO with
lifetime along
segment

171
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
DAO-ACK
unicast, self 13
as parent, final
destination 56 as
target

172
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
56 via 46
Preexisting
Preexisting connected
route to 35
35 via 24

173
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
routed
DATA Path
Loose Source
routed DATA Path
Packet to 35,
RH 56
routed
DATA Path

174
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Src: X
Dest: 56
Via: 13
Via: 24
Stuff
Src: X
Dest: 56
Stuff
Via: 35
Src: Root
Dest: 56
RPI
Via: 46

177
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56

178
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56

179
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56

180
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
New non-storing
P-DAO with path
segment unicast
to target 41 via
42

181
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
DAO ACK

182
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Packet for 41

183
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
IP in IP encapsulation
with SRH 42, 41

184
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
storing P-DAO
with path
segment unicast
to target 51 via
41 (egress)

185
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Packet for 51

186
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
IP in IP encapsulation
with SRH 42, 41

187
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Packet for 51

189
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
New (projected)
DAO with path
segment unicast
to target 53 via
41 (ingress), 42
and 43 (egress)

190
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Storing mode
DAO with
lifetime along
segment

191
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
Storing mode
DAO with
lifetime along
segment

192
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56
DAO-ACK
unicast, self 41
as parent, final
destination 53 as
target

193
11 12 13
25242322
3534333231
464544434241
DAG Root
Application
Server D
51 52 53 55 56

195
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
B: Rank 530
D: Rank 510
C: Rank 610
E: Rank 620
A: Rank 380
Initial situation;
• Rank is computed on some metric e.g. LQI.
• Node A has a single parent, node P
• A can hear D and C which are in its subdag
• A can hear B and E which are not

196
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
A: Rank 380
B: Rank 530
D: Rank 510
C: Rank 610
E: Rank 620
Say that the radio connectivity between A
and P dies. A looses it only feasible parent.
Its neighbors are all deeper (higher Rank) so
it cannot reattach without risking a loop.
Attaching to D and C would create a loop.
Attaching to E or B would not create a loop.
Trouble is A does not know.
196

197
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
B: Rank 540
D: Rank ∞
C: Rank ∞
E: Rank 620
RRFC 6550 says that node A must detach, freeze,
and wait for the resulting of the freezing.
Freezing may be done by poisoning, IOW sending
infinite rank. A (preferable IMHO) alternative is to
form a floating DAG, which spreads the freezing
differently with the advantage to maintain the
shape of the DODAG in place
After some time, the devices that depended on A
are (mostly) frozen or re-parented elsewhere.
From that point, RPL says that the frozen nodes
can all reparent, that’s A, D and C here, and then
the network is fixed
The problem is the “After some time” above. That
is disruptive to traffic, which can be unacceptable
A: Rank ∞
197

201
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
B: Rank 530
D: Rank 510
C: Rank 610
E: Rank 620
A selects a number if neighbors as prospective
parents.
(Optional) We create a new RPI flag for loop
detection.
A sends packets using them randomly setting its Rank
in RPI to OxFFFF, and sets a new RPI “P” flag. (Alt is set
rank to 0xFFFE)
A node that receives a packet with RPI “P” flag from a
parent returns it with the RPI “F” flag set, indicating
forwarding error and A removes it from the
prospective parents. Alt, it may forward via another
parent.
During that period, A destroys any packet coming back
with the RPI ”P” flag on.
A: Rank 380
Proposal use to keep forwarding and to use the data
path to detect lower nodes that are feasible successors:
201

202
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
B: Rank 530
D: Rank 510
C: Rank 610
E: Rank 620
Proposal use the datapath to select a parent
faster:
A selects a number if neighbors as prospective
parents.
We create a new OAM which allows A to “ping”
the Root. The packet indicates the selected
parent.
(Optional) The nodes that forward the packet add
their IP address as a trace root
A sends a version of that packet unicast to all the
selected neighbors
A: Rank 380
202

203
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
B: Rank 530
D: Rank 510
C: Rank 610
E: Rank 620
The messages that are responded by the root
contain feasible successors. Getting that back
may be slow.
A picks them as they come, keeping the best
so far as preferred parent
A: Rank 380
203

204
Root
Rank 1
Rank 110
P: Rank 250
Rank 260
B: Rank 530
D: Rank 510
C: Rank 610
E: Rank 620
Loops will cause the packet to come back to A.
A recognizes them (e.g. source address is A, a
new flag in RPI), and eliminates the neighbor
indicated in the packet from the potential
parents
A: Rank 380
204

206
An Arc is a 2 ended reversible path
Edges are directed outwards; links within are reversible
An arc is resilient to any link or Junction break by returning links
Links are oriented from cursor to edges and returned by moving the cursor.
C
Rev
Rev Rev
Rev
EdgeCursor

207
An infrastructure Arc is multihop
An Edge Junction terminates one reversible link
An Intermediate Junction terminates two reversible links
Links are oriented from a mobile cursor (C) Junction outwards
R
A collapsed Arc does not have an Intermediate Junction
An Edge Junction may belong to multiple collapsed Arcs
C
Rev
Rev Rev
Rev
Edge JunctionIntermediate Junction
207

208
Junctions may have multiple incoming links
An Edge Junction might have multiple outgoing links
An intermediate Junction has no outgoing link but along the Arc
J
C
Rev
Rev Rev
Rev
208

209
ROOT
A
B
Software-defined Projected ARROW
Arcs for RPL Routing Over Wireless
- Metrics are accumulated as usual in RPL (separated from Rank)
- Siblings are allowed (all ARC members have the same Rank)
- Rank of ARC members defines ARC height

210
- Sparrow requires non-storing mode (NS-mode).
- Nodes must advertise at least 2 parents and report
metrics
- Root computes ARC Set based on NS-mode DAO
- Need to update DAO projection to enable inverting
parent->child links
210

211
R
A
D
L
B
K
J
C
E
F
G
H I
M
M
211

212
In blue the preferred
parent path
In red the alt path as
RPL computes them
based on Rank
relationship.
These « arrows » are
advertised to the
root using NS-Mode
We see that most
nodes do not have 2
non-congruent
solutions
(in fact, only J does!)
R
A
D
L
B
K
J
C
E
F
G
H I
M
N
Rank = 1
Rank = 3
Rank = 2
Rank = 4
Rank = 5
Rank = 6
Rank = 5
Rank = 7
Rank = 10
Rank = 8
Rank = 5
Rank = 10
Rank = 9
Rank = 10 Rank = 12
212

213
Original RPL DAG
R
A
D
L
B
K
J
C
E
F
G
H I
M
N
ARC Re-organized DAG
R
A
D
L
B
K
J
C
E
F
G
H I
Rev
Rev
Rev
Rev
Rev
Rev
M
N
Rev
213

214
DAG visualization == ARC visualization
R
A
D
L
B
K
J
C
E
F
G
H I
M
N
R
A
D
L
B
K
J
C
E
F
G
H I
Rev
Rev
Rev
Rev
Rev
Rev
M
N Rev
214

215
1) Root considers changes made on
DODAG and notifies nodes, e.g.
it tells C that D is not more a
feasible successor and it tells D
that C is a feasible successor.
Same goes between E and F. This
can be done with a novel
variation of the DAO projection
2) For collapsed ARCs, e.g. D, we
are all set
3) For other nodes that are not on
collased ARCs, the root
computes a path along the ARC
towards the other exit of the
ARC. For Node C that is Node B.
R
A
D
L
B
K
J
C
E F
G
H I
M
N
R
A
D
L
B
K
J
C
E F
G
H I
Rev
Rev
Rev
Rev
Rev
Rev
M
N
Rev
Use C as
alt parent
Do Not
Use D as
alt parent
215

216
1) The path to B is installed as either storing or
non storing projected DAO
2) In NS Mode the source route path from the
node to the other ARC edge is indicated to
each node
3) In Storing Mode, a route is created from both
ends of the ARC allowing each edge (a,d all
nodes in between) to route to the other
edge
4) If C loses connectivity to A, it uses a tunnel to
B till RPL completes local repair. Tunnel has a
routing header in NS mode.
5) When the Edge decaps, it must forward
outside the ARC; it cannot reinject in the
ARC.
R
A
D
L
B
K
J
C
E F
G
H I
Rev
Rev
Rev
Rev
Rev
Rev
M
N
Rev
Non storing DAO:
indicating
Source Route path to
B
Source Route
path to B
Projected DAOR
A
D
L
B
K
J
C
E F
G
H I
Rev
Rev
Rev
Rev
Rev
Rev
M
N
Rev
DAO Ack
Storing mode
Route to B
Projected DAO
216

218
DV, stretch optimized for P2MP/MP2P
Peer selection /Trickle and OFs
Anisotropy, lazy maintenance,
Non-Storing Mode,
Decoupled Metrics, NECM DAGs,
Datapath validation
Local and Global Recovery
Coupling with MIPv6 and NEMO
Dynamic Topologies
Density
Constrained Objects
Fuzzy Links
Routing, local Mobility
Global Mobility
New Radios issues: Addressed in RPL by:

219
• AODV RPL to be Standard track Reactive model (P2P RPL rfc6997 is experimental)
• Centralized route computation (e.g. draft-ietf-roll-dao-projection ), SDN-Like
• BIER unicast and multicast routing, Storing vs. Non-Storing, bit-index vs. Bloom Filters
• DAG limitations and Fast Reroute
Sibling routing, more resilient schemes (ARCs)
• Better / Faster (re) join (with DIS message e.g. draft-zhong-roll-dis-modifications)
• Stimulated updates (lookup) with targetted DAO
• Asymmetrical links
• Multi-Topology routing and cascading

© 2012 Cisco and/or its affiliates. All rights reserved.IoT6 220Unclassified
“We might be at the eve of pervasive networking, a vision for the Internet
where every person and every device is connected to the network in the
ultimate realization of Metcalf's Law.”

IPv6 ND 2020

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IPv6 ND 2020

Similar to IPv6 ND 2020 (20)

Recently uploaded

Recently uploaded (20)

IPv6 ND 2020