この文書はRFC2710の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
この文書は、直接接続されたリンク上でマルチキャストの聞き手の探索と、
明確にどのマルチキャストアドレスが近隣ノードに興味があるかの探索をす
るため、ＩＰｖ６ルータが使用するプロトコルを指定します。このプロトコ
ルはマルチキャスト聞き手探索あるいはＭＬＤと述べられます。ＭＬＤはＩ
Ｐｖ４インターネットグループ管理プロトコルのバージョン２、ＩＧＭＰｖ
２を基にしています。１つの重要な違いは、ＭＬＤが、ＩＧＭＰ（ＩＰプロ
トコル２）メッセージタイプではなく、ＩＣＭＰｖ６（ＩＰプロトコル５８）
メッセージタイプを使うということです。
1. Definitions
1. 定義
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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"はＲＦ
Ｃ２１１９[KEYWORDS]で記述されるように解釈されます。
2. Introduction
2. はじめに
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 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.
ＭＬＤは、マルチキャスト聞き手とルータに異なった行動を指定する、非対
称プロトコルです。ルータそれ自身が聞いているマルチキャストアドレスに
対し、ルータは自分自身のメッセージに返答することを含めプロトコルの両
者を実施します。
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.
もしルータが同じリンクへの複数のインタフェースを持っているなら、それ
はそれらのインタフェースの１つでだけの上記のＭＬＤルータの役割を行う
必要があります。他方、聞き手はＭＬＤの聞き手部分だけを、アプリケー
ションや上位レイヤプロトコルはマルチキャストパケットの受信をしたい全
インターフェースで、実行します。
3. Message Format
3. メッセージフォーマット
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.)
ＭＬＤはＩＣＭＰｖ６の副プロトコルです、すなわち、ＭＬＤメッセージタ
イプはＩＣＭＰｖ６メッセージの一部です、そしてＭＬＤメッセージは直前
の次ヘッダ値が５８であることで他のＩＰｖ６パケットと区別されます。こ
の文書で記述されたすべてのＭＬＤメッセージは、リンクローカルＩＰｖ６
ソースアドレスと、ＩＰｖ６ホップ限界が１と、ホップ毎オプションヘッダ
のＩＰｖ６ルータ警告オプション[RTR-ALERT]で送られます。（ルータ警告オ
プションはルータにルータ自身が受信をしていないマルチキャストアドレス
に送られたＭＬＤメッセージを調べさせるために必要です）。
MLD messages have the following format:
ＭＬＤメッセージは次のフォーマットです：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
| タイプ | コード | チェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Reserved |
| 最大応答遅延 | 予約 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| マルチキャストアドレス |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1. Type
3.1. タイプ
There are three types of MLD messages:
ＭＬＤメッセージに３つのタイプがあります：
Multicast Listener Query (Type = decimal 130)
マルチキャスト聞き手質問（タイプ＝１０進数で１３０）。
There are two subtypes of Multicast Listener Query messages:
マルチキャスト聞き手質問メッセージに２つのサブタイプがあります：
- 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.
これらの２つのサブタイプは、３.６章で記述されるように、マルチキャス
トアドレスフィールドの内容によって区別されます。
Multicast Listener Report (Type = decimal 131)
マルチキャスト聞き手報告（タイプ＝１０進数１３１）。
Multicast Listener Done (Type = decimal 132)
マルチキャスト聞き手完了（タイプ＝１０進数１３２）。
In the rest of this document, the above messages types are referred
to simply as "Query", "Report", and "Done".
この文書の残りで、上記のメッセージタイプはただ「質問」と「報告」と
「完了」と言います。
3.2. Code
3.2. コード
Initialized to zero by the sender; ignored by receivers.
送信者がゼロで初期化；受信者が無視。
3.3. Checksum
3.3. チェックサム
The standard ICMPv6 checksum, covering the entire MLD message plus a
"pseudo-header" of IPv6 header fields [ICMPv6,IPv6].
全部ＭＬＤメッセージとＩＰｖ６ヘッダーフィールドの「疑似ヘッダ」
[ICMPv6,IPv6]をカバーする、標準的なＩＣＭＰｖ６チェックサム。
3.4. Maximum Response Delay
3.4. 最大応答遅延
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.
この値を変えると、ルータは７.８章で論じられる「離脱遅延」を調整でき
ます（この時間はリンク上の最後の特定のマルチキャストを受信する最後の
ノードが受信を止めてから、ルーティングプロトコルがそのアドレスの受信
者がいないということを知らせられるまで時間です）。これは、７.３章で論
じられるように、リンク上のＭＬＤトラフィックのバースト性の調整を許し
ます。
3.5. Reserved
3.5. 予約
Initialized to zero by the sender; ignored by receivers.
送信者がゼロで初期化；受信者が無視。
3.6. Multicast Address
3.6. マルチキャストアドレス
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.
質問メッセージで、マルチキャストアドレスフィールドは、一般的質問を送
る時ゼロを設定し、そして、マルチキャストアドレス特定の質問を送る時、
特定のＩＰｖ６マルチキャストアドレスを設定します。
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.
報告あるいは完了メッセージで、マルチキャストアドレスフィールドは、メッ
セージ送信者が受信しているか受信を止める特定のＩＰｖ６マルチキャスト
アドレスです。
3.7. Other fields
3.7. 他のフィールド
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.
受信ＭＬＤメッセージ長はＩＰｖ６ペイロード長から、ＩＰｖ６ヘッダとＭ
ＬＤメッセージ間のＩＰｖ６拡張ヘッダを引くことで計算できます。もしそ
の長さが２４のオクテットより大きいなら、それは上記のフィールドの後に
他のフィールドがあることを意味し、多分将来の後方互換性があるバージョ
ンです。この文書で指定されたＭＬＤバージョンの実装は２４オクテットよ
り長いＭＬＤメッセージを送ってはならず(MUST NOT)、そして受信ＭＬＤメッ
セージの最初２４オクテット以降は無視しなくてはなりません(MUST)。例外
なく、ＭＬＤチェックサムはは、最初の２４オクテットだけではなく、全Ｍ
ＬＤメッセージ上で計算されなくてはなりません(MUST)。
4. Protocol Description
4. プロトコル記述
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.
ルータが接続するリンク上でどのマルチキャストアドレスに受信者がいるか
知るためにＭＬＤを使います。それぞれのルータがそれぞれの接続リンク毎
に受信者がいるマルチキャストアドレスのリストと、各アドレス毎のを維持
します。ルータがただ特定のマルチキャストアドレスの受信者がリンク上に
いるかだけを学ぶ必要があることに注意してください；受信者の識別子（例
えば、ユニキャストアドレス）や、何人の受信者がいるかを学ぶか必要があ
りません。
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.
それぞれの接続リンクで、ルータがそのリンク上にリンクローカルユニキャ
ストアドレスの１つを、そのリンク上で送信するすべてのＭＬＤパケットの
ＩＰｖ６ソースアドレスとして用るよう選びます。
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.
ルータがＭＬＤプロトコルを実施しているそれぞれのインタフェースで、ルー
タはＩＰｖ６マルチキャストで生成できる全てのリンクレイヤマルチキャス
トアドレスを受信する様にインタフェースの構成を設定しなくてはなりませ
ん。例えば、イーサネット接続ルータでイーサネットアドレス受信フィルタ
は１６進数で３３３３から始まる全イーサーネットマルチキャストアドレス
[IPv6-ETHER]を受け入れなければなりません；この範囲のマルチキャストの
フィルタをサポートしないイーサーネットインターフェースでは、ＭＬＤの
必要条件を満たすために、すべてのイーサネットマルチキャストアドレスを
受け入れるように設定されなくてはなりません。
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.
接続されているリンクのそれぞれに関して、ルータが２つの役割のいずれか
を引き受けてもよいです：質問者か非質問者。通常リンク毎に１つだけ質問
者がいます。全てのルータは接続しているリンクのそれぞれで質問者として
開始します。もしルータが、ＩＰｖ６ソースアドレスが自分の選択したアド
レスより数値的に小さい質問メッセージを聞くなら、そのリンク上で非質問
者にならなくてはなりません(MUST)。もし特定の接続リンクで自分自身のよ
り小さいアドレスのルータから［他質問発生間隔］を超えて質問の受信がな
いなら、ルータがそのリンク上の質問者の役割を再開します。
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.
リンクの質問者はそのリンクのすべての受信しているマルチキャストアドレ
スの報告を要請するために、リンクに周期的［質問間隔］で一般的質問を送
ります。最初ルータが、素早く信頼できるようにマルチキャストの受信者の
存在を検出するために、一般的質問を短い間隔[初期質問間隔]で送るべきで
す[初期質問回数](SHOULD)。
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].
一般的質問は、マルチキャストアドレスフィールドが０で、最大応答遅延が
[応答遅延間隔]で、リンク範囲全ノードマルチキャストアドレス（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.
ノードが一般的質問を受け取る時、質問を受信したインターフェースで受信
してそれぞれのマルチキャストアドレス毎に遅延タイマを起動します、但し、
リンク範囲全ノードアドレスや範囲０（予約）や範囲１（ノードローカル）
を除きます。それぞれのタイマは、ノードの利用可能な最高精度の時計の精
度で、[０、最大応答遅延]の範囲の異なったランダム値を設定します、最大
応答遅延は質問で指定された値です。もしいずれかのアドレスのタイマがす
でに動いているなら、求められた最大応答遅延がタイマの残り時間より小さ
い場合に限り、新しいランダム値にリセットします。もし質問パケットがゼ
ロの最大応答遅延を指定するなら、それぞれのタイマはゼロが設定され、そ
してタイマのタイムアウト時の下で指定する行動はすぐに行われます。
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.
ノードがマルチキャスト特定の質問を受信したら、もし質問を受信したイン
ターフェースで該当する質問されたマルチキャストアドレスを受信している
なら、そのアドレスの遅延タイマに、上記同様に、[０、最大応答時間]の範
囲のランダム値を設定します。もしいずれかのアドレスのタイマがすでに動
いているなら、求められた最大応答遅延がタイマの残り時間より小さい場合
に限り、新しいランダム値にリセットします。もし質問パケットがゼロの最
大応答遅延を指定するなら、それぞれのタイマはゼロが設定され、そしてタ
イマのタイムアウト時の下で指定する行動はすぐに行われます。
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.
もしノードの特定のインタフェース上の特定のマルチキャストアドレスのた
めのタイマがタイムアウトするなら、ノードはそのインタフェースからその
アドレスへ報告を伝達します；報告されているアドレスはＩＰｖ６宛先アド
レスフィールドと報告パケットのＭＬＤマルチキャストアドレスフィールド
の両方で運ばれます。ＩＰｖ６ホップ限界の１（リンクローカルＩＰｖ６ソー
スアドレスである限り）は、報告インタフェースの接続リンクを越えてパケッ
トが移動するのを阻止します。
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.
ノードがインタフェース上でマルチキャストアドレスの受信をやめる時、マ
ルチキャストアドレスフィールドに受信をやめるアドレスを設定して、リン
ク範囲全ルータマルチキャストアドレスに完了メッセージを送るべきです
(SHOULD)。もしノードの最近の報告メッセージが他の報告メッセージを聞く
ことにで抑制されたなら、同じリンクにまだ存在しているアドレスの受信者
がいることは大いにありそうであるから、何も送らないかもしれません
(MAY)。もしこの最適化が実施されるなら、これはオフにできなければなりま
せん(MUST)が、デフォルトはオンであるべきです(SHOULD)。
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.
質問状態のルータが完了メッセージをリンクで受信した場合、もしメッセー
ジで指定されたマルチキャストアドレスが質問者のそそのリンク上の受信者
アドレスリストに存在しているなら、質問者はマルチキャストアドレス特定
質問を、[最終受信者質問回数]毎に、マルチキャストアドレスに送信します
[最終受信者質問回数]。これらのマルチキャストアドレス特定の質問は最大
応答遅延を［最終受信者質問間隔］に設定します。もし最後の問合せの回答
遅延までにリンクからアドレスの報告がなければ、リンク上のルータはその
アドレスの受信者がもういないと想定します；従ってアドレスはリストから
削除され、その削除はマルチキャストルーティングコンポーネントに知らせ
られます。このプロセスは、たとえ質問者がこのリンクの質問者でなくなっ
たとしても、解決するまで（すなわち報告を受信するか、最後のマルチキャ
ストアドレス特定の問合せの応答がないと確認できるまで）続けられます。
Routers in Non-Querier state MUST ignore Done messages.
非質問者状態のルータが完了メッセージを無視しなくてはなりません(MUST)。
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.
非質問者状態のルータがマルチキャストアドレス特定質問を受信し、もし指
定されたマルチキャストアドレスのタイマ値が[最終受信者質問カウント]と
メッセージで指定された最大応答遅延の掛け算よりおおきいなら、アドレス
のタイマーを後の値に設定します。
5. Node State Transition Diagram
5. ノード状態遷移図
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:
ノード動作がより公式に下記の状態遷移図によって指定されます。ノードは
１つのインターフェース上の１つの状態に対応する、３つの状態の１つです：
- "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:
ＭＬＤ状態遷移を起こす５つの重要なイベントがあります：。
- "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.
- 「質問受信」はノードが正当な一般的問合せメッセージ、あるいは正当な
マルチキャストアドレス特定の問合せメッセージを受信する時に起こりま
す。正当であるために、質問メッセージはリンクローカルＩＰｖ６ソース
アドレスから来て、２４オクテット以上であり、そして正しいＭＬＤチェッ
クサムでなくてはなりません(MUST)。ＭＬＤメッセージのマルチキャスト
アドレスフィールドはゼロ（一般的質問）あるいは正当なマルチキャスト
アドレス（マルチキャストアドレス特定質問）を含んでいなくてはなりま
せん。一般的質問は、質問を受信したインタフェース上の全てのマルチキャ
ストアドレスに当てはまります。マルチキャストアドレス特定問合せが問
合せを受信したインターフェースのひとつのマルチキャストアドレスに当
てはまります。非受信状態のアドレスへの質問は無視されます。
- "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.
- 「報告受信」はノードが正当なＭＬＤ報告メッセージを受け取る時に起こ
ります。正当であるために、報告メッセージはリンクローカルＩＰｖ６ソー
スアドレスから来て、少なくとも２４オクテットであり、正しいＭＬＤ
チェックサムを持っていなくてはなりません(MUST)。報告は、報告を受信
するインタフェース上の、報告のマルチキャストアドレスフィールドで示
されたアドレスにだけ当てはまります。これは非受信はアイドル受信状態
では無視されます。
- "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.
すべての無効なＭＬＤメッセージや質問・報告以外のＭＬＤメッセージタイ
プを受信する他のイベントはすべての状態で無視されます。
There are seven possible actions that may be taken in response to the
above events:
上記のイベントに応えてとられるかもしれない７つの可能な行動があります：
- "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).
- 「完了送信」、インタフェースのアドレスを完了。もし我々が報告を送った
最後のノードである事を示すフラグがクリアなら、この行動は省略される
かもしれません(MAY)。完了メッセージはリンク範囲全ルータアドレス
（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] ].
- 「タイマ開始」、質問で指定された最大応答遅延に対し、[０、最大応答遅
延]の範囲から一様分布で選択された、遅延値を使ってインタフェース上
のアドレスのタイマを開始。もしこれが要請されていない報告であるなら
ば、タイマは[０、要請されていない応答遅延]の範囲から一様分布で選択
された遅延値を設定します。
- "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".
- 「タイマリセット」、「タイマ開始」で記述されるように、、[０、最大応答
遅延]の範囲から一様分布で選択された、遅延値を使ってインタフェース
インタフェース上のアドレスのタイマをリセットします。
- "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 | |
| | 質問受信 | |
| | (start timer) | |
| Delaying | (タイマ開始) | 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 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).
ＭＬＤメッセージは範囲２（リンクローカル）であるマルチキャストアドレ
スで、要請ノードマルチキャストアドレス[ADDR- ARCH]を含めて、リンク範
囲全ノードアドレス（FF02::1）以外、に送られます。
6. Router State Transition Diagram
6. ルータ状態遷移図
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:
ルータは接続するリンクに関して２つの可能な状態の１つにあるかもしれま
せん：
- "Querier", when this router is designated to transmit MLD Queries
on this link.
- 「質問者」、このルータがこのリンク上でＭＬＤ質問を送信するように指
名されてる。
- "Non-Querier", when there is another router designated to transmit
MLD Queries on this link.
- 「非質問者」、他のルータがこのリンク上でＭＬＤ質問を送信するように
指名されてる。
The following three events can cause the router to change states:
次の３つのイベントはルータ状態を変えることができます：
- "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.
- 「より小さいＩＰアドレスのルータから質問の受信」は、正当なＭＬＤの
問合せが同じリンクの上のより小さいＩＰｖ６ソースアドレスのルータか
ら来た時に、起こります。正当であるために、問合せメッセージはリンク
ローカルＩＰｖ６ソースアドレスから来て、少なくとも２４オクテット長
であって、そして正しいＭＬＤチェックサムを持っていなくてはなりませ
ん(MUST)。
- "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.
- 「他質問者存在タイマタイムアウト」は、リンク上のより小さいＩＰアド
レスの他の質問者の存在に気付くために定められたタイマがタイムアウト
する時、起こります。このイベントは、ただ非質問者状態で、重要です。
There are three actions that may be taken in response to the above
events:
上記のイベントに応えてとられるかもしれない３つの行動があります：
- "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:
加えて、どのマルチキャストアドレスに受信者がいるか記録・追跡するため
に、ルータはひとつの接続リンク上の１つのＩＰｖ６マルチキャストアドレ
スに関して、３つの可能な状態の１つにあるかもしれません：
- "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:
ルータ状態遷移を起こすことができる５つの重要なイベントがあります：
- "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.
- 「報告受信」は、ルータがリンクからアドレスの報告を受け取る時に起こ
ります。正当であるために、報告メッセージはリンクローカルＩＰｖ６ソー
スアドレスから来て、少なくとも２４オクテット長であって、正しいＭＬ
Ｄチェックサムでなくてはなりません(MUST)。
- "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.
- 「完了受信」は、ルータがリンクからアドレスの完了メッセージを受け取
る時に起こります。正当であるために、完了メッセージははリンクローカ
ルＩＰｖ６ソースアドレスから来て、少なくとも２４オクテット長であっ
て、正しいＭＬＤチェックサムでなくてはなりません(MUST)。このイベン
トは「受信者存在」状態でルータが質問者である時にだけ意味があります。
- "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.
- 「マルチキャストアドレス特定質問受信」は、ルータがリンクからアドレ
スのマルチキャストアドレス特定質問を受信する時に起こります。正当で
あるために、質問メッセージはリンクローカル範囲のＩＰｖ６ソースアド
レスから来て、少なくとも２４オクテット長で、正しいＭＬＤチェックサ
ムでなければなりません(MUST)。このイベントは「受信者存在」状態でルー
タが非質問者である時にだけ意味を持ちます。
- "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:
上記のイベントに応えてとられるかもしれない７つの可能な行動があります：
- "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.
- 「タイマ起動＊」、リンク上のアドレスのタイマを起動−この動作はタイ
マを現在の値か次の値の小さいほうにタイマを設定します、もしこのルー
タが質問者なら［最終受信者質問間隔］×[最終受信者質問カウント]
か、もしこのルータが非質問者なら質問メッセージの最大応答遅延×
[最終受信者質問カウント]。
- "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.
次の状態図はリンク毎グループ毎に適用されます。２つの状態図があります；
１つは質問者状態のルータ用で、他は非質問者状態のルータ用です。リンク
上での質問者と非質問者状態間の遷移は特別に処理されます。質問者／非質
問者状態間遷移が生じた際に、「受信者不在」か「受信者存在」状態にある
全てのグループは、状態遷移図を切り替えます。しかしながら、「受信者検
査」状態にあるグループは、「受信者検査」状態から抜けるまで、同じ状態
遷移図に留まりつづけます。例えば質問者で開始したルータが、グループの
完了メッセージを受信し、それからより小さいアドレスのルータの質問を受
信（非受信者状態にに移行する事になる）しても、報告を受信するかタイム
アウトするまでグループのマルチキャスト特有の質問を送信し続け、そして
そこからこのグループの非質問者として動作します。
The state transition diagram for a router in Querier state follows:
質問者状態のルータの状態遷移図は以下のとおりです：
________________
| |timer expired
| |タイマタイムアウト
timer expired| |(notify routing -,
タイマタイムアウト| |clear rxmt tmr)
(notify routing -)| No Listeners |(ルーティング通知−,
(ルーティング通知−)| Present |再送タイマクリア)
------->| 受信者不在 |<---------
| | | |
| | | |
| |________________| | ---------------
| | | | rexmt timer |
| report received| | | expired |
| 報告受信| | | 再送信タイマ |
| (notify routing +,| | | タイムアウト |
| start timer)| | | (send m-a-s |
|(ルーティング通知＋,| | | query, |
| タイマ起動)| | | st rxmt tmr) |
| | | |(マルチキャスト|
| | | | アドレス特定質|
| | | | 問送信, |
| | | | 再送タイマ |
__________|______ | ________|_|______ 起動) |
| |<------------ | | |
| | | |<-------
| | report received | |
| | 報告受信 | |
| | (start timer, | |
| | clear rxmt tmr) | |
| | (タイマ起動, | |
| | 再送タイマクリア) | |
| Listeners |<-------------------| Checking |
| Present | | Listeners |
| 受信者存在 | done received | 受信者検査 |
| | 完了受信 | |
| | (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 -)| |(notify routing -)
(ルーティング通知−)| No Listeners |(ルーティング通知−)
--------->| 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) |
| (タイマ起動) |
-----------------
7. List of timers and default values
7. タイマとデフォルト値のリスト
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.
これらのタイマの大部分が変更可能です。もし非デフォルト設定が使われる
なら、それらはひとつのリンク上の全ルータ間で整合してなくてはなりませ
ん(MUST)。数式を明らかにするためにグループ表現の括弧が使われることに
注意してください。
7.1. Robustness Variable
7.1. 強靭変数
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
強靭変数はリンク上で予想されるパケット損失のために調整できます。もし
リンクの損失が多そうなら、強靭変数は値を増やされるかもしれません。Ｍ
ＬＤは（強靭変数−１）のパケット損失に対して安定です。変数はゼロであっ
てはならなくて(MUST NOT)、そして１でないべきです(SHOULD NOT)。デフォ
ルト：２。
7.2. Query Interval
7.2. 質問間隔
The Query Interval is the interval between General Queries sent by
the Querier. Default: 125 seconds.
質問間隔は質問者が送る一般的質問の間の間隔です。デフォルト：１２５秒。
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.
［質問間隔］を変えることによって、管理者がリンク上のＭＬＤメッセージ
数を調整できます；より大きい値はＭＬＤ質問が稀にしか送られないように
します。
7.3. Query Response Interval
7.3. 質問応答間隔
The Maximum Response Delay inserted into the periodic General
Queries. Default: 10000 (10 seconds)
周期的な一般的質問に設定される最大応答遅延。デフォルト：１００００
（１０秒）。
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].
［質問応答間隔］を変えることによって、管理者がリンク上のＭＬＤメッセー
ジのバースト性を調整できます；より大きい値は、ノード応答をより大きい
間隔の上に展開するので、トラフィックのバースト性をより少なくします。
［質問応答間隔］で表される秒数は［質問間隔］より小さいに違いありませ
ん。
7.4. Multicast Listener Interval
7.4. マルチキャスト受信者間隔
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).
マルチキャスト受信者間隔は、ルータがリンクにアドレスの受信者がいない
と決定する前に、待たなければならない時間量です。この値は（（強靭変数）
×（質問間隔））＋（１つの質問応答間隔）に違いありません(MUST)。
7.5. Other Querier Present Interval
7.5. 他質問者存在間隔
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).
他質問者の存在間隔は、ルータがリンクに他の質問者のルータが存在しない
と決定するまで待つ時間です。この値は（（強靭変数）×（質問間隔））＋
（１つの質問回答間隔の２分の１）に違いありません(MUST)。
7.6. Startup Query Interval
7.6. 起動質問間隔
The Startup Query Interval is the interval between General Queries
sent by a Querier on startup. Default: 1/4 the Query Interval.
起動質問間隔は起動した質問者が送る一般的質問の間隔です。デフォルト：
質問間隔の１／４。
7.7. Startup Query Count
7.7. 起動質問カウント
The Startup Query Count is the number of Queries sent out on startup,
separated by the Startup Query Interval. Default: the Robustness
Variable.
起動質問カウントは起動時に、始動質問間隔で、送る質問の数です。デフォ
ルト：強靭変数。
7.8. Last Listener Query Interval
7.8. 最終受信者質問間隔
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)
最終受信者質問間隔は完了メッセージに応えて送られたマルチキャストアド
レス特定質問に設定される最大応答遅延で、同じくマルチキャストアドレス
特定質問のメッセージ間の時間です。デフォルト：１０００（１秒）。
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.
この値はリンクの「離脱遅延」を修正するために調整されるかもしれません。
値を減らすとアドレスの最終受信者の検出時間の現象をもたらします。
7.9. Last Listener Query Count
7.9. 最終受信者質問カウント
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.
最終受信者質問カウントは、ルータがリンクのアドレスに受信者が残ってい
ないと想定する前に送るマルチキャストアドレス特有質問の数です。デフォ
ルト：強靭変数。
7.10. Unsolicited Report Interval
7.10. 望まれない報告間隔
The Unsolicited Report Interval is the time between repetitions of a
node's initial report of interest in a multicast address. Default:
10 seconds.
望まれない報告間隔はマルチキャストアドレスの受信ノードの最初の報告の
間隔です。デフォルト：１０秒。
8. Message Destinations
8. メッセージ宛先
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)
一般質問 リンク範囲全ノード（FF02::1）
Multicast-Address-Specific Query the multicast address being queried
マルチキャストアドレス特定質問 質問するマルチキャストアドレス
Report the multicast address being reported
報告 報告するマルチキャストアドレス
Done link-scope all-routers (FF02::2)
完了 リンク範囲全ノード（FF02::1）
9. Security Considerations
9. セキュリティの考慮
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.
我々はそれぞれのタイプの偽造されたメッセージの結果を考察します。ノー
ドがすべての受信ＭＬＤメッセージのＩＰｖ６ソースアドレスがリンクロー
カルアドレスであることを確かめるという必要条件によりリンク外の偽造か
ら防御できます、それでリンク内の偽造の効果だけを論じます。
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.
受信者のいるアドレスに送られた偽造質問メッセージはそのアドレス
の受信者である１つ以上のノードに報告を送らせるでしょう。これは
リンク上に小さい量の余分のトラフィックを起こしますが、プロトコ
ル問題を起こしません。
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.
偽造された完了メッセージは質問者に問題のアドレスのためのマルチ
キャストアドレス特定質問を送らさせるでしょう。これはそれぞれの
ルータとそれぞれのアドレスの受信者とに余分の処理をもたらし、リン
ク上に余計なパケットを発生させますが、望ましいトラフィックの損失
を起こしません。
10. Acknowledgments
10. 謝辞
MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen
Sharma and Steve Deering and documented by Bill Fenner.
ＭＬＤはＩＧＭＰｖ２［IGMPv2］から得られ、そしてそれはRosen Sharmaと
Steve Deeringによって設計され、Bill Fennerによって文書化されました。
11. References
11. 参考文献
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December, 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RTR-ALERT] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[STD-PROC] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
12. Authors' Addresses
12. 著者のアドレス
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
Phone: +1 650 867 6073
EMail: fenner@research.att.com
Brian Haberman
IBM Corporation
800 Park Office Drive
Research Triangle Park, NC 27709
USA
Phone: +1 919 254 2673
EMail: haberman@raleigh.ibm.com
13. Full Copyright Statement
13. 著作権表示全文
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（Ｃ）インターネット学会（１９９９）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。