draft-ietf-mboned-ieee802-mcast-problems-06.txt   draft-ietf-mboned-ieee802-mcast-problems-07.txt 
Internet Area C. Perkins Internet Area C. Perkins
Internet-Draft M. McBride Internet-Draft M. McBride
Intended status: Informational Futurewei Intended status: Informational Futurewei
Expires: January 9, 2020 D. Stanley Expires: January 27, 2020 D. Stanley
HPE HPE
W. Kumari W. Kumari
Google Google
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
July 8, 2019 July 26, 2019
Multicast Considerations over IEEE 802 Wireless Media Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-06 draft-ietf-mboned-ieee802-mcast-problems-07
Abstract Abstract
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 and other local-area wireless environments. This multicast in 802.11 and other local-area wireless environments. This
document offers guidance on known limitations and problems with document offers guidance on known limitations and problems with
wireless multicast. Also described are certain multicast enhancement wireless multicast. Also described are certain multicast enhancement
features that have been specified by the IETF and by IEEE 802 for 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 wireless media, as well as some operational choices that can be taken
to improve the performace of the network. Finally, some to improve the performace of the network. Finally, some
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 January 9, 2020. This Internet-Draft will expire on January 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5. Operational optimizations . . . . . . . . . . . . . . . . . . 15 5. Operational optimizations . . . . . . . . . . . . . . . . . . 15
5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15
5.2. Mitigating Spurious Service Discovery Messages . . . . . 17 5.2. Mitigating Spurious Service Discovery Messages . . . . . 17
6. Multicast Considerations for Other Wireless Media . . . . . . 17 6. Multicast Considerations for Other Wireless Media . . . . . . 17
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18
8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes in this draft between revisions 05 versus 06 23 Appendix A. Changes in this draft between revisions 06 versus 07 23
Appendix B. Changes in this draft between revisions 04 versus 05 23 Appendix B. Changes in this draft between revisions 05 versus 06 23
Appendix C. Changes in this draft between revisions 03 versus 04 24 Appendix C. Changes in this draft between revisions 04 versus 05 23
Appendix D. Changes in this draft between revisions 03 versus 04 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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], [mc-props], [mc-prob-stmt], and other multicast in 802.11 [dot11] and other local-area wireless
local-area wireless environments. Performance issues have been environments, as described in [mc-props], [mc-prob-stmt].
observed when multicast packet transmissions of IETF protocols are Performance issues have been observed when multicast packet
used over IEEE 802 wireless media. Even though enhancements for transmissions of IETF protocols are used over IEEE 802 wireless
multicast transmissions have been designed at both IETF and IEEE 802, media. Even though enhancements for multicast transmissions have
incompatibilities still exist between specifications, implementations been designed at both IETF and IEEE 802, incompatibilities still
and configuration choices. exist between specifications, implementations and configuration
choices.
Many IETF protocols depend on multicast/broadcast for delivery of Many IETF protocols depend on multicast/broadcast for delivery of
control messages to multiple receivers. Multicast is used for control messages to multiple receivers. Multicast is used for
various purposes such as neighbor discovery, network flooding, various purposes such as neighbor discovery, network flooding,
address resolution, as well minimizing media occupancy for the address resolution, as well minimizing media occupancy for the
transmission of data that is intended for multiple receivers. In transmission of data that is intended for multiple receivers. In
addition to protocol use of broadcast/multicast for control messages, addition to protocol use of broadcast/multicast for control messages,
more applications, such as push to talk in hospitals, or video in more applications, such as push to talk in hospitals, or video in
enterprises, universities, and homes, are sending multicast IP to end enterprises, universities, and homes, are sending multicast IP to end
user devices, which are increasingly using Wi-Fi for their user devices, which are increasingly using Wi-Fi for their
skipping to change at page 10, line 6 skipping to change at page 10, line 6
multicast and broadcast traffic. Due to hardware filtering (see, multicast and broadcast traffic. Due to hardware filtering (see,
e.g., [Deri-2010]), inadvertently flooded traffic (or excessive e.g., [Deri-2010]), inadvertently flooded traffic (or excessive
ethernet multicast) on wired networks can be quite a bit less costly, ethernet multicast) on wired networks can be quite a bit less costly,
compared to wireless cases where sleeping devices have to wake up to compared to wireless cases where sleeping devices have to wake up to
process packets. Wired Ethernets tend to be switched networks, process packets. Wired Ethernets tend to be switched networks,
further reducing interference from multicast. There is effectively further reducing interference from multicast. There is effectively
no collision / scheduling problem except at extremely high port no collision / scheduling problem except at extremely high port
utilizations. utilizations.
This is not true in the wireless realm; wireless equipment is often This is not true in the wireless realm; wireless equipment is often
unable to send high volumes of broadcast and multicast traffic. unable to send high volumes of broadcast and multicast traffic,
Consequently, on the wireless networks, a significant number of causing numerous broadcast and multicast packets to be dropped.
dropped broadcast and multicast packets are observed. This, in turn, Consequently, when a host connects it is often not able to complete
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 DHCP, and IPv6 RAs get dropped, leading to users being unable to use
the network. the network.
4. Multicast protocol optimizations 4. Multicast protocol optimizations
This section lists some optimizations that have been specified in This section lists some optimizations that have been specified in
IEEE 802 and IETF that are aimed at reducing or eliminating the IEEE 802 and IETF that are aimed at reducing or eliminating the
issues discussed in Section 3. issues discussed in Section 3.
4.1. Proxy ARP in 802.11-2012 4.1. Proxy ARP in 802.11-2012
skipping to change at page 14, line 35 skipping to change at page 14, line 35
4.5.4. Automatic Multicast Tunneling (AMT) 4.5.4. Automatic Multicast Tunneling (AMT)
AMT[RFC7450] provides a method to tunnel multicast IP packets inside AMT[RFC7450] provides a method to tunnel multicast IP packets inside
unicast IP packets over network links that only support unicast. unicast IP packets over network links that only support unicast.
When an operating system or application running on an STA has an AMT When an operating system or application running on an STA has an AMT
gateway capability integrated, it's possible to use unicast to gateway capability integrated, it's possible to use unicast to
traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi
portion of the network connected to the AP. portion of the network connected to the AP.
It is RECOMMENDED that multicast-enabled networks deploying AMT It is RECOMMENDED that multicast-enabled networks deploying AMT
relays for this purpose make the relays discoverable with the relays for this purpose make the relays locally discoverable with the
following methods: following methods, as described in
[I-D.ietf-mboned-driad-amt-discovery]:
o DNS-SD [RFC6763] o DNS-SD [RFC6763]
o the well-known IP addresses from Section 7 of [RFC7450], and o the well-known IP addresses from Section 7 of [RFC7450]
o DRIAD [I-D.ietf-mboned-driad-amt-discovery]
Providing the multiple standard discovery methods makes it more An AMT gateway that implements multiple standard discovery methods is
likely that AMT gateway implementations will discover the local more likely to discover the local multicast-capable network, instead
multicast-capable network, rather than forming a connection to an AMT of forming a connection to an AMT relay further upstream.
relay further upstream.
4.6. GroupCast with Retries (GCR) 4.6. GroupCast with Retries (GCR)
GCR (defined in [dot11aa]) provides greater reliability by using GCR (defined in [dot11aa]) provides greater reliability by using
either unsolicited retries or a block acknowledgement mechanism. GCR either unsolicited retries or a block acknowledgement mechanism. GCR
increases probability of broadcast frame reception success, but still increases probability of broadcast frame reception success, but still
does not guarantee success. does not guarantee success.
For the block acknowledgement mechanism, the AP transmits each group For the block acknowledgement mechanism, the AP transmits each group
addressed frame as conventional group addressed transmission. addressed frame as conventional group addressed transmission.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
An ARP Sponge sits on a network and learn which IP 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 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 (the sponge daemons were not really designed for this use (one of
standard one [arpsponge], was designed to deal with the the most widely deployed arp sponges [arpsponge], was designed
disappearance of participants from an IXP) and so are not to deal with the disappearance of participants from an IXP) and
optimized for this purpose. One daemon is needed per subnet, so are not optimized for this purpose. One daemon is needed
the tuning is tricky (the scanning rate versus the population per subnet, the tuning is tricky (the scanning rate versus the
rate versus retires, etc.) and sometimes the daemons just seem population rate versus retires, etc.) and sometimes the daemons
to stop, requiring a restart of the daemon and causing just seem to stop, requiring a restart of the daemon and
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 network and often do not support this. When a host connects to network and
gets an IP address, it will ARP for its default gateway (the gets an IP address, it will ARP for its default gateway (the
router). The router will update its cache with the IP to host router). The router will update its cache with the IP to host
MAC mapping learnt from the request (passive ARP learning). MAC mapping learnt from the request (passive ARP learning).
Firewall unused space Firewall unused space
The distribution of users on wireless networks / subnets The distribution of users on wireless networks / subnets
changes from IETF meeting to the next (e.g SSIDs are renamed, changes from one IETF meeting to the next (e.g SSIDs are
some SSIDs lose favor, etc). This makes utilization for renamed, some SSIDs lose favor, etc). This makes utilization
particular SSIDs difficult to predict ahead of time, but usage for particular SSIDs difficult to predict ahead of time, but
can be monitored as attendees use the different networks. usage can be monitored as attendees use the different networks.
Configuring multiple DHCP pools per subnet, and enabling them Configuring multiple DHCP pools per subnet, and enabling them
sequentially, can create a large subnet, from which only sequentially, can create a large subnet, from which only
addresses in the lower portions are assigned. Therefore input addresses in the lower portions are assigned. Therefore input
IP access lists can be applied, which deny traffic to the IP access lists can be applied, which deny traffic to the
upper, unused portions. Then the router does not attempt to upper, unused portions. Then the router does not attempt to
forward packets to the unused portions of the subnets, and so forward packets to the unused portions of the subnets, and so
does not ARP for it. This method has proven to be very does not ARP for it. This method has proven to be very
effective, but is somewhat of a blunt axe, is fairly labor effective, but is somewhat of a blunt axe, is fairly labor
intensive, and requires coordination. intensive, and requires coordination.
skipping to change at page 19, line 45 skipping to change at page 19, line 45
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, Pascal Thubert, Jeffrey Jaeggli, Jan Komissar, David Lamparter, Pascal Thubert, Jeffrey
(Zhaohui) Zhang (Zhaohui) Zhang
12. Informative References 12. Informative References
[arpsponge] [arpsponge]
Vijn, A. and S. Bakker, "Arp Sponge", March 2015, Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address
<https://ams-ix.net/downloads/arpsponge/3.12.2/arpsponge- resolution on AMS-IX and the ARP Sponge", July 2009,
3.12.2/arpsponge.txt>. <http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.182.4692>.
[bridge-mc-2-uc] [bridge-mc-2-uc]
Torvalds, L., "bridge: multicast to unicast", Jan 2017, Fietkau, F., "bridge: multicast to unicast", Jan 2017,
<https://github.com/torvalds/linux/ <https://github.com/torvalds/linux/
commit/6db6f0eae6052b70885562e1733896647ec1d807>. commit/6db6f0eae6052b70885562e1733896647ec1d807>.
[Deri-2010] [Deri-2010]
Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet
Filtering Using Commodity Network Adapters", RIPE 61, Filtering Using Commodity Network Adapters", RIPE 61,
2010, <http://ripe61.ripe.net/ 2010, <http://ripe61.ripe.net/
presentations/138-Deri_RIPE_61.pdf>. presentations/138-Deri_RIPE_61.pdf>.
[dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for [dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for
Information technology--Telecommunications and information Information technology--Telecommunications and information
exchange between systems Local and metropolitan area exchange between systems Local and metropolitan area
networks--Specific requirements - Part 11: Wireless LAN networks--Specific requirements - Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Medium Access Control (MAC) and Physical Layer (PHY)
Specification", March 2016, Specification (includes 802.11v amendment)", March 2016,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/findstds/
download/802.11-2016.pdf (includes 802.11v amendment)>. standard/802.11-2016.html>.
[dot11-proxyarp] [dot11-proxyarp]
"IEEE 802 Wireless P802.11", "IEEE 802 Wireless P802.11", Hiertz, G., Mestanov, F., and B. Hart, "Proxy ARP in
and "IEEE 802 Wireless P802.11", "Proxy ARP in 802.11ax", 802.11ax", September 2015,
September 2015, <https://mentor.ieee.org/802.11/ <https://mentor.ieee.org/802.11/
dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>. dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>.
[dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access [dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications Control (MAC) and Physical Layer (PHY) Specifications
Amendment 2: MAC Enhancements for Robust Audio Video Amendment 2: MAC Enhancements for Robust Audio Video
Streaming", March 2012, Streaming", March 2012,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/findstds/
download/802.11aa-2012.pdf>. standard/802.11aa-2012.pdf>.
[group_key] [group_key]
Spiff, ""Why do some WiFi routers block multicast packets Spiff, ""Why do some WiFi routers block multicast packets
going from wired to wireless?"", Jan 2017, going from wired to wireless?"", Jan 2017,
<https://superuser.com/questions/730288/why-do-some-wifi- <https://superuser.com/questions/730288/why-do-some-wifi-
routers-block-multicast-packets-going-from-wired-to- routers-block-multicast-packets-going-from-wired-to-
wireless>. wireless>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
skipping to change at page 23, line 15 skipping to change at page 23, line 21
[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/ <https://mentor.ieee.org/802.15/
dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>. dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>.
Appendix A. Changes in this draft between revisions 05 versus 06 Appendix A. Changes in this draft between revisions 06 versus 07
This section lists the changes between revisions ...-06.txt and
...-07.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Improved wording in section describing ARPsponge.
o Removed DRIAD as a discovery mechanism for multicast relays.
o Updated bibliographic citations, repaired broken URLs as needed.
o More editorial improvements and grammatical corrections.
Appendix B. Changes in this draft between revisions 05 versus 06
This section lists the changes between revisions ...-05.txt and This section lists the changes between revisions ...-05.txt and
...-06.txt of draft-ietf-mboned-ieee802-mcast-problems. ...-06.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Included new text in Security Considerations to alert about o Included new text in Security Considerations to alert about
problems regarding Group Key management caused by multicast problems regarding Group Key management caused by multicast
unreliability and implementation bugs. unreliability and implementation bugs.
o Included DRIAD as a discovery mechanism for multicast relays. o Included DRIAD as a discovery mechanism for multicast relays.
o Corrected occurrences of "which" versus "that" and "amount" versus o Corrected occurrences of "which" versus "that" and "amount" versus
"number". "number".
o Updated bibliographic citations, included URLs as needed. o Updated bibliographic citations, included URLs as needed.
o More editorial improvements and grammatical corrections. o More editorial improvements and grammatical corrections.
Appendix B. Changes in this draft between revisions 04 versus 05 Appendix C. Changes in this draft between revisions 04 versus 05
This section lists the changes between revisions ...-04.txt and This section lists the changes between revisions ...-04.txt and
...-05.txt of draft-ietf-mboned-ieee802-mcast-problems. ...-05.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Incorporated text from Jake Holland for a new section about o Incorporated text from Jake Holland for a new section about
conversion of multicast to unicast and included AMT as an existing conversion of multicast to unicast and included AMT as an existing
solution. solution.
o Included some text about likely future multicast applications that o Included some text about likely future multicast applications that
will emphasize the need for attention to the technical matters will emphasize the need for attention to the technical matters
collected in this document. collected in this document.
o Further modified text to be more generic instead of referring o Further modified text to be more generic instead of referring
specifically to IETF conference situations. specifically to IETF conference situations.
o Modified text to be more generic instead of referring specifically o Modified text to be more generic instead of referring specifically
to Bonjour. to Bonjour.
o Added uPnP as a representative multicast protocol in IP networks. o Added uPnP as a representative multicast protocol in IP networks.
o Referred to Linux bridging code for multicast to unicast. o Referred to Linux bridging code for multicast to unicast.
o Updated bibliographic citations, included URLs as needed. o Updated bibliographic citations, included URLs as needed.
skipping to change at page 24, line 5 skipping to change at page 24, line 17
collected in this document. collected in this document.
o Further modified text to be more generic instead of referring o Further modified text to be more generic instead of referring
specifically to IETF conference situations. specifically to IETF conference situations.
o Modified text to be more generic instead of referring specifically o Modified text to be more generic instead of referring specifically
to Bonjour. to Bonjour.
o Added uPnP as a representative multicast protocol in IP networks. o Added uPnP as a representative multicast protocol in IP networks.
o Referred to Linux bridging code for multicast to unicast. o Referred to Linux bridging code for multicast to unicast.
o Updated bibliographic citations, included URLs as needed. o Updated bibliographic citations, included URLs as needed.
o More editorial improvements and grammatical corrections. o More editorial improvements and grammatical corrections.
Appendix C. Changes in this draft between revisions 03 versus 04 Appendix D. Changes in this draft between revisions 03 versus 04
This section lists the changes between revisions ...-03.txt and This section lists the changes between revisions ...-03.txt and
...-04.txt of draft-ietf-mboned-ieee802-mcast-problems. ...-04.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Replaced "client" by "STA". o Replaced "client" by "STA".
o Used terminology "Wi-Fi" throughout. o Used terminology "Wi-Fi" throughout.
o Many editorial improvements and grammatical corrections. o Many editorial improvements and grammatical corrections.
o Modified text to be more generic instead of referring specifically o Modified text to be more generic instead of referring specifically
to IETF conference situations. to IETF conference situations.
o Cited [RFC5757] for introduction to other wireless media. o Cited [RFC5757] for introduction to other wireless media.
 End of changes. 21 change blocks. 
53 lines changed or deleted 65 lines changed or added

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