[要約] RFC 2710はIPv6のマルチキャストリスナーの検出（MLD）に関する規格であり、IPv6ネットワークでのマルチキャスト通信の効率的な管理を目的としています。
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
IPv6のマルチキャストリスナーディスカバリー（MLD）
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.
Copyright（c）The Internet Society（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のInternet Group Management ProtocolであるIGMPV2のバージョン2から派生しています。注意すべき重要な違いの1つは、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
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はICMPv6のサブプロトコルです。つまり、MLDメッセージタイプはICMPV6メッセージのセットのサブセットであり、MLDメッセージは58の次のヘッダー値によってIPv6パケットで識別されます。このドキュメントで説明されているすべてのMLDメッセージはLink-Local IPv6ソースアドレス、1のIPv6ホップ制限、およびホップバイホップオプションヘッダーのIPv6ルーターアラートオプション[RTR-Alert]を使用して送信されます。（ルーターがマルチキャストアドレスに送信されたMLDメッセージを調べて、ルーター自体に興味がない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)
マルチキャストリスナークエリ（Type = 10進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.
これらの2つのサブタイプは、セクション3.6で説明されているように、マルチキャストアドレスフィールドの内容によって区別されます。
Multicast Listener Report (Type = decimal 131)
マルチキャストリスナーレポート（Type =小数131）
Multicast Listener Done (Type = decimal 132)
マルチキャストリスナーが完了しました（Type = 10進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.
クエリメッセージでは、一般的なクエリを送信するときにマルチキャストアドレスフィールドがゼロに設定され、マルチキャストアドレス固有のクエリを送信するときに特定の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.
レポートまたは完了したメッセージでは、マルチキャストアドレスフィールドには、メッセージ送信者がそれぞれ聞いているか、リッスンを停止している特定の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のバージョンの実装は、24オクテットより長いMLDメッセージを送信してはならず、受信したMLDメッセージの最初の24オクテットを超えて無視する必要があります。すべての場合において、MLDチェックサムは、最初の24オクテットだけでなく、MLDメッセージ全体で計算する必要があります。
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.
添付のリンクごとに、ルーターは、そのリンクでリンクローカルユニキャストアドレスの1つを選択し、そのリンクで送信するすべての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.
添付のリンクのそれぞれに関して、ルーターは2つの役割のいずれかを想定する場合があります。通常、リンクごとにクエリエが1つしかありません。すべてのルーターは、添付された各リンクのクエリエとして起動します。ルーターが、IPv6ソースアドレスがそのリンクの選択したアドレスよりも数値的に少ないクエリメッセージを聞く場合、そのリンクのqueては非極地になる必要があります。[他のQuerier Present間隔]が、特定の添付のリンクから、それ自体よりも少ないアドレスを持つルーターからのクエリを受信せずに通過する場合、ルーターはそのリンクのQuerierの役割を再開します。
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と[クエリ応答間隔]の最大応答遅延で、リンクスコープAll-Nodesマルチキャストアドレス（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マルチキャストアドレスフィールドフィールドの両方で運ばれます。IPv6ホップ制限1（およびリンクローカル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).
ノードがインターフェイス上のマルチキャストアドレスの聴取を開始すると、リンクの最初のリスナーである場合、そのインターフェイス上のそのアドレスの未承諾レポートを直ちに送信する必要があります。最初のレポートが失われたり破損したりする可能性をカバーするために、短い遅延[未承諾レポート間隔]後に1回または2回繰り返すことをお勧めします。（これを達成する簡単な方法は、最初のレポートを送信してから、そのアドレスに対してマルチキャストアドレス固有のクエリを受信し、タイマーを適切に設定するかのように行動することです）。
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.
Querier Stateのルーターがリンクから完成したメッセージを受信すると、メッセージで識別されたマルチキャストアドレスがそのリンクにリスナーがあるアドレスのQuerierのリストに存在する場合、Querierは[最後のリスナークエリカウント]マルチキャストアドレス固有の送信クエリ、そのマルチキャストアドレスへのすべての[最後のリスナークエリ間隔]。これらのマルチキャストアドレス固有のクエリの最大応答遅延は、[最後のリスナークエリ間隔]に設定されています。最後のクエリの応答遅延が渡された後、リンクからアドレスのレポートが受信されない場合、リンク上のルーターは、アドレスにリスナーがいなくなったと仮定します。したがって、アドレスはリストから削除され、その消失はマルチキャストルーティングコンポーネントに知られています。このリンクの移行にもかかわらず、このプロセスは解決に続きます（つまり、レポートを受信するか、最後のマルチリカストアドレス固有のクエリが応答なしで送信されるまで送信されます）。
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.
- 「クエリの受信」は、ノードが有効な一般的なクエリメッセージ、または有効なマルチキャストアドレス固有のクエリメッセージのいずれかを受信したときに発生します。有効にするには、クエリメッセージはLink-Local 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レポートメッセージを受信したときに、「受信したレポート」が発生します。有効にするには、レポートメッセージはリンクローカル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).
- インターフェイス上のアドレスの「DONEを送信」。私たちが報告した最後のノードであるというフラグがクリアされた場合、このアクションはスキップされる可能性があります。完了したメッセージは、Link-Scope All-Routersアドレス（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.
Link-Scope All-Nodesアドレス（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メッセージは、リンクスコープ、All-Nodesアドレス（FF02 :: 1）を除き、勧誘されたノードマルチキャストアドレス[ADDR-ARCH]を含む、スコープが2（リンクローカル）であるマルチキャストアドレスに対して送信されます。
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.
- 「Querier」、このルーターがこのリンクにMLDクエリを送信するように指定されている場合。
- "Non-Querier", when there is another router designated to transmit MLD Queries on this link.
- 「非querier」、このリンクに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.
- 「低いIPアドレスを持つルーターから受信したクエリ」は、低いIPv6ソースアドレスと同じリンクのルーターから有効なMLDクエリが受信されたときに発生します。有効にするには、クエリメッセージはLink-Local 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].
- 添付のリンクで「一般的なクエリを送信」します。一般的なクエリは、Link-Scope All-Nodesアドレス（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.
ルーターは、添付のすべてのリンクで初期状態で開始され、すぐにQuerier状態に移行します。
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.
- 「完了した」は、ルーターがリンクからアドレスの完了メッセージを受信したときに発生します。有効にするには、完了したメッセージは、Link-Local IPv6ソースアドレスから送信され、少なくとも24オクテットの長さであり、正しいMLDチェックサムを持っている必要があります。このイベントは、「リステルズが出席する」状態でのみ重要です。ルーターがクエリエである場合です。
- "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.
- 「Multicast-Address固有のクエリが受信された」は、ルーターがリンクからアドレスのマルチキャストアドレス固有のクエリを受信したときに発生します。有効にするには、クエリメッセージはLink-Local 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.
- リンク上のアドレスの「スタートタイマー *」 - この代替アクションにより、タイマーが現在の値の最小値に設定され、[最後のリスナークエリ間隔] * [最後のリスナークエリカウント]このルーターがクエリエの場合、または最大値クエリメッセージの応答遅延 * [最後のリスナークエリカウント]このルーターがquerierでない場合。
- "start retransmit timer" for the address on the link [Last Listener Query Interval].
- リンク上のアドレスの「再送信タイマーを開始」[最後のリスナークエリ間隔]。
- "clear retransmit timer" for the address on the link.
- リンク上のアドレスの「Clear Rectransmitタイマー」。
- "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つはQuerier状態のルーター用、もう1つは非極人状態のルーター用です。リンク上のQuerierと非querier状態の間の移行は、特別に処理されます。「リスナーは存在しない」または「リスナーが提示されていない」状態のすべてのグループは、クエリエ/querier状態のトランジションが発生したときに状態遷移図を切り替えます。ただし、「リスナーをチェックする」状態のグループは、「リスナーのチェック」状態が終了するまで、同じ状態遷移図を継続します。例えば。クエリエとして起動するルーターは、グループに対して完了したメッセージを受信し、より低いアドレス（非極人状態への移行を引き起こす）を持つルーターからクエリを受信します。問題は、レポートを受け取るか、そのタイマーが期限切れになるまで、このグループの非querierの行動の実行を開始するまで。
The state transition diagram for a router in Querier state follows:
Querier状態のルーターの状態遷移図は次のとおりです。
________________
| |
| |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.
非極地状態のルーターの状態遷移図は似ていますが、非queriersはメッセージを送信せず、メッセージ受信によってのみ駆動されます。
________________
| |
| |
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.
各タイプの偽造メッセージの影響を検討します。ノードという要件は、受信したすべてのMLDメッセージのIPv6ソースアドレスがリンクローカルアドレスであることを確認することに注意してください。
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].
現在のクエリエよりも低いIPアドレスを持つマシンからの偽造クエリメッセージにより、クエリエの任務がForgerに割り当てられます。Forgerがクエリメッセージを送信しない場合、他のルーターの他のクエリエプレゼントタイムはタイムアウトし、クエリエの役割を再開します。この間、Forgerが実行されたメッセージを無視している場合、[マルチキャストリスナー間隔]のリスナーがいないため、トラフィックがアドレスに流れる可能性があります。
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.
リスナーと一緒にアドレスに送信された鍛造クエリメッセージは、そのアドレスのリスナーである1つ以上のノードを、レポートを送信することになります。これにより、リンク上の余分なトラフィックが少なくなりますが、プロトコルの問題は発生しません。
Report message:
レポートメッセージ：
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:
完了したメッセージ：
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.
偽造されたメッセージにより、Querierは問題のアドレスのマルチキャストアドレス固有のクエリを送信します。これにより、各ルーターと各アドレスのリスナーに追加の処理が発生し、リンクに追加のパケットが発生しますが、希望するトラフィックの損失を引き起こすことはできません。
MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen Sharma and Steve Deering and documented by Bill Fenner.
MLDは、Rosen SharmaとSteve Deeringによって設計され、Bill Fennerによって記録されたIgmpv2 [Igmpv2]に由来しています。
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Addr-Arch] Hinden、R。およびS. Deering、「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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Igmpv2] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and 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] Crawford、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RTR-ALERT] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RTR-Alert] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[STD-PROC] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[STD-Proc] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E. Deering Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1 408 527 8213
EMail: deering@cisco.com
William C. Fenner AT&T Research 75 Willow Road Menlo Park, CA 94025 USA
William C. Fenner AT＆T Research 75 Willow Road Menlo Park、CA 94025 USA
Phone: +1 650 867 6073
EMail: fenner@research.att.com
Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA
ブライアンハーバーマンIBMコーポレーション800パークオフィスドライブリサーチトライアングルパーク、ノースカロライナ州27709 USA
Phone: +1 919 254 2673
EMail: haberman@raleigh.ibm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。