draft-ietf-6lo-multicast-registration-00.txt   draft-ietf-6lo-multicast-registration-01.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505, 9010 (if approved) 21 October 2021 Updates: 6550, 8505, 9010 (if approved) 22 October 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 24 April 2022 Expires: 25 April 2022
IPv6 Neighbor Discovery Multicast Address Registration IPv6 Neighbor Discovery Multicast Address Listener Registration
draft-ietf-6lo-multicast-registration-00 draft-ietf-6lo-multicast-registration-01
Abstract Abstract
This document updates RFC 8505 to enable the address registration of This document updates RFC 8505 to enable a listener to subscribe to
IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550 an IPv6 anycast or multicast address; the draft updates RFC 6550
(RPL) add a new Non-Storing multicast mode and support for anycast (RPL) to add a new Non-Storing multicast mode and support for anycast
addresses. This document also extends RFC 9010 to enable the 6LR to addresses. This document also extends RFC 9010 to enable the 6LR to
inject the anycast and multicast addresses in RPL. inject the anycast and multicast addresses in 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 24 April 2022. This Internet-Draft will expire on 25 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 8 4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 8
5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 8 5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 8 5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 9
5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 9 5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 9
5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 9 5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 10
5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 10 5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 11
6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 11 6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 11
6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 11 6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Registering Extensions . . . . . . . . . . . . . . . . . 12 6.2. Registering Extensions . . . . . . . . . . . . . . . . . 12
7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 12 7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 13
8. Deployment considerations . . . . . . . . . . . . . . . . . . 13 8. Deployment considerations . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1. New RTO flags . . . . . . . . . . . . . . . . . . . . . 16 11.1. New RTO flags . . . . . . . . . . . . . . . . . . . . . 17
11.2. New RPL Mode of Operation . . . . . . . . . . . . . . . 16 11.2. New RPL Mode of Operation . . . . . . . . . . . . . . . 17
11.3. New EARO flags . . . . . . . . . . . . . . . . . . . . . 16 11.3. New EARO flags . . . . . . . . . . . . . . . . . . . . . 17
11.4. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 17 11.4. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
13. Normative References . . . . . . . . . . . . . . . . . . . . 17 13. Normative References . . . . . . . . . . . . . . . . . . . . 18
14. Informative References . . . . . . . . . . . . . . . . . . . 19 14. Informative References . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. The radio (both transmitting or derive from that primary concern. The radio (both transmitting or
simply listening) is a major energy drain and the LLN protocols must simply listening) is a major energy drain and the LLN protocols must
be adapted to allow the nodes to remain sleeping with the radio be adapted to allow the nodes to remain sleeping with the radio
skipping to change at page 5, line 24 skipping to change at page 5, line 24
AMC Address Mapping Confirmation AMC Address Mapping Confirmation
AMR Address Mapping Request AMR Address Mapping Request
ARO Address Registration Option ARO Address Registration Option
DAC Duplicate Address Confirmation DAC Duplicate Address Confirmation
DAD Duplicate Address Detection DAD Duplicate Address Detection
DAR Duplicate Address Request DAR Duplicate Address Request
EARO Extended Address Registration Option EARO Extended Address Registration Option
EDAC Extended Duplicate Address Confirmation EDAC Extended Duplicate Address Confirmation
EDAR Extended Duplicate Address Request EDAR Extended Duplicate Address Request
DODAG Destination-Oriented Directed Acyclic Graph DODAG Destination-Oriented Directed Acyclic Graph
IR Ingress Replication
LLN Low-Power and Lossy 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
NS Neighbor Solicitation NS Neighbor Solicitation
ROVR Registration Ownership Verifier ROVR Registration Ownership Verifier
RTO RPL Target Option
RA Router Advertisement RA Router Advertisement
RS Router Solicitation RS Router Solicitation
TID Transaction ID TID Transaction ID
TIO Transit Information Option
3. Overview 3. Overview
[RFC8505] is a pre-requisite to this specification. A node that [RFC8505] is a pre-requisite to this specification. A node that
implements this MUST also implement [RFC8505]. This specification implements this MUST also implement [RFC8505]. This specification
does not introduce a new option; it modifies existing options and does not introduce a new option; it modifies existing options and
updates the associated behaviors to enable the Registration for updates the associated behaviors to enable the Registration for
Multicast Addresses with [RFC8505]. Multicast Addresses as an extension to [RFC8505].
This specification also extends [RFC6550] and [RFC9010] in the case This specification also extends [RFC6550] and [RFC9010] in the case
of a route-over multilink subnet based on the RPL routing protocol. of a route-over multilink subnet based on the RPL routing protocol,
A 6LR that implements the RPL extensions specified therein MUST also to add multicast ingress replication in Non-Storing Mode and anycast
implement [RFC9010]. support in both Storing and Non-Storing modes. A 6LR that implements
the RPL extensions specified therein MUST also implement [RFC9010].
Figure 1 illustrates the classical situation of an LLN as a single Figure 1 illustrates the classical situation of an LLN as a single
IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root
for RPL operations and maintains a registry of the active for RPL operations and maintains a registry of the active
registrations as an abstract data structure called an Address registrations as an abstract data structure called an Address
Registrar for 6LoWPAN ND. Registrar for 6LoWPAN ND.
The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi
[IEEE Std 802.11] and Bluetooth (Low Energy) [IEEE Std 802.15.1], or [IEEE Std 802.11] and Bluetooth (Low Energy) [IEEE Std 802.15.1], or
a Route-Over LLN such as the Wi-SUN mesh [Wi-SUN] that leverages a Route-Over LLN such as the Wi-SUN mesh [Wi-SUN] that leverages
skipping to change at page 6, line 37 skipping to change at page 6, line 43
+---+ +---+
Figure 1: Wireless Mesh Figure 1: Wireless Mesh
A leaf acting as a 6LN registers its unicast addresses to a RPL A leaf acting as a 6LN registers its unicast addresses to a RPL
router acting as a 6LR, using a unicast NS message with an EARO as router acting as a 6LR, using a unicast NS message with an EARO as
specified in [RFC8505]. The registration state is periodically specified in [RFC8505]. The registration state is periodically
renewed by the Registering Node, before the lifetime indicated in the renewed by the Registering Node, before the lifetime indicated in the
EARO expires. EARO expires.
With this specification, the 6LNs can now register for the multicast With this specification, the 6LNs can now subscribe to the multicast
addresses they listen to, using a new M flag in the EARO to signal a addresses they listen to, using a new M flag in the EARO to signal
registration for a multicast address. Multiple 6LN can register for that the registration is for a multicast address. Multiple 6LN may
the same multicast address to the same 6LR. Note the use of the term subscribe to the same multicast address to the same 6LR. Note the
"for", a node registers the unicast addresses that it owns, but use of the term "subscribe": using the EARO registration mechanism, a
registers for multicast addresses that it listens to. node registers the unicast addresses that it owns, but subscribes to
the multicast addresses that it listens to.
With this specification, the 6LNs can also resgister the anycast
addresses they accept, using a new A flag in the EARO to signal that
the registration is for an anycast address. As for multicast,
multiple 6LN may register the same anycast address to the same 6LR.
If the R flag is set in the registration of one or more 6LNs for the If the R flag is set in the registration of one or more 6LNs for the
same multicast address, the 6LR injects the multicast address in the same address, the 6LR injects the anycast and multicast addresses in
RPL multicast support, based on the longest registration lifetime RPL, based on the longest registration lifetime across the active
across those 6LNs. registrations for the address.
In the RPL "Storing Mode of Operation with multicast support", the In the RPL "Storing Mode of Operation with multicast support", the
DAO messages for the multicast address percolate along the RPL DAO messages for the multicast address percolate along the RPL
preferred parent tree and mark a subtree that becomes the multicast preferred parent tree and mark a subtree that becomes the multicast
tree for that multicast address, with 6LNs that registered for it as tree for that multicast address, with 6LNs that subscribed to the
the leaves. address as the leaves. As prescribed in section 12 of [RFC6550], the
6LR forwards a multicast packet as an individual unicast MAC frame to
As prescribed in section 12 of [RFC6550], the 6LR forward the each peer along the multicast tree, excepting to the node it received
multicast packets as individual unicast MAC frames to each child that the packet from.
advertised the multicast address in its DAO message. In most LLNs a
broadcast is unreliable (no ack) and forces a listener to remain
awake, so it is expected that the 6LR also delivers the multicast
packet as individual unicast MAC frames to each of the 6LNs that
registered for the multicast address.
In the new RPL "Non-Storing Mode of Operation with multicast support" In the new RPL "Non-Storing Mode of Operation with multicast support"
that is introduced here, the DAO messages register multicast that is introduced here, the DAO messages announce the multicast
addresses as Targets, though never as Transit. The multicast addresses as Targets though never as Transit. The multicast
distribution is hub-and-spoke from the Root to all the 6LRs that are distribution is an ingress replication whereby the Root encapsulates
transit for the multicast address, using the same source-routing the multicast packets to all the 6LRs that are transit for the
header as for unicast targets attached to the 6LR, but for the multicast address, using the same source-routing header as for
ultimate entry that is the multicast address. unicast targets attached to the respective 6LRs.
With this specification, the 6LNs can also register for the anycast Broadcasting is typically unreliable in LLNs (no ack) and forces a
addresses they listen to, using a new A flag in the EARO to signal a listener to remain awake, so it generally discouraged. The
registration for an anycast address. Multiple 6LN can register for expectation is thus that in either mode, the 6LRs deliver the
the same anycast address to the same 6LR, but the RPL routing ensures multicast packets as individual unicast MAC frames to each of the
that only one of the 6LN gets the particular packet. 6LNs that subscribed to the multicast address.
With this specification, anycast addresses can be injected in RPL in
both Storing and Non-Storing modes. In Storing Mode the RPL router
accepts DAO from multiple children for the same anycast address, but
only forwards a packet to one of the children. In Non-Storing Mode,
the Root maintains the list of all the RPL nodes that announced the
anycast address as Target, but forwards a given packet to only one of
them.
For backward compatibility, this specification allows to build a
single DODAG signaled as MOP 1, that conveys anycast, unicast and
multicast packets using the same source routing mechanism, more in
Section 8.
It is also possible to leverage this specification between the 6LN It is also possible to leverage this specification between the 6LN
and the 6LR for the registration of an anycast or a multicast and the 6LR for the registration of unicast, anycast and multicast
addresses in networks that are not necessarily LLNs, and/or where the IPv6 addresses in networks that are not necessarily LLNs, and/or
routing protocol between the 6LR and above is not necessarily RPL. where the routing protocol between the 6LR and above is not
necessarily RPL. In that case, the distribution of packets between
the 6LR and the 6LNs may effectively rely on a broadcast or multicast
support at the lower layer.
For instance, it is possible to operate a RPL Instance in the new For instance, it is possible to operate a RPL Instance in the new
"Non-Storing Mode of Operation with multicast support" and use "Non-Storing Mode of Operation with multicast support" (while
"Multicast Protocol for Low-Power and Lossy Networks (MPL)" [RFC7731] possibly signaling a MOP of 1) and use "Multicast Protocol for
for the multicast operation. MPL floods the DODAG with the multicast Low-Power and Lossy Networks (MPL)" [RFC7731] for the multicast
messages independently of the RPL DODAG topologies. Two variations operation. MPL floods the DODAG with the multicast messages
are possible: independently of the RPL DODAG topologies. Two variations are
possible:
* In one possible variation, all the 6LNs set the R flag in the EARO * In one possible variation, all the 6LNs set the R flag in the EARO
for a multicast target, upon which the 6LR sends a unicast DAO for a multicast target, upon which the 6LRs send a unicast DAO
message to the Root; in that case, the Root can filter the message to the Root; the Root filters out the multicast messages
multicast messages for which there is no listener and only flood for which there is no listener and only floods when there is.
the relevant multicasts.
* In a simpler variation, the 6LNs do not set the R flag and the * In a simpler variation, the 6LNs do not set the R flag and the
Root floods all the multicast packets over the whole DODAG. Root floods all the multicast packets over the whole DODAG. Using
configuration, it is also possible to control the behavior of the
6LR to ignore the R flag and either always or never send the DAO
message, and/or to control the Root and specify which groups it
should flood or not flood.
Note that if the configuration instructs the 6LR not to send the DAO,
then MPL can really by used in conjunction with RPL Storing Mode as
well.
4. Extending RFC 7400 4. Extending RFC 7400
This specification defines a new capability bit for use in the 6CIO This specification defines a new capability bit for use in the 6CIO
as defined by "6LoWPAN-GHC: Generic Header Compression for IPv6 over as defined by "6LoWPAN-GHC: Generic Header Compression for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] and Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] and
extended in [RFC8505] for use in IPv6 ND messages. extended in [RFC8505] for use in IPv6 ND messages.
The new "Registration for Multicast Address Supported" (M) flag The new "Registration for Multicast Address Supported" (M) flag
indicates to the 6LN that the 6LR accepts multicast address indicates to the 6LN that the 6LR accepts multicast address
skipping to change at page 9, line 13 skipping to change at page 9, line 44
is the norm. Though it is preferred to build separate RPL Instances, is the norm. Though it is preferred to build separate RPL Instances,
one in MOP 1 and one in MOP 3, this specification allows to hybrid one in MOP 1 and one in MOP 3, this specification allows to hybrid
the Storing Mode for multicast and Non-Storing Mode for unicast in the Storing Mode for multicast and Non-Storing Mode for unicast in
the same RPL Instance, more in Section 8. the same RPL Instance, more in Section 8.
5.2. New Non-Storing Multicast MOP 5.2. New Non-Storing Multicast MOP
This specification adds a "Non-Storing Mode of Operation with This specification adds a "Non-Storing Mode of Operation with
multicast support" (MOP to be assigned by IANA) whereby the non- multicast support" (MOP to be assigned by IANA) whereby the non-
storing Mode DAO to the Root may contain multicast addresses in the storing Mode DAO to the Root may contain multicast addresses in the
RTO, whereas the Transit Information Option (TIO) can not. In that RPL Target Option (RTO), whereas the Transit Information Option (TIO)
case, the RPL Root copies the multicast packet to each 6LR that is a can not.
transit for the multicast target, using the same source routing
header as for unicast address of a RPL Unaware Leaf (RUL) attached to In that mode, the RPL Root performs an ingress replication (IR)
that 6LR. operation on the multicast packets, meaning that it transmits one
copy of each multicast packet to each 6LR that is a transit for the
multicast target, using the same source routing header and
encapsulation as it would for a unicast packet for a RPL Unaware Leaf
(RUL) attached to that 6LR..
For the intermediate routers, the packet appears as any source routed
unicast packet. The difference shows only at the 6LR, that
terminates the source routed path and forwards the multicast packet
to all 6LNs that registered for the muticast address.
For a packet that is generated by the Root, this means that the Root For a packet that is generated by the Root, this means that the Root
builds a source routing header as discussed in section 8.1.3 of builds a source routing header as shown in section 8.1.3 of
[RFC9008], but for which the last and only the last address is [RFC9008], but for which the last and only the last address is
multicast. For a packet that is not generated by the Root,the Root multicast. For a packet that is not generated by the Root,the Root
encapsulates the multicast packet as discussed in section 8.2.4 of encapsulates the multicast packet as per section 8.2.4 of [RFC9008].
[RFC9008]. In that case, the outer header is purely unicast, and the
encapsulated packet is purely multicast.
For this new mode as well, this specification allows to enable the For this new mode as well, this specification allows to enable the
operation in a MOP 1 brown field, more in Section 8. operation in a MOP 1 brown field, more in Section 8.
5.3. RPL Anycast Operation 5.3. RPL Anycast Operation
With multicast, the address has a recognizable format, and a With multicast, the address has a recognizable format, and a
multicast packet is to be delivered to all the registered listeners. multicast packet is to be delivered to all the active subscribers.
In contrast with anycast, the format of the address may not be In contrast with anycast, the format of the address is not
distinguishable from unicast. In fact, an external destination distinguishable from that of unicast. In fact, an external
(address or prefix) that may be injected from multiple border routers destination (address or prefix) that may be injected from multiple
MUST be injected as anycast in RPL. border routers MUST be injected as anycast in RPL.
For both multicast and anycast, there is no concept of duplication, For either multicast and anycast, there can be multiple registrations
and there might be multiple registrations from multiple parties, each from multiple parties, each using a different value of the ROVR field
using a different value of the ROVR field that identifies that that identifies the individual registration. The 6LR MUST maintain a
registration. The 6LR MUST conserve one registration per value of registration state per value of the ROVR per multicast or anycast
the ROVR per multicast or anycast address, but inject the route into address, but inject the route into RPL only once for each address.
RPL only once for each address. Since the registrations are Since the registrations are considered separate, the check on the TID
considered separate, the check on the TID that acts as registration that acts as registration sequence only applies to the registration
sequence only applies to the registration with the same ROVR. with the same ROVR.
The 6LRs that inject multicast and anycast routes into RPL may not be The 6LRs that inject multicast and anycast routes into RPL may not be
synchronized to advertise same value of the Path Sequence in the RPL synchronized to advertise same value of the Path Sequence in the RPL
TIO. It results that the value the Path Sequence is irrelevant when TIO. It results that the value the Path Sequence is irrelevant when
the target is anycast or multicast, and that it MUST be ignored. the target is anycast or multicast, and that it MUST be ignored.
Like the 6LR, a RPL router in Storing Mode propagates the route to Like the 6LR, a RPL router in Storing Mode propagates the route to
its parent(s) in DAO messages once and only once for each address, its parent(s) in DAO messages once and only once for each address,
but it MUST retain a routing table entry for each of the children but it MUST retain a routing table entry for each of the children
that advertised the address. Note that typically the router that advertised the address.
advertises the multicast and anycast addresses only to its preferred
parents, in which case the resulting routes form a tree down the
DODAG.
When forwarding multicast packets down the DODAG, the RPL router MUST When forwarding multicast packets down the DODAG, the RPL router
copy all the children that advertised the address in their DAO copies all the children that advertised the address in their DAO
messages. In contrast, when forwarding anycast packets down the messages. In contrast, when forwarding anycast packets down the
DODAG, the RPL router MUST copy one and only one of the children that DODAG, the RPL router MUST copy one and only one of the children that
advertised the address in their DAO messages. Typically this is done advertised the address in their DAO messages, and forward to one
through MAC-Layer unicast which makes the operation more reliable. parent if there is no such child.
5.4. New RPL Target Option Flags 5.4. New RPL Target Option Flags
[RFC6550] recognizes a multicast address by its format (as specified [RFC6550] recognizes a multicast address by its format (as specified
in section 2.7 of [RFC4291]) and applies the specified multicast in section 2.7 of [RFC4291]) and applies the specified multicast
operation if the address is recognized as multicast. This operation if the address is recognized as multicast. This
specification updates [RFC6550] to add the M and A flags to the RTO specification updates [RFC6550] to add the M and A flags to the RTO
to indicate that the target address is to be processed as multicast to indicate that the target address is to be processed as multicast
or anycast, respectively. or anycast, respectively.
skipping to change at page 12, line 42 skipping to change at page 13, line 34
Protocol Independent Multicast [RFC7761] protocol. Protocol Independent Multicast [RFC7761] protocol.
* The 6LN MUST also register all the IPv6 anycast addresses that it * The 6LN MUST also register all the IPv6 anycast addresses that it
supports and it MUST set the A flag in the EARO for those supports and it MUST set the A flag in the EARO for those
addresses. addresses.
* The Registration Ownership Verifier (ROVR) in the EARO identifies * The Registration Ownership Verifier (ROVR) in the EARO identifies
uniquely a registration within the namespace of the Registered uniquely a registration within the namespace of the Registered
Address. The 6LR MUST maintain a registration state per tuple Address. The 6LR MUST maintain a registration state per tuple
(IPv6 address, ROVR) for both anycast and multicast types of (IPv6 address, ROVR) for both anycast and multicast types of
address, since multiple 6LNs may register for the same address of address, since multiple 6LNs may subscribe to the same address of
these types. these types.
7. Updating RFC 9010 7. Updating RFC 9010
With [RFC9010]: With [RFC9010]:
* The 6LR injects only unicast routes in RPL * The 6LR injects only unicast routes in RPL
* upon a registration with the R flag set to 1 in the EARO, the 6LR * upon a registration with the R flag set to 1 in the EARO, the 6LR
injects the address in the RPL unicast support. injects the address in the RPL unicast support.
 End of changes. 32 change blocks. 
102 lines changed or deleted 139 lines changed or added

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