< 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/