<?xml<?xml version="1.0" encoding="UTF-8"?> encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- declare nbsp and friends -->
<!ENTITY nbsp " "> " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑"> "‑">
<!ENTITY wj "⁠"> "⁠">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended updated by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- ?rfc subcompact="no" ? -->
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
<!-- TODO!!
== We could write text for more Recommendations.
== We could more fully describe the IPv6 uses of multicast.
== We could describe more potential multicast applications that might be
enabled with better multicast solutions (if in fact better solutions exist). MS 08/02/21 -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-mboned-ieee802-mcast-problems-15"
ipr="trust200902"> ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3" consensus="true" number="9119">
<!-- xml2rfc v2v3 conversion 3.9.1 -->
<front>
<title abbrev="Multicast Over IEEE 802 Wireless">Multicast Considerations
over IEEE 802 Wireless Media</title>
<seriesInfo name="RFC" value="9119"/>
<author fullname="Charles E. Perkins" initials="C.E." initials="C." surname="Perkins">
<organization abbrev="Blue Meadow Networks">Blue Meadow Networks</organization>
<organization>Lupin Lodge</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
<phone>+1 408 255 9223</phone>
<email>charliep@lupinlodge.com</email>
</address>
</author>
<author fullname="Mike McBride" initials="M." surname="McBride">
<organization abbrev="Futurewei">Futurewei Technologies Inc.</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95055</code>
<region>CA</region>
<country>USA</country>
<country>United States of America</country>
</postal>
<email>michael.mcbride@futurewei.com</email>
</address>
</author>
<author fullname="Dorothy Stanley" initials="D" surname="Stanley">
<organization abbrev="HPE">Hewlett Packard Enterprise</organization>
<address>
<postal>
<street>2000 North Naperville Rd.</street>
<city>Naperville</city>
<code>60566</code>
<region>IL</region>
<country>USA</country>
<street>6280 America Center Dr.</street>
<city>San Jose</city>
<code>95002</code>
<region>CA</region>
<country>United States of America</country>
</postal>
<phone>+1 630 979 1572</phone>
<email>dstanley1389@gmail.com</email> 363 1389</phone>
<email>dorothy.stanley@hpe.com</email>
</address>
</author>
<author fullname="Warren Kumari" initials="W" surname="Kumari">
<organization abbrev="Google">Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<code>94043</code>
<region>CA</region>
<country>USA</country>
<country>United States of America</country>
</postal>
<email>warren@kumari.net</email>
</address>
</author>
<author fullname="Juan Carlos Zuniga" initials="JC" surname="Zuniga">
<organization abbrev="SIGFOX">SIGFOX</organization>
<address>
<postal>
<street>425 rue Jean Rostand</street>
<city>Labege</city>
<code>31670</code>
<region/>
<country>France</country>
<street/>
<city>Montreal</city>
<code/>
<country>Canada</country>
</postal>
<email>j.c.zuniga@ieee.org</email>
</address>
</author>
<date/>
<date year="2021" month="September"/>
<area>Internet</area>
<workgroup>Internet Area</workgroup>
<keyword>Multicast</keyword>
<keyword>Broadcast</keyword>
<keyword>BUM</keyword>
<keyword>wifi</keyword>
<keyword>wireless</keyword>
<keyword>IEEE 802 Wireless Multicast</keyword>
<abstract>
<t>
Well-known issues with multicast have prevented the deployment of
multicast in 802.11 (wifi) (Wi-Fi) and other local-area wireless environments.
<!-- deleted re: Jake Holland, Aug. 10.
IETF multicast experts have been meeting
together to discuss these issues and provide IEEE updates. The
mboned working group is chartered to receive regular reports on the
current state of the deployment of multicast technology, create
"practice and experience" documents that capture the experience of
those who have deployed and are deploying various multicast
technologies, and provide feedback to other relevant working groups.
-->
This document describes the known limitations
of wireless (primarily 802.11) Layer-2 Layer 2 multicast. Also described are certain multicast
enhancement features that have been specified by the IETF, IETF
and by IEEE 802, 802 for wireless media, as well as some operational choices that can be taken made to improve the performance of the network. Finally,
some recommendations are provided about the usage and combination of
these features and operational choices.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction"> numbered="true" toc="default">
<name>Introduction</name>
<t>
Well-known issues with multicast have prevented the deployment of
multicast in 802.11 <xref target="dot11"/> target="dot11" format="default"/> and other local-area
wireless environments, as described in <xref target="mc-props"/>, target="mc-props" format="default"/> and <xref target="mc-prob-stmt"/>. target="mc-prob-stmt" format="default"/>. Performance issues have been observed
when multicast
packet transmissions of IETF protocols are used over IEEE 802 wireless
media. Even though enhancements for multicast transmissions have been
designed at both IETF and IEEE 802, incompatibilities still exist
between specifications, implementations implementations, and configuration choices.
</t>
<t> Many IETF protocols depend on multicast/broadcast for delivery of
control messages to multiple receivers. Multicast allows sending data to be sent to
multiple interested recipients without the source needing to send duplicate
data to each recipient. With broadcast traffic, data is sent to every device
regardless of their expressed interest in the data. Multicast is used for various
purposes such as neighbor discovery, Neighbor Discovery, network flooding, and address
resolution, as well as minimizing media occupancy for the
transmission of data that is intended for multiple receivers.
In addition to protocol use of broadcast/multicast for
control messages, more applications, such as push to talk Push To Talk in
hospitals,
hospitals or video in enterprises, universities, and homes, are
sending multicast IP to end user end-user devices, which are increasingly
using Wi-Fi for their connectivity. </t>
<t> IETF protocols typically rely on network protocol layering in order
to reduce or eliminate any dependence of higher level higher-level protocols on
the specific nature of the MAC layer MAC-layer protocols or the physical media.
In the case of multicast transmissions, higher level higher-level protocols have
traditionally been designed as if transmitting a packet to an IP
address had the same cost in interference and network media access,
regardless of whether the destination IP address is a unicast address
or a multicast or broadcast address. This model was reasonable for
networks where the physical medium was wired, like Ethernet.
Unfortunately, for many wireless media, the costs to access the
medium can be quite different. Multicast over Wi-Fi has often been
plagued by such poor performance that it is disallowed.
Some enhancements have been designed
in IETF protocols that are assumed to work primarily over wireless
media. However, these enhancements are usually implemented in limited
deployments and are not widespread on most wireless networks.</t>
<t> IEEE 802 wireless protocols have been designed with certain features
to support multicast traffic. For instance, lower modulations are
used to transmit multicast frames, frames so that these can be received by
all stations in the cell, regardless of the distance or path
attenuation from the base station or access point. Access Point (AP).
However, these
lower modulation transmissions occupy the medium longer;
they hamper efficient transmission of traffic using
higher order
higher-order modulations to nearby stations.
For these and other reasons, IEEE 802 working groups Working Groups such as 802.11
have designed features to improve the performance of multicast
transmissions at Layer 2 <xref target="ietf_802-11" />. format="default"/>.
In addition to protocol design features, certain operational and
configuration enhancements can ameliorate the network
performance issues created by multicast traffic,
as described in <xref target="optim3" />.</t> format="default"/>.</t>
<t> There seems to be general agreement that these problems will not
be fixed anytime soon, primarily because it's expensive to do so
and due to multicast being unreliable. because of the unreliability of multicast. Compared to unicast over Wi-Fi,
multicast is often treated as somewhat of a second class citizen, second-class citizen even
though there are many protocols using multicast. Something needs to
be provided in order to make them more reliable. IPv6
neighbor discovery
Neighbor Discovery saturating the Wi-Fi link is only part of the
problem. Wi-Fi traffic classes may help. This document is intended
to help make the determination about
what problems should be solved by the IETF and what problems
should be solved by the IEEE (see <xref target="discussion" />).
<!--
A "multicast over wifi" IETF mailing list has been formed
(mcast-wifi@ietf.org) for further discussion. This draft will
be updated according to the current state of discussion.
--> format="default"/>).
</t>
<t> This document details various problems caused by multicast transmission
over wireless networks, including high packet error rates, no
acknowledgements, and low data rate. It also explains some
enhancements that have been designed at the IETF and IEEE 802.11 to ameliorate
the effects of the radio medium on multicast traffic. Recommendations are also provided
to implementors about how to use and combine these enhancements.
Some advice about the operational choices that can be taken made is also
included. It is likely that this document will also be considered
relevant to designers of future IEEE wireless specifications. </t>
</section> <!-- end section "Introduction" -->
<section anchor="def" title="Terminology">
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119" />.</t>
<t>This document also uses some terminology from <xref
target="RFC5444" />.</t>
--> numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the following definitions:
<list style="hanging">
<t hangText="ACK"><vspace/>
</t>
<dl newline="true">
<dt>ACK</dt>
<dd> The 802.11 layer Layer 2 acknowledgement</t>
<t><vspace/></t>
<t hangText="AP"><vspace/> acknowledgement.</dd>
<dt>AES-CCMP</dt><dd>AES-Counter Mode CBC-MAC Protocol</dd>
<dt>AP</dt>
<dd> IEEE 802.11 Access Point</t>
<t><vspace/></t>
<t hangText="basic rate"><vspace/> Point.</dd>
<dt>Basic rate</dt>
<dd> The slowest rate of all the
connected devices, devices at which multicast and broadcast traffic is
generally transmitted</t>
<t><vspace/></t>
<t hangText="DTIM"><vspace/> Delivery transmitted.</dd>
<dt>DVB-H</dt><dd>Digital Video Broadcasting - Handheld</dd>
<dt>DVB-IPDC</dt><dd>Digital Video Broadcasting - Internet Protocol Datacasting</dd>
<dt>DTIM</dt>
<dd>Delivery Traffic Indication Map (DTIM): An Map; an information element that advertises whether or not any associated
stations have buffered multicast or broadcast frames</t>
<t><vspace/></t>
<t hangText="MCS"><vspace/> frames.</dd>
<dt>MCS</dt>
<dd> Modulation and Coding Scheme</t>
<t><vspace/></t>
<t hangText="NOC"><vspace/> Scheme.</dd>
<dt>NOC</dt>
<dd> Network Operations Center</t>
<t><vspace/></t>
<t hangText="PER"><vspace/> Center.</dd>
<dt>PER</dt>
<dd> Packet Error Rate</t>
<t><vspace/></t>
<t hangText="STA"><vspace/> Rate.</dd>
<dt>STA</dt>
<dd> 802.11 station (e.g. (e.g., handheld device)</t>
<t><vspace/></t>
<t hangText="TIM"><vspace/> Traffic device).</dd>
<dt>TIM</dt>
<dd>Traffic Indication Map (TIM): An Map; an
information element that advertises whether or not any associated
stations have buffered unicast frames</t>
<t><vspace/></t>
</list></t>
<!-- <t><vspace blankLines="19" /></t> --> frames.</dd>
<dt>TKIP</dt><dd>Temporal Key Integrity Protocol</dd>
<dt>WiMAX</dt><dd>Worldwide Interoperability for Microwave Access</dd>
<dt>WPA</dt><dd>Wi-Fi Protected Access</dd>
</dl>
</section> <!-- end section "Terminology" -->
<section anchor="multicast_issues" title="Identified multicast issues"> numbered="true" toc="default">
<name>Identified Multicast Issues</name>
<section anchor="l2_issues" title="Issues numbered="true" toc="default">
<name>Issues at Layer 2 and Below"> Below</name>
<t> In this section section, some of the issues related to the use of multicast
transmissions over IEEE 802 wireless technologies are described.</t>
<section anchor="reliability" title="Multicast reliability"> numbered="true" toc="default">
<name>Multicast Reliability</name>
<t> Multicast traffic is typically much less reliable than unicast
traffic. Since multicast makes point-to-multipoint communications,
multiple acknowledgements would be needed to guarantee reception
at all recipients. And However, since there are no ACKs for multicast
packets, it is not possible for the Access Point (AP) AP to
know whether or not a retransmission is needed. Even in the wired
Internet, this characteristic often causes undesirably high error
rates. This has contributed to the relatively slow uptake of
multicast applications even though the protocols have long been
available. The situation for wireless links is much worse, worse and is
quite sensitive to the presence of background traffic.
Consequently, there can be a high packet error rate (PER)
due to lack of retransmission, retransmission and because the sender never backs
off. PER is the ratio, in percent, of the number of packets not successfully
received by the device. It is not uncommon for there to be a packet loss rate of 5%
or more, which is particularly troublesome for video and other
environments where high data rates and high reliability are
required. </t>
</section> <!-- end section "Multicast reliability" -->
<section anchor="lower_rate" title="Lower numbered="true" toc="default">
<name>Lower and Variable Data Rate"> Rate</name>
<t> Multicast over wired differs from multicast over wireless because
transmission over wired links often occurs at
a fixed rate. Wi-Fi, on the other hand, has a transmission rate
that varies depending upon the STA's proximity to the AP.
The throughput of video flows, flows and the capacity of the broader
Wi-Fi network, network will change with device movement. This impacts the ability for QoS
solutions to effectively reserve bandwidth and provide admission
control. </t>
<t> For wireless stations authenticated and linked with an Access Point, AP, the power
necessary for good reception can vary from station to station. For
unicast, the goal is to minimize power requirements while maximizing
the data rate to the destination. For multicast, the goal is simply
to maximize the number of receivers that will correctly receive the
multicast packet; generally generally, the Access Point AP has
to use a much lower data rate at a power level high enough for even
the farthest station to receive the packet, for example example, as briefly
mentioned in section 2 of <xref target="RFC5757"/>. target="RFC5757" sectionFormat="of" section="4"/>. Consequently, the data
rate of a video stream, for instance, would be constrained by the
environmental considerations of the least reliable least-reliable receiver
associated with the Access Point. AP. </t>
<t> Because more robust modulation and coding schemes (MCSs)
have a longer range but also a lower data rate, multicast / broadcast multicast/broadcast
traffic is generally transmitted at the slowest rate of all the
connected devices. This is also known as the basic rate.
The amount of additional interference depends on the
specific wireless technology. In fact, backward compatibility and
multi-stream implementations mean 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 transmission rate between
multicast / broadcast
multicast/broadcast versus optimal unicast forwarding. Some
techniques employed to increase spectral efficiency, such as spatial
multiplexing in MIMO Multiple Input Multiple Output (MIMO) systems, are not available with more than
one intended receiver; it is not the case that backwards
compatibility is the only factor responsible for lower multicast
transmission rates. </t>
<t> Wired multicast also affects wireless LANs when the AP extends
the wired segment; in that case, multicast / broadcast multicast/broadcast frames
on the wired LAN side are copied to the Wireless Local Area Network (WLAN). Since broadcast
messages are transmitted at the most robust MCS,
many large frames are sent at a slow rate over the air. </t>
</section> <!-- end section "Lower Data Rate" -->
<section anchor="interference" title="Capacity numbered="true" toc="default">
<name>Capacity and Impact on Interference"> Interference</name>
<t> Transmissions at a lower
rate require longer occupancy of the wireless medium and thus
take away from the airtime of other communications and
degrade the overall capacity. Furthermore, transmission at higher
power, as is required to reach all multicast STAs associated
to
with the AP, proportionately increases the area of interference with other
consumers of the radio spectrum. </t>
</section> <!-- end section "Capacity and Impact on Interference" -->
<section anchor="power_save" title="Power-save numbered="true" toc="default">
<name>Power-Save Effects on Multicast"> Multicast</name>
<t> One of the characteristics of multicast transmission over wifi Wi-Fi is that every
station has to be configured to wake up to receive the multicast frame,
even though the received packet may ultimately be discarded. This
process can have a large effect on the power consumption by
the multicast receiver station. For this reason reason, there are workarounds,
such as Directed Multicast Service (DMS) described in Section 4, <xref target="optim2"/>, to
prevent unnecessarily waking up stations.</t>
<t> Multicast (and unicast) can work poorly with the power-save mechanisms defined in
IEEE 802.11e, 802.11e for the following reasons.
<list style="symbols">
<t>
</t>
<ul>
<li> Clients may be unable to stay in sleep mode due to
multicast control packets frequently waking them up.</t>
<t> up.</li>
<li> A unicast packet is delayed until an STA wakes up and requests
it. Unicast traffic may also be delayed to improve power
save,
save and efficiency and to increase the probability of aggregation.</t>
<t> aggregation.</li>
<li> Multicast traffic is delayed in a wireless network if any of
the STAs in that network are power savers.
All STAs associated to with the AP have to be
awake at a known time to receive multicast traffic.</t>
<t> traffic.</li>
<li> Packets can also be discarded due to buffer limitations in
the AP and non-AP STA.</t>
</list></t> STA.</li>
</ul>
</section> <!-- end section "Power-save Effects on Multicast" -->
</section> <!-- end section "Issues at Layer 2 and Below" -->
<section anchor="l3_issues" title="Issues numbered="true" toc="default">
<name>Issues at Layer 3 and Above"> Above</name>
<t> This section identifies some representative IETF protocols, protocols and
describes possible negative effects due to performance degradation
when using multicast transmissions for control messages.
Common uses of multicast include:
<list style="symbols">
<t>
</t>
<ul>
<li> Control plane signaling </t>
<t> </li>
<li> Neighbor Discovery </t>
<t> </li>
<li> Address Resolution </t>
<t> resolution </li>
<li> Service Discovery </t>
<t> </li>
<li> Applications (video delivery, stock data, etc.) </t>
<t> </li>
<li> On-demand routing </t>
<t> </li>
<li> Backbone construction </t>
<t> </li>
<li> Other L3 Layer 3 protocols (non-IP) </t>
<!-- CEP: citations needed here, especially for non-IP protocols. -->
</list>
</t> </li>
</ul>
<t>
User Datagram Protocol (UDP) is the most common transport layer transport-layer
protocol for multicast applications.
By itself, UDP is not reliable -- messages may be lost or
delivered out of order.
</t>
<section anchor="IPv4" title="IPv4 issues"> numbered="true" toc="default">
<name>IPv4 Issues</name>
<t> The following list contains some representative
discovery protocols, which utilize broadcast/multicast, protocols that utilize broadcast/multicast and are used with IPv4.
<list style="symbols">
<t>ARP <xref target="RFC0826"/></t>
<t>DHCP <xref target="RFC2131"/></t>
<t>mDNS
</t>
<ul>
<li>ARP <xref target="RFC6762"/></t>
<t>uPnP target="RFC0826" format="default"/></li>
<li>DHCP <xref target="RFC2131" format="default"/></li>
<li>Multicast DNS (mDNS) <xref target="RFC6970"/></t>
</list></t> target="RFC6762" format="default"/></li>
<li>Universal Plug and Play (uPnP) <xref target="RFC6970" format="default"/></li>
</ul>
<t> After initial configuration, ARP (described in more detail later), DHCP DHCP, and uPnP occur much less
commonly, but service discovery can occur at any time. Some
widely-deployed
widely deployed service discovery protocols (e.g., for finding a
printer) utilize mDNS (i.e., multicast) multicast), which is often dropped by operators. Even if multicast
snooping <xref target="RFC4541"/> target="RFC4541" format="default"/> (which provides the benefit of conserving
bandwidth on those segments of the network where no node has expressed interest in receiving
packets addressed to the group address) is utilized, many devices can register at once and cause serious
network degradation.</t>
</section> <!-- end section 'IPv4 uses' -->
<section anchor="IPv6" title="IPv6 issues"> numbered="true" toc="default">
<name>IPv6 Issues</name>
<t> IPv6 makes extensive use of multicast, including the following:
<list style="symbols">
<t>
</t>
<ul>
<li> DHCPv6 <xref target="RFC8415"/></t>
<t> target="RFC8415" format="default"/></li>
<li> Protocol Independent Multicast (PIM) <xref target="RFC7761"/></t>
<t> target="RFC7761" format="default"/></li>
<li> IPv6 Neighbor Discovery Protocol (NDP) <xref target="RFC4861"/></t>
<t> multicast target="RFC4861" format="default"/></li>
<li> Multicast DNS (mDNS) <xref target="RFC6762"/></t>
<t> target="RFC6762" format="default"/></li>
<li> Router Discovery <xref target="RFC4286"/></t>
</list></t> target="RFC4286" format="default"/></li>
</ul>
<t> IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate Address
Detection (DAD) and Address Lookup address lookup make use of Link-Scope link-scope multicast. In
contrast to IPv4, an IPv6 node will typically use multiple
addresses,
addresses and may change them often for privacy reasons. This
intensifies the impact of multicast messages that are associated
to
with the mobility of a node. Router advertisement (RA) messages
are also periodically multicasted multicast over the Link. link.
</t>
<t> Neighbors may be considered lost if several consecutive
Neighbor Discovery packets fail.
</t>
</section> <!-- end section 'IPv6 uses' -->
<section anchor="mld" title="MLD issues"> numbered="true" toc="default">
<name>MLD Issues</name>
<t> Multicast Listener Discovery (MLD) <xref target="RFC4541"/> target="RFC4541" format="default"/> is
used to identify members of a multicast group that are connected to
the ports of a switch. Forwarding multicast frames into a
Wi-Fi-enabled area can use switch support for hardware
forwarding state information. However, since IPv6 makes heavy use
of multicast, each STA with an IPv6 address will require state on
the switch for several and possibly many multicast solicited-node multicast
addresses. A solicited-node multicast address is an IPv6 multicast
address used by NDP to verify whether an IPv6 address is already
used by the local-link. local link. Multicast addresses that do not have forwarding state
installed (perhaps due to hardware memory limitations on the
switch) cause frames to be flooded on all ports of the switch. Some
switch vendors do not support MLD, MLD for link-scope multicast, multicast due to
the increase it can cause in state. </t>
</section> <!-- end section "MLD issues" -->
<section anchor="spurious" title="Spurious numbered="true" toc="default">
<name>Spurious Neighbor Discovery"> Discovery</name>
<t> On the Internet Internet, there is a "background radiation" of scanning
traffic (people scanning for vulnerable machines) and backscatter
(responses from spoofed traffic, etc). etc.). This means that routers
very often receive packets destined for IPv4 addresses regardless of
whether those IP addresses are in use. In the cases where the IP
is assigned to a host, the router broadcasts an ARP request, gets back receives an ARP
reply, and caches it; then then, traffic can be delivered to the host.
When the IP address is not in use, the router broadcasts one (or
more) ARP requests, requests and never gets a reply. This means that it does
not populate the ARP cache, and the next time there is traffic for
that IP address address, the router will rebroadcast the ARP requests.
</t>
<t> The rate of these ARP requests is proportional to the size of the
subnets, the rate of scanning and backscatter, and how long the
router keeps state on non-responding ARPs. As it turns out, this
rate is inversely proportional to how occupied the subnet is
(valid ARPs end up in a cache, stopping the broadcasting; unused
IPs never respond, and so cause more broadcasts). Depending on
the address space in use, the time of day, how occupied the
subnet is, and other unknown factors, thousands of broadcasts per second
have been observed. Around 2,000 broadcasts per second have been observed at
the IETF NOC during face-to-face meetings. </t>
<t> With Neighbor Discovery for IPv6 <xref target="RFC4861"/>, target="RFC4861" format="default"/>, nodes
accomplish address resolution by multicasting a Neighbor Solicitation
that asks the target node to return its link-layer address. Neighbor
Solicitation messages are multicast to the solicited-node multicast
address of the target address. The target returns its link-layer address
in a unicast Neighbor Advertisement message. A single request-response
pair of packets is sufficient for both the initiator and the target to resolve
each other's link-layer addresses; the initiator includes its link-layer
address in the Neighbor Solicitation.</t>
<t> On a wired network, there is not a huge difference between unicast,
multicast
multicast, and broadcast traffic. Due to hardware filtering
(see, e.g., <xref target="Deri-2010" />), format="default"/>), inadvertently flooded
traffic (or excessive ethernet Ethernet multicast) on wired networks
can be quite a bit less costly, costly compared to wireless cases where sleeping
devices have to wake up to process packets. Wired Ethernets tend to be switched
networks, further reducing interference from multicast. There is
effectively no collision / scheduling problem except at extremely
high port utilizations. </t>
<t> This is not true in the wireless realm; wireless equipment is
often unable to send high volumes of broadcast and multicast
traffic, causing numerous broadcast and multicast packets to be
dropped. Consequently, when a host connects connects, it is often not
able to complete DHCP, and IPv6 RAs get dropped, leading to
users being unable to use the network.</t>
</section> <!-- end section "Spurious Neighbor Discovery" -->
</section> <!-- end section "Issues at Layer 3 and Above" -->
</section>
<section anchor="optim2" title="Multicast protocol optimizations"> numbered="true" toc="default">
<name>Multicast Protocol Optimizations</name>
<t> This section lists some optimizations that have been specified in
IEEE 802 and IETF that are aimed at reducing or eliminating the
issues discussed in <xref target="multicast_issues"/>.</t> target="multicast_issues" format="default"/>.</t>
<section anchor="proxy-arp" title="Proxy numbered="true" toc="default">
<name>Proxy ARP in 802.11-2012"> 802.11-2012</name>
<t> The AP knows the MAC Medium Access Control (MAC) address and IP address for all associated
STAs. In this way, the AP acts as the central "manager" for all
the 802.11 STAs in its basic service set Basic Service Set (BSS). Proxy ARP is easy to implement at the
AP,
AP and offers the following advantages:
<list style="symbols">
<t>
</t>
<ul>
<li> Reduced broadcast traffic (transmitted at low MCS) on the
wireless medium</t>
<t> medium.</li>
<li> STA benefits from extended power save in sleep mode, as ARP
requests for STA's IP address are handled instead by the AP.</t>
<t> AP.</li>
<li> ARP frames are kept off the wireless medium.</t>
<t> medium.</li>
<li> No changes are needed to STA implementation.</t>
</list></t> implementation.</li>
</ul>
<t> Here is the specification language as
described in clause 10.23.13 of <xref target="dot11-proxyarp"/>:
<list style="empty">
<t> When target="dot11-proxyarp" format="default"/>:
</t>
<blockquote><t>When the AP supports Proxy ARP "[...] the AP shall maintain a
Hardware Address to Internet Address mapping for each
associated station, and shall update the mapping when the
Internet Address of the associated station changes. When the
IPv4 address being resolved in the ARP request packet is used
by a non-AP STA currently associated to the BSS, the proxy ARP
service shall respond on behalf of the non-AP STA".</t>
</list></t>
</section> <!-- end section "Proxy STA to an ARP in 802.11-2012" --> request or an ARP Probe.
</t></blockquote>
</section>
<section anchor="proxy-ND"
title="IPv6 numbered="true" toc="default">
<name>IPv6 Address Registration and Proxy Neighbor Discovery"> Discovery</name>
<t>
As used in this section,
a Low-Power Wireless Personal Area Network (6LoWPAN) denotes a low
power lossy network Low-Power and Lossy Network (LLN) that supports
<xref target="RFC6282"> target="RFC6282" format="default"> 6LoWPAN Header Compression (HC)</xref>.
A <xref target="I-D.ietf-6tisch-architecture">6TiSCH target="RFC9030" format="default">6TiSCH network</xref>
is an example of a 6LowPAN. 6LoWPAN.
In order to control the use of IPv6 multicast over 6LoWPANs, the
<xref target="RFC6775">6LoWPAN target="RFC6775" format="default">6LoWPAN Neighbor Discovery (6LoWPAN ND)</xref>
standard defines an address registration mechanism that relies on a
central registry to assess address uniqueness, uniqueness as a substitute to the
inefficient DAD mechanism found in the mainstream IPv6 Neighbor Discovery Protocol (NDP)
<xref target="RFC4861"/><xref target="RFC4862"/>. target="RFC4861" format="default"/> <xref target="RFC4862" format="default"/>.
</t>
<t>
The 6lo Working Group has specified an
<xref target="RFC8505">update</xref> target="RFC8505" format="none">update</xref> to RFC6775. <xref target="RFC6775"/>.
Wireless devices can register their address to a
<xref target="I-D.ietf-6lo-backbone-router">Backbone target="RFC8929" format="default">Backbone Router</xref>,
which proxies for the registered addresses with the IPv6
NDP running on a high speed high-speed aggregating backbone. The update also
enables a proxy registration mechanism on behalf of the registered
node, e.g. Registered
Node, e.g., by a 6LoWPAN router to which the mobile node is attached.
</t>
<t>
The general idea behind the backbone router Backbone Router concept is that broadcast
and multicast messaging should be tightly controlled in a variety
of WLANs and Wireless Personal Area
Networks (WPANs).
Connectivity to a particular link that provides the subnet should
be left to Layer-3. Layer 3. The model for the Backbone Router operation is
represented in <xref target='figBackbone'/>. target="figBackbone" format="default"/>.
</t>
<figure anchor='figBackbone' title="Backbone anchor="figBackbone">
<name>Backbone Link and Backbone Routers">
<artwork><![CDATA[ Routers</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|
+-----+
| | Gateway (default) router
| |
+-----+
|
| Backbone Link
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
| | 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
LLN 1 LLN 2 LLN 3
]]></artwork>
</figure>
<t>
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 backbone,
keeping any of the IPv6 addresses they have configured.
The Backbone Routers maintain a Binding Table of their
Registered Nodes, which serves as a distributed database of all the LLN
Nodes.
nodes. An extension to the Neighbor Discovery Protocol is introduced to
exchange Binding Table information across the Backbone Link as needed
for the operation of IPv6 Neighbor Discovery.
</t>
<t>
RFC6775
<xref target="RFC6775"/> and follow-on work <xref target="RFC8505"/> target="RFC8505" format="default"/>
address the needs of LLNs, and similar techniques are likely to be
valuable on any type of
link where sleeping devices are attached, attached or where the use of
broadcast and multicast operations should be limited. </t>
</section>
<section anchor="buffer" title="Buffering numbered="true" toc="default">
<name>Buffering to Improve Battery Life"> Life</name>
<t> Methods have been developed to help save battery life; for example,
a device might not wake up when the AP receives a multicast packet.
The AP acts on behalf of STAs in various ways. To enable use of
the power-saving feature for STAs in its BSS, the AP buffers frames
for delivery to the STA at the time when the STA is scheduled for
reception. If an AP, for instance, expresses a DTIM (Delivery Delivery Traffic
Indication Message) Message (DTIM) of 3 3, then
the AP will send a multicast packet every 3 packets. In fact,
when any single wireless STA associated with an access point AP has
802.11 power-save mode enabled, the access point AP buffers all multicast
frames and sends them only after the next DTIM beacon. </t>
<t> In practice, most AP's APs will send a multicast every 30 packets.
For unicast unicast, the AP could send a TIM (Traffic Traffic Indication Message),
but Message (TIM),
but, for multicast multicast, the AP sends a broadcast to everyone. DTIM does
power management management, but STAs can choose whether or not to wake up
and whether or not to drop the packet. Unfortunately, without proper administrative
control, such STAs may be unable to determine why their
multicast operations do not work. </t>
</section> <!-- end of section 'Buffering to improve Power-Save' -->
<section title="Limiting multicast buffer hardware queue depth"> numbered="true" toc="default">
<name>Limiting Multicast Buffer Hardware Queue Depth</name>
<t>The CAB (Content Content after Beacon) Beacon (CAB) queue is used for beacon-triggered
transmission of buffered multicast frames. If lots of multicast frames were
buffered,
buffered and this queue fills up, it drowns out all regular traffic. To limit the
damage that buffered traffic can do, some drivers limit the amount of
queued multicast data to a fraction of the beacon_interval. An example of
this is <xref target="CAB" />. format="default"/>. </t>
</section>
<section anchor="ipv6" title="IPv6 support numbered="true" toc="default">
<name>IPv6 Support in 802.11-2012"> 802.11-2012</name>
<t> IPv6 uses NDP instead of ARP. Every IPv6 node subscribes to a special
multicast address for this purpose.
</t>
<t> Here is the specification language from clause 10.23.13
of <xref target="dot11-proxyarp"/>:
<list style="empty">
<t>"When target="dot11-proxyarp" format="default"/>:
</t>
<blockquote>
<t>When an IPv6 address is being resolved, the Proxy Neighbor
Discovery service shall respond with a Neighbor Advertisement
message [...] on behalf of an associated STA to an [ICMPv6]
Neighbor Solicitation message [...]. When MAC address mappings
change, the AP may send unsolicited Neighbor Advertisement
Messages on behalf of a STA."</t>
</list></t> STA.</t>
</blockquote>
<t>NDP may be used to request additional information
<list style="symbols">
<t>Maximum using the following methods, among others:
</t>
<ul>
<li>Maximum Transmission Unit</t>
<t>Router Solicitation</t>
<t>Router Advertisement, etc.</t>
</list> Unit</li>
<li>Router Solicitation</li>
<li>Router Advertisement</li>
</ul>
<t>
NDP messages are sent as group addressed group-addressed (broadcast) frames
in 802.11. Using the proxy operation helps to keep NDP messages off
the wireless medium.</t>
</section> <!-- end of section 'IPv6 support in 802.11-2012' -->
<section anchor="convert" title="Using numbered="true" toc="default">
<name>Using Unicast Instead of Multicast"> Multicast</name>
<t> It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually.</t>
<section anchor="convert-over" title="Overview"> numbered="true" toc="default">
<name>Overview</name>
<t>
In many situations, it's a good choice to use unicast instead of
multicast over the Wi-Fi link. This avoids most of the
problems specific to multicast over Wi-Fi, since the individual
frames are then acknowledged and buffered for power save clients, power-save clients
in the way that unicast traffic normally operates.
</t>
<t>
This approach comes with the tradeoff trade-off of sometimes sending
the same packet multiple times over the Wi-Fi link. However,
in many cases, such as video into a residential home network,
this can be a good tradeoff, trade-off since the Wi-Fi link may have enough
capacity for the unicast traffic to be transmitted to each
subscribed STA, even though multicast addressing may have been
necessary for the upstream access network.
</t>
<t>
Several technologies exist that can be used to arrange unicast
transport over the Wi-Fi link, outlined in the subsections below.
</t>
</section> <!-- end of section 'Overview' -->
<section anchor="convert-l2"
title="Layer numbered="true" toc="default">
<name>Layer 2 Conversion to Unicast"> Unicast</name>
<t>
It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually.
</t>
<t>
Although there is not yet a standardized method of conversion, at
least one widely available implementation exists in the Linux
bridging code <xref target="bridge-mc-2-uc"/>. target="bridge-mc-2-uc" format="default"/>. Other proprietary
implementations are available from various vendors.
In general, these implementations perform a straightforward
mapping for groups or channels, discovered by IGMP or MLD
snooping, to the corresponding unicast MAC addresses.
</t>
</section> <!-- end of section 'Layer 2 Conversion to Unicast' -->
<section anchor="convert-DMS" title="Directed numbered="true" toc="default">
<name>Directed Multicast Service (DMS)"> (DMS)</name>
<t>
There are situations where more is needed than simply converting
multicast to unicast. <!-- Editor's note: citation needed -->
For these purposes,
DMS enables an STA to request that the AP
transmit multicast group addressed group-addressed frames destined to the
requesting STAs as individually addressed frames [i.e., (i.e., convert
multicast to unicast]. unicast). Here are some characteristics of DMS:
<list style="symbols">
<t>
</t>
<ul>
<li> Requires 802.11n A-MSDUs</t>
<t> Aggregate MAC Service Data Units (A-MSDUs).</li>
<li> Individually addressed frames are acknowledged and are
buffered for power save STAs</t>
<t> power-save STAs.</li>
<li> The requesting STA may specify traffic characteristics for
DMS traffic</t>
<t> traffic.</li>
<li> DMS was defined in IEEE Std 802.11v-2011</t>
<t> 802.11v-2011 <xref target="v2011"/>.</li>
<li> DMS requires changes to both AP and STA implementation.</t>
</list> implementation.</li>
</ul>
<t>
DMS is not currently implemented in products.
See <xref target="Tramarin2017"/> target="Tramarin2017" format="default"/> and <xref target="Oliva2013"/> target="Oliva2013" format="default"/>
for more information. </t>
</section> <!-- end of section 'Directed Multicast Service (DMS)' -->
<section anchor="convert-amt"
title="Automatic numbered="true" toc="default">
<name>Automatic Multicast Tunneling (AMT)"> (AMT)</name>
<t>
AMT<xref target="RFC7450"/>
AMT <xref target="RFC7450" format="default"/> provides a method to tunnel multicast
IP packets inside unicast IP packets over network links that only
support unicast. When an operating system or application running
on an STA has an AMT 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 portion of the network connected to the AP.
</t>
<t>
It is recommended that multicast-enabled networks deploying AMT
relays for this purpose make the relays locally discoverable with
the following methods, as described in
<xref target="I-D.ietf-mboned-driad-amt-discovery"/>:
<list style="symbols">
<t> DNS-SD target="RFC8777" format="default"/>:
</t>
<ul>
<li>DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"/></t>
<t> the target="RFC6763" format="default"/></li>
<li>The well-known IP addresses from Section 7 of <xref target="RFC7450"/></t>
</list>
</t> target="RFC7450" sectionFormat="of" section="7"/></li>
</ul>
<t>
An AMT gateway that implements multiple standard discovery methods
is more likely to discover the local multicast-capable network, network
instead of forming a connection to a non-local nonlocal AMT relay further upstream.
</t>
</section> <!-- end of section 'Automatic Multicast Tunneling (AMT)'-->
</section> <!-- end of section 'Using Unicast Instead of Multicast' -->
<section anchor="GCR" title="GroupCast numbered="true" toc="default">
<name>GroupCast with Retries (GCR)"> (GCR)</name>
<t> GCR (defined in <xref target="dot11aa"/>) target="dot11aa" format="default"/>) provides greater
reliability by using either unsolicited retries or a block
acknowledgement mechanism. GCR increases the probability of broadcast
frame reception success, success but still does not guarantee success.</t>
<t> For the block acknowledgement mechanism, the AP transmits each
group addressed
group-addressed frame as a conventional group addressed group-addressed transmission.
Retransmissions are group addressed, addressed but hidden from non-11aa STAs.
A directed block acknowledgement scheme is used to harvest reception
status from receivers; retransmissions are based upon these
responses.</t>
<t> 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 acknowledgement requests to only a small subset of the group.
GCR does require changes to both AP and STA implementations.</t>
<t> GCR may introduce unacceptable latency. After sending a group of
data frames to the group, the AP has to do the following:
<list style="symbols">
<t>unicast
</t>
<ul>
<li>Unicast a Block Ack Request (BAR) to a subset of members.</t>
<t>wait members.</li>
<li>Wait for the corresponding Block Ack (BA).</t>
<t>retransmit (BA).</li>
<li>Retransmit any missed frames.</t>
<t>resume frames.</li>
<li>Resume other operations that may have been delayed.</t>
</list> delayed.</li>
</ul>
<t> This latency may not be acceptable for some traffic.</t>
<t> There are ongoing extensions in 802.11 to improve GCR performance.
<list style="symbols">
<t>
</t>
<ul>
<li> BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO
is already specified in 802.11-REVmc 4.3).</t>
<t> Multi-User MIMO.</li>
<li> BA is sent using uplink MU-MIMO (which (uplink MU-MIMO is a .11ax feature).</t>
<t> Additional 802.11ax extensions are under consideration; see
<xref target="mc-ack-mux"/></t>
<t> an IEEE 801.11ax-2021 feature).</li>
<li> Latency may also be reduced by simultaneously receiving BA
information from multiple STAs.</t>
</list></t> STAs.</li>
</ul>
</section>
</section>
<section anchor="optim3" title="Operational optimizations"> numbered="true" toc="default">
<name>Operational Optimizations</name>
<t> This section lists some operational optimizations that can be
implemented when deploying wireless IEEE 802 networks to mitigate
some of the issues discussed in <xref target="multicast_issues"/>.</t>
<!-- Jake Holland:
Is it worth adding here use cases that are considered probably useful, but
not currently done with multicast over Wi-Fi, in part because of these
concerns? (e.g. apps providing instant replays in a stadium IIUC currently
use unicast, but could theoretically share a lot of bandwidth)
--> target="multicast_issues" format="default"/>.</t>
<section anchor="mitigate-spurious"
title="Mitigating numbered="true" toc="default">
<name>Mitigating Problems from Spurious Neighbor Discovery"> Discovery</name>
<dl newline="true" indent="6">
<dt>ARP Sponges</dt>
<dd>
<t> <list hangIndent="6" style="hanging">
<t hangText="ARP Sponges"><vspace blankLines="1"/> An ARP Sponge
sits on a network and learns which IP addresses are actually in
use. It also listens for ARP requests, and, if it sees an ARP for
an IP address that it believes is not used, it will reply with
its own MAC address. This means that the router now has an IP to
MAC IP-to-MAC mapping, which it caches. If that IP is later assigned to a
machine (e.g (e.g., using DHCP), the ARP sponge Sponge will see this, this and will
stop replying for that address. Gratuitous ARPs (or the machine
ARPing for its gateway) will replace the sponged address in the
router ARP table. This technique is quite effective; but, unfortunately, the ARP sponge Sponge daemons were not really designed for
this use (one of the most widely deployed arp sponges ARP Sponges
<xref target="arpsponge"/>, target="arpsponge" format="default"/> was
designed to deal with the disappearance of participants from an
IXP)
Internet Exchange Point (IXP)) and so are not optimized for this purpose.
One daemon is
needed per subnet, subnet; the tuning is tricky (the scanning rate versus
the population rate versus retires, etc.) retries, etc.), and sometimes daemons just stop,
requiring a restart of the daemon which that causes disruption. <vspace blankLines="1"/></t>
<t hangText="Router mitigations"><vspace blankLines="1"/> </t>
</dd>
<dt>Router mitigations</dt>
<dd>
<t> Some
routers (often those based on Linux) implement a "negative ARP
cache" daemon. If the router does not see a reply to
an ARP ARP, it can be configured to cache this information for some
interval. Unfortunately, the core routers in use often do
not support this. Instead, when a host connects to a network and gets an IP
address, it will ARP for its default gateway (the router). The
router will update its cache with the IP to host MAC mapping
learned from the request (passive ARP learning). <vspace
blankLines="1"/></t>
<t hangText="Firewall </t>
</dd>
<dt>Firewall unused space"><vspace blankLines="1"/> space</dt>
<dd>
<t> The
distribution of users on wireless networks / subnets may change in various
use cases, such as conference venues (e.g SSIDs (e.g., Service Set Identifiers (SSIDs) are renamed, some SSIDs
lose favor, etc). etc.). This makes utilization for particular SSIDs
difficult to predict ahead of time, but usage can be monitored
as attendees use the different networks. Configuring multiple
DHCP pools per subnet, subnet and enabling them sequentially, sequentially can create
a large subnet, subnet from which only addresses in the lower portions
are assigned. Therefore Therefore, input IP access lists can be applied,
which deny traffic to the upper, unused portions. Then the
router does not attempt to forward packets to the unused portions
of the subnets, subnets and so does not ARP for it. This method has proven
to be very effective, effective but is somewhat of a blunt axe, is fairly
labor intensive, and requires coordination. <vspace
blankLines="1"/></t>
<t hangText="Disabling/filtering </t>
</dd>
<dt>Disabling/Filtering ARP requests"><vspace
blankLines="1"/> requests</dt>
<dd>
<t> In general, the router does not need to ARP for
hosts; when a host connects, the router can learn the IP to MAC IP-to-MAC
mapping from the ARP request sent by that host. Consequently Consequently, it
should be possible to disable and / or and/or filter ARP requests from the
router. Unfortunately, ARP is a very low level / fundamental low-level/fundamental part
of the IP stack, stack and is often offloaded from the normal control
plane. While many routers can filter layer-2 Layer 2 traffic, this is
usually implemented as an input filter and / or and/or has limited
ability to filter output broadcast traffic.
This means that the seemingly simple and obvious solution to "just disable ARP or filter it outbound" seems like a
really simple (and obvious) solution, but implementations /
architectural issues make this is made difficult or awkward in practice.
<vspace blankLines="1"/></t>
<t hangText="NAT"><vspace blankLines="1"/> practice by implementations and/or architectural issues.
</t>
</dd>
<dt>NAT</dt>
<dd>
<t> Broadcasts can often be
caused by outside wifi Wi-Fi scanning / backscatter traffic. In order to reduce the impact of
broadcasts, NAT can be used on the entire (or a large portion) of a network. This would
eliminate NAT translation entries for unused addresses, and the router would never ARP
for them. There are, however, many reasons to avoid using NAT in such a blanket fashion.
<vspace blankLines="1"/></t>
<t hangText="Stateful firewalls"><vspace blankLines="1"/>
</t>
</dd>
<dt>Stateful firewalls</dt>
<dd> Another
obvious solution would be to put a stateful firewall between the
wireless network and the Internet. This firewall would block
incoming traffic not associated with an outbound request.
But this conflicts with the need and desire of some
organizations to have the network as open as possible and to
honor the end-to-end principle. An attendee on a meeting network
should be an Internet host, host and should be able to receive
unsolicited requests. Unfortunately, keeping the network working
and stable is the first priority priority, and a stateful firewall may be
required in order to achieve this.</t>
</list></t>
</section><!--'Mitigating Problems from Spurious Neighbor Discovery'--> this.</dd>
</dl>
</section>
<section anchor="mitigate-spurious-sd"
title="Mitigating numbered="true" toc="default">
<name>Mitigating Spurious Service Discovery Messages"> Messages</name>
<t>
In networks that must support hundreds of STAs, operators have
observed network degradation due to many devices simultaneously
registering with mDNS. In a network with many clients, it is
recommended to ensure that mDNS packets designed to discover
services in smaller home networks be constrained to avoid
disrupting other traffic.
</t>
</section> <!-- 'Mitigating Spurious Service Discovery Messages' -->
</section> <!-- end section 'Layer 3 optimizations' -->
<section anchor="other-media"
title="Multicast numbered="true" toc="default">
<name>Multicast Considerations for Other Wireless Media"> Media</name>
<t> Many of the causes of performance degradation described in earlier
sections are also observable for wireless media other than 802.11.</t>
<t> For instance, problems with power save, excess media occupancy, and
poor reliability will also affect 802.15.3 and 802.15.4. Unfortunately,
802.15 media specifications do not yet include mechanisms similar to
those developed for 802.11. In fact, the design philosophy for 802.15
is oriented towards minimality, with the result that many such
functions are relegated to operation within higher layer higher-layer protocols.
This leads to a patchwork of non-interoperable and vendor-specific
solutions. See <xref target="uli"/> target="uli" format="default"/> for some additional discussion, discussion
and a proposal for a task group to resolve similar issues, in which
the multicast problems might be considered for mitigation. </t>
<t> Similar considerations hold for most other wireless media. A brief
introduction is provided in <xref target="RFC5757"/> target="RFC5757" format="default"/> for the following:
<list style="symbols">
<t> 802.16 WIMAX
</t>
<t>
<ul>
<li> 802.16 WiMAX </li>
<li> 3GPP/3GPP2 </t>
<t> DVB-H / DVB-IPDC </t>
<t> </li>
<li> DVB-H/DVB-IPDC </li>
<li> TV Broadcast and Satellite Networks </t>
</list></t> </li>
</ul>
</section> <!-- 'Multicast Considerations for Other Wireless Media' -->
<!-- CEP: More recommendations are needed. -->
<section anchor="recommendations" title="Recommendations"> numbered="true" toc="default">
<name>Recommendations</name>
<t> This section provides some recommendations about the usage and
combinations of some of the multicast enhancements described in Sections
<xref target="optim2"/> target="optim2" format="counter"/> and <xref target="optim3"/>.</t> target="optim3" format="counter"/>.</t>
<t> Future protocol documents utilizing multicast signaling should
be carefully scrutinized if the protocol is likely to be used over
wireless media. </t>
<t> The use of proxy methods should be encouraged to conserve network bandwidth
and power utilization by low-power devices.
The device can use send a unicast message to its proxy, and then the proxy can take care
of any needed multicast operations. </t>
<t> Multicast signaling for wireless devices should be done in a way that is
compatible with low duty-cycle operation. </t>
</section>
<section anchor="discussion" title="On-going numbered="true" toc="default">
<name>Ongoing Discussion Items"> Items</name>
<t> This section suggests two discussion items for further resolution. </t>
<t> First, standards (and private) organizations should develop guidelines to help clarify when
multicast packets would be better served by being sent wired rather than wireless.
For example,
<eref target="https://www.ieee802.org/1/pages/802.1ak.html">802.1ak</eref> 802.1ak <xref target="IEEE802.1ak"/> works on
both ethernet Ethernet and Wi-Fi Wi-Fi, and organizations could help with deployment decision making
by developing guidelines for multicast over Wi-Fi Wi-Fi, including options for when traffic should be sent wired.
</t>
<t>
Second, reliable registration to Layer-2 Layer 2 multicast groups, groups and a reliable
multicast operation at Layer-2, Layer 2 might provide a good multicast over wifi Wi-Fi solution.
There shouldn't be a need to support 2^24 2<sup>24</sup> groups to get solicited node
multicast working: it is possible 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.
The IEEE 802.1,
802.11, and 802.15 Working Groups should be encouraged to revisit L2 Layer 2 multicast issues and provide
workable solutions.
</t>
</section>
<section anchor="sec" title="Security Considerations"> numbered="true" toc="default">
<name>Security Considerations</name>
<t>
This document does not introduce or modify any security mechanisms.
Multicast deployed on wired or wireless networks as discussed in this document can be
made more secure in a variety of ways.
<xref target="RFC4601"/>, target="RFC4601" format="default"/>, for instance,
specifies the use of IPsec to ensure authentication of the link-local messages
in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol.
<xref target="RFC5796"/>specifies target="RFC5796" format="default"/> 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).
</t>
<t>When using mechanisms that convert multicast traffic to unicast traffic for traversing radio links,
the AP (or other entity) is forced to explicitly track which subscribers care about certain multicast traffic.
This is generally a reasonable tradeoff, trade-off but does result in another entity that is tracking what entities
subscribe to which multicast traffic. While such information is already (by necessity) tracked elsewhere,
this does present an expansion of the attack surface for that potentially privacy-sensitive information.</t>
<t>
As noted in <xref target="group_key"/>, target="group_key" format="default"/>, the unreliable nature of
multicast transmission over wireless media can cause subtle problems
with multicast group key management and updates. When WPA (TKIP)
<xref target="group_key"/> states that when TKIP (WPA, now deprecated) or WPA2 (AES-CCMP) AES-CCMP (WPA2/WPA3) encryption is in use, AP to client (From DS) AP-to-client (FromDS) multicasts have to be encrypted with a separate encryption key that
is known to all of the clients (this is called the Group Key). Quoting further from that
website, "... most clients are able to get connected and surf the web,
check email, etc. even when From DS FromDS multicasts are broken. So a lot of
people don't realize they have multicast problems on their network..."
</t>
<t>This document encourages the use of proxy methods to conserve network bandwidth and
power utilization by low-power devices. Such proxy methods in general have security considerations that
require the proxy to be trusted to not misbehave. One such proxy method listed is an Arp ARP Sponge which that listens for ARP requests, and, if it sees an ARP for an IP address that it believes is not used, it will reply
with its own MAC address. ARP poisoning and false advertising could potentially undermine (e.g. (e.g., DoS)
this,
this and other, other proxy approaches.</t>
</section>
<section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
<name>IANA Considerations</name>
<t> This document does not request any has no IANA actions.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>
This document has benefitted from discussions with the following
people, in alphabetical order:
Mikael Abrahamsson,
Bill Atwood,
Stuart Cheshire,
Donald Eastlake,
Toerless Eckert,
Jake Holland,
Joel Jaeggli,
Jan Komissar,
David Lamparter,
Morten Pedersen,
Pascal Thubert,
Jeffrey (Zhaohui) Zhang
</t>
</section>
</middle>
<back>
<references title="Informative References">
<!-- <?rfc include='reference.RFC.2119.xml'?> -->
<?rfc include='reference.I-D.ietf-6tisch-architecture.xml'?>
<?rfc include='reference.I-D.ietf-6lo-backbone-router.xml'?>
<?rfc include='reference.I-D.ietf-mboned-driad-amt-discovery.xml'?>
<?rfc include='reference.RFC.0826.xml'?>
<?rfc include='reference.RFC.5424.xml'?>
<?rfc include='reference.RFC.2131.xml'?>
<?rfc include='reference.RFC.4861.xml'?>
<?rfc include='reference.RFC.4286.xml'?>
<?rfc include='reference.RFC.4541.xml'?>
<?rfc include='reference.RFC.4601.xml'?>
<?rfc include='reference.RFC.7761.xml'?>
<?rfc include='reference.RFC.4862.xml'?>
<?rfc include='reference.RFC.5757.xml'?>
<?rfc include='reference.RFC.5796.xml'?>
<?rfc include='reference.RFC.6282.xml'?>
<?rfc include='reference.RFC.6762.xml'?>
<?rfc include='reference.RFC.6763.xml'?>
<?rfc include='reference.RFC.6775.xml'?>
<?rfc include='reference.RFC.6970.xml'?>
<?rfc include='reference.RFC.7450.xml'?>
<?rfc include='reference.RFC.8505.xml'?>
<?rfc include='reference.RFC.8415.xml'?>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4286.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4601.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5757.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5796.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6970.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7450.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8777.xml"/>
<reference anchor="v2011" target="https://ieeexplore.ieee.org/document/5716530">
<front>
<title>Information technology -- Local and metropolitan area networks -- Specific requirements -- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: IEEE 802.11 Wireless Network Management</title>
<author>
<organization>IEEE</organization>
</author>
<date month="February" year="2011"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5716530"/>
<seriesInfo name="IEEE Std" value="802.11v-2011"/>
</reference>
<reference anchor="IEEE802.1ak" target="https://www.ieee802.org/1/pages/802.1ak.html">
<front>
<title>Local and Metropolitan Area Networks Virtual Bridged Local Area Networks - Amendment 07: Multiple Registration Protocol</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" year="2007"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2007.380667"/>
<seriesInfo name="IEEE Std" value="802.1ak-2007 "/>
</reference>
<reference anchor="uli" target='https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx'> target="https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx">
<front>
<title>LLC Proposal for 802.15.4</title>
<author fullname="Pat Kinney">
<organization>"IEEE 802 Wireless"</organization>
<address>
</address> Kinney" initials="P." surname="Kinney">
</author>
<date month="Nov" month="September" year="2015"/>
</front>
</reference>
<reference anchor="ietf_802-11" target='https://mentor.ieee.org/802.11/dcn/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-ietf-nov-2015.ppt'> target="https://mentor.ieee.org/802.11/dcn/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-ietf-nov-2015.ppt">
<front>
<title>IEEE 802.11 multicast capabilities</title>
<!-- author
<author fullname="Dorothy Stanley" initials="D" surname="Stanley" -->
<author fullname="Dorothy Stanley">
<organization>"IEEE 802 Wireless"</organization>
<address>
</address>
</author> initials="D." surname="Stanley"/>
<date month="Nov" year="2015"/>
</front>
</reference>
<reference anchor="mc-ack-mux" target='https://mentor.ieee.org/802.11/dcn/15/11-15-0800-00-00ax-multiplexing-of-acknowledgements-for-multicast-transmission.pptx'>
<front>
<title>Multiplexing of Acknowledgements for Multicast
Transmission</title>
<author fullname="Yusuke Tanaka">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Eisuke Sakai">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Yuichi Morioka">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Masahito Mori">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Guido Hiertz">
<organization>"IEEE 802 Wireless, Ericsson"</organization>
<address>
</address>
</author>
<author fullname="Sean Coffey">
<organization>"IEEE 802 Wireless, Realtek"</organization>
<address>
</address>
</author>
<date month="July" month="November" year="2015"/>
</front>
</reference>
<reference anchor="dot11"
target='http://standards.ieee.org/findstds/standard/802.11-2016.html'> target="https://standards.ieee.org/standard/802_11-2020.html">
<front>
<title>802.11-2016 - IEEE Standard for Information technology--Telecommunications
<title>Information Technology--Telecommunications and information exchange Information Exchange between systems Systems - Local and metropolitan area networks--Specific requirements Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification Specifications (includes 802.11v amendment)</title>
<author surname="P802.11">
<organization>"IEEE 802 Wireless"</organization>
<address>
</address>
<author>
<organization>IEEE</organization>
</author>
<date month="March" year="2016"/> month="December" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
<seriesInfo name="IEEE Std" value="802.11-2020"/>
</reference>
<reference anchor="mc-props" target='https://mentor.ieee.org/802.11/dcn/15/11-15-1161-02-0arc-802-11-multicast-properties.ppt'> target="https://mentor.ieee.org/802.11/dcn/15/11-15-1161-02-0arc-802-11-multicast-properties.ppt">
<front>
<title>IEEE 802.11 multicast properties</title>
<author fullname="Adrian Stephens">
<organization>"IEEE 802 Wireless"</organization>
<address>
</address>
<organization>Intel Corporation</organization>
</author>
<date month="March" month="September" year="2015"/>
</front>
</reference>
<reference anchor="bridge-mc-2-uc" target='https://github.com/torvalds/linux/commit/6db6f0eae6052b70885562e1733896647ec1d807'> target="https://github.com/torvalds/linux/commit/6db6f0e">
<front>
<title>bridge: multicast to unicast</title>
<author fullname="Felix Fietkau">
<organization>"Linux"</organization>
<address>
</address>
</author>
<author/>
<date month="Jan" month="January" year="2017"/>
</front>
<refcontent>commit 6db6f0e</refcontent>
</reference>
<reference anchor="arpsponge"
target='http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692'> target="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692">
<front>
<title>Effects of IPv4 and IPv6 address resolution on AMS-IX and
the ARP Sponge</title>
<author fullname="Marco Wessel">
<organization>"Universiteit van Amsterdam"</organization>
<address>
</address>
</author>
<author fullname="Niels Sijm">
<organization>"Universiteit van Amsterdam"</organization>
<address>
</address>
</author>
<date month="July" year="2009"/>
</front>
</reference>
<reference anchor="dot11-proxyarp" target='https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx'> target="https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx">
<front>
<title>Proxy ARP in 802.11ax</title>
<author fullname="Guido R. Hiertz" initials="G. R." surname="Hiertz">
<organization>"IEEE 802 Wireless P802.11"</organization>
<address>
</address>
</author> initials="G." surname="Hiertz"/>
<author fullname="Filip Mestanov" initials="F." surname="Mestanov">
<organization>"IEEE 802 Wireless P802.11"</organization>
<address>
</address>
</author> surname="Mestanov"/>
<author fullname="Brian Hart" initials="B." surname="Hart">
<organization>"IEEE 802 Wireless P802.11"</organization>
<address>
</address>
</author> surname="Hart"/>
<date month="September" year="2015"/>
</front>
</reference>
<reference anchor="dot11aa"
target='https://standards.ieee.org/standard/802_11aa-2012.html'> target="https://standards.ieee.org/standard/802_11aa-2012.html">
<front>
<title>Part
<title>Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming</title>
<author surname="P802.11">
<organization>"IEEE 802 Wireless"</organization>
<address>
</address>
</author>
<author>
<organization>IEEE</organization></author>
<date month="March" year="2012"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6204193"/>
<seriesInfo name="IEEE Std" value="802.11aa-2012"/>
</reference>
<reference anchor="mc-prob-stmt" target='https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem-statement.pptx'> target="https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem-statement.pptx">
<front>
<title>Multicast on 802.11</title>
<author fullname="Mikael Abrahamsson">
<organization>"IAB, IEEE 802 Wireless"</organization>
<address>
</address>
<organization>Deutsche Telekom</organization>
</author>
<author fullname="Adrian Stephens">
<organization>"IAB, IEEE 802 Wireless"</organization>
<address>
</address>
<organization>Intel Corporation</organization>
</author>
<date month="March" year="2015"/> year="2013"/>
</front>
</reference>
<reference anchor="Deri-2010" target="http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf">
<front>
<title abbrev="Deri-2010">10 Gbit Hardware Packet Filtering Using
Commodity Network Adapters</title>
<author fullname="Luca Deri" initials="L." surname="Deri">
<organization>NTOP</organization>
</author>
<author fullname="Joseph Gasparakis" initials="J." surname="Gasparakis">
<organization>Intel</organization>
</author>
<date year="2010" /> month="November" year="2010"/>
</front>
<seriesInfo name="RIPE" value="61" />
<format
target="http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf"
type="HTML" />
<refcontent>RIPE 61</refcontent>
</reference>
<reference anchor="CAB" target="https://patchwork.kernel.org/patch/2687951/">
<front>
<title abbrev="CAB">Limit
<title>limit multicast buffer hardware queue depth</title>
<author fullname="Felix Fietkau">
<organization>"openwrt.org"</organization>
<address>
</address>
</author>
<author/>
<date year="2013" /> month="June"/>
</front>
<refcontent>commit 2687951</refcontent>
</reference>
<reference anchor="group_key" target='https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless'> target="https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless">
<front>
<title>Why
<title>Subject: Why do some WiFi routers block multicast packets going from wired to wireless?</title>
<author fullname="Spiff">
<organization>"superuser.com"</organization>
<address>
</address>
</author> />
<date month="Jan" month="January" year="2017"/>
</front>
<refcontent>message to the Super User Q & A community</refcontent>
</reference>
<reference anchor="Tramarin2017">
<front>
<title> IEEE 802.11n for Distributed Measurement Systems</title>
<author fullname="Federico Tramarin" initials="F." surname="Tramarin">
<organization>
National Research Council of Italy, CNR-IEIIT
</organization>
<address>
<postal>
<street>
Via Gradenigo 6/B, 35131 Padova, Italy
</street>
</postal>
</address>
</author>
<author fullname="Stefano Vitturi" initials="S." surname="Vitturi">
<organization>
National Research Council of Italy, CNR-IEIIT
</organization>
<address>
<postal>
<street>
Via Gradenigo 6/B, 35131 Padova, Italy
</street>
</postal>
</address>
</author>
<author fullname="Michele Luvisotto" initials="M." surname="Luvisotto">
<organization>
Dept. of Information Engineering, University of Padova
</organization>
<address>
<postal>
<street>
Via Gradenigo 6/B, 35131 Padova, Italy
</street>
</postal>
</address>
</author>
<date month="May" year="2017"/>
</front>
<seriesInfo name="2017
<refcontent>2017 IEEE International Instrumentation and Measurement Technology Conference (I2MTC)"
value="pp. 1-6"/> (I2MTC), pp. 1-6</refcontent>
</reference>
<!--
Antonio de la Oliva
Universidad Carlos III de Madrid,
Avda. Universidad, 30, 28911 Leganes, Spain
Pablo Serrano
Universidad Carlos III de Madrid,
Avda. Universidad, 30, 28911 Leganes, Spain
Pablo Salvador
Institute IMDEA Networks,
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
Albert Banchs
Institute IMDEA Networks,
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
Email:
{ aoliva,pablo } @it.uc3m.es
Email:
{ josepablo.salvador,albert.banchs } @imdea.org
@INPROCEEDINGS{6583394,
author={A. de la Oliva and P. Serrano and P. Salvador and A. Banchs},
booktitle={2013 IEEE 14th International Symposium on "A World of Wireless, Mobile and Multimedia Networks" (WoWMoM)},
title={Performance evaluation of the IEEE 802.11aa multicast mechanisms for video streaming},
year={2013},
volume={},
number={},
pages={1-9},
keywords={multicast communication;performance evaluation;radio transmitters;
telecommunication traffic;video communication;video streaming;
wireless LAN;IEEE 802.11aa Task Group;IEEE 802.11aa multicast mechanism;
Internet traffic;group addressed frame handling;home environment;
multicast flow transmission;multimedia traffic;performance evaluation;
resource complexity;resource consumption;video streaming;video traffic;
video transmission;wireless LAN;wireless equipment;
IEEE 802.11 Standards;Multimedia communication;Receivers;Reliability;
Streaming media;Wireless LAN;802.11aa;Groupcast;WLAN},
doi={10.1109/WoWMoM.2013.6583394},
ISSN={},
month={June},}
-->
<reference anchor="Oliva2013">
<front>
<title> Performance evaluation of the IEEE 802.11aa multicast
mechanisms for video streaming </title>
<author fullname="Antonio de la Oliva" initials="A." surname="de la Oliva">
<organization>
Universidad Carlos III de Madrid
</organization>
<address>
<postal>
<street>
Avda. Universidad, 30, 28911 Leganes, Spain
</street>
</postal>
</address>
</author>
<author fullname="Pablo Serrano" initials="P." surname="Serrano">
<organization>
Universidad Carlos III de Madrid
</organization>
<address>
<postal>
<street>
Avda. Universidad, 30, 28911 Leganes, Spain
</street>
</postal>
</address>
</author>
<author fullname="Pablo Salvador" initials="P." surname="Salvador">
<organization>
Institute IMDEA Networks,
</organization>
<address>
<postal>
<street>
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
</street>
</postal>
</address>
</author>
<author fullname="Albert Banchs" initials="A." surname="Banchs">
<organization>
Institute IMDEA Networks,
</organization>
<address>
<postal>
<street>
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
</street>
</postal>
</address>
</author>
<date month="June" year="2013"/>
</front>
<seriesInfo name='2013 name="DOI" value="10.1109/WoWMoM.2013.6583394"/>
<refcontent>2013 IEEE 14th International Symposium on "A World of Wireless, Mobile and Multimedia Networks" (WoWMoM)'
value="pp. 1-9"/> (WoWMoM), pp. 1-9 </refcontent>
</reference>
<!--
<reference anchor="dot15mc">
<front>
<title>IEEE 802.15.4 and ZigBee as Enabling Technologies</title>
<author surname='Stefano Tennina et al.'>
<organization>
</organization>
<address>
<uri>https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem-statement.pptx</uri>
</address>
</author>
<date month="March" year="2015"/>
</front>
</reference>
<author surname='Stefano Tennina, Anis Koubaa, Roberta Daidone,
Mario Alves, et al.'>
Koubaa had first 'a' with caret
Mario had 'a' with accent
-->
</references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
This document has benefitted from discussions with the following
people, in alphabetical order:
<contact fullname="Mikael Abrahamsson"/>,
<contact fullname="Bill Atwood"/>,
<contact fullname="Stuart Cheshire"/>,
<contact fullname="Donald Eastlake 3rd"/>,
<contact fullname="Toerless Eckert"/>,
<contact fullname="Jake Holland"/>,
<contact fullname="Joel Jaeggli"/>,
<contact fullname="Jan Komissar"/>,
<contact fullname="David Lamparter"/>,
<contact fullname="Morten Pedersen"/>,
<contact fullname="Pascal Thubert"/>, and
<contact fullname="Jeffrey (Zhaohui) Zhang"/>.
</t>
</section>
</back>
</rfc>