draft-ietf-roll-unaware-leaves-00.txt   draft-ietf-roll-unaware-leaves-01.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 6550, 8505 (if approved) May 28, 2019 Updates: 6550, 8505 (if approved) July 2, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: November 29, 2019 Expires: January 3, 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-00 draft-ietf-roll-unaware-leaves-01
Abstract Abstract
This specification leverages 6LoWPAN ND to provide a unicast and This specification leverages 6LoWPAN ND to provide a unicast and
multicast routing service in a RPL domain to 6LNs that do not multicast routing service in a RPL domain to 6LNs that do not
participate to RPL. participate to RPL.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2019. This Internet-Draft will expire on January 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6
4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 7 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 7
5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 7 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 7
6. Dependencies on the 6LN . . . . . . . . . . . . . . . . . . . 8 6. Dependencies on the 6LN . . . . . . . . . . . . . . . . . . . 8
7. Protocol Operations for Unicast Addresses . . . . . . . . . . 8 7. Protocol Operations for Unicast Addresses . . . . . . . . . . 9
7.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 8 7.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 9
7.2. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 11 7.2. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 11
7.3. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 12 7.3. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 12
7.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 13 7.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 13
7.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 14 7.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 14
8. Protocol Operations for Multicast Addresses . . . . . . . . . 15 8. Protocol Operations for Multicast Addresses . . . . . . . . . 15
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 21 skipping to change at page 3, line 21
forwarding solutions towards the Root of the topology via so-called forwarding solutions towards the Root of the topology via so-called
parents. RPL is designed to adapt to fuzzy connectivity, whereby the parents. RPL is designed to adapt to fuzzy connectivity, whereby the
physical topology cannot be expected to reach a stable state, with a physical topology cannot be expected to reach a stable state, with a
lazy control that creates routes proactively but only fixes them when lazy control that creates routes proactively but only fixes them when
they are used by actual traffic. It results that RPL provides they are used by actual traffic. It results that RPL provides
reachability for most of the LLN nodes, most of the time, but does reachability for most of the LLN nodes, most of the time, but does
not really converge in the classical sense. RPL provides unicast and not really converge in the classical sense. RPL provides unicast and
multicast routing services back to RPL-Aware nodes (RANs). A RAN multicast routing services back to RPL-Aware nodes (RANs). A RAN
will inject routes to self using Destination Advertisement Object will inject routes to self using Destination Advertisement Object
(DAO) messages sent to either their parents in Storing Mode or to the (DAO) messages sent to either their parents in Storing Mode or to the
Root indicating their parent in Non-Storing mode. This process Root indicating their parent in Non-Storing Mode. This process
effectively forms a DODAG back to the device that is a subset of the effectively forms a DODAG back to the device that is a subset of the
DODAG to the Root with all links reversed. DODAG to the Root with all links reversed.
When a routing protocol such as RPL is used to maintain reachability When a routing protocol such as RPL is used to maintain reachability
within a Non-Broadcast Multi-Access (NBMA) subnet, some nodes may act within a Non-Broadcast Multi-Access (NBMA) subnet, some nodes may act
as routers and participate to the routing operations whereas others as routers and participate to the routing operations whereas others
may be plain hosts. In RPL terms, a plain host that does not may be plain hosts. In RPL terms, a plain host that does not
participate to the routing protocol is called a Leaf. It must be participate to the routing protocol is called a Leaf. It must be
noted that a 6LN could participate to RPL and inject DAO routes to noted that a 6LN could participate to RPL and inject DAO routes to
self, but refrain from advertising DIO and get children. In that self, but refrain from advertising DIO and get children. In that
skipping to change at page 5, line 14 skipping to change at page 5, line 14
o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919], Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
o "Neighbor Discovery Optimization for Low-power and Lossy Networks" o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], and [RFC6775], and
o "Registration Extensions for IPv6 over Low-Power Wireless Personal o "Registration Extensions for IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]. Area Network (6LoWPAN) Neighbor Discovery" [RFC8505].
2.3. Subset of a 6LoWPAN Glossary 2.3. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
6BBR: 6LoWPAN Backbone Router (proxy for the registration) AR: Address Resolution (aka Address Lookup)
6LBR: 6LoWPAN Border Router (authoritative on DAD) 6BBR: 6LoWPAN Backbone Router (proxy ND)
6LN: 6LoWPAN Node 6LBR: 6LoWPAN Border Router (an Address Registrar that is
authoritative on DAD)
6LR: 6LoWPAN Router (relay to the registration process) 6LN: 6LoWPAN Node (a Low Power host or router)
6LR: 6LoWPAN Router
6CIO: Capability Indication Option 6CIO: Capability Indication Option
(E)ARO: (Extended) Address Registration Option (E)ARO: (Extended) Address Registration Option
(E)DAR: (Extended) Duplicate Address Request (E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation (E)DAC: (Extended) Duplicate Address Confirmation
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network (a typical IoT network) LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol NDP: Neighbor Discovery Protocol
NS: Neighbor Solicitation NS: Neighbor Solicitation
RA: Router Advertisement
ROVR: Registration Ownership Verifier (pronounced rover) ROVR: Registration Ownership Verifier (pronounced rover)
RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) RPI: RPL Packet Information (an Option in the Hop-By_Hop header)
RA: Router Advertisement
RAL: RPL-Aware Leaf
RS: Router Solicitation RS: Router Solicitation
TSCH: Timeslotted Channel Hopping RPL: IPv6 Routing Protocol for LLNs (pronounced ripple)
RUL: RPL-Unaware Leaf
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
3. 6LoWPAN Neighbor Discovery 3. 6LoWPAN Neighbor Discovery
The IPv6 [RFC8200]Neighbor Discovery (IPv6 ND) Protocol (NDP) suite The IPv6 [RFC8200]Neighbor Discovery (IPv6 ND) Protocol (NDP) suite
[RFC4861] [RFC4862] defined for fast media such a Ethernet, relies [RFC4861] [RFC4862] defined for fast media such a Ethernet, relies
heavily on multicast operations for address discovery and duplicate heavily on multicast operations for address discovery and duplicate
address detection (DAD). address detection (DAD).
skipping to change at page 8, line 22 skipping to change at page 8, line 35
and not aware of RPL. Still, a minimal RPL-independent functionality and not aware of RPL. Still, a minimal RPL-independent functionality
is expected from the 6LN in order to operate properly as a RLU; in is expected from the 6LN in order to operate properly as a RLU; in
particular: particular:
o the 6LN MUST implement [RFC8505] and set the 'R' flag in the EARO o the 6LN MUST implement [RFC8505] and set the 'R' flag in the EARO
option. The 'R' flag is used to determine whether the Registering option. The 'R' flag is used to determine whether the Registering
Node is a RUL, not aware of the RPL operation in the network, and Node is a RUL, not aware of the RPL operation in the network, and
thus does not participate to it. A 6LN is considered to be a RUL thus does not participate to it. A 6LN is considered to be a RUL
if and only if it sets the 'R' flag in the EARO. if and only if it sets the 'R' flag in the EARO.
o RPL data packets are often encapsulated using IP in IP and in non- o RPL data packets are often encapsulated using IP in IP and in Non-
storing mode, packets going down will carry an SRH as well. RPL Storing Mode, packets going down will carry an SRH as well. RPL
data packets also typically carry a Hop-by-Hop Header to transport data packets also typically carry a Hop-by-Hop Header to transport
a RPL Packet Information (RPI) [RFC6550]. These additional a RPL Packet Information (RPI) [RFC6550]. These additional
headers are called RPL artifacts. headers are called RPL artifacts.
o When IP-in-IP is used and the outter headers terminate at the 6LR o An arbitrary 6LN is expected to support IPv6-in-IPv6 encapsulation
when it is the destination of the outer header. If the 6LN is a
host, it is expected to drop the inner packet if it is not the
destination of the inner header.
o An arbitrary 6LN is expected to process an unknown Option Type in
a Hop-by-Hop Header as prescribed by section 4.2 of [RFC8200].
This means in particular that an RPI with an Option Type of 0x23
[I-D.ietf-roll-useofrplinfo] is ignored when not understood.
o An arbitrary 6LN is expected to process an unknown Routing Header
Type as prescribed by section 4.4 of [RFC8200]. This means in
particular that Routing Header with a Routing Type of 3 [RFC6553]
is ignored when the Segments Left is zero, and dropped otherwise.
o When IP-in-IP is used and the outer headers terminate at the 6LR
that generated the DAO, then the 6LR decapsulates the packet to that generated the DAO, then the 6LR decapsulates the packet to
the 6LN. In that case the 6LN gets a packet that is free of RPL the 6LN. In that case the 6LN gets a packet that is free of RPL
artifacts. IP-in-IP to the 6LR MUST be used if the 6LN cannot artifacts. IP-in-IP to the 6LR MUST be used if the 6LN cannot
handle the RPL artifacts or the way they are compressed [RFC8138]. handle or ignore the RPL artifacts or the way they are compressed
It SHOULD be used it there is a particular bandwidth or power [RFC8138]. It SHOULD be used it there is a particular bandwidth
constraint at the 6LN. or power constraint at the 6LN that justifies saving the
encapsulation at the last hop.
o In order to save the IP-in-IP encapsulation and to suport storing o In order to save the IP-in-IP encapsulation and to support Storing
mode of operation, it is preferred that the 6LN can ignore an RPI Mode of operation, it is preferred that the 6LN can ignore an RPI
and consume a routing header in both the native and compressed and consume a routing header in both the native and compressed
forms. In order to enable IP-in-IP to a 6LN in non storing mode, forms. In order to enable IP-in-IP to a 6LN in Non-Storing Mode,
it is also of interest that the 6LN supports decapsulating IP-in- it is also of interest that the 6LN supports decapsulating IP-in-
IP in both forms. But since the preferred behaviour when using IP in both forms. But since the preferred behaviour when using
IP-in-IP is that the outter headers terminate at the 6LR, IP-in-IP is that the outter headers terminate at the 6LR,
supporting this capability is secondary. supporting this capability is secondary.
7. Protocol Operations for Unicast Addresses 7. Protocol Operations for Unicast Addresses
7.1. General Flow 7.1. General Flow
This specification enables to save the exchange of Extended Duplicate This specification enables to save the exchange of Extended Duplicate
skipping to change at page 9, line 19 skipping to change at page 9, line 50
the registration lifetime in the NS(EARO) message from the 6LN. the registration lifetime in the NS(EARO) message from the 6LN.
From the perspective of the 6LN, the registration flow happens From the perspective of the 6LN, the registration flow happens
transparently; it is not delayed by the proxy RPL operation, so the transparently; it is not delayed by the proxy RPL operation, so the
device does not need to wait more whether RPL proxy operation happens device does not need to wait more whether RPL proxy operation happens
or not. The flows below are RPL Non-Storing Mode examples. In or not. The flows below are RPL Non-Storing Mode examples. In
Storing Mode, the DAO ACK may not be present, and the DAO messages Storing Mode, the DAO ACK may not be present, and the DAO messages
cascade from child to parent all the way to the DODAG Root. cascade from child to parent all the way to the DODAG Root.
On the first registration, illustrated in Figure 2, from the On the first registration, illustrated in Figure 2, from the
perspective of the 6LR in non-storing mode, the Extended Duplicate perspective of the 6LR in Non-Storing Mode, the Extended Duplicate
Address message takes place as prescribed by [RFC8505]. When Address message takes place as prescribed by [RFC8505]. When
successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR, successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR,
and the 6LR injects the Registered Address in RPL using DAO/DAO-ACK and the 6LR injects the Registered Address in RPL using DAO/DAO-ACK
exchanges all the way to the RPL DODAG Root. The protocol does not exchanges all the way to the RPL DODAG Root. The protocol does not
carry a specific information that the Extended Duplicate Address carry a specific information that the Extended Duplicate Address
messages were already exchanged, so the Root proxies them anyway. messages were already exchanged, so the Root proxies them anyway.
Note that in Storing Mode the DAO ACK is generated from the parent Note that in Storing Mode the DAO ACK is generated from the parent
that does not necessary wait for the grand parent to acknowledge, so that does not necessary wait for the grand parent to acknowledge, so
the DAO-ACK is no guarantee that the keep-alive EDAR succeeded. On the DAO-ACK is no guarantee that the keep-alive EDAR succeeded. On
the other hand, th eflows can be nested in non storing mode, and it the other hand, the flows can be nested in Non-Storing Mode, and it
is possible to carry information such as an updated lifetime from the is possible to carry information such as an updated lifetime from the
6LBR all the way to the 6LN. 6LBR all the way to the 6LN.
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | Extended DAR | | | Extended DAR |
| |-------------------------------->| | |-------------------------------->|
| | | | | |
skipping to change at page 11, line 5 skipping to change at page 11, line 5
illustrated in Figure 3, the 6LR redistributes the Registered Address illustrated in Figure 3, the 6LR redistributes the Registered Address
NS(EARO) in RPL. This causes the RPL DODAG Root to refresh the state NS(EARO) in RPL. This causes the RPL DODAG Root to refresh the state
in the 6LBR with a keep-alive EDAC message. The keep-alive EDAC in the 6LBR with a keep-alive EDAC message. The keep-alive EDAC
lacks the Registration Ownership Verifier (ROVR) information, since lacks the Registration Ownership Verifier (ROVR) information, since
it is not present in RPL DAO messages, but the EDAC message sent in it is not present in RPL DAO messages, but the EDAC message sent in
response by the 6LBR contains the actual value of the ROVR field for response by the 6LBR contains the actual value of the ROVR field for
that registration. This enables the RPL Root to perform the proxy- that registration. This enables the RPL Root to perform the proxy-
registration for the Registered Address and attract traffic captured registration for the Registered Address and attract traffic captured
over the backbone by the 6BBR and route it back to the device. over the backbone by the 6BBR and route it back to the device.
6LN 6LR Root 6LBR 6BBR 6LN 6LR Root 6LBR 6BBR
| | | | | | | | | |
| NS(EARO) | | | | | NS(EARO) | | | |
|--------------->| | | | |-------------->| | | |
| NA(EARO) | | | | | NA(EARO) | | | |
|<---------------| | | | |<--------------| | | |
| | | | | | | | | |
| | DAO | | | | | DAO | | |
| |-------------->| | | | |-------------->| | |
| | | | | | | | | |
| | | keep-alive EDAR | | | | | keep-alive EDAR | |
| | |---------------->| | | | |---------------->| |
| | | EDAC(ROVR) | | | | | EDAC(ROVR) | |
| | |<----------------| | | | |<----------------| |
| | | | | | | | | |
| | | proxy NS(EARO) | | | | proxy NS(EARO) |
| | |-------------------------------->| | | |------------------------------->|
| | | proxy NA(EARO) | | | | proxy NA(EARO) |
| | |<--------------------------------| | | |<-------------------------------|
| | | | | | | | | |
| | DAO ACK | | | | | DAO ACK | | |
| |<--------------| | | | |<--------------| | |
| | | | | | | | | |
Figure 3: Next Registration Flow Figure 3: Next Registration Flow
Note that any of the functions 6LR, Root and 6LBR might be collapsed Note that any of the functions 6LR, Root and 6LBR might be collapsed
in a single node, in which case the flow above happens internally, in a single node, in which case the flow above happens internally,
and possibly through internal API calls as opposed to messaging. and possibly through internal API calls as opposed to messaging.
7.2. 6LN Operation 7.2. 6LN Operation
This specification does not alter the operation of a 6LoWPAN ND- This specification does not alter the operation of a 6LoWPAN ND-
skipping to change at page 13, line 21 skipping to change at page 13, line 21
The DAO message advertising the Registered Address MUST be The DAO message advertising the Registered Address MUST be
constructed as follows: constructed as follows:
o The Registered Address is placed in a RPL Target Option in the DAO o The Registered Address is placed in a RPL Target Option in the DAO
message as the Target Prefix, and the Prefix Length is set to 128 message as the Target Prefix, and the Prefix Length is set to 128
o the External 'E' flag in the Transit Information Option (TIO) o the External 'E' flag in the Transit Information Option (TIO)
associated to the Target Option is set to indicate that the 6LR associated to the Target Option is set to indicate that the 6LR
redistributes an external target into the RPL network. This is redistributes an external target into the RPL network. This is
how the root knows in non-storing mode to use IP-in-IP and how the Root knows in Non-Storing Mode to use IP-in-IP and
terminate the outters headers at the 6LR that generated the DAO. terminate the outters headers at the 6LR that generated the DAO.
o the Path Lifetime in the TIO is computed from the Lifetime in the o the Path Lifetime in the TIO is computed from the Lifetime in the
EARO Option to adapt it to the Lifetime Units used in the RPL EARO Option to adapt it to the Lifetime Units used in the RPL
operation. Note that if the lifetime is 0, then the 6LR generates operation. Note that if the lifetime is 0, then the 6LR generates
a No-Path DAO message that cleans up the routes down to the a No-Path DAO message that cleans up the routes down to the
Address of the 6LN. Address of the 6LN.
o the Path Sequence in the TIO is set to the TID value found in the o the Path Sequence in the TIO is set to the TID value found in the
EARO option. EARO option.
skipping to change at page 15, line 47 skipping to change at page 15, line 47
start receiving the flow immediately. Since multicast Layer-2 start receiving the flow immediately. Since multicast Layer-2
messages are avoided, it is important that the asynchronous messages messages are avoided, it is important that the asynchronous messages
for unsolicited Report and Done are sent reliably, for instance using for unsolicited Report and Done are sent reliably, for instance using
an Layer-2 acknoledgement, or attempted multiple times. an Layer-2 acknoledgement, or attempted multiple times.
The 6LR acts as a generic MLD querier and generates a DAO for the The 6LR acts as a generic MLD querier and generates a DAO for the
multicast target. The lifetime of the DAO is set to be in the order multicast target. The lifetime of the DAO is set to be in the order
of the Query Interval, yet larger to account for variable propagation of the Query Interval, yet larger to account for variable propagation
delays. delays.
The root proxies the MLD echange as listener with the 6BBR acting as The Root proxies the MLD echange as listener with the 6BBR acting as
the querier, so as to get packets from a source external to the RPL the querier, so as to get packets from a source external to the RPL
domain. Upon a DAO with a multicast target, the RPL root checks if domain. Upon a DAO with a multicast target, the RPL Root checks if
it is already registered as a listener for that address, and if not, it is already registered as a listener for that address, and if not,
it performs its own unsolicited Report for the multicast target. it performs its own unsolicited Report for the multicast target.
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
| unsolicited Report | | | | unsolicited Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | | | | <L2 ack> | | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
skipping to change at page 18, line 28 skipping to change at page 18, line 28
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[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,
DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012, RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>. <https://www.rfc-editor.org/info/rfc6606>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
skipping to change at page 19, line 13 skipping to change at page 19, line 22
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
progress), April 2019.
[I-D.ietf-roll-efficient-npdao] [I-D.ietf-roll-efficient-npdao]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", draft-ietf-roll-efficient-npdao-11 Route Invalidation", draft-ietf-roll-efficient-npdao-13
(work in progress), May 2019. (work in progress), June 2019.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPL
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-29 (work in progress), May 2019. roll-useofrplinfo-30 (work in progress), June 2019.
[IEEEstd802154]
IEEE standard for Information Technology, "IEEE Standard
for Local and metropolitan area networks-- Part 15.4: Low-
Rate Wireless Personal Area Networks (LR-WPANs)".
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur,
Ed., "Performance Evaluation of the Routing Protocol for Ed., "Performance Evaluation of the Routing Protocol for
Low-Power and Lossy Networks (RPL)", RFC 6687, Low-Power and Lossy Networks (RPL)", RFC 6687,
DOI 10.17487/RFC6687, October 2012, DOI 10.17487/RFC6687, October 2012,
 End of changes. 31 change blocks. 
68 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/