draft-ietf-mboned-ieee802-mcast-problems-11.txt   draft-ietf-mboned-ieee802-mcast-problems-12.txt 
Internet Area C. Perkins Internet Area C. Perkins
Internet-Draft Blue Meadow Networks Internet-Draft Blue Meadow Networks
Intended status: Informational M. McBride Intended status: Informational M. McBride
Expires: June 13, 2020 Futurewei Expires: April 29, 2021 Futurewei
D. Stanley D. Stanley
HPE HPE
W. Kumari W. Kumari
Google Google
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
December 11, 2019 October 26, 2020
Multicast Considerations over IEEE 802 Wireless Media Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-11 draft-ietf-mboned-ieee802-mcast-problems-12
Abstract Abstract
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 (wifi) and other local-area wireless multicast in 802.11 (wifi) and other local-area wireless
environments. environments. This document describes the problems of known
limitations with wireless (primarily 802.11) Layer-2 multicast. Also
This document describes the problems of known limitations with described are certain multicast enhancement features that have been
wireless (primarily 802.11) Layer-2 multicast. Also described are specified by the IETF, and by IEEE 802, for wireless media, as well
certain multicast enhancement features that have been specified by as some operational choices that can be taken to improve the
the IETF, and by IEEE 802, for wireless media, as well as some performance of the network. Finally, some recommendations are
operational choices that can be taken to improve the performance of provided about the usage and combination of these features and
the network. Finally, some recommendations are provided about the 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 June 13, 2020. This Internet-Draft will expire on April 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 6
3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6 3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6
3.1.3. Capacity and Impact on Interference . . . . . . . . . 7 3.1.3. Capacity and Impact on Interference . . . . . . . . . 7
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 . . . . . . . . . . . . . . . 8
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
4.4. Limiting multicast buffer hardware queue depth . . . . . 13 4.4. Limiting multicast buffer hardware queue depth . . . . . 13
4.5. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 13 4.5. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 52 skipping to change at page 2, line 52
4.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 4.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14
4.6.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 14 4.6.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 14
4.6.3. Directed Multicast Service (DMS) . . . . . . . . . . 14 4.6.3. Directed Multicast Service (DMS) . . . . . . . . . . 14
4.6.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 15 4.6.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 15
4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15 4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15
5. Operational optimizations . . . . . . . . . . . . . . . . . . 16 5. Operational optimizations . . . . . . . . . . . . . . . . . . 16
5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16
5.2. Mitigating Spurious Service Discovery Messages . . . . . 18 5.2. Mitigating Spurious Service Discovery Messages . . . . . 18
6. Multicast Considerations for Other Wireless Media . . . . . . 18 6. Multicast Considerations for Other Wireless Media . . . . . . 18
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19
8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 19 8. On-going Discussion Items . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Informative References . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Changes in this draft between revisions 06 versus 07 24 12.1. Informative References . . . . . . . . . . . . . . . . . 20
Appendix B. Changes in this draft between revisions 05 versus 06 24 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Changes in this draft between revisions 06 versus 07 25
Appendix B. Changes in this draft between revisions 05 versus 06 25
Appendix C. Changes in this draft between revisions 04 versus 05 25 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 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 7, line 23 skipping to change at page 7, line 33
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
One of the characteristics of multicast transmission is that every One of the characteristics of multicast transmission is that every
station has to be configured to wake up to receive the multicast, station has to be configured to wake up to receive the multicast,
even though the received packet may ultimately be discarded. This even though the received packet may ultimately be discarded. This
process can have a large effect on the power consumption by the process can have a large effect on the power consumption by the
multicast receiver station. multicast receiver station. For this reason there are workarounds,
such as Directed Multicast Service (DMS) described in Section 4, to
prevent unnecessarily waking up stations.
Multicast can work poorly with the power-save mechanisms defined in Multicast can work poorly with the power-save mechanisms defined in
IEEE 802.11e, for the following reasons. IEEE 802.11e, for the following reasons.
o Clients may be unable to stay in sleep mode due to multicast o Clients may be unable to stay in sleep mode due to multicast
control packets frequently waking them up. control packets frequently waking them up.
o Both unicast and multicast traffic can be delayed by power-saving o Both unicast and multicast traffic can be delayed by power-saving
mechanisms. mechanisms.
o A unicast packet is delayed until an STA wakes up and requests it. o A unicast packet is delayed until an STA wakes up and requests it.
Unicast traffic may also be delayed to improve power save, Unicast traffic may also be delayed to improve power save,
skipping to change at page 8, line 17 skipping to change at page 8, line 30
User Datagram Protocol (UDP) is the most common transport layer User Datagram Protocol (UDP) is the most common transport layer
protocol for multicast applications. By itself, UDP is not reliable protocol for multicast applications. By itself, UDP is not reliable
-- messages may be lost or delivered out of order. -- messages may be lost or delivered out of order.
3.2.1. IPv4 issues 3.2.1. IPv4 issues
The following list contains some representative discovery protocols, The following list contains some representative discovery protocols,
which utlize broadcast/multicast, that are used with IPv4. which utlize broadcast/multicast, that are used with IPv4.
o ARP o ARP [RFC5424]
o DHCP o DHCP [RFC2131]
o mDNS [RFC6762] o mDNS [RFC6762]
o uPnP [RFC6970] o uPnP [RFC6970]
After initial configuration, ARP (described in more detail later) and After initial configuration, ARP (described in more detail later) and
DHCP occur much less commonly, but service discovery can occur at any DHCP occur much less commonly, but service discovery can occur at any
time. Some widely-deployed service discovery protocols (e.g., for time. Some widely-deployed service discovery protocols (e.g., for
finding a printer) utilize mDNS (i.e., multicast). It's often the finding a printer) utilize mDNS (i.e., multicast) which is often the
first service that operators drop. Even if multicast snooping is first service that operators drop. Even if multicast snooping
utilized, many devices can register at once and cause serious network [RFC4541] (which provides the benefit of conserving bandwidth on
degradation. 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.
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 [RFC8415]
o Protocol Independent Multicast (PIM) o Protocol Independent Multicast (PIM) [RFC7761]
o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]
o multicast DNS (mDNS) o multicast DNS (mDNS) [RFC6762]
o Route Discovery o Router Discovery [RFC4286]
o Decentralized Address Assignment
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.
This intensifies the impact of multicast messages that are associated This intensifies the impact of multicast messages that are associated
to the mobility of a node. Router advertisement (RA) messages are to the mobility of a node. Router advertisement (RA) messages are
also periodically multicasted over the Link. also periodically multicasted over the Link.
Neighbors may be considered lost if several consecutive Neighbor Neighbors may be considered lost if several consecutive Neighbor
skipping to change at page 14, line 45 skipping to change at page 14, line 45
least one widely available implementation exists in the Linux least one widely available implementation exists in the Linux
bridging code [bridge-mc-2-uc]. Other proprietary implementations bridging code [bridge-mc-2-uc]. Other proprietary implementations
are available from various vendors. In general, these are available from various vendors. In general, these
implementations perform a straightforward mapping for groups or implementations perform a straightforward mapping for groups or
channels, discovered by IGMP or MLD snooping, to the corresponding channels, discovered by IGMP or MLD snooping, to the corresponding
unicast MAC addresses. unicast MAC addresses.
4.6.3. Directed Multicast Service (DMS) 4.6.3. Directed Multicast Service (DMS)
There are situations where more is needed than simply converting There are situations where more is needed than simply converting
multicast to unicast. multicast to unicast. For these purposes, DMS enables an STA to
request that the AP transmit multicast group addressed frames
For these purposes, DMS enables an STA to request that the AP destined to the requesting STAs as individually addressed frames
transmit multicast group addressed frames destined to the requesting [i.e., convert multicast to unicast]. Here are some characteristics
STAs as individually addressed frames [i.e., convert multicast to of DMS:
unicast]. Here are some characteristics of DMS:
o Requires 802.11n A-MSDUs o Requires 802.11n A-MSDUs
o Individually addressed frames are acknowledged and are buffered o Individually addressed frames are acknowledged and are buffered
for power save STAs for power save STAs
o The requesting STA may specify traffic characteristics for DMS o The requesting STA may specify traffic characteristics for DMS
traffic traffic
o DMS was defined in IEEE Std 802.11v-2011 o DMS was defined in IEEE Std 802.11v-2011
o DMS requires changes to both AP and STA implementation. o DMS requires changes to both AP and STA implementation.
DMS is not currently implemented in products. See [Tramarin2017] and DMS is not currently implemented in products. See [Tramarin2017] and
skipping to change at page 16, line 37 skipping to change at page 16, line 37
5. Operational optimizations 5. Operational optimizations
This section lists some operational optimizations that can be This section lists some operational optimizations that can be
implemented when deploying wireless IEEE 802 networks to mitigate the implemented when deploying wireless IEEE 802 networks to mitigate the
issues discussed in Section 3. issues discussed in Section 3.
5.1. Mitigating Problems from Spurious Neighbor Discovery 5.1. Mitigating Problems from Spurious Neighbor Discovery
ARP Sponges ARP Sponges
An ARP Sponge sits on a network and learn which IP addresses An ARP Sponge sits on a network and learns which IP addresses
are actually in use. It also listen for ARP requests, and, if are actually in use. It also listen for ARP requests, and, if
it sees an ARP for an IP address that it believes is not used, 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 it will reply with its own MAC address. This means that the
router now has an IP to MAC mapping, which it caches. If that router now has an IP to MAC mapping, which it caches. If that
IP is later assigned to an machine (e.g using DHCP), the ARP IP is later assigned to an machine (e.g using DHCP), the ARP
sponge will see this, and will stop replying for that address. sponge will see this, and will stop replying for that address.
Gratuitous ARPs (or the machine ARPing for its gateway) will Gratuitous ARPs (or the machine ARPing for its gateway) will
replace the sponged address in the router ARP table. This replace the sponged address in the router ARP table. This
technique is quite effective; but, unfortunately, the ARP technique is quite effective; but, unfortunately, the ARP
sponge daemons were not really designed for this use (one of sponge daemons were not really designed for this use (one of
the most widely deployed arp sponges [arpsponge], was designed the most widely deployed arp sponges [arpsponge], was designed
to deal with the disappearance of participants from an IXP) and to deal with the disappearance of participants from an IXP) and
so are not optimized for this purpose. One daemon is needed so are not optimized for this purpose. One daemon is needed
per subnet, the tuning is tricky (the scanning rate versus the per subnet, the tuning is tricky (the scanning rate versus the
population rate versus retires, etc.) and sometimes the daemons population rate versus retires, etc.) and sometimes buggy
just seem to stop, requiring a restart of the daemon and daemons have stopped, requiring a restart of the daemon and
causing disruption. causing disruption.
Router mitigations Router mitigations
Some routers (often those based on Linux) implement a "negative Some routers (often those based on Linux) implement a "negative
ARP cache" daemon. Simply put, if the router does not see a ARP cache" daemon. Simply put, if the router does not see a
reply to an ARP it can be configured to cache this information reply to an ARP it can be configured to cache this information
for some interval. Unfortunately, the core routers in use for some interval. Unfortunately, the core routers in use
often do not support this. When a host connects to a network often do not support this. When a host connects to a network
and gets an IP address, it will ARP for its default gateway and gets an IP address, it will ARP for its default gateway
(the router). The router will update its cache with the IP to (the router). The router will update its cache with the IP to
host MAC mapping learned from the request (passive ARP host MAC mapping learned from the request (passive ARP
learning). learning).
Firewall unused space Firewall unused space
The distribution of users on wireless networks / subnets The distribution of users on wireless networks / subnets may
changes from one IETF meeting to the next (e.g SSIDs are change in various use cases, such as conference venues (e.g
renamed, some SSIDs lose favor, etc). This makes utilization SSIDs are renamed, some SSIDs lose favor, etc). This makes
for particular SSIDs difficult to predict ahead of time, but utilization for particular SSIDs difficult to predict ahead of
usage can be monitored as attendees use the different networks. time, but usage can be monitored as attendees use the different
Configuring multiple DHCP pools per subnet, and enabling them networks. Configuring multiple DHCP pools per subnet, and
sequentially, can create a large subnet, from which only enabling them sequentially, can create a large subnet, from
addresses in the lower portions are assigned. Therefore input which only addresses in the lower portions are assigned.
IP access lists can be applied, which deny traffic to the Therefore input IP access lists can be applied, which deny
upper, unused portions. Then the router does not attempt to traffic to the upper, unused portions. Then the router does
forward packets to the unused portions of the subnets, and so not attempt to forward packets to the unused portions of the
does not ARP for it. This method has proven to be very subnets, and so does not ARP for it. This method has proven to
effective, but is somewhat of a blunt axe, is fairly labor be very effective, but is somewhat of a blunt axe, is fairly
intensive, and requires coordination. labor intensive, and requires coordination.
Disabling/filtering ARP requests Disabling/filtering ARP requests
In general, the router does not need to ARP for hosts; when a In general, the router does not need to ARP for hosts; when a
host connects, the router can learn the IP to MAC mapping from host connects, the router can learn the IP to MAC mapping from
the ARP request sent by that host. Consequently it should be the ARP request sent by that host. Consequently it should be
possible to disable and / or filter ARP requests from the possible to disable and / or filter ARP requests from the
router. Unfortunately, ARP is a very low level / fundamental router. Unfortunately, ARP is a very low level / fundamental
part of the IP stack, and is often offloaded from the normal part of the IP stack, and is often offloaded from the normal
control plane. While many routers can filter layer-2 traffic, control plane. While many routers can filter layer-2 traffic,
skipping to change at page 18, line 19 skipping to change at page 18, line 19
portion) of the attendee networks would eliminate NAT portion) of the attendee networks would eliminate NAT
translation entries for unused addresses, and so the router translation entries for unused addresses, and so the router
would never ARP for them. However, there are many reasons to would never ARP for them. However, there are many reasons to
avoid using NAT in such a blanket fashion. avoid using NAT in such a blanket fashion.
Stateful firewalls Stateful firewalls
Another obvious solution would be to put a stateful firewall Another obvious solution would be to put a stateful firewall
between the wireless network and the Internet. This firewall between the wireless network and the Internet. This firewall
would block incoming traffic not associated with an outbound would block incoming traffic not associated with an outbound
request. But this conflicts with the need and desire of the request. But this conflicts with the need and desire of some
IETF and other organizations to have the network as open as organizations to have the network as open as possible and to
possible and to honor the end-to-end principle. An attendee on honor the end-to-end principle. An attendee on a meeting
the meeting network should be an Internet host, and should be network should be an Internet host, and should be able to
able to receive unsolicited requests. Unfortunately, keeping receive unsolicited requests. Unfortunately, keeping the
the network working and stable is the first priority and a network working and stable is the first priority and a stateful
stateful firewall may be required in order to achieve this. firewall may be required in order to achieve this.
5.2. Mitigating Spurious Service Discovery Messages 5.2. Mitigating Spurious Service Discovery Messages
In networks that must support hundreds of STAs, operators have In networks that must support hundreds of STAs, operators have
observed network degradation due to many devices simultaneously observed network degradation due to many devices simultaneously
registering with mDNS. In a network with many clients, it is registering with mDNS. In a network with many clients, it is
recommended to ensure that mDNS packets designed to discover recommended to ensure that mDNS packets designed to discover
services in smaller home networks be constrained to avoid services in smaller home networks be constrained to avoid
disrupting other traffic. disrupting other traffic.
skipping to change at page 19, line 31 skipping to change at page 19, line 31
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
multicast operations. multicast operations.
Multicast signaling for wireless devices should be done in a way Multicast signaling for wireless devices should be done in a way
compatible with low duty-cycle operation. compatible with low duty-cycle operation.
8. Discussion Items 8. On-going Discussion Items
This section suggests two discussion items for further resolution. This section suggests two discussion items for further resolution.
The IETF should determine guidelines by which it may be decided that First, standards (and private) organizations should develop
multicast packets are to be sent wired. For example, 802.1ak works guidelines to help clarify when multicast packets should be sent
on ethernet and Wi-Fi. 802.1ak has been pulled into 802.1Q as of wired rather than wireless. For example, 802.1ak [1] works on both
802.1Q-2011. If a generic solution is not found, guidelines for ethernet and Wi-Fi and organizations could help decision making by
multicast over Wi-Fi should be established. developing guidelines for multicast over Wi-Fi including options for
when traffic should be sent wired.
Reliable registration to Layer-2 multicast groups and a reliable Second, reliable registration to Layer-2 multicast groups, and a
multicast operation at Layer-2 might provide a generic solution. reliable multicast operation at Layer-2, might provide a good
There is no need to support 2^24 groups to get solicited node multicast over wifi solution. There shouldn't be a need to support
multicast working: it is possible to simply select a number of 2^24 groups to get solicited node multicast working: it is possible
trailing bits that make sense for a given network size to limit the to simply select a number of trailing bits that make sense for a
number of unwanted deliveries to reasonable levels. IEEE 802.1, given network size to limit the number of unwanted deliveries to
802.11, and 802.15 should be encouraged to revisit L2 multicast reasonable levels. IEEE 802.1, 802.11, and 802.15 should be
issues. In reality, Wi-Fi provides a broadcast service, not a encouraged to revisit L2 multicast issues and provide workable
multicast service. On the physical medium, all frames are broadcast solutions.
except in very unusual cases in which special beamforming
transmitters are used. Unicast offers the advantage of being much
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 Multicast is made more secure in a variety of ways. [RFC4601], for
instance, mandates the use of IPsec to ensure authentication of the instance, mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms to Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms to
authenticate the PIM-SM link-local messages using the IP security authenticate the PIM-SM link-local messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the (IPsec) Encapsulating Security Payload (ESP) or (optionally) the
skipping to change at page 20, line 39 skipping to change at page 20, line 39
This document does not request any IANA actions. This document does not request any IANA actions.
11. Acknowledgements 11. Acknowledgements
This document has benefitted from discussions with the following This document has benefitted from discussions with the following
people, in alphabetical order: Mikael Abrahamsson, Bill Atwood, people, in alphabetical order: Mikael Abrahamsson, Bill Atwood,
Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel
Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal
Thubert, Jeffrey (Zhaohui) Zhang Thubert, Jeffrey (Zhaohui) Zhang
12. Informative References 12. References
12.1. Informative References
[arpsponge] [arpsponge]
Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address
resolution on AMS-IX and the ARP Sponge", July 2009, resolution on AMS-IX and the ARP Sponge", July 2009,
<http://citeseerx.ist.psu.edu/viewdoc/ <http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.182.4692>. summary?doi=10.1.1.182.4692>.
[bridge-mc-2-uc] [bridge-mc-2-uc]
Fietkau, F., "bridge: multicast to unicast", Jan 2017, Fietkau, F., "bridge: multicast to unicast", Jan 2017,
<https://github.com/torvalds/linux/ <https://github.com/torvalds/linux/
skipping to change at page 21, line 45 skipping to change at page 21, line 45
[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-20 (work
in progress), September 2019. in progress), March 2020.
[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-28 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-29 (work
in progress), October 2019. in progress), August 2020.
[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 (Automatic Multicast
mboned-driad-amt-discovery-09 (work in progress), October Tunneling) Discovery", draft-ietf-mboned-driad-amt-
2019. discovery-13 (work in progress), December 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.,
and S. Coffey, "Multiplexing of Acknowledgements for and S. Coffey, "Multiplexing of Acknowledgements for
skipping to change at page 22, line 42 skipping to change at page 22, line 42
dcn/15/11-15-1161-02-0arc-802-11-multicast- dcn/15/11-15-1161-02-0arc-802-11-multicast-
properties.ppt>. properties.ppt>.
[Oliva2013] [Oliva2013]
de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs,
"Performance evaluation of the IEEE 802.11aa multicast "Performance evaluation of the IEEE 802.11aa multicast
mechanisms for video streaming", 2013 IEEE 14th mechanisms for video streaming", 2013 IEEE 14th
International Symposium on "A World of Wireless, Mobile International Symposium on "A World of Wireless, Mobile
and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013. and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
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>.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, DOI 10.17487/RFC4286, December 2005,
<https://www.rfc-editor.org/info/rfc4286>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006, DOI 10.17487/RFC4601, August 2006,
skipping to change at page 23, line 21 skipping to change at page 23, line 31
[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>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<https://www.rfc-editor.org/info/rfc5424>.
[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 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796, Mode (PIM-SM) Link-Local Messages", RFC 5796,
DOI 10.17487/RFC5796, March 2010, DOI 10.17487/RFC5796, March 2010,
<https://www.rfc-editor.org/info/rfc5796>. <https://www.rfc-editor.org/info/rfc5796>.
skipping to change at page 24, line 15 skipping to change at page 24, line 29
[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
Play (UPnP) Internet Gateway Device - Port Control Play (UPnP) Internet Gateway Device - Port Control
Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, Protocol Interworking Function (IGD-PCP IWF)", RFC 6970,
DOI 10.17487/RFC6970, July 2013, DOI 10.17487/RFC6970, July 2013,
<https://www.rfc-editor.org/info/rfc6970>. <https://www.rfc-editor.org/info/rfc6970>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[Tramarin2017] [Tramarin2017]
Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n
for Distributed Measurement Systems", 2017 IEEE for Distributed Measurement Systems", 2017 IEEE
International Instrumentation and Measurement Technology International Instrumentation and Measurement Technology
Conference (I2MTC) pp. 1-6, May 2017. Conference (I2MTC) pp. 1-6, May 2017.
[uli] Kinney, P., "LLC Proposal for 802.15.4", Nov 2015, [uli] Kinney, P., "LLC Proposal for 802.15.4", Nov 2015,
<https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0- <https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-
llc-proposal-for-802-15-4.pptx>. llc-proposal-for-802-15-4.pptx>.
12.2. URIs
[1] https://www.ieee802.org/1/pages/802.1ak.html
Appendix A. Changes in this draft between revisions 06 versus 07 Appendix A. Changes in this draft between revisions 06 versus 07
This section lists the changes between revisions ...-06.txt and This section lists the changes between revisions ...-06.txt and
...-07.txt of draft-ietf-mboned-ieee802-mcast-problems. ...-07.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Improved wording in section describing ARPsponge. o Improved wording in section describing ARPsponge.
o Removed DRIAD as a discovery mechanism for multicast relays. o Removed DRIAD as a discovery mechanism for multicast relays.
o Updated bibliographic citations, repaired broken URLs as needed. o Updated bibliographic citations, repaired broken URLs as needed.
o More editorial improvements and grammatical corrections. o More editorial improvements and grammatical corrections.
skipping to change at page 26, line 19 skipping to change at page 26, line 45
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Dorothy Stanley Dorothy Stanley
Hewlett Packard Enterprise Hewlett Packard Enterprise
2000 North Naperville Rd. 2000 North Naperville Rd.
Naperville, IL 60566 Naperville, IL 60566
USA USA
Phone: +1 630 979 1572 Phone: +1 630 979 1572
Email: dstanley@arubanetworks.com Email: dstanley1389@gmail.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: warren@kumari.net Email: warren@kumari.net
Juan Carlos Zuniga Juan Carlos Zuniga
SIGFOX SIGFOX
 End of changes. 35 change blocks. 
94 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/