draft-ietf-roll-unaware-leaves-12.txt   draft-ietf-roll-unaware-leaves-13.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505 (if approved) M. Richardson Updates: 6550, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 18 September 2020 17 March 2020 Expires: 18 September 2020 17 March 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-12 draft-ietf-roll-unaware-leaves-13
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide routing This specification extends RFC6550 and RFC8505 to provide routing
services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND
but do not participate to RPL. This specification also enables the but do not participate to RPL. This specification also enables the
RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG.
Status of This Memo Status of This Memo
skipping to change at page 2, line 35 skipping to change at page 2, line 35
6.2.1. Support of IPv6 Encapsulation . . . . . . . . . . . . 13 6.2.1. Support of IPv6 Encapsulation . . . . . . . . . . . . 13
6.2.2. Support of the HbH Header . . . . . . . . . . . . . . 13 6.2.2. Support of the HbH Header . . . . . . . . . . . . . . 13
6.2.3. Support of the Routing Header . . . . . . . . . . . . 13 6.2.3. Support of the Routing Header . . . . . . . . . . . . 13
7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13 7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13
8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14 8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15
9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 16 9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 16
9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 18 9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 18
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 19 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 19
9.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 19 9.2.1. By the RUL Acting as 6LN . . . . . . . . . . . . . . 19
9.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. By the RPL Border Router Acting as 6LR . . . . . . . 20
9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 22 9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 22
9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 23 9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 23
10. Protocol Operations for Multicast Addresses . . . . . . . . . 24 10. Protocol Operations for Multicast Addresses . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1. Resizing the ARO Status values . . . . . . . . . . . . . 26 12.1. Resizing the ARO Status values . . . . . . . . . . . . . 26
12.2. New DODAG Configuration Option Flag . . . . . . . . . . 26 12.2. New DODAG Configuration Option Flag . . . . . . . . . . 27
12.3. RPL Target Option Flags . . . . . . . . . . . . . . . . 27 12.3. RPL Target Option Flags . . . . . . . . . . . . . . . . 27
12.4. New Subregistry for the RPL Non-Rejection Status 12.4. New Subregistry for the RPL Non-Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 27 values . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.5. New Subregistry for the RPL Rejection Status values . . 27 12.5. New Subregistry for the RPL Rejection Status values . . 27
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
14. Normative References . . . . . . . . . . . . . . . . . . . . 28 14. Normative References . . . . . . . . . . . . . . . . . . . . 28
15. Informative References . . . . . . . . . . . . . . . . . . . 30 15. Informative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Compression . . . . . . . . . . . . . . . . 31 Appendix A. Example Compression . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
skipping to change at page 3, line 31 skipping to change at page 3, line 31
allows a routing stretch (see [RFC6687]), whereby routing is only allows a routing stretch (see [RFC6687]), whereby routing is only
performed along an acyclic graph optimized to reach a Root node, as performed along an acyclic graph optimized to reach a Root node, as
opposed to straight along a shortest path between 2 peers, whatever opposed to straight along a shortest path between 2 peers, whatever
that would mean in a given LLN. This trades the quality of peer-to- that would mean in a given LLN. This trades the quality of peer-to-
peer (P2P) paths for a vastly reduced amount of control traffic and peer (P2P) paths for a vastly reduced amount of control traffic and
routing state that would be required to operate a any-to-any shortest routing state that would be required to operate a any-to-any shortest
path protocol. Finally, broken routes may be fixed lazily and on- path protocol. Finally, broken routes may be fixed lazily and on-
demand, based on dataplane inconsistency discovery, which avoids demand, based on dataplane inconsistency discovery, which avoids
wasting energy in the proactive repair of unused paths. wasting energy in the proactive repair of unused paths.
In provide alternate paths in lossy networks, RPL forms Direction- To provide alternate paths in lossy networks, RPL forms Direction-
Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information
Solicitation (DIS) and DODAG Information Object (DIO) messages. For Solicitation (DIS) and DODAG Information Object (DIO) messages. For
many of the nodes, though not all, a DODAG provides multiple many of the nodes, though not all, a DODAG provides multiple
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 the routes proactively, but may only fix lazy control that creates the routes proactively, but may only fix
them reactively, upon actual traffic. The result is that RPL them reactively, upon actual traffic. The result is that RPL
provides reachability for most of the LLN nodes, most of the time, provides reachability for most of the LLN nodes, most of the time,
but may not converge in the classical sense. but may not converge in the classical sense.
skipping to change at page 9, line 10 skipping to change at page 9, line 10
could be extended to RPL. On the other hand, it adds the ROVR to the could be extended to RPL. On the other hand, it adds the ROVR to the
DAO to build the proxied EDAR at the Root (see Section 8), which DAO to build the proxied EDAR at the Root (see Section 8), which
means that nodes that are aware of the Host route to the 6LN are made means that nodes that are aware of the Host route to the 6LN are made
aware of the associated ROVR as well. aware of the associated ROVR as well.
3.3. RFC 8505 Extended DAR/DAC 3.3. RFC 8505 Extended DAR/DAC
[RFC8505] updates the periodic DAR/DAC exchange that takes place [RFC8505] updates the periodic DAR/DAC exchange that takes place
between the 6LR and the 6LBR using Extended DAR/DAC messages which between the 6LR and the 6LBR using Extended DAR/DAC messages which
can carry a ROVR field of variable size. The periodic EDAR/EDAC can carry a ROVR field of variable size. The periodic EDAR/EDAC
exchange is triggered by a NS(EARO) message and is intended to create exchange is triggered by a NS(EARO) message and is intended to
and then refresh the corresponding state in the 6LBR for a lifetime create, refresh and delete the corresponding state in the 6LBR for a
that is indicated by the 6LN. lifetime that is indicated by the 6LN.
Conversely, RPL [RFC6550] specifies a periodic DAO from the 6LN all Conversely, RPL [RFC6550] specifies a periodic DAO from the 6LN all
the way to the Root that maintains the routing state in the RPL the way to the Root that maintains the routing state in the RPL
network for the lifetime indicated by the source of the DAO. This network for the lifetime indicated by the source of the DAO. This
means that for each address, there are two keep-alive messages that means that for each address, there are two keep-alive messages that
traverse the whole network, one to the Root and one to the 6LBR. traverse the whole network, one to the Root and one to the 6LBR.
This specification removes the extraneous keep-alive across the LLN. This specification removes the extraneous keep-alive across the LLN.
The 6LR turns the periodic Address Registration from the RUL into a The 6LR turns the periodic Address Registration from the RUL into a
DAO message to the Root on every refresh, but it only generates the DAO message to the Root on every refresh, but it only generates the
skipping to change at page 12, line 32 skipping to change at page 12, line 32
the amount of state that must be maintained in those routers. A RUL the amount of state that must be maintained in those routers. A RUL
is an example of a destination that is reachable via an external is an example of a destination that is reachable via an external
route which happens to be a Host route. route which happens to be a Host route.
The RPL data packets always carry a Hop-by-Hop Header to transport a The RPL data packets always carry a Hop-by-Hop Header to transport a
RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates
its packets with an RPI, the 6LR needs to tunnel them to the Root to its packets with an RPI, the 6LR needs to tunnel them to the Root to
add the RPI. As a rule of a thumb and except for the very special add the RPI. As a rule of a thumb and except for the very special
case above, the packets from and to a RUL are always encapsulated case above, the packets from and to a RUL are always encapsulated
using an IP-in-IP tunnel between the Root and the 6LR that serves the using an IP-in-IP tunnel between the Root and the 6LR that serves the
RUL. (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4,
8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details) 8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details).
In Non-Storing Mode, packets going down carry a Source Routing Header In Non-Storing Mode, packets going down carry a Source Routing Header
(SRH). The IP-in-IP encapsulation, the RPI and the SRH are (SRH). The IP-in-IP encapsulation, the RPI and the SRH are
collectively called the "RPL artifacts" and can be compressed using collectively called the "RPL artifacts" and can be compressed using
[RFC8138]. Figure 12 presents an example compressed format for a [RFC8138]. Figure 12 presents an example compressed format for a
packet forwarded by the Root to a RUL in a Storing Mode DODAG. packet forwarded by the Root to a RUL in a Storing Mode DODAG.
The inner packet that is forwarded to the RUL may carry some RPL The inner packet that is forwarded to the RUL may carry some RPL
artifacts, e.g., an RPI if the original packet was generated with it artifacts, e.g., an RPI if the original packet was generated with it
and possibly an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] and possibly an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo]
skipping to change at page 19, line 30 skipping to change at page 19, line 30
| |<------------| | | | |<------------| | |
| | | | | | | | | |
| NA(EARO, Status) | | | | | NA(EARO, Status) | | | |
|<-----------------| | | | |<-----------------| | | |
| | | | | | | | | |
Figure 9: Issue in Storing Mode Figure 9: Issue in Storing Mode
9.2. Detailed Operation 9.2. Detailed Operation
9.2.1. By the 6LN 9.2.1. By the RUL Acting as 6LN
This specification does not alter the operation of a 6LoWPAN ND- This specification does not alter the operation of a 6LoWPAN ND-
compliant 6LN, and a RUL is expected to operate as follows: compliant 6LN, and a RUL is expected to operate as follows:
* The 6LN obtains an IPv6 global address, either using Stateless 1. The 6LN obtains an IPv6 global address, either using Stateless
Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix
Information Option (PIO) [RFC4861] found in a Router Advertisement Information Option (PIO) [RFC4861] found in a RA message, or some
message, or some other means such as DHCPv6 [RFC3315]. other means such as DHCPv6 [RFC3315].
* Once it has formed an address, the 6LN (re)registers its address
periodically, within the Lifetime of the previous Address
Registration, as prescribed by [RFC6775] and [RFC8505].
* As stated in section 5.2 of [RFC8505], the 6LN can register to 2. Once it has formed an address, the 6LN (re)registers its address
more than one 6LR at the same time. In that case, it MUST use the periodically, within the Lifetime of the previous Address
same value of TID for all of the parallel Address Registrations. Registration, as prescribed by [RFC6775] and [RFC8505], to
refresh the NCE before the lifetime indicated in the EARO
expires. The TID is incremented each time and wraps in a
lollipop fashion (see section 5.2.1 of [RFC8505] which is fully
compatible with section 7.2 of [RFC6550]).
* Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets the 3. As stated in section 5.2 of [RFC8505], the 6LN can register to
"R" flag in the EARO of at least one registration, whereas acting more than one 6LR at the same time. In that case, it MUST use
as a RAN it never does. If the "R" flag is set in the NS but not the same value of TID for all of the parallel Address
echoed in the NA, the RUL SHOULD attempt to use another 6LR. Registrations.
* Upon each consecutive Address Registration, the 6LN increases the 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
TID field in the EARO, as prescribed by [RFC8505] section 5.2. the "R" flag in the EARO of at least one registration, whereas
acting as a RAN it never does. If the "R" flag is not echoed in
the NA, the RUL SHOULD attempt to use another 6LR.
* The 6LN may use any of the 6LRs to which it register to forward 5. The 6LN may use any of the 6LRs to which it registered as default
its packets. Using a 6LR to which the 6LN is not registered may gateway. Using a 6LR to which the 6LN is not registered may
result in packets dropped at the 6LR by a Source Address result in packets dropped at the 6LR by a Source Address
Validation function (SAVI) so it is NOT RECOMMENDED. Validation function (SAVI) so it is not recommended.
Even without support for RPL, a RUL may be aware of opaque values to Even without support for RPL, a RUL may be aware of opaque values to
be provided to the routing protocol. If the RUL has a knowledge of be provided to the routing protocol. If the RUL has a knowledge of
the RPL Instance the packet should be injected into, then it SHOULD the RPL Instance the packet should be injected into, then it SHOULD
set the Opaque field in the EARO to the RPLInstanceID, else it MUST set the Opaque field in the EARO to the RPLInstanceID, else it MUST
leave the Opaque field to zero. leave the Opaque field to zero.
Regardless of the setting of the Opaque field, the 6LN MUST set the Regardless of the setting of the Opaque field, the 6LN MUST set the
"I" field to zero to signal "topological information to be passed to "I" field to zero to signal "topological information to be passed to
a routing process" as specified in section 5.1 of [RFC8505]. a routing process" as specified in section 5.1 of [RFC8505].
A RUL is not expected to produce RPL artifacts in the data packets, A RUL is not expected to produce RPL artifacts in the data packets,
but it MAY do so. For instance, if the RUL has a minimal awareness but it MAY do so. For instance, if the RUL has a minimal awareness
of the RPL Instance then it can build an RPI. A RUL that places an of the RPL Instance then it can build an RPI. A RUL that places an
RPI in a data packet MUST indicate the RPLInstanceID that corresponds RPI in a data packet MUST indicate the RPLInstanceID that corresponds
to the RPL Instance the packet should be injected into. All the to the RPL Instance the packet should be injected into. All the
flags and the Rank field are set to zero as specified by section 11.2 flags and the Rank field are set to zero as specified by section 11.2
of [RFC6550]. of [RFC6550].
9.2.2. By the 6LR 9.2.2. By the RPL Border Router Acting as 6LR
Also as prescribed by [RFC8505], the 6LR generates an EDAR message Also as prescribed by [RFC8505], the 6LR generates an EDAR message
upon reception of a valid NS(EARO) message for the Address upon reception of a valid NS(EARO) message for the Address
Registration of a new IPv6 Address by a 6LN. If the Duplicate Registration of a new IPv6 Address by a 6LN and for the termination
Address exchange succeeds, then the 6LR installs an NCE. If the "R" of a registration (lifetime of 0).
flag was set in the EARO of the NS message, and this 6LR can manage
the reachability of Registered Address, then the 6LR sets the "R"
flag in the EARO of the NA message that is sends in response.
From then on, the 6LN periodically sends a new NS(EARO) to refresh If the initial EDAR/EDAC exchange succeeds, then the 6LR installs an
the NCE state before the lifetime indicated in the EARO expires, with NCE for the registration lifetime. If the "R" flag was set in the
a TID that is incremented each time till it wraps in a lollipop EARO of the NS message, and this 6LR can manage the reachability of
fashion (see section 5.2.1 of [RFC8505] which is fully compatible Registered Address, then the 6LR sets the "R" flag in the EARO of the
with section 7.2 of [RFC6550]). As long as the "R" flag is set and NA message that is sends in response.
this Router can still manage the reachability of Registered Address,
the 6LR keeps setting the "R" flag in the EARO of the response NA From then on, as long as the "R" flag is set in the periodic NS(EARO)
message, but the exchange of keep-alive Extended Duplicate Address from the 6LN and this Router can still manage the reachability of
messages with the 6LBR is avoided if the RPL Root has indicated that Registered Address, the 6LR keeps setting the "R" flag in the EARO of
it proxies for it. the response NA message. But if the RPL Root has indicated that it
proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
Section 4), the 6LR MUST refrain from sending the keep-alive EDAR
itself.
The Opaque field in the EARO hints the 6LR on the RPL Instance that The Opaque field in the EARO hints the 6LR on the RPL Instance that
should be used for the DAO advertisements, and for the forwarding of should be used for the DAO advertisements, and for the forwarding of
packets sourced at the registered address when there is no RPI in the packets sourced at the registered address when there is no RPI in the
packet, in which case the 6LR MUST encapsulate the packet to the Root packet, in which case the 6LR MUST encapsulate the packet to the Root
adding an RPI in the outer header. If the Opaque field is zero, the adding an RPI in the outer header. If the Opaque field is zero, the
6LR is free to use the default RPL Instance (zero) for the registered 6LR is free to use the default RPL Instance (zero) for the registered
address or to select an Instance of its choice. address or to select an Instance of its choice.
if the "I" field is not zero, then the 6LR MUST consider that the if the "I" field is not zero, then the 6LR MUST consider that the
skipping to change at page 22, line 41 skipping to change at page 22, line 41
If a 6LR receives a valid NS(EARO) message with the "R" flag reset If a 6LR receives a valid NS(EARO) message with the "R" flag reset
and a Registration Lifetime that is not 0, and the 6LR was and a Registration Lifetime that is not 0, and the 6LR was
redistributing the Registered Address due to previous NS(EARO) redistributing the Registered Address due to previous NS(EARO)
messages with the flag set, then it MUST stop injecting the address. messages with the flag set, then it MUST stop injecting the address.
It is up to the Registering 6LN to maintain the corresponding route It is up to the Registering 6LN to maintain the corresponding route
from then on, either keeping it active via a different 6LR or by from then on, either keeping it active via a different 6LR or by
acting as a RAN and managing its own reachability. acting as a RAN and managing its own reachability.
9.2.3. By the RPL Root 9.2.3. By the RPL Root
In RPL Storing Mode of Operation (MOP), the DAO message is propagated A RPL Root SHOULD set the "P" flag in the RPL configuration option of
from child to parent all the way to the Root along the DODAG, the DIO messages that it generates (see Section 4) to signal that it
populating routing state as it goes. In Non-Storing Mode, The DAO proxies the keep-alive EDAR/EDAC echange. The remainder of this
message is sent directly to the RPL Root. Upon reception of a DAO section assumes that it does.
message, for each RPL Target option that creates or updates an
existing RPL state:
* the Root notifies the 6LBR using an internal API if they are co- Upon reception of a DAO message, for each RPL Target option that
located, or using a proxied EDAR/EDAC exchange if they are creates or updates an existing RPL state, the Root notifies the 6LBR.
separated. If the RPL Target option transports a ROVR, then the This can be done using an internal API if they are co-located, or
Root MUST use it to build a full EDAR message; else, an anonymous using a proxied EDAR/EDAC exchange if they are separated.
EDAR is used with the ROVR field set to zero.
If the RPL Target option transports a ROVR, then the Root MUST use it
to build a full EDAR message; else, an anonymous EDAR is used with
the ROVR field set to zero.
The EDAR message MUST be constructed as follows: The EDAR message MUST be constructed as follows:
* The Target IPv6 address from the RPL Target Option is placed in 1. The Target IPv6 address from the RPL Target Option is placed in
the Registered Address field of the EDAR message; the Registered Address field of the EDAR message;
* the Registration Lifetime is adapted from the Path Lifetime in the 2. the Registration Lifetime is adapted from the Path Lifetime in
TIO by converting the Lifetime Units used in RPL into units of 60 the TIO by converting the Lifetime Units used in RPL into units
seconds used in the 6LoWPAN ND messages; of 60 seconds used in the 6LoWPAN ND messages;
* the TID value is set to the Path Sequence in the TIO and indicated 3. the TID value is set to the Path Sequence in the TIO and
with an ICMP code of 1 in the EDAR message; indicated with an ICMP code of 1 in the EDAR message;
* If the ROVR is present in the RPL Target option, it is copied as 4. If the ROVR is present in the RPL Target option, it is copied as
is in the EDAR and the ICMP Code Suffix is set to the appropriate is in the EDAR and the ICMP Code Suffix is set to the appropriate
value as shown in Table 4 of [RFC8505] depending on the size of value as shown in Table 4 of [RFC8505] depending on the size of
the ROVR field; else, the ROVR field in the EDAR is set to zero the ROVR field; else, the ROVR field in the EDAR is set to zero
indicating an anonymous EDAR. indicating an anonymous EDAR.
Upon a Status value in an EDAC message that is not "Success", the Upon a Status value in an EDAC message that is not "Success", the
Root SHOULD destroy the formed paths using either a DAO-ACK (in Non- Root SHOULD destroy the formed paths using either a DAO-ACK (in Non-
Storing Mode) or a DCO downwards as specified in [EFFICIENT-NPDAO]. Storing Mode) or a DCO downwards as specified in [EFFICIENT-NPDAO].
Failure to destroy the former path would result in Stale routing Failure to destroy the former path would result in Stale routing
state and local black holes if the address belongs to another party state and local black holes if the address belongs to another party
elsewhere in the network. The RPL Status value that maps the 6LoWPAN elsewhere in the network. The RPL Status value that maps the 6LoWPAN
ND Status value MUST be embedded in the RPL Status in the DCO. ND Status value MUST be embedded in the RPL Status in the DCO.
9.2.4. By the 6LBR 9.2.4. By the 6LBR
Upon reception of an EDAR message with the ROVR field is set to zero Upon reception of an EDAR message with the ROVR field is set to 0
indicating an anonymous EDAR, the 6LBR checks whether an entry exists indicating an anonymous EDAR, the 6LBR checks whether an entry exists
for the and computes whether the TID in the DAR message is fresher for the address. If the entry does not exist, the 6LBR does not
than that in the entry as prescribed in section 4.2.1. of [RFC8505]. create the entry, and answers with a Status "Removed" in the EDAC
message.
If the entry does not exist, the 6LBR does not create the entry, and If the entry exists, the 6LBR computes whether the TID in the EDAR
answers with a Status "Removed" in the EDAC message. If the entry message is fresher than the one in the entry as prescribed in section
exists but is not fresher, the 6LBR does not update the entry, and 4.2.1. of [RFC8505] and MUST operate as below:
answers with a Status "Success" in the EDAC message.
If the entry exists and the TID in the DAR message is fresher, the 1. If the anonymous EDAR message is fresher, the 6LBR updates the
6LBR updates the TID in the entry, and if the lifetime of the entry TID in the entry, restarts the heartbeat timer for the entry, and
is extended by the Registration Lifetime in the DAR message, it also answers with a Status "Success" in the EDAC message. If the
updates the lifetime of the entry. In that case, the 6LBR replies duration of the lifetime of the entry is extended by the
with a Status "Success" in the DAC message. Registration Lifetime in the EDAR message, it also updates the
lifetime of the entry.
2. If the TIDs are the same, the 6LBR does not update the entry, and
answers with a Status "Success" in the EDAC message.
3. If the TID in the entry is fresher, the 6LBR does not update the
entry, and answers with a Status "Moved" in the EDAC message.
The EDAC that is constructed is the same as if the anonymous EDAR was The EDAC that is constructed is the same as if the anonymous EDAR was
a full EDAR, and includes the ROVR that is associated to the Address a full EDAR, and includes the ROVR that is associated to the Address
Registration. Registration.
10. Protocol Operations for Multicast Addresses 10. Protocol Operations for Multicast Addresses
Section 12 of [RFC6550] details the RPL support for multicast flows. Section 12 of [RFC6550] details the RPL support for multicast flows.
This support is not source-specific and only operates as an extension This support is not source-specific and only operates as an extension
to the Storing Mode of Operation for unicast packets. Note that it to the Storing Mode of Operation for unicast packets. Note that it
skipping to change at page 24, line 25 skipping to change at page 24, line 35
updated version "Multicast Listener Discovery Version 2 (MLDv2) for updated version "Multicast Listener Discovery Version 2 (MLDv2) for
IPv6" [RFC3810] provide an interface for a listener to register to IPv6" [RFC3810] provide an interface for a listener to register to
multicast flows. MLDv2 is backwards compatible with MLD, and adds in multicast flows. MLDv2 is backwards compatible with MLD, and adds in
particular the capability to filter the sources via black lists and particular the capability to filter the sources via black lists and
white lists. In the MLD model, the Router is a "querier" and the white lists. In the MLD model, the Router is a "querier" and the
Host is a multicast listener that registers to the querier to obtain Host is a multicast listener that registers to the querier to obtain
copies of the particular flows it is interested in. copies of the particular flows it is interested in.
On the first Address Registration, as illustrated in Figure 10, the On the first Address Registration, as illustrated in Figure 10, the
6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in
order to start receiving the flow immediately. Since multicast order to start receiving the flow immediately.
Layer-2 messages are avoided, it is important that the asynchronous
messages for unsolicited Report and Done are sent reliably, for
instance using an Layer-2 acknoledgement, or attempted multiple
times.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| unsolicited Report | | | | unsolicited Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | | | | <L2 ack> | | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | <if not listening> | | | | <if not listening> |
| | | unsolicited Report | | | | unsolicited Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
| | | | | | | |
Figure 10: First Multicast Registration Flow Figure 10: First Multicast Registration Flow
Since multicast Layer-2 messages are avoided, it is important that
the asynchronous messages for unsolicited Report and Done are sent
reliably, for instance using a 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 exchange as a listener with the 6LBR acting The Root proxies the MLD exchange as a listener with the 6LBR acting
as the querier, so as to get packets from a source external to the as 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 RPL 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 if it is already registered as a listener for that address, and if
not, it performs its own unsolicited Report for the multicast target. not, it performs its own unsolicited Report for the multicast target.
skipping to change at page 26, line 12 skipping to change at page 26, line 25
joining and the Link-Layer security. This is a generic 6LoWPAN joining and the Link-Layer security. This is a generic 6LoWPAN
requirement, see Req5.1 in Appendix of [RFC8505]. requirement, see Req5.1 in Appendix of [RFC8505].
Additionally, the trust model could include a role validation to Additionally, the trust model could include a role validation to
ensure that the node that claims to be a 6LBR or a RPL Root is ensure that the node that claims to be a 6LBR or a RPL Root is
entitled to do so. entitled to do so.
The anonymous EDAR message does not carry a valid Registration Unique The anonymous EDAR message does not carry a valid Registration Unique
ID [RFC8505] in the form of a ROVR and may be played by any node on ID [RFC8505] in the form of a ROVR and may be played by any node on
the network without the need to know the ROVR. The 6LBR MUST NOT the network without the need to know the ROVR. The 6LBR MUST NOT
create an entry based on a anonymous EDAR that does not match an create an entry based on a anonymous EDAR and it MUST NOT decrease
existing entry. All it can do is refresh the lifetime and the TID of the value of the lifetime. All it can do is refresh the lifetime and
an existing entry. So the message cannot be used to create a binding the TID of an existing entry. So the message cannot be used to
state in the 6LBR but it can be use to maintain one active longer create a binding state in the 6LBR but it can be used to maintain one
than expected. active longer than expected.
Note that a full EDAR message with a lifetime of 0 will destroy that Note that a full EDAR message with a lifetime of 0 will destroy that
state and the anonymous message will not recreate it. Note also that state and the anonymous message will not recreate it. Note also that
a rogue that has access to the network can attack the 6LBR with other a rogue that has access to the network can attack the 6LBR with other
(forged) addresses and ROVR, and that this is a much easier DoS (forged) addresses and ROVR, and that this is a much easier DoS
attack than trying to keep existing state alive longer. attack than trying to keep existing state alive longer.
At the time of this writing RPL does not have a zerotrust model At the time of this writing RPL does not have a zerotrust model
whereby the it is possible to validate the origin of an address that whereby the it is possible to validate the origin of an address that
is injected in a DAO. This specification makes a first step in that is injected in a DAO. This specification makes a first step in that
 End of changes. 29 change blocks. 
94 lines changed or deleted 105 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/