Internet Engineering Task Force (IETF) N. Karstens
Request for Comments: 10019 Garmin
Category: Informational D. Farinacci
ISSN: 2070-1721 lispers.net
M. McBride
Futurewei
July 2026
This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration (zeroconf) networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination.
この文書では、ゼロ構成 (zeroconf) ネットワーキング環境でマルチキャスト IP アドレスを自動的に割り当てるための既存のプロトコルに関する現在の問題を調査します。これは、リンク層アドレスの衝突、ハードウェアの制限、マルチキャスト スヌーピングの非効率性、手動構成を回避する必要性などの主要な課題に対処します。これらの課題に基づいて、中央調整を行わずに一意のマルチキャスト グループ アドレスを動的に割り当てる軽量の分散ソリューションの要件を導き出します。
The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks.
この文書では、検出、割り当て、競合の検出と解決、リース管理をカバーする明確な要件を示しています。また、IPv6 および IPv4 マルチキャスト アドレス範囲に特有の考慮事項を評価し、zeroconf の展開に適さないアプローチを特定します。この基盤は、ローカル ネットワーク内で自律的に動作するマルチキャスト アドレス割り当ての将来のソリューションを開発するための参考として機能します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10019.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10019 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Link-Layer Address Collisions
3. Solution Requirements
4. IPv6 Considerations
5. IPv4 Considerations
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Excluded Solutions
Acknowledgement
Authors' Addresses
Multicast communication is commonly used in networks that need to distribute data from one sender to multiple receivers efficiently. In some environments, such as small or isolated networks, multicast operate without centralized servers or manual configuration. These are referred to as zero-configuration (zeroconf) multicast networks.
マルチキャスト通信は、1 人の送信者から複数の受信者にデータを効率的に配信する必要があるネットワークで一般的に使用されます。小規模ネットワークや孤立したネットワークなどの一部の環境では、マルチキャストは集中サーバーや手動構成なしで動作します。これらは、ゼロ構成 (zeroconf) マルチキャスト ネットワークと呼ばれます。
One example of such an environment is marine networks, which typically include a mix of sensors, controls, and displays. These networks vary in complexity depending on the size and design of the vessel. Devices may range from low-cost temperature or fluid sensors to high-bandwidth sources such as radar, sonar, or video feeds. Many marine networks are built on a single subnet and rely on Layer 2 Ethernet switches to connect devices.
このような環境の一例は海洋ネットワークであり、通常、センサー、制御装置、ディスプレイが混在しています。これらのネットワークの複雑さは、船舶のサイズと設計に応じて異なります。デバイスは、低コストの温度センサーや流体センサーから、レーダー、ソナー、ビデオ フィードなどの高帯域幅のソースまで多岐にわたります。多くの海洋ネットワークは単一のサブネット上に構築されており、デバイスの接続にはレイヤー 2 イーサネット スイッチに依存しています。
In these networks, multicast is the most efficient method for distributing sensor data to multiple displays. However, challenges arise when high-bandwidth multicast streams overload links to low-bandwidth devices. Cost-effective switches often do not support source-specific multicast (SSM) because their address table only maps destination Media Access Control (MAC) addresses. Instead, each multicast stream is assigned a unique destination multicast IP address, and IGMP/MLD snooping [RFC4541] is used to control multicast delivery. This method introduces limitations, especially in environments where switch hardware lacks advanced multicast filtering capabilities.
これらのネットワークでは、マルチキャストがセンサー データを複数のディスプレイに配信する最も効率的な方法です。ただし、高帯域幅のマルチキャスト ストリームが低帯域幅のデバイスへのリンクを過負荷にすると、問題が発生します。コスト効率の高いスイッチは、アドレス テーブルが宛先メディア アクセス コントロール (MAC) アドレスのみをマップするため、ソース固有マルチキャスト (SSM) をサポートしていないことがよくあります。代わりに、各マルチキャスト ストリームには一意の宛先マルチキャスト IP アドレスが割り当てられ、IGMP/MLD スヌーピング [RFC4541] がマルチキャスト配信の制御に使用されます。この方法では、特にスイッチ ハードウェアに高度なマルチキャスト フィルタリング機能がない環境では制限が生じます。
While marine networks illustrate these issues well, the challenges they face are not unique. Many other zeroconf multicast environments, such as industrial automation, small-scale audio-visual (AV) systems, or ad hoc sensor networks, share similar constraints.
海洋ネットワークはこれらの問題をよく示していますが、海洋ネットワークが直面する課題は特別なものではありません。産業オートメーション、小規模オーディオビジュアル (AV) システム、アドホック センサー ネットワークなど、他の多くの zeroconf マルチキャスト環境も同様の制約を共有しています。
The Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] is a method for multicast IP address allocation, but its server-based model does not suit a zeroconf environment. [RFC3306] and [RFC4489] both discuss similar approaches to host-based multicast IPv6 address allocation, but neither adequately prevents link-layer address collisions. Although [RFC3307] establishes a framework to avoid multicast address collisions at both IPv6 and link layers, additional refinement is needed to put this into practice (see Section 4).
マルチキャスト アドレス動的クライアント割り当てプロトコル (MADCAP) [RFC2730] はマルチキャスト IP アドレス割り当ての方法ですが、そのサーバーベースのモデルは zeroconf 環境には適していません。[RFC3306] と [RFC4489] は両方とも、ホストベースのマルチキャスト IPv6 アドレス割り当てに対する同様のアプローチについて議論していますが、どちらもリンク層アドレスの衝突を適切に防止していません。[RFC3307] は、IPv6 層とリンク層の両方でマルチキャスト アドレスの衝突を回避するフレームワークを確立していますが、これを実践するには追加の改良が必要です (セクション 4 を参照)。
This document outlines the problem space for zeroconf multicast address allocation, describes the key limitations of current protocols, details sources of link-layer address collisions, and defines a set of requirements for decentralized, zero-configuration multicast address allocation solutions. Multicast applications deployed in a zeroconf environment can use these solutions to dynamically allocate multicast group addresses. The manner in which a multicast group address is used after allocation is outside the scope of this document.
この文書では、zeroconf マルチキャスト アドレス割り当ての問題領域の概要を説明し、現在のプロトコルの主な制限について説明し、リンク層アドレス衝突の原因を詳細に説明し、分散型のゼロ構成マルチキャスト アドレス割り当てソリューションの一連の要件を定義します。zeroconf 環境に展開されたマルチキャスト アプリケーションは、これらのソリューションを使用して、マルチキャスト グループ アドレスを動的に割り当てることができます。マルチキャスト グループ アドレスが割り当て後に使用される方法については、このドキュメントの範囲外です。
The organization of IPv6 multicast and immense volume of possible multicast addresses makes IPv6 well-suited for zeroconf multicast networks. However, IPv4 is still considered by this document for networks where transitioning to IPv6 remains impractical.
IPv6 マルチキャストの構成と、使用可能なマルチキャスト アドレスの膨大な量により、IPv6 は zeroconf マルチキャスト ネットワークに適しています。ただし、この文書では、IPv6 への移行が依然として現実的でないネットワークについては、IPv4 を考慮しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The requirements language is used in Section 3 and applies to implementations conformant to the listed requirements.
要件言語はセクション 3 で使用され、リストされた要件に準拠する実装に適用されます。
Link-layer address collisions are a key concern in multicast networks, particularly when devices rely on zero-configuration operation. Collisions occur when two or more multicast groups are assigned the same link-layer (MAC) address, leading to performance or forwarding issues. This section outlines three scenarios where such collisions can cause problems.
リンク層アドレスの衝突は、特にデバイスがゼロ構成の動作に依存している場合、マルチキャスト ネットワークにおける主要な懸念事項です。2 つ以上のマルチキャスト グループに同じリンク層 (MAC) アドレスが割り当てられている場合に衝突が発生し、パフォーマンスや転送の問題が発生します。このセクションでは、このような衝突が問題を引き起こす可能性がある 3 つのシナリオについて概説します。
First, many host network interfaces allow filtering of multicast traffic directly in hardware. When an application joins a multicast group, the host network stack typically programs the hardware to accept only traffic for that group. However, if two groups share the same link-layer address, the network interface cannot distinguish them. The network stack is then forced to process unwanted traffic in software, reducing performance and increasing CPU usage.
まず、多くのホスト ネットワーク インターフェイスでは、マルチキャスト トラフィックをハードウェアで直接フィルタリングできます。アプリケーションがマルチキャスト グループに参加すると、ホスト ネットワーク スタックは通常、そのグループのトラフィックのみを受け入れるようにハードウェアをプログラムします。ただし、2 つのグループが同じリンク層アドレスを共有している場合、ネットワーク インターフェイスはそれらを区別できません。その後、ネットワーク スタックはソフトウェアで不要なトラフィックを処理することになり、パフォーマンスが低下し、CPU 使用率が増加します。
Second, link-layer address collisions reduce the benefit of using multicast snooping switches on a network. Section 4 of [RFC4541] indicates some switches forward multicast traffic based solely on the link-layer address, without considering the network-layer group (see the results for Q2 and Q3). Although the survey is outdated, switches with these limitations still exist in some of the target deployments. In such cases, if two multicast streams share the same MAC address, traffic may be sent to devices that did not request it. This is especially problematic when low-bandwidth links are overwhelmed by high-bandwidth streams. Additional concerns related to the overlap of IPv6 and link-layer addresses are discussed in Section 3 of [RFC4541].
第 2 に、リンク層アドレスの衝突により、ネットワーク上でマルチキャスト スヌーピング スイッチを使用する利点が減ります。[RFC4541] のセクション 4 では、一部のスイッチがネットワーク層グループを考慮せず、リンク層アドレスのみに基づいてマルチキャスト トラフィックを転送することが示されています (Q2 および Q3 の結果を参照)。調査は古いものですが、これらの制限のあるスイッチは一部の対象展開に依然として存在します。このような場合、2 つのマルチキャスト ストリームが同じ MAC アドレスを共有すると、トラフィックが要求していないデバイスに送信される可能性があります。これは、低帯域幅のリンクが高帯域幅のストリームによって圧倒される場合に特に問題になります。IPv6 アドレスとリンク層アドレスの重複に関する追加の懸念事項は、[RFC4541] のセクション 3 で説明されています。
Third, the internal design of some switches can also contribute to collisions. For example, certain switch implementations use a hash table with fixed buckets to store forwarding entries based on MAC addresses (see [US6690667B1]). If multiple addresses hash to the same location and the bucket fills up, additional entries may be dropped or rejected, resulting in forwarding failures.
第三に、一部のスイッチの内部設計も衝突の原因となる可能性があります。たとえば、特定のスイッチ実装では、固定バケットを持つハッシュ テーブルを使用して、MAC アドレスに基づいて転送エントリを保存します ([US6690667B1] を参照)。複数のアドレスが同じ場所にハッシュされ、バケットがいっぱいになると、追加のエントリがドロップまたは拒否され、転送エラーが発生する可能性があります。
These examples highlight why a collision-resistant multicast address allocation mechanism is essential in zeroconf environments. The success of this approach depends on the capabilities of the hardware (such as the number of addresses supported by the filters in host network interfaces and the size of the tables maintained in switches/ routers) and on the number of multicast groups that are subscribed to by a particular receiver. When the number of entries in the filter tables exceeds availability, a typical fallback mechanism is to bypass the filter entirely and flood traffic to the receiver. This subsequently incurs a per-packet cost for any software-based filtering that is needed.
これらの例は、衝突耐性のあるマルチキャスト アドレス割り当てメカニズムが zeroconf 環境で不可欠である理由を強調しています。このアプローチが成功するかどうかは、ハードウェアの機能 (ホスト ネットワーク インターフェイスのフィルターでサポートされるアドレスの数や、スイッチ/ルーターで維持されるテーブルのサイズなど) と、特定の受信者がサブスクライブするマルチキャスト グループの数に依存します。フィルタ テーブル内のエントリの数が可用性を超えると、一般的なフォールバック メカニズムはフィルタを完全にバイパスし、トラフィックを受信者にフラッディングします。これにより、必要なソフトウェアベースのフィルタリングに対してパケットごとのコストが発生します。
A solution intended for decentralized, zero-configuration multicast IP address assignment is expected to operate in dynamic, infrastructure-free environments. To be effective in such contexts, the solution needs to exhibit the following characteristics:
分散型のゼロ構成マルチキャスト IP アドレス割り当てを目的としたソリューションは、動的でインフラストラクチャのない環境で動作することが期待されています。このような状況で効果を発揮するには、ソリューションが次の特性を示す必要があります。
[REQ-1] Unique Address Assignment: Use of the solution SHALL result in a unique address being assigned to the multicast group at both the network and link layers.
[REQ-1] 一意のアドレス割り当て: ソリューションを使用すると、ネットワーク層とリンク層の両方でマルチキャスト グループに一意のアドレスが割り当てられるものとします(SHALL)。
[REQ-2] Resilience to Single Points of Failure: The solution SHALL be designed to minimize introduction of a single point of failure, ensuring that operation continues even if individual devices or links become unavailable.
[REQ-2] 単一障害点に対する回復力: ソリューションは、単一障害点の導入を最小限に抑え、個々のデバイスまたはリンクが使用できなくなった場合でも動作を継続できるように設計されなければなりません(SHALL)。
[REQ-3] Zero User Configuration: It SHALL operate without requiring user or administrator configuration, allowing seamless deployment in unmanaged networks.
[REQ-3] ゼロユーザー構成: ユーザーまたは管理者の構成を必要とせずに動作し、管理されていないネットワークでのシームレスな展開を可能にするものとします。
[REQ-4] Coexistence with Multicast Address Allocation Solutions: The design SHALL allow coexistence with other multicast IP address allocation solutions, including both manual assignment and existing dynamic protocols.
[REQ-4] マルチキャスト アドレス割り当てソリューションとの共存: 設計は、手動割り当てと既存の動的プロトコルの両方を含む、他のマルチキャスト IP アドレス割り当てソリューションとの共存を可能にするものとします (SHALL)。
[REQ-5] Single-Subnet Operation: It SHALL support operation within a single IP subnet, which is typical in link-local or isolated network environments.
[REQ-5] 単一サブネット動作: リンクローカルまたは分離されたネットワーク環境で一般的な、単一 IP サブネット内での動作をサポートするものとします (SHALL)。
[REQ-6] No External Connectivity: The solution SHALL NOT require Internet access or connectivity to external infrastructure.
[REQ-6] 外部接続なし: このソリューションは、インターネット アクセスや外部インフラへの接続を必要としません。
[REQ-7] Supports Multiple Host Applications: It SHALL support multiple applications on the same host, each independently allocating multicast addresses and transmitting to those addresses.
[REQ-7] 複数のホスト アプリケーションのサポート: 同じホスト上の複数のアプリケーションをサポートし、それぞれが独立してマルチキャスト アドレスを割り当て、それらのアドレスに送信するものとします(SHALL)。
[REQ-8] Collision Detection and Resolution: The solution SHALL include mechanisms to detect and resolve multicast address collisions at both the network and link layers.
[REQ-8] 衝突の検出と解決: ソリューションには、ネットワーク層とリンク層の両方でマルチキャスト アドレスの衝突を検出し、解決するメカニズムが含まれなければなりません(SHALL)。
Note: In rare cases, collisions may arise after a temporary network partition, when different parts of the network allocate the same multicast address independently. Upon reconnection, such collisions SHALL be detectable and resolved gracefully by ensuring that conflicting streams are migrated to unique addresses.
注: まれに、ネットワークの異なる部分が同じマルチキャスト アドレスを個別に割り当てる場合、ネットワークの一時的な分割後に衝突が発生することがあります。再接続時には、競合するストリームが確実に一意のアドレスに移行されるようにすることで、そのような衝突が検出可能になり、適切に解決されるものとします(SHALL)。
In addition to the above, the following characteristics are considered desirable, but are left as recommendations to allow for flexibility in solution design:
上記に加えて、次の特性が望ましいと考えられますが、ソリューション設計の柔軟性を考慮して推奨事項として残されています。
[CONS-1] Multi-Subnet Support: Operation across multiple subnets is beneficial in more complex or routed environments and SHOULD be supported.
[短所-1] マルチサブネットのサポート: 複数のサブネットにわたる運用は、より複雑な環境やルーティングされた環境では有益であり、サポートされるべきです(SHOULD)。
[CONS-2] Standards Compatibility: The solution SHOULD aim to minimize the need for changes to existing protocols or standards that affect backwards compatibility or deployment in existing networks.
[CONS-2] 標準の互換性: このソリューションは、下位互換性や既存のネットワークでの展開に影響を与える既存のプロトコルや標準への変更の必要性を最小限に抑えることを目指すべきです。
[CONS-3] Cross-Platform Availability: It SHOULD use capabilities that are widely available across host platforms and operating systems.
[短所-3] クロスプラットフォームの可用性: ホスト プラットフォームとオペレーティング システム全体で広く利用できる機能を使用する必要があります (SHOULD)。
[CONS-4] Minimal Dependency on Manufacturing Data: It SHOULD avoid reliance on preloaded configuration or device-specific manufacturing data.
[短所-4] 製造データへの依存性を最小限に抑える: プリロードされた構成やデバイス固有の製造データへの依存を回避すべきです。
[CONS-5] Low Overhead: The solution SHOULD minimize the volume and frequency of network traffic generated during normal operation.
[CONS-5] 低いオーバーヘッド: このソリューションでは、通常の運用中に生成されるネットワーク トラフィックの量と頻度を最小限に抑える必要があります。
[CONS-6] Advertisement: The solution SHOULD describe a mechanism for advertising and discovering multicast addresses allocated for an application.
[CONS-6] アドバタイズメント: 解決策は、アプリケーションに割り当てられたマルチキャスト アドレスをアドバタイズし、発見するためのメカニズムを記述する必要があります (SHOULD)。
[CONS-7] Network Topology: To allow compatibility with a variety of networks, the solution SHOULD work independently of the dynamics of the underlying topology and adjacencies.
[CONS-7] ネットワーク トポロジ: さまざまなネットワークとの互換性を可能にするために、ソリューションは、基礎となるトポロジや隣接関係のダイナミクスとは独立して機能する必要があります (SHOULD)。
The rules for IPv6 multicast addresses, described in [RFC3307], are comprehensive and well-organized. These rules must be followed by any solution allocating IPv6 multicast addresses, including solutions that meet the requirements defined in this document. However, some aspects of the organization of [RFC3307] need to be improved to ensure that a zeroconf multicast address assignment solution can coexist with other IPv6 multicast address assignment protocols.
[RFC3307] で説明されている IPv6 マルチキャスト アドレスの規則は、包括的でよく整理されています。この文書で定義されている要件を満たすソリューションを含め、IPv6 マルチキャスト アドレスを割り当てるソリューションは、これらのルールに従う必要があります。ただし、zeroconf マルチキャスト アドレス割り当てソリューションが他の IPv6 マルチキャスト アドレス割り当てプロトコルと共存できるようにするには、[RFC3307] の構成のいくつかの側面を改善する必要があります。
For example, Section 2 of [RFC3307] explains that the last 32 bits of an IPv6 multicast address, called the group ID, are mapped directly to the Ethernet MAC address. Different parts of the group ID range are assigned based on how the address is allocated. Section 4.3 of [RFC3307] describes two ways to assign group IDs dynamically: one where a server assigns addresses, and another where hosts assign addresses themselves. However, both methods use the same group ID range, which creates a risk of address collisions if both are used at the same time.
たとえば、[RFC3307] のセクション 2 では、グループ ID と呼ばれる IPv6 マルチキャスト アドレスの最後の 32 ビットがイーサネット MAC アドレスに直接マッピングされると説明しています。グループ ID 範囲のさまざまな部分は、アドレスの割り当て方法に基づいて割り当てられます。[RFC3307] のセクション 4.3 では、グループ ID を動的に割り当てる 2 つの方法について説明しています。1 つはサーバーがアドレスを割り当てる方法で、もう 1 つはホスト自身がアドレスを割り当てる方法です。ただし、どちらの方法も同じグループ ID 範囲を使用するため、両方を同時に使用するとアドレス衝突のリスクが生じます。
An additional concern is that the group IDs used for this dynamic range overlap with the range used for Solicited-Node multicast addresses, a special type of multicast used by IPv6 for neighbor discovery (see Section 2.7.1 of [RFC4291]). This overlap increases the risk of unintentional conflicts with link-layer addresses.
さらに懸念されるのは、このダイナミック レンジに使用されるグループ ID が、近隣探索のために IPv6 で使用される特別なタイプのマルチキャストである Solicited-Node マルチキャスト アドレスに使用される範囲と重複していることです ([RFC4291] のセクション 2.7.1 を参照)。この重複により、リンク層アドレスとの意図しない競合が発生するリスクが増加します。
Note that [RFC3307] focuses on 48-bit addresses on Ethernet, but similar issues would be seen on any medium that generates link-layer multicast addresses by truncating an IPv6 multicast address.
[RFC3307] はイーサネット上の 48 ビット アドレスに焦点を当てていますが、IPv6 マルチキャスト アドレスを切り詰めることによってリンク層マルチキャスト アドレスを生成するあらゆる媒体で同様の問題が発生することに注意してください。
In IPv4, multicast addresses can sometimes cause conflicts at the data link layer. For example, as explained in Section 6.4 of [RFC1112], this happens with Ethernet because only the lower 23 bits of an IPv4 multicast address are used to generate the Ethernet multicast address. Since an IPv4 multicast address is 32 bits and starts with a fixed 4-bit prefix (leaving 28 bits), this means up to 2^(28-23) = 32 different multicast IP addresses can map to the same Ethernet address. As a result, devices may receive multicast traffic they didn't ask for.
IPv4 では、マルチキャスト アドレスがデータ リンク層で競合を引き起こす場合があります。たとえば、[RFC1112] のセクション 6.4 で説明されているように、イーサネットでは、IPv4 マルチキャスト アドレスの下位 23 ビットのみがイーサネット マルチキャスト アドレスの生成に使用されるため、これが発生します。IPv4 マルチキャスト アドレスは 32 ビットで、固定の 4 ビット プレフィックス (残り 28 ビット) で始まるため、最大 2^(28-23) = 32 個の異なるマルチキャスト IP アドレスを同じイーサネット アドレスにマッピングできることを意味します。その結果、デバイスは要求していないマルチキャスト トラフィックを受信する可能性があります。
The address allocation guidelines in [RFC5771] did not account for this type of collision when they were created. Because of this limitation, the recommended approach for new designs that need dynamic multicast IP address assignment is to use IPv6 instead of IPv4.
[RFC5771] のアドレス割り当てガイドラインは、作成時にこのタイプの衝突を考慮していませんでした。この制限のため、動的なマルチキャスト IP アドレスの割り当てを必要とする新しい設計には、IPv4 の代わりに IPv6 を使用することをお勧めします。
However, if using IPv4 is necessary, then multicast addresses SHOULD be chosen carefully from within the Administratively Scoped Block (239.0.0.0/8). Additionally, solutions for zeroconf multicast address allocation SHOULD try to avoid using addresses that may already be in use by other applications on the same network, to minimize the risk of conflicts.
ただし、IPv4 の使用が必要な場合は、マルチキャスト アドレスは管理範囲ブロック (239.0.0.0/8) 内から慎重に選択する必要があります (SHOULD)。さらに、zeroconf マルチキャスト アドレス割り当てのソリューションでは、競合のリスクを最小限に抑えるために、同じネットワーク上の他のアプリケーションによってすでに使用されている可能性のあるアドレスの使用を避けるように努めるべきです (SHOULD)。
Zeroconf coexistence with other IPv4 multicast address allocation solutions may not be possible; in that case, it may be necessary to require manual configuration or to limit the solutions that are deployed.
Zeroconf と他の IPv4 マルチキャスト アドレス割り当てソリューションとの共存は不可能な場合があります。その場合、手動構成が必要になるか、展開されるソリューションを制限することが必要になる場合があります。
Zeroconf multicast address allocation mechanisms are vulnerable to accidental or malicious address collisions, which may lead to denial of service or misdirection of traffic. Solutions derived from these requirements SHALL include measures for collision detection and conflict resolution [REQ-8], and SHOULD include measures to prevent unauthorized address use. Specific security mechanisms are outside the scope of this document.
Zeroconf マルチキャスト アドレス割り当てメカニズムは、偶発的または悪意のあるアドレス衝突に対して脆弱であり、サービス拒否やトラフィックの誤った方向につながる可能性があります。これらの要件から導き出される解決策には、衝突検出と競合解決の手段が含まれなければなりません [REQ-8]。また、不正なアドレス使用を防止する手段も含まれるべきです (SHOULD)。特定のセキュリティ メカニズムについては、このドキュメントの範囲外です。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<https://www.rfc-editor.org/info/rfc3307>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
DOI 10.17487/RFC2730, December 1999,
<https://www.rfc-editor.org/info/rfc2730>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
August 2002, <https://www.rfc-editor.org/info/rfc3306>.
[RFC4489] Park, J., Shin, M., and H. Kim, "A Method for Generating
Link-Scoped IPv6 Multicast Addresses", RFC 4489,
DOI 10.17487/RFC4489, April 2006,
<https://www.rfc-editor.org/info/rfc4489>.
[US6690667B1]
Warren, D., "Switch with adaptive address lookup hashing
scheme", United States Patent 6690667B1, 10 February 2004,
<https://patents.google.com/patent/US6690667B1/en>.
The way multicast IP addresses are mapped to link-layer multicast addresses is already defined in existing standards, such as [RFC1112] for IPv4 over Ethernet and [RFC2464] for IPv6 over Ethernet. These standards specify a fixed prefix used in creating the Ethernet multicast address. Changing this prefix would open the door to new solutions, but those are not being considered here for practical reasons.
マルチキャスト IP アドレスをリンク層マルチキャスト アドレスにマッピングする方法は、IPv4 over Ethernet の [RFC1112] や IPv6 over Ethernet の [RFC2464] などの既存の標準ですでに定義されています。これらの標準は、イーサネット マルチキャスト アドレスの作成に使用される固定プレフィックスを指定します。このプレフィックスを変更すると、新しいソリューションへの扉が開かれますが、実際的な理由から、ここではそれらは考慮されていません。
One idea is to reduce the size of the fixed prefix, which would leave more bits available for the group ID. This would make address collisions less likely. Another idea is to create a new protocol that dynamically maps multicast IP addresses to link-layer addresses, similar to how DHCP assigns IP addresses. This protocol could work locally on a subnet, and routers could adjust the mapping for incoming multicast traffic at the network edge.
1 つのアイデアは、固定プレフィックスのサイズを削減して、グループ ID に使用できるビットを増やすことです。これにより、アドレス衝突の可能性が低くなります。もう 1 つのアイデアは、DHCP が IP アドレスを割り当てる方法と同様に、マルチキャスト IP アドレスをリンク層アドレスに動的にマッピングする新しいプロトコルを作成することです。このプロトコルはサブネット上でローカルに動作し、ルーターはネットワーク エッジで受信マルチキャスト トラフィックのマッピングを調整できます。
However, these ideas would require significant changes to how network devices handle multicast traffic. Since existing hardware and operating systems are built around the current standards, it's unlikely that such changes would be widely supported anytime soon.
ただし、これらのアイデアには、ネットワーク デバイスがマルチキャスト トラフィックを処理する方法に大幅な変更が必要になります。既存のハードウェアとオペレーティング システムは現在の標準に基づいて構築されているため、そのような変更がすぐに広くサポートされる可能性は低いです。
Another potential solution for IPv4 was to assign 32 separate, non-overlapping address ranges to avoid collisions altogether (e.g., assign 224.0.0.254, 224.128.0.254, 225.0.0.254, etc.). However, this was rejected because [RFC5771] discourages new allocations, given how limited the IPv4 multicast address space already is.
IPv4 のもう 1 つの潜在的な解決策は、衝突を完全に回避するために 32 の個別の重複しないアドレス範囲を割り当てることでした (たとえば、224.0.0.254、224.128.0.254、225.0.0.254 などを割り当てる)。しかし、IPv4 マルチキャスト アドレス空間がすでにどれほど限られているかを考慮すると、[RFC5771] は新しい割り当てを妨げているため、これは拒否されました。
Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research.
海洋産業標準の開発に貢献し、この研究を支援してくれた National Marine Electronics Association に特に感謝します。
Thanks also to the members of the PIM Working Group for their early brainstorming sessions and review of this document, and to Gunter van de Velde for his review and suggestions.
また、初期のブレーンストーミング セッションとこの文書のレビューに協力してくれた PIM ワーキング グループのメンバー、およびレビューと提案をしてくれた Gunter van de Velde にも感謝します。
Nate Karstens
Garmin International, Inc.
1200 E. 151st St.
Olathe, KS 66062-3426
United States of America
Email: nate.karstens@gmail.com
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
Mike McBride
Futurewei
United States of America
Email: michael.mcbride@futurewei.com