--- 1/draft-ietf-mboned-ieee802-mcast-problems-05.txt 2019-07-08 10:15:43.503653941 -0700 +++ 2/draft-ietf-mboned-ieee802-mcast-problems-06.txt 2019-07-08 10:15:43.559655352 -0700 @@ -1,24 +1,24 @@ Internet Area C. Perkins Internet-Draft M. McBride Intended status: Informational Futurewei -Expires: October 17, 2019 D. Stanley +Expires: January 9, 2020 D. Stanley HPE W. Kumari Google JC. Zuniga SIGFOX - April 15, 2019 + July 8, 2019 Multicast Considerations over IEEE 802 Wireless Media - draft-ietf-mboned-ieee802-mcast-problems-05 + draft-ietf-mboned-ieee802-mcast-problems-06 Abstract Well-known issues with multicast have prevented the deployment of multicast in 802.11 and other local-area wireless environments. This document offers guidance on known limitations and problems with wireless multicast. Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be taken to improve the performace of the network. Finally, some @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 17, 2019. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,72 +58,73 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identified multicast issues . . . . . . . . . . . . . . . . . 5 3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5 3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5 3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6 - 3.1.3. High Interference . . . . . . . . . . . . . . . . . . 6 + 3.1.3. High Interference . . . . . . . . . . . . . . . . . . 7 3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7 3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7 3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9 4. Multicast protocol optimizations . . . . . . . . . . . . . . 10 4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10 4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10 4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12 4.4. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12 4.5. Using Unicast Instead of Multicast . . . . . . . . . . . 13 4.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 4.5.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13 - 4.5.3. Directed Multicast Service (DMS) . . . . . . . . . . 13 + 4.5.3. Directed Multicast Service (DMS) . . . . . . . . . . 14 4.5.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14 4.6. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 14 5. Operational optimizations . . . . . . . . . . . . . . . . . . 15 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15 5.2. Mitigating Spurious Service Discovery Messages . . . . . 17 6. Multicast Considerations for Other Wireless Media . . . . . . 17 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . 19 - Appendix A. Changes in this draft between revisions 04 versus 05 22 - Appendix B. Changes in this draft between revisions 03 versus 04 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + Appendix A. Changes in this draft between revisions 05 versus 06 23 + Appendix B. Changes in this draft between revisions 04 versus 05 23 + Appendix C. Changes in this draft between revisions 03 versus 04 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Well-known issues with multicast have prevented the deployment of multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other local-area wireless environments. 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 and configuration choices. Many IETF protocols depend on multicast/broadcast for delivery of control messages to multiple receivers. Multicast is used for various purposes such as neighbor discovery, network flooding, address resolution, as well 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 in hospitals, or video in enterprises, universities, and homes, are sending multicast IP to end - user devices, which are increasingly using wifi for their + user devices, which are increasingly using Wi-Fi for their connectivity. IETF protocols typically rely on network protocol layering in order to reduce or eliminate any dependence of higher level protocols on the specific nature of the MAC layer protocols or the physical media. In the case of multicast transmissions, 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 @@ -205,22 +206,22 @@ TIM Traffic Indication Map (TIM): An information element that advertises whether or not any associated stations have buffered unicast frames 3. Identified multicast issues 3.1. Issues at Layer 2 and Below - In this section we describe some of the issues related to the use of - multicast transmissions over IEEE 802 wireless technologies. + In this section some of the issues related to the use of multicast + transmissions over IEEE 802 wireless technologies are described. 3.1.1. Multicast reliability 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. Since typically there are no ACKs for multicast packets, it is not possible for the Access Point (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 @@ -231,23 +232,23 @@ packet error rate (PER) due to lack of retransmission, and because the sender never backs off. It is not uncommon for there to be a 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. 3.1.2. Lower and Variable Data Rate 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 which varies depending - upon the STA's proximity to the AP. The throughput of video flows, - and the capacity of the broader Wi-Fi network, will change and will + on the other hand, has a transmission rate that varies depending upon + the STA's proximity to the AP. The throughput of video flows, and + the capacity of the broader Wi-Fi network, will change and will impact the ability for QoS solutions to effectively reserve bandwidth and provide admission control. For wireless stations associated with an Access Point, 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 the Access Point has to use a much lower data rate at a power level high enough for even the farthest station @@ -294,21 +295,21 @@ process can have a large effect on the power consumption by the multicast receiver station. Multicast can work poorly with the power-save mechanisms defined in IEEE 802.11e, for the following reasons. o Clients may be unable to stay in sleep mode due to multicast control packets frequently waking them up. o Both unicast and multicast traffic can be delayed by power-saving mechanisms. - o A unicast packet is delayed until a 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, efficiency and increase probability of aggregation. o Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated to the AP have to be awake at a known time to receive multicast traffic. o Packets can also be discarded due to buffer limitations in the AP and non-AP STA. 3.2. Issues at Layer 3 and Above @@ -382,53 +382,53 @@ possibly many multicast solicited-node addresses. 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. 3.2.4. Spurious Neighbor Discovery On the Internet there is a "background radiation" of scanning traffic (people scanning for vulnerable machines) and backscatter (responses from spoofed traffic, etc). This means that routers very often - receive packets destined for IP addresses regardless of whether they - are in use. In the cases where the IP is assigned to a host, the - router broadcasts an ARP request, gets back an ARP reply, and caches - it; then traffic can be delivered to the host. When the IP address - is not in use, the router broadcasts one (or more) ARP 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 the - router will rebroadcast the ARP requests. + receive packets destined for IP 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 an ARP reply, + and caches it; then traffic can be delivered to the host. When the + IP address is not in use, the router broadcasts one (or more) ARP + 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 the router will rebroadcast the ARP requests. 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, on the order of 2000 broadcasts per second have been observed, for instance at the NOCs during IETF face-to-face meetings. On a wired network, there is not a huge difference between unicast, multicast and broadcast traffic. Due to hardware filtering (see, - e.g., [Deri-2010]), inadvertently flooded traffic (or high amounts of + e.g., [Deri-2010]), inadvertently flooded traffic (or excessive ethernet multicast) on wired networks can be quite a bit less 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. This is not true in the wireless realm; wireless equipment is often unable to send high volumes of broadcast and multicast traffic. - Consequently, on the wireless networks, we observe a significant - amount of dropped broadcast and multicast packets. This, in turn, + Consequently, on the wireless networks, a significant number of + dropped broadcast and multicast packets are observed. This, in turn, means that when a host connects it is often not able to complete DHCP, and IPv6 RAs get dropped, leading to users being unable to use the network. 4. Multicast protocol optimizations 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 Section 3. @@ -602,52 +602,53 @@ least one widely available implementation exists in the Linux bridging code [bridge-mc-2-uc]. 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. 4.5.3. Directed Multicast Service (DMS) There are situations where more is needed than simply converting - multicast to unicast. For these purposes, DMS enables a STA to + multicast to unicast. For these purposes, DMS enables an STA to request that the AP transmit multicast group addressed frames destined to the requesting STAs as individually addressed frames [i.e., convert multicast to unicast]. Here are some characteristics of DMS: o Requires 802.11n A-MSDUs o Individually addressed frames are acknowledged and are buffered for power save STAs o The requesting STA may specify traffic characteristics for DMS traffic o DMS was defined in IEEE Std 802.11v-2011 o DMS requires changes to both AP and STA implementation. DMS is not currently implemented in products. See [Tramarin2017] and [Oliva2013] for more information. 4.5.4. Automatic Multicast Tunneling (AMT) AMT[RFC7450] 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 a STA has an AMT + When an operating system or application running on an STA has an AMT gateway capability integrated, it's possible to use unicast to traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi portion of the network connected to the AP. It is RECOMMENDED that multicast-enabled networks deploying AMT - relays for this purpose make the relays discoverable with both of - these methods: + relays for this purpose make the relays discoverable with the + following methods: + o DNS-SD [RFC6763] o the well-known IP addresses from Section 7 of [RFC7450], and - o with DNS-SD [RFC6763] + o DRIAD [I-D.ietf-mboned-driad-amt-discovery] Providing the multiple standard discovery methods makes it more likely that AMT gateway implementations will discover the local multicast-capable network, rather than forming a connection to an AMT relay further upstream. 4.6. GroupCast with Retries (GCR) GCR (defined in [dot11aa]) provides greater reliability by using either unsolicited retries or a block acknowledgement mechanism. GCR @@ -665,21 +666,21 @@ 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 implementation. GCR may introduce unacceptable latency. After sending a group of data frames to the group, the AP has do the following: o unicast a Block Ack Request (BAR) to a subset of members. o wait for the corresponding Block Ack (BA). o retransmit any missed frames. - o resume other operations which may have been delayed. + o resume other operations that may have been delayed. This latency may not be acceptable for some traffic. There are ongoing extensions in 802.11 to improve GCR performance. o BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is already specified in 802.11-REVmc 4.3). o BA is sent using uplink MU-MIMO (which is a .11ax feature). o Additional 802.11ax extensions are under consideration; see [mc-ack-mux] @@ -689,105 +690,104 @@ 5. Operational optimizations This section lists some operational optimizations that can be implemented when deploying wireless IEEE 802 networks to mitigate the issues discussed in Section 3. 5.1. Mitigating Problems from Spurious Neighbor Discovery ARP Sponges - An ARP Sponge sits on a network and learn which IPs addresses + An ARP Sponge sits on a network and learn which IP addresses are actually in use. It also listen for ARP requests, and, if - it sees an ARP for an IP address which 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 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 sponge will see 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 daemons were not really designed for this use (the standard one [arpsponge], was designed to deal with the disappearance of participants from an IXP) and so are not - optimized for this purpose. We have to run one daemon per - subnet, the tuning is tricky (the scanning rate versus the - population rate versus retires, etc.) and sometimes the daemons - just seem to stop, requiring a restart of the daemon and - causing disruption. + optimized for this purpose. One daemon is needed per subnet, + the tuning is tricky (the scanning rate versus the population + rate versus retires, etc.) and sometimes the daemons just seem + to stop, requiring a restart of the daemon and causing + disruption. Router mitigations Some routers (often those based on Linux) implement a "negative ARP cache" daemon. Simply put, if the router does not see a reply to an ARP it can be configured to cache this information - for some interval. Unfortunately, the core routers which we - are using do not support this. When a host connects to 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 learnt from the request (passive ARP - learning). + for some interval. Unfortunately, the core routers in use + often do not support this. When a host connects to 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 learnt from the request (passive ARP learning). Firewall unused space The distribution of users on wireless networks / subnets - changes from meeting to meeting (e.g SSIDs are renamed, some - SSIDs lose favor, 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, and enabling them sequentially, - can create a large subnet, from which only addresses in the - lower portions are assigned. 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, and so does not ARP for - it. This method has proven to be very effective, but is - somewhat of a blunt axe, is fairly labor intensive, and - requires coordination. + changes from IETF meeting to the next (e.g SSIDs are renamed, + some SSIDs lose favor, 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, and enabling them + sequentially, can create a large subnet, from which only + addresses in the lower portions are assigned. 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, and so + does not ARP for it. This method has proven to be very + effective, but is somewhat of a blunt axe, is fairly labor + intensive, and requires coordination. Disabling/filtering ARP requests 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 - the ARP request sent by that host. This means that we should - be able to disable and / or filter ARP requests from the + the ARP request sent by that host. Consequently it should be + possible to disable and / or filter ARP requests from the router. Unfortunately, ARP is a very low level / fundamental part of the IP stack, and is often offloaded from the normal control plane. While many routers can filter layer-2 traffic, this is usually implemented as an input filter and / or has limited ability to filter output broadcast traffic. This means that the simple "just disable ARP or filter it outbound" seems like a really simple (and obvious) solution, but implementations / architectural issues make this difficult or awkward in practice. NAT The broadcasts are overwhelmingly being caused by outside - scanning / backscatter traffic. This means that, if we were to - NAT the entire (or a large portion) of the attendee networks, - there would be no NAT translation entries for unused addresses, - and so the router would never ARP for them. However, there are - many reasons to avoid using NAT in such a blanket fashion. + scanning / backscatter traffic. To NAT the entire (or a large + portion) of the attendee networks would eliminate NAT + translation entries for unused addresses, and so the router + would never ARP for them. However, there are many reasons to + avoid using NAT in such a blanket fashion. Stateful firewalls 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 to have - the network as open as possible and to honor the end-to-end - principle. An attendee on the meeting network should be an - Internet host, and should be able to receive unsolicited - requests. Unfortunately, keeping the network working and - stable is the first priority and a stateful firewall may be - required in order to achieve this. + request. But this conflicts with the need and desire of the + IETF and other organizations to have the network as open as + possible and to honor the end-to-end principle. An attendee on + the meeting network should be an Internet host, and should be + able to receive unsolicited requests. Unfortunately, keeping + the network working and stable is the first priority and a + stateful firewall may be required in order to achieve this. 5.2. Mitigating Spurious Service Discovery Messages 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. @@ -844,43 +844,51 @@ 802.1Q-2011. 802.1Q-2014 can be found here: http://www.ieee802.org/1/pages/802.1Q-2014.html. If a generic solution is not found, guidelines for multicast over Wi-Fi should be established. Reliable registration to Layer-2 multicast groups and a reliable multicast operation at Layer-2 might provide a generic solution. There is no need to support 2^24 groups to get solicited node multicast working: it is possible to simply select a number of trailing bits that make sense for a given network size to limit the - amount of unwanted deliveries to reasonable levels. IEEE 802.1, + number of unwanted deliveries to reasonable levels. IEEE 802.1, 802.11, and 802.15 should be encouraged to revisit L2 multicast issues. In reality, Wi-Fi provides a broadcast service, not a multicast service. On the physical medium, all frames are broadcast 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 - This document neither introduces nor modifies any security - mechanisms. + This document does not introduce or modify any security mechanisms. + + As noted in [group_key], the unreliable nature of multicast + transmission over wireless media can cause subtle problems with + multicast group key management and updates. Quoting from that + website, "... most clients are able to get connected and surf the + web, check email, etc. even when FromDS multicasts are broken. So a + lot of people don't realize they have multicast problems on their + network..." 10. IANA Considerations This document does not request any IANA actions. 11. Acknowledgements This document has benefitted from discussions with the following - people, in alphabetical order: Mikael Abrahamsson, Stuart Cheshire, - Donald Eastlake, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan - Komissar, David Lamparter, Pascal Thubert + people, in alphabetical order: Mikael Abrahamsson, Bill Atwood, + Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel + Jaeggli, Jan Komissar, David Lamparter, Pascal Thubert, Jeffrey + (Zhaohui) Zhang 12. Informative References [arpsponge] Vijn, A. and S. Bakker, "Arp Sponge", March 2015, . [bridge-mc-2-uc] Torvalds, L., "bridge: multicast to unicast", Jan 2017, @@ -908,29 +916,41 @@ September 2015, . [dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming", March 2012, . + [group_key] + Spiff, ""Why do some WiFi routers block multicast packets + going from wired to wireless?"", Jan 2017, + . + [I-D.ietf-6lo-backbone-router] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Backbone Router", draft-ietf-6lo-backbone-router-11 (work in progress), February 2019. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work - in progress), March 2019. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work + in progress), July 2019. + + [I-D.ietf-mboned-driad-amt-discovery] + Holland, J., "DNS Reverse IP AMT Discovery", draft-ietf- + mboned-driad-amt-discovery-08 (work in progress), June + 2019. [ietf_802-11] Stanley, D., "IEEE 802.11 multicast capabilities", Nov 2015, . [mc-ack-mux] Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G., and S. Coffey, "Multiplexing of Acknowledgements for @@ -1016,41 +1036,55 @@ [Tramarin2017] Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n for Distributed Measurement Systems", 2017 IEEE International Instrumentation and Measurement Technology Conference (I2MTC) pp. 1-6, May 2017. [uli] Kinney, P., "LLC Proposal for 802.15.4", Nov 2015, . -Appendix A. Changes in this draft between revisions 04 versus 05 +Appendix A. Changes in this draft between revisions 05 versus 06 + + This section lists the changes between revisions ...-05.txt and + ...-06.txt of draft-ietf-mboned-ieee802-mcast-problems. + + o Included new text in Security Considerations to alert about + problems regarding Group Key management caused by multicast + unreliability and implementation bugs. + o Included DRIAD as a discovery mechanism for multicast relays. + o Corrected occurrences of "which" versus "that" and "amount" versus + "number". + o Updated bibliographic citations, included URLs as needed. + o More editorial improvements and grammatical corrections. + +Appendix B. Changes in this draft between revisions 04 versus 05 This section lists the changes between revisions ...-04.txt and ...-05.txt of draft-ietf-mboned-ieee802-mcast-problems. o Incorporated text from Jake Holland for a new section about conversion of multicast to unicast and included AMT as an existing solution. o Included some text about likely future multicast applications that will emphasize the need for attention to the technical matters collected in this document. o Further modified text to be more generic instead of referring specifically to IETF conference situations. o Modified text to be more generic instead of referring specifically to Bonjour. o Added uPnP as a representative multicast protocol in IP networks. o Referred to Linux bridging code for multicast to unicast. o Updated bibliographic citations, included URLs as needed. o More editorial improvements and grammatical corrections. -Appendix B. Changes in this draft between revisions 03 versus 04 +Appendix C. Changes in this draft between revisions 03 versus 04 This section lists the changes between revisions ...-03.txt and ...-04.txt of draft-ietf-mboned-ieee802-mcast-problems. o Replaced "client" by "STA". o Used terminology "Wi-Fi" throughout. o Many editorial improvements and grammatical corrections. o Modified text to be more generic instead of referring specifically to IETF conference situations. o Cited [RFC5757] for introduction to other wireless media. @@ -1066,21 +1100,21 @@ Phone: +1-408-330-4586 Email: charliep@computer.org Mike McBride Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95055 USA - Email: michael.mcbride@huawei.com + Email: michael.mcbride@futurewei.com Dorothy Stanley Hewlett Packard Enterprise 2000 North Naperville Rd. Naperville, IL 60566 USA Phone: +1 630 979 1572 Email: dstanley@arubanetworks.com Warren Kumari