draft-ietf-mboned-ieee802-mcast-problems-14.txt		draft-ietf-mboned-ieee802-mcast-problems-15.txt
	Internet Area C. Perkins		Internet Area C.E. Perkins
	Internet-Draft Blue Meadow Networks		Internet-Draft Blue Meadow Networks
	Intended status: Informational M. McBride		Intended status: Informational M. McBride
	Expires: December 31, 2021 Futurewei		Expires: 29 January 2022 Futurewei
	D. Stanley		D. Stanley
	HPE		HPE
	W. Kumari		W. Kumari
	Google		Google
	JC. Zuniga		JC. Zuniga
	SIGFOX		SIGFOX
	June 29, 2021		28 July 2021
	Multicast Considerations over IEEE 802 Wireless Media		Multicast Considerations over IEEE 802 Wireless Media
	draft-ietf-mboned-ieee802-mcast-problems-14		draft-ietf-mboned-ieee802-mcast-problems-15
	Abstract		Abstract
	Well-known issues with multicast have prevented the deployment of		Well-known issues with multicast have prevented the deployment of
	multicast in 802.11 (wifi) and other local-area wireless		multicast in 802.11 (wifi) and other local-area wireless
	environments. This document describes the known limitations of		environments. This document describes the known limitations of
	wireless (primarily 802.11) Layer-2 multicast. Also described are		wireless (primarily 802.11) Layer-2 multicast. Also described are
	certain multicast enhancement features that have been specified by		certain multicast enhancement features that have been specified by
	the IETF, and by IEEE 802, for wireless media, as well as some		the IETF, and by IEEE 802, for wireless media, as well as some
	operational choices that can be taken to improve the performance of		operational choices that can be taken to improve the performance of
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 December 31, 2021.		This Internet-Draft will expire on 29 January 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Identified multicast issues . . . . . . . . . . . . . . . . . 5		3. Identified multicast issues . . . . . . . . . . . . . . . . . 5
	3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5		3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5
	3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5		3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5
	3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6		3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6
	3.1.3. Capacity and Impact on Interference . . . . . . . . . 7		3.1.3. Capacity and Impact on Interference . . . . . . . . . 7
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 6 ¶
	4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15		4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15
	5. Operational optimizations . . . . . . . . . . . . . . . . . . 16		5. Operational optimizations . . . . . . . . . . . . . . . . . . 16
	5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16		5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16
	5.2. Mitigating Spurious Service Discovery Messages . . . . . 18		5.2. Mitigating Spurious Service Discovery Messages . . . . . 18
	6. Multicast Considerations for Other Wireless Media . . . . . . 18		6. Multicast Considerations for Other Wireless Media . . . . . . 18
	7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19		7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19
	8. On-going Discussion Items . . . . . . . . . . . . . . . . . . 19		8. On-going Discussion Items . . . . . . . . . . . . . . . . . . 19
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 20		9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		12. Informative References . . . . . . . . . . . . . . . . . . . 21
	12.1. Informative References . . . . . . . . . . . . . . . . . 21
	12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	Well-known issues with multicast have prevented the deployment of		Well-known issues with multicast have prevented the deployment of
	multicast in 802.11 [dot11] and other local-area wireless		multicast in 802.11 [dot11] and other local-area wireless
	environments, as described in [mc-props], [mc-prob-stmt].		environments, as described in [mc-props], [mc-prob-stmt].
	Performance issues have been observed when multicast packet		Performance issues have been observed when multicast packet
	transmissions of IETF protocols are used over IEEE 802 wireless		transmissions of IETF protocols are used over IEEE 802 wireless
	media. Even though enhancements for multicast transmissions have		media. Even though enhancements for multicast transmissions have
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 33 ¶
	that every station has to be configured to wake up to receive the		that every station has to be configured to wake up to receive the
	multicast frame, even though the received packet may ultimately be		multicast frame, even though the received packet may ultimately be
	discarded. This process can have a large effect on the power		discarded. This process can have a large effect on the power
	consumption by the multicast receiver station. For this reason there		consumption by the multicast receiver station. For this reason there
	are workarounds, such as Directed Multicast Service (DMS) described		are workarounds, such as Directed Multicast Service (DMS) described
	in Section 4, to prevent unnecessarily waking up stations.		in Section 4, to prevent unnecessarily waking up stations.
	Multicast (and unicast) can work poorly with the power-save		Multicast (and unicast) can work poorly with the power-save
	mechanisms defined in IEEE 802.11e, for the following reasons.		mechanisms defined in IEEE 802.11e, for the following reasons.
	o Clients may be unable to stay in sleep mode due to multicast		* Clients may be unable to stay in sleep mode due to multicast
	control packets frequently waking them up.		control packets frequently waking them up.
	o A unicast packet is delayed until an STA wakes up and requests it.		* A unicast packet is delayed until an STA wakes up and requests it.
	Unicast traffic may also be delayed to improve power save,		Unicast traffic may also be delayed to improve power save,
	efficiency and increase probability of aggregation.		efficiency and increase probability of aggregation.
	o Multicast traffic is delayed in a wireless network if any of the		* Multicast traffic is delayed in a wireless network if any of the
	STAs in that network are power savers. All STAs associated to the		STAs in that network are power savers. All STAs associated to the
	AP have to be awake at a known time to receive multicast traffic.		AP have to be awake at a known time to receive multicast traffic.
	o Packets can also be discarded due to buffer limitations in the AP		* Packets can also be discarded due to buffer limitations in the AP
	and non-AP STA.		and non-AP STA.
	3.2. Issues at Layer 3 and Above		3.2. Issues at Layer 3 and Above
	This section identifies some representative IETF protocols, and		This section identifies some representative IETF protocols, and
	describes possible negative effects due to performance degradation		describes possible negative effects due to performance degradation
	when using multicast transmissions for control messages. Common uses		when using multicast transmissions for control messages. Common uses
	of multicast include:		of multicast include:
	o Control plane signaling		* Control plane signaling
	o Neighbor Discovery		* Neighbor Discovery
	o Address Resolution		* Address Resolution
	o Service Discovery		* Service Discovery
	o Applications (video delivery, stock data, etc.)		* Applications (video delivery, stock data, etc.)
	o On-demand routing		* On-demand routing
	o Backbone construction		* Backbone construction
	o Other L3 protocols (non-IP)		* Other L3 protocols (non-IP)
	User Datagram Protocol (UDP) is the most common transport layer		User Datagram Protocol (UDP) is the most common transport layer
	protocol for multicast applications. By itself, UDP is not reliable		protocol for multicast applications. By itself, UDP is not reliable
	-- messages may be lost or delivered out of order.		-- messages may be lost or delivered out of order.
	3.2.1. IPv4 issues		3.2.1. IPv4 issues
	The following list contains some representative discovery protocols,		The following list contains some representative discovery protocols,
	which utilize broadcast/multicast, that are used with IPv4.		which utilize broadcast/multicast, that are used with IPv4.
	o ARP [RFC5424]		* ARP [RFC0826]
	o DHCP [RFC2131]		* DHCP [RFC2131]
	o mDNS [RFC6762]		* mDNS [RFC6762]
	o uPnP [RFC6970]		* uPnP [RFC6970]
	After initial configuration, ARP (described in more detail later),		After initial configuration, ARP (described in more detail later),
	DHCP and uPnP occur much less commonly, but service discovery can		DHCP and uPnP occur much less commonly, but service discovery can
	occur at any time. Some widely-deployed service discovery protocols		occur at any time. Some widely-deployed service discovery protocols
	(e.g., for finding a printer) utilize mDNS (i.e., multicast) which is		(e.g., for finding a printer) utilize mDNS (i.e., multicast) which is
	often dropped by operators. Even if multicast snooping [RFC4541]		often dropped by operators. Even if multicast snooping [RFC4541]
	(which provides the benefit of conserving bandwidth on those segments		(which provides the benefit of conserving bandwidth on those segments
	of the network where no node has expressed interest in receiving		of the network where no node has expressed interest in receiving
	packets addressed to the group address) is utilized, many devices can		packets addressed to the group address) is utilized, many devices can
	register at once and cause serious network degradation.		register at once and cause serious network degradation.
	3.2.2. IPv6 issues		3.2.2. IPv6 issues
	IPv6 makes extensive use of multicast, including the following:		IPv6 makes extensive use of multicast, including the following:
	o DHCPv6 [RFC8415]		* DHCPv6 [RFC8415]
	o Protocol Independent Multicast (PIM) [RFC7761]		* Protocol Independent Multicast (PIM) [RFC7761]
	o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]		* IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]
	o multicast DNS (mDNS) [RFC6762]		* multicast DNS (mDNS) [RFC6762]
	o Router Discovery [RFC4286]		* Router Discovery [RFC4286]
	IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate		IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate
	Address Detection (DAD) and Address Lookup make use of Link-Scope		Address Detection (DAD) and Address Lookup make use of Link-Scope
	multicast. In contrast to IPv4, an IPv6 node will typically use		multicast. In contrast to IPv4, an IPv6 node will typically use
	multiple addresses, and may change them often for privacy reasons.		multiple addresses, and may change them often for privacy reasons.
	This intensifies the impact of multicast messages that are associated		This intensifies the impact of multicast messages that are associated
	to the mobility of a node. Router advertisement (RA) messages are		to the mobility of a node. Router advertisement (RA) messages are
	also periodically multicasted over the Link.		also periodically multicasted over the Link.
	Neighbors may be considered lost if several consecutive Neighbor		Neighbors may be considered lost if several consecutive Neighbor
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 40 ¶
	IEEE 802 and IETF that are aimed at reducing or eliminating the		IEEE 802 and IETF that are aimed at reducing or eliminating the
	issues discussed in Section 3.		issues discussed in Section 3.
	4.1. Proxy ARP in 802.11-2012		4.1. Proxy ARP in 802.11-2012
	The AP knows the MAC address and IP address for all associated STAs.		The AP knows the MAC address and IP address for all associated STAs.
	In this way, the AP acts as the central "manager" for all the 802.11		In this way, the AP acts as the central "manager" for all the 802.11
	STAs in its basic service set (BSS). Proxy ARP is easy to implement		STAs in its basic service set (BSS). Proxy ARP is easy to implement
	at the AP, and offers the following advantages:		at the AP, and offers the following advantages:
	o Reduced broadcast traffic (transmitted at low MCS) on the wireless		* Reduced broadcast traffic (transmitted at low MCS) on the wireless
	medium		medium
	o STA benefits from extended power save in sleep mode, as ARP		* STA benefits from extended power save in sleep mode, as ARP
	requests for STA's IP address are handled instead by the AP.		requests for STA's IP address are handled instead by the AP.
	o ARP frames are kept off the wireless medium.		* ARP frames are kept off the wireless medium.
	o No changes are needed to STA implementation.		* No changes are needed to STA implementation.
	Here is the specification language as described in clause 10.23.13 of		Here is the specification language as described in clause 10.23.13 of
	[dot11-proxyarp]:		[dot11-proxyarp]:
	When the AP supports Proxy ARP "[...] the AP shall maintain a		When the AP supports Proxy ARP "[...] the AP shall maintain a
	Hardware Address to Internet Address mapping for each associated		Hardware Address to Internet Address mapping for each associated
	station, and shall update the mapping when the Internet Address of		station, and shall update the mapping when the Internet Address of
	the associated station changes. When the IPv4 address being		the associated station changes. When the IPv4 address being
	resolved in the ARP request packet is used by a non-AP STA		resolved in the ARP request packet is used by a non-AP STA
	currently associated to the BSS, the proxy ARP service shall		currently associated to the BSS, the proxy ARP service shall
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 26 ¶
	| | router 1 | | router 2 | | router 3		| | router 1 | | router 2 | | router 3
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	o o o o o o		o o o o o o
	o o o o o o o o o o o o o o		o o o o o o o o o o o o o o
	o o o o o o o o o o o o o o o		o o o o o o o o o o o o o o o
	o o o o o o o o o o		o o o o o o o o o o
	o o o o o o o		o o o o o o o
	LLN 1 LLN 2 LLN 3		LLN 1 LLN 2 LLN 3
	Figure 1: Backbone Link and Backbone Routers		Figure 1: Backbone Link and Backbone Routers
	LLN nodes can move freely from an LLN anchored at one IPv6 Backbone		LLN nodes can move freely from an LLN anchored at one IPv6 Backbone
	Router to an LLN anchored at another Backbone Router on the same		Router to an LLN anchored at another Backbone Router on the same
	backbone, keeping any of the IPv6 addresses they have configured.		backbone, keeping any of the IPv6 addresses they have configured.
	The Backbone Routers maintain a Binding Table of their Registered		The Backbone Routers maintain a Binding Table of their Registered
	Nodes, which serves as a distributed database of all the LLN Nodes.		Nodes, which serves as a distributed database of all the LLN Nodes.
	An extension to the Neighbor Discovery Protocol is introduced to		An extension to the Neighbor Discovery Protocol is introduced to
	exchange Binding Table information across the Backbone Link as needed		exchange Binding Table information across the Backbone Link as needed
	for the operation of IPv6 Neighbor Discovery.		for the operation of IPv6 Neighbor Discovery.
	skipping to change at page 13, line 41 ¶		skipping to change at page 13, line 41 ¶
	"When an IPv6 address is being resolved, the Proxy Neighbor		"When an IPv6 address is being resolved, the Proxy Neighbor
	Discovery service shall respond with a Neighbor Advertisement		Discovery service shall respond with a Neighbor Advertisement
	message [...] on behalf of an associated STA to an [ICMPv6]		message [...] on behalf of an associated STA to an [ICMPv6]
	Neighbor Solicitation message [...]. When MAC address mappings		Neighbor Solicitation message [...]. When MAC address mappings
	change, the AP may send unsolicited Neighbor Advertisement		change, the AP may send unsolicited Neighbor Advertisement
	Messages on behalf of a STA."		Messages on behalf of a STA."
	NDP may be used to request additional information		NDP may be used to request additional information
	o Maximum Transmission Unit		* Maximum Transmission Unit
	o Router Solicitation		* Router Solicitation
	o Router Advertisement, etc.		* Router Advertisement, etc.
	NDP messages are sent as group addressed (broadcast) frames in		NDP messages are sent as group addressed (broadcast) frames in
	802.11. Using the proxy operation helps to keep NDP messages off the		802.11. Using the proxy operation helps to keep NDP messages off the
	wireless medium.		wireless medium.
	4.6. Using Unicast Instead of Multicast		4.6. Using Unicast Instead of Multicast
	It is often possible to transmit multicast control and data messages		It is often possible to transmit multicast control and data messages
	by using unicast transmissions to each station individually.		by using unicast transmissions to each station individually.
	skipping to change at page 14, line 51 ¶		skipping to change at page 14, line 51 ¶
	4.6.3. Directed Multicast Service (DMS)		4.6.3. Directed Multicast Service (DMS)
	There are situations where more is needed than simply converting		There are situations where more is needed than simply converting
	multicast to unicast. For these purposes, DMS enables an STA to		multicast to unicast. For these purposes, DMS enables an STA to
	request that the AP transmit multicast group addressed frames		request that the AP transmit multicast group addressed frames
	destined to the requesting STAs as individually addressed frames		destined to the requesting STAs as individually addressed frames
	[i.e., convert multicast to unicast]. Here are some characteristics		[i.e., convert multicast to unicast]. Here are some characteristics
	of DMS:		of DMS:
	o Requires 802.11n A-MSDUs		* Requires 802.11n A-MSDUs
	o Individually addressed frames are acknowledged and are buffered		* Individually addressed frames are acknowledged and are buffered
	for power save STAs		for power save STAs
	o The requesting STA may specify traffic characteristics for DMS		* The requesting STA may specify traffic characteristics for DMS
	traffic		traffic
	o DMS was defined in IEEE Std 802.11v-2011		* DMS was defined in IEEE Std 802.11v-2011
	o DMS requires changes to both AP and STA implementation.		* DMS requires changes to both AP and STA implementation.
	DMS is not currently implemented in products. See [Tramarin2017] and		DMS is not currently implemented in products. See [Tramarin2017] and
	[Oliva2013] for more information.		[Oliva2013] for more information.
	4.6.4. Automatic Multicast Tunneling (AMT)		4.6.4. Automatic Multicast Tunneling (AMT)
	AMT[RFC7450] provides a method to tunnel multicast IP packets inside		AMT[RFC7450] provides a method to tunnel multicast IP packets inside
	unicast IP packets over network links that only support unicast.		unicast IP packets over network links that only support unicast.
	When an operating system or application running on an STA has an AMT		When an operating system or application running on an STA has an AMT
	gateway capability integrated, it's possible to use unicast to		gateway capability integrated, it's possible to use unicast to
	traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi		traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi
	portion of the network connected to the AP.		portion of the network connected to the AP.
	It is recommended that multicast-enabled networks deploying AMT		It is recommended that multicast-enabled networks deploying AMT
	relays for this purpose make the relays locally discoverable with the		relays for this purpose make the relays locally discoverable with the
	following methods, as described in		following methods, as described in
	[I-D.ietf-mboned-driad-amt-discovery]:		[I-D.ietf-mboned-driad-amt-discovery]:
	o DNS-SD [RFC6763]		* DNS-SD [RFC6763]
	o the well-known IP addresses from Section 7 of [RFC7450]		* the well-known IP addresses from Section 7 of [RFC7450]
	An AMT gateway that implements multiple standard discovery methods is		An AMT gateway that implements multiple standard discovery methods is
	more likely to discover the local multicast-capable network, instead		more likely to discover the local multicast-capable network, instead
	of forming a connection to a non-local AMT relay further upstream.		of forming a connection to a non-local AMT relay further upstream.
	4.7. GroupCast with Retries (GCR)		4.7. GroupCast with Retries (GCR)
	GCR (defined in [dot11aa]) provides greater reliability by using		GCR (defined in [dot11aa]) provides greater reliability by using
	either unsolicited retries or a block acknowledgement mechanism. GCR		either unsolicited retries or a block acknowledgement mechanism. GCR
	increases probability of broadcast frame reception success, but still		increases probability of broadcast frame reception success, but still
	skipping to change at page 16, line 10 ¶		skipping to change at page 16, line 13 ¶
	responses.		responses.
	GCR is suitable for all group sizes including medium to large groups.		GCR is suitable for all group sizes including medium to large groups.
	As the number of devices in the group increases, GCR can send block		As the number of devices in the group increases, GCR can send block
	acknowledgement requests to only a small subset of the group. GCR		acknowledgement requests to only a small subset of the group. GCR
	does require changes to both AP and STA implementations.		does require changes to both AP and STA implementations.
	GCR may introduce unacceptable latency. After sending a group of		GCR may introduce unacceptable latency. After sending a group of
	data frames to the group, the AP has to do the following:		data frames to the group, the AP has to do the following:
	o unicast a Block Ack Request (BAR) to a subset of members.		* unicast a Block Ack Request (BAR) to a subset of members.
	o wait for the corresponding Block Ack (BA).		* wait for the corresponding Block Ack (BA).
	o retransmit any missed frames.		* retransmit any missed frames.
	o resume other operations that may have been delayed.		* resume other operations that may have been delayed.
	This latency may not be acceptable for some traffic.		This latency may not be acceptable for some traffic.
	There are ongoing extensions in 802.11 to improve GCR performance.		There are ongoing extensions in 802.11 to improve GCR performance.
	o BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is		* BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is
	already specified in 802.11-REVmc 4.3).		already specified in 802.11-REVmc 4.3).
	o BA is sent using uplink MU-MIMO (which is a .11ax feature).		* BA is sent using uplink MU-MIMO (which is a .11ax feature).
	o Additional 802.11ax extensions are under consideration; see		* Additional 802.11ax extensions are under consideration; see
	[mc-ack-mux]		[mc-ack-mux]
	o Latency may also be reduced by simultaneously receiving BA		* Latency may also be reduced by simultaneously receiving BA
	information from multiple STAs.		information from multiple STAs.
	5. Operational optimizations		5. Operational optimizations
	This section lists some operational optimizations that can be		This section lists some operational optimizations that can be
	implemented when deploying wireless IEEE 802 networks to mitigate		implemented when deploying wireless IEEE 802 networks to mitigate
	some of the issues discussed in Section 3.		some of the issues discussed in Section 3.
	5.1. Mitigating Problems from Spurious Neighbor Discovery		5.1. Mitigating Problems from Spurious Neighbor Discovery
	skipping to change at page 19, line 8 ¶		skipping to change at page 19, line 5 ¶
	result that many such functions are relegated to operation within		result that many such functions are relegated to operation within
	higher layer protocols. This leads to a patchwork of non-		higher layer protocols. This leads to a patchwork of non-
	interoperable and vendor-specific solutions. See [uli] for some		interoperable and vendor-specific solutions. See [uli] for some
	additional discussion, and a proposal for a task group to resolve		additional discussion, and a proposal for a task group to resolve
	similar issues, in which the multicast problems might be considered		similar issues, in which the multicast problems might be considered
	for mitigation.		for mitigation.
	Similar considerations hold for most other wireless media. A brief		Similar considerations hold for most other wireless media. A brief
	introduction is provided in [RFC5757] for the following:		introduction is provided in [RFC5757] for the following:
	o 802.16 WIMAX		* 802.16 WIMAX
	o 3GPP/3GPP2		* 3GPP/3GPP2
	o DVB-H / DVB-IPDC		* DVB-H / DVB-IPDC
	o TV Broadcast and Satellite Networks		* TV Broadcast and Satellite Networks
	7. Recommendations		7. Recommendations
	This section provides some recommendations about the usage and		This section provides some recommendations about the usage and
	combinations of some of the multicast enhancements described in		combinations of some of the multicast enhancements described in
	Section 4 and Section 5.		Section 4 and Section 5.
	Future protocol documents utilizing multicast signaling should be		Future protocol documents utilizing multicast signaling should be
	carefully scrutinized if the protocol is likely to be used over		carefully scrutinized if the protocol is likely to be used over
	wireless media.		wireless media.
	skipping to change at page 19, line 36 ¶		skipping to change at page 19, line 33 ¶
	of any needed multicast operations.		of any needed multicast operations.
	Multicast signaling for wireless devices should be done in a way		Multicast signaling for wireless devices should be done in a way
	compatible with low duty-cycle operation.		compatible with low duty-cycle operation.
	8. On-going Discussion Items		8. On-going Discussion Items
	This section suggests two discussion items for further resolution.		This section suggests two discussion items for further resolution.
	First, standards (and private) organizations should develop		First, standards (and private) organizations should develop
	guidelines to help clarify when multicast packets should be sent		guidelines to help clarify when multicast packets would be better
	wired rather than wireless. For example, 802.1ak [1] works on both		served by being sent wired rather than wireless. For example,
	ethernet and Wi-Fi and organizations could help decision making by		802.1ak (https://www.ieee802.org/1/pages/802.1ak.html) works on both
	developing guidelines for multicast over Wi-Fi including options for		ethernet and Wi-Fi and organizations could help with deployment
	when traffic should be sent wired.		decision making by developing guidelines for multicast over Wi-Fi
			including options for when traffic should be sent wired.
	Second, reliable registration to Layer-2 multicast groups, and a		Second, reliable registration to Layer-2 multicast groups, and a
	reliable multicast operation at Layer-2, might provide a good		reliable multicast operation at Layer-2, might provide a good
	multicast over wifi solution. There shouldn't be a need to support		multicast over wifi solution. There shouldn't be a need to support
	2^24 groups to get solicited node multicast working: it is possible		2^24 groups to get solicited node multicast working: it is possible
	to simply select a number of bits that make sense for a given network		to simply select a number of bits that make sense for a given network
	size to limit the number of unwanted deliveries to reasonable levels.		size to limit the number of unwanted deliveries to reasonable levels.
	IEEE 802.1, 802.11, and 802.15 should be encouraged to revisit L2		IEEE 802.1, 802.11, and 802.15 should be encouraged to revisit L2
	multicast issues and provide workable solutions.		multicast issues and provide workable solutions.
	9. Security Considerations		9. Security Considerations
	This document does not introduce or modify any security mechanisms.		This document does not introduce or modify any security mechanisms.
	Multicast deployed on wired or wireless networks as discussed in this		Multicast deployed on wired or wireless networks as discussed in this
	document can be made more secure in a variety of ways. [RFC7761],		document can be made more secure in a variety of ways. [RFC4601],
	for instance, specifies the use of IPsec to ensure authentication of		for instance, specifies the use of IPsec to ensure authentication of
	the link-local messages in the Protocol Independent Multicast -		the link-local messages in the Protocol Independent Multicast -
	Sparse Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms		Sparse Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms
	to authenticate the PIM-SM link-local messages using the IP security		to authenticate the PIM-SM link-local messages using the IP security
	(IPsec) Encapsulating Security Payload (ESP) or (optionally) the		(IPsec) Encapsulating Security Payload (ESP) or (optionally) the
	Authentication Header (AH).		Authentication Header (AH).
	When using mechanisms that convert multicast traffic to unicast		When using mechanisms that convert multicast traffic to unicast
	traffic for traversing radio links, the AP (or other entity) is		traffic for traversing radio links, the AP (or other entity) is
	forced to explicitly track which subscribers care about certain		forced to explicitly track which subscribers care about certain
	skipping to change at page 21, line 13 ¶		skipping to change at page 21, line 13 ¶
	This document does not request any IANA actions.		This document does not request any IANA actions.
	11. Acknowledgements		11. Acknowledgements
	This document has benefitted from discussions with the following		This document has benefitted from discussions with the following
	people, in alphabetical order: Mikael Abrahamsson, Bill Atwood,		people, in alphabetical order: Mikael Abrahamsson, Bill Atwood,
	Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel		Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel
	Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal		Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal
	Thubert, Jeffrey (Zhaohui) Zhang		Thubert, Jeffrey (Zhaohui) Zhang
	12. References		12. Informative References
	12.1. Informative References
	[arpsponge]		[arpsponge]
	Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address		Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address
	resolution on AMS-IX and the ARP Sponge", July 2009,		resolution on AMS-IX and the ARP Sponge", July 2009,
	<http://citeseerx.ist.psu.edu/viewdoc/		<http://citeseerx.ist.psu.edu/viewdoc/
	summary?doi=10.1.1.182.4692>.		summary?doi=10.1.1.182.4692>.
	[bridge-mc-2-uc]		[bridge-mc-2-uc]
	Fietkau, F., "bridge: multicast to unicast", Jan 2017,		Fietkau, F., "bridge: multicast to unicast", January 2017,
	<https://github.com/torvalds/linux/		<https://github.com/torvalds/linux/
	commit/6db6f0eae6052b70885562e1733896647ec1d807>.		commit/6db6f0eae6052b70885562e1733896647ec1d807>.
	[CAB] Fietkau, F., "Limit multicast buffer hardware queue		[CAB] Fietkau, F., "Limit multicast buffer hardware queue
	depth", 2013,		depth", 2013,
	<https://patchwork.kernel.org/patch/2687951/>.		<https://patchwork.kernel.org/patch/2687951/>.
	[Deri-2010]		[Deri-2010]
	Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet		Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet
	Filtering Using Commodity Network Adapters", RIPE 61,		Filtering Using Commodity Network Adapters", RIPE 61,
	skipping to change at page 21, line 48 ¶		skipping to change at page 21, line 46 ¶
	[dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for		[dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for
	Information technology--Telecommunications and information		Information technology--Telecommunications and information
	exchange between systems Local and metropolitan area		exchange between systems Local and metropolitan area
	networks--Specific requirements - Part 11: Wireless LAN		networks--Specific requirements - Part 11: Wireless LAN
	Medium Access Control (MAC) and Physical Layer (PHY)		Medium Access Control (MAC) and Physical Layer (PHY)
	Specification (includes 802.11v amendment)", March 2016,		Specification (includes 802.11v amendment)", March 2016,
	<http://standards.ieee.org/findstds/		<http://standards.ieee.org/findstds/
	standard/802.11-2016.html>.		standard/802.11-2016.html>.
	[dot11-proxyarp]		[dot11-proxyarp]
	Hiertz, G., Mestanov, F., and B. Hart, "Proxy ARP in		Hiertz, G. R., Mestanov, F., and B. Hart, "Proxy ARP in
	802.11ax", September 2015,		802.11ax", September 2015,
	<https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-		<https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-
	proxy-arp-in-802-11ax.pptx>.		proxy-arp-in-802-11ax.pptx>.
	[dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access		[dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access
	Control (MAC) and Physical Layer (PHY) Specifications		Control (MAC) and Physical Layer (PHY) Specifications
	Amendment 2: MAC Enhancements for Robust Audio Video		Amendment 2: MAC Enhancements for Robust Audio Video
	Streaming", March 2012,		Streaming", March 2012,
	<https://standards.ieee.org/standard/802_11aa-2012.html>.		<https://standards.ieee.org/standard/802_11aa-2012.html>.
	[group_key]		[group_key]
	Spiff, "Why do some WiFi routers block multicast packets		Spiff, "Why do some WiFi routers block multicast packets
	going from wired to wireless?", Jan 2017,		going from wired to wireless?", January 2017,
	<https://superuser.com/questions/730288/why-do-some-wifi-		<https://superuser.com/questions/730288/why-do-some-wifi-
	routers-block-multicast-packets-going-from-wired-to-		routers-block-multicast-packets-going-from-wired-to-
	wireless>.		wireless>.
	[I-D.ietf-6lo-backbone-router]		[I-D.ietf-6lo-backbone-router]
	Thubert, P., Perkins, C. E., and E. Levy-Abegnoli, "IPv6		Thubert, P., Perkins, C. E., and E. Levy-Abegnoli, "IPv6
	Backbone Router", draft-ietf-6lo-backbone-router-20 (work		Backbone Router", Work in Progress, Internet-Draft, draft-
	in progress), March 2020.		ietf-6lo-backbone-router-20, 23 March 2020,
			<https://www.ietf.org/archive/id/draft-ietf-6lo-backbone-
			router-20.txt>.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the Time-
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-30 (work		Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
	in progress), November 2020.		Work in Progress, Internet-Draft, draft-ietf-6tisch-
			architecture-30, 26 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-6tisch-
			architecture-30.txt>.
	[I-D.ietf-mboned-driad-amt-discovery]		[I-D.ietf-mboned-driad-amt-discovery]
	Holland, J., "DNS Reverse IP Automatic Multicast Tunneling		Holland, J., "DNS Reverse IP Automatic Multicast Tunneling
	(AMT) Discovery", draft-ietf-mboned-driad-amt-discovery-13		(AMT) Discovery", Work in Progress, Internet-Draft, draft-
	(work in progress), December 2019.		ietf-mboned-driad-amt-discovery-13, 20 December 2019,
			<https://www.ietf.org/archive/id/draft-ietf-mboned-driad-
			amt-discovery-13.txt>.
	[ietf_802-11]		[ietf_802-11]
	Stanley, D., "IEEE 802.11 multicast capabilities", Nov		Stanley, D., "IEEE 802.11 multicast capabilities",
	2015, <https://mentor.ieee.org/802.11/		November 2015, <https://mentor.ieee.org/802.11/
	dcn/15/11-15-1261-03-0arc-multicast-performance-		dcn/15/11-15-1261-03-0arc-multicast-performance-
	optimization-features-overview-for-ietf-nov-2015.ppt>.		optimization-features-overview-for-ietf-nov-2015.ppt>.
	[mc-ack-mux]		[mc-ack-mux]
	Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G.,		Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G.,
	and S. Coffey, "Multiplexing of Acknowledgements for		and S. Coffey, "Multiplexing of Acknowledgements for
	Multicast Transmission", July 2015,		Multicast Transmission", July 2015,
	<https://mentor.ieee.org/802.11/dcn/15/11-15-0800-00-00ax-		<https://mentor.ieee.org/802.11/dcn/15/11-15-0800-00-00ax-
	multiplexing-of-acknowledgements-for-multicast-		multiplexing-of-acknowledgements-for-multicast-
	transmission.pptx>.		transmission.pptx>.
	[mc-prob-stmt]		[mc-prob-stmt]
	Abrahamsson, M. and A. Stephens, "Multicast on 802.11",		Abrahamsson, M. and A. Stephens, "Multicast on 802.11",
	March 2015, <https://www.iab.org/wp-content/IAB-		March 2015, <https://www.iab.org/wp-content/IAB-
	uploads/2013/01/multicast-problem-statement.pptx>.		uploads/2013/01/multicast-problem-statement.pptx>.
	[mc-props]		[mc-props] Stephens, A., "IEEE 802.11 multicast properties", March
	Stephens, A., "IEEE 802.11 multicast properties", March
	2015, <https://mentor.ieee.org/802.11/		2015, <https://mentor.ieee.org/802.11/
	dcn/15/11-15-1161-02-0arc-802-11-multicast-		dcn/15/11-15-1161-02-0arc-802-11-multicast-
	properties.ppt>.		properties.ppt>.
	[Oliva2013]		[Oliva2013]
	de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs,		de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs,
	"Performance evaluation of the IEEE 802.11aa multicast		"Performance evaluation of the IEEE 802.11aa multicast
	mechanisms for video streaming", 2013 IEEE 14th		mechanisms for video streaming", 2013 IEEE 14th
	International Symposium on "A World of Wireless, Mobile		International Symposium on "A World of Wireless, Mobile
	and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013.		and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013.
			[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
			Converting Network Protocol Addresses to 48.bit Ethernet
			Address for Transmission on Ethernet Hardware", STD 37,
			RFC 826, DOI 10.17487/RFC0826, November 1982,
			<https://www.rfc-editor.org/info/rfc826>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, DOI 10.17487/RFC2131, March 1997,		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<https://www.rfc-editor.org/info/rfc2131>.		<https://www.rfc-editor.org/info/rfc2131>.
	[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",		[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
	RFC 4286, DOI 10.17487/RFC4286, December 2005,		RFC 4286, DOI 10.17487/RFC4286, December 2005,
	<https://www.rfc-editor.org/info/rfc4286>.		<https://www.rfc-editor.org/info/rfc4286>.
	[RFC4541] Christensen, M., Kimball, K., and F. Solensky,		[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
	"Considerations for Internet Group Management Protocol		"Considerations for Internet Group Management Protocol
	(IGMP) and Multicast Listener Discovery (MLD) Snooping		(IGMP) and Multicast Listener Discovery (MLD) Snooping
	Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,		Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
	<https://www.rfc-editor.org/info/rfc4541>.		<https://www.rfc-editor.org/info/rfc4541>.
			[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
			"Protocol Independent Multicast - Sparse Mode (PIM-SM):
			Protocol Specification (Revised)", RFC 4601,
			DOI 10.17487/RFC4601, August 2006,
			<https://www.rfc-editor.org/info/rfc4601>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862,		Address Autoconfiguration", RFC 4862,
	DOI 10.17487/RFC4862, September 2007,		DOI 10.17487/RFC4862, September 2007,
	<https://www.rfc-editor.org/info/rfc4862>.		<https://www.rfc-editor.org/info/rfc4862>.
	skipping to change at page 25, line 17 ¶		skipping to change at page 25, line 29 ¶
	Wireless Personal Area Network (6LoWPAN) Neighbor		Wireless Personal Area Network (6LoWPAN) Neighbor
	Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,		Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
	<https://www.rfc-editor.org/info/rfc8505>.		<https://www.rfc-editor.org/info/rfc8505>.
	[Tramarin2017]		[Tramarin2017]
	Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n		Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n
	for Distributed Measurement Systems", 2017 IEEE		for Distributed Measurement Systems", 2017 IEEE
	International Instrumentation and Measurement Technology		International Instrumentation and Measurement Technology
	Conference (I2MTC) pp. 1-6, May 2017.		Conference (I2MTC) pp. 1-6, May 2017.
	[uli] Kinney, P., "LLC Proposal for 802.15.4", Nov 2015,		[uli] Kinney, P., "LLC Proposal for 802.15.4", November 2015,
	<https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-		<https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-
	llc-proposal-for-802-15-4.pptx>.		llc-proposal-for-802-15-4.pptx>.
	12.2. URIs
	[1] https://www.ieee802.org/1/pages/802.1ak.html
	Authors' Addresses		Authors' Addresses
	Charles E. Perkins		Charles E. Perkins
	Blue Meadow Networks		Blue Meadow Networks
	Phone: +1-408-330-4586		Phone: +1-408-330-4586
	Email: charliep@computer.org		Email: charliep@computer.org
	Mike McBride		Mike McBride
	Futurewei Technologies Inc.		Futurewei Technologies Inc.
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95055		Santa Clara, CA 95055
	USA		United States of America
	Email: michael.mcbride@futurewei.com		Email: michael.mcbride@futurewei.com
	Dorothy Stanley		Dorothy Stanley
	Hewlett Packard Enterprise		Hewlett Packard Enterprise
	2000 North Naperville Rd.		2000 North Naperville Rd.
	Naperville, IL 60566		Naperville, IL 60566
	USA		United States of America
	Phone: +1 630 979 1572		Phone: +1 630 979 1572
	Email: dstanley1389@gmail.com		Email: dstanley1389@gmail.com
	Warren Kumari		Warren Kumari
	Google		Google
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		United States of America
	Email: warren@kumari.net		Email: warren@kumari.net
	Juan Carlos Zuniga		Juan Carlos Zuniga
	SIGFOX		SIGFOX
	425 rue Jean Rostand		425 rue Jean Rostand
	Labege 31670		31670 Labege
	France		France
	Email: j.c.zuniga@ieee.org		Email: j.c.zuniga@ieee.org
End of changes. 49 change blocks.
	100 lines changed or deleted		110 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/