[要約] RFC 4286は、マルチキャストルーターの発見に関するプロトコルであり、マルチキャストグループへの参加をサポートするために設計されています。このRFCの目的は、ネットワーク内のマルチキャストルーターを自動的に検出し、効率的なマルチキャスト通信を実現することです。
Network Working Group B. Haberman
Request for Comments: 4286 JHU APL
Category: Standards Track J. Martin
Netzwert AG
December 2005
Multicast Router Discovery
マルチキャストルーターの発見
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングの概念には、マルチキャストルーターの位置を識別する機能が必要です。スヌーピングは標準化されていないため、マルチキャストルーターを識別するために使用されている多くのメカニズムがあります。ただし、これにより、マルチキャストルーターとさまざまなベンダーからのスヌーピングスイッチ間の相互運用性の問題につながる可能性があります。
This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.
このドキュメントでは、マルチキャストルーターの発見を可能にする一般的なメカニズムを紹介します。この新しいメカニズムであるマルチキャストルーター発見（MRD）は、特定のマルチキャストルーティングプロトコルに依存せずにマルチキャストルーターを識別する標準化された手段を導入します。
Table of Contents
目次
1. Introduction ....................................................3
2. Protocol Overview ...............................................3
3. Multicast Router Advertisement ..................................4
3.1. Advertisement Configuration Variables ......................4
3.1.1. AdvertisementInterval ...............................5
3.1.2. AdvertisementJitter .................................5
3.1.3. MaxInitialAdvertisementInterval .....................5
3.1.4. MaxInitialAdvertisements ............................5
3.1.5. NeighborDeadInterval ................................5
3.1.6. MaxMessageRate ......................................6
3.2. Advertisement Packet Format ................................6
3.2.1. Type Field ..........................................6
3.2.2. Advertisement Interval Field ........................6
3.2.3. Checksum Field ......................................6
3.2.4. Query Interval Field ................................7
3.2.5. Robustness Variable Field ...........................7
3.3. IP Header Fields ...........................................7
3.3.1. Source Address ......................................7
3.3.2. Destination Address .................................7
3.3.3. Time-to-Live / Hop Limit ............................7
3.3.4. IPv4 Protocol .......................................7
3.3.5. IPv6 Next Header ....................................7
3.4. Sending Multicast Router Advertisements ....................8
3.5. Receiving Multicast Router Advertisements ..................8
4. Multicast Router Solicitation ...................................9
4.1. Solicitation Packet Format .................................9
4.1.1. Type Field ..........................................9
4.1.2. Reserved Field ......................................9
4.1.3. Checksum Field ......................................9
4.2. IP Header Fields ..........................................10
4.2.1. Source Address .....................................10
4.2.2. Destination Address ................................10
4.2.3. Time-to-Live / Hop Limit ...........................10
4.2.4. IPv4 Protocol ......................................10
4.2.5. IPv6 Next Header ...................................10
4.3. Sending Multicast Router Solicitations ....................10
4.4. Receiving Multicast Router Solicitations ..................10
5. Multicast Router Termination ...................................11
5.1. Termination Packet Format .................................11
5.1.1. Type Field .........................................11
5.1.2. Reserved Field .....................................11
5.1.3. Checksum Field .....................................11
5.2. IP Header Fields ..........................................12
5.2.1. Source Address .....................................12
5.2.2. Destination Address ................................12
5.2.3. Time-to-Live / Hop Limit ...........................12
5.2.4. IPv4 Protocol ......................................12
5.2.5. IPv6 Next Header ...................................12
5.3. Sending Multicast Router Terminations .....................12
5.4. Receiving Multicast Router Terminations ...................12
6. Protocol Constants .............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
Multicast Router Discovery (MRD) messages are useful for determining which nodes attached to a switch have multicast routing enabled. This capability is useful in a layer-2 bridging domain with snooping switches. By utilizing MRD messages, layer-2 switches can determine where to send multicast source data and group membership messages [1] [2]. Multicast source data and group membership reports must be received by all multicast routers on a segment. Using the group membership protocol Query messages to discover multicast routers is insufficient due to query suppression.
マルチキャストルーター発見（MRD）メッセージは、スイッチに接続されているノードがマルチキャストルーティングを有効にしているかを判断するのに役立ちます。この機能は、スヌーピングスイッチを備えたレイヤー2ブリッジングドメインで役立ちます。MRDメッセージを利用することにより、レイヤー-2スイッチは、マルチキャストソースデータとグループメンバーシップメッセージを送信する場所を決定できます[1] [2]。マルチキャストソースデータとグループメンバーシップレポートは、セグメント上のすべてのマルチキャストルーターが受信する必要があります。グループメンバーシッププロトコルクエリメッセージを使用してマルチキャストルーターを発見するには、クエリ抑制のために不十分です。
Although MRD messages could be sent as ICMP messages, the group management protocols were chosen since this functionality is multicast specific. The addition of this functionality to the group membership protocol also allows operators to have congruence between MRD problems and data forwarding issues.
MRDメッセージはICMPメッセージとして送信できますが、この機能はマルチキャスト固有であるため、グループ管理プロトコルが選択されました。この機能をグループメンバーシッププロトコルに追加することで、オペレーターはMRDの問題とデータ転送の問題との間に一致することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].
「必須」、「必要」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうはならない」、「そうでない」、「推奨」、「5月」、および「オプション」は[3]に記載されていると解釈されます。
Multicast Router Discovery consists of three messages for discovering multicast routers. The Multicast Router Advertisement is sent by routers to advertise that IP multicast forwarding is enabled. Devices may send Multicast Router Solicitation messages in order to solicit Advertisement messages from multicast routers. The Multicast Router Termination messages are sent when a router stops IP multicast routing functions on an interface.
マルチキャストルーターの発見は、マルチキャストルーターを発見するための3つのメッセージで構成されています。マルチキャストルーター広告は、IPマルチキャスト転送が有効になっていることを宣伝するためにルーターによって送信されます。デバイスは、マルチキャストルーターからの広告メッセージを求めるために、マルチキャストルーターの勧誘メッセージを送信する場合があります。マルチキャストルーター終了メッセージは、ルーターがインターフェイス上のIPマルチキャストルーティング機能を停止すると送信されます。
Multicast routers send unsolicited Advertisements periodically on all interfaces on which multicast forwarding is enabled. Advertisement messages are also sent in response to Solicitations. In addition to advertising the location of multicast routers, Advertisements also convey useful information concerning group management protocol variables. This information can be used for consistency checking on the subnet.
マルチキャストルーターは、マルチキャスト転送が有効になっているすべてのインターフェイスで定期的に未承諾広告を送信します。広告メッセージは、勧誘に応じて送信されます。マルチキャストルーターの場所を宣伝することに加えて、広告はグループ管理プロトコル変数に関する有用な情報も伝えます。この情報は、サブネットの一貫性チェックに使用できます。
A device sends Solicitation messages whenever it wishes to discover multicast routers on a directly attached link.
デバイスは、直接接続されたリンクでマルチキャストルーターを発見したい場合はいつでも、勧誘メッセージを送信します。
A router sends Termination messages when it terminates multicast routing functionality on an interface.
ルーターは、インターフェイス上のマルチキャストルーティング機能を終了するときに終了メッセージを送信します。
All MRD messages are sent with an IPv4 Time to Live (TTL) or IPv6 Hop Limit of 1 and contain the Router Alert Option [4] [5]. All MRD messages SHOULD be rate-limited as per the MaxMessageRate variable.
すべてのMRDメッセージは、1のIPv4時間（TTL）またはIPv6ホップ制限で送信され、ルーターアラートオプション[4] [5]が含まれています。すべてのMRDメッセージは、maxmessagerate変数に従ってレート制限する必要があります。
Advertisement and Termination messages are sent to the All-Snoopers multicast address.
広告メッセージと終了メッセージは、All-Snoopersマルチキャストアドレスに送信されます。
Solicitation messages are sent to the All-Routers multicast address.
勧誘メッセージは、オールルーターのマルチキャストアドレスに送信されます。
Any data beyond the fixed message format MUST be ignored.
固定メッセージ形式を超えたデータは無視する必要があります。
Multicast Router Advertisements are sent unsolicited periodically on all router interfaces on which multicast forwarding is enabled. They are also sent in response to Multicast Router Solicitation messages.
マルチキャストルーター広告は、マルチキャスト転送が有効になっているすべてのルーターインターフェイスで定期的に承認されていません。また、マルチキャストルーターの勧誘メッセージに応じて送信されます。
Advertisements are sent
広告が送信されます
1. Upon the expiration of a periodic (modulo randomization) timer
1. 周期（モジュロランダム化）タイマーの有効期限が
2. As part of a router's start-up procedure
2. ルーターの起動手順の一部として
3. During the restart of a multicast forwarding interface
3. マルチキャスト転送インターフェイスの再起動中
4. On receipt of a Solicitation message
4. 勧誘メッセージを受け取ったとき
All Advertisements are sent as Internet Group Management Protocol (for IPv4) or Multicast Listener Discovery (for IPv6) messages to the All-Snoopers multicast address. These messages SHOULD be rate-limited as per the MaxMessageRate variable.
すべての広告は、インターネットグループ管理プロトコル（IPv4用）またはマルチキャストリスナーディスカバリー（IPv6用）メッセージとして送信されます。これらのメッセージは、maxmessagerate変数に従って料金制限する必要があります。
An MRD implementation MUST support the following variables being configured by system management. Default values are specified to make it unnecessary to configure any of these variables in many cases.
MRDの実装は、システム管理によって構成されている次の変数をサポートする必要があります。デフォルト値は、多くの場合、これらの変数のいずれかを構成する必要がないように指定されています。
This variable is the base interval (in integer seconds) between the transmissions of unsolicited Advertisements on an interface. This value MUST be no less than 4 seconds and no greater than 180 seconds.
この変数は、インターフェイス上の未承諾広告の送信の間のベース間隔（整数秒）です。この値は4秒以上、180秒以下でなければなりません。
Default: 20 seconds
デフォルト：20秒
This is the maximum time (in seconds) by which the AdvertisementInterval is perturbed for each unsolicited Advertisement. Note that the purpose of this jitter is to avoid synchronization of multiple routers on a network, hence choosing a value of zero is discouraged. This value MUST be an integer no less than 0 seconds and no greater than AdvertisementInterval.
これは、AdvertisementIntervalが未承諾の広告ごとに摂動される最大時間（秒単位）です。このジッターの目的は、ネットワーク上の複数のルーターの同期を避けることであるため、ゼロの値を選択することは推奨されていません。この値は、0秒以上、AdvertisementIntervalよりも大きい整数でなければなりません。
The AdvertisementJitter MUST be 0.025*AdvertisementInterval
AdvertisementJitterは0.025*AdvertisementIntervalでなければなりません
The first unsolicited Advertisement transmitted on an interface is sent after waiting a random interval (in seconds) less than this variable. This prevents a flood of Advertisements when multiple routers start up at the same time.
インターフェイスに送信された最初の未承諾の広告は、この変数よりも少ないランダムな間隔（秒）を待った後に送信されます。これにより、複数のルーターが同時に起動すると、広告の洪水が防止されます。
Default: 2 seconds
デフォルト：2秒
This variable is the maximum number of unsolicited Advertisements that will be transmitted by the advertising interface when MRD starts up.
この変数は、MRDが起動したときに広告インターフェイスによって送信される未承諾の広告の最大数です。
Default: 3
デフォルト：3
The NeighborDeadInterval variable is the maximum time (in seconds) allowed to elapse (after receipt of the last valid Advertisement) before a neighboring router is declared unreachable. This variable is maintained per neighbor. An MRD receiver should set the NeighborDeadInterval to 3 times the sum of Advertisement Interval Field received plus the AdvertisementJitter calculated from the received Advertisement Interval Field. This ensures consistent behavior between multiple devices on a network.
NeighbordeadedInterval変数は、隣接するルーターが到達不可能であると宣言される前に、（最後の有効な広告を受け取った後）経過を許可された最大時間（秒単位）です。この変数は、隣人ごとに維持されます。MRDレシーバーは、neighbordeadIntervalを受信した広告間隔フィールドの3倍に設定し、受信した広告間隔フィールドから計算されたAdvertisementJitterに設定する必要があります。これにより、ネットワーク上の複数のデバイス間で一貫した動作が保証されます。
Default : 3 * (Advertisement Interval Field + calculated AdvertisementJitter)
デフォルト：3 *（Advertisement Intervalフィールド計算されたAdvertisementJitter）
The MaxMessageRate variable is the maximum aggregate number of messages an MRD implementation SHOULD send (per second) per interface or per management or logging destination.
Maxmessagerate変数は、MRD実装がインターフェイスまたは管理宛先またはロギング宛先ごとに（秒あたり）送信するメッセージの最大集約数です。
Default: 10
デフォルト：10
The Advertisement message has the following format:
広告メッセージには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Ad. Interval | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Interval | Robustness Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field identifies the message as an Advertisement. It is set to 0x30 for IPv4 and 151 for IPv6.
タイプフィールドは、メッセージを広告として識別します。IPv4では0x30、IPv6で151に設定されています。
This field specifies the periodic time interval at which unsolicited Advertisement messages are transmitted in units of seconds. This value is set to the configured AdvertisementInterval.
このフィールドは、未承諾の広告メッセージが秒単位で送信される定期時間間隔を指定します。この値は、構成された広告間隔に設定されています。
The checksum field is set as follows:
チェックサムフィールドは次のように設定されています。
1. For IPv4 it is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the Type field. For computing the checksum, the checksum field is set to 0.
1. IPv4の場合、それはタイプフィールドから始まるIGMPメッセージの補完合計の16ビットの補完です。チェックサムを計算するために、チェックサムフィールドは0に設定されています。
2. For IPv6 it is ICMPv6 checksum as specified in [6].
2. IPv6の場合、[6]で指定されているICMPv6チェックサムです。
The Query Interval field is set to the Query Interval value (in seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is not enabled on the advertising interface, this field MUST be set to 0. Note that this is the Querier's Query Interval (QQI), not the Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD specifications.
クエリ間隔フィールドは、インターフェイスでIGMPまたはMLDが使用するクエリ間隔値（秒単位）に設定されます。IGMPまたはMLDが広告インターフェイスで有効になっていない場合、このフィールドは0に設定する必要があります。これは、IGMP/MLD仕様で指定されているQuerierのクエリインターバルコード（QQIC）ではなく、Querierのクエリ間隔（QQI）であることに注意してください。
This field is set to the Robustness Variable in use by IGMPv2 [2], IGMPv3 [7], or MLD [8] [9] on the advertising interface. If IGMPv1 is in use or no group management protocol is enabled on the interface, this field MUST be set to 0.
このフィールドは、広告インターフェイスでIGMPv2 [2]、IGMPv3 [7]、またはMLD [8] [9]によって使用される堅牢性変数に設定されています。IGMPV1が使用されている場合、またはインターフェイスでグループ管理プロトコルが有効になっている場合、このフィールドは0に設定する必要があります。
The IP source address is set to an IP address configured on the advertising interface. For IPv6, a link-local address MUST be used.
IPソースアドレスは、広告インターフェイスで構成されたIPアドレスに設定されています。IPv6の場合、リンクローカルアドレスを使用する必要があります。
The IP destination address is set to the All-Snoopers multicast address.
IP宛先アドレスは、All-Snoopersマルチキャストアドレスに設定されています。
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTLおよびIPv6ホップ制限は1に設定されています。
The IPv4 Protocol field is set to IGMP (2).
IPv4プロトコルフィールドはIGMPに設定されています（2）。
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPV6ヘッダーは、直前のヘッダー[6]の次のヘッダー値58によって識別されます。
Advertisement messages are sent when the following events occur:
次のイベントが発生したときに広告メッセージが送信されます。
1. The expiration of the periodic advertisement interval timer. Note that this timer is not strictly periodic since the base AdvertisementInterval is varied at each interval by a random value no more than plus or minus AdvertisementJitter seconds.
1. 周期的な広告間隔タイマーの有効期限。Base AdvertisementIntervalは、各間隔ではプラスまたはマイナスAdvertisementJitterの秒以下のランダムな値によって変化するため、このタイマーは厳密に周期的ではないことに注意してください。
2. After a random delay less than MaxInitialAdvertisementInterval when an interface is first enabled, is (re-)initialized, or MRD is enabled. A router may send up to a maximum of MaxInitialAdvertisements Advertisements, waiting for a random delay less than MaxInitialAdvertisementInterval between each successive message. Multiple Advertisements are sent for robustness in the face of packet loss on the network.
2. インターフェイスが最初に有効になっている場合、MaxInitialAdvertisementIntervalよりも少ないランダムな遅延の後、（再）初期化、またはMRDが有効になっています。ルーターは、最大のMaxInitialAdvertisements広告に送信され、各連続したメッセージの間でMaxInitialAdvertisementInterval未満のランダム遅延を待っています。ネットワーク上のパケット損失に直面して、堅牢性のために複数の広告が送信されます。
This is to prevent an implosion of Advertisements. An example of this occurring would be when many routers are powered on at the same time. When a Solicitation is received, an Advertisement is sent in response with a random delay less than MAX_RESPONSE_DELAY. If a Solicitation is received while an Advertisement is pending, that Solicitation MUST be ignored.
これは、広告の崩壊を防ぐためです。この発生の例は、多くのルーターが同時に電源を入れている場合です。勧誘を受け取ると、MAX_RESPONSE_DELAYよりも少ないランダムな遅延で、それに応じて広告が送信されます。広告が保留中に勧誘が受け取られた場合、その勧誘は無視する必要があります。
Changes in the Query Interval or Robustness Variable MUST NOT trigger a new Advertisement; however, the new values MUST be used in all future Advertisement messages.
クエリ間隔または堅牢性変数の変更は、新しい広告をトリガーしてはなりません。ただし、新しい値は、将来のすべての広告メッセージで使用する必要があります。
When an Advertisement is sent, the periodic advertisement interval timer MUST be reset.
広告が送信される場合、定期的な広告インターバルタイマーをリセットする必要があります。
Upon receiving an Advertisement message, devices validate the message with the following criteria:
広告メッセージを受信すると、デバイスは次の基準でメッセージを検証します。
1. The checksum is correct
1. チェックサムは正しいです
2. The IP destination address is equal to the All-Snoopers multicast address
2. IP宛先アドレスはオールスヌーパーのマルチキャストアドレスに等しくなります
3. For IPv6, the IP source address is a link-local address
3. IPv6の場合、IPソースアドレスはリンクローカルアドレスです
An Advertisement not meeting the validity requirements MUST be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
有効性の要件を満たさない広告は静かに破棄され、MaxMessagerate変数に従ってレート制限された方法で記録する必要があります。
If an Advertisement is not received for a particular neighbor within a NeighborDeadInterval time interval, then the neighbor is considered unreachable.
NeighbordeadeadInterval時間間隔内の特定の隣人の広告が受け取られていない場合、隣人は到達不能と見なされます。
Multicast Router Solicitation messages are used to solicit Advertisements from multicast routers on a segment. These messages are used when a device wishes to discover multicast routers. Upon receiving a solicitation on an interface with IP multicast forwarding and MRD enabled, a router will respond with an Advertisement.
マルチキャストルーターの勧誘メッセージは、セグメントのマルチキャストルーターからの広告を求めるために使用されます。これらのメッセージは、デバイスがマルチキャストルーターを発見したいときに使用されます。IPマルチキャスト転送とMRDが有効になっているインターフェイスで勧誘を受信すると、ルーターが広告で応答します。
Solicitations may be sent when these occur:
これらが発生したときに勧誘が送信される場合があります。
1. An interface is (re-)initialized
1. インターフェイスが（再）初期化されます
2. MRD is enabled
2. MRDが有効になっています
Solicitations are sent to the All-Routers multicast address and SHOULD be rate-limited, as per the MaxMessageRate variable.
勧誘は、Maxmessagerate変数に従って、全ルーターのマルチキャストアドレスに送信され、レート制限される必要があります。
The Solicitation message has the following format:
勧誘メッセージには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field identifies the message as a Solicitation. It is set to 0x31 for IPv4 and 152 for IPv6.
タイプフィールドは、メッセージを勧誘として識別します。IPv4では0x31、IPv6で152に設定されています。
The Reserved field is set to 0 on transmission and ignored on reception.
予約済みフィールドは、送信時に0に設定され、受信で無視されます。
The checksum field is set as follows:
チェックサムフィールドは次のように設定されています。
o For IPv4 it is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the Type field. For computing the checksum, the checksum field is set to 0.
o IPv4の場合、それはタイプフィールドから始まるIGMPメッセージの補完合計の16ビットの補完です。チェックサムを計算するために、チェックサムフィールドは0に設定されています。
o For IPv6 it is ICMPv6 checksum as specified in [6].
o IPv6の場合、[6]で指定されているICMPv6チェックサムです。
The IP source address is set to an IP address configured on the soliciting interface. For IPv6, a link-local address MUST be used.
IPソースアドレスは、勧誘インターフェイスで構成されたIPアドレスに設定されています。IPv6の場合、リンクローカルアドレスを使用する必要があります。
The IP destination address is set to the All-Routers multicast address.
IP宛先アドレスは、オールルーターのマルチキャストアドレスに設定されています。
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTLおよびIPv6ホップ制限は1に設定されています。
The IPv4 Protocol field is set to IGMP (2).
IPv4プロトコルフィールドはIGMPに設定されています（2）。
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPV6ヘッダーは、直前のヘッダー[6]の次のヘッダー値58によって識別されます。
Solicitation messages are sent when the following events occur:
勧誘メッセージは、次のイベントが発生したときに送信されます。
o After waiting for a random delay less than MAX_SOLICITATION_DELAY when an interface first becomes operational, is (re-)initialized, or MRD is enabled. A device may send up to a maximum of MAX_SOLICITATIONS, waiting for a random delay less than MAX_SOLICITATION_DELAY between each solicitation.
o インターフェイスが最初に動作する場合、MAX_Solicitation_Delayよりも少ないランダムな遅延を待った後、（再）初期化されるか、MRDが有効になっています。デバイスは、各勧誘の間でmax_solicitation_delayよりも少ないランダム遅延を待機して、最大のmax_solicitationsまで送信する場合があります。
o Optionally, for an implementation specific event.
o オプションで、実装固有のイベントの場合。
Solicitations MUST be rate-limited as per the MaxMessageRate variable; the implementation MUST send no more than MAX_SOLICITATIONS in MAX_SOLICITATION_DELAY seconds.
勧誘は、maxmessagerate変数に従って料金制限されている必要があります。実装は、max_solicitation_delay秒でmax_solicitations以外に送信する必要があります。
A Solicitation message MUST be validated before a response is sent. A router MUST verify the following: o The checksum is correct.
応答が送信される前に、勧誘メッセージを検証する必要があります。ルーターは次のことを確認する必要があります。Oチェックサムは正しいです。
o The IP destination address is the All-Routers multicast address.
o IP宛先アドレスは、オールルーターのマルチキャストアドレスです。
o For IPv6, the IP source address MUST be a link-local address.
o IPv6の場合、IPソースアドレスはリンクローカルアドレスでなければなりません。
Solicitations not meeting the validity requirements SHOULD be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
有効性の要件を満たさない勧誘は、静かに廃棄されるべきであり、Maxmessagerate変数に従ってレートに制限された方法で記録される可能性があります。
The Multicast Router Termination message is used to expedite the notification of a change in the status of a router's multicast forwarding functions. Multicast routers send Terminations when multicast forwarding is disabled on the advertising interface.
マルチキャストルーター終了メッセージは、ルーターのマルチキャスト転送機能のステータスの変更の通知を促進するために使用されます。マルチキャストルーターは、広告インターフェイスでマルチキャスト転送が無効になっているときに終端を送信します。
The Termination message has the following format:
終了メッセージには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field identifies the message as a Termination. It is set to 0x32 for IPv4 and 153 for IPv6.
タイプフィールドは、メッセージを終了として識別します。IPv4では0x32、IPv6で153に設定されています。
The Reserved field is set to 0 on transmission and ignored on reception.
予約済みフィールドは、送信時に0に設定され、受信で無視されます。
The checksum field is set as follows:
チェックサムフィールドは次のように設定されています。
o For IPv4 it is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the Type field. For computing the checksum, the checksum field is set to 0.
o IPv4の場合、それはタイプフィールドから始まるIGMPメッセージの補完合計の16ビットの補完です。チェックサムを計算するために、チェックサムフィールドは0に設定されています。
o For IPv6 it is ICMPv6 checksum as specified in [6].
o IPv6の場合、[6]で指定されているICMPv6チェックサムです。
The IP source address is set to an IP address configured on the advertising interface. For IPv6, a link-local address MUST be used.
IPソースアドレスは、広告インターフェイスで構成されたIPアドレスに設定されています。IPv6の場合、リンクローカルアドレスを使用する必要があります。
The IP destination address is set to the All-Snoopers multicast address.
IP宛先アドレスは、All-Snoopersマルチキャストアドレスに設定されています。
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTLおよびIPv6ホップ制限は1に設定されています。
The IPv4 Protocol field is set to IGMP (2).
IPv4プロトコルフィールドはIGMPに設定されています（2）。
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPV6ヘッダーは、直前のヘッダー[6]の次のヘッダー値58によって識別されます。
Termination messages are sent by multicast routers when
終了メッセージは、マルチキャストルーターによって送信されます
o Multicast forwarding is disabled on an interface
o マルチキャスト転送はインターフェイスで無効になっています
o An interface is administratively disabled
o インターフェイスは管理上無効です
o The router is gracefully shut down
o ルーターは優雅にシャットダウンされています
o MRD is disabled
o MRDは無効です
The sending of Termination messages SHOULD be rate-limited as per the MaxMessageRate variable.
終了メッセージの送信は、maxmessagerate変数に従って料金制限する必要があります。
Upon receiving a Termination message, devices validate the message. The validation criteria are the following:
終了メッセージを受信すると、デバイスはメッセージを検証します。検証基準は次のとおりです。
o Checksum MUST be correct.
o チェックサムは正しい必要があります。
o IP destination address MUST equal the All-Snoopers multicast address.
o IP宛先アドレスは、すべてのスヌーパーマルチキャストアドレスに等しくなければなりません。
o For IPv6, the IP source address MUST be a link-local address.
o IPv6の場合、IPソースアドレスはリンクローカルアドレスでなければなりません。
Termination messages not meeting the validity requirements MUST be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
有効性の要件を満たさない終了メッセージは静かに破棄する必要があり、Maxmessagerate変数に従ってレート制限された方法で記録される場合があります。
If the message passes these validation steps, a Solicitation is sent. If an Advertisement is not received within NeighborDeadInterval, the sending router is removed from the list of active multicast routers.
メッセージがこれらの検証手順を渡すと、勧誘が送信されます。Adveryedeadedinterval内で広告が受信されない場合、送信ルーターはアクティブなマルチキャストルーターのリストから削除されます。
The following list identifies constants used in the MRD protocol. These constants are used in the calculation of parameters.
次のリストは、MRDプロトコルで使用される定数を識別します。これらの定数は、パラメーターの計算で使用されます。
o MAX_RESPONSE_DELAY 2 seconds
o max_response_delay 2秒
o MAX_SOLICITATION_DELAY 1 second
o max_solicitation_delay 1秒
o MAX_SOLICITATIONS 3 transmissions
o MAX_SOLICITATIONS 3送信
As MRD is a link-local protocol, there is no circumstance in which it would be correct for an MRD receiver to receive MRD traffic from an off-network source. For IPv6, MRD messages MUST have a valid link-local source address. Any messages received without a valid link-local source address MUST be discarded. Similarly, for IPv4, the MRD receiver MUST determine if the source address is local to the receiving interface, and MUST discard any messages that have a non-local source. Determining what networks are local may be accomplished through configuration information or operational capabilities.
MRDはLink-Localプロトコルであるため、MRDレシーバーがネットワーク外のソースからMRDトラフィックを受信することが正しい状況はありません。IPv6の場合、MRDメッセージには有効なリンクローカルソースアドレスが必要です。有効なリンクローカルソースアドレスなしで受信したメッセージは破棄する必要があります。同様に、IPv4の場合、MRDレシーバーは、ソースアドレスが受信インターフェイスにローカルであるかどうかを判断し、非ローカルソースを持つメッセージを破棄する必要があります。どのネットワークがローカルであるかを決定することは、構成情報または運用機能を通じて達成される場合があります。
Rogue nodes may attempt to attack a network running MRD by sending spoofed Advertisement, Solicitation, or Termination messages. Each type of spoofed message can be dealt with using existing technology.
Rogueノードは、スプーフィングされた広告、勧誘、または終了メッセージを送信することにより、MRDを実行しているネットワークを攻撃しようとする場合があります。スプーフィングされた各タイプのメッセージは、既存のテクノロジーの使用に対処できます。
A rogue node may attempt to interrupt multicast service by sending spoofed Termination messages. As described in Section 5.4, all Termination messages are validated by sending a Solicitation message. By sending a Solicitation, the node will force the transmission of an Advertisement by an active router.
Rogueノードは、スプーフィングされた終了メッセージを送信することにより、マルチキャストサービスを中断しようとする場合があります。セクション5.4で説明したように、すべての終了メッセージは、勧誘メッセージを送信することにより検証されます。勧誘を送信することにより、ノードはアクティブなルーターによる広告の送信を強制します。
Spoofed Solicitation messages do not cause any operational harm. They may be used as a flooding mechanism to attack a multicast router. This attack can be mitigated through the rate-limiting recommendation for all MRD messages.
スプーフィングされた勧誘メッセージは、運用上の害を引き起こしません。それらは、マルチキャストルーターを攻撃するための洪水メカニズムとして使用できます。この攻撃は、すべてのMRDメッセージに対するレート制限の推奨を通じて軽減できます。
The Multicast Router Advertisement message may allow rogue machines to masquerade as multicast routers. This could allow those machines to eavesdrop on multicast data transmissions. Additionally, it could constitute a denial of service attack to other hosts in the same snooping domain or sharing the same device port in the presence of high-rate multicast flows.
マルチキャストルーター広告メッセージにより、Rogue Machinesがマルチキャストルーターを装備できる場合があります。これにより、これらのマシンがマルチキャストデータ送信を盗聴できるようになります。さらに、同じスヌーピングドメインの他のホストに対するサービス拒否攻撃を構成するか、高レートのマルチキャストフローの存在下で同じデバイスポートを共有することができます。
The technology available in SEND [10] can be utilized to address spoofed Advertisement messages in IPv6 networks. IPv6 Multicast routers in an MRD-enabled network can use SEND-based link-local addresses as the IPv6 source address for MRD messages. When a switch receives an initial Advertisement, it can use the information in the SEND-based address to challenge the router to authenticate itself. It should be noted that this approach only applies to IPv6 networks.
送信[10]で利用可能なテクノロジーは、IPv6ネットワークのスプーフィングされた広告メッセージに対処するために利用できます。MRD対応ネットワークのIPv6マルチキャストルーターは、MRDメッセージのIPv6ソースアドレスとして送信ベースのリンクローカルアドレスを使用できます。スイッチが初期広告を受信すると、送信ベースのアドレスの情報を使用して、ルーターに挑戦して自体を認証できます。このアプローチはIPv6ネットワークにのみ適用されることに注意する必要があります。
Another solution that supports both IPv4 and IPv6 is to use IPsec in Encapsulating Security Payload (ESP) mode [11] to protect against attacks by ensuring that messages came from a system with the proper key. When using IPsec, the messages sent to the All-Snoopers address should be authenticated using ESP. Should encryption not be desired, ESP with a null encryption algorithm and a symmetric authentication algorithm, such as HMAC-SHA-1, is viable. For keying, a symmetric signature algorithm with a single manually configured key is used for routers sending Advertisements. This allows validation that the MRD message was sent by a system with the key. It should be noted that this does not prevent a system with the key from forging a message and it requires the disabling of IPsec's Replay Protection. It is the responsibility of the network administrator to ensure that the same key is present on all possible MRD participants.
IPv4とIPv6の両方をサポートするもう1つのソリューションは、セキュリティペイロード（ESP）モード[11]をカプセル化するIPSECを使用して、適切なキーを持つシステムからメッセージが届くようにすることにより、攻撃から保護することです。IPSECを使用する場合、All-Snoopersアドレスに送信されたメッセージをESPを使用して認証する必要があります。暗号化が望まれない場合、null暗号化アルゴリズムとHMAC-SHA-1などの対称認証アルゴリズムを備えたESPは実行可能です。キーイングの場合、1つの手動で構成されたキーを備えた対称署名アルゴリズムが、広告を送信するルーターに使用されます。これにより、MRDメッセージがキーを使用したシステムによって送信されたことが検証できます。これは、キーがメッセージの鍛造を防ぐことができず、IPSECのリプレイ保護を無効にする必要があることに注意する必要があります。ネットワーク管理者の責任は、すべての可能なMRD参加者に同じキーが存在するようにすることです。
This document introduces three new IGMP messages. Each of these messages requires a new IGMP Type value. The IANA has assigned three new IGMP Type values to the Multicast Router Discovery Protocol:
このドキュメントでは、3つの新しいIGMPメッセージを紹介します。これらの各メッセージには、新しいIGMPタイプの値が必要です。IANAは、3つの新しいIGMPタイプの値をマルチキャストルーターディスカバリープロトコルに割り当てました。
+-----------+-----------------+--------------------------------+
| IGMP Type | Section | Message Name |
+-----------+-----------------+--------------------------------+
| 0x30 | Section 3.2.1 | Multicast Router Advertisement |
| 0x31 | Section 4.1.1 | Multicast Router Solicitation |
| 0x32 | Section 5.1.1 | Multicast Router Termination |
+-----------+-----------------+--------------------------------+
This document also introduces three new MLD messages. Each of these messages requires a new ICMPv6 Type value. The IANA has assigned three new ICMPv6 Type values from the Informational range:
このドキュメントでは、3つの新しいMLDメッセージも導入されています。これらの各メッセージには、新しいICMPV6タイプの値が必要です。IANAは、情報範囲から3つの新しいICMPV6タイプの値を割り当てました。
+-------------+-----------------+--------------------------------+
| ICMPv6 Type | Section | Message Name |
+-------------+-----------------+--------------------------------+
| 151 | Section 3.2.1 | Multicast Router Advertisement |
| 152 | Section 4.1.1 | Multicast Router Solicitation |
| 153 | Section 5.1.1 | Multicast Router Termination |
+-------------+-----------------+--------------------------------+
This document also requires the assignment of an All-Snoopers multicast address for IPv4. This multicast address is in the 224.0.0/24 range since it is used for link-local, control messages. The IPv4 multicast address for All-Snoopers is 224.0.0.106.
このドキュメントでは、IPv4のAll-Snoopersマルチキャストアドレスの割り当ても必要です。このマルチキャストアドレスは、Link-Localのコントロールメッセージに使用されるため、224.0.0/24の範囲にあります。All-SnoopersのIPv4マルチキャストアドレスは224.0.0.106です。
A corresponding IPv6 multicast address has also been assigned. Following the guidelines in [12], the IPv6 multicast address is a link-local in scope and has a group-ID value equal to the low-order 8 bits of the requested IPv4 multicast address. The IPv6 multicast address is FF02:0:0:0:0:0:0:6A.
対応するIPv6マルチキャストアドレスも割り当てられています。[12]のガイドラインに従って、IPv6マルチキャストアドレスは範囲がリンクローカルであり、要求されたIPv4マルチキャストアドレスの低次8ビットに等しいグループID値を持っています。IPv6マルチキャストアドレスはFF02：0：0：0：0：0：6aです。
Brad Cain and Shantam Biswis are the authors of the original Multicast Router Discovery proposal.
Brad CainとShantam Biswisは、元のマルチキャストルーター発見提案の著者です。
ICMP Router Discovery [13] was used as a general model for Multicast Router Discovery.
ICMPルーター発見[13]は、マルチキャストルーター発見の一般的なモデルとして使用されました。
Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas provided helpful feedback on various versions of this document.
Morten Christensen、Pekka Savola、Hugh Holbrook、およびIsidor Kouvelasは、このドキュメントのさまざまなバージョンに関する有益なフィードバックを提供しました。
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[4] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[5] Partridge、C。and A. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[6] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[7] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[7] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[8] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[9] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[10] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[11] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[12] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[12] Haberman、B。、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、2002年8月。
[13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[13] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
Authors' Addresses
著者のアドレス
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマンジョンズホプキンス大学応用物理学ラボ11100ジョンズホプキンスロードローレル、メリーランド20723-6099 US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Jim Martin Netzwert AG An den Treptowers 1 D-12435 Berlin Germany
ジム・マーティン・ネッツワートAg an den treptowers 1 D-12435ベルリンドイツ
Phone: +49.30/5 900 80-1180
EMail: jim@netzwert.ag
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。