< draft-ietf-6lo-multicast-registration-01.txt   draft-ietf-6lo-multicast-registration-02.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505, 9010 (if approved) 22 October 2021 Updates: 6550, 6553, 8505, 9010 (if approved) 8 November 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 25 April 2022 Expires: 12 May 2022
IPv6 Neighbor Discovery Multicast Address Listener Registration IPv6 Neighbor Discovery Multicast Address Listener Registration
draft-ietf-6lo-multicast-registration-01 draft-ietf-6lo-multicast-registration-02
Abstract Abstract
This document updates RFC 8505 to enable a listener to subscribe to This document updates RFC 8505 to enable a listener to register an
an IPv6 anycast or multicast address; the draft updates RFC 6550 IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
(RPL) to add a new Non-Storing multicast mode and support for anycast updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
addresses. This document also extends RFC 9010 to enable the 6LR to new support for anycast addresses in Storing and Non-Storing Modes.
inject the anycast and multicast addresses in RPL. This document extends RFC 9010 to enable the 6LR to 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 25 April 2022. This Internet-Draft will expire on 12 May 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 8 4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 9
5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9 5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 9 5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 10
5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 9 5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 10
5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 10 5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 11
5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 11 5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 12
6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 11 6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 12
6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 11 6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Registering Extensions . . . . . . . . . . . . . . . . . 12 6.2. New EDAR Message Flag field . . . . . . . . . . . . . . . 14
7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Registering Extensions . . . . . . . . . . . . . . . . . 15
8. Deployment considerations . . . . . . . . . . . . . . . . . . 14 7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Deployment considerations . . . . . . . . . . . . . . . . . . 17
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19
11.1. New RTO flags . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.2. New RPL Mode of Operation . . . . . . . . . . . . . . . 17 11.1. New EDAR Message Flags Subregistry . . . . . . . . . . . 20
11.3. New EARO flags . . . . . . . . . . . . . . . . . . . . . 17 11.2. New EARO flags . . . . . . . . . . . . . . . . . . . . . 20
11.4. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 18 11.3. New RTO flags . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11.4. New RPL Mode of Operation . . . . . . . . . . . . . . . 21
13. Normative References . . . . . . . . . . . . . . . . . . . . 18 11.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 21
14. Informative References . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Normative References . . . . . . . . . . . . . . . . . . . . 21
14. Informative References . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
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 4, line 25 skipping to change at page 4, line 36
multicast address, but as the classical IPv6 ND protocol, MLD relies multicast address, but as the classical IPv6 ND protocol, MLD relies
on multicasting Queries to all nodes, which is unfit for low power on multicasting Queries to all nodes, which is unfit for low power
operations. As for IPv6 ND, it makes sense to let the 6LNs control operations. As for IPv6 ND, it makes sense to let the 6LNs control
when and how they maintain the state associated to their multicast when and how they maintain the state associated to their multicast
addresses in the 6LR, e.g., during their own wake time. In the case addresses in the 6LR, e.g., during their own wake time. In the case
of a constrained node that already implements [RFC8505] for unicast of a constrained node that already implements [RFC8505] for unicast
reachability, it makes sense to extend to that support to register reachability, it makes sense to extend to that support to register
the multicast addresses they listen to. the multicast addresses they listen to.
This specification extends [RFC8505] and [RFC9010] to add the This specification extends [RFC8505] and [RFC9010] to add the
capability for the 6LN to register multicast addresses and for the capability for the 6LN to register anycast and multicast addresses
6LR to inject them in the RPL multicast support. and for the 6LR to inject them in RPL.
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 5, line 39 skipping to change at page 6, line 7
NS Neighbor Solicitation NS Neighbor Solicitation
ROVR Registration Ownership Verifier ROVR Registration Ownership Verifier
RTO RPL Target Option 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 TIO Transit Information Option
3. Overview 3. Overview
This specification inherits from [RFC6550], [RFC8505], and [RFC8505]
to provide additional capabilities for anycast and multicast. Unless
specified otherwise therein, the behavior of the 6LBR that acts as
RPL Root, of the intermediate routers down the RPL graph, of the 6LR
that act as access routers and of the 6LNs that are the RFC-unaware
destinations, is the same as for unicast. In particular, forwarding
a packet happens as specified in section 11 of [RFC6550], including
loop avoidance and detection, though in the case of multicast
multiple copies might be generated.
[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 as an extension to [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,
to add multicast ingress replication in Non-Storing Mode and anycast to add multicast ingress replication in Non-Storing Mode and anycast
support in both Storing and Non-Storing modes. A 6LR that implements support in both Storing and Non-Storing modes. A 6LR that implements
skipping to change at page 6, line 37 skipping to change at page 7, line 25
o o o LLN o +---+ o o o LLN o +---+
o o o o o |6LR| o o o o o |6LR|
o o o o o +---+ o o o o o +---+
o o o o o o z o o o o o o z
o o oo o o +---+ o o oo o o +---+
o |6LN| o |6LN|
+---+ +---+
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 and anycast addresses a
router acting as a 6LR, using a unicast NS message with an EARO as RPL router acting as a 6LR, using a layer-2 unicast NS message with
specified in [RFC8505]. The registration state is periodically an EARO as specified in [RFC8505]. The registration state is
renewed by the Registering Node, before the lifetime indicated in the periodically renewed by the Registering Node, before the lifetime
EARO expires. indicated in the EARO expires. As for unicast IPv6 addresses, the
6LR uses an EDAR/EDAR exchange with the 6LBR to notify the 6LBR of
the presence of the listeners.
With this specification, the 6LNs can now subscribe to 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 addresses they listen to, using a new M flag in the EARO to signal
that the registration is for a multicast address. Multiple 6LN may that the registration is for a multicast address. Multiple 6LN may
subscribe to the same multicast address to the same 6LR. Note the subscribe to the same multicast address to the same 6LR. Note the
use of the term "subscribe": using the EARO registration mechanism, a use of the term "subscribe": using the EARO registration mechanism, a
node registers the unicast addresses that it owns, but subscribes to node registers the unicast addresses that it owns, but subscribes to
the multicast addresses that it listens to. the multicast addresses that it listens to.
With this specification, the 6LNs can also resgister the anycast With this specification, the 6LNs can also register the anycast
addresses they accept, using a new A flag in the EARO to signal that addresses they accept, using a new A flag in the EARO to signal that
the registration is for an anycast address. As for multicast, the registration is for an anycast address. As for multicast,
multiple 6LN may register the same anycast address to the same 6LR. 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 address, the 6LR injects the anycast and multicast addresses in same address, the 6LR injects the anycast and multicast addresses in
RPL, based on the longest registration lifetime across the active RPL, based on the longest registration lifetime across the active
registrations for the address. 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
skipping to change at page 9, line 45 skipping to change at page 10, line 35
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
RPL Target Option (RTO), whereas the Transit Information Option (TIO) RPL Target Option (RTO), whereas the Transit Information Option (TIO)
can not. cannot.
In that mode, the RPL Root performs an ingress replication (IR) In that mode, the RPL Root performs an ingress replication (IR)
operation on the multicast packets, meaning that it transmits one operation on the multicast packets, meaning that it transmits one
copy of each multicast packet to each 6LR that is a transit for the copy of each multicast packet to each 6LR that is a transit for the
multicast target, using the same source routing header and multicast target, using the same source routing header and
encapsulation as it would for a unicast packet for a RPL Unaware Leaf encapsulation as it would for a unicast packet for a RPL Unaware Leaf
(RUL) attached to that 6LR.. (RUL) attached to that 6LR.
For the intermediate routers, the packet appears as any source routed For the intermediate routers, the packet appears as any source routed
unicast packet. The difference shows only at the 6LR, that unicast packet. The difference shows only at the 6LR, that
terminates the source routed path and forwards the multicast packet terminates the source routed path and forwards the multicast packet
to all 6LNs that registered for the muticast address. to all 6LNs that registered for the multicast 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 shown 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 per section 8.2.4 of [RFC9008]. encapsulates the multicast packet as per section 8.2.4 of [RFC9008].
In that case, the outer header is purely unicast, and the In that case, the outer header is purely unicast, and the
encapsulated packet is purely multicast. 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 active subscribers. multicast packet is to be delivered to all the active subscribers.
In contrast with anycast, the format of the address is not In contrast with anycast, the format of the address is not
distinguishable from that of unicast. In fact, an external distinguishable from that of unicast. A legacy node may issue a DAO
destination (address or prefix) that may be injected from multiple message without setting the A flag, the unicast behaviour may apply
border routers MUST be injected as anycast in RPL. to anycast traffic in a subDAGs. A target is routed as anycast by a
parent (or the Root) that received at least one DAO message for that
target with the A flag set to 1. As for multicast, the freshness
comparison cannot apply to an anycast target, and the TID field is
ignored.
As opposed to multicast, the anycast operation described therein
applies to both addresses and prefixes, and the A flag can be set for
both. An external destination (address or prefix) that may be
injected as a RPL target from multiple border routers SHOULD be
injected as anycast in RPL to enable load balancing. A mobile target
that is multihomed SHOULD in contrast be advertised as unicast over
the multiple interfaces to favor the TID comparision and vs. the
multipath load balancing.
For either multicast and anycast, there can be multiple registrations For either multicast and anycast, there can be multiple registrations
from multiple parties, each using a different value of the ROVR field from multiple parties, each using a different value of the ROVR field
that identifies the individual registration. The 6LR MUST maintain a that identifies the individual registration. The 6LR MUST maintain a
registration state per value of the ROVR per multicast or anycast registration state per value of the ROVR per multicast or anycast
address, but inject the route into RPL only once for each address. address, but inject the route into RPL only once for each address.
Since the registrations are considered separate, the check on the TID Since the registrations are considered separate, the check on the TID
that acts as registration sequence only applies to the registration that acts as registration sequence only applies to the registration
with the same ROVR. with the same ROVR.
skipping to change at page 11, line 21 skipping to change at page 12, line 21
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.
An RTO that has the M flag set is called a multicast RTO. An RTO An RTO that has the M flag set to 1 is called a multicast RTO. An
that has the A flag set is called an anycast RTO. An RTO that has RTO that has the A flag set to 1 is called an anycast RTO. An RTO
neither M nor A flag set is called a unicast RTO. The M and A flags that has both the A and the M flags set to 0 is called an unicast
are mutually exclusive and MUST NOT be both set. RTO. With this specification, the M and A flags are mutually
exclusive and MUST NOT be both set to 1. The capability to set both
flags is reserved and an RTO that is received with both flags set
MUST be ignored.
The suggested position for the A and M flags are 2 and 3 counting The suggested position for the A and M flags are 2 and 3 counting
from 0 to 7 in network order as shown in Figure 3, based on figure 4 from 0 to 7 in network order as shown in Figure 3, based on figure 4
of [RFC9010] which defines the flags in position 0 and 1: of [RFC9010] which defines the flags in position 0 and 1:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length |F|X|A|M|ROVRsz | Prefix Length | | Type = 0x05 | Option Length |F|X|A|M|ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 46 skipping to change at page 14, line 5
New and updated Option Fields: New and updated Option Fields:
Rsv 2-bit field: reserved, MUST be set to 0 and ignored by the Rsv 2-bit field: reserved, MUST be set to 0 and ignored by the
receiver receiver
A 1-bit flag: "Registration for Anycast Address" A 1-bit flag: "Registration for Anycast Address"
M 1-bit flag: "Registration for Multicast Address" M 1-bit flag: "Registration for Multicast Address"
6.2. Registering Extensions 6.2. New EDAR Message Flag field
Section 4 of [RFC6775] provides the same format for DAR and DAC
messages by but the status field is only used in DAC message and has
to set to zero in DAC messages. [RFC8505] extends the DAC message as
an EDAC but does not change the status field in the EDAR.
This specification repurposes the status field in the EDAR and a
Flags field. It adds a new M flag to the EDAR flags field to signal
that the Registered Address is a multicast address and a new A flag
to signal that the Registered Address is an anycast address. As for
EARO, the flags are mutually exclusive.
Figure 5 illustrates the A and M flags in their suggested positions
(0 and 1, respectively, counting 0 to 7 in network order in the 8-bit
array), to be confirmed by IANA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|M| Reserved | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Extended Duplicate Address Message Format
New and updated Option Fields:
Reserved 6-bit field: reserved, MUST be set to 0 and ignored by the
receiver
A 1-bit flag: "Registration for Anycast Address"
M 1-bit flag: "Registration for Multicast Address"
6.3. Registering Extensions
With [RFC8505]: With [RFC8505]:
* Only unicast addresses can be registered. * Only unicast addresses can be registered.
* The 6LN must register all its ULA and GUA with a NS(EARO). * The 6LN must register all its ULA and GUA with a NS(EARO).
* The 6LN may set the R flag in the EARO to obtain return * The 6LN may set the R flag in the EARO to obtain return
reachability services by the 6LR, e.g., through ND proxy reachability services by the 6LR, e.g., through ND proxy
operations, or by injecting the route in a route-over subnet. operations, or by injecting the route in a route-over subnet.
* the 6LR maintains a registration state per Registered Address, * the 6LR maintains a registration state per Registered Address,
including an NCE with the Link Layer Address (LLA) of the including an NCE with the Link Layer Address (LLA) of the
Registered Node (the 6LN here). Registered Node (the 6LN here).
This specification adds the following behavior: This specification adds the following behavior:
* Registration for multicast and anycast addresses is now supported. * Registration for multicast and anycast addresses is now supported.
New flags are added to the EARO to signal when the registered
address is anycast or multicast.
* The Status field in the EDAR message that was reserved and not
used in RFC 8505 is repurposed to transport the flags to signal
multicast and anycast.
* The 6LN MUST also register all the IPv6 multicast addresses that * The 6LN MUST also register all the IPv6 multicast addresses that
it listens to and it MUST set the M flag in the EARO for those it listens to and it MUST set the M flag in the EARO for those
addresses. addresses.
* The 6LN MAY set the R flag in the EARO to obtain the delivery of * The 6LN MAY set the R flag in the EARO to obtain the delivery of
the multicast packets by the 6LR, e.g., by MLD proxy operations, the multicast packets by the 6LR, e.g., by MLD proxy operations,
or by injecting the address in a route-over subnet or in the or by injecting the address in a route-over subnet or in the
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 6LR and the 6LBR are extended to accept more than one
uniquely a registration within the namespace of the Registered registration for the same address when it is anycast or multicast,
Address. The 6LR MUST maintain a registration state per tuple since multiple 6LNs may subscribe to the same address of these
(IPv6 address, ROVR) for both anycast and multicast types of types. In both cases, the Registration Ownership Verifier (ROVR)
address, since multiple 6LNs may subscribe to the same address of in the EARO identifies uniquely a registration within the
these types. namespace of the Registered Address.
* The 6LR MUST maintain a registration state per tuple (IPv6
address, ROVR) for both anycast and multicast types of address.
It SHOULD notify the 6LBR with an EDAR message, unless it
determined that the 6LBR is legacy and does not support this
specification. In turn, the 6LBR MUST maintain a registration
state per tuple (IPv6 address, ROVR) for both anycast and
multicast types of address.
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.
* Upon receiving a packet directed to a unicast address for which it * Upon receiving a packet directed to a unicast address for which it
has an active registration, the 6LR delivers the packet as a has an active registration, the 6LR delivers the packet as a
unicast layer-2 frame to the LLA the nodes that registered the unicast layer-2 frame to the LLA the nodes that registered the
unicast address. unicast address.
This specification adds the following behavior: This specification adds the following behavior:
* Upon a registration with the R and the M flags set to 1 in the * Upon a registration with the R and the M flags set to 1 in the
EARO, the 6LR injects the address in the RPL multicast support. EARO, the 6LR injects the address in the RPL multicast support and
sets the M flag in the RTO.
* Upon a registration with the R and the A flags set to 1 in the
EARO, the 6LR injects the address in the new RPL anycast support
and sets the A flag in the RTO.
* Upon receiving a packet directed to a multicast address for which * Upon receiving a packet directed to a multicast address for which
it has at least one registration, the 6LR delivers a copy of the it has at least one registration, the 6LR delivers a copy of the
packet as a unicast layer-2 frame to the LLA of each of the nodes packet as a unicast layer-2 frame to the LLA of each of the nodes
that registered to that multicast address. that registered to that multicast address.
* Upon receiving a packet directed to a multicast address for which
it has at least one registration, the 6LR delivers a copy of the
packet as a unicast layer-2 frame to the LLA of exactly one of the
nodes that registered to that multicast address.
8. Deployment considerations 8. Deployment considerations
With this specification, a RPL DODAG forms a realm, and multiple RPL With this specification, a RPL DODAG forms a realm, and multiple RPL
DODAGs may federated in a single RPL Instance administratively. This DODAGs may federated in a single RPL Instance administratively. This
means that a multicast address that needs to span a RPL DODAG MUST means that a multicast address that needs to span a RPL DODAG MUST
use a scope of Realm-Local whereas a multicast address that needs to use a scope of Realm-Local whereas a multicast address that needs to
span a RPL Instance MUST use a scope of Admin-Local as discussed in span a RPL Instance MUST use a scope of Admin-Local as discussed in
section 3 of "IPv6 Multicast Address Scopes" [RFC7346]. section 3 of "IPv6 Multicast Address Scopes" [RFC7346].
"IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed
skipping to change at page 16, line 24 skipping to change at page 19, line 18
that document also applies to this document. In particular, the link that document also applies to this document. In particular, the link
layer SHOULD be sufficiently protected to prevent rogue access. layer SHOULD be sufficiently protected to prevent rogue access.
10. Backward Compatibility 10. Backward Compatibility
A legacy 6LN will not register multicast addresses and the service A legacy 6LN will not register multicast addresses and the service
will be the same when the network is upgraded. A legacy 6LR will not will be the same when the network is upgraded. A legacy 6LR will not
set the M flag in the 6CIO and an upgraded 6LN will not register set the M flag in the 6CIO and an upgraded 6LN will not register
multicast addresses. multicast addresses.
Upon an EDAR message, a legacy 6LBR may not realize that the address
being registered is anycast or multicast, and return that it is
duplicate in the EDAC status. The 6LR MUST ignore a duplicate status
in the EDAR for anycast and multicast addresses.
As detailed in Section 8, it is possible to add multicast on an As detailed in Section 8, it is possible to add multicast on an
existing MOP 1 deployment, existing MOP 1 deployment.
The combination of a multicast address and the M flag set to 0 in an The combination of a multicast address and the M flag set to 0 in an
RTO in a MOP 3 RPL Instance is understood by the receiver that RTO in a MOP 3 RPL Instance is understood by the receiver that
supports this specification (the parent) as an indication that the supports this specification (the parent) as an indication that the
sender (child) does not support this specification, but the RTO is sender (child) does not support this specification, but the RTO is
accepted and processed as if the M flag was set for backward accepted and processed as if the M flag was set for backward
compatibility. compatibility.
When the DODAG is operated in MOP 3, a legacy node will not set the M When the DODAG is operated in MOP 3, a legacy node will not set the M
flag and still expect multicast service as specified in section 12 of flag and still expect multicast service as specified in section 12 of
[RFC6550]. In MOP 3 an RTO that is received with a target that is [RFC6550]. In MOP 3 an RTO that is received with a target that is
multicast and the M bit set to 0 MUST be considered as multicast and multicast and the M bit set to 0 MUST be considered as multicast and
MUST be processed as if the M flag is set. MUST be processed as if the M flag is set.
11. IANA Considerations 11. IANA Considerations
Note to RFC Editor, to be removed: please replace "This RFC" Note to RFC Editor, to be removed: please replace "This RFC"
throughout this document by the RFC number for this specification throughout this document by the RFC number for this specification
once it is allocated. Also, the I Field is defined in RFC 9010 but once it is allocated. Also, the I Field is defined in [RFC9010] but
we failed to insert it in the subregistry and the flags appear as is missing from the subregistry, so the bit positions must be added
unspecified though they are. for completeness.
IANA is requested to make changes under the "Internet Control Message IANA is requested to make changes under the "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing
Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL]
registries, as follows: registries, as follows:
11.1. New RTO flags 11.1. New EDAR Message Flags Subregistry
IANA is requested to make additions to the "RPL Target Option Flags" IANA is requested to create a new "EDAR Message Flags" subregistry of
[IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power the "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
and Lossy Networks (RPL)" registry as indicated in Table 1: registry as indicated in Table 1:
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| Bit Number | Meaning | Reference | | Bit Number | Meaning | Reference |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| 2 (suggested) | A flag: Target is an Anycast Address | This RFC | | 0 (suggested) | A flag: Registered | This RFC |
| | Address is Anycast | |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| 3 (suggested) | M flag: Target is a Multicast | This RFC | | 1 (suggested) | M flag: Registered | This RFC |
| | Address | | | | Address is Multicast | |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
Table 1: New RTO flags Table 1: EDAR Message flags
11.2. New RPL Mode of Operation
IANA is requested to make an addition to the "Mode of Operation"
[IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and
Lossy Networks (RPL)" registry as indicated in Table 2:
+---------------+-------------------------------+-----------+
| Value | Description | Reference |
+---------------+-------------------------------+-----------+
| 5 (suggested) | Non-Storing Mode of Operation | This RFC |
| | with multicast support | |
+---------------+-------------------------------+-----------+
Table 2: New RPL Mode of Operation
11.3. New EARO flags 11.2. New EARO flags
IANA is requested to make additions to the "Address Registration IANA is requested to make additions to the "Address Registration
Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" registry as indicated in Protocol version 6 (ICMPv6) Parameters" registry as indicated in
Table 3: Table 2:
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| ARO flag | Meaning | Reference | | ARO flag | Meaning | Reference |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| 2 (suggested) | A flag: Registration | This RFC | | 2 (suggested) | A flag: Registration | This RFC |
| | for Anycast Address | | | | for Anycast Address | |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| 3 (suggested) | M flag: Registration | This RFC | | 3 (suggested) | M flag: Registration | This RFC |
| | for Multicast Address | | | | for Multicast Address | |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| 4 and 5 | "I" Field | RFC 8505 | | 4 and 5 | "I" Field | RFC 8505 |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
Table 3: New ARO flags Table 2: New ARO flags
11.4. New 6LoWPAN Capability Bits 11.3. New RTO flags
IANA is requested to make additions to the "RPL Target Option Flags"
[IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power
and Lossy Networks (RPL)" registry as indicated in Table 3:
+---------------+---------------------------------------+-----------+
| Bit Number | Meaning | Reference |
+---------------+---------------------------------------+-----------+
| 2 (suggested) | A flag: Registered | This RFC |
| | Address is Anycast | |
+---------------+---------------------------------------+-----------+
| 3 (suggested) | M flag: Registered | This RFC |
| | Address is Multicast | |
+---------------+---------------------------------------+-----------+
Table 3: New RTO flags
11.4. New RPL Mode of Operation
IANA is requested to make an addition to the "Mode of Operation"
[IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and
Lossy Networks (RPL)" registry as indicated in Table 4:
+---------------+-------------------------------+-----------+
| Value | Description | Reference |
+---------------+-------------------------------+-----------+
| 5 (suggested) | Non-Storing Mode of Operation | This RFC |
| | with multicast support | |
+---------------+-------------------------------+-----------+
Table 4: New RPL Mode of Operation
11.5. New 6LoWPAN Capability Bits
IANA is requested to make an addition to the "6LoWPAN Capability IANA is requested to make an addition to the "6LoWPAN Capability
Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet
Control Message Protocol version 6 (ICMPv6) Parameters" registry as Control Message Protocol version 6 (ICMPv6) Parameters" registry as
indicated in Table 4: indicated in Table 5:
+----------------+------------------------------------+-----------+ +----------------+------------------------------------+-----------+
| Capability Bit | Meaning | Reference | | Capability Bit | Meaning | Reference |
+----------------+------------------------------------+-----------+ +----------------+------------------------------------+-----------+
| 8 (suggested) | M flag: Registration for Multicast | This RFC | | 8 (suggested) | M flag: Registration for Multicast | This RFC |
| | and Anycast Addresses Supported | | | | and Anycast Addresses Supported | |
+----------------+------------------------------------+-----------+ +----------------+------------------------------------+-----------+
Table 4: New 6LoWPAN Capability Bits Table 5: New 6LoWPAN Capability Bits
12. Acknowledgments 12. Acknowledgments
13. Normative References 13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 38 change blocks. 
95 lines changed or deleted 222 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/