draft-ietf-mboned-ieee802-mcast-problems-09.txt		draft-ietf-mboned-ieee802-mcast-problems-10.txt
	Internet Area C. Perkins		Internet Area C. Perkins
	Internet-Draft		Internet-Draft
	Intended status: Informational M. McBride		Intended status: Informational M. McBride
	Expires: March 29, 2020 Futurewei		Expires: May 7, 2020 Futurewei
	D. Stanley		D. Stanley
	HPE		HPE
	W. Kumari		W. Kumari
	Google		Google
	JC. Zuniga		JC. Zuniga
	SIGFOX		SIGFOX
	September 26, 2019		November 4, 2019
	Multicast Considerations over IEEE 802 Wireless Media		Multicast Considerations over IEEE 802 Wireless Media
	draft-ietf-mboned-ieee802-mcast-problems-09		draft-ietf-mboned-ieee802-mcast-problems-10
	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 and other local-area wireless environments. This		multicast in 802.11 and other local-area wireless environments. This
	document offers guidance on known limitations and problems with		document offers guidance on known limitations and problems with
	wireless Layer-2 multicast. Also described are certain multicast		wireless (primarily 802.11) Layer-2 multicast. Also described are
	enhancement features that have been specified by the IETF and by IEEE		certain multicast enhancement features that have been specified by
	802 for wireless media, as well as some operational choices that can		the IETF and by IEEE 802 for wireless media, as well as some
	be taken to improve the performance of the network. Finally, some		operational choices that can be taken to improve the performance of
	recommendations are provided about the usage and combination of these		the network. Finally, some recommendations are provided about the
	features and operational choices.		usage and combination of these features and operational choices.
	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 March 29, 2020.		This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	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. High Interference . . . . . . . . . . . . . . . . . . 7		3.1.3. Capacity and Impact on Interference . . . . . . . . . 7
	3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7		3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7
	3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7		3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7
	3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8		3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8
	3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8		3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8
	3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9		3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9
	3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9		3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9
	4. Multicast protocol optimizations . . . . . . . . . . . . . . 10		4. Multicast protocol optimizations . . . . . . . . . . . . . . 10
	4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10		4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10
	4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 11		4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 11
	4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12		4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	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. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 19		8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 19
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 20		9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	12. Informative References . . . . . . . . . . . . . . . . . . . 20		12. Informative References . . . . . . . . . . . . . . . . . . . 20
	Appendix A. Changes in this draft between revisions 06 versus 07 24		Appendix A. Changes in this draft between revisions 06 versus 07 24
	Appendix B. Changes in this draft between revisions 05 versus 06 24		Appendix B. Changes in this draft between revisions 05 versus 06 24
	Appendix C. Changes in this draft between revisions 04 versus 05 24		Appendix C. Changes in this draft between revisions 04 versus 05 25
	Appendix D. Changes in this draft between revisions 03 versus 04 25		Appendix D. Changes in this draft between revisions 03 versus 04 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
	been designed at both IETF and IEEE 802, incompatibilities still		been designed at both IETF and IEEE 802, incompatibilities still
	exist between specifications, implementations and configuration		exist between specifications, implementations and configuration
	choices.		choices.
	Many IETF protocols depend on multicast/broadcast for delivery of		Many IETF protocols depend on multicast/broadcast for delivery of
	control messages to multiple receivers. Multicast is used for		control messages to multiple receivers. Multicast allows sending
	various purposes such as neighbor discovery, network flooding,		data to multiple interested recipients without the source needing to
	address resolution, as well minimizing media occupancy for the		send duplicate data to each recipient. With broadcast traffic, data
	transmission of data that is intended for multiple receivers. In		is sent to every device regardless of their interest in the data.
	addition to protocol use of broadcast/multicast for control messages,		Multicast is used for various purposes such as neighbor discovery,
	more applications, such as push to talk in hospitals, or video in		network flooding, address resolution, as well minimizing media
	enterprises, universities, and homes, are sending multicast IP to end		occupancy for the transmission of data that is intended for multiple
	user devices, which are increasingly using Wi-Fi for their		receivers. In addition to protocol use of broadcast/multicast for
	connectivity.		control messages, more applications, such as push to talk in
			hospitals, or video in enterprises, universities, and homes, are
			sending multicast IP to end user devices, which are increasingly
			using Wi-Fi for their connectivity.
	IETF protocols typically rely on network protocol layering in order		IETF protocols typically rely on network protocol layering in order
	to reduce or eliminate any dependence of higher level protocols on		to reduce or eliminate any dependence of higher level protocols on
	the specific nature of the MAC layer protocols or the physical media.		the specific nature of the MAC layer protocols or the physical media.
	In the case of multicast transmissions, higher level protocols have		In the case of multicast transmissions, higher level protocols have
	traditionally been designed as if transmitting a packet to an IP		traditionally been designed as if transmitting a packet to an IP
	address had the same cost in interference and network media access,		address had the same cost in interference and network media access,
	regardless of whether the destination IP address is a unicast address		regardless of whether the destination IP address is a unicast address
	or a multicast or broadcast address. This model was reasonable for		or a multicast or broadcast address. This model was reasonable for
	networks where the physical medium was wired, like Ethernet.		networks where the physical medium was wired, like Ethernet.
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 38 ¶
	needs to be provided in order to make them more reliable. IPv6		needs to be provided in order to make them more reliable. IPv6
	neighbor discovery saturating the Wi-Fi link is only part of the		neighbor discovery saturating the Wi-Fi link is only part of the
	problem. Wi-Fi traffic classes may help. This document is intended		problem. Wi-Fi traffic classes may help. This document is intended
	to help make the determination about what problems should be solved		to help make the determination about what problems should be solved
	by the IETF and what problems should be solved by the IEEE (see		by the IETF and what problems should be solved by the IEEE (see
	Section 8).		Section 8).
	This document details various problems caused by multicast		This document details various problems caused by multicast
	transmission over wireless networks, including high packet error		transmission over wireless networks, including high packet error
	rates, no acknowledgements, and low data rate. It also explains some		rates, no acknowledgements, and low data rate. It also explains some
	enhancements that have been designed at the IETF and IEEE 802 to		enhancements that have been designed at the IETF and IEEE 802.11 to
	ameliorate the effects of multicast traffic. Recommendations are		ameliorate the effects of multicast traffic. Recommendations are
	also provided to implementors about how to use and combine these		also provided to implementors about how to use and combine these
	enhancements. Some advice about the operational choices that can be		enhancements. Some advice about the operational choices that can be
	taken is also included. It is likely that this document will also be		taken is also included. It is likely that this document will also be
	considered relevant to designers of future IEEE wireless		considered relevant to designers of future IEEE wireless
	specifications.		specifications.
	2. Terminology		2. Terminology
	This document uses the following definitions:		This document uses the following definitions:
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 46 ¶
	3.1. Issues at Layer 2 and Below		3.1. Issues at Layer 2 and Below
	In this section some of the issues related to the use of multicast		In this section some of the issues related to the use of multicast
	transmissions over IEEE 802 wireless technologies are described.		transmissions over IEEE 802 wireless technologies are described.
	3.1.1. Multicast reliability		3.1.1. Multicast reliability
	Multicast traffic is typically much less reliable than unicast		Multicast traffic is typically much less reliable than unicast
	traffic. Since multicast makes point-to-multipoint communications,		traffic. Since multicast makes point-to-multipoint communications,
	multiple acknowledgements would be needed to guarantee reception at		multiple acknowledgements would be needed to guarantee reception at
	all recipients. Since typically there are no ACKs for multicast		all recipients. Since there are no ACKs for multicast packets, it is
	packets, it is not possible for the Access Point (AP) to know whether		not possible for the Access Point (AP) to know whether or not a
	or not a retransmission is needed. Even in the wired Internet, this		retransmission is needed. Even in the wired Internet, this
	characteristic often causes undesirably high error rates. This has		characteristic often causes undesirably high error rates. This has
	contributed to the relatively slow uptake of multicast applications		contributed to the relatively slow uptake of multicast applications
	even though the protocols have long been available. The situation		even though the protocols have long been available. The situation
	for wireless links is much worse, and is quite sensitive to the		for wireless links is much worse, and is quite sensitive to the
	presence of background traffic. Consequently, there can be a high		presence of background traffic. Consequently, there can be a high
	packet error rate (PER) due to lack of retransmission, and because		packet error rate (PER) due to lack of retransmission, and because
	the sender never backs off. It is not uncommon for there to be a		the sender never backs off. It is not uncommon for there to be a
	packet loss rate of 5% or more, which is particularly troublesome for		packet loss rate of 5% or more, which is particularly troublesome for
	video and other environments where high data rates and high		video and other environments where high data rates and high
	reliability are required.		reliability are required.
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 29 ¶
	impact the ability for QoS solutions to effectively reserve bandwidth		impact the ability for QoS solutions to effectively reserve bandwidth
	and provide admission control.		and provide admission control.
	For wireless stations associated with an Access Point, the power		For wireless stations associated with an Access Point, the power
	necessary for good reception can vary from station to station. For		necessary for good reception can vary from station to station. For
	unicast, the goal is to minimize power requirements while maximizing		unicast, the goal is to minimize power requirements while maximizing
	the data rate to the destination. For multicast, the goal is simply		the data rate to the destination. For multicast, the goal is simply
	to maximize the number of receivers that will correctly receive the		to maximize the number of receivers that will correctly receive the
	multicast packet; generally the Access Point has to use a much lower		multicast packet; generally the Access Point has to use a much lower
	data rate at a power level high enough for even the farthest station		data rate at a power level high enough for even the farthest station
	to receive the packet, for example as briefly mentioned in [RFC5757].		to receive the packet, for example as briefly mentioned in section 2
	Consequently, the data rate of a video stream, for instance, would be		of [RFC5757]. Consequently, the data rate of a video stream, for
	constrained by the environmental considerations of the least reliable		instance, would be constrained by the environmental considerations of
	receiver associated with the Access Point.		the least reliable receiver associated with the Access Point.
	Because more robust modulation and coding schemes (MCSs) have longer		Because more robust modulation and coding schemes (MCSs) have longer
	range but also lower data rate, multicast / broadcast traffic is		range but also lower data rate, multicast / broadcast traffic is
	generally transmitted at the slowest rate of all the connected		generally transmitted at the slowest rate of all the connected
	devices. This is also known as the basic rate. The amount of		devices. This is also known as the basic rate. The amount of
	additional interference depends on the specific wireless technology.		additional interference depends on the specific wireless technology.
	In fact, backward compatibility and multi-stream implementations mean		In fact, backward compatibility and multi-stream implementations mean
	that the maximum unicast rates are currently up to a few Gbps, so		that the maximum unicast rates are currently up to a few Gbps, so
	there can be more than 3 orders of magnitude difference in the		there can be more than 3 orders of magnitude difference in the
	transmission rate between multicast / broadcast versus optimal		transmission rate between multicast / broadcast versus optimal
	unicast forwarding. Some techiques employed to increase spectral		unicast forwarding. Some techiques employed to increase spectral
	efficiency, such as spatial multiplexing in mimo systems, are not		efficiency, such as spatial multiplexing in MIMO systems, are not
	available with more than one intended reciever; it is not the case		available with more than one intended receiver; it is not the case
	that backwards compatibility is the only factor responsible for lower		that backwards compatibility is the only factor responsible for lower
	multicast transmission rates.		multicast transmission rates.
	Wired multicast also affects wireless LANs when the AP extends the		Wired multicast also affects wireless LANs when the AP extends the
	wired segment; in that case, multicast / broadcast frames on the		wired segment; in that case, multicast / broadcast frames on the
	wired LAN side are copied to WLAN. Since broadcast messages are		wired LAN side are copied to the Wireless Local Area Network (WLAN).
	transmitted at the most robust MCS, many large frames are sent at a
	slow rate over the air.
	3.1.3. High Interference		Since broadcast messages are transmitted at the most robust MCS, many
			large frames are sent at a slow rate over the air.
			3.1.3. Capacity and Impact on Interference
	Transmissions at a lower rate require longer occupancy of the		Transmissions at a lower rate require longer occupancy of the
	wireless medium and thus take away from the airtime of other		wireless medium and thus take away from the airtime of other
	communications and degrade the overall capacity. Furthermore,		communications and degrade the overall capacity. Furthermore,
	transmission at higher power, as is required to reach all multicast		transmission at higher power, as is required to reach all multicast
	STAs associated to the AP, proportionately increases the area of		STAs associated to the AP, proportionately increases the area of
	interference.		interference.
	3.1.4. Power-save Effects on Multicast		3.1.4. Power-save Effects on Multicast
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 14 ¶
	o On-demand routing		o On-demand routing
	o Backbone construction		o Backbone construction
	o Other L3 protocols (non-IP)		o 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 multicast protocols		The following list contains some representative discovery protocols
	that are used with IPv4.		that are used with IPv4.
	o ARP		o ARP
	o DHCP		o DHCP
	o mDNS [RFC6762]		o mDNS [RFC6762]
	o uPnP [RFC6970]		o uPnP [RFC6970]
	After initial configuration, ARP and DHCP occur much less commonly,		After initial configuration, ARP and DHCP occur much less commonly,
	but service discovery can occur at any time. Some widely-deployed		but service discovery can occur at any time. Some widely-deployed
	service discovery protocols (e.g., for finding a printer) utilize		service discovery protocols (e.g., for finding a printer) utilize
	mDNS (i.e., multicast). It's often the first service that operators		mDNS (i.e., multicast). It's often the first service that operators
	drop. Even if multicast snooping is utilized, many devices can		drop. Even if multicast snooping 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		o DHCPv6
			o Protocol Independent Multicast (PIM)
	o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]		o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]
	o multicast DNS (mDNS)		o multicast DNS (mDNS)
	o Route Discovery		o Route Discovery
	o Decentralized Address Assignment		o Decentralized Address Assignment
	o Geographic routing		o Geographic routing
	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.
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	4. Multicast protocol optimizations		4. Multicast protocol optimizations
	This section lists some optimizations that have been specified in		This section lists some optimizations that have been specified in
	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 BSS. Proxy ARP is easy to implement at the AP, and		STAs in its basic service set (BSS). Proxy ARP is easy to implement
	offers the following advantages:		at the AP, and offers the following advantages:
	o Reduced broadcast traffic (transmitted at low MCS) on the wireless		o Reduced broadcast traffic (transmitted at low MCS) on the wireless
	medium		medium
	o STA benefits from extended power save in sleep mode, as ARP		o 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.		o ARP frames are kept off the wireless medium.
	o No changes are needed to STA implementation.		o 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]:
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 28 ¶
	The 6lo Working Group has specified an update [RFC8505] to RFC6775.		The 6lo Working Group has specified an update [RFC8505] to RFC6775.
	Wireless devices can register their address to a Backbone Router		Wireless devices can register their address to a Backbone Router
	[I-D.ietf-6lo-backbone-router], which proxies for the registered		[I-D.ietf-6lo-backbone-router], which proxies for the registered
	addresses with the IPv6 NDP running on a high speed aggregating		addresses with the IPv6 NDP running on a high speed aggregating
	backbone. The update also enables a proxy registration mechanism on		backbone. The update also enables a proxy registration mechanism on
	behalf of the registered node, e.g. by a 6LoWPAN router to which the		behalf of the registered node, e.g. by a 6LoWPAN router to which the
	mobile node is attached.		mobile node is attached.
	The general idea behind the backbone router concept is that broadcast		The general idea behind the backbone router concept is that broadcast
	and multicast messaging should be tightly controlled in a variety of		and multicast messaging should be tightly controlled in a variety of
	Wireless Local Area Networks (WLANs) and Wireless Personal Area		WLANs and Wireless Personal Area Networks (WPANs). Connectivity to a
	Networks (WPANs). Connectivity to a particular link that provides		particular link that provides the subnet should be left to Layer-3.
	the subnet should be left to Layer-3. The model for the Backbone		The model for the Backbone Router operation is represented in
	Router operation is represented in Figure 1.		Figure 1.
	|		|
	+-----+		+-----+
	| | Gateway (default) router		| | Gateway (default) router
	| |		| |
	+-----+		+-----+
	|		|
	| Backbone Link		| Backbone Link
	+--------------------+------------------+		+--------------------+------------------+
	| | |		| | |
	skipping to change at page 19, line 15 ¶		skipping to change at page 19, line 15 ¶
	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		o 802.16 WIMAX
	o 3GPP/3GPP2		o 3GPP/3GPP2
	o DVB-H / DVB-IPDC		o DVB-H / DVB-IPDC
	o TV Broadcast and Satellite Networks		o TV Broadcast and Satellite Networks
	7. Recommendations		7. Recommendations
	This section will provide some recommendations about the usage and		This section provides some recommendations about the usage and
	combinations of the multicast enhancements described in Section 4 and		combinations of the multicast enhancements described in Section 4 and
	Section 5.		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.
	Proxy methods should be encouraged to conserve network bandwidth and		Proxy methods should be encouraged to conserve network bandwidth and
	power utilization by low-power devices. The device can use a unicast		power utilization by low-power devices. The device can use a unicast
	message to its proxy, and then the proxy can take care of any needed		message to its proxy, and then the proxy can take care of any needed
	skipping to change at page 19, line 38 ¶		skipping to change at page 19, line 38 ¶
	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. Discussion Items		8. Discussion Items
	This section suggests two discussion items for further resolution.		This section suggests two discussion items for further resolution.
	The IETF should determine guidelines by which it may be decided that		The IETF should determine guidelines by which it may be decided that
	multicast packets are to be sent wired. For example, 802.1ak works		multicast packets are to be sent wired. For example, 802.1ak works
	on ethernet and Wi-Fi. 802.1ak has been pulled into 802.1Q as of		on ethernet and Wi-Fi. 802.1ak has been pulled into 802.1Q as of
	802.1Q-2011. 802.1Q-2014 can be found here:		802.1Q-2011. If a generic solution is not found, guidelines for
	http://www.ieee802.org/1/pages/802.1Q-2014.html. If a generic		multicast over Wi-Fi should be established.
	solution is not found, guidelines for multicast over Wi-Fi should be
	established.
	Reliable registration to Layer-2 multicast groups and a reliable		Reliable registration to Layer-2 multicast groups and a reliable
	multicast operation at Layer-2 might provide a generic solution.		multicast operation at Layer-2 might provide a generic solution.
	There is no need to support 2^24 groups to get solicited node		There is no need to support 2^24 groups to get solicited node
	multicast working: it is possible to simply select a number of		multicast working: it is possible to simply select a number of
	trailing bits that make sense for a given network size to limit the		trailing bits that make sense for a given network size to limit the
	number of unwanted deliveries to reasonable levels. IEEE 802.1,		number of unwanted deliveries to reasonable levels. IEEE 802.1,
	802.11, and 802.15 should be encouraged to revisit L2 multicast		802.11, and 802.15 should be encouraged to revisit L2 multicast
	issues. In reality, Wi-Fi provides a broadcast service, not a		issues. In reality, Wi-Fi provides a broadcast service, not a
	multicast service. On the physical medium, all frames are broadcast		multicast service. On the physical medium, all frames are broadcast
	except in very unusual cases in which special beamforming		except in very unusual cases in which special beamforming
	transmitters are used. Unicast offers the advantage of being much		transmitters are used. Unicast offers the advantage of being much
	faster (2 orders of magnitude) and much more reliable (L2 ARQ).		faster (2 orders of magnitude) and much more reliable (L2 ARQ).
	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 is made more secure in a variety of ways. [RFC4601], for
			instance, mandates the use of IPsec to ensure authentication of the
			link-local messages in the Protocol Independent Multicast - Sparse
			Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms to
			authenticate the PIM-SM link-local messages using the IP security
			(IPsec) Encapsulating Security Payload (ESP) or (optionally) the
			Authentication Header (AH).
	As noted in [group_key], the unreliable nature of multicast		As noted in [group_key], the unreliable nature of multicast
	transmission over wireless media can cause subtle problems with		transmission over wireless media can cause subtle problems with
	multicast group key management and updates. Quoting from that		multicast group key management and updates. When WPA (TKIP) or WPA2
	website, "... most clients are able to get connected and surf the		(AES-CCMP) encryption is in use, AP to client (From DS) multicasts
	web, check email, etc. even when From DS multicasts are broken. So a		have to be encrypted with a separate encryption key that is known to
	lot of people don't realize they have multicast problems on their		all of the clients (this is called the Group Key). Quoting further
	network..."		from that website, "... most clients are able to get connected and
			surf the web, check email, etc. even when From DS multicasts are
			broken. So a lot of people don't realize they have multicast
			problems on their network..."
	10. IANA Considerations		10. IANA Considerations
	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
	skipping to change at page 21, line 30 ¶		skipping to change at page 21, line 34 ¶
	[dot11-proxyarp]		[dot11-proxyarp]
	Hiertz, G., Mestanov, F., and B. Hart, "Proxy ARP in		Hiertz, G., 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,
	<http://standards.ieee.org/findstds/standard/802.11aa-		<https://standards.ieee.org/standard/802_11aa-2012.html>.
	2012.pdf>.
	[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?", Jan 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., and E. Levy-Abegnoli, "IPv6		Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
	Backbone Router", draft-ietf-6lo-backbone-router-13 (work		Backbone Router", draft-ietf-6lo-backbone-router-13 (work
	in progress), September 2019.		in progress), September 2019.
	[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 TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-26 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work
	in progress), August 2019.		in progress), October 2019.
	[I-D.ietf-mboned-driad-amt-discovery]		[I-D.ietf-mboned-driad-amt-discovery]
	Holland, J., "DNS Reverse IP AMT Discovery", draft-ietf-		Holland, J., "DNS Reverse IP AMT Discovery", draft-ietf-
	mboned-driad-amt-discovery-08 (work in progress), June		mboned-driad-amt-discovery-09 (work in progress), October
	2019.		2019.
	[ietf_802-11]		[ietf_802-11]
	Stanley, D., "IEEE 802.11 multicast capabilities", Nov		Stanley, D., "IEEE 802.11 multicast capabilities", Nov
	2015, <https://mentor.ieee.org/802.11/		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.,
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	Discovery for IP Version 6 (IPv6)", RFC 2461,		Discovery for IP Version 6 (IPv6)", RFC 2461,
	DOI 10.17487/RFC2461, December 1998,		DOI 10.17487/RFC2461, December 1998,
	<https://www.rfc-editor.org/info/rfc2461>.		<https://www.rfc-editor.org/info/rfc2461>.
	[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>.
	[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast		[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
	Mobility in Mobile IP Version 6 (MIPv6): Problem Statement		Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
	and Brief Survey", RFC 5757, DOI 10.17487/RFC5757,		and Brief Survey", RFC 5757, DOI 10.17487/RFC5757,
	February 2010, <https://www.rfc-editor.org/info/rfc5757>.		February 2010, <https://www.rfc-editor.org/info/rfc5757>.
			[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
			Confidentiality in Protocol Independent Multicast Sparse
			Mode (PIM-SM) Link-Local Messages", RFC 5796,
			DOI 10.17487/RFC5796, March 2010,
			<https://www.rfc-editor.org/info/rfc5796>.
	[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	DOI 10.17487/RFC6282, September 2011,		DOI 10.17487/RFC6282, September 2011,
	<https://www.rfc-editor.org/info/rfc6282>.		<https://www.rfc-editor.org/info/rfc6282>.
	[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	DOI 10.17487/RFC6762, February 2013,		DOI 10.17487/RFC6762, February 2013,
	<https://www.rfc-editor.org/info/rfc6762>.		<https://www.rfc-editor.org/info/rfc6762>.
	[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service		[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
End of changes. 28 change blocks.
	59 lines changed or deleted		83 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/