Network Working Group S. Deering
Request for Comments: 2710 Cisco Systems
Category: Standards Track W. Fenner
AT&T Research
B. Haberman
IBM
October 1999
Multicast Listener Discovery (MLD) for IPv6
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.
この文書は、直接接続されているリンク上で（すなわち、マルチキャストパケットを受信することを望むノードである）マルチキャストリスナの存在を発見するために、マルチキャストアドレスがそれらの隣接ノードへの関心である具体的発見するためのIPv6ルータによって使用されるプロトコルを指定します。このプロトコルは、マルチキャストリスナ発見やMLDと呼ばれています。 MLDは、IPv4の者のインターネットグループ管理プロトコル、IGMPv2のバージョン2から導出されます。注意すべき重要な違いは、MLDはというIGMP（IPプロトコル2）メッセージタイプよりも、ICMPv6の（IPプロトコル58）メッセージタイプを使用していることです。
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 RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
The purpose of Multicast Listener Discovery (MLD) is to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This information is then provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all links where there are interested receivers.
マルチキャストリスナ発見（MLD）の目的は、直接接続されたリンク上のマルチキャストリスナー（すなわち、マルチキャストパケットを受信することを望むノード）の存在を発見するために、各IPv6ルータを可能にするために、マルチキャストアドレスに関心のあるどの具体的発見することですこれらの隣接ノード。この情報は、マルチキャストルーティングプロトコルは、マルチキャストパケットが興味受信機が存在するすべてのリンクに配信されることを保証するために、ルータによって使用されている方に設けられています。
MLD is an asymmetric protocol, specifying different behaviors for multicast listeners and for routers. For those multicast addresses to which a router itself is listening, the router performs both parts of the protocol, including responding to its own messages.
MLDは、マルチキャストリスナーのためのルータのために異なる動作を指定して、非対称プロトコルです。ルータ自身が聴取されたものマルチキャストアドレスのために、ルータは、自身のメッセージへの応答を含むプロトコルの両方の部分を実行します。
If a router has more than one interface to the same link, it need perform the router part of MLD over only one of those interfaces. Listeners, on the other hand, must perform the listener part of MLD on all interfaces from which an application or upper-layer protocol has requested reception of multicast packets.
ルータが同じリンクに複数のインタフェースを持っている場合、それはそれらの1つのインターフェイスのみの上にMLDのルータの一部を実行する必要があります。リスナーは、他方で、アプリケーションまたは上位層プロトコルは、マルチキャストパケットの受信を要求しているから、すべてのインターフェイス上でMLDのリスナーの一部を実行しなければなりません。
MLD is a sub-protocol of ICMPv6, that is, MLD message types are a subset of the set of ICMPv6 messages, and MLD messages are identified in IPv6 packets by a preceding Next Header value of 58. All MLD messages described in this document are sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR-ALERT] in a Hop-by-Hop Options header. (The Router Alert option is necessary to cause routers to examine MLD messages sent to multicast addresses in which the routers themselves have no interest.)
MLDはつまり、MLDメッセージタイプは、ICMPv6メッセージのセットのサブセットである、のICMPv6のサブプロトコルであり、MLDメッセージは、この文書で説明58すべてMLDメッセージの前の次ヘッダ値によってIPv6パケットで識別されホップバイホップオプションヘッダのリンクローカルIPv6ソースアドレス、1のIPv6のホップリミット、およびIPv6ルータ警告オプション[RTR-ALERT]で送りました。 （ルータアラートオプションは、ルータ自体は関心がないているマルチキャストアドレスに送信されたMLDメッセージを調べるために、ルータを起こすことが必要です。）
MLD messages have the following format:
MLDメッセージの形式は次のとおりです。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are three types of MLD messages:
MLDメッセージの3つのタイプがあります。
Multicast Listener Query (Type = decimal 130)
マルチキャストリスナクエリ（タイプ=小数130）
There are two subtypes of Multicast Listener Query messages:
マルチキャストリスナクエリメッセージの2つのサブタイプがあります。
- General Query, used to learn which multicast addresses have listeners on an attached link. - Multicast-Address-Specific Query, used to learn if a particular multicast address has any listeners on an attached link.
- マルチキャストアドレスが接続リンク上のリスナーを持っているかを学習するために使用される一般的なクエリ、。 - 特定のマルチキャストアドレスが接続リンク上の任意のリスナーがあるかどうかを学習するために使用されるマルチキャスト・アドレス固有のクエリー、。
These two subtypes are differentiated by the contents of the Multicast Address field, as described in section 3.6.
セクション3.6で説明したように、これらの2つのサブタイプは、マルチキャストアドレスフィールドの内容によって区別されます。
Multicast Listener Report (Type = decimal 131)
マルチキャストリスナレポート（タイプ=小数131）
Multicast Listener Done (Type = decimal 132)
マルチキャストリスナーが完了（タイプ=小数132）
In the rest of this document, the above messages types are referred to simply as "Query", "Report", and "Done".
この文書の残りの部分では、上記のメッセージタイプは、単に「クエリ」、「レポート」と呼ばれ、「完了」。
Initialized to zero by the sender; ignored by receivers.
送信者によってゼロに初期化。受信機によって無視されます。
The standard ICMPv6 checksum, covering the entire MLD message plus a "pseudo-header" of IPv6 header fields [ICMPv6,IPv6].
全体MLDメッセージプラスIPv6ヘッダフィールド[ICMPv6の、IPv6の]の「擬似ヘッダ」をカバーする標準のICMPv6チェックサム、。
The Maximum Response Delay field is meaningful only in Query messages, and specifies the maximum allowed delay before sending a responding Report, in units of milliseconds. In all other messages, it is set to zero by the sender and ignored by receivers.
最大応答遅延フィールドは、クエリメッセージに意味があり、ミリ秒単位で、応答レポートを送信する前に許容される最大遅延時間を指定します。他のすべてのメッセージでは、送信者によってゼロに設定され、受信機によって無視されます。
Varying this value allows the routers to tune the "leave latency" (the time between the moment the last node on a link ceases listening to a particular multicast address and moment the routing protocol is notified that there are no longer any listeners for that address), as discussed in section 7.8. It also allows tuning of the burstiness of MLD traffic on a link, as discussed in section 7.3.
この値を変化させること（瞬間の間の時間がリンクの最後のノードがルーティングプロトコルがそのアドレスのリスナーがもはや存在することが通知されていない特定のマルチキャストアドレスおよびモーメントを聞く停止）チューニングするルータは「待ち時間を残す」ことができ、セクション7.8で議論するように。 7.3節で述べたように、それはまた、リンク上のMLDトラフィックのバースト性のチューニングを可能にします。
Initialized to zero by the sender; ignored by receivers.
送信者によってゼロに初期化。受信機によって無視されます。
In a Query message, the Multicast Address field is set to zero when sending a General Query, and set to a specific IPv6 multicast address when sending a Multicast-Address-Specific Query.
一般クエリを送信するときにQueryメッセージでは、マルチキャストアドレスフィールドはゼロに設定され、マルチキャスト・アドレスの固有のクエリーを送信するときに特定のIPv6マルチキャストアドレスに設定してください。
In a Report or Done message, the Multicast Address field holds a specific IPv6 multicast address to which the message sender is listening or is ceasing to listen, respectively.
レポートまたはDoneメッセージでは、マルチキャストアドレスフィールドは、メッセージの送信者が聞いているか、それぞれ、聞くために中止された固有のIPv6マルチキャストアドレスを保持しています。
The length of a received MLD message is computed by taking the IPv6 Payload Length value and subtracting the length of any IPv6 extension headers present between the IPv6 header and the MLD message. If that length is greater than 24 octets, that indicates that there are other fields present beyond the fields described above, perhaps belonging to a future backwards-compatible version of MLD. An implementation of the version of MLD specified in this document MUST NOT send an MLD message longer than 24 octets and MUST ignore anything past the first 24 octets of a received MLD message. In all cases, the MLD checksum MUST be computed over the entire MLD message, not just the first 24 octets.
受信したMLDメッセージの長さは、IPv6ペイロード長の値をとるとIPv6ヘッダとMLDメッセージの間に存在する任意のIPv6拡張ヘッダの長さを減算することにより計算されます。その長さが24オクテットよりも大きい場合、それはおそらく将来MLDの下位互換性のあるバージョンに属する、上記のフィールドを超えて存在する他のフィールドがあることを示しています。 MLDのバージョンの実装が長い24オクテットよりMLDメッセージを送ってはいけませんし、受信したMLDメッセージの最初の24オクテット過去何を無視しなければなりません。この文書で指定されました。全ての場合において、MLDチェックサムは全体MLDメッセージだけでなく、最初の24オクテットにわたって計算されなければなりません。
Note that defaults for timer values are described later in this document. Timer and counter names appear in square brackets.
タイマー値のデフォルトは、このドキュメントの後半で説明されていることに注意してください。タイマとカウンタ名は、角括弧内に表示されます。
Routers use MLD to learn which multicast addresses have listeners on each of their attached links. Each router keeps a list, for each attached link, of which multicast addresses have listeners on that link, and a timer associated with each of those addresses. Note that the router needs to learn only that listeners for a given multicast address are present on a link; it does NOT need to learn the identity (e.g., unicast address) of those listeners or even how many listeners are present.
ルータは、マルチキャストアドレスは、その接続されたリンクの各上のリスナーを持っているかを学習するためにMLDを使用しています。各ルータは、マルチキャストアドレスは、そのリンク上のリスナーを持っているの各接続リンク、およびこれらのアドレスのそれぞれに関連するタイマに、リストを保持します。ルータが特定のマルチキャストアドレスのリスナーがリンク上に存在していることだけを学習する必要があることに注意してください。それは、これらのリスナーのアイデンティティ（例えば、ユニキャストアドレス）、あるいはどのように多くのリスナーが存在しているが学習する必要はありません。
For each attached link, a router selects one of its link-local unicast addresses on that link to be used as the IPv6 Source Address in all MLD packets it transmits on that link.
各添付のリンクのために、ルータはそのリンク上で送信するすべてのMLDパケット内のIPv6送信元アドレスとして使用される、そのリンク上のリンクローカルユニキャストアドレスのいずれかを選択します。
For each interface over which the router is operating the MLD protocol, the router must configure that interface to listen to all link-layer multicast address that can be generated by IPv6 multicasts. For example, an Ethernet-attached router must set its Ethernet address reception filter to accept all Ethernet multicast addresses that start with the hexadecimal value 3333 [IPv6-ETHER]; in the case of an Ethernet interface that does not support the filtering of such a range of multicast address, it must be configured to accept ALL Ethernet multicast addresses, in order to meet the requirements of MLD.
ルータがMLDプロトコルを動作している上で各インタフェースについて、ルーターは、IPv6マルチキャストによって生成することができ、すべてのリンク層マルチキャストアドレスを聞くためにそのインターフェイスを設定する必要があります。例えば、イーサネット接続ルータは、16進値3333 [たIPv6-ETHER]で始まるすべてのイーサネットマルチキャストアドレスを受け入れるために、そのイーサネット・アドレス受信フィルタを設定する必要があります。マルチキャストアドレスのような範囲のフィルタリングをサポートしていないイーサネットインタフェースの場合には、MLDの要件を満たすために、すべてのイーサネットマルチキャストアドレスを受け入れるように構成されなければなりません。
With respect to each of its attached links, a router may assume one of two roles: Querier or Non-Querier. There is normally only one Querier per link. All routers start up as a Querier on each of their attached links. If a router hears a Query message whose IPv6 Source Address is numerically less than its own selected address for that link, it MUST become a Non-Querier on that link. If [Other Querier Present Interval] passes without receiving, from a particular attached link, any Queries from a router with an address less than its own, a router resumes the role of Querier on that link.
クエリアまたは非クエリア：その接続リンクの各々に関して、ルータは、二つの役割のいずれかをとることができます。リンクごとに1つのだけ質問者が通常あります。すべてのルータは、その接続されたリンクの各上のクエリアとして起動します。ルータはそのIPv6の送信元アドレスQueryメッセージを聞く場合は、そのリンクのための独自の選択したアドレスよりも数値的に小さいですが、それはそのリンク上で非クエリアになる必要があります。 [その他の問現在のインターバルは、特に添付のリンクから受信せずに合格した場合、以下独自よりアドレスを持つルータからの任意のクエリは、ルータはそのリンク上のクエリアの役割を再開する。
A Querier for a link periodically [Query Interval] sends a General Query on that link, to solicit reports of all multicast addresses of interest on that link. On startup, a router SHOULD send [Startup Query Count] General Queries spaced closely together [Startup Query Interval] on all attached links in order to quickly and reliably discover the presence of multicast listeners on those links.
定期的にリンクのクエリア[クエリー間隔]はそのリンク上の関心のあるすべてのマルチキャストアドレスのレポートを勧誘するために、そのリンク上で一般クエリを送信します。起動時に、ルータが送るべき一般的なクエリは、これらのリンク上のマルチキャストリスナーの存在を発見し、迅速かつ確実にするために取り付けられているすべてのリンク上で一緒に[スタートアップクエリー間隔]密集した[スタートアップのクエリ数]。
General Queries are sent to the link-scope all-nodes multicast address (FF02::1), with a Multicast Address field of 0, and a Maximum Response Delay of [Query Response Interval].
一般的なクエリが0のマルチキャストアドレスフィールドに、マルチキャストアドレス（FF02 :: 1）リンクスコープに全ノードに送信され、[クエリ応答間隔]の最大応答遅延されています。
When a node receives a General Query, it sets a delay timer for each multicast address to which it is listening on the interface from which it received the Query, EXCLUDING the link-scope all-nodes address and any multicast addresses of scope 0 (reserved) or 1 (node-local). Each timer is set to a different random value, using the highest clock granularity available on the node, selected from the range [0, Maximum Response Delay] with Maximum Response Delay as specified in the Query packet. If a timer for any address is already running, it is reset to the new random value only if the requested Maximum Response Delay is less than the remaining value of the running timer. If the Query packet specifies a Maximum Response Delay of zero, each timer is effectively set to zero, and the action specified below for timer expiration is performed immediately.
ノードは一般クエリーを受信すると、全ノードのアドレスと範囲0のいずれかのマルチキャストアドレスは、（予約リンクスコープを除いて、それがクエリを受信するインターフェイスをリッスンしている各マルチキャストアドレスのための遅延タイマをセット）又は1（ノードローカル）。各タイマーは、クエリパケットで指定された最大応答遅延と範囲[0、最大応答遅延]から選択されたノード上で利用可能な最高クロックの粒度を使用して、異なるランダムな値に設定されています。任意のアドレスのためのタイマーがすでに実行されている場合、要求された最大応答遅延が実行されているタイマーの残り値未満である場合にのみ、新しいランダムな値にリセットされます。クエリパケットがゼロの最大応答遅延を指定した場合、各タイマは実質的にゼロに設定され、タイマ満了のために、以下の指定されたアクションがすぐに実行されます。
When a node receives a Multicast-Address-Specific Query, if it is listening to the queried Multicast Address on the interface from which the Query was received, it sets a delay timer for that address to a random value selected from the range [0, Maximum Response Delay], as above. If a timer for the address is already running, it is reset to the new random value only if the requested Maximum Response Delay is less than the remaining value of the running timer. If the Query packet specifies a Maximum Response Delay of zero, the timer is effectively set to zero, and the action specified below for timer expiration is performed immediately.
ノードは、マルチキャストアドレス固有のクエリーを受信すると、クエリが受信されたインターフェイス上で照会マルチキャストアドレスにリッスンしている場合には、範囲[0から選択されたランダムな値にそのアドレスの遅延タイマーを設定します最大応答遅延]、上記のように。アドレスのためのタイマーがすでに実行されている場合、要求された最大応答遅延が実行されているタイマーの残り値未満である場合にのみ、新しいランダムな値にリセットされます。クエリパケットがゼロの最大応答遅延を指定した場合、タイマーは実質的にゼロに設定され、タイマ満了のために、以下の指定されたアクションがすぐに実行されます。
If a node's timer for a particular multicast address on a particular interface expires, the node transmits a Report to that address via that interface; the address being reported is carried in both the IPv6 Destination Address field and the MLD Multicast Address field of the Report packet. The IPv6 Hop Limit of 1 (as well as the presence of a link-local IPv6 Source Address) prevent the packet from traveling beyond the link to which the reporting interface is attached.
特定のインターフェイス上の特定のマルチキャストアドレスのためのノードのタイマーが期限切れになった場合、ノードはそのインタフェースを介して、そのアドレスにレポートを送信します。アドレスは、IPv6宛先アドレスフィールドとレポートパケットのMLDマルチキャストアドレスフィールドの両方で運ばれていると報告されています。 1のIPv6のホップ限界（同様に、リンクローカルIPv6ソースアドレスの存在は）レポートインターフェイスが取り付けられたリンクを超えて走行からパケットを防ぎます。
If a node receives another node's Report from an interface for a multicast address while it has a timer running for that same address on that interface, it stops its timer and does not send a Report for that address, thus suppressing duplicate reports on the link.
ノードが受信した場合、それはそのインターフェイス上の同じアドレスに対して実行されているタイマーを有しているマルチキャストアドレスのためのインタフェースから別のノードの報告書は、それはそのタイマーを停止し、したがって、リンク上で重複した報告を抑制し、そのアドレスに対してレポートを送信しません。
When a router receives a Report from a link, if the reported address is not already present in the router's list of multicast address having listeners on that link, the reported address is added to the list, its timer is set to [Multicast Listener Interval], and its appearance is made known to the router's multicast routing component. If a Report is received for a multicast address that is already present in the router's list, the timer for that address is reset to [Multicast Listener Interval]. If an address's timer expires, it is assumed that there are no longer any listeners for that address present on the link, so it is deleted from the list and its disappearance is made known to the multicast routing component.
ルータがリンクから報告書を受け取ると報告したアドレスが既にそのリンク上のリスナーを持つマルチキャストアドレスのルータのリストに存在しない場合には、報告されたアドレスがリストに追加され、そのタイマは、[マルチキャストリスナ間隔]に設定されています、そしてその外観は、ルータのマルチキャストルーティングコンポーネントに知らされています。報告書はすでにルータのリストに存在するマルチキャストアドレスのために受信された場合、そのアドレスのタイマーは、[マルチキャストリスナ間隔]にリセットされます。アドレスのタイマーが期限切れになった場合、もはや、リンク上のアドレス存在にリスナーがあることを想定されていないので、それがリストから削除され、その消失は、マルチキャストルーティングコンポーネントに知らされています。
When a node starts listening to a multicast address on an interface, it should immediately transmit an unsolicited Report for that address on that interface, in case it is the first listener on the link. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to accomplish this is to send the initial Report and then act as if a Multicast-Address-Specific Query was received for that address, and set a timer appropriately).
ノードは、インターフェイス上でマルチキャストアドレスを聞いて起動すると、それがリンク上の最初のリスナーがある場合には、それはすぐに、そのインターフェイス上のアドレスのために迷惑レポートを送信する必要があります。紛失または破損している初期の報告書の可能性をカバーするために、短い遅延[迷惑レポート間隔]の後に一度か二度繰り返されることをお勧めします。 （これを達成する簡単な方法は、最初のレポートを送信して、マルチキャスト・アドレス固有のクエリーは、そのアドレスのために受信されたかのように行動し、適切にタイマーを設定することです）。
When a node ceases to listen to a multicast address on an interface, it SHOULD send a single Done message to the link-scope all-routers multicast address (FF02::2), carrying in its Multicast Address field the address to which it is ceasing to listen. If the node's most recent Report message was suppressed by hearing another Report message, it MAY send nothing, as it is highly likely that there is another listener for that address still present on the same link. If this optimization is implemented, it MUST be able to be turned off but SHOULD default to on.
ノードがインタフェース上のマルチキャストアドレスをリッスンしなくなったとき、そのマルチキャストアドレスフィールドにそれがするアドレスを運ぶリンクスコープ全ルーターマルチキャストアドレス（FF02 :: 2）に単一完了メッセージを送信するべきです聞くことを止めます。ノードの最新のレポートメッセージが別のレポートメッセージを聞くことにより、抑制された場合は、同じリンク上にまだ存在し、そのアドレスのための別のリスナーがある可能性が高いとして、それは、何も送信しないかもしれません。この最適化が実装されている場合、オフにすることができなければならないが、上にデフォルトで設定される必要があり。
When a router in Querier state receives a Done message from a link, if the Multicast Address identified in the message is present in the Querier's list of addresses having listeners on that link, the Querier sends [Last Listener Query Count] Multicast-Address-Specific Queries, one every [Last Listener Query Interval] to that multicast address. These Multicast-Address-Specific Queries have their Maximum Response Delay set to [Last Listener Query Interval]. If no Reports for the address are received from the link after the response delay of the last query has passed, the routers on the link assume that the address no longer has any listeners there; the address is therefore deleted from the list and its disappearance is made known to the multicast routing component. This process is continued to its resolution (i.e. until a Report is received or the last Multicast-Address-Specific Query is sent with no response) despite any transition from Querier to Non-Querier on this link.
クエリア状態のルータがリンクからDoneメッセージを受信すると、メッセージに示されたマルチキャストアドレスは、そのリンク上のリスナーを持つアドレスのクエリアのリストに存在する場合、クエリアは、送信[最終リスナークエリーカウント]マルチキャストアドレス固有クエリ、そのマルチキャストアドレスへの1つのすべての[最終リスナークエリー間隔]。これらのマルチキャストアドレス固有のクエリは、彼らの最大応答遅延が[最終リスナークエリー間隔]に設定されています。最後のクエリの応答遅れが経過した後にアドレスのためのレポートはリンクから受信されない場合は、リンク上のルータは、アドレスが、もはやそこにされたリスナーがあることを前提としていません。アドレスは、したがって、リストから削除され、その消失は、マルチキャストルーティングコンポーネントに知らされます。このプロセスは、その解像度に継続される（すなわち、レポートが受信されるか、または最後のマルチキャストアドレス固有のクエリーが無応答で送信されるまで）、このリンク上の非クエリアにクエリアからの任意の変化にもかかわらず。
Routers in Non-Querier state MUST ignore Done messages.
非クエリア状態のルータは、実行されたメッセージを無視しなければなりません。
When a router in Non-Querier state receives a Multicast-Address-Specific Query, if its timer value for the identified multicast address is greater than [Last Listener Query Count] times the Maximum Response Delay specified in the message, it sets the address's timer to that latter value.
非クエリア状態のルータがマルチキャストアドレス固有のクエリーを受信すると、特定されたマルチキャストアドレスのためのタイマ値がより大きい場合、最大応答遅延がメッセージに指定された回数を[最終リスナークエリーカウント]、それはアドレスのタイマーをセットします後者の値。
Node behavior is more formally specified by the state transition diagram below. A node may be in one of three possible states with respect to any single IPv6 multicast address on any single interface:
ノードの動作は、より正式に以下の状態遷移図によって指定されます。ノードは、任意の単一のインターフェース上の任意の単一のIPv6マルチキャストアドレスに対して、3つの状態のいずれかであってもよいです。
- "Non-Listener" state, when the node is not listening to the address on the interface (i.e., no upper-layer protocol or application has requested reception of packets to that multicast address). This is the initial state for all multicast addresses on all interfaces; it requires no storage in the node.
- 「非リスナー」ノードがインタフェース上のアドレスを聞いていない状態（すなわち、どの上位層プロトコルまたはアプリケーションがそのマルチキャストアドレスへのパケットの受信を要求していません）。これは、すべてのインターフェイス上のすべてのマルチキャストアドレスのための初期状態です。それは、ノード内に記憶域は必要ありません。
- "Delaying Listener" state, when the node is listening to the address on the interface and has a report delay timer running for that address.
- ノードは、インターフェイス上のアドレスに耳を傾け、そのアドレスに対して実行されているレポート遅延タイマを持っているとき、状態「リスナーを遅延させます」。
- "Idle Listener" state, when the node is listening to the address on the interface and does not have a report delay timer running for that address.
- 「アイドルリスナー」状態、ノードは、インターフェイス上のアドレスを聞いていると、そのアドレスのために実行されているレポート遅延タイマを持っていないとき。
There are five significant events that can cause MLD state transitions:
MLDの状態遷移を引き起こす可能性があります5つの重要なイベントがあります。
- "start listening" occurs when the node starts listening to the address on the interface. It may occur only in the Non-Listener state.
- ノードがインターフェイス上のアドレスを聞いて開始したときに発生する「リスニングを開始」。それは唯一の非リスナーの状態で発生することがあります。
- "stop listening" occurs when the node stops listening to the address on the interface. It may occur only in the Delaying Listener and Idle Listener states.
- ノードがインターフェイス上のアドレスを聞いて停止したときに発生する「リスニング停止」。それは遅らせるリスナーとアイドルリスナーの状態でのみ発生する可能性があります。
- "query received" occurs when the node receives either a valid General Query message, or a valid Multicast-Address-Specific Query message. To be valid, the Query message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. The Multicast Address field in the MLD message must contain either zero (a General Query) or a valid multicast address (a Multicast- Address-Specific Query). A General Query applies to all multicast addresses on the interface from which the Query is received. A Multicast-Address-Specific Query applies to a single multicast address on the interface from which the Query is received. Queries are ignored for addresses in the Non-Listener state.
- ノードが有効な一般クエリメッセージ、または有効なマルチキャストアドレス固有のクエリメッセージのいずれかを受信したときに発生する「クエリが受信されました」。有効であるために、クエリメッセージは、リンクローカルIPv6ソースアドレスから来なければならない、少なくとも24オクテットの長さで、かつ正しいMLDチェックサムを持っています。 MLDメッセージ内のマルチキャストアドレスフィールドはゼロ（一般クエリ）または有効なマルチキャストアドレス（マルチキャストのアドレス固有のクエリー）のいずれかを含める必要があります。一般クエリは、クエリが受信されたインターフェイス上のすべてのマルチキャストアドレスに適用されます。マルチキャストアドレス固有のクエリは、クエリが受信されたインターフェイス上の単一のマルチキャストアドレスに適用されます。クエリは非リスナーの状態でのアドレスでは無視されます。
- "report received" occurs when the node receives a valid MLD Report message. To be valid, the Report message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. A Report applies only to the address identified in the Multicast Address field of the Report, on the interface from which the Report is received. It is ignored in the Non-Listener or Idle Listener state.
- ノードが有効なMLD Reportメッセージを受信したときに、「報告書は受け取った」が発生します。有効であるために、レポートメッセージは、リンクローカルIPv6ソースアドレスから来なければならない、少なくとも24オクテットの長さで、かつ正しいMLDチェックサムを持っています。報告書は、報告書が受信されたインターフェイス上で、唯一の報告書のマルチキャストアドレスフィールドで識別されるアドレスに適用されます。これは、非リスナーまたはアイドルリスナー状態では無視されます。
- "timer expired" occurs when the report delay timer for the address on the interface expires. It may occur only in the Delaying Listener state.
- インターフェイス上のアドレスのための報告書の遅延タイマーが満了したときに発生する「タイマーが期限切れ」。それだけ遅らせるリスナー状態で発生することがあります。
All other events, such as receiving invalid MLD messages or MLD message types other than Query or Report, are ignored in all states.
無効なMLDメッセージまたはクエリまたはレポート以外のMLDメッセージタイプを受けるなど他のすべてのイベントは、すべての州では無視されます。
There are seven possible actions that may be taken in response to the above events:
上記のイベントに応じてとることができる7つの可能なアクションがあります。
- "send report" for the address on the interface. The Report message is sent to the address being reported.
- インターフェイス上のアドレスは、「レポートを送信します」。レポートメッセージが報告されているアドレスに送信されます。
- "send done" for the address on the interface. If the flag saying we were the last node to report is cleared, this action MAY be skipped. The Done message is sent to the link-scope all-routers address (FF02::2).
- インターフェイス上のアドレスは、「行ってSEND」。我々は報告する最後のノードたと言ってフラグがクリアされている場合、このアクションはスキップしてもよいです。完了メッセージは、リンクスコープ全ルーターアドレス（FF02 :: 2）に送られます。
- "set flag" that we were the last node to send a report for this address.
- 私たちは、このアドレスにレポートを送信するために最後のノードたこと「フラグを設定します」。
- "clear flag" since we were not the last node to send a report for this address.
- 私たちは、このアドレスにレポートを送信するための最後のノードではなかったので、「クリアフラグ」。
- "start timer" for the address on the interface, using a delay value chosen uniformly from the interval [0, Maximum Response Delay], where Maximum Response Delay is specified in the Query. If this is an unsolicited Report, the timer is set to a delay value chosen uniformly from the interval [0, [Unsolicited Report Interval] ].
- 最大応答遅延がクエリで指定された間隔[0、最大応答遅延]から均一に選択された遅延値を使用して、インターフェイス上のアドレスは、「タイマーをスタート」。これは、迷惑なレポートである場合、タイマは区間[0、[迷惑報告間隔]から一様に選択された遅延値に設定されています。
- "reset timer" for the address on the interface to a new value, using a delay value chosen uniformly from the interval [0, Maximum Response Delay], as described in "start timer".
- 「開始タイマ」に記載されているように、区間[0、最大応答遅延]から一様に選択された遅延値を使用して、新しい値へのインタフェース上のアドレスは、「タイマーをリセット」。
- "stop timer" for the address on the interface.
- インターフェイス上のアドレスは、「タイマーを停止」。
In all of the following state transition diagrams, each state transition arc is labeled with the event that causes the transition, and, in parentheses, any actions taken during the transition. Note that the transition is always triggered by the event; even if the action is conditional, the transition still occurs.
以下の状態遷移図の全てにおいて、各状態遷移アークは括弧内に、いずれかのアクションは、遷移中に撮影、遷移を引き起こし、そしてイベントで標識されています。遷移は常にイベントによってトリガーされることに注意してください。アクションが条件付きであっても、移行が引き続き発生します。
________________
| |
| |
| |
| |
--------->| Non-Listener |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| stop listening | start listening | stop listening
| (stop timer, |(send report, | (send done if
| send done if | set flag, | flag set)
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying | (start timer) | Idle |
---->| Listener |------------------->| Listener |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| query received | timer expired
| (reset timer if | (send report,
| Max Resp Delay | set flag)
| < current timer) |
-------------------
The link-scope all-nodes address (FF02::1) is handled as a special case. The node starts in Idle Listener state for that address on every interface, never transitions to another state, and never sends a Report or Done for that address.
リンクスコープ全ノードアドレス（FF02 :: 1）特殊なケースとして扱われます。ノードは、すべてのインターフェイス上のアドレスのためのアイドルリスナー状態で起動し、別の状態に移行しないと、決してレポートを送信するか、そのアドレスのために行いません。
MLD messages are never sent for multicast addresses whose scope is 0 (reserved) or 1 (node-local).
MLDメッセージは、その範囲0（予約）または1（ノードローカル）マルチキャストアドレスに送信されることはありません。
MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR-ARCH], except for the link-scope, all-nodes address (FF02::1).
MLDメッセージは、リンクスコープを除いて、要請ノードマルチキャストアドレス[ADDR-ARCH]を含むそのスコープ2でマルチキャストアドレス（リンクローカル）のために送信され、全ノードアドレス（FF02 :: 1）。
Router behavior is more formally specified by the state transition diagrams below.
ルータの動作は、より正式に以下の状態遷移図で指定されています。
A router may be in one of two possible states with respect to any single attached link:
ルータは、任意の単一の添付のリンクに対して2つの可能な状態のいずれかであってもよいです。
- "Querier", when this router is designated to transmit MLD Queries on this link.
- このルータは、このリンクをMLDクエリーを送信するために指定されている「クエリア」、。
- "Non-Querier", when there is another router designated to transmit MLD Queries on this link.
- 「非クエリア」、このリンク上でMLDクエリーを送信するために指定された別のルータがあります。
The following three events can cause the router to change states:
以下の3つのイベントでは、ルータが状態を変化させることができます。
- "query timer expired" occurs when the timer set for query transmission expires. This event is significant only when in the Querier state.
- クエリ送信のためのタイマーセットが満了したときに、「クエリータイマーの期限が切れ」が発生します。このイベントは、ときにのみクエリア状態に重要です。
- "query received from a router with a lower IP address" occurs when a valid MLD Query is received from a router on the same link with a lower IPv6 Source Address. To be valid, the Query message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum.
- 有効なMLDクエリーは、下のIPv6ソースアドレスと同じリンク上のルータから受信したとき、「クエリは下位IPアドレスを持つルータから受信した」が発生します。有効であるために、クエリメッセージは、リンクローカルIPv6ソースアドレスから来なければならない、少なくとも24オクテットの長さで、かつ正しいMLDチェックサムを持っています。
- "other querier present timer expired" occurs when the timer set to note the presence of another querier with a lower IP address on the link expires. This event is significant only when in the Non-Querier state.
- タイマーが満了したリンク上の下位IPアドレスを持つ別のクエリアの存在を注意するように設定するときに発生「他のクエリア存在タイマーが期限切れ」。このイベントは、ときにのみ非クエリア状態で重要です。
There are three actions that may be taken in response to the above events:
上記のイベントに応じて取ることができる3つのアクションがあります。
- "start general query timer" for the attached link to [Query Interval].
- [クエリー間隔]への接続リンクのための「一般的なクエリータイマーを起動します」。
- "start other querier present timer" for the attached link to [Other Querier Present Interval].
- [その他の問合者存在間隔]への添付のリンクは、「他のクエリア存在タイマーを開始」。
- "send general query" on the attached link. The General Query is sent to the link-scope all-nodes address (FF02::1), and has a Maximum Response Delay of [Query Response Interval].
- 付属のリンクの「一般クエリーを送信」。一般的なクエリは、リンクスコープの全ノードアドレス（FF02 :: 1）に送られ、[クエリ応答間隔]の最大応答遅延を持っています。
--------------------------------
_______|________ gen. query timer |
--------- | | expired |
| Initial |---------------->| | (send general query, |
--------- (send gen. q., | | start gen. q. timer) |
start initial gen. q. | |<----------------------
timer) | Querier |
| |
-----| |<---
| | | |
| |________________| |
query received from a | | other querier
router with a lower | | present timer
IP address | | expired
(start other querier | ________________ | (send gen. query,
present timer) | | | | start gen. q. timer)
| | | |
| | | |
---->| Non |----
| Querier |
| |
| |
---->| |----
| |________________| |
| query received from a |
| router with a lower IP |
| address |
| (start other querier |
| present timer) |
---------------------------
A router starts in the Initial state on all attached links, and immediately transitions to Querier state.
ルータは、接続されたすべてのリンクで、初期状態で開始し、すぐに状態をクエリアに移行します。
In addition, to keep track of which multicast addresses have listeners, a router may be in one of three possible states with respect to any single IPv6 multicast address on any single attached link:
また、マルチキャストアドレスがリスナーを持っているのを追跡するために、ルータは、任意の単一の添付のリンク上の任意の単一のIPv6マルチキャストアドレスに対して、3つの状態のいずれかであってもよいです。
- "No Listeners Present" state, when there are no nodes on the link that have sent a Report for this multicast address. This is the initial state for all multicast addresses on the router; it requires no storage in the router.
- 「いいえリスナープレゼント」状態、このマルチキャストアドレスにレポートを送信したリンク上のノードがないとき。これは、ルータ上のすべてのマルチキャストアドレスのための初期状態です。それは、ルータ内に記憶域は必要ありません。
- "Listeners Present" state, when there is a node on the link that has sent a Report for this multicast address.
- 「現在のリスナー」状態、このマルチキャストアドレスにレポートを送信したリンク上のノードがあります。
- "Checking Listeners" state, when the router has received a Done message but has not yet heard a Report for the identified address.
- ルータが完了メッセージを受信しましたが、まだ特定されたアドレスのレポートを聞いていない状態を、「リスナーの確認」。
There are five significant events that can cause router state transitions:
ルータの状態遷移を引き起こす可能性があります5つの重要なイベントがあります。
- "report received" occurs when the router receives a Report for the address from the link. To be valid, the Report message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum.
- ルータがリンクからアドレスの報告書を受け取ったときに、「報告書は受け取った」が発生します。有効であるために、レポートメッセージは、リンクローカルIPv6ソースアドレスから来なければならない、少なくとも24オクテットの長さで、かつ正しいMLDチェックサムを持っています。
- "done received" occurs when the router receives a Done message for the address from the link. To be valid, the Done message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. This event is significant only in the "Listerners Present" state and when the router is a Querier.
- ルータがリンクからアドレスのDoneメッセージを受信したときに、「受信完了」が発生します。有効であるために、Doneメッセージは、リンクローカルIPv6ソースアドレスから来なければならない、少なくとも24オクテットの長さで、かつ正しいMLDチェックサムを持っています。このイベントは、唯一の「Listernersプレゼント」状態にしてたときに、ルータがクエリアで重要です。
- "multicast-address-specific query received" occurs when a router receives a Multicast-Address-Specific Query for the address from the link. To be valid, the Query message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. This event is significant only in the "Listeners Present" state and when the router is a Non-Querier.
- ルータがリンクからアドレスをマルチキャストアドレス固有のクエリーを受信したときに発生する「マルチキャストアドレス固有のクエリーが受信されました」。有効であるために、クエリメッセージは、リンクローカルIPv6ソースアドレスから来なければならない、少なくとも24オクテットの長さで、かつ正しいMLDチェックサムを持っています。このイベントは、「現在のリスナー」状態とする場合、ルータが非質問者であるに重要です。
- "timer expired" occurs when the timer set for a multicast address expires. This event is significant only in the "Listeners Present" or "Checking Listeners" state.
- マルチキャストアドレスのためのタイマーセットが期限切れになったとき、「タイマーの期限が切れ」が発生します。このイベントは、「現在のリスナー」または「リスナーのチェック」状態に重要です。
- "retransmit timer expired" occurs when the timer set to retransmit a Multicast-Address-Specific Query expires. This event is significant only in the "Checking Listeners" state.
- タイマーがマルチキャストアドレス固有のクエリーの有効期限が切れた再送信するように設定したときに発生する「再送信タイマーが期限切れ」。このイベントは、「チェックリスナー」状態に重要です。
There are seven possible actions that may be taken in response to the above events:
上記のイベントに応じてとることができる7つの可能なアクションがあります。
- "start timer" for the address on the link - also resets the timer to its initial value [Multicast Listener Interval] if the timer is currently running.
- リンク上のアドレスは、「タイマーをスタート」 - タイマーが現在実行されている場合も、その初期値[マルチキャストリスナ間隔]にタイマーをリセットします。
- "start timer*" for the address on the link - this alternate action sets the timer to the minimum of its current value and either [Last Listener Query Interval] * [Last Listener Query Count] if this router is a Querier, or the Maximum Response Delay in the Query message * [Last Listener Query Count] if this router is a non-Querier.
- リンク上のアドレスは、「タイマー*を開始する」 - この代替措置は、その電流値とのいずれか[最終リスナークエリー間隔] * [最終リスナークエリーカウント]このルータがクエリア場合、または最小にタイマーをセットしますQueryメッセージにおける最大応答遅延* [最終リスナークエリーカウント]このルータは、非クエリアである場合。
- "start retransmit timer" for the address on the link [Last Listener Query Interval].
- リンク[最終リスナークエリー間隔]上のアドレスは、「再送信タイマーをスタート」。
- "clear retransmit timer" for the address on the link.
- リンク上のアドレスのための「明確な再送信タイマー」。
- "send multicast-address-specific query" for the address on the link. The Multicast-Address-Specific Query is sent to the address being queried, and has a Maximum Response Delay of [Last Listener Query Interval].
- リンク上のアドレスは、「マルチキャストアドレス固有のクエリーを送信します」。マルチキャストアドレス固有のクエリーは、照会されているアドレスに送信され、[最終リスナークエリー間隔]の最大応答遅延を持っています。
- "notify routing +" internally notify the multicast routing protocol that there are listeners to this address on this link.
- 「ルーティング通知+」内部でこのリンク上でこのアドレスにリスナーがあることをマルチキャストルーティングプロトコルに通知します。
- "notify routing -" internally notify the multicast routing protocol that there are no longer any listeners to this address on this link.
- 「ルーティング通知 - 」内部的にはもはやこのリンク上でこのアドレスにリスナーが存在しないことをマルチキャストルーティングプロトコルに通知します。
The following state diagrams apply per group per link. There are two diagrams; one for routers in Querier state and one for routers in Non-Querier state. The transition between Querier and Non-Querier state on a link is handled specially. All groups on that link in "No Listeners Present" or "Listeners Present" states switch state transition diagrams when the Querier/Non-Querier state transition occurs. However, any groups in "Checking Listeners" state continue with the same state transition diagram until the "Checking Listeners" state is exited. E.g. a router that starts as a Querier, receives a Done message for a group and then receives a Query from a router with a lower address (causing a transition to the Non-Querier state) continues to send multicast-address-specific queries for the group in question until it either receives a Report or its timer expires, at which time it starts performing the actions of a Non-Querier for this group.
以下の状態図は、リンクごとにグループごとに適用されます。 2つの図があります。クエリア状態でルータ用と非クエリア状態のルータのための1つ。リンク上のクエリアおよび非クエリア状態間の遷移は、特別に処理されます。クエリア/非クエリア状態遷移が発生したときに「いいえリスナープレゼント」または「リスナープレゼント」の状態でそのリンク上のすべてのグループは、状態遷移図を切り替えます。 「チェックリスナー」状態が終了するまでは、「チェックリスナー」状態のいずれかのグループは、同じ状態遷移図を続行します。例えば。クエリアとして起動ルータは、グループのために完了メッセージを受信し、グループのマルチキャストアドレス固有クエリーを送信し続けている（非クエリア状態に遷移させる）下位アドレスでルータからクエリーを受信します質問には報告書を受け、いずれか、またはそのタイマーはその時点では、このグループのために非クエリアのアクションを実行開始し、有効期限が切れるまで。
The state transition diagram for a router in Querier state follows:
問合状態でルータの状態遷移図は、以下：
________________
| |
| |timer expired
timer expired| |(notify routing -,
(notify routing -)| No Listeners |clear rxmt tmr)
------->| Present |<---------
| | | |
| | | |
| |________________| | ---------------
| | | | rexmt timer |
| report received| | | expired |
| (notify routing +,| | | (send m-a-s |
| start timer)| | | query, |
__________|______ | ________|_|______ st rxmt |
| |<------------ | | tmr) |
| | | |<-------
| | report received | |
| | (start timer, | |
| | clear rxmt tmr) | |
| Listeners |<-------------------| Checking |
| Present | done received | Listeners |
| | (start timer*, | |
| | start rxmt timer, | |
| | send m-a-s query) | |
--->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
The state transition diagram for a router in Non-Querier state is similar, but non-Queriers do not send any messages and are only driven by message reception.
非クエリア状態でルータの状態遷移図は似ていますが、非クエリアは、すべてのメッセージを送信しないとだけメッセージ受信によって駆動されます。
________________
| |
| |
timer expired| |timer expired
(notify routing -)| No Listeners |(notify routing -)
--------->| Present |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| |report received |
| |(notify routing +,|
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | report received | |
| | (start timer) | |
| Listeners |<-------------------| Checking |
| Present | m-a-s query rec'd | Listeners |
| | (start timer*) | |
---->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all routers on a single link. Note that parentheses are used to group expressions to make the algebra clear.
これらのタイマーの大半は設定可能です。デフォルト以外の設定が使用されている場合、それらは単一のリンク上のすべてのルータ間で一致している必要があります。グループ式に使用されている括弧は代数を明確にすることに注意してください。
The Robustness Variable allows tuning for the expected packet loss on a link. If a link is expected to be lossy, the Robustness Variable may be increased. MLD is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2
ロバストネス変数は、リンク上で予想されるパケット損失のためにチューニングすることができます。リンクは非可逆であることが予想されている場合は、ロバストネス変数を増加させることができます。パケットロス - MLDは、（1ロバストネス変数）に対して堅牢です。ロバストネス変数はゼロであるはずがありませんし、1すべきではありません。デフォルト：2
The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds.
クエリー間隔は、クエリアによって送られた一般クエリーの間隔です。デフォルト：125秒。
By varying the [Query Interval], an administrator may tune the number of MLD messages on the link; larger values cause MLD Queries to be sent less often.
[クエリー間隔]、管理者よい曲リンク上のMLDメッセージの数を変えることにより、より大きな値は、MLDクエリーはあまり頻繁に送信されることはあり。
The Maximum Response Delay inserted into the periodic General Queries. Default: 10000 (10 seconds)
最大応答遅延は、定期的な一般的なクエリーに挿入します。デフォルト：10000（10秒）
By varying the [Query Response Interval], an administrator may tune the burstiness of MLD messages on the link; larger values make the traffic less bursty, as node responses are spread out over a larger interval. The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].
[クエリ応答間隔]を変化させることにより、管理者が調整するリンク上のMLDメッセージのバーストをしてもよいです。ノードの応答が大きくなる区間にわたって広がっているとして、より大きな値は、トラフィックが少ないバースト性にします。 [クエリ応答間隔]で表される秒数は、[クエリー間隔]未満でなければなりません。
The Multicast Listener Interval is the amount of time that must pass before a router decides there are no more listeners for an address on a link. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
マルチキャストリスナ間隔は、ルータがリンク上のアドレスのためのより多くのリスナーが存在しないことを決定する前に通過しなければならない時間の量です。この値は、する必要があります（（ロバストネス変数）回（クエリー間隔））プラス（1クエリ応答間隔）。
The Other Querier Present Interval is the length of time that must pass before a router decides that there is no longer another router which should be the querier on a link. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval).
他問合者存在間隔は、ルータがリンク上クエリアである必要があり、別のルータがもはや存在しないことを決定する前に通過しなければならない時間の長さです。この値は、（倍（クエリー間隔）（ロバストネス変数））プラス（1クエリ応答間隔の半分）でなければなりません。
The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval.
スタートアップクエリー間隔は、起動時にクエリアによって送られた一般クエリーの間隔です。デフォルト：1/4クエリー間隔。
The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable.
スタートアップクエリーカウントは、スタートアップクエリー間隔で区切って、起動時に送出されたクエリの数です。デフォルト：ロバストネス変数。
The Last Listener Query Interval is the Maximum Response Delay inserted into Multicast-Address-Specific Queries sent in response to Done messages, and is also the amount of time between Multicast-Address-Specific Query messages. Default: 1000 (1 second)
最終リスナークエリー間隔は最大応答遅延が実行されたメッセージに応答して送信されるマルチキャストアドレス固有クエリーに挿入され、また、マルチキャストアドレス固有のクエリメッセージ間の時間の量です。デフォルト：1000（1秒）
This value may be tuned to modify the "leave latency" of the link. A reduced value results in reduced time to detect the departure of the last listener for an address.
この値は、リンクの「脱退遅延」を修正するために調整することができます。短縮された時間での換算値の結果は、アドレスの最後のリスナーの出発を検出します。
The Last Listener Query Count is the number of Multicast-Address-Specific Queries sent before the router assumes there are no remaining listeners for an address on a link. Default: the Robustness Variable.
最後のリスナークエリーカウントは、ルータがリンク上のアドレスには、残りのリスナーが存在しないと仮定し前に送られたマルチキャストアドレス固有クエリーの数です。デフォルト：ロバストネス変数。
The Unsolicited Report Interval is the time between repetitions of a node's initial report of interest in a multicast address. Default: 10 seconds.
迷惑レポート間隔は、マルチキャストアドレスで目的のノードの最初の報告書の繰り返しの間の時間です。デフォルト：10秒。
This information is provided elsewhere in the document, but is summarized here for convenience.
この情報は他の場所で、文書で提供されていますが、便宜のために、ここに要約されます。
Message Type IPv6 Destination Address
------------ ------------------------
General Query link-scope all-nodes (FF02::1)
Multicast-Address-Specific Query the multicast address being queried
Report the multicast address being reported
Done link-scope all-routers (FF02::2)
We consider the ramifications of a forged message of each type. Note that the requirement that nodes verify that the IPv6 Source Address of all received MLD messages is a link-local address defends them from acting on forged MLD messages originated off-link, so we discuss only the effects of on-link forgery.
私たちは、それぞれのタイプの偽造メッセージの影響を考慮します。すべてのIPv6の送信元アドレスは、MLDメッセージを受け取ったことを確認ノード要件は、リンクローカルアドレスが偽造MLDメッセージに作用するからそれらを擁護していることに注意してくださいオフリンク発祥ので、我々は上のリンク偽造の唯一の影響を議論します。
Query message:
クエリメッセージ：
A forged Query message from a machine with a lower IP address
than the current Querier will cause Querier duties to be
assigned to the forger. If the forger then sends no more Query
messages, other routers' Other Querier Present timer will time
out and one will resume the role of Querier. During this time,
if the forger ignores Done messages, traffic might flow to
addresses with no listeners for up to [Multicast Listener
Interval].
A forged Query message sent to an address with listeners will cause one or more nodes that are listeners to that address to send a Report. This causes a small amount of extra traffic on the link, but causes no protocol problems.
リスナーとのアドレスに送信された偽造Queryメッセージには、レポートを送信するためにそのアドレスへのリスナーである1つの以上のノードが発生します。これは、リンク上の余分な少量のトラフィックが発生しますが、何のプロトコルの問題が生じません。
Report message:
Reportメッセージ：
A forged Report message may cause routers to think there are
listeners for an address present on a link when there are not.
However, since listening to a multicast address is generally an
unprivileged operation, a local user may trivially gain the same
result without forging any messages.
Done message:
Doneメッセージ：
A forged Done message will cause the Querier to send out
Multicast-Address-Specific Queries for the address in question.
This causes extra processing on each router and on each of the
address's listeners, and extra packets on the link, but cannot
cause loss of desired traffic.
MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen Sharma and Steve Deering and documented by Bill Fenner.
MLDは、ローゼン・シャーマとスティーブ・デアリングによって設計され、ビルフェナーによって文書化したIGMPv2の[IGMPv2の]に由来しました。
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDR-ARCH] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
【のICMPv6]コンタ、A.、およびS.デアリング、 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 2463、1998年12月。
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[IGMPv2の]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December, 1998.
[IPv6の-ETHER]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RTR-ALERT] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RTR-ALERT]ヤマウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[STD-PROC] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[STD-PROC]ブラドナー、S.、 "インターネット標準化過程 - リビジョン3"、BCP 9、RFC 2026、1996年10月。
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
スティーブンE.デアリングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 527 8213 EMail: deering@cisco.com
電話：+1 408 527 8213 Eメール：deering@cisco.com
William C. Fenner AT&T Research 75 Willow Road Menlo Park, CA 94025 USA
ウィリアム・C・フェナーAT＆T研究所75ウィローロードメンロパーク、CA 94025 USA
Phone: +1 650 867 6073 EMail: fenner@research.att.com
電話：+1 650 867 6073 Eメール：fenner@research.att.com
Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA
ブライアンハーバーマンIBMコーポレーション800公園事務所ドライブリサーチトライアングルパーク、NC 27709 USA
Phone: +1 919 254 2673 EMail: haberman@raleigh.ibm.com
電話：+1 919 254 2673 Eメール：haberman@raleigh.ibm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。