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).
著作権（C）インターネット協会（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）とMulticast Listener Discovery（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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メッセージは（TTL）または1のIPv6のホップ限界を生きてIPv4の時間で送信され、ルータ警告オプションを含有している[4] [5]。すべてのMRDメッセージがMaxMessageRate変数ごとにレート制限する必要があります。
Advertisement and Termination messages are sent to the All-Snoopers multicast address.
広告と終了メッセージはすべて、詮索のマルチキャストアドレスに送信されます。
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
広告は送信されます
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.
NeighborDeadInterval変数は、隣接ルータが到達不能と宣言される前に、（最後の有効な広告の受領後）経過させ最大時間（秒単位）です。この変数は、隣接ごとに維持されます。広告間隔フィールドの3倍の和にNeighborDeadIntervalを設定する必要がMRD受信機は、受信した広告間隔フィールドから計算AdvertisementJitter足した受信しました。これは、ネットワーク上の複数のデバイス間で一貫性のある動作を保証します。
Default : 3 * (Advertisement Interval Field + calculated AdvertisementJitter)
デフォルト：3 *（広告インターバル・フィールド+計算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.
Typeフィールドは、広告としてメッセージを識別します。 IPv4とIPv6のための151のために0x30をするように設定されています。
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.
このフィールドは、未承諾広告メッセージは秒単位で送信される定期的な時間間隔を指定します。この値は設定され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メッセージの1の補数和の16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドは0に設定されています。
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が広告インタフェースで有効になっていない場合、このフィールドは、これは質問者のクエリー間隔（QQI）であることを0に注意、IGMP / MLD仕様で指定されていないクエリアのクエリー間隔コード（QQIC）に設定しなければなりません。
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.
このフィールドは、IGMPv3の広告インターフェースの[9] [7]、またはMLD [8]のIGMPv2によって使用中のロバストネス変数[2]に設定されています。 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宛先アドレスは、全詮索マルチキャストアドレスに設定されています。
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のヘッダは、直前のヘッダ58の次ヘッダ値によって識別される[6]。
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。ベース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が有効になっています。ルータは、各連続メッセージ間MaxInitialAdvertisementInterval未満のランダムな遅延を待って、MaxInitialAdvertisements広告の最大まで送信することができます。複数の広告は、ネットワーク上のパケット損失に直面して堅牢性のために送信されます。
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:
広告メッセージを受信すると、デバイスは、以下の基準でメッセージを検証します：
2. The IP destination address is equal to the All-Snoopers multicast address
2. 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.
広告はNeighborDeadIntervalの時間内に特定の隣人のために受信されない場合は、隣人が到達不能と見なされます。
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:
これらが発生したときに懇願を送信することができます。
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.
Typeフィールドは、要請としてメッセージを識別する。 IPv4とIPv6のための152のために0x31に設定されています。
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メッセージの1の補数和の16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドは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のヘッダは、直前のヘッダ58の次ヘッダ値によって識別される[6]。
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.
Typeフィールドは、終端としてメッセージを識別する。 IPv4とIPv6のための153のために0x32のために設定されています。
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メッセージの1の補数和の16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドは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宛先アドレスは、全詮索マルチキャストアドレスに設定されています。
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のヘッダは、直前のヘッダ58の次ヘッダ値によって識別される[6]。
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.
メッセージは、これらの検証手順を通過した場合、勧誘が送信されます。広告がNeighborDeadInterval内に受信されない場合は、送信ルータは、アクティブなマルチキャストルータのリストから削除されます。
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
MAX_SOLICITATIONS 3トランスミッションO
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は、リンクローカルプロトコルであるように、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.
ローグのノードが偽装された広告、勧誘、または終了メッセージを送信することによって、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.
不正なノードが偽装された終了メッセージを送信することにより、マルチキャストサービスを中断しようとすることができます。 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.
マルチキャストルータ広告メッセージは、不正なマシンがマルチキャストルータになりすますことを可能にします。これは、これらのマシンは、マルチキャストデータ伝送を盗聴する可能性があります。また、それは同じスヌーピングドメイン内の他のホストへのサービス拒否攻撃を構成するか、高レートのマルチキャストフローの存在下で、同じデバイス・ポートを共有することができました。
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] SENDで利用可能な技術は、IPv6ネットワークでの偽装された広告メッセージに対処するために利用することができます。 MRD対応ネットワークにおけるIPv6マルチキャストルータは、MRDメッセージのIPv6送信元アドレスとしてSENDベースのリンクローカルアドレスを使用することができます。スイッチは最初の広告を受信すると、それは自分自身を認証するためにルータに挑戦するSENDベースのアドレスの情報を使用することができます。このアプローチは唯一の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の両方をサポートしている別の解決策は、メッセージが適切なキーを使用してシステムから来たことを確実にすることにより、攻撃を防御するために、[11]カプセル化セキュリティペイロード（ESP）モードでIPsecを使用することです。 IPsecを使用する場合は、すべての-詮索アドレスに送信されたメッセージは、ESPを使用して認証する必要があります。このようHMAC-SHA-1として、ESPヌル暗号化アルゴリズムと対称認証アルゴリズムで、所望されない暗号化する必要があり、実行可能です。キーイングのために、単一の手動で設定されているキー対称署名アルゴリズムは、広告を送信するルータのために使用されます。これは、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 Type値が必要です。 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 Type値が必要です。 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の全詮索マルチキャストアドレスの割り当てが必要です。それがリンクローカル、制御メッセージのために使用されるので、このマルチキャスト・アドレスは224.0.0 / 24の範囲です。すべての-詮索のための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値を有します。 0：0：0：0：0：0：6 IPv6マルチキャストアドレスがFF02です。
Brad Cain and Shantam Biswis are the authors of the original Multicast Router Discovery proposal.
ブラッドカインと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.
モーテン・クリステンセン、ペッカSavola、ヒュー・ホルブルック、とイジドールKouvelasは、このドキュメントのさまざまなバージョンに有用なフィードバックを提供します。
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1]デアリング、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[4]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[5]ウズラ、C.とA.ジャクソン、 "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]コンタ、A.、およびS.デアリングを、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様は、"、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見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]ヴィーダ、R.とL.コスタ、 "マルチキャストリスナ発見バージョン2（MLDv2の）IPv6のため"、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[11]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[12] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[12]ハーバーマン、B.、 "IPv6マルチキャストアドレスの割り当てに関するガイドライン"、RFC 3307、2002年8月。
[13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[13]デアリング、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ジョンズホプキンスロードローレル、MD 20723から6099米
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
電話：+1 443 778 1319 Eメール：brian@innovationslab.net
Jim Martin Netzwert AG An den Treptowers 1 D-12435 Berlin Germany
Treptowers 1 D-12435ベルリンドイツでジム・マーティンNetzwert
Phone: +49.30/5 900 80-1180 EMail: jim@netzwert.ag
電話：+ 49.30 / 5 900 80から1180 Eメール：jim@netzwert.ag
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.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 Editor機能のための基金は現在、インターネット協会によって提供されます。