[要約] RFC 9119はIEEE 802無線メディア上でのマルチキャスト通信に関する考慮事項を扱っています。この文書の目的は、無線ネットワーク上でのマルチキャストの効率性と信頼性を向上させるためのガイドラインを提供することです。利用場面としては、Wi-Fiやその他のIEEE 802無線技術を使用するネットワークでのマルチキャスト配信の最適化が挙げられます。
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 9119 Lupin Lodge
Category: Informational M. McBride
ISSN: 2070-1721 Futurewei
D. Stanley
HPE
W. Kumari
Google
JC. Zúñiga
SIGFOX
October 2021
Multicast Considerations over IEEE 802 Wireless Media
IEEE 802ワイヤレスメディアに対するマルチキャスト考慮事項
Abstract
概要
Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 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 made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices.
マルチキャストに関する有名な問題は、802.11（Wi-Fi）およびその他のローカルエリアの無線環境におけるマルチキャストの展開を妨げてきました。この文書では、無線（主に802.11）のマルチキャストの既知の制限について説明します。また、無線メディア用のIETFおよびIEEE802によって指定された特定のマルチキャスト強調機能、ならびにネットワークのパフォーマンスを向上させるために行うことができるいくつかの動作選択が記載されている。最後に、これらの機能と運用選択の使用と組み合わせについての推奨事項がいくつか提供されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9119.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9119で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Identified Multicast Issues
3.1. Issues at Layer 2 and Below
3.1.1. Multicast Reliability
3.1.2. Lower and Variable Data Rate
3.1.3. Capacity and Impact on Interference
3.1.4. Power-Save Effects on Multicast
3.2. Issues at Layer 3 and Above
3.2.1. IPv4 Issues
3.2.2. IPv6 Issues
3.2.3. MLD Issues
3.2.4. Spurious Neighbor Discovery
4. Multicast Protocol Optimizations
4.1. Proxy ARP in 802.11-2012
4.2. IPv6 Address Registration and Proxy Neighbor Discovery
4.3. Buffering to Improve Battery Life
4.4. Limiting Multicast Buffer Hardware Queue Depth
4.5. IPv6 Support in 802.11-2012
4.6. Using Unicast Instead of Multicast
4.6.1. Overview
4.6.2. Layer 2 Conversion to Unicast
4.6.3. Directed Multicast Service (DMS)
4.6.4. Automatic Multicast Tunneling (AMT)
4.7. GroupCast with Retries (GCR)
5. Operational Optimizations
5.1. Mitigating Problems from Spurious Neighbor Discovery
5.2. Mitigating Spurious Service Discovery Messages
6. Multicast Considerations for Other Wireless Media
7. Recommendations
8. Ongoing Discussion Items
9. Security Considerations
10. IANA Considerations
11. Informative References
Acknowledgements
Authors' Addresses
Well-known issues with multicast have prevented the deployment of multicast in 802.11 [dot11] and other local-area wireless environments, as described in [mc-props] and [mc-prob-stmt]. 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.
マルチキャストに関する有名な問題は、[MC-Props]と[MC-POB-STMT]で説明されているように、802.11 [DOT11]およびその他のローカルエリアワイヤレス環境のマルチキャストの展開を防ぎました。IETFプロトコルのマルチキャストパケット送信がIEEE 802ワイヤレスメディアを介して使用されている場合、パフォーマンスの問題が観察されました。マルチキャスト送信の機能強化がIETFとIEEE 802の両方で設計されていても、仕様、実装、および構成の選択の間には依然として矛盾があります。
Many IETF protocols depend on multicast/broadcast for delivery of control messages to multiple receivers. Multicast allows data to be sent to multiple interested recipients without the source needing to send duplicate data to each recipient. With broadcast traffic, data is sent to every device regardless of their expressed interest in the data. Multicast is used for various purposes such as Neighbor Discovery, network flooding, and address resolution, as well as minimizing media occupancy for the transmission of data that is intended for multiple receivers. In addition to protocol use of broadcast/multicast for control messages, more applications, such as Push To Talk in hospitals or video in enterprises, universities, and homes, are sending multicast IP to end-user devices, which are increasingly using Wi-Fi for their connectivity.
多くのIETFプロトコルは、複数の受信機への制御メッセージの配信についてのマルチキャスト/ブロードキャストに依存します。マルチキャストを使用すると、各受信者に重複したデータを送信する必要があるソースが必要な場合、データを複数の利点の受信者に送信できます。ブロードキャストトラフィックでは、データへの表現関心に関係なくデータはすべてのデバイスに送信されます。マルチキャストは、近隣探索、ネットワークフラッディング、アドレス解決などのさまざまな目的に使用され、複数の受信機を対象としたデータの送信のためのメディアの占有率を最小限に抑えます。制御メッセージのためのブロードキャスト/マルチキャストのプロトコル使用に加えて、病院や企業のビデオ、大学、家庭でのビデオでのPushへのプッシュなどのアプリケーションは、マルチキャストIPをエンドユーザーデバイスに送信しています。これはますますWi-Fiを使用しています。彼らの接続性のために。
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 networks where the physical medium was wired, like Ethernet. Unfortunately, for many wireless media, the costs to access the medium can be quite different. Multicast over Wi-Fi has often been plagued by such poor performance that it is disallowed. Some enhancements have been designed in IETF protocols that are assumed to work primarily over wireless media. However, these enhancements are usually implemented in limited deployments and are not widespread on most wireless networks.
IETFプロトコルは、通常、高レベルのプロトコルの特定の性質上の依存性を低減または排除するために、ネットワークプロトコル階層化に依存しています。マルチキャスト送信の場合、上位レベルのプロトコルは、宛先IPアドレスがユニキャストアドレスであるかマルチキャストかにかかわらず、IPアドレスにパケットを送信するかのように、干渉およびネットワークメディアアクセスにおいて同じコストを有するかのように従来のプロトコルが設計されてきた。ブロードキャストアドレス。このモデルは、イーサネットのように物理媒体が配線されていたネットワークにとって合理的でした。残念ながら、多くのワイヤレスメディアの場合、媒体にアクセスするためのコストはかなり異なることがあります。 Wi-Fiを介したマルチキャストは、それが許可されていないそのような貧弱なパフォーマンスによって悩まされています。一部の機能強化は、主に無線メディアを介して動作すると仮定されているIETFプロトコルで設計されています。ただし、これらの機能強化は通常制限された展開で実装されており、ほとんどのワイヤレスネットワークでは広くない。
IEEE 802 wireless protocols have been designed with certain features to support multicast traffic. For instance, lower modulations are used to transmit multicast frames so that these can be received by all stations in the cell, regardless of the distance or path attenuation from the base station or Access Point (AP). However, these lower modulation transmissions occupy the medium longer; they hamper efficient transmission of traffic using higher-order modulations to nearby stations. For these and other reasons, IEEE 802 Working Groups such as 802.11 have designed features to improve the performance of multicast transmissions at Layer 2 [ietf_802-11]. In addition to protocol design features, certain operational and configuration enhancements can ameliorate the network performance issues created by multicast traffic, as described in Section 5.
IEEE 802ワイヤレスプロトコルは、マルチキャストトラフィックをサポートするための特定の機能で設計されています。例えば、より低い変調は、基地局またはアクセスポイント（AP）からの距離または経路減衰にかかわらず、これらがセル内のすべてのステーションによって受信されることができるようにマルチキャストフレームを送信するために使用される。しかしながら、これらの低い変調伝送は媒体を長く占めている。彼らは、近くの駅への高次変調を用いて効率的なトラフィックの伝送を妨げる。これらおよび他の理由で、802.11などのIEEE 802ワーキンググループは、レイヤ2 [IETF_802-11]でのマルチキャスト送信のパフォーマンスを向上させるための機能を設計しています。プロトコル設計機能に加えて、特定の動作および構成の機能強化は、セクション5で説明されているように、マルチキャストトラフィックによって作成されたネットワークパフォーマンスの問題を改善することができます。
There seems to be general agreement that these problems will not be fixed anytime soon, primarily because it's expensive to do so and because of the unreliability of multicast. Compared to unicast over Wi-Fi, multicast is often treated as somewhat of a second-class citizen even though there are many protocols using multicast. Something needs to be provided in order to make them more reliable. IPv6 Neighbor Discovery saturating the Wi-Fi link is only part of the problem. Wi-Fi traffic classes may help. This document is intended to help make the determination about what problems should be solved by the IETF and what problems should be solved by the IEEE (see Section 8).
一般的には、主に費用がかかり、マルチキャストの信頼性のため、これらの問題はすぐに固定されないという一般的な合意があるようです。Wi-Fiを介したユニキャストと比較して、マルチキャストを使用するプロトコルが多数あるとしても、マルチキャストはしばしば2級の市民の幾分扱われます。それらをより信頼できるようにするために何かを提供する必要があります。Wi-Fiリンクを飽和させるIPv6 Noible Discoveryは問題の一部です。Wi-Fiトラフィッククラスが役立ちます。この文書は、IETFによってどの問題を解決すべきか、そしてIEEEによってどのような問題を解決すべきかについての決定を下すことを目的としています（セクション8を参照）。
This document details various problems caused by multicast transmission over wireless networks, including high packet error rates, no acknowledgements, and low data rate. It also explains some enhancements that have been designed at the IETF and IEEE 802.11 to ameliorate the effects of the radio medium on multicast traffic. Recommendations are also provided to implementors about how to use and combine these enhancements. Some advice about the operational choices that can be made is also included. It is likely that this document will also be considered relevant to designers of future IEEE wireless specifications.
この文書は、高いパケットエラーレート、承認なし、および低いデータレートを含む、無線ネットワークを介したマルチキャスト送信によって引き起こされるさまざまな問題について詳しく説明します。マルチキャストトラフィックに対する無線媒体の影響を改善するために、IETFおよびIEEE 802.11で設計されているいくつかの機能強化についても説明します。これらの機能強化の使用方法と組み合わせ方法については、実装者にも推奨事項を提供しています。作ることができる運用の選択に関するいくつかのアドバイスも含まれています。この文書は将来のIEEEワイヤレス仕様の設計者にも関連すると見なされる可能性があります。
This document uses the following definitions:
この文書では、次の定義を使用します。
ACK The 802.11 Layer 2 acknowledgement.
ACK 802.11レイヤ2の確認応答。
AES-CCMP AES-Counter Mode CBC-MAC Protocol
AES-CCMP AESカウンタモードCBC-MACプロトコル
AP IEEE 802.11 Access Point.
AP IEEE 802.11アクセスポイント。
Basic rate The slowest rate of all the connected devices at which multicast and broadcast traffic is generally transmitted.
基本レートマルチキャストトラフィックとブロードキャストトラフィックが一般的に送信されるすべての接続されたすべてのデバイスの遅いレート。
DVB-H Digital Video Broadcasting - Handheld
DVB-Hデジタルビデオ放送 - ハンドヘルド
DVB-IPDC Digital Video Broadcasting - Internet Protocol Datacasting
DVB-IPDCデジタルビデオ放送 - インターネットプロトコルデータキャスト
DTIM Delivery Traffic Indication Map; an information element that advertises whether or not any associated stations have buffered multicast or broadcast frames.
DTIM配信トラフィック表示マップ。関連局がバッファされているかブロードキャストフレームを有するか否かをアドバタイズする情報要素。
MCS Modulation and Coding Scheme.
MCS変調と符号化方式
NOC Network Operations Center.
NOCネットワークオペレーションセンター。
PER Packet Error Rate.
パケット誤り率あたり。
STA 802.11 station (e.g., handheld device).
STA 802.11ステーション（例えば、ハンドヘルド装置）。
TIM Traffic Indication Map; an information element that advertises whether or not any associated stations have buffered unicast frames.
TIMトラフィック表示マップ。関連するステーションにバッファされたユニキャストフレームがあるかどうかをアドバタイズする情報要素。
TKIP Temporal Key Integrity Protocol
TKIP Temporal Key Integrity Protocol.
WiMAX Worldwide Interoperability for Microwave Access
マイクロ波アクセスのためのWiMAXの世界的な相互運用性
WPA Wi-Fi Protected Access
WPA Wi-Fi保護されたアクセス
In this section, some of the issues related to the use of multicast transmissions over IEEE 802 wireless technologies are described.
このセクションでは、IEEE 802ワイヤレス技術上のマルチキャスト送信の使用に関連するいくつかの問題が説明されている。
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. However, since there are no ACKs for multicast packets, it is not possible for the AP to know whether or not a retransmission is needed. Even in the wired Internet, this characteristic often causes undesirably high error rates. This has contributed to the relatively slow uptake of multicast applications even though the protocols have long been available. The situation for wireless links is much worse and is quite sensitive to the presence of background traffic. Consequently, there can be a high packet error rate (PER) due to lack of retransmission and because the sender never backs off. PER is the ratio, in percent, of the number of packets not successfully received by the device. It is not uncommon for there to be a packet loss rate of 5% or more, which is particularly troublesome for video and other environments where high data rates and high reliability are required.
マルチキャストトラフィックは通常、ユニキャストトラフィックよりもはるかに信頼性が低いです。マルチキャストはポイントツーマルチポイント通信を行うので、すべての受信者での受信を保証するために複数の承認が必要になるでしょう。ただし、マルチキャストパケット用のACKがないため、APが再送信が必要かどうかを知ることはできません。有線インターネットでさえ、この特徴はしばしば望ましくないエラー率を引き起こす。これは、プロトコルが長い間利用されていても、マルチキャストアプリケーションの比較的遅い取り込みに貢献しました。ワイヤレスリンクの状況ははるかに悪く、バックグラウンドトラフィックの存在に非常に敏感です。その結果、再送信がないため、および送信者が復帰しないため、高いパケットエラーレート（PER）がある可能性があります。 PERは、デバイスによって正常に受信されなかったパケットの数の割合で、パーセントの比率です。 5％以上のパケット損失率があることは珍しくありません。これは、高いデータレートと高い信頼性が要求されるビデオやその他の環境にとって特に面倒です。
Multicast over wired differs from multicast over wireless because transmission over wired links often occurs at a fixed rate. Wi-Fi, on the other hand, has a transmission rate that varies depending upon the STA's proximity to the AP. The throughput of video flows and the capacity of the broader Wi-Fi network will change with device movement. This impacts the ability for QoS solutions to effectively reserve bandwidth and provide admission control.
有線でのマルチキャストは、有線リンクを介した伝送が一定の割合で行われるため、ワイヤレス上のマルチキャストとは異なります。一方、Wi-Fiは、STAのAPの近さに応じて変化する伝送速度を持ちます。ビデオフローのスループットとより広いWi-Fiネットワークの容量は、デバイスの動きによって変わります。これは、QoSソリューションが帯域幅を効果的に予約し、入場管理を提供する能力に影響を与えます。
For wireless stations authenticated and linked with an AP, the power necessary for good reception can vary from station to station. For unicast, the goal is to minimize power requirements while maximizing the data rate to the destination. For multicast, the goal is simply to maximize the number of receivers that will correctly receive the multicast packet; generally, the AP has to use a much lower data rate at a power level high enough for even the farthest station to receive the packet, for example, as briefly mentioned in Section 4 of [RFC5757]. Consequently, the data rate of a video stream, for instance, would be constrained by the environmental considerations of the least-reliable receiver associated with the AP.
AP認証およびAPとリンクされている無線局の場合、優れたレセプションに必要な電力はステーションからステーションごとに異なります。ユニキャストの場合、目的はデータレートを最大化しながら電力要件を最小限に抑えることです。マルチキャストの場合、目標は、マルチキャストパケットを正しく受信する受信機の数を最大化することです。一般に、APは、例えば、[RFC5757]のセクション4において、最後のステーションでさえパケットを受信するのに十分な高出力ではるかに低いデータレートを使用する必要がある。したがって、例えば、ビデオストリームのデータレートは、APに関連付けられている最小信頼性の低い受信機の環境上の考慮事項によって制約されるであろう。
Because more robust modulation and coding schemes (MCSs) have a longer range but also a lower data rate, multicast/broadcast traffic is generally transmitted at the slowest rate of all the connected devices. This is also known as the basic rate. The amount of additional interference depends on the specific wireless technology. In fact, backward compatibility and multi-stream implementations mean that the maximum unicast rates are currently up to a few Gbps, so there can be more than 3 orders of magnitude difference in the transmission rate between multicast/broadcast versus optimal unicast forwarding. Some techniques employed to increase spectral efficiency, such as spatial multiplexing in Multiple Input Multiple Output (MIMO) systems, are not available with more than one intended receiver; it is not the case that backwards compatibility is the only factor responsible for lower multicast transmission rates.
より堅牢な変調および符号化方式（MCSS）がより長い範囲であるだけでなく、より低いデータレートもあるので、マルチキャスト/ブロードキャストトラフィックは一般に、接続されているすべてのデバイスの最も遅い速度で送信される。これは基本レートとしても知られています。追加の干渉の量は特定の無線技術に依存します。実際、下位互換性とマルチストリーム実装は、最大ユニキャストレートが現在数Gbpsまでであることを意味します。したがって、マルチキャスト/ブロードキャストと最適なユニキャスト転送の間の伝送速度に3桁以上の違いがある可能性があります。複数の入力多出力（MIMO）システムにおける空間多重化などのスペクトル効率を高めるために使用されるいくつかの技法は、1つ以上の意図された受信機では利用できない。下位互換性が低いマルチキャスト伝送速度の責任ある唯一の要因であるという事実ではありません。
Wired multicast also affects wireless LANs when the AP extends the wired segment; in that case, multicast/broadcast frames on the wired LAN side are copied to the Wireless Local Area Network (WLAN). Since broadcast messages are transmitted at the most robust MCS, many large frames are sent at a slow rate over the air.
有線マルチキャストは、APが有線セグメントを拡張したときに無線LANにも影響します。その場合、有線LAN側のマルチキャスト/ブロードキャストフレームが無線ローカルエリアネットワーク（WLAN）にコピーされる。ブロードキャストメッセージは最も堅牢なMCSで送信されるので、多くの大きなフレームが空気の上で遅い速度で送信される。
Transmissions at a lower rate require longer occupancy of the wireless medium and thus take away from the airtime of other communications and degrade the overall capacity. Furthermore, transmission at higher power, as is required to reach all multicast STAs associated with the AP, proportionately increases the area of interference with other consumers of the radio spectrum.
より低いレートでの送信は、無線媒体のより長い占有率を必要とし、したがって他の通信の放送時間から離れて全体的な容量を劣化させる。さらに、APに関連するすべてのマルチキャストSTAに到達することが要求されるように、より高い電力での送信は、無線スペクトルの他の消費者との干渉の領域を比例して増加させる。
One of the characteristics of multicast transmission over Wi-Fi is that every station has to be configured to wake up to receive the multicast frame, even though the received packet may ultimately be discarded. This process can have a large effect on the power consumption by the multicast receiver station. For this reason, there are workarounds, such as Directed Multicast Service (DMS) described in Section 4, to prevent unnecessarily waking up stations.
Wi - Fiに対するマルチキャスト送信の特徴の1つは、受信したパケットが最終的に廃棄されていても、すべてのステーションがマルチキャストフレームを受信するように起動するように構成されなければならないことである。このプロセスは、マルチキャスト受信機局による消費電力に大きな影響を与える可能性がある。このため、局が局を目覚めさせるのを防ぐために、セクション4で説明されている有向マルチキャストサービス（DMS）などの回避策がある。
Multicast (and unicast) can work poorly with the power-save mechanisms defined in IEEE 802.11e for the following reasons.
マルチキャスト（およびユニキャスト）は、IEEE 802.11eで定義されている省電力メカニズムが以下の理由で働くことができます。
* Clients may be unable to stay in sleep mode due to multicast control packets frequently waking them up.
* 頻繁に目覚めさせるマルチキャスト制御パケットのため、クライアントがスリープモードに留まることができない場合があります。
* A unicast packet is delayed until an STA wakes up and requests it. Unicast traffic may also be delayed to improve power save and efficiency and to increase the probability of aggregation.
* STAが起動してそれを要求するまで、ユニキャストパケットが遅延されます。ユニキャストトラフィックはまた、省電力と効率を向上させ、集約の可能性を高めるために遅延され得る。
* Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated with the AP have to be awake at a known time to receive multicast traffic.
* そのネットワーク内のSTAのいずれかが省電力である場合、マルチキャストトラフィックは無線ネットワークで遅延されます。APに関連するすべてのSTAは、マルチキャストトラフィックを受信するために既知の時間に起こらなければならない。
* Packets can also be discarded due to buffer limitations in the AP and non-AP STA.
* APと非AP STAのバッファの制限によりパケットを破棄することもできます。
This section identifies some representative IETF protocols and describes possible negative effects due to performance degradation when using multicast transmissions for control messages. Common uses of multicast include:
このセクションでは、いくつかの代表的なIETFプロトコルを識別し、制御メッセージのマルチキャスト送信を使用する場合のパフォーマンスの低下による悪影響を説明します。マルチキャストの一般的な用途は次のとおりです。
* Control plane signaling
* 制御プレーンシグナリング
* Neighbor Discovery
* 近隣探索
* Address resolution
* アドレスの解決
* Service Discovery
* サービス発見
* Applications (video delivery, stock data, etc.)
* アプリケーション（ビデオ配信、株式データなど）
* On-demand routing
* オンデマンドルーティング
* Backbone construction
* バックボーンの建設
* Other Layer 3 protocols (non-IP)
* その他のレイヤ3プロトコル（非IP）
User Datagram Protocol (UDP) is the most common transport-layer protocol for multicast applications. By itself, UDP is not reliable -- messages may be lost or delivered out of order.
ユーザーデータグラムプロトコル（UDP）は、マルチキャストアプリケーションのための最も一般的なトランスポート層プロトコルです。それ自体では、UDPは信頼できません - メッセージが失われるか、または順不同で配信される可能性があります。
The following list contains some representative discovery protocols that utilize broadcast/multicast and are used with IPv4.
次のリストには、ブロードキャスト/マルチキャストを利用し、IPv4と共に使用されるいくつかの代表的な発見プロトコルが含まれています。
* ARP [RFC0826]
* ARP [RFC0826]
* DHCP [RFC2131]
* DHCP [RFC2131]
* Multicast DNS (mDNS) [RFC6762]
* マルチキャストDNS（MDNS）[RFC6762]
* Universal Plug and Play (uPnP) [RFC6970]
* ユニバーサルプラグアンドプレイ（UPnP）[RFC6970]
After initial configuration, ARP (described in more detail later), DHCP, and uPnP occur much less commonly, but service discovery can occur at any time. Some widely deployed service discovery protocols (e.g., for finding a printer) utilize mDNS (i.e., multicast), which is often dropped by operators. Even if multicast snooping [RFC4541] (which provides the benefit of conserving bandwidth on those segments of the network where no node has expressed interest in receiving packets addressed to the group address) is utilized, many devices can register at once and cause serious network degradation.
初期設定の後、ARP（後で後で詳しく説明）、DHCP、およびUPnPは一般的に一般的に発生しますが、サービス検出はいつでも発生する可能性があります。いくつかの広く展開されたサービス発見プロトコル（例えば、プリンタを検索するための）は、MDN（すなわちマルチキャスト）を利用しており、これはしばしば演算子によってドロップされる。たとえマルチキャストスヌーピング[RFC4541]（これは、ノードがグループアドレスに対処されているパケットの受信にノードを表すネットワークのセグメントに節約するという利点を提供するという利点を提供します）が利用され、多くのデバイスが一度に登録し、深刻なネットワーク劣化を引き起こす可能性がある。
IPv6 makes extensive use of multicast, including the following:
IPv6は次のものを含むマルチキャストを広く使用します。
* DHCPv6 [RFC8415]
* DHCPV6 [RFC8415]
* Protocol Independent Multicast (PIM) [RFC7761]
* プロトコル独立マルチキャスト（PIM）[RFC7761]
* IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]
* IPv6近隣探索プロトコル（NDP）[RFC4861]
* Multicast DNS (mDNS) [RFC6762]
* マルチキャストDNS（MDNS）[RFC6762]
* Router Discovery [RFC4286]
* ルーターディスカバリー[RFC4286]
IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate Address Detection (DAD) and address lookup make use of link-scope multicast. In contrast to IPv4, an IPv6 node will typically use multiple addresses and may change them often for privacy reasons. This intensifies the impact of multicast messages that are associated with the mobility of a node. Router advertisement (RA) messages are also periodically multicast over the link.
重複アドレス検出（DAD）およびアドレス検索で使用されるIPv6 NDPネイバー勧誘（NS）メッセージは、リンクスコープマルチキャストを利用しています。IPv4とは対照的に、IPv6ノードは通常複数のアドレスを使用し、プライバシー上の理由から頻繁に変更される可能性があります。これにより、ノードのモビリティに関連付けられているマルチキャストメッセージの影響が軽減されます。ルータ広告（RA）メッセージもリンク上で定期的にマルチキャストされています。
Neighbors may be considered lost if several consecutive Neighbor Discovery packets fail.
いくつかの連続した隣接発見パケットが失敗した場合、隣接者は失われたと見なすことができます。
Multicast Listener Discovery (MLD) [RFC4541] is used to identify members of a multicast group that are connected to the ports of a switch. Forwarding multicast frames into a Wi-Fi-enabled area can use switch support for hardware forwarding state information. However, since IPv6 makes heavy use of multicast, each STA with an IPv6 address will require state on the switch for several and possibly many solicited-node multicast addresses. A solicited-node multicast address is an IPv6 multicast address used by NDP to verify whether an IPv6 address is already used by the local link. Multicast addresses that do not have forwarding state installed (perhaps due to hardware memory limitations on the switch) cause frames to be flooded on all ports of the switch. Some switch vendors do not support MLD for link-scope multicast due to the increase it can cause in state.
Multicast Listener Discovery（MLD）[RFC4541]は、スイッチのポートに接続されているマルチキャストグループのメンバーを識別するために使用されます。マルチキャストフレームをWi-Fi対応エリアに転送すると、ハードウェア転送状態情報のスイッチサポートを使用できます。ただし、IPv6はマルチキャストを重く使用するため、IPv6アドレスを持つ各STAは、いくつかの要求ノードのマルチキャストアドレスのためのスイッチ上の状態が必要になります。勧誘ノードマルチキャストアドレスは、IPv6アドレスがローカルリンクによって既に使用されているかどうかを確認するために、NDPによって使用されるIPv6マルチキャストアドレスです。転送状態がインストールされていないマルチキャストアドレス（おそらくスイッチのハードウェアメモリの制限により）フレームをスイッチのすべてのポートにフラッディングさせる。一部のスイッチベンダは、その上昇の原因となるため、リンクスコープマルチキャストのためにMLDをサポートしません。
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 IPv4 addresses regardless of whether those IP addresses are in use. In the cases where the IP is assigned to a host, the router broadcasts an ARP request, receives 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.
インターネット上では、スキャントラフィック（脆弱なマシンをスキャンする人）と後方散乱の「背景放射線」があります（偽装されたトラフィックなどからの応答）。つまり、ルータは、それらのIPアドレスが使用されているかどうかにかかわらず、IPv4アドレス宛てのパケットを非常に頻繁に受け取ることを意味します。IPがホストに割り当てられている場合、ルータはARP要求をブロードキャストし、ARP応答を受信してキャッシュする。その後、トラフィックをホストに配信できます。IPアドレスが使用されていない場合、ルータは1つのARP要求をブロードキャストし、返信を取得しません。つまり、ARPキャッシュを入力しないことを意味し、次回そのIPアドレスのトラフィックがあるときに、ルータはARP要求を再送信します。
The rate of these ARP requests is proportional to the size of the subnets, the rate of scanning and backscatter, and how long the router keeps state on non-responding ARPs. As it turns out, this rate is inversely proportional to how occupied the subnet is (valid ARPs end up in a cache, stopping the broadcasting; unused IPs never respond, and so cause more broadcasts). Depending on the address space in use, the time of day, how occupied the subnet is, and other unknown factors, thousands of broadcasts per second have been observed. Around 2,000 broadcasts per second have been observed at the IETF NOC during face-to-face meetings.
これらのARP要求の割合は、サブネットのサイズ、スキャン率、および後方散乱の速度、およびルータが非対応するARPで状態を保持する期間に比例します。最適なので、このレートはサブネットがどのように占有されているかに反比例します（有効なARPはキャッシュ内に進み、ブロードキャストを停止します。未使用のIPSは、それ以上の放送をもたらす）。使用中のアドレス空間、日の時間、サブネットの占有方法、およびその他の未知の要因、毎秒何千もの放送が観察されました。対面会議中にIETF NOCで毎秒約2,000の放送が見られました。
With Neighbor Discovery for IPv6 [RFC4861], nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. Neighbor Solicitation messages are multicast to the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast Neighbor Advertisement message. A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation.
IPv6 [RFC4861]のネイバー・ディスカバリーを使用すると、ノードは、ターゲット・ノードにそのリンク層アドレスを返すように求める隣接勧誘をマルチキャストすることによってアドレス解決を実行します。隣接勧誘メッセージは、ターゲットアドレスの要求ノードマルチキャストアドレスにマルチキャストされています。ターゲットは、ユニキャストネイバーアドバタイズメントメッセージでリンクレイヤアドレスを返します。単一の要求応答のパケットのペアは、イニシエータとターゲットの両方が互いのリンク層アドレスを解決するのに十分です。イニシエータは、隣接勧誘におけるリンク層アドレスを含む。
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 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.
有線ネットワークでは、ユニキャスト、マルチキャスト、およびブロードキャストトラフィックの間に大きな違いはありません。ハードウェアフィルタリング（例えば、[DERI-2010]参照）のために、有線ネットワーク上の誤ってフラッドトラフィック（または過度のイーサネットマルチキャスト）は、スリーピングデバイスがパケットを処理するために起動しなければならないワイヤレスケースとかなり費用がかからない。有線イーサネットはネットワークが切り替えられ、さらにマルチキャストからの干渉を減らす傾向があります。非常に高いポートの使用を除いて、衝突/スケジューリングの問題は効果的です。
This is not true in the wireless realm; wireless equipment is often unable to send high volumes of broadcast and multicast traffic, causing numerous broadcast and multicast packets to be dropped. Consequently, when a host connects, it is often not able to complete DHCP, and IPv6 RAs get dropped, leading to users being unable to use the network.
これはワイヤレスレルムには当てはまりません。無線機器は、多くの場合、大量のブロードキャストトラフィックとマルチキャストトラフィックを送信できず、多数のブロードキャストパケットとマルチキャストパケットをドロップします。その結果、ホストが接続すると、DHCPを完了できず、IPv6 RASがドロップされ、ユーザーがネットワークを使用できなくなります。
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.
このセクションでは、セクション3で説明した問題を軽減または削除することを目的としたIEEE 802およびIETFで指定された最適化を示します。
The AP knows the Medium Access Control (MAC) address and IP address for all associated STAs. In this way, the AP acts as the central "manager" for all the 802.11 STAs in its Basic Service Set (BSS). Proxy ARP is easy to implement at the AP and offers the following advantages:
APは、関連付けられているすべてのSTAの中アクセス制御（MAC）アドレスとIPアドレスを認識しています。このようにして、APは、その基本サービスセット（BSS）内のすべての802.11 STAの中央 "マネージャ"として機能します。Proxy ARPはAPで実装が簡単で、以下の利点があります。
* Reduced broadcast traffic (transmitted at low MCS) on the wireless medium.
* 無線媒体上のブロードキャストトラフィック（ローMCSで送信された）を縮小した。
* STA benefits from extended power save in sleep mode, as ARP requests for STA's IP address are handled instead by the AP.
* STAの利点スリープモードでは、STAのIPアドレスのARP要求がAPで代わりに処理されます。
* ARP frames are kept off the wireless medium.
* ARPフレームはワイヤレスメディアから保持されます。
* No changes are needed to STA implementation.
* STA実装に変更は不要です。
Here is the specification language as described in clause 10.23.13 of [dot11-proxyarp]:
これがDot11-Proxyarpの10.23.13号に記載されているような仕様言語です。
| When the AP supports Proxy ARP "[...] the AP shall maintain a
| Hardware Address to Internet Address mapping for each associated
| station, and shall update the mapping when the Internet Address of
| the associated station changes. When the IPv4 address being
| resolved in the ARP request packet is used by a non-AP STA
| currently associated to the BSS, the proxy ARP service shall
| respond on behalf of the STA to an ARP request or an ARP Probe.
As used in this section, a Low-Power Wireless Personal Area Network (6LoWPAN) denotes a Low-Power and Lossy Network (LLN) that supports 6LoWPAN Header Compression (HC) [RFC6282]. A 6TiSCH network [RFC9030] is an example of a 6LoWPAN. In order to control the use of IPv6 multicast over 6LoWPANs, the 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] standard defines an address registration mechanism that relies on a central registry to assess address uniqueness as a substitute to the inefficient DAD mechanism found in the mainstream IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] [RFC4862].
このセクションで使用されているように、低電力無線パーソナルエリアネットワーク（6LOWPAN）は、6LOWPANヘッダ圧縮（HC）[RFC6282]をサポートする低電力および非損失ネットワーク（LLN）を表す。6Tischネットワーク[RFC9030]は6LOWPANの一例です。6LOWPANを介してIPv6マルチキャストの使用を制御するために、6LOWPANネイバーディスカバリ（6LOWPAN ND）[RFC6775]標準は、中央レジストリに依存しているアドレス登録メカニズムを定義して、アドレスの一意性を評価しています。メインストリームIPv6ネイバーディスカバリプロトコル（NDP）[RFC4861] [RFC4862]。
The 6lo Working Group has specified an update to [RFC6775]. Wireless devices can register their address to a Backbone Router [RFC8929], which proxies for the registered addresses with the IPv6 NDP running on a high-speed aggregating backbone. The update also enables a proxy registration mechanism on behalf of the Registered Node, e.g., by a 6LoWPAN router to which the mobile node is attached.
6LOワーキンググループは[RFC6775]に更新を指定しました。ワイヤレスデバイスは、アドレスをバックボーンルータ[RFC8929]に登録できます。このアドレスは、登録アドレスが高速集計バックボーンで実行されているIPv6 NDPでプロキシを処理できます。この更新はまた、登録されたノード、例えば、モバイルノードが接続されている6LOWPANルータによって代わってプロキシ登録メカニズムを有効にする。
The general idea behind the Backbone Router concept is that broadcast and multicast messaging should be tightly controlled in a variety of WLANs and Wireless Personal Area Networks (WPANs). Connectivity to a particular link that provides the subnet should be left to Layer 3. The model for the Backbone Router operation is represented in Figure 1.
バックボーンルータの概念の背後にある一般的な考え方は、放送およびマルチキャストメッセージングがさまざまなWLANおよび無線個人エリアネットワーク（WPAN）で厳重に管理されるべきです。サブネットを提供する特定のリンクへの接続はレイヤ3に残されるべきです。バックボーンルータの動作のモデルは図1に示されています。
|
+-----+
| | Gateway (default) router
| |
+-----+
|
| Backbone Link
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
| | router 1 | | router 2 | | router 3
+-----+ +-----+ +-----+
o o o o o o
o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o
o o o o o o o o o o
o o o o o o o
LLN 1 LLN 2 LLN 3
LLN 1 LLN 2 LLN 3
Figure 1: Backbone Link and Backbone Routers
図1：バックボーンリンクとバックボーンルータ
LLN nodes can move freely from an LLN anchored at one IPv6 Backbone Router to an LLN anchored at another Backbone Router on the same backbone, keeping any of the IPv6 addresses they have configured. The Backbone Routers maintain a Binding Table of their Registered Nodes, which serves as a distributed database of all the LLN nodes. An extension to the Neighbor Discovery Protocol is introduced to exchange Binding Table information across the Backbone Link as needed for the operation of IPv6 Neighbor Discovery.
LLNノードは、1つのIPv6バックボーンルータに固定されたLLNから同じバックボーン上の別のバックボーンルータに固定されたLLNに自由に移動し、それらが設定したIPv6アドレスを保持します。バックボーンルータは、登録されたノードのバインディングテーブルを維持します。これは、すべてのLLNノードの分散データベースとして機能します。IPv6ネイバーディスカバリの動作に必要に応じて、近隣探索プロトコルへの拡張機能がバックボーンリンクを介してテーブル情報を交換するために導入されました。
[RFC6775] and follow-on work [RFC8505] address the needs of LLNs, and similar techniques are likely to be valuable on any type of link where sleeping devices are attached or where the use of broadcast and multicast operations should be limited.
[RFC6775]およびフォローオン・ワーク[RFC8505] LLNのニーズに対処すると、滑り機器が接続されている任意の種類のリンクで、または放送およびマルチキャスト操作の使用が制限されるべきである任意の種類のリンクに貴重なものがあります。
Methods have been developed to help save battery life; for example, a device might not wake up when the AP receives a multicast packet. The AP acts on behalf of STAs in various ways. To enable use of the power-saving feature for STAs in its BSS, the AP buffers frames for delivery to the STA at the time when the STA is scheduled for reception. If an AP, for instance, expresses a Delivery Traffic Indication Message (DTIM) of 3, then the AP will send a multicast packet every 3 packets. In fact, when any single wireless STA associated with an AP has 802.11 power-save mode enabled, the AP buffers all multicast frames and sends them only after the next DTIM beacon.
電池寿命を節約するための方法が開発されました。たとえば、APがマルチキャストパケットを受信したときにデバイスが起動しない場合があります。APは様々な方法でSTAに代わって行動します。そのBSS内のSTAの省電力機能の使用を可能にするために、STAが受信のためにスケジュールされたときのSTAへの配信のためのフレームをバッファする。例えば、APが3の配信トラフィック指示メッセージ（DTIM）を表す場合、APは3パケットごとにマルチキャストパケットを送信します。実際、APに関連付けられている1つのワイヤレスSTAが802.11のパワーセーブモードが有効になっている場合、APはすべてのマルチキャストフレームをバッファし、次のDTIMビーコンの後にのみ送信します。
In practice, most APs will send a multicast every 30 packets. For unicast, the AP could send a Traffic Indication Message (TIM), but, for multicast, the AP sends a broadcast to everyone. DTIM does power management, but STAs can choose whether to wake up and whether to drop the packet. Unfortunately, without proper administrative control, such STAs may be unable to determine why their multicast operations do not work.
実際には、ほとんどのAPは30パケットごとにマルチキャストを送信します。ユニキャストの場合、APはトラフィック表示メッセージ（TIM）を送信できますが、マルチキャストの場合、APはブロードキャストをみんなに送信します。DTIMは電源管理をしますが、STAは起動するかパケットをドロップするかどうかを選択できます。残念なことに、適切な管理管理を行わずに、そのようなSTAは、それらのマルチキャスト操作が機能しない理由を判断できないかもしれません。
The Content after Beacon (CAB) queue is used for beacon-triggered transmission of buffered multicast frames. If lots of multicast frames were buffered and this queue fills up, it drowns out all regular traffic. To limit the damage that buffered traffic can do, some drivers limit the amount of queued multicast data to a fraction of the beacon_interval. An example of this is [CAB].
ビーコン（CAB）キューの後のコンテンツは、バッファ付きマルチキャストフレームのビーコントリガ送信送信に使用されます。たくさんのマルチキャストフレームがバッファされていてこのキューが充填されている場合は、すべての通常のトラフィックを排出します。バッファされたトラフィックができる損傷を制限するために、一部のドライバはキューに入れられたマルチキャストデータの量をBEACON_INTERVALの端数に制限します。この例は[CAB]です。
IPv6 uses NDP instead of ARP. Every IPv6 node subscribes to a special multicast address for this purpose.
IPv6はARPの代わりにNDPを使用します。すべてのIPv6ノードは、この目的のための特別なマルチキャストアドレスを購読します。
Here is the specification language from clause 10.23.13 of [dot11-proxyarp]:
これが[Dot11-Proxyarp]の10.23.13からの仕様言語です。
| When an IPv6 address is being resolved, the Proxy Neighbor
| Discovery service shall respond with a Neighbor Advertisement
| message [...] on behalf of an associated STA to an [ICMPv6]
| Neighbor Solicitation message [...]. When MAC address mappings
| change, the AP may send unsolicited Neighbor Advertisement
| Messages on behalf of a STA.
NDP may be used to request additional information using the following methods, among others:
次の方法を使用して追加情報を要求するために、NDPを使用することができます。
* Maximum Transmission Unit
* 最大伝送単位
* Router Solicitation
* ルーターの勧誘
* Router Advertisement
* ルーター広告
NDP messages are sent as group-addressed (broadcast) frames in 802.11. Using the proxy operation helps to keep NDP messages off the wireless medium.
NDPメッセージは、802.11でグループアドレス（ブロードキャスト）フレームとして送信されます。プロキシ操作を使用すると、NDPメッセージをワイヤレスメディアから保存するのに役立ちます。
It is often possible to transmit multicast control and data messages by using unicast transmissions to each station individually.
各ステーションへのユニキャスト送信を個別に各ステーションに使用することによってマルチキャスト制御およびデータメッセージを送信することが可能である。
In many situations, it's a good choice to use unicast instead of multicast over the Wi-Fi link. This avoids most of the problems specific to multicast over Wi-Fi, since the individual frames are then acknowledged and buffered for power-save clients in the way that unicast traffic normally operates.
多くの状況では、Wi-Fiリンクを介してマルチキャストの代わりにユニキャストを使用することができます。ユニキャストトラフィックが正常に動作するように、個々のフレームは省電力クライアントに承認されバッファされているため、これにより、Wi-Fi経由でマルチキャスト特有の問題を回避します。
This approach comes with the trade-off of sometimes sending the same packet multiple times over the Wi-Fi link. However, in many cases, such as video into a residential home network, this can be a good trade-off since the Wi-Fi link may have enough capacity for the unicast traffic to be transmitted to each subscribed STA, even though multicast addressing may have been necessary for the upstream access network.
このアプローチには、Wi-Fiリンクの上に同じパケットを複数回送信することがあります。しかし、住宅用ホームネットワークへのビデオなどの多くの場合、Wi-Fiリンクは、マルチキャストアドレス指定があっても、Wi-Fiリンクが各購読STAに送信されるのに十分な容量を有している可能性があるため、良いトレードオフになる可能性があります。アップストリームアクセスネットワークに必要でした。
Several technologies exist that can be used to arrange unicast transport over the Wi-Fi link, outlined in the subsections below.
下記の小節に概説されているWi-Fiリンクを介してユニキャストトランスポートを手配するために使用できるいくつかの技術が存在します。
It is often possible to transmit multicast control and data messages by using unicast transmissions to each station individually.
各ステーションへのユニキャスト送信を個別に各ステーションに使用することによってマルチキャスト制御およびデータメッセージを送信することが可能である。
Although there is not yet a standardized method of conversion, at 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.
まだ標準化された変換方法はありませんが、Linuxブリッジコード[Bridge-MC-2-UC]には少なくとも1つの広く利用可能な実装が存在します。他の独自の実装はさまざまなベンダーから入手できます。一般に、これらの実装は、IGMPまたはMLDスヌーピングによって発見されたグループまたはチャネルのための直接的なマッピングを対応するユニキャストMACアドレスに実行します。
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:
DMSを使用すると、STAは、要求されているSTAS宛てのマルチキャストグループアドレスフレームを個別にアドレス指定されたフレーム（すなわち、ユニキャストにマルチキャストを変換する）を送信することを要求する。これがDMSのいくつかの特性です。
* Requires 802.11n Aggregate MAC Service Data Units (A-MSDUs).
* 802.11n集計MACサービスデータユニット（A-MSDU）が必要です。
* Individually addressed frames are acknowledged and are buffered for power-save STAs.
* 個々にアドレス指定されたフレームは確認され、省電力STA用にバッファされています。
* The requesting STA may specify traffic characteristics for DMS traffic.
* 要求側STAは、DMSトラフィックのトラフィック特性を指定することができる。
* DMS was defined in IEEE Std 802.11v-2011 [v2011].
* DMSはIEEE STD 802.11V-2011 [V2011]で定義されました。
* DMS requires changes to both AP and STA implementation.
* DMSには、APとSTA実装の両方への変更が必要です。
DMS is not currently implemented in products. See [Tramarin2017] and [Oliva2013] for more information.
DMSは現在製品に実装されていません。詳細については[TRAMARIN2017]と[OLIVA2013]を参照してください。
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 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.
AMT [RFC7450]ユニキャストのみをサポートするネットワークリンクを介してユニキャストIPパケット内のマルチキャストIPパケットをトンネル化する方法を提供します。STA上で動作するオペレーティングシステムまたはアプリケーションがAMTゲートウェイ機能を統合している場合は、APに接続されているネットワークの非Wi-Fi部分にAMTリレーを展開することで、Wiicastをトラバースすることができます。
It is recommended that multicast-enabled networks deploying AMT relays for this purpose make the relays locally discoverable with the following methods, as described in [RFC8777]:
この目的のためにAMTリレーをデプロイするマルチキャスト対応ネットワークは、[RFC8777]で説明されているように、リレーを次の方法でローカルに検出できます。
* DNS-based Service Discovery (DNS-SD) [RFC6763]
* DNSベースサービス発見（DNS-SD）[RFC6763]
* The well-known IP addresses from Section 7 of [RFC7450]
* [RFC7450]のセクション7からの有名なIPアドレス
An AMT gateway that implements multiple standard discovery methods is more likely to discover the local multicast-capable network instead of forming a connection to a nonlocal AMT relay further upstream.
複数の標準的な発見方法を実装するAMTゲートウェイは、さらに上流の非ローカルAMTリレーへの接続を形成する代わりに、ローカルマルチキャスト対応ネットワークを発見する可能性が高い。
GCR (defined in [dot11aa]) provides greater reliability by using either unsolicited retries or a block acknowledgement mechanism. GCR increases the probability of broadcast frame reception success but still does not guarantee success.
GCR（DOT11aa]で定義）は、迷惑な再試行またはブロック確認メカニズムを使用することによってより大きな信頼性を提供します。GCRは、放送フレームの受信の成功の確率を高めるが、それでも成功を保証するものではありません。
For the block acknowledgement mechanism, the AP transmits each group-addressed frame as a conventional group-addressed transmission. Retransmissions are group addressed but hidden from non-11aa STAs. A directed block acknowledgement scheme is used to harvest reception status from receivers; retransmissions are based upon these responses.
ブロック確認メカニズムの場合、APは各グループアドレスフレームを従来のグループアドレス送信送信として送信する。再送信は、非11AA STAから隠れているグループです。受信機から受信状況を収集するために、指向ブロック確認応答方式が使用されます。再送信はこれらの応答に基づいています。
GCR is suitable for all group sizes including medium to large groups. As the number of devices in the group increases, GCR can send block acknowledgement requests to only a small subset of the group. GCR does require changes to both AP and STA implementations.
GCRは、培地から大きな群を含む全ての基サイズに適している。グループ内のデバイスの数が増えると、GCRはブロック確認応答要求をグループの小さなサブセットのみに送信できます。GCRは、APの両方の実装とSTA実装の両方への変更を必要とします。
GCR may introduce unacceptable latency. After sending a group of data frames to the group, the AP has to do the following:
GCRは許容できない待ち時間を導入するかもしれません。グループにデータフレームのグループを送信した後、APは次のとおりです。
* Unicast a Block Ack Request (BAR) to a subset of members.
* メンバーのサブセットへのブロックACK要求（BAR）をユニキャストします。
* Wait for the corresponding Block Ack (BA).
* 対応するブロックACK（BA）を待ちます。
* Retransmit any missed frames.
* 逃したフレームを再送信します。
* 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.
GCRの性能を向上させるために802.11に進行中の拡張機能があります。
* BAR is sent using downlink Multi-User MIMO.
* バーはダウンリンクマルチユーザーMIMOを使用して送信されます。
* BA is sent using uplink MU-MIMO (uplink MU-MIMO is an IEEE 801.11ax-2021 feature).
* BAはアップリンクMU-MIMOを使用して送信されます（Uplink MU-MIMOはIEEE 801.11ax-2021機能です）。
* Latency may also be reduced by simultaneously receiving BA information from multiple STAs.
* 複数のSTAからBA情報を同時に受信することでレイテンシを短縮することもできます。
This section lists some operational optimizations that can be implemented when deploying wireless IEEE 802 networks to mitigate some of the issues discussed in Section 3.
このセクションでは、セクション3で説明されている問題のいくつかを軽減するために、無線IEEE 802ネットワークを展開するときに実装できるいくつかの動作最適化を示します。
ARP Sponges An ARP Sponge sits on a network and learns which IP addresses are actually in use. It also listens for ARP requests, and, if it sees an ARP for an IP address that it believes is not used, it will reply with its own MAC address. This means that the router now has an IP-to-MAC mapping, which it caches. If that IP is later assigned to a 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; unfortunately, the ARP Sponge daemons were not really designed for this use (one of the most widely deployed ARP Sponges [arpsponge] was designed to deal with the disappearance of participants from an Internet Exchange Point (IXP)) and so are not optimized for this purpose. One daemon is needed per subnet; the tuning is tricky (the scanning rate versus the population rate versus retries, etc.), and sometimes daemons just stop, requiring a restart of the daemon that causes disruption.
ARPは、ARPスポンジがネットワーク上に座っているか、どのIPアドレスが実際に使用されているかを学習します。 ARPリクエストも聴取し、IPアドレスが使用されていないIPアドレスのARPを見れば、独自のMACアドレスで返信します。つまり、ルータにIPからMACマッピングがあることを意味します。そのIPが後でマシンに（例えばDHCPを使用）に割り当てられている場合、ARPスポンジはこれを表示し、そのアドレスの返信を停止します。リートされたARP（またはそのゲートウェイのためのマシンが走る）は、ルータARPテーブル内のスポンジアドレスを置き換えます。この技術は非常に効果的です。残念ながら、ARPスポンジデーモンは本当にこの使用のために設計されていなかった（最も広く展開されたARPスポンジの1つがインターネット交換点（IXP）からの参加者の消失に対処するように設計されていたため、このために最適化されていません。目的。サブネットごとに1つのデーモンが必要です。チューニングはトリッキーです（走査レート対母集団レート対再試行など）、そして時にはデーモンはただ停止し、中断を引き起こすデーモンの再起動を必要とします。
Router mitigations Some routers (often those based on Linux) implement a "negative ARP cache" daemon. 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 in use often do not support this. Instead, when a host connects to a network and gets an IP address, it will ARP for its default gateway (the router). The router will update its cache with the IP to host MAC mapping learned from the request (passive ARP learning).
ルータの軽減のあるルータ（Linuxに基づくもの）は、「負のarp cache」デーモンを実装しています。ルータがARPへの返信を表示しない場合は、この情報をある間隔でキャッシュするように設定できます。残念ながら、使用中のコアルータはこれをサポートしていません。代わりに、ホストがネットワークに接続してIPアドレスを取得すると、そのデフォルトゲートウェイ（ルータ）のARPになります。ルータは、リクエストから学習したMACマッピングをIPにアップデートしてキャッシュを更新します（パッシブARP Learning）。
Firewall unused space The distribution of users on wireless networks / subnets may change in various use cases, such as conference venues (e.g., Service Set Identifiers (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.
ファイアウォール未使用スペースワイヤレスネットワーク/サブネット上のユーザーの分布は、会議の会議（例えば、サービスセット識別子（SSID）の名前が変更され、いくつかのSSIDが有利なものなど）などのさまざまなユースケースで変わる可能性があります。これにより、特定のSSIDの使用率を高く予測するのが困難になりますが、参加者は異なるネットワークを使用するため、使用を監視できます。サブネットごとに複数のDHCPプールを設定し、それらを順番に有効にすることで、下部部分のアドレスのみが割り当てられる大きなサブネットを作成できます。したがって、入力されたIPアクセスリストを適用することができます。これは、上位、未使用部分へのトラフィックを拒否します。その後、ルータはサブネットの未使用部分にパケットを転送しようとしませんので、ARPはそうしません。この方法は非常に効果的であることが証明されていますが、鈍い斧のやや範囲はかなり労働集約的で、調整が必要です。
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. 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 seemingly simple and obvious solution to "just disable ARP or filter it outbound" is made difficult or awkward in practice by implementations and/or architectural issues.
ARP要求を無効/フィルタリングする一般的に、ルータはホストに対してARPを必要としません。ホストが接続すると、ルータはそのホストによって送信されたARP要求からのIPからMACマッピングを学習できます。その結果、ルータからARP要求を無効化および/またはフィルタすることが可能であるはずである。残念ながら、ARPはIPスタックの非常に低いレベル/基本的な部分であり、しばしば通常のコントロールプレーンからオフロードされます。多くのルータがレイヤ2トラフィックをフィルタリングできますが、これは通常入力フィルタとして実装されています。また、出力ブロードキャストトラフィックをフィルタリングする機能が制限されています。つまり、「ARPを無効にするか、絞り込みを無効にする」という一見簡単で明らかな解決策は、実装やアーキテクチャ上の問題によって実際には困難または厄介なものです。
NAT Broadcasts can often be caused by outside Wi-Fi scanning / backscatter traffic. In order to reduce the impact of broadcasts, NAT can be used on the entire (or a large portion) of a network. This would eliminate NAT translation entries for unused addresses, and the router would never ARP for them. There are, however, many reasons to avoid using NAT in such a blanket fashion.
NATブロードキャストは、Wi-Fiスキャン/後方散乱トラフィックの外部によって引き起こされることがよくあります。放送の影響を減らすために、NATはネットワークの全体（または大部分）で使用することができる。これにより、未使用のアドレスのNAT変換エントリを排除し、ルータはそれらのためにARPを実行しません。しかしながら、そのような毛布のファッションでNATを使用するのを避けるための多くの理由がある。
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 of some organizations to have the network as open as possible and to honor the end-to-end principle. An attendee on a meeting network should be an Internet host 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.
ステートフルファイアウォールもう一つの明白な解決策は、無線ネットワークとインターネットとの間にステートフルなファイアウォールを置くことです。このファイアウォールは、発信要求に関連付けられていない着信トラフィックをブロックします。しかし、これは、ネットワークをできる限りオープンとし、そしてエンドツーエンドの原則を尊重するためのいくつかの組織の必要性と願望と矛盾します。会議ネットワーク上の出席者はインターネットホストであるべきであり、迷惑な要求を受け取ることができるはずです。残念ながら、ネットワークが初めての優先順位であり、これを達成するためにステートフルファイアウォールが必要になることがあります。
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.
何百ものSTAをサポートしなければならないネットワークでは、オペレータは、同時にMDNに登録された多くのデバイスによるネットワーク劣化を観察しました。多くのクライアントを持つネットワークでは、他のトラフィックの中断を避けるために、より小さなホームネットワークでサービスを発見するように設計されたMDNSパケットを確実にすることをお勧めします。
Many of the causes of performance degradation described in earlier sections are also observable for wireless media other than 802.11.
以前のセクションで説明されているパフォーマンス劣化の原因の多くは、802.11以外の無線メディアに対しても観察可能である。
For instance, problems with power save, excess media occupancy, and poor reliability will also affect 802.15.3 and 802.15.4. Unfortunately, 802.15 media specifications do not yet include mechanisms similar to those developed for 802.11. In fact, the design philosophy for 802.15 is oriented towards minimality, with the result that many such functions are relegated to operation within higher-layer protocols. This leads to a patchwork of non-interoperable and vendor-specific solutions. See [uli] for additional discussion and a proposal for a task group to resolve similar issues, in which the multicast problems might be considered for mitigation.
例えば、省電力、過剰なメディアの占有、および信頼性が低いという問題も802.15.3および802.15.4にも影響を与えます。残念ながら、802.15メディア仕様はまだ802.11のために開発されたものと同様のメカニズムを含めていません。実際、802.15の設計理念は最小限に向けられており、その結果、そのような機能は高層プロトコル内の操作に耐えられます。これにより、相互運用不能およびベンダー固有の解決策のパッチワークがつながります。追加の議論とタスクグループの提案について[Uli]を参照してください。緩和のためにマルチキャストの問題が考慮される可能性がある類似の問題を解決するためのタスクグループの提案。
Similar considerations hold for most other wireless media. A brief introduction is provided in [RFC5757] for the following:
他のほとんどの無線メディアについても同様の考察が保持されています。次のために[RFC5757]に簡単な紹介が行われています。
* 802.16 WiMAX
* 802.16 WiMAX.
* 3GPP/3GPP2
* 3GPP / 3GPP2.
* DVB-H/DVB-IPDC
* DVB-H / DVB-IPDC
* TV Broadcast and Satellite Networks
* テレビ放送および衛星ネットワーク
This section provides some recommendations about the usage and combinations of some of the multicast enhancements described in Sections 4 and 5.
このセクションでは、セクション4と5で説明されているマルチキャスト強化のいくつかの使用方法と組み合わせに関するいくつかの推奨事項を提供します。
Future protocol documents utilizing multicast signaling should be carefully scrutinized if the protocol is likely to be used over wireless media.
プロトコルが無線メディアを介して使用される可能性がある場合、マルチキャストシグナリングを利用した将来のプロトコル文書は慎重に精査されるべきです。
The use of proxy methods should be encouraged to conserve network bandwidth and power utilization by low-power devices. The device can send a unicast message to its proxy, and then the proxy can take care of any needed multicast operations.
プロキシメソッドの使用は、低電力デバイスによるネットワーク帯域幅と電力利用率を節約することをお勧めします。デバイスはユニキャストメッセージをそのプロキシに送信でき、プロキシは必要なマルチキャスト操作の世話をすることができます。
Multicast signaling for wireless devices should be done in a way that is compatible with low duty-cycle operation.
無線装置用のマルチキャストシグナリングは、低デューティサイクル動作と互換性のある方法で行う必要があります。
This section suggests two discussion items for further resolution.
このセクションでは、さらなる解決策のための2つのディスカッションアイテムが示唆されています。
First, standards (and private) organizations should develop guidelines to help clarify when multicast packets would be better served by being sent wired rather than wireless. For example, 802.1ak [IEEE802.1ak] works on both Ethernet and Wi-Fi, and organizations could help with deployment decision making by developing guidelines for multicast over Wi-Fi, including options for when traffic should be sent wired.
まず、標準（およびプライベート）組織は、マルチキャストパケットが無線ではなく有線で送付されることによってよりよく提供されることによって明確にするのを助けるためのガイドラインを開発するべきです。たとえば、802.1ak [IEEE802.1ak]はイーサネットとWi-Fiの両方で動作し、組織はWi-Fiを介したマルチキャストのガイドラインを開発することによって、Wi-Fiを介したガイドラインを開発することによる展開意思決定に役立ちます。
Second, reliable registration to Layer 2 multicast groups and a reliable multicast operation at Layer 2 might provide a good multicast over Wi-Fi solution. There shouldn't be a need to support 2^24 groups to get solicited node multicast working: it is possible to simply select a number of bits that make sense for a given network size to limit the number of unwanted deliveries to reasonable levels. The IEEE 802.1, 802.11, and 802.15 Working Groups should be encouraged to revisit Layer 2 multicast issues and provide workable solutions.
第二に、レイヤ2マルチキャストグループおよびレイヤ2での信頼できるマルチキャスト動作への信頼できる登録は、Wi - Fiソリューションを介して良好なマルチキャストを提供する可能性がある。勧誘ノードマルチキャスト作業を得るために2 ^ 24グループをサポートする必要はありません。特定のネットワークサイズを意味するビット数を簡単に選択することはできます。IEEE 802.1,802.11、および802.15ワーキンググループは、レイヤ2マルチキャストの問題を再検討し、作業可能な解決策を提供することをお勧めします。
This document does not introduce or modify any security mechanisms. Multicast deployed on wired or wireless networks as discussed in this document can be made more secure in a variety of ways. [RFC4601], for instance, specifies the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. [RFC5796] specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH).
この文書はセキュリティメカニズムを導入または変更しません。この文書で説明したように、有線または無線ネットワークに配置されたマルチキャストは、さまざまな方法でより安全にすることができます。[RFC4601]は、たとえば、プロトコルに依存しないマルチキャストスパースモード（PIM-SM）ルーティングプロトコル内のリンクローカルメッセージの認証を確実にするためのIPsecの使用を指定します。[RFC5796]セキュリティペイロード（ESP）または（オプションで）認証ヘッダー（AH）をカプセル化するIPセキュリティ（IPSec）を使用してPIM-SMリンクローカルメッセージを認証するメカニズムを指定します。
When using mechanisms that convert multicast traffic to unicast traffic for traversing radio links, the AP (or other entity) is forced to explicitly track which subscribers care about certain multicast traffic. This is generally a reasonable trade-off but does result in another entity that is tracking what entities subscribe to which multicast traffic. While such information is already (by necessity) tracked elsewhere, this does present an expansion of the attack surface for that potentially privacy-sensitive information.
マルチキャストトラフィックをマルチキャストトラフィックを中心にトラバースするためのユニキャストトラフィックに変換するメカニズムを使用する場合、AP（または他のエンティティ）は、どの加入者が特定のマルチキャストトラフィックを気にするかを明示的に追跡することを余儀なくされます。これは一般に合理的なトレードオフですが、どのエンティティがどのマルチキャストトラフィックを購読するかを追跡している別のエンティティになります。そのような情報はすでに（必要に応じて）他の場所に追跡されていますが、これはその潜在的にプライバシーに敏感な情報のための攻撃面の拡大を提示します。
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. [group_key] states that when TKIP (WPA, now deprecated) or AES-CCMP (WPA2/WPA3) encryption is in use, AP-to-client (FromDS) multicasts have to be encrypted with a separate encryption key that is known to all of the clients (this is called the Group Key). Quoting further from that website, "... most clients are able to get connected and surf the web, check email, etc. even when FromDS multicasts are broken. So a lot of people don't realize they have multicast problems on their network..."
[Group_Key]に記載されているように、ワイヤレスメディアを介したマルチキャスト送信の信頼性の低い性質は、マルチキャストグループのキー管理と更新プログラムに関する微妙な問題を引き起こす可能性があります。[GROUP_KEY] TKIP（WPA、廃止予定）またはAES-CCMP（WPA2 / WPA3）暗号化が使用されている場合、AP-TO-CLIENT（FROMDS）マルチキャストは、すべてに知られている別の暗号化キーで暗号化されなければなりません。クライアントの概要（これはグループキーと呼ばれます）。...ほとんどのクライアントは、FromDSマルチキャストが壊れている場合でも、ほとんどのクライアントはWebに接続して電子メールなどを調べることができます。だから多くの人が彼らのネットワーク上でマルチキャストの問題を抱えていることを理解していません。...」
This document encourages the use of proxy methods to conserve network bandwidth and power utilization by low-power devices. Such proxy methods in general have security considerations that require the proxy to be trusted to not misbehave. One such proxy method listed is an ARP Sponge that listens for ARP requests, and, if it sees an ARP for an IP address that it believes is not used, it will reply with its own MAC address. ARP poisoning and false advertising could potentially undermine (e.g., DoS) this and other proxy approaches.
この文書は、プロキシ法の使用が低電力装置によるネットワーク帯域幅と電力利用率を節約することを奨励しています。そのようなプロキシメソッド一般に、プロキシが不正行為をしないように信頼される必要があるセキュリティ上の考慮事項を有する。リストされているそのようなプロキシメソッドの1つは、ARP要求を待機するARPスポンジであり、それが使用されないIPアドレスのためのARPを見れば、それはそれ自身のMACアドレスで返信します。ARP中毒および誤った広告は、これと他のプロキシのアプローチを潜在的に損なう可能性があります（例えば、DOS）。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[arpsponge] Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge", July 2009, <http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.182.4692>.
[ARPSPONGE] Wessel、M.およびN.Sijm、「AMS-IXおよびARPスポンジのIPv4およびIPv6アドレス解決の効果」、2009年7月、<http://citeeserX.ist.psu.edu/viewdoc/概要？DOI = 10.1.1.182.4692>。
[bridge-mc-2-uc] "bridge: multicast to unicast", commit 6db6f0e, January 2017, <https://github.com/torvalds/linux/commit/6db6f0e>.
[Bridge-MC-2-UC] "Bridge：Unicastへのマルチキャスト"、2017年1月、<https：//github.com/torvalds/linux/commit/6db6f0e>。
[CAB] "limit multicast buffer hardware queue depth", commit 2687951, June 2013, <https://patchwork.kernel.org/patch/2687951/>.
[CAB]「マルチキャストバッファハードウェアキューの深さ」、COMMIT 2687951、2013年6月、<https://patchwwork.kernel.org/patch/2687951/>。
[Deri-2010] Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet Filtering Using Commodity Network Adapters", RIPE 61, November 2010, <http://ripe61.ripe.net/ presentations/138-Deri_RIPE_61.pdf>.
[DERI-2010] Deri、L.およびJ.ガスパラキス、「商品ネットワークアダプタを使用した10Gbitハードウェアパケットフィルタリング」、熟した61、2010年11月、<http://RIPE61.RIPE.NET/プレゼンテーション/ 138-DERI_RIPE_61.PDF>。
[dot11] IEEE, "Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (includes 802.11v amendment)", DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020, December 2020, <https://standards.ieee.org/standard/802_11-2020.html>.
[DOT11] IEEE、「情報技術」システム間の電気通信と情報交換 - 地域と首都圏のネットワーク - 特別な要件 - 第11部：無線LANメディアアクセス制御（MAC）と物理層（PHY）仕様（802.11Vの修正を含む））「、DOI 10.1109 / IEEESTD.2021.9363693、IEEE STD 802.11-2020、2020年12月、<https://standards.ieee.org/standard/802_11-2020.html>。
[dot11-proxyarp] Hiertz, G., Mestanov, F., and B. Hart, "Proxy ARP in 802.11ax", September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>.
[Dot11-Proxyarp] Hirertz、G.、Mestanov、F.、B.Hart、「802.11axのプロキシARP」、2015年9月、<https：//mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00AX-Proxy-ARP-IN-802-11ax.pptx>。
[dot11aa] IEEE, "Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming", DOI 10.1109/IEEESTD.2012.6204193, IEEE Std 802.11aa-2012, March 2012, <https://standards.ieee.org/standard/802_11aa-2012.html>.
[DOT11A] IEEE、「情報技術 - システム間の電気通信および情報交換」ネットワーク - 特有の要件部分：無線LAN中アクセス制御（MAC）および物理層（PHY）の仕様の仕様2：堅牢なMACの機能強化オーディオビデオストリーミング "、DOI 10.1109 / IEEESTD.2012.6204193、IEEE STD 802.11AA-2012、2012年3月、<https：//standards.ieee.org/standard/802_11aa-2012.html>。
[group_key] "Subject: Why do some WiFi routers block multicast packets going from wired to wireless?", message to the Super User Q & A community, January 2017, <https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless>.
[Group_Key] "Subject：WiFiルーターがあるなぜWiFiルーターがワイヤーからワイヤレスへのマルチキャストパケットをブロックするのですか？"、2017年1月、<https：//superuser.com/questions/730288/Why-DO-SHOURD-WIFIルーター - ブロックマルチキャストパケット - ワイヤレスからワイヤレスへ。
[IEEE802.1ak] IEEE, "Local and Metropolitan Area Networks Virtual Bridged Local Area Networks - Amendment 07: Multiple Registration Protocol", DOI 10.1109/IEEESTD.2007.380667, IEEE Std 802.1ak-2007, June 2007, <https://www.ieee802.org/1/pages/802.1ak.html>.
[IEEE802.1AK] IEEE、「地元と首都圏ネットワークバーチャルブリッジローカルエリアネットワーク - 修正07：複数登録プロトコル」、DOI 10.1109 / IEEESTD.2007.380667、IEEE STD 802.1AK-2007、2007年6月、<HTTPS：// WWW.ieee802.org / 1 / pages / 802.1ak.html>。
[ietf_802-11] Stanley, D., "IEEE 802.11 multicast capabilities", November 2015, <https://mentor.ieee.org/802.11/ dcn/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-ietf-nov-2015.ppt>.
[IETF_802-11] Stanley、D.、「IEEE 802.11マルチキャスト機能」、2015年11月、<https：//mentor.ieee.org/802.11/ DCN / 15/11/15-1261-03-0ARC-マルチキャスト - パフォーマンス-optimization-features-overview-for-ietf-2015.ppt>。
[mc-prob-stmt] Abrahamsson, M. and A. Stephens, "Multicast on 802.11", 2013, <https://www.iab.org/wp-content/IAB-uploads/2013/01/ multicast-problem-statement.pptx>.
[MC-PROB-STMT] Abrahamsson、M.およびA. Stephens、「マルチキャスト：802.11のマルチキャスト」、2013、<https：//www.iab.org/wp-content/iab-uploads/2013/01/マルチキャスト - 問題-Statement.PPTX>。
[mc-props] Stephens, A., "IEEE 802.11 multicast properties", September 2015, <https://mentor.ieee.org/802.11/ dcn/15/11-15-1161-02-0arc-802-11-multicast-properties.ppt>.
[MC-Props] Stephens、A。、「IEEE 802.11マルチキャストプロパティ」、2015年9月、<https：//mentor.ieee.org/802.11/ DCN / 15/11-15-1161-02-0ARC-802-11-multicast-properties.ppt>。
[Oliva2013] de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, "Performance evaluation of the IEEE 802.11aa multicast mechanisms for video streaming", 2013 IEEE 14th International Symposium on "A World of Wireless, Mobile and Multimedia Networks" (WoWMoM), pp. 1-9, DOI 10.1109/WoWMoM.2013.6583394, June 2013, <https://doi.org/10.1109/WoWMoM.2013.6583394>.
[OLIVA2013]デラ・オリバ、A.、Serrano、P.、Salvador、P.、およびA. Banchs、「IEEE 802.11aaのパフォーマンス評価」、2013年IEEE第14回国際シンポジウムオンワイヤレス、モバイル、マルチメディアネットワーク（Wowmom）、PP。1-9、DOI 10.1109 / Wowmom.2013.6583394、2013年6月、<https：//doi.org/10.1109/wowmom.2013.6583394>
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.
[RFC0826] Plummer、D.、「イーサネット・アドレス解決プロトコル：またはネットワークプロトコル・アドレスをイーサネット・ハードウェア上での送信・イーサネット・アドレスの変換」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<https：//www.rfc-editor.org/info/rfc826>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] DROMS、R.、「動的ホスト構成プロトコル」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https：//www.rfc-editor.org/info/rfc2131>。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, DOI 10.17487/RFC4286, December 2005, <https://www.rfc-editor.org/info/rfc4286>.
[RFC4286] Haberman、B.およびJ. Martin、 "Multicast Router Discovery"、RFC 4286、DOI 10.17487 / RFC4286、2005年12月、<https：//www.rfc-editor.org/info/rfc4286>。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.
[RFC4541] Christensen、M.、Kimball、K.、F. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチ（MLD）スヌーピングスイッチ（MLD）スヌーピングスイッチに関する考察 "、RFC 4541、DOI 10.17487 / RFC4541、2006年5月、<https://www.rfc-editor.org/info/rfc4541>。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, <https://www.rfc-editor.org/info/rfc4601>.
[RFC4601] Fenner、B、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂） "、RFC 4601、DOI 10.17487 / RFC46012006年8月、<https：//www.rfc-editor.org/info/rfc4601>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T.、T. Jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, DOI 10.17487/RFC5757, February 2010, <https://www.rfc-editor.org/info/rfc5757>.
[RFC5757] Schmidt、T.、Waehlisch、M.、G. FairHurst、「モバイルIPバージョン6（MIPv6）のマルチキャストモビリティ（MIPv6）：問題ステートメントと簡単な調査」、RFC 5757、DOI 10.17487 / RFC5757、2010年2月、<HTTPS：//www.rfc-editor.org/info/rfc5757>。
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796, March 2010, <https://www.rfc-editor.org/info/rfc5796>.
[RFC5796] Atwood、W.、ISLAM、S.、およびM. Siami、「プロトコル独立マルチキャストスパースモード（PIM-SM）リンクローカルメッセージの認証および機密性」、RFC 5796、DOI 10.17487 / RFC 5796、2010年3月<https：//www.rfc-editor.org/info/rfc5796>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、2011年9月、2011年9月、<https：//www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S.およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https：//www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S.およびM. Krochmal、「DNSベースのサービス発見」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https：//www.rfc-editor.org/info/rfc6763>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https：//www.rfc-editor.org/info/rfc6775>。
[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, DOI 10.17487/RFC6970, July 2013, <https://www.rfc-editor.org/info/rfc6970>.
[RFC6970] Boucadair、M.、Penno、R.、D.ウィング、「ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス - ポート制御プロトコルインターワーキング機能（IGD-PCP IWF）」、RFC 6970、DOI 10.17487 / RFC6970、2013年7月、<https：//www.rfc-editor.org/info/rfc6970>。
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.
[RFC7450] Bumgardner、G.、 "自動マルチキャストトンネリング"、RFC 7450、DOI 10.17487 / RFC7450、2015年2月、<https：//www.rfc-editor.org/info/rfc7450>。
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7761] Fenner、B、Handley、M.、Holbrook、H.、Kouvelas、I。、Parekh、R.、Zhang、Z.、L.Zheng、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂） "、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https：//www.rfc-editor.org/info/rfc7761>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S.およびPerkins、「低電力無線パーソナルエリアネットワーク（6lowpan）隣接ディスカバリーに関するIPv6の登録拡張」、RFC 8505、DOI10.17487 / RFC8505、2018年11月、<https：//www.rfc-editor.org/info/rfc8505>。
[RFC8777] Holland, J., "DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery", RFC 8777, DOI 10.17487/RFC8777, April 2020, <https://www.rfc-editor.org/info/rfc8777>.
[RFC8777] Holland、J.、 "DNSリバースIP自動マルチキャストトンネリング（AMT）ディスカバリー"、RFC 8777、DOI 10.17487 / RFC8777、2020年4月、<https://www.rfc-editor.org/info/rfc8777>。
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC8929] Thubert、P.、Ed。、Perkins、CE、E. Levy-Abngingoli、「IPv6 Backbone Router」、RFC 8929、DOI 10.17487 / RFC8929、2020年11月、<https：//www.rfc-編集者。ORG / INFO / RFC8929>。
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.
[RFC9030]「IEEE 802.15.4（6tisch）のタイムスロットチャネルホッピングモード（6Tisch）」、RFC 9030、DOI 10.17487 / RFC9030、<https：//のタイムスロットチャネルホッピングモードでのIPv6のアーキテクチャー。www.rfc-editor.org/info/rfc9030>。
[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.
[TRAMARIN2017] Tramarin、F.、Vitturi、S.、およびM. Luvisotto、「分散測定システム用IEEE 802.11n」、2017 IEEE国際計装・測定技術会議（I2MTC）、PP。1-6、2017年5月。
[uli] Kinney, P., "LLC Proposal for 802.15.4", September 2015, <https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0- llc-proposal-for-802-15-4.pptx>.
[Uli] Kinney、P.、「802.15.4のLLCの提案」、2015年9月、<https：//mentor.ieee.org/802.15/dcn/15/15-15-0521-01-0521-01-wng0 - llc-proposal-FOR-802-15-4.pptx>。
[v2011] IEEE, "Information technology -- Local and metropolitan area networks -- Specific requirements -- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: IEEE 802.11 Wireless Network Management", DOI 10.1109/IEEESTD.2011.5716530, IEEE Std 802.11v-2011, February 2011, <https://ieeexplore.ieee.org/document/5716530>.
[V2011] IEEE、「情報技術 - ローカルおよび首都圏ネットワーク - 特有の要件 - 第11部：無線LAN中アクセス制御（MAC）および物理層（PHY）仕様修正8：IEEE 802.11無線ネットワーク管理 "、DOI10.1109 / IEEESTD.2011.5716530、IEEE STD 802.11V-2011、2011年2月、<https：//ieeexplore.ieee.org/document/5716530>。
Acknowledgements
謝辞
This document has benefitted from discussions with the following people, in alphabetical order: Mikael Abrahamsson, Bill Atwood, Stuart Cheshire, Donald Eastlake 3rd, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Thubert, and Jeffrey (Zhaohui) Zhang.
この文書は、次の人々との議論から、アルファベット順に、Bill Atwood、Stuart Cheshire、Donald Eastlake 3rd、Toerless Eckert、Jake Holland、Javid Lamparter、Pascal Thubert、ジェフリー（趙大）Zhang。
Authors' Addresses
著者の住所
Charles E. Perkins Lupin Lodge
チャールズE.パーキンスルパンロッジ
Phone: +1 408 255 9223
Email: charliep@lupinlodge.com
Mike McBride Futurewei Technologies Inc. 2330 Central Expressway Santa Clara, CA 95055 United States of America
Mike McBride Futurewei Technologies Inc. 2330 Central Expresswayサンタクララ、CA 95055アメリカ合衆国
Email: michael.mcbride@futurewei.com
Dorothy Stanley Hewlett Packard Enterprise 6280 America Center Dr. San Jose, CA 95002 United States of America
Dorothy Stanley Hewlett Packard Enterprise 6280アメリカセンターサンノゼ、CA 95002アメリカ合衆国
Phone: +1 630 363 1389
Email: dorothy.stanley@hpe.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net
Juan Carlos Zúñiga SIGFOX Montreal Canada
Juan CarlosZāñigaSigfox Montrealカナダ
Email: j.c.zuniga@ieee.org