idnits 2.17.1 draft-ietf-mboned-ieee802-mcast-problems-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2018) is 1974 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ICMPv6' is mentioned on line 550, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-08 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-17 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area C. Perkins 3 Internet-Draft M. McBride 4 Intended status: Informational Futurewei 5 Expires: June 1, 2019 D. Stanley 6 HPE 7 W. Kumari 8 Google 9 JC. Zuniga 10 SIGFOX 11 November 28, 2018 13 Multicast Considerations over IEEE 802 Wireless Media 14 draft-ietf-mboned-ieee802-mcast-problems-04 16 Abstract 18 Well-known issues with multicast have prevented the deployment of 19 multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other 20 local-area wireless environments. This document offers guidance on 21 known limitations and problems with wireless multicast. Also 22 described are certain multicast enhancement features that have been 23 specified by the IETF and by IEEE 802 for wireless media, as well as 24 some operational choices that can be taken to improve the performace 25 of the network. Finally, some recommendations are provided about the 26 usage and combination of these features and operational choices. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 1, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Identified multicast issues . . . . . . . . . . . . . . . . . 5 65 3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5 66 3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5 67 3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 5 68 3.1.3. High Interference . . . . . . . . . . . . . . . . . . 6 69 3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7 70 3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7 71 3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8 72 3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8 73 3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 8 74 3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9 75 4. Multicast protocol optimizations . . . . . . . . . . . . . . 10 76 4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10 77 4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10 78 4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12 79 4.4. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12 80 4.5. Conversion of multicast to unicast . . . . . . . . . . . 13 81 4.6. Directed Multicast Service (DMS) . . . . . . . . . . . . 13 82 4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 13 83 5. Operational optimizations . . . . . . . . . . . . . . . . . . 14 84 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 14 85 6. Multicast Considerations for Other Wireless Media . . . . . . 16 86 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16 87 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 17 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 91 12. Informative References . . . . . . . . . . . . . . . . . . . 18 92 Appendix A. Changes between draft-ietf-mboned-ieee802-mcast- 93 problems revisions 03 versus 04 . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Performance issues have been observed when multicast packet 99 transmissions of IETF protocols are used over IEEE 802 wireless 100 media. Even though enhancements for multicast transmissions have 101 been designed at both IETF and IEEE 802, incompatibilities still 102 exist between specifications, implementations and configuration 103 choices. 105 Many IETF protocols depend on multicast/broadcast for delivery of 106 control messages to multiple receivers. Multicast is used for 107 various purposes such as neighbor discovery, network flooding, 108 address resolution, as well minimizing media occupancy for the 109 transmission of data that is intended for multiple receivers. In 110 addition to protocol use of broadcast/multicast for control messages, 111 more applications, such as push to talk in hospitals, or video in 112 enterprises, universities, and homes, are sending multicast IP to end 113 user devices, which are increasingly using wifi for their 114 connectivity. 116 IETF protocols typically rely on network protocol layering in order 117 to reduce or eliminate any dependence of higher level protocols on 118 the specific nature of the MAC layer protocols or the physical media. 119 In the case of multicast transmissions, higher level protocols have 120 traditionally been designed as if transmitting a packet to an IP 121 address had the same cost in interference and network media access, 122 regardless of whether the destination IP address is a unicast address 123 or a multicast or broadcast address. This model was reasonable for 124 networks where the physical medium was wired, like Ethernet. 125 Unfortunately, for many wireless media, the costs to access the 126 medium can be quite different. Multicast over Wi-Fi has often been 127 plagued by such poor performance that it is disallowed. Some 128 enhancements have been designed in IETF protocols that are assumed to 129 work primarily over wireless media. However, these enhancements are 130 usually implemented in limited deployments and not widespread on most 131 wireless networks. 133 IEEE 802 wireless protocols have been designed with certain features 134 to support multicast traffic. For instance, lower modulations are 135 used to transmit multicast frames, so that these can be received by 136 all stations in the cell, regardless of the distance or path 137 attenuation from the base station or access point. However, these 138 lower modulation transmissions occupy the medium longer; they hamper 139 efficient transmission of traffic using higher order modulations to 140 nearby stations. For these and other reasons, IEEE 802 working 141 groups such as 802.11 have designed features to improve the 142 performance of multicast transmissions at Layer 2 [ietf_802-11]. In 143 addition to protocol design features, certain operational and 144 configuration enhancements can ameliorate the network performance 145 issues created by multicast traffic, as described in Section 5. 147 There seems to be general agreement that these problems will not be 148 fixed anytime soon, primarily because it's expensive to do so, and 149 multicast is unreliable. Compared to unicast over Wi-Fi, multicast 150 is often treated as somewhat a second class citizen, even though 151 there are many protocols using multicast. Something needs to be 152 provided in order to make them more reliable. IPv6 neighbor 153 discovery saturating the Wi-Fi link is only part of the problem. Wi- 154 Fi traffic classes may help. This document is intended to help make 155 the determination about what problems should be solved by the IETF 156 and what problems should be solved by the IEEE (see Section 8). 158 This document details various problems caused by multicast 159 transmission over wireless networks, including high packet error 160 rates, no acknowledgements, and low data rate. It also explains some 161 enhancements that have been designed at IETF and IEEE 802 to 162 ameliorate the effects of multicast traffic. Recommendations are 163 also provided to implementors about how to use and combine these 164 enhancements. Some advice about the operational choices that can be 165 taken is also included. It is likely that this document will also be 166 considered relevant to designers of future IEEE wireless 167 specifications. 169 2. Terminology 171 This document uses the following definitions: 173 ACK 174 IEEE 802.11 Access Point 176 AP 177 The 802.11 layer 2 acknowledgement 179 basic rate 180 The slowest rate of all the connected devices, at which multicast 181 and broadcast traffic is generally transmitted 183 DTIM 184 Delivery Traffic Indication Map (DTIM): An information element 185 that advertises whether or not any associated stations have 186 buffered multicast or broadcast frames 188 MCS 189 Modulation and Coding Scheme 191 NOC 192 Network Operations Center 194 PER 195 Packet Error Rate 197 STA 198 802.11 station (e.g. handheld device) 200 TIM 201 Traffic Indication Map (TIM): An information element that 202 advertises whether or not any associated stations have buffered 203 unicast frames 205 3. Identified multicast issues 207 3.1. Issues at Layer 2 and Below 209 In this section we describe some of the issues related to the use of 210 multicast transmissions over IEEE 802 wireless technologies. 212 3.1.1. Multicast reliability 214 Multicast traffic is typically much less reliable than unicast 215 traffic. Since multicast makes point-to-multipoint communications, 216 multiple acknowledgements would be needed to guarantee reception at 217 all recipients. Since typically there are no ACKs for multicast 218 packets, it is not possible for the Access Point (AP) to know whether 219 or not a retransmission is needed. Even in the wired Internet, this 220 characteristic often causes undesirably high error rates. This has 221 contributed to the relatively slow uptake of multicast applications 222 even though the protocols have long been available. The situation 223 for wireless links is much worse, and is quite sensitive to the 224 presence of background traffic. Consequently, there can be a high 225 packet error rate (PER) due to lack of retransmission, and because 226 the sender never backs off. It is not uncommon for there to be a 227 packet loss rate of 5% or more, which is particularly troublesome for 228 video and other environments where high data rates and high 229 reliability are required. 231 3.1.2. Lower and Variable Data Rate 233 Multicast over wired differs from multicast over wireless because 234 transmission over wired links often occurs at a fixed rate. Wi-Fi, 235 on the other hand, has a transmission rate which varies depending 236 upon the STA's proximity to the AP. The throughput of video flows, 237 and the capacity of the broader Wi-Fi network, will change and will 238 impact the ability for QoS solutions to effectively reserve bandwidth 239 and provide admission control. 241 For wireless stations associated with an Access Point, the power 242 necessary for good reception can vary from station to station. For 243 unicast, the goal is to minimize power requirements while maximizing 244 the data rate to the destination. For multicast, the goal is simply 245 to maximize the number of receivers that will correctly receive the 246 multicast packet; generally the Access Point has to use a much lower 247 data rate at a power level high enough for even the farthest station 248 to receive the packet, for example as briefly mentioned in [RFC5757]. 249 Consequently, the data rate of a video stream, for instance, would be 250 constrained by the environmental considerations of the least reliable 251 receiver associated with the Access Point. 253 Because more robust modulation and coding schemes (MCSs) have longer 254 range but also lower data rate, multicast / broadcast traffic is 255 generally transmitted at the slowest rate of all the connected 256 devices, also known as the basic rate. The amount of additional 257 interference depends on the specific wireless technology. In fact 258 backward compatibility and multi-stream implementations mean that the 259 maximum unicast rates are currently up to a few Gb/s, so there can be 260 a more than 3 orders of magnitude difference in the transmission rate 261 between multicast / broadcast versus optimal unicast forwarding. 262 Some techinues employed to increase spectral efficiency, such as 263 spatial multiplexing in mimo systems, are not available with more 264 than one intended reciever; it is not the case that backwards 265 compatibility is the only factor responsible for lower multicast 266 transmission rates. 268 Wired multicast also affects wireless LANs when the AP extends the 269 wired segment; in that case, multicast / broadcast frames on the 270 wired LAN side are copied to WLAN. Since broadcast messages are 271 transmitted at the most robust MCS, many large frames are sent at a 272 slow rate over the air. 274 3.1.3. High Interference 276 Transmissions at a lower rate require longer occupancy of the 277 wireless medium and thus take away from the airtime of other 278 communications and degrade the overall capacity. Furthermore, 279 transmission at higher power, as is required to reach all multicast 280 STAs associated to the AP, proportionately increases the area of 281 interference. 283 3.1.4. Power-save Effects on Multicast 285 One of the characteristics of multicast transmission is that every 286 station has to be configured to wake up to receive the multicast, 287 even though the received packet may ultimately be discarded. This 288 process can have a large effect on the power consumption by the 289 multicast receiver station. 291 Multicast can work poorly with the power-save mechanisms defined in 292 IEEE 802.11e, for the following reasons. 294 o Clients may be unable to stay in sleep mode due to multicast 295 control packets frequently waking them up. 296 o Both unicast and multicast traffic can be delayed by power-saving 297 mechanisms. 298 o A unicast packet is delayed until a STA wakes up and requests it. 299 Unicast traffic may also be delayed to improve power save, 300 efficiency and increase probability of aggregation. 301 o Multicast traffic is delayed in a wireless network if any of the 302 STAs in that network are power savers. All STAs associated to the 303 AP have to be awake at a known time to receive multicast traffic. 304 o Packets can also be discarded due to buffer limitations in the AP 305 and non-AP STA. 307 3.2. Issues at Layer 3 and Above 309 This section identifies some representative IETF protocols, and 310 describes possible negative effects due to performance degradation 311 when using multicast transmissions for control messages. Common uses 312 of multicast include: 314 o Control plane signaling 315 o Neighbor Discovery 316 o Address Resolution 317 o Service discovery 318 o Applications (video delivery, stock data, etc.) 319 o On-demand routing 320 o Backbone construction 321 o Other L3 protocols (non-IP) 323 User Datagram Protocol (UDP) is the most common transport layer 324 protocol for multicast applications. By itself, UDP is not reliable 325 -- messages may be lost or delivered out of order. 327 3.2.1. IPv4 issues 329 The following list contains a few representative IPv4 protocols using 330 multicast. 332 o ARP 333 o DHCP 334 o mDNS 336 After initial configuration, ARP and DHCP occur much less commonly, 337 but service discovery can occur at any time. Apple's Bonjour 338 protocol, for instance, provides service discovery (for printing) 339 that utilizes multicast. It's often the first service that operators 340 drop. Even if multicast snooping is utilized, many devices can 341 register at once using Bonjour, causing serious network degradation. 343 3.2.2. IPv6 issues 345 IPv6 makes extensive use of multicast, including the following: 347 o DHCPv6 348 o IPv6 Neighbor Discovery Protocol (NDP) 349 o Duplicate Address Detection (DAD) 350 o Address Resolution 351 o Service Discovery 352 o Route Discovery 353 o Decentralized Address Assignment 354 o Geographic routing 356 IPv6 NDP Neighbor Solicitation (NS) messages used in DAD and Address 357 Lookup make use of Link-Scope multicast. In contrast to IPv4, an 358 IPv6 node will typically use multiple addresses, and may change them 359 often for privacy reasons. This intensifies the impact of multicast 360 messages that are associated to the mobility of a node. Router 361 advertisement (RA) messages are also periodically multicasted over 362 the Link. 364 Neighbors may be considered lost if several consecutive Neighbor 365 Discovery packets fail. 367 3.2.3. MLD issues 369 Multicast Listener Discovery(MLD) [RFC4541] is often used to identify 370 members of a multicast group that are connected to the ports of a 371 switch. Forwarding multicast frames into a Wi-Fi-enabled area can 372 use such switch support for hardware forwarding state information. 373 However, since IPv6 makes heavy use of multicast, each STA with an 374 IPv6 address will require state on the switch for several and 375 possibly many multicast solicited-node addresses. Multicast 376 addresses that do not have forwarding state installed (perhaps due to 377 hardware memory limitations on the switch) cause frames to be flooded 378 on all ports of the switch. 380 3.2.4. Spurious Neighbor Discovery 382 On the Internet there is a "background radiation" of scanning traffic 383 (people scanning for vulnerable machines) and backscatter (responses 384 from spoofed traffic, etc). This means that routers very often 385 receive packets destined for IP addresses regardless of whether they 386 are in use. In the cases where the IP is assigned to a host, the 387 router broadcasts an ARP request, gets back an ARP reply, and caches 388 it; then traffic can be delivered to the host. When the IP address 389 is not in use, the router broadcasts one (or more) ARP requests, and 390 never gets a reply. This means that it does not populate the ARP 391 cache, and the next time there is traffic for that IP address the 392 router will rebroadcast the ARP requests. 394 The rate of these ARP requests is proportional to the size of the 395 subnets, the rate of scanning and backscatter, and how long the 396 router keeps state on non-responding ARPs. As it turns out, this 397 rate is inversely proportional to how occupied the subnet is (valid 398 ARPs end up in a cache, stopping the broadcasting; unused IPs never 399 respond, and so cause more broadcasts). Depending on the address 400 space in use, the time of day, how occupied the subnet is, and other 401 unknown factors, on the order of 2000 broadcasts per second have been 402 observed, for instance at the NOCs during IETF face-to-face meetings. 404 On a wired network, there is not a huge difference between unicast, 405 multicast and broadcast traffic. Due to hardware filtering (see, 406 e.g., [Deri-2010]), inadvertently flooded traffic (or high amounts of 407 ethernet multicast) on wired networks can be quite a bit less costly, 408 compared to wireless cases where sleeping devices have to wake up to 409 process packets. Wired Ethernets tend to be switched networks, 410 further reducing interference from multicast. There is effectively 411 no collision / scheduling problem except at extremely high port 412 utilizations. 414 This is not true in the wireless realm; wireless equipment is often 415 unable to send high volumes of broadcast and multicast traffic. 416 Consequently, on the wireless networks, we observe a significant 417 amount of dropped broadcast and multicast packets. This, in turn, 418 means that when a host connects it is often not able to complete 419 DHCP, and IPv6 RAs get dropped, leading to users being unable to use 420 the network. 422 4. Multicast protocol optimizations 424 This section lists some optimizations that have been specified in 425 IEEE 802 and IETF that are aimed at reducing or eliminating the 426 issues discussed in Section 3. 428 4.1. Proxy ARP in 802.11-2012 430 The AP knows the MAC address and IP address for all associated STAs. 431 In this way, the AP acts as the central "manager" for all the 802.11 432 STAs in its BSS. Proxy ARP is easy to implement at the AP, and 433 offers the following advantages: 435 o Reduced broadcast traffic (transmitted at low MCS) on the wireless 436 medium 437 o STA benefits from extended power save in sleep mode, as ARP 438 requests for STA's IP address are handled instead by the AP. 439 o ARP frames are kept off the wireless medium. 440 o No changes are needed to STA implementation. 442 Here is the specification language as described in clause 10.23.13 of 443 [dot11-proxyarp]: 445 When the AP supports Proxy ARP "[...] the AP shall maintain a 446 Hardware Address to Internet Address mapping for each associated 447 station, and shall update the mapping when the Internet Address of 448 the associated station changes. When the IPv4 address being 449 resolved in the ARP request packet is used by a non-AP STA 450 currently associated to the BSS, the proxy ARP service shall 451 respond on behalf of the non-AP STA" 453 4.2. IPv6 Address Registration and Proxy Neighbor Discovery 455 As used in this section, a Low-Power Wireless Personal Area Network 456 (6LoWPAN) denotes a low power lossy network (LLN) that supports 457 6LoWPAN Header Compression (HC) [RFC6282]. A 6TiSCH network 458 [I-D.ietf-6tisch-architecture] is an example of a 6LowPAN. In order 459 to control the use of IPv6 multicast over 6LoWPANs, the 6LoWPAN 460 Neighbor Discovery (6LoWPAN ND) [RFC6775] standard defines an address 461 registration mechanism that relies on a central registry to assess 462 address uniqueness, as a substitute to the inefficient Duplicate 463 Address Detection (DAD) mechanism found in the mainstream IPv6 464 Neighbor Discovery Protocol (NDP) [RFC4861][RFC4862]. 466 The 6lo Working Group has specified an update [RFC8505] to RFC6775. 467 Wireless devices can register their address to a Backbone Router 468 [I-D.ietf-6lo-backbone-router], which proxies for the registered 469 addresses with the IPv6 NDP running on a high speed aggregating 470 backbone. The update also enables a proxy registration mechanism on 471 behalf of the registered node, e.g. by a 6LoWPAN router to which the 472 mobile node is attached. 474 The general idea behind the backbone router concept is that broadcast 475 and multicast messaging should be tightly controlled in a variety of 476 Wireless Local Area Networks (WLANs) and Wireless Personal Area 477 Networks (WPANs). Connectivity to a particular link that provides 478 the subnet should be left to Layer-3. The model for the Backbone 479 Router operation is represented in Figure 1. 481 | 482 +-----+ 483 | | Gateway (default) router 484 | | 485 +-----+ 486 | 487 | Backbone Link 488 +--------------------+------------------+ 489 | | | 490 +-----+ +-----+ +-----+ 491 | | Backbone | | Backbone | | Backbone 492 | | router 1 | | router 2 | | router 3 493 +-----+ +-----+ +-----+ 494 o o o o o o 495 o o o o o o o o o o o o o o 496 o o o o o o o o o o o o o o o 497 o o o o o o o o o o 498 o o o o o o o 500 LLN 1 LLN 2 LLN 3 502 Figure 1: Backbone Link and Backbone Routers 504 LLN nodes can move freely from an LLN anchored at one IPv6 Backbone 505 Router to an LLN anchored at another Backbone Router on the same 506 backbone, keeping any of the IPv6 addresses they have configured. 507 The Backbone Routers maintain a Binding Table of their Registered 508 Nodes, which serves as a distributed database of all the LLN Nodes. 509 An extension to the Neighbor Discovery Protocol is introduced to 510 exchange Binding Table information across the Backbone Link as needed 511 for the operation of IPv6 Neighbor Discovery. 513 RFC6775 and follow-on work [RFC8505] address the needs of LLNs, and 514 similar techniques are likely to be valuable on any type of link 515 where sleeping devices are attached, or where the use of broadcast 516 and multicast operations should be limited. 518 4.3. Buffering to Improve Battery Life 520 Methods have been developed to help save battery life; for example, a 521 device might not wake up when the AP receives a multicast packet. 522 The AP acts on behalf of STAs in various ways. To enable use of the 523 power-saving feature for STAs in its BSS, the AP buffers frames for 524 delivery to the STA at the time when the STA is scheduled for 525 reception. If an AP, for instance, expresses a DTIM (Delivery 526 Traffic Indication Message) of 3 then the AP will send a multicast 527 packet every 3 packets. In fact, when any single wireless STA 528 associated with an access point has 802.11 power-save mode enabled, 529 the access point buffers all multicast frames and sends them only 530 after the next DTIM beacon. 532 In practice, most AP's will send a multicast every 30 packets. For 533 unicast the AP could send a TIM (Traffic Indication Message), but for 534 multicast the AP sends a broadcast to everyone. DTIM does power 535 management but STAs can choose whether or not to wake up or not and 536 whether or not to drop the packet. Unfortunately, without proper 537 administrative control, such STAs may be unable to determine why 538 their multicast operations do not work. 540 4.4. IPv6 support in 802.11-2012 542 IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP. Every 543 IPv6 node subscribes to a special multicast address for this purpose. 545 Here is the specification language from clause 10.23.13 of 546 [dot11-proxyarp]: 548 "When an IPv6 address is being resolved, the Proxy Neighbor 549 Discovery service shall respond with a Neighbor Advertisement 550 message [...] on behalf of an associated STA to an [ICMPv6] 551 Neighbor Solicitation message [...]. When MAC address mappings 552 change, the AP may send unsolicited Neighbor Advertisement 553 Messages on behalf of a STA." 555 NDP may be used to request additional information 557 o Maximum Transmission Unit 558 o Router Solicitation 559 o Router Advertisement, etc. 561 NDP messages are sent as group addressed (broadcast) frames in 562 802.11. Using the proxy operation helps to keep NDP messages off the 563 wireless medium. 565 4.5. Conversion of multicast to unicast 567 It is often possible to transmit multicast control and data messages 568 by using unicast transmissions to each station individually. 570 4.6. Directed Multicast Service (DMS) 572 There are situations where more is needed than simply converting 573 multicast to unicast. For these purposes, DMS enables a STA to 574 request that the AP transmit multicast group addressed frames 575 destined to the requesting STAs as individually addressed frames 576 [i.e., convert multicast to unicast]. Here are some characteristics 577 of DMS: 579 o Requires 802.11n A-MSDUs 580 o Individually addressed frames are acknowledged and are buffered 581 for power save STAs 582 o The requesting STA may specify traffic characteristics for DMS 583 traffic 584 o DMS was defined in IEEE Std 802.11v-2011 585 o DMS requires changes to both AP and STA implementation. 587 DMS is not currently implemented in products. See [Tramarin2017] and 588 [Oliva2013] for more information. 590 4.7. GroupCast with Retries (GCR) 592 GCR (defined in [dot11aa]) provides greater reliability by using 593 either unsolicited retries or a block acknowledgement mechanism. GCR 594 increases probability of broadcast frame reception success, but still 595 does not guarantee success. 597 For the block acknowledgement mechanism, the AP transmits each group 598 addressed frame as conventional group addressed transmission. 599 Retransmissions are group addressed, but hidden from non-11aa STAs. 600 A directed block acknowledgement scheme is used to harvest reception 601 status from receivers; retransmissions are based upon these 602 responses. 604 GCR is suitable for all group sizes including medium to large groups. 605 As the number of devices in the group increases, GCR can send block 606 acknowledgement requests to only a small subset of the group. GCR 607 does require changes to both AP and STA implementation. 609 GCR may introduce unacceptable latency. After sending a group of 610 data frames to the group, the AP has do the following: 612 o unicast a Block Ack Request (BAR) to a subset of members. 614 o wait for the corresponding Block Ack (BA). 615 o retransmit any missed frames. 616 o resume other operations which may have been delayed. 618 This latency may not be acceptable for some traffic. 620 There are ongoing extensions in 802.11 to improve GCR performance. 622 o BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is 623 already specified in 802.11-REVmc 4.3). 624 o BA is sent using uplink MU-MIMO (which is a .11ax feature). 625 o Additional 802.11ax extensions are under consideration; see 626 [mc-ack-mux] 627 o Latency may also be reduced by simultaneously receiving BA 628 information from multiple STAs. 630 5. Operational optimizations 632 This section lists some operational optimizations that can be 633 implemented when deploying wireless IEEE 802 networks to mitigate the 634 issues discussed in Section 3. 636 5.1. Mitigating Problems from Spurious Neighbor Discovery 638 ARP Sponges 640 An ARP Sponge sits on a network and learn which IPs addresses 641 are actually in use. It also listen for ARP requests, and, if 642 it sees an ARP for an IP address which it believes is not used, 643 it will reply with its own MAC address. This means that the 644 router now has an IP to MAC mapping, which it caches. If that 645 IP is later assigned to an machine (e.g using DHCP), the ARP 646 sponge will see this, and will stop replying for that address. 647 Gratuitous ARPs (or the machine ARPing for its gateway) will 648 replace the sponged address in the router ARP table. This 649 technique is quite effective; but, unfortunately, the ARP 650 sponge daemons were not really designed for this use (the 651 standard one [arpsponge], was designed to deal with the 652 disappearance of participants from an IXP) and so are not 653 optimized for this purpose. We have to run one daemon per 654 subnet, the tuning is tricky (the scanning rate versus the 655 population rate versus retires, etc.) and sometimes the daemons 656 just seem to stop, requiring a restart of the daemon and 657 causing disruption. 659 Router mitigations 660 Some routers (often those based on Linux) implement a "negative 661 ARP cache" daemon. Simply put, if the router does not see a 662 reply to an ARP it can be configured to cache this information 663 for some interval. Unfortunately, the core routers which we 664 are using do not support this. When a host connects to network 665 and gets an IP address, it will ARP for its default gateway 666 (the router). The router will update its cache with the IP to 667 host MAC mapping learnt from the request (passive ARP 668 learning). 670 Firewall unused space 672 The distribution of users on wireless networks / subnets 673 changes from meeting to meeting (e.g SSIDs are renamed, some 674 SSIDs lose favor, etc). This makes utilization for particular 675 SSIDs difficult to predict ahead of time, but usage can be 676 monitored as attendees use the different networks. Configuring 677 multiple DHCP pools per subnet, and enabling them sequentially, 678 can create a large subnet, from which only addresses in the 679 lower portions are assigned. Therefore input IP access lists 680 can be applied, which deny traffic to the upper, unused 681 portions. Then the router does not attempt to forward packets 682 to the unused portions of the subnets, and so does not ARP for 683 it. This method has proven to be very effective, but is 684 somewhat of a blunt axe, is fairly labor intensive, and 685 requires coordination. 687 Disabling/filtering ARP requests 689 In general, the router does not need to ARP for hosts; when a 690 host connects, the router can learn the IP to MAC mapping from 691 the ARP request sent by that host. This means that we should 692 be able to disable and / or filter ARP requests from the 693 router. Unfortunately, ARP is a very low level / fundamental 694 part of the IP stack, and is often offloaded from the normal 695 control plane. While many routers can filter layer-2 traffic, 696 this is usually implemented as an input filter and / or has 697 limited ability to filter output broadcast traffic. This means 698 that the simple "just disable ARP or filter it outbound" seems 699 like a really simple (and obvious) solution, but 700 implementations / architectural issues make this difficult or 701 awkward in practice. 703 NAT 705 The broadcasts are overwhelmingly being caused by outside 706 scanning / backscatter traffic. This means that, if we were to 707 NAT the entire (or a large portion) of the attendee networks, 708 there would be no NAT translation entries for unused addresses, 709 and so the router would never ARP for them. However, there are 710 many reasons to avoid using NAT in such a blanket fashion. 712 Stateful firewalls 714 Another obvious solution would be to put a stateful firewall 715 between the wireless network and the Internet. This firewall 716 would block incoming traffic not associated with an outbound 717 request. But this conflicts with the need and desire to have 718 the network as open as possible / honor the end-to-end 719 principle. An attendee on the meeting network should be an 720 Internet host, and should be able to receive unsolicited 721 requests. Unfortunately, keeping the network working and 722 stable is the first priority and a stateful firewall may be 723 required in order to achieve this. 725 6. Multicast Considerations for Other Wireless Media 727 Many of the causes of performance degradation described in earlier 728 sections are also observable for wireless media other than 802.11. 730 For instance, problems with power save, excess media occupancy, and 731 poor reliability will also affect 802.15.3 and 802.15.4. 732 Unfortunately, 802.15 media specifications do not yet include 733 mechanisms similar to those developed for 802.11. In fact, the 734 design philosophy for 802.15 is oriented towards minimality, with the 735 result that many such functions are relegated to operation within 736 higher layer protocols. This leads to a patchwork of non- 737 interoperable and vendor-specific solutions. See [uli] for some 738 additional discussion, and a proposal for a task group to resolve 739 similar issues, in which the multicast problems might be considered 740 for mitigation. 742 Similar considerations hold for most other wireless media. A brief 743 introduction is provided in [RFC5757] for the following: 745 o 802.16 WIMAX 746 o 3GPP/3GPP2 747 o DVB-H / DVB-IPDC 748 o TV Broadcast and Satellite Networks 750 7. Recommendations 752 This section will provide some recommendations about the usage and 753 combinations of the multicast enhancements described in Section 4 and 754 Section 5. 756 Future protocol documents utilizing multicast signaling should be 757 carefully scrutinized if the protocol is likely to be used over 758 wireless media. 760 Proxy methods should be encouraged to conserve network bandwidth and 761 power utilization by low-power devices. The device can use a unicast 762 message to its proxy, and then the proxy can take care of any needed 763 multicast operations. 765 Multicast signaling for wireless devices should be done in a way 766 compatible with low-duty cycle operation. 768 (FFS) 770 8. Discussion Items 772 This section suggests two discussion items for further resolution. 774 The IETF should determine guidelines by which it may be decided that 775 multicast packets are to be sent wired. For example, 802.1ak works 776 on ethernet and Wi-Fi. 802.1ak has been pulled into 802.1Q as of 777 802.1Q-2011. 802.1Q-2014 can be found here: 778 http://www.ieee802.org/1/pages/802.1Q-2014.html. If a generic 779 solution is not found, guidelines for multicast over Wi-Fi should be 780 established. 782 Reliable registration to Layer-2 multicast groups and a reliable 783 multicast operation at Layer-2 might provide a generic solution. 784 There is no need to support 2^24 groups to get solicited node 785 multicast working: it is possible to simply select a number of 786 trailing bits that make sense for a given network size to limit the 787 amount of unwanted deliveries to reasonable levels. IEEE 802.1, 788 802.11, and 802.15 should be encouraged to revisit L2 multicast 789 issues. In reality, Wi-Fi provides a broadcast service, not a 790 multicast service. On the physical medium, all frames are broadcast 791 except in very unusual cases in which special beamforming 792 transmitters are used. Unicast offers the advantage of being much 793 faster (2 orders of magnitude) and much more reliable (L2 ARQ). 795 9. Security Considerations 797 This document does not introduce any security mechanisms, and does 798 not have affect existing security mechanisms. 800 10. IANA Considerations 802 This document does not request any IANA actions. 804 11. Acknowledgements 806 This document has benefitted from discussions with the following 807 people, in alphabetical order: Mikael Abrahamsson, Stuart Cheshire, 808 Donald Eastlake, Toerless Eckert, Jake Holland, Joel Jaeggli, Pascal 809 Thubert 811 12. Informative References 813 [arpsponge] 814 Arien Vijn, Steven Bakker, "Arp Sponge", March 2015. 816 [Deri-2010] 817 Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet 818 Filtering Using Commodity Network Adapters", RIPE 61, 819 2010, . 822 [dot11] P802.11, "802.11-2016 - IEEE Standard for Information 823 technology--Telecommunications and information exchange 824 between systems Local and metropolitan area networks-- 825 Specific requirements - Part 11: Wireless LAN Medium 826 Access Control (MAC) and Physical Layer (PHY) 827 Specification", March 2016. 829 [dot11-proxyarp] 830 P802.11, "Proxy ARP in 802.11ax", September 2015. 832 [dot11aa] P802.11, "Part 11: Wireless LAN Medium Access Control 833 (MAC) and Physical Layer (PHY) Specifications Amendment 2: 834 MAC Enhancements for Robust Audio Video Streaming", March 835 2012. 837 [I-D.ietf-6lo-backbone-router] 838 Thubert, P. and C. Perkins, "IPv6 Backbone Router", draft- 839 ietf-6lo-backbone-router-08 (work in progress), October 840 2018. 842 [I-D.ietf-6tisch-architecture] 843 Thubert, P., "An Architecture for IPv6 over the TSCH mode 844 of IEEE 802.15.4", draft-ietf-6tisch-architecture-17 (work 845 in progress), November 2018. 847 [ietf_802-11] 848 Dorothy Stanley, "IEEE 802.11 multicast capabilities", Nov 849 2015. 851 [mc-ack-mux] 852 Yusuke Tanaka et al., "Multiplexing of Acknowledgements 853 for Multicast Transmission", July 2015. 855 [mc-prob-stmt] 856 Mikael Abrahamsson and Adrian Stephens, "Multicast on 857 802.11", March 2015. 859 [mc-props] 860 Adrian Stephens, "IEEE 802.11 multicast properties", March 861 2015. 863 [Oliva2013] 864 de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, 865 "Performance evaluation of the IEEE 802.11aa multicast 866 mechanisms for video streaming", 2013 IEEE 14th 867 International Symposium on "A World of Wireless, Mobile 868 and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013. 870 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 871 "Considerations for Internet Group Management Protocol 872 (IGMP) and Multicast Listener Discovery (MLD) Snooping 873 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 874 . 876 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 877 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 878 DOI 10.17487/RFC4861, September 2007, 879 . 881 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 882 Address Autoconfiguration", RFC 4862, 883 DOI 10.17487/RFC4862, September 2007, 884 . 886 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 887 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 888 and Brief Survey", RFC 5757, DOI 10.17487/RFC5757, 889 February 2010, . 891 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 892 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 893 DOI 10.17487/RFC6282, September 2011, 894 . 896 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 897 Bormann, "Neighbor Discovery Optimization for IPv6 over 898 Low-Power Wireless Personal Area Networks (6LoWPANs)", 899 RFC 6775, DOI 10.17487/RFC6775, November 2012, 900 . 902 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 903 Perkins, "Registration Extensions for IPv6 over Low-Power 904 Wireless Personal Area Network (6LoWPAN) Neighbor 905 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 906 . 908 [Tramarin2017] 909 Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n 910 for Distributed Measurement Systems", 2017 IEEE 911 International Instrumentation and Measurement Technology 912 Conference (I2MTC) pp. 1-6, May 2017. 914 [uli] Pat Kinney, "LLC Proposal for 802.15.4", Nov 2015. 916 Appendix A. Changes between draft-ietf-mboned-ieee802-mcast-problems 917 revisions 03 versus 04 919 This section lists the changes between revisions ...-03.txt and 920 ...-04.txt of draft-ietf-mboned-ieee802-mcast-problems. 922 o Replaced "client" by "STA". 923 o Used terminology "Wi-Fi" throughout. 924 o Many editorial improvements and grammatical corrections. 925 o Modified text to be more generic instead of referring specifically 926 to IETF conference situations. 927 o Cited RFC 5757 [RFC5757] for introduction to other wireless media. 928 o Updated bibliographic citations. 930 Authors' Addresses 932 Charles E. Perkins 933 Futurewei Inc. 934 2330 Central Expressway 935 Santa Clara, CA 95050 936 USA 938 Phone: +1-408-330-4586 939 Email: charliep@computer.org 940 Mike McBride 941 Futurewei Inc. 942 2330 Central Expressway 943 Santa Clara, CA 95055 944 USA 946 Email: michael.mcbride@huawei.com 948 Dorothy Stanley 949 Hewlett Packard Enterprise 950 2000 North Naperville Rd. 951 Naperville, IL 60566 952 USA 954 Phone: +1 630 979 1572 955 Email: dstanley@arubanetworks.com 957 Warren Kumari 958 Google 959 1600 Amphitheatre Parkway 960 Mountain View, CA 94043 961 USA 963 Email: warren@kumari.net 965 Juan Carlos Zuniga 966 SIGFOX 967 425 rue Jean Rostand 968 Labege 31670 969 France 971 Email: j.c.zuniga@ieee.org