この文書はRFC3810の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Vida, Ed.
Request for Comments: 3810 L. Costa, Ed.
Updates: 2710 LIP6
Category: Standards Track June 2004
Multicast Listener Discovery Version 2 (MLDv2) 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 (2004).
Abstract
概要
This document updates RFC 2710, and it specifies Version 2 of the
Multicast Listener Discovery Protocol (MLDv2). MLD is used by an
IPv6 router to discover the presence of multicast listeners on
directly attached links, and to discover which multicast addresses
are of interest to those neighboring nodes. MLDv2 is designed to be
interoperable with MLDv1. MLDv2 adds the ability for a node to
report interest in listening to packets with a particular multicast
address only from specific source addresses or from all sources
except for specific source addresses.
この文書はＲＦＣ２７１０を更新します、そしてこれはマルチキャスト受信
者探索プロトコルの２版（ＭＬＤｖ２）を指定します。ＭＬＤは直接接続す
るリンク上でマルチキャストの受信者の存在を見つけて、それらの隣接する
ノードがどのマルチキャストアドレスを受信するか知るためにＩＰｖ６ルー
タによって使われます。ＭＬＤｖ２はＭＬＤｖ１と同時使用可能であるよう
意図されます。ＭＬＤｖ２は特定のソースアドレスからの特定のマルチキャ
ストアドレスだけ、あるいは特定のソースアドレス以外のすべてのソースア
ドレスからの特定のマルチキャストアドレスだけノードが聞く報告をする能
力を加えます。
Table of Contents
目次
1. Introduction
1. はじめに
2. Protocol Overview
2. プロトコル概観
3. The Service Interface for Requesting IP Multicast Reception
3. ＩＰマルチキャスト受信を求めるサービスインタフェース
4. Multicast Listening State Maintained by Nodes
4. ノードのマルチキャスト受信状態維持
5. Message Formats
5. メッセージフォーマット
6. Protocol Description for Multicast Address Listeners
6. マルチキャストアドレス受信者のためのプロトコル記述
7. Description of the Protocol for Multicast Routers
7. マルチキャストルータのためのプロトコルの記述
8. Interoperation with MLDv1
8. ＭＬＤｖ１との相互運用
9. List of Timers, Counters, and their Default Values
9. タイマとカウンタとそれらのデフォルト値のリスト
10. Security Considerations
10. セキュリティの考察
11. IANA Considerations
11. ＩＡＮＡの考慮
12. References
12. 参考文献
13. Acknowledgments
13. 謝辞
APPENDIX A. Design Rationale
付録Ａ。 デザイン原理
APPENDIX B. Summary of Changes from MLDv1
付録Ｂ。 ＭＬＤｖ１からの変更の要約
Editors' Contact Information
編集者への連絡情報
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
The Multicast Listener Discovery Protocol (MLD) is used by IPv6
routers to discover the presence of multicast listeners (i.e., nodes
that wish to receive multicast packets) on their directly attached
links, and to discover specifically which multicast addresses are of
interest to those neighboring nodes. Note that a multicast router
may itself be a listener of one or more multicast addresses; in this
case it performs both the "multicast router part" and the "multicast
address listener part" of the protocol, to collect the multicast
listener information needed by its multicast routing protocol on the
one hand, and to inform itself and other neighboring multicast
routers of its listening state on the other hand.
マルチキャスト受信者探索プロトコル（ＭＬＤ）は、直接接続するリンク上
のマルチキャストの受信者（すなわち、マルチキャストパケットを受信する
ことを望むノード）の存在を見つけて、特にそれらの隣接するノードがどの
マルチキャストアドレスを受信したいか知るためにＩＰｖ６ルータによって
使われます。マルチキャストルータ自身が、マルチキャストアドレスの受信
者であるかもしれないことに注意してください；この場合これは、一方でマ
ルチキャストルーティングプロトコルに必要としたマルチキャストの受信者
の情報を集めて、他方それ自身と他の隣接するマルチキャストルータに受信
者の状態を伝えるために、プロトコルの「マルチキャストルータの役割」と
「マルチキャストアドレスの受信者の役割」の両方を行います。
This document specifies Version 2 of MLD. The previous version of
MLD is specified in [RFC2710]. In this document we will refer to it
as MLDv1. MLDv2 is a translation of the IGMPv3 protocol [RFC3376]
for IPv6 semantics.
この文書はＭＬＤの２版を指定します。ＭＬＤの前の版は[RFC2710]で指定さ
れます。この文書で我々はそれをＭＬＤｖ１と述べるでしょう。ＭＬＤｖ２
はＩＰｖ６のためのＩＧＭＰｖ３[RFC3376]の意味的の翻訳です。
The MLDv2 protocol, when compared to MLDv1, adds support for "source
filtering", i.e., the ability for a node to report interest in
listening to packets *only* from specific source addresses, as
required to support Source-Specific Multicast [RFC3569], or from *all
but* specific source addresses, sent to a particular multicast
address. MLDv2 is designed to be interoperable with MLDv1.
ＭＬＤｖ２プロトコルは、ＭＬＤｖ１と比較して、「ソースフィルタリング」
に対するサポート、すなわち、ソース特定マルチキャスト[RFC3569]のサポー
トで要求されるように、ノードが特定のソースアドレスからのパケット*だけ*、
あるいは特定のソース*以外*からマルチキャストアドレスに送られたパケッ
トだけに興味を持つと報告する能力を加えます。ＭＬＤｖ２はＭＬＤｖ１と
同時使用可能であるよう意図されます。
The capitalized 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
[RFC2119]. Due to the lack of italics, emphasis is indicated herein
by bracketing a word or phrase in "*" characters. Furthermore,
square brackets are used to denote the value of the enclosed
variable, as opposed to the variable itself, written without
brackets.
この文書での大文字化されたキーワード"MUST"と"MUST NOT"と"REQUIRED"と
"SHALL"と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と
"OPTIONAL"は［RFC2119]で記述されるように解釈されるはずです。イタリッ
ク体がないので、単語や文の強調は"*"文字でくくることで示されます。さら
に、角カッコが、カッコ無しで書かれた変数に対し、変数の値を意味するた
めに使われます。
2. Protocol Overview
2. プロトコル概観
This section gives a brief description of the protocol operation. The
following sections present the protocol details.
この章はプロトコルオペレーションの短い記述をします。次の章はプロトコ
ル細部を示します。
MLD is an asymmetric protocol; it specifies separate behaviors for
multicast address listeners (i.e., hosts or routers that listen to
multicast packets) and multicast routers. The purpose of MLD is to
enable each multicast router to learn, for each of its directly
attached links, which multicast addresses and which sources have
interested listeners on that link. The information gathered by MLD
is provided to whichever multicast routing protocol is used by the
router, in order to ensure that multicast packets are delivered to
all links where there are listeners interested in such packets.
ＭＬＤは非対称プロトコルです；マルチキャストアドレスの受信者（すなわ
ち、マルチキャストパケットを受信するホストあるいはルータ）とマルチキャ
ストルータに別の行動を指定します。ＭＬＤの目的は、それぞれのマルチキャ
ストルータが直接接続されているそれぞれのリンクで、どのマルチキャスト
アドレスとどのソースアドレスに受信者がいあるかを学ぶことができるよう
にすることです。ＭＬＤによって集められた情報は、マルチキャストパケッ
トを受信者がいるすべてのリンクに配達することを保証するために、ルータ
の使用するマルチキャストルーティングプロトコルに供給されます。
Multicast routers only need to know that *at least one* node on an
attached link is listening to packets for a particular multicast
address, from a particular source; a multicast router is not required
to *individually* keep track of the interests of each neighboring
node. (Nevertheless, see Appendix A2 item 1 for discussion.)
マルチキャストルータは接続するリンク上で、特定マルチキャストアドレス
と特定ソースアドレスで、*少なくとも１つ*のノードがパケットを受信して
いる、ということを知る必要があるだけです；マルチキャストルータは
*個々に*それぞれの隣接するノードの受信パケットを記録・追跡するように
要求されません。（にもかかわらず、論議のために付録Ａ２の項目１を見て
ください。）
A multicast router performs the *router part* of the MLDv2 protocol
(described in details in section 7) on each of its directly attached
links. If a multicast router has more than one interface connected
to the same link, it only needs to operate the protocol on one of
those interfaces. The router behavior depends on whether there are
several multicast routers on the same subnet, or not. If that is the
case, a querier election mechanism (described in section 7.6.2) is
used to elect a single multicast router to be in Querier state. This
router is called the Querier. All multicast routers on the subnet
listen to the messages sent by multicast address listeners, and
maintain the same multicast listening information state, so that they
can take over the querier role, should the present Querier fail.
Nevertheless, only the Querier sends periodical or triggered query
messages on the subnet, as described in section 7.1.
マルチキャストルータはその直接接続されているリンクのそれぞれの上で
（７章で細部を記述する）ＭＬＤｖ２プロトコルの*ルータ役*を行います。
もしマルチキャストルータが複数のインタフェースで同じリンクに接続した
なら、そのインタフェースの１つでだけプロトコルを操作する必要がありま
す。ルータ行動は、同じサブネット上に、いくつかのマルチキャストルータ
があるかどうかによります。もしそうなら、（７.６.２章で記述された）問
合者選出メカニズムが一つのマルチキャストルータが問合者状態にいるよう
に使われます。このルータは問合者と呼ばれます。すべてのサブネット上の
マルチキャストルータはマルチキャストアドレス受信者から送られるメッセー
ジを受信し、そして同じマルチキャスト受信情報状態を維持します、それで
もし現在の問合者が失敗したなら、彼らは問合者の役割を引き継ぐことがで
きます。にもかかわらず、問合者はただ周期的であるか、７.１章で記述され
るように、サブネット上に周期的か引き起こされた問合せメッセージだけを
送ります。
A multicast address listener performs the *listener part* of the
MLDv2 protocol (described in details in section 6) on all interfaces
on which multicast reception is supported, even if more than one of
those interfaces are connected to the same link.
マルチキャストアドレス受信者は、たとえインタフェースのいくつかが同じ
リンクに接続していても、マルチキャスト受信がサポートされるすべてのイ
ンタフェース上で（６章で細部で記述された）ＭＬＤｖ２プロトコルの*受
信者の役割*を行います。
2.1. Building Multicast Listening State on Multicast Address Listeners
2.1. マルチキャストアドレス受信者にマルチキャスト受信状態を作ること
Upper-layer protocols and applications that run on a multicast
address listener node use specific service interface calls (described
in section 3) to ask the IP layer to enable or disable reception of
packets sent to specific multicast addresses. The node keeps
Multicast Address Listening state for each socket on which the
service interface calls have been invoked (section 4.1). In addition
to this per-socket multicast listening state, a node must also
maintain or compute multicast listening state for each of its
interfaces (section 4.2). Conceptually, that state consists of a set
of records, with each record containing an IPv6 multicast address, a
filter mode, and a source list. The filter mode may be either
INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to
the specified multicast address is enabled *only* from the source
addresses listed in the source list. In EXCLUDE mode, reception of
packets sent to the given multicast address is enabled from all
source addresses *except* those listed in the source list.
マルチキャストアドレス受信者ノード上で走る上位レイヤプロトコルとアプ
リケーションが特定のマルチキャストアドレスに送ったパケットの受信を可
能にするかどうかＩＰレイヤに尋ねる（３章で記述された）特定のサービス
インタフェース呼び出しを使います。ノードはサービスインタフェース呼び
出しがされたそれぞれのソケットのためにマルチキャストアドレス受信状態
を維持します（４.１章）。このソケット毎のマルチキャスト受信状態に加え
て、ノードがインターフェース毎にマルチキャスト受信状態を維持するか計
算しなければなりません。概念的に、この状態は、それぞれのレコードがＩ
Ｐｖ６マルチキャストアドレスとフィルタモードとソースリストを含んでい
る、レコード集合から成り立ちます。フィルタモードはINCLUDEかEXCLUDEか
もしれません。INCLUDEモードで、指定されたマルチキャストアドレスに送ら
れたパケットの受信は、ソースリストでリストアップされたソースアドレス
から*のみ*可能です。EXCLUDEモードで、所定のマルチキャストアドレスに送
られたパケットの受信は、ソースリストでリストアップされたソースアドレ
ス以外のソースアドレスから*のみ*可能です。
At most one record per multicast address exists for a given
interface. This per-interface state is derived from the per-socket
state, but may differ from it when different sockets have differing
filter modes and/or source lists for the same multicast address and
interface. After a multicast packet has been accepted from an
interface by the IP layer, its subsequent delivery to the application
connected to a particular socket depends on the multicast listening
state of that socket (and possibly also on other conditions, such as
what transport-layer port the socket is bound to). Note that MLDv2
messages are not subject to source filtering and must always be
processed by hosts and routers.
特定のインタフェースで、マルチキャストアドレス毎に最大１つのレコード
が存在します。このインターフェース毎の状態はソケット毎状態から得られ
ますが、異なったソケットが同じマルチキャストアドレスとインタフェース
で異なるフィルタモードやソースリストを持っている時は違うかもしれませ
ん。ＩＰレイヤでインタフェースからマルチキャストパケットを受信した後、
そのソケットに接続したアプリケーションへの次の配達はそのソケットのマ
ルチキャスト受信状態（そして多分ソケットがどの輸送レイヤポートと接続
しているかなど他の条件）に依存します。ＭＬＤｖ２メッセージがフィルタ
ソースの適用を受けず、そして常にホストとルータによって処理されなくて
はならないことに注意を払ってください。
2.2. Exchanging Messages between the Querier and the Listening Nodes
2.2. 問合者と受信者ノード間のメッセージ交換
There are three types of MLDv2 query messages: General Queries,
Multicast Address Specific Queries, and Multicast Address and Source
Specific Queries. The Querier periodically sends General Queries, to
learn multicast address listener information from an attached link.
These queries are used to build and refresh the Multicast Address
Listener state inside all multicast routers on the link.
ＭＬＤｖ２問合せメッセージに３つのタイプがあります：一般的問合せと、
マルチキャストアドレス特定問合せと、マルチキャストアドレスとソース特
定問合せ。問合者は接続リンクからマルチキャストアドレス受信者情報を学
ぶために、周期的に一般問合せを送ります。これらの問合せはリンク上のす
べてのマルチキャストルータのマルチキャストアドレス受信者状態の生成と
更新に使われます。
Nodes respond to these queries by reporting their per-interface
Multicast Address Listening state, through Current State Report
messages sent to a specific multicast address all MLDv2 routers on
the link listen to. On the other hand, if the listening state of a
node changes, the node immediately reports these changes through a
State Change Report message. The State Change Report contains either
Filter Mode Change records, Source List Change records, or records of
both types. A detailed description of the report messages is
presented in section 5.2.12.
ノードは、すべてのリンク上のＭＬＤｖ２ルータが聞く特定のマルチキャス
トアドレスに送られた現在状態報告メッセージを通して、インターフェース
毎のマルチキャストアドレス受信状態を報告することによって、これらの問
合せに返答します。他方、もしノードの受信状態が変化するなら、ノード状
態変更報告メッセージを通してすぐにこれらの変更を報告します。状態変更
報告はフィルタモード変更記録、ソースリスト変更記録、あるいは両方の種
類の記録を含んでいます。報告メッセージの詳細な記述が５.２.１２章で提
出されます。
Both router and listener state changes are mainly triggered by the
expiration of a specific timer, or the reception of an MLD message
(listener state change can be also triggered by the invocation of a
service interface call). Therefore, to enhance protocol robustness,
in spite of the possible unreliability of message exchanges, messages
are retransmitted several times. Furthermore, timers are set so as
to take into account the possible message losses, and to wait for
retransmissions.
ルータと受信者の状態の変更の両方が主に特定のタイマの期限切れや、ＭＬ
Ｄメッセージの受信によって引き起こされます（受信状態変化が同じくサー
ビスインタフェース呼出しによって引き起こされえます）。従って、プロト
コル強靭性を確保するために、メッセージ交換の可能な頼りなさに関係なく、
メッセージが数回再送されます。さらに、タイマはメッセージ損失の可能性
と再送待ちを考慮して定められています。
Periodical General Queries and Current State Reports do not apply
this rule, in order not to overload the link; it is assumed that in
general these messages do not generate state changes, their main
purpose being to refresh existing state. Thus, even if one such
message is lost, the corresponding state will be refreshed during the
next reporting period.
リンクに負荷をかけ過ぎないために定期的な一般問合せと現在状態報告はこ
の規則を適用しません；一般にこれらのメッセージの主な目的は既存の状態
の更新で、状態変更を起こさないと想定されます。それで、たとえそのよう
なメッセージが１つ失われるとしても、対応する状態は次の報告時期に更新
されるでしょう。
As opposed to Current State Reports, State Change Reports are
retransmitted several times, in order to avoid them being missed by
one or more multicast routers. The number of retransmissions depends
on the so-called Robustness Variable. This variable allows tuning
the protocol according to the expected packet loss on a link. If a
link is expected to be lossy (e.g., a wireless connection), the value
of the Robustness Variable may be increased. MLD is robust to
[Robustness Variable]-1 packet losses. This document recommends a
default value of 2 for the Robustness Variable (see section 9.1).
現在状態報告に対して、状態変更報告は、マルチキャストルータの誤りを避
けるために、数回再送されます。再送回数はいわゆる信頼性変数に頼ります。
この変数はリンク上で予想されるパケット損失に従ってプロトコル調整を許
します。もしリンクの損失が多そうなら（例えば、無線の接続）、信頼性変
数の値は増やされるかもしれません。ＭＬＤは［信頼性変数］-1パケットの
損失に対して強靭です。この文書は信頼性変数のデフォルト値として２を推
薦します（９.１章参照）。
If more changes to the same per-interface state entry occur before
all the retransmissions of the State Change Report for the first
change have been completed, each additional change triggers the
immediate transmission of a new State Change Report. Section 6.1
shows how the content of this new report is computed. Retransmissions
of the new State Change Report will be scheduled as well, in order to
ensure that each instance of state change is transmitted at least
[Robustness Variable] times.
もし最初の変更の状態変更報告のすべての再送が完了する前に、同じインター
フェース状態項目に対する変更が起るなら、それぞれの追加の変更が新しい
状態変更報告の即時送信を起こします。６.１章はどのようにこの新しい報告
の内容が計算されるか示します。新しい状態変更報告の再送は、それぞれの
状態変化が最少の［信頼性変数］回数伝達されることを保証するように、ス
ケジュールされるでしょう。
If a node on a link expresses, through a State Change Report, its
desire to no longer listen to a particular multicast address (or
source), the Querier must query for other listeners of the multicast
address (or source) before deleting the multicast address (or source)
from its Multicast Address Listener state and stopping the
corresponding traffic. Thus, the Querier sends a Multicast Address
もしリンク上のノードが、状態変更報告を通して、もう特定のマルチキャス
トアドレス（あるいはソース）を聞かない事を示すなら、問合者はそのマル
チキャストアドレス受信者状態からマルチキャストアドレス（あるいはソー
ス）を削除して対応するトラフィックを止める前に、マルチキャストアドレ
ス（あるいはソース）の他の受信者に質問しなくてはなりません。
Specific Query to verify whether there are nodes still listening to a
specified multicast address or not. Similarly, the Querier sends a
Multicast Address and Source Specific Query to verify whether, for a
specified multicast address, there are nodes still listening to a
specific set of sources, or not. Section 5.1.13 describes each query
in more detail.
それで、問合者は指定されたマルチキャストアドレスを聞いているノードが
まだいるかどうか確かめるためにマルチキャストアドレス特定問合せを送り
ます。同様に、問合者は、特定のソースの指定されたマルチキャストアドレ
スを聞いているノードがまだいるかどうか確かめるためにマルチキャストア
ドレスとソース特定問合せを送ります。５.１.１３章がより多くの細部でそ
れぞれの質問を記述します。
Both Multicast Address Specific Queries and Multicast Address and
Source Specific Queries are only sent in response to State Change
Reports, never in response to Current State Reports. This
distinction between the two types of reports is needed to avoid the
router treating all Multicast Listener Reports as potential changes
in state. By doing so, the fast leave mechanism of MLDv2, described
in more detail in section 2.2, might not be effective if a State
Change Report is lost, and only the following Current State Report is
received by the router. Nevertheless, it avoids an increased
processing at the router and it reduces the MLD traffic on the link.
More details on the necessity of distinguishing between the two
report types can be found in Appendix A1.
マルチキャストアドレス特定問合せとマルチキャストアドレスとソース特定
問合せの両方は、現在状態報告に応えてではなく、状態変更報告に応えて送
られるだけです。この報告の２つの種類の間の区別は、ルータがすべてのマ
ルチキャスト受信者報告を状態変更の可能性と扱うのを避けるために必要と
されます。この場合、２.２章で細部を記述するＭＬＤｖ２の急速離脱メカニ
ズムは、もし状態変更報告を失い現在状態報告 だけがルータに受信された際
に、効率的ではないかもしれません。にもかかわらず、これはルータの処理
の増加を避けとリンク上のＭＬＤトラヒックを減らします。２つの報告種別
を区別する必要のより詳細は付録Ａ１にあります。
Nodes respond to the above queries through Current State Reports,
that contain their per-interface Multicast Address Listening state
only for the multicast addresses (or sources) being queried.
ノードは上記の問合せに対し、インターフェース毎の要求されたマルチキャ
ストアドレス（あるいはソース）のマルチキャストアドレス受信状態だけを、
現在状態報告で返答します。
As stated earlier, in order to ensure protocol robustness, all the
queries, except the periodical General Queries, are retransmitted
several times within a given time interval. The number of
retransmissions depends on the Robustness Variable. If, while
scheduling new queries, there are pending queries to be retransmitted
for the same multicast address, the new queries and the pending
queries have to be merged. In addition, host reports received for a
multicast address with pending queries may affect the contents of
those queries. The process of building and maintaining the state of
pending queries is presented in section 7.6.3.
前に述るように、プロトコル強靭性を保証するために、すべての問合せは、
周期一般問合せ以外、所定の時間間隔内で数回再送されます。再送回数は信
頼性変数に頼ります。もし新しい問合せのスケジュールをする際に、同じマ
ルチキャストアドレスの再送待ちの問合せがあるなら、新しい問合せと再送
待ちの問合せは合併されなければなりません。加えて、待ち状態の問合せの
マルチキャストアドレスに対するホスト報告の受信は、これらの問合せの中
身に影響を与えるかもしれません。待ち状態の質問の状態の生成と維持の処
理は７.６.３章にあります。
Protocol robustness is also enhanced through the use of the S flag
(Suppress Router-Side Processing). As described above, when a
Multicast Address Specific or a Multicast Address and Source Specific
Query is sent by the Querier, a number of retransmissions of the
query are scheduled. In the original (first) query the S flag is
clear. When the Querier sends this query, it lowers the timers for
the concerned multicast address (or source) to a given value;
similarly, any non-querier multicast router that receives the query
lowers its timers in the same way. Nevertheless, while waiting for
the next scheduled queries to be sent, the Querier may receive a
report that updates the timers. The scheduled queries still have to
be sent, in order to ensure that a non-querier router keeps its state
synchronized with the current Querier (the non-querier router might
have missed the first query). Nevertheless, the timers should not be
lowered again, as a valid answer was already received. Therefore, in
subsequent queries the Querier sets the S flag.
プロトコルロ強靭性がＳフラグ（ルータ側処理抑制）の使用を通して拡張さ
れています。上記のように、問合者がマルチキャストアドレス特定あるいは
マルチキャストアドレスとソース特定問合せを送る時、多くの質問の再送が
予定されます。元（最初）の質問でＳフラグは明確です。問合者がこの問合
せを送る時、そのマルチキャストアドレス（あるいはソース）に対するタイ
マを特定の値に設定します；同様に、問合せを受け取る非問合者のマルチキャ
ストルータもそのタイマを設定します。次の質問の送信時刻を待つ間に、問
合者はタイマを更新する報告を受け取るかもしれません。予定された問合せ
は非問合者ルータの状態が現在の問合者（非問合者のルータが最初の問合せ
を受取れなかったかもしれない）と同期する状態になることを保証するため
に、送られなければなりません。にもかかわらず、タイマは正当な応答を受
信しているので、再び設定するべきではありません。それ故に、次の質問で
問合者はＳフラグを設定します。
2.3. Building Multicast Address Listener State on Multicast Routers
2.3. マルチキャストルータ上のマルチキャストアドレス受信状態の作成
Multicast routers that implement MLDv2 (whether they are in Querier
state or not) keep state per multicast address per attached link.
This multicast address listener state consists of a Filter Mode, a
Filter Timer, and a Source List, with a timer associated to each
source from the list. The Filter Mode is used to summarize the total
listening state of a multicast address to a minimum set, such that
all nodes' listening states are respected. The Filter Mode may
change in response to the reception of particular types of report
messages, or when certain timer conditions occur.
（問合者状態にいるか否かにかかわらず）ＭＬＤｖ２を実行するマルチキャ
ストルータが接続されているリンク毎にマルチキャストアドレス毎に状態を
維持します。このマルチキャストアドレス受信状態は、フィルタモード、
フィルタタイマ、ソースリスト、リストのそれぞれのソースに関連づけられ
たタイマから成り立ちます。フィルタモード (Filter Mode) は、すべての
ノードの受信状態を考慮した、マルチキャストアドレスの全受信状態をまと
めて最小セットを作るために使われます。フィルタモードは、特定のタイプ
の報告メッセージの受信やあるタイマー状態に応えて、変化するかもしれま
せん。
A router is in INCLUDE mode for a specific multicast address on a
given interface if all the listeners on the link interested in that
address are in INCLUDE mode. The router state is represented through
the notation INCLUDE (A), where A is a list of sources, called the
"Include List". The Include List is the set of sources that one or
more listeners on the link have requested to receive. All the
sources from the Include List will be forwarded by the router. Any
other source that is not in the Include List will be blocked by the
router.
ルータは、特定のインタフェースの特定のマルチキャストアドレスで、リン
ク上のそのアドレスの全ての受信者がINCLUDEモードなら、INCLUDEモードで
す。ルータ状態は、Ａが「組み込みリスト」と呼ばれるソースリストであれ
ば、INCLUDE(A)と表記します。組み込みリストはリンク上の受信者が受信を
頼んだソースのセットです。組み込みリストのソースからのはルータによっ
て転送されるでしょう。組み込みリストにないソースからのはルータで止め
られるでしょう。
A source can be added to the current Include List if a listener in
INCLUDE mode sends a Current State or a State Change Report that
includes that source. Each source from the Include List is
associated with a source timer that is updated whenever a listener in
INCLUDE mode sends a report that confirms its interest in that
specific source. If the timer of a source from the Include List
expires, the source is deleted from the Include List.
もしINCLUDEモードの受信者が、ソースを含む現在状態か状態変更報告を送る
なら、現在の組込リストにソースが追加できます。それぞれの組込リストか
らのソースは、INCLUDEモードの受信者が特定のソースに興味を持つと報告を
送信する場合更新される、ソースタイマと結び付けられます。もし組込リス
トからのソースのタイマ期限が切れるなら、ソースは組込リストから削除さ
れます。
Besides this "soft leave" mechanism, there is also a "fast leave"
scheme in MLDv2; it is also based on the use of source timers. When
a node in INCLUDE mode expresses its desire to stop listening to a
specific source, all the multicast routers on the link lower their
timers for that source to a given value. The Querier then sends a
Multicast Address and Source Specific Query, to verify whether there
are other listeners for that source on the link, or not. If a report
that includes this source is received before the timer expiration,
all the multicast routers on the link update the source timer. If
not, the source is deleted from the Include List. The handling of
the Include List, according to the received reports, is detailed in
Tables 7.4.1 and 7.4.2.
この「ソフト離脱」メカニズムのほかに、ＭＬＤｖ２「速い離脱」案があり
ます；これもソースタイマの使用に基づいています。INCLUDEモードのノード
が特定のソースからの受信をやめる事を示す時、リンク上のすべてのマルチ
キャストルータはそのソースのタイマに特定の値を設定します。問合者は、
リンク上にそのソースの他の聞き手がいるかどうか確かめるために、マルチ
キャストアドレスとソース特定問合せを送ります。もしこのソースを含む報
告がタイマ期限前に受け取られるなら、リンク上のすべてのマルチキャスト
ルータはソースタイマを更新します。もしそうでなければ、ソースは組込リ
ストから削除されます。組込リストの取り扱いは、報告の受信に関連して、
表７.４.１と表７.４.２で詳述されます。
A router is in EXCLUDE mode for a specific multicast address on a
given interface if there is at least one listener in EXCLUDE mode for
that address on the link. When the first report is received from
such a listener, the router sets the Filter Timer that corresponds to
that address. This timer is reset each time an EXCLUDE mode listener
confirms its listening state through a Current State Report. The
timer is also updated when a listener, formerly in INCLUDE mode,
announces its filter mode change through a State Change Report
message. If the Filter Timer expires, it means that there are no
more listeners in EXCLUDE mode on the link. In this case, the router
switches back to INCLUDE mode for that multicast address.
もしリンク上でそのアドレスのために少なくとも１人のEXCLUDEモードの受信
者がいるなら、ルータがそのインタフェース上のそのマルチキャストアドレ
スに対しEXCLUDEモードです。最初の報告がこのような受信者から来た時、ルー
タはそのアドレスに対応するフィルタタイマを調整します。このタイマは、
EXCLUDEモード受信者が現在状態報告を通してその受信状態を確証するたびに、
リセットされます。タイマは、以前はINCLUDEモードの受信者が状態変更報告
メッセージを通してフィルタモード変更を示す時も、更新されます。もしフィ
ルタタイマの期限が切れるなら、それはリンクにEXCLUDEモード受信者がいな
いことを意味します。この場合、ルータはそのマルチキャストアドレスのモー
ドをINCLUDEに切り戻します。
When the router is in EXCLUDE mode, the router state is represented
by the notation EXCLUDE (X,Y), where X is called the "Requested List"
and Y is called the "Exclude List". All sources, except those from
the Exclude List, will be forwarded by the router. The Requested
List has no effect on forwarding. Nevertheless, the router has to
maintain the Requested List for two reasons:
ルータがEXCLUDEモードの時、ルータ状態はEXCLUDE(X,Y)で表記されます、こ
こでXは「要求リスト」と呼ばれ、Yは「除外リスト」と呼ばれます。すべて
のソースは、それらが除外リストになければ、ルータによって転送されるで
しょう。要求リストは転送に対する効果を持ちません。にもかかわらず、ルー
タは２つの理由で要求リストを維持しなければなりません：
o To keep track of sources that listeners in INCLUDE mode listen to.
This is necessary to assure a seamless transition of the router to
INCLUDE mode, when there is no listener in EXCLUDE mode left.
This transition should not interrupt the flow of traffic to
listeners in INCLUDE mode for that multicast address. Therefore,
at the time of the transition, the Requested List should contain
the set of sources that nodes in INCLUDE mode have explicitly
requested.
o INCLUDEモードの受信者が受信するソースを記録・追跡するために。これ
は、EXCLUDEモードに受信者がいない時、INCLUDEモードにルータのスムー
ズな移行を保証するために必要です。この移行はそのマルチキャストアド
レスのINCLUDEモード受信者のトラフィックの流れを中断させないべきで
す。それ故に、移行時に、要求リストはINCLUDEモードのノードが明示的
に求めたソースの集合を含んでいるべきです。
When the router switches to INCLUDE mode, the sources in the
Requested List are moved to the Include List, and the Exclude List
is deleted. Before switching, the Requested List can contain an
inexact guess of the sources listeners in INCLUDE mode listen to -
might be too large or too small. These inexactitudes are due to
the fact that the Requested List is also used for fast blocking
purposes, as described below. If such a fast blocking is
required, some sources may be deleted from the Requested List (as
shown in Tables 7.4.1 and 7.4.2) in order to reduce router state.
Nevertheless, in each such case the Filter Timer is updated as
well. Therefore, listeners in INCLUDE mode will have enough time,
before an eventual switching, to reconfirm their interest in the
eliminated source(s), and rebuild the Requested List accordingly.
The protocol ensures that when a switch to INCLUDE mode occurs,
the Requested List will be accurate. Details about the transition
of the router to INCLUDE mode are presented in Appendix A3.
ルータがINCLUDEモードに切り替わる時、要求リストのソースは組込リス
トに動かされ、そして除外リストは削除されます。切り替え前に、要求リ
ストはINCLUDEモードで受信者の受信するソースの不正確な推測を含む事
ができ−大きすぎか、あるいは小すぎかもしれません。これらの不正確さ
は、下記のように、即時停止の目的で使われる事実のためです。もしこの
ような即時停止が必要とされるなら、（表７.４.１と７.４.２に示される
ように）あるソースがルータ状態を減らすための要求リストから削除され
るかもしれません。にもかかわらず、このような場合フィルタタイマが更
新されます。それ故に、INCLUDEモードの受信者が、最終切替前に、削除
されたソースに対しての受信要求を再確認し、適切な要求リストを再建す
る十分な時間を持つでしょう。プロトコルはINCLUDEモードへの切替が起
こる時、要求リストが正確であろうことを保証します。ルータのINCLUDE
モードへの移行の細部が付録Ａ３で提出されます。
o To allow the fast blocking of previously unblocked sources. If
the router receives a report that contains such a request, the
concerned sources are added to the Requested List. Their timers
are set to a given small value, and a Multicast Address and Source
Specific Query is sent by the Querier, to check whether there are
nodes on the link still interested in those sources, or not. If
no node announces its interest in receiving those specific source,
the timers of those sources expire. Then, the sources are moved
from the Requested List to the Exclude List. From then on, the
sources will be blocked by the router.
o 前に届いていたソースをすばやく止めるのを許すために。もしルータがこ
のような要請を含む報告を受け取るなら、問題のソースは要求リストに加
えられます。それらのタイマは所定の小さい値に設定されます、そしてま
だそれらのソースを受信するリンク上のノードがあるかどうか調べるため
に、マルチキャストアドレスとソース特定問合せが問合者によって行われ
ます。もしノードがその、それらを受け取るというノードがないなら、そ
れらのソースのタイマは期限が切れます。それから、ソースは要求リスト
から除外リストに動かされます。その時から、ソースはルータによって止
められます。
The handling of the EXCLUDE mode router state, according to the
received reports, is detailed in Tables 7.4.1 and 7.4.2.
EXCLUDEモードルータ状態の取り扱いは、受信報告により、表７.４.１と
７.４.２で詳述されます。
Both the MLDv2 router and listener behaviors described in this
document were defined to ensure backward interoperability with MLDv1
hosts and routers. Interoperability issues are detailed in section
8.
ＭＬＤｖ２ルータとこの文書で記述された受信者の行動の両方がＭＬＤｖ１
ホストとルータと後方互換性を保証するために定義されました。互換性問題
が８章で詳述されます。
3. The Service Interface for Requesting IP Multicast Reception
3. ＩＰマルチキャスト受信を求めるサービスインタフェース
Within an IP system, there is (at least conceptually) a service
interface used by upper-layer protocols or application programs to
ask the IP layer to enable or disable reception of packets sent to
specific IP multicast addresses. In order to take full advantage of
the capabilities of MLDv2, a node's IP service interface must support
the following operation:
ＩＰシステムの中で、上位レイヤプロトコルあるいはアプリケーションプロ
グラムによって使われる、特定のＩＰマルチキャストアドレス宛のパケット
の受信が可能か否かをＩＰレイヤを尋ねるたサービスインタフェースが（少
なくとも概念的に）あります。ＭＬＤｖ２の能力の完全な利用をするために、
ノードのＩＰサービスインタフェースは次のオペレーションをサポートしな
くてはなりません：
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
filter mode, source list )
where:
o "socket" is an implementation-specific parameter used to
distinguish among different requesting entities (e.g., programs,
processes) within the node; the socket parameter of BSD Unix
system calls is a specific example.
o 「ソケット」はノードの中で異なる要求者（例えば、プログラム、プロセ
ス）を識別するために使われる実装固有のパラメータです；ＢＳＤ ＵＮ
ＩＸシステム呼出しのソケットパラメータは個々の事例です。
o "interface" is a local identifier of the network interface on
which reception of the specified multicast address is to be
enabled or disabled. Interfaces may be physical (e.g., an
Ethernet interface) or virtual (e.g., the endpoint of a Frame
Relay virtual circuit or an IP-in-IP "tunnel"). An implementation
may allow a special "unspecified" value to be passed as the
interface parameter, in which case the request would apply to the
"primary" or "default" interface of the node (perhaps established
by system configuration). If reception of the same multicast
address is desired on more than one interface, IPv6MulticastListen
is invoked separately for each desired interface.
o 「インターフェース」はネットワークインタフェースのローカルな識別子
で、その上で指定されたマルチキャストアドレスの受信が使用可能である
か使用不能になるはずです。インタフェースが物理的（例えば、イーサネッ
トインタフェース）かもしれないし、仮想（例えば、フレームリレー仮想
回路の終端あるいはＩＰ上のＩＰトンネル」）であるかもしれません。実
装が特別な「特定されていない」値をインタフェースパラメータとして渡
されることを許すかもしれず、このの場合要求は（多分システム設定で確
立された）ノードの「主」あるいは「デフォルト」インタフェースに当て
はまるでしょう。もし同じマルチキャストアドレスの受信が１つ以上のイ
ンタフェースで望まれるなら、 IPv6MulticastListenがそれぞれの望まし
いインタフェースのために別々に呼び出されます。
o "IPv6 multicast address" is the multicast address to which the
request pertains. If reception of more than one multicast address
on a given interface is desired, IPv6MulticastListen is invoked
separately for each desired address.
o 「ＩＰｖ６マルチキャストアドレス」は要請に関係するマルチキャストア
ドレスです。もし指定のインタフェース上で１つ以上のマルチキャストア
ドレスの受信を望むなら、それぞれのアドレスに対して
IPv6MulticastListenを呼び出します。
o "filter mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode,
reception of packets sent to the specified multicast address is
requested *only* from the source addresses listed in the source
list parameter. In EXCLUDE mode, reception of packets sent to the
given multicast address is requested from all source addresses
*except* those listed in the source list parameter.
o 「フィルタモード」はINCLUDEかEXCLUDEです。INCLUDEモードで、指定さ
れたマルチキャストアドレスに送られた、ソースリストパラメータで指定
されたソースアドレスからのパケット*のみ*受信します。EXCLUDEモード
で、指定されたマルチキャストアドレスに送られた、ソースリストパラメー
タで指定されたソースアドレス*以外*からのパケットを受信します。
o "source list" is an unordered list of zero or more unicast
addresses from which multicast reception is desired or not
desired, depending on the filter mode. An implementation MAY
impose a limit on the size of source lists. When an operation
causes the source list size limit to be exceeded, the service
interface SHOULD return an error.
o 「ソースリスト」は０個以上の順序なしのユニキャストアドレスのリスト
で、フィルタモードに依存して、マルチキャスト受信を望むか望まないか
を指定します。実装がソースリストの大きさに限度を課すかもしれません
(MAY)。ソースリストの大きさの限界を越えるオペレーションは、サービ
スインタフェースエラーを返すべきです(SHOULD)。
For a given combination of socket, interface, and IPv6 multicast
address, only a single filter mode and source list can be in effect
at any one time. Nevertheless, either the filter mode or the source
list, or both, may be changed by subsequent IPv6MulticastListen
requests that specify the same socket, interface, and IPv6 multicast
address. Each subsequent request completely replaces any earlier
request for the given socket, interface, and multicast address.
あるソケットとインタフェースとＩＰｖ６マルチキャストアドレスの組合せ
に対して、同時に１つのフィルタモードとソースリストだけが実施され得ま
す。にもかかわらず、フィルタモードあるいはソースリストあるいは両方が、
同じソケットとインタフェースとＩＰｖ６マルチキャストアドレスを指定す
る次のIPv6MulticastListen要請によって変えられるかもしれません。それぞ
れの次の要請は、ソケットとインタフェースとマルチキャストアドレスに対
する、以前の要請を完全に置き換えます。
The MLDv1 protocol did not support source filters, and had a simpler
service interface; it consisted of Start Listening and Stop Listening
operations to enable and disable listening to a given multicast
address (from *all* sources) on a given interface. The equivalent
operations in the new service interface are as follows:
ＭＬＤｖ１プロトコルはソースフィルタをサポートせず、より単純なサービ
スインタフェースを持ちました；これは指定インターフェースの（*全ての*
ソースからの）指定のマルチキャストアドレスの受信の軌道と停止のための
受信開始と受信終了オペレーションからなります。新しいサービスインタ
フェースでの等価なオペレーションは次の通りです：
The Start Listening operation is equivalent to:
受信開始オペレーションが次と等価です：
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
EXCLUDE, {} )
and the Stop Listening operation is equivalent to:
そして受信終了オペレーションが次と等価です：
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
INCLUDE, {} )
where {} is an empty source list.
ここで{}は空のソースリストです。
An example of an API that provides the capabilities outlined in this
service interface is given in [RFC3678].
このサービスインタフェースで概説された能力を供給するＡＰＩの例が
[RFC3678]で与えられます。
4. Multicast Listening State Maintained by Nodes
4. ノードのマルチキャスト受信状態維持
4.1. Per-Socket State
4.1. ソケット毎状態
For each socket on which IPv6MulticastListen has been invoked, the
node records the desired multicast listening state for that socket.
That state conceptually consists of a set of records of the form:
IPv6MulticastListenが呼出されたそれぞれのソケットで、ノードはソケット
の望ましいマルチキャスト受信状態を記録します。この状態は概念的に下記
の形式のレコードの集合から成り立ちます：
(interface, IPv6 multicast address, filter mode, source list)
The per-socket state evolves in response to each invocation of
IPv6MulticastListen on the socket, as follows:
ソケット毎状態はソケット上のそれぞれのIPv6MulticastListenの実施に応え
て次のように変化します：
o If the requested filter mode is INCLUDE *and* the requested source
list is empty, then the entry that corresponds to the requested
interface and multicast address is deleted, if present. If no
such entry is present, the request has no effect.
o もし指定されたフィルタモードがINCLUDEで*かつ*指定されたソースリス
トが空なら、指定されたインタフェースとマルチキャストアドレスに対応
する項目は、もしあれば、削除されます。もしこのような項目が存在して
いないなら、要求は効果がありません。
o If the requested filter mode is EXCLUDE *or* the requested source
list is non-empty, then the entry that corresponds to the
requested interface and multicast address, if present, is changed
to contain the requested filter mode and source list. If no such
entry is present, a new entry is created, using the parameters
specified in the request.
o もし指定されたフィルタモードがEXCLUDEであるか*あるいは*指定された
ソースリストが空でないなら、指定されたインタフェースとマルチキャス
トアドレスに対応する項目は、もしあれば、指定フィルタモードとソース
リストに変えられます。もしこのようなどの項目が存在していないなら、
新しい項目が、指定されたパラメータを使って、作られます。
4.2. Per-Interface State
4.2. インタフェース毎状態
In addition to the per-socket multicast listening state, a node must
also maintain or compute multicast listening state for each of its
interfaces. That state conceptually consists of a set of records of
the form:
ソケット毎マルチキャスト受信状態のほかに、ノードがそのインタフェース
のそれぞれでマルチキャスト受信状態を維持するか計算しなくてはなりませ
ん。その状態は概念的に次の形式のレコードの集合から成り立ちます：
(IPv6 multicast address, filter mode, source list)
At most one record per multicast address exists for a given
interface. This per-interface state is derived from the per-socket
state, but may differ from it when different sockets have differing
filter modes and/or source lists for the same multicast address and
interface. For example, suppose one application or process invokes
the following operation on socket s1:
特定のインターフェースでマルチキャストアドレス毎にせいぜい１つのレコー
ドが存在します。このインターフェース毎の状態はソケット毎状態から得ら
れます、が、同じマルチキャストアドレスとインタフェースでも異なるソケッ
トでは異なったフィルタモードやソースリストを持つかもしれません。例え
ば、１つのアプリケーションあるいはプロセスがソケットＳ１上で次のオペ
レーションを呼び出すと考えてください：
IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
requesting reception on interface i of packets sent to multicast
address m, *only* if they come from the sources a, b, or c. Suppose
another application or process invokes the following operation on
socket s2:
インターフェースiでのマルチキャストアドレスmへのパケットの、ソースaか
bかcから来た場合*のみ*の、受信要求。他のアプリケーションかプロセスが
ソケットs2上で次のオペレーションを呼び出すと考えてください：
IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
requesting reception on the same interface i of packets sent to the
same multicast address m, *only* if they come from sources b, c, or
d. In order to satisfy the reception requirements of both sockets,
it is necessary for interface i to receive packets sent to m from any
one of the sources a, b, c, or d. Thus, in this example, the
listening state of interface i for multicast address m has filter
mode INCLUDE and source list {a, b, c, d}.
同じインターフェースiでの同じマルチキャストアドレスmへのパケットの、
ソースbかcかdから来た場合*のみ*の、受信要求。両方のソケットの受信必要
条件を満たすために、インターフェースiはmへ送ったパケットでソースaかb
かcかdのパケットの受信が必要です。それで、この例で、インターフェース
iのマルチキャストアドレスmの受信状態は、フィルタモードINCLUDEでソース
リストは{a, b, c, d}です。
After a multicast packet has been accepted from an interface by the
IP layer, its subsequent delivery to the application or process that
listens on a particular socket depends on the multicast listening
state of that socket (and possibly also on other conditions, such as
what transport-layer port the socket is bound to). So, in the above
example, if a packet arrives on interface i, destined to multicast
address m, with source address a, it may be delivered on socket s1
but not on socket s2. Note that MLDv2 messages are not subject to
source filtering and must always be processed by hosts and routers.
マルチキャストパケットがインタフェースからＩＰレイヤに受け入れられた
後、その特定のソケットのマルチキャスト受信状態（そして多分ソケットが
結合する輸送レイヤポートのような、他の条件）に依存して特定のソケット
で受信するアプリケーションかプロセスへ次の配達が行われます。それで、
上記の例で、もし宛先マルチキャストアドレスmでソースアドレスaのパケッ
トがインターフェースiに到着するなら、パケットはソケットs1に配達される
が、s2に配達されないでしょう。ＭＬＤｖ２メッセージがソースフィルタの
適用を受けず、そして常にホストとルータによって処理されなくてはならな
いことに注意してください。
Requiring the filtering of packets based upon a socket's multicast
reception state is a new feature of this service interface. The
previous service interface described no filtering based upon
multicast listening state; rather, a Start Listening operation on a
socket simply caused the node to start to listen to a multicast
address on the given interface; packets sent to that multicast
address could be delivered to all sockets, whether they had started
to listen or not.
ソケットのマルチキャスト受信状態に基づいてパケットをフィルターする要
求は、このサービスインタフェースの新しい機能です。前のサービスインタ
フェースはマルチキャスト受信状態に基づくフィルタを記述しませんでした；
どちらかと言うと、ソケット上の受信開始オペレーションでノードが指定イ
ンタフェース上でマルチキャストアドレス受信を始めました；そのマルチキャ
ストアドレスに送られたパケットは、それらが受信を始めているか否かに関
わらず、すべてのソケットに配達されました。
The general rules for deriving the per-interface state from the per-
socket state are as follows: for each distinct (interface, IPv6
multicast address) pair that appears in any per-socket state, a per-
interface record is created for that multicast address on that
interface. Considering all socket records that contain the same
(interface, IPv6 multicast address) pair,
ソケット毎の状態からインターフェース毎の状態を得るための一般的な規則
は次の通りです：ソケット毎の状態のそれぞれの(interface, IPv6
multicast address)対から、インターフェースのマルチキャストアドレスの
インターフェース毎状態が生成されます。同じ(interface, IPv6 multicast
address)対を含んでいるすべてのソケットレコードを考えます。
o if *any* such record has a filter mode of EXCLUDE, then the filter
mode of the interface record is EXCLUDE, and the source list of
the interface record is the intersection of the source lists of
all socket records in EXCLUDE mode, minus those source addresses
that appear in any socket record in INCLUDE mode. For example, if
the socket records for multicast address m on interface i are:
o EXCLUDEで、インタフェースレコードのソースリストはすべてのEXCLUDE
モードのソケットレコードの共通項から、INCLUDEモードのソケットレコー
ドに現われるそれらのソースアドレスを差し引いたものです。例えば、も
しインタフェースｉの上のマルチキャストアドレスmのソケットレコード
が以下であるなら：
from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3: ( i, m, INCLUDE, {d, e, f} )
then the corresponding interface record on interface i is:
インタフェースｉの対応するインタフェースレコードは以下です：
( m, EXCLUDE, {b, c} )
If a fourth socket is added, such as:
もし以下の４番目のソケットが追加されるなら：
From socket s4: ( i, m, EXCLUDE, {} )
then the interface record becomes:
インタフェースレコードは以下になります：
( m, EXCLUDE, {} )
o if *all* such records have a filter mode of INCLUDE, then the
filter mode of the interface record is INCLUDE, and the source
list of the interface record is the union of the source lists of
all the socket records. For example, if the socket records for
multicast address m on interface i are:
o もし*すべて*のレコードのフィルタモードがINCLUDEなら、インタフェー
スレコードのフィルタモードはINCLUDEで、インタフェースレコードのソー
スリストはすべてのソケットレコードのソースリストの和です。例えば、
もしインタフェースｉの上のマルチキャストアドレスmのソケットレコー
ドが以下であるなら：
from socket s1: ( i, m, INCLUDE, {a, b, c} )
from socket s2: ( i, m, INCLUDE, {b, c, d} )
from socket s3: ( i, m, INCLUDE, {e, f} )
then the corresponding interface record on interface i is:
インタフェースｉの対応するインタフェースレコードは以下です：
( m, INCLUDE, {a, b, c, d, e, f} )
An implementation MUST NOT use an EXCLUDE interface record for a
multicast address if all sockets for this multicast address are in
INCLUDE state. If system resource limits are reached when a per-
interface state source list is calculated, an error MUST be returned
to the application which requested the operation.
実装は、もしあるマルチキャストアドレスのすべてのソケットがINCLUDE状態
なら、そのマルチキャストアドレスでEXCLUDEインタフェースレコードを使っ
てはなりません(MUST NOT)。もし、インタフェース毎状態ソースリストの計
算で、システム資源の限界に達した場合、オペレーションを求めたアプリケー
ションにエラーを返されなくてはなりません(MUST)。
The above rules for deriving the per-interface state are
(re)evaluated whenever an IPv6MulticastListen invocation modifies the
per-socket state by adding, deleting, or modifying a per-socket state
record. Note that a change of the per-socket state does not
necessarily result in a change of the per-interface state.
インタフェース毎状態を得るための上記の規則は、IPv6MulticastListen呼出
がソケット毎状態レコードの追加や削除や修正でソケット毎状態を変更する
毎に（再）評価されます。ソケット毎状態の変更が必ずしもインターフェー
ス毎状態の変更をもたらさないことに注意してください。
5. Message Formats
5. メッセージフォーマット
MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a
subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6
packets by a preceding Next Header value of 58. All MLDv2 messages
described in this document MUST be sent with a link-local IPv6 Source
Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
[RFC2711] in a Hop-by-Hop Options header. (The Router Alert option
is necessary to cause routers to examine MLDv2 messages sent to IPv6
multicast addresses in which the routers themselves have no
interest.) MLDv2 Reports can be sent with the source address set to
the unspecified address [RFC3513], if a valid link-local IPv6 source
address has not been acquired yet for the sending interface. (See
section 5.2.13. for details.)
ＭＬＤｖ２はＩＣＭＰｖ６の副プロトコルです、すなわち、ＭＬＤｖ２メッ
セージタイプはＩＣＭＰｖ６メッセージの部分集合です、そしてＭＬＤｖ２
メッセージが前にある次のヘッダ値の５８によって他のＩＰｖ６パケットと
区別されます。すべてのこの文書で記述されたＭＬＤｖ２メッセージは、リ
ンクローカルＩＰｖ６ソースアドレスと、ＩＰｖ６ホップ限界が１と、ホッ
プ毎オプションヘッダのＩＰｖ６ルータ警告オプション[RFC2711]で送られな
くてはなりません。（ルータ警告オプションは、ルータ自身が受信しないＩ
Ｐｖ６マルチキャストアドレスに送られたＭＬＤｖ２メッセージをルータに
調べさせるために必要です。）もし送信インタフェースのためにまだ正当な
リンクローカルＩＰｖ６ソースアドレスが獲得されていなかったなら、特定
されていないアドレス[RFC3513]のソースアドレスでＭＬＤｖ２報告を送るこ
とができます。（詳細は５.２.１３章を見てください。）
There are two MLD message types of concern to the MLDv2 protocol
described in this document:
この文書に記述されたＭＬＤｖ２プロトコルに関する２つのＭＬＤメッセー
ジ種別があります：
o Multicast Listener Query (Type = decimal 130)
o マルチキャスト受信者問合（種別＝十進数１３０）。
o Version 2 Multicast Listener Report (Type = decimal 143). See
section 11 for IANA considerations.
o ２版マルチキャスト受信者報告（種別＝十進数１４３）。１１章のＩＡＮ
Ａ考慮を見てください。
To assure the interoperability with nodes that implement MLDv1 (see
section 8), an implementation of MLDv2 must also support the
following two message types:
ＭＬＤｖ１を実行するノードとの互換性を保証するために（８章参照）、Ｍ
ＬＤｖ２実装が次の２つのメッセージ種別をサポートしなくてはなりません：
o Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710]
o １版マルチキャスト受信者幇助区（種別＝十進数１３１）[RFC2710]。
o Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710]
o １版マルチキャスト受信終了（種別＝十進数１３２）[RFC2710]。
Unrecognized message types MUST be silently ignored. Other message
types may be used by newer versions or extensions of MLD, by
multicast routing protocols, or for other uses.
認識できないメッセージ種別は静かに無視されなくてはなりません(MUST)。
他のメッセージ種別がＭＬＤの新しい版あるいは拡張や、マルチキャストルー
ティングプロトコルや、あるいは他の使用のために使われるかもしれません。
In this document, unless otherwise qualified, the capitalized words
"Query" and "Report" refer to MLD Multicast Listener Queries and MLD
Version 2 Multicast Listener Reports, respectively.
この文書で、特に記述がなければそれぞれ、大文字で始まる用語「問合せ」
と「報告」はＭＬＤマルチキャスト受信者問合と、ＭＬＤ２版マルチキャス
ト受信報告の事です。
5.1. Multicast Listener Query Message
5.1. マルチキャスト受信者問合メッセージ
Multicast Listener Queries are sent by multicast routers in Querier
State to query the multicast listening state of neighboring
interfaces. Queries 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 = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1. Code
5.1.1. コード
Initialized to zero by the sender; ignored by receivers.
送信者はゼロで初期化；受信者は無視。
5.1.2. Checksum
5.1.2. チェックサム
The standard ICMPv6 checksum; it covers the entire MLDv2 message,
plus a "pseudo-header" of IPv6 header fields [RFC2463]. For
computing the checksum, the Checksum field is set to zero. When a
packet is received, the checksum MUST be verified before processing
it.
標準的なＩＣＭＰｖ６チェックサム；これは全部のＭＬＤｖ２メッセージと
ＩＰｖ６ヘッダーフィールドの「疑似ヘッダ」[RFC2463]をカバーします。
チェックサムを計算することに対して、チェクサムフィールドはゼロに設定
されます。パケットを受信する時、チェックサムは処理をする前に検証され
なくてはなりません(MUST)。
5.1.3. Maximum Response Code
5.1.3. 最大応答コード
The Maximum Response Code field specifies the maximum time allowed
before sending a responding Report. The actual time allowed, called
the Maximum Response Delay, is represented in units of milliseconds,
and is derived from the Maximum Response Code as follows:
最大応答コードフィールドは報告を送信する前に許された最大時間を指定し
ます。最大応答遅延と呼ばれる、許された実際の時間は、ミリ秒単位で表さ
れ、そして次のように最大応答コードから得られます：
If Maximum Response Code < 32768,
Maximum Response Delay = Maximum Response Code
もし最大応答コード＜３２７６８であるなら、。
最大応答遅延＝最大応答コードです。
If Maximum Response Code >=32768, Maximum Response Code represents a
floating-point value as follows:
もし最大応答コード≧３２７６８なら、最大応答コードは以下の浮動小数点
値を示します：
0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Response Delay = (mant | 0x1000) << (exp+3)
Small values of Maximum Response Delay allow MLDv2 routers to tune
the "leave latency" (the time between the moment the last node on a
link ceases to listen to a specific multicast address and the moment
the routing protocol is notified that there are no more listeners for
that address). Larger values, especially in the exponential range,
allow the tuning of the burstiness of MLD traffic on a link.
最大応答遅延の小さい値はＭＬＤｖ２ルータが「離脱遅延」（リンク上の最
後のノードが特定のマルチキャストアドレスを聞くことをやめる瞬間と、ルー
ティングプロトコルがそのアドレスの受信者がいないと知るまでの間の時間）
を調整することを許します。特に指数の範囲の、より大きい価は、リンク上
のＭＬＤトラフィックの輻輳調整を許します。
5.1.4. Reserved
5.1.4. 予約
Initialized to zero by the sender; ignored by receivers.
送信者はゼロで初期化；受信者は無視。
5.1.5. Multicast Address
5.1.5. マルチキャストアドレス
For a General Query, the Multicast Address field is set to zero. For
a Multicast Address Specific Query or Multicast Address and Source
Specific Query, it is set to the multicast address being queried (see
section 5.1.10, below).
一般問合せで、マルチキャストアドレスフィールドはゼロが設定されます。
マルチキャストアドレス特定問合せあるいはマルチキャストアドレスとソー
ス特定問合せで、これは質問するマルチキャストアドレスが設定されます
（下記５.１.１０章参照）。
5.1.7. S Flag (Suppress Router-Side Processing)
5.1.7. Ｓフラグ（ルータ側処理抑制）
When set to one, the S Flag indicates to any receiving multicast
routers that they have to suppress the normal timer updates they
perform upon hearing a Query. Nevertheless, it does not suppress the
querier election or the normal "host-side" processing of a Query that
a router may be required to perform as a consequence of itself being
a multicast listener.
１が設定される時、Ｓフラグは受信マルチキャストルータが問合せを受けた
時の通常のタイマ更新を抑制する事を意味します。にもかかわらず、これは
問合者選出や、マルチキャスト受信者自身として実行を要求されるルータで
の問合せの通常の「ホスト側」処理を抑制しません。
5.1.8. QRV (Querier's Robustness Variable)
5.1.8. ＱＲＶ（問合者信頼性変数）
If non-zero, the QRV field contains the [Robustness Variable] value
used by the Querier. If the Querier's [Robustness Variable] exceeds
7 (the maximum value of the QRV field), the QRV field is set to zero.
もしゼロ以外であるなら、ＱＲＶフィールドは問合者によって使われた［信
頼性変数］値を含んでいます。もし問合者の［信頼性変数］が７（ＱＲＶ
フィールドの最大値）を越えるなら、 QRV フィールドはゼロにセットされ
ます。
Routers adopt the QRV value from the most recently received Query as
their own [Robustness Variable] value, unless that most recently
received QRV was zero, in which case they use the default [Robustness
Variable] value specified in section 9.1, or a statically configured
value.
ルータは最も最近受信されたＱＲＶがゼロでなければ最も最近受信した問合
せのＱＲＶ値を自身の［信頼性変数］値として採用します、もしゼロなら
９.１章で示されるデフォルト［信頼性変数］値か、静的に設定された値を
使います。
5.1.9. QQIC (Querier's Query Interval Code)
5.1.9. ＱＱＩＣ（問合者質問間隔コード）
The Querier's Query Interval Code field specifies the [Query
Interval] used by the Querier. The actual interval, called the
Querier's Query Interval (QQI), is represented in units of seconds,
and is derived from the Querier's Query Interval Code as follows:
問合者の問合せ間隔コードフィールドは問合者の使用する［問合せ間隔］を
指定します。問合者問合間隔（ＱＱＩ）と呼ばれる実際の間隔は、秒単位で
示され、次のように問合者の問合せ間隔コードから得られます：
If QQIC < 128, QQI = QQIC
もしＱＱＩＣ＜１２８なら、ＱＱＩ＝ＱＱＩＣ
If QQIC >= 128, QQIC represents a floating-point value as follows:
もし最大応答コード≧１２８なら、ＱＱＩＣは以下の浮動小数点値を示し
ます：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
QQI = (mant | 0x10) << (exp + 3)
Multicast routers that are not the current Querier adopt the QQI
value from the most recently received Query as their own [Query
Interval] value, unless that most recently received QQI was zero, in
which case the receiving routers use the default [Query Interval]
value specified in section 9.2.
現在の問合者でないマルチキャストルータが、その最も最近受信したＱＱＩ
がゼロではなかったなら、最も最近受信した問合せのＱＱＩ値を自身のもの
［問合間隔］値として採用します、ゼロの場合受信ルータは９.２章で指定さ
れるデフォルト［問合間隔］値を使用します。
5.1.10. Number of Sources (N)
5.1.10. ソース数（Ｎ）
The Number of Sources (N) field specifies how many source addresses
are present in the Query. This number is zero in a General Query or
a Multicast Address Specific Query, and non-zero in a Multicast
Address and Source Specific Query. This number is limited by the MTU
of the link over which the Query is transmitted. For example, on an
Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets)
together with the Hop-By-Hop Extension Header (8 octets) that
includes the Router Alert option consume 48 octets; the MLD fields up
to the Number of Sources (N) field consume 28 octets; thus, there are
1424 octets left for source addresses, which limits the number of
source addresses to 89 (1424/16).
ソース数（Ｎ）フィールドは何個のソースアドレスが問合せに存在している
か明示します。この数は一般問合せやマルチキャストアドレス特定問合せで
ゼロで、マルチキャストアドレスとソース特定問合せでゼロ以外です。この
数は問合せが伝達されるリンクのＭＴＵによって制限されます。例えば、
１５００のオクテットのイーサーリンクで、ＩＰｖ６ヘッダ（４０オクテッ
ト）とルータ警告オプションを含むホップ毎拡張ヘッダ（８オクテット）は
４８オクテットになります；ソース数（Ｎ）までのＭＬＤフィールドは２８
オクテットです；ソースアドレスのための残りは１４２４オクテットなので、
ソースアドレスの数の限界は８９（１４２４／１６）です。
5.1.11. Source Address [i]
5.1.11. ソースアドレス[i]
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in the Number of Sources (N) field.
ソースアドレス[i]フィールドはｎユニキャストアドレスの列です、ここでｎ
はソース数（Ｎ）フィールドの値です。
5.1.12. Additional Data
5.1.12. 追加データ
If the Payload Length field in the IPv6 header of a received Query
indicates that there are additional octets of data present, beyond
the fields described here, MLDv2 implementations MUST include those
octets in the computation to verify the received MLD Checksum, but
MUST otherwise ignore those additional octets. When sending a Query,
an MLDv2 implementation MUST NOT include additional octets beyond the
fields described above.
もし受信問合せのＩＰｖ６ヘッダのペイロード長フィールドが、ここに記載
した以外に追加のデータがあることを示すなら、ＭＬＤｖ２実装は受信ＭＬ
Ｄチェックサム検査でこれらのオクテットを計算しなければならない(MUST)
が、それ以外は追加のオクテットを無視しなくてはなりません(MUST)。質問
を送る時、ＭＬＤｖ２実装は上記フィールド以外に追加オクテットを含んで
はなりません（MUST NOT）。
5.1.13. Query Variants
5.1.13. 質問の種類
There are three variants of the Query message:
質問メッセージの３つの種類があります：
o A "General Query" is sent by the Querier to learn which multicast
addresses have listeners on an attached link. In a General Query,
both the Multicast Address field and the Number of Sources (N)
field are zero.
o 「一般問合せ」は、接続リンク上でどのマルチキャストアドレスに受信者
がいるか学ぶために問合者によって行われます。一般問合せで、マルチキャ
ストアドレスフィールドとソース数（Ｎ）フィールドの両方がゼロです。
o A "Multicast Address Specific Query" is sent by the Querier to
learn if a particular multicast address has any listeners on an
attached link. In a Multicast Address Specific Query, the
Multicast Address field contains the multicast address of
interest, while the Number of Sources (N) field is set to zero.
o 「マルチキャストアドレス特定問合せ」は接続しているリンク上で、特定
のマルチキャストアドレスの受信者がいるかどうか学ぶために問合者によっ
て行われます。マルチキャストアドレス特定問合せで、マルチキャストア
ドレスフィールドは対象となるマルチキャストアドレスを含み、他方ソー
ス数（Ｎ）フィールドはゼロが設定されます。
o A "Multicast Address and Source Specific Query" is sent by the
Querier to learn if any of the sources from the specified list for
the particular multicast address has any listeners on an attached
link or not. In a Multicast Address and Source Specific Query the
Multicast Address field contains the multicast address of
interest, while the Source Address [i] field(s) contain(s) the
source address(es) of interest.
o 「マルチキャストアドレスとソース特定問合せ」は接続しているリンク上
で、指定されたソースからの特定のマルチキャストアドレスの受信者がい
るかどうか学ぶために問合者によって行われます。マルチキャストアドレ
スとソース特定問合せでマルチキャストアドレスフィールドは対象となる
マルチキャストアドレスを含み、ソースアドレス［ｉ］フィールドは対象
となるソースアドレスを含みます。
5.1.14. Source Addresses for Queries
5.1.14. 問合せのソースアドレス
All MLDv2 Queries MUST be sent with a valid IPv6 link-local source
address. If a node (router or host) receives a Query message with
the IPv6 Source Address set to the unspecified address (::), or any
other address that is not a valid IPv6 link-local address, it MUST
silently discard the message and SHOULD log a warning.
すべてのＭＬＤｖ２問合せは正当なＩＰｖ６リンクローカルソースアドレス
で送られなくてはなりません(MUST)。もしノード（ルータあるいはホスト）
が特定されていないアドレス(::)のＩＰｖ６ソースアドレスを設定した問合
せメッセージを受け取るなら、あるいは正当なＩＰｖ６リンクローカルアド
レスでないアドレスで受取るなら、静かにメッセージを捨てなくてはならず
(MUST)、そして警告をログに記録するべきです(SHOULD)。
5.1.15. Destination Addresses for Queries
5.1.15. 問合せの宛先アドレス
In MLDv2, General Queries are sent to the link-scope all-nodes
multicast address (FF02::1). Multicast Address Specific and
Multicast Address and Source Specific Queries are sent with an IP
destination address equal to the multicast address of interest.
*However*, a node MUST accept and process any Query whose IP
Destination Address field contains *any* of the addresses (unicast or
multicast) assigned to the interface on which the Query arrives. This
might be useful, e.g., for debugging purposes.
ＭＬＤｖ２で、一般問合せはリンク範囲の全ノードマルチキャストアドレス
(FF02::1)に送られます。マルチキャストアドレス特定問合せとマルチキャス
トアドレスとソース特定問合せは対象のマルチキャストアドレスと等しいＩ
Ｐ宛先アドレスで送られます。*しかしながら*ノードがＩＰ宛先アドレスに、
問合せを受信したインターフェースに割当てられたアドレス（ユニキャスト
とマルチキャスト）を含む、問合せを受け入れて処理しなければなしません
(MUST)。これは、例えば、デバッグの目的で有用であるかもしれません。
5.2. Version 2 Multicast Listener Report Message
5.2. ２版マルチキャスト受信者報告メッセージ
Version 2 Multicast Listener Reports are sent by IP nodes to report
(to neighboring routers) the current multicast listening state, or
changes in the multicast listening state, of their interfaces.
Reports 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 = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each Multicast Address Record has the following internal format:
それぞれのマルチキャストアドレスレコードが次の内部のフォーマットです：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- -+
. . .
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.1. Reserved
5.2.1. 予約
The Reserved fields are set to zero on transmission, and ignored on
reception.
予約のフィールドは送信時にゼロが設定され、受信時に無視されます。
5.2.2. Checksum
5.2.2. チェックサム
The standard ICMPv6 checksum; it covers the entire MLDv2 message,
plus a "pseudo-header" of IPv6 header fields [RFC2460, RFC2463]. In
order to compute the checksum, the Checksum field is set to zero.
When a packet is received, the checksum MUST be verified before
processing it.
標準的なＩＣＭＰｖ６チェックサム；これは全部のＭＬＤｖ２メッセージと、
ＩＰｖ６ヘッダーフィールドの「疑似ヘッダ」[RFC2460, RFC2463]をカバー
します。チェックサムを計算するために、チェックサムフィールドはゼロを
設定されます。パケットを受信する時、チェックサムはこれを処理する前に
実証されなくてはなりません(MUST)。
5.2.3. Nr of Mcast Address Records (M)
5.2.3. NrあるいはMcastアドレスレコード（Ｍ）
The Nr of Mcast Address Records (M) field specifies how many
Multicast Address Records are present in this Report.
NrあるいはMcastアドレスレコード（Ｍ）フィールドは何個のマルチキャスト
アドレスレコードがこの報告で存在しているか明示します。
5.2.4. Multicast Address Record
5.2.4. マルチキャストアドレスレコード
Each Multicast Address Record is a block of fields that contain
information on the sender listening to a single multicast address on
the interface from which the Report is sent.
それぞれのマルチキャストアドレスレコードは報告を送るインタフェース上
で送信者が受信する１つのマルチキャストアドレスの情報を含むフィールド
の塊です。
5.2.5. Record Type
5.2.5. 記録種別
It specifies the type of the Multicast Address Record. See section
5.2.12 for a detailed description of the different possible Record
Types.
これはマルチキャストアドレスレコードの種別を指定します。異なる記録種
別のの詳細な記述は５.２.１２章を見てください。
5.2.6. Aux Data Len
5.2.6. 補助データ長
The Aux Data Len field contains the length of the Auxiliary Data
Field in this Multicast Address Record, in units of 32-bit words. It
may contain zero, to indicate the absence of any auxiliary data.
補助データ長フィールドは、３２ビット単位で、このマルチキャストアドレ
スレコードの補助データフィールドの長さを含んでいます。これは補助デー
タがない事を示すために、ゼロを含んでいるかもしれません。
5.2.7. Number of Sources (N)
5.2.7. ソースの数（Ｎ）
The Number of Sources (N) field specifies how many source addresses
are present in this Multicast Address Record.
ソースの数（Ｎ）フィールドは何個のソースアドレスがこのマルチキャスト
アドレスレコードで存在しているか明示します。
5.2.8. Multicast Address
5.2.8. マルチキャストアドレス
The Multicast Address field contains the multicast address to which
this Multicast Address Record pertains.
マルチキャストアドレスフィールドはこのマルチキャストアドレスレコード
に関係するマルチキャストアドレスを含んでいます。
5.2.9. Source Address [i]
5.2.9. ソースアドレス［ｉ］
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in this record's Number of Sources (N) field.
ソースアドレス［ｉ］フィールドはｎ個のユニキャストアドレスのベクトル
で、そしてｎはこのレコードのソースの数（Ｎ）フィールドの値です。
5.2.10. Auxiliary Data
5.2.10. 補助データ
The Auxiliary Data field, if present, contains additional information
that pertain to this Multicast Address Record. The protocol
specified in this document, MLDv2, does not define any auxiliary
data. Therefore, implementations of MLDv2 MUST NOT include any
auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any
transmitted Multicast Address Record, and MUST ignore any such data
present in any received Multicast Address Record. The semantics and
the internal encoding of the Auxiliary Data field are to be defined
by any future version or extension of MLD that uses this field.
補助データフィールドは、もし存在するなら、このマルチキャストアドレス
レコードに関係ある追加情報を含んでいます。この文書で指定されたプロト
コル、ＭＬＤｖ２、は補助データを定義しません。それ故に、ＭＬＤｖ２実
装が伝達されたマルチキャストアドレスレコードにどんな補助データも含ん
ではならず(MUST NOT)（すなわち、補助データ長フィールドはゼロを設定し
なければならない(MUST)）、そして受信マルチキャストアドレスレコードの
このようなデータの存在を無視しなくてはなりません(MUST)。意味と補助デー
タフィールドの内部のコーディングはこのフィールドを使う将来のバージョ
ンあるいはＭＬＤ拡張で定義されるはずです。
5.2.11. Additional Data
5.2.11. 追加のデータ
If the Payload Length field in the IPv6 header of a received Report
indicates that there are additional octets of data present, beyond
the last Multicast Address Record, MLDv2 implementations MUST include
those octets in the computation to verify the received MLD Checksum,
but MUST otherwise ignore those additional octets. When sending a
Report, an MLDv2 implementation MUST NOT include additional octets
beyond the last Multicast Address Record.
もし受信した報告のＩＰｖ６ヘッダのペイロード長フィールドが追加のオク
テットデータがあることを示すなら、最後のマルチキャストアドレスレコー
ド以降は、ＭＬＤｖ２実装は受信ＭＬＤチェックサム検査の計算にそれらの
オクテットを含めなくてはなりません(MUST)が、それ以外は追加のオクテッ
トを無視しなくてはなりません(MUST)。報告を送る時、ＭＬＤｖ２実装が最
後のマルチキャストアドレスレコード以降に追加オクテットを含んではなり
ません(MUST NOT)。
5.2.12. Multicast Address Record Types
5.2.12. マルチキャストアドレスレコードタイプ
There are a number of different types of Multicast Address Records
that may be included in a Report message:
報告メッセージに含まれるかもしれない多くの異なるタイプのマルチキャス
トアドレスレコードがあります：
o A "Current State Record" is sent by a node in response to a Query
received on an interface. It reports the current listening state
of that interface, with respect to a single multicast address.
The Record Type of a Current State Record may be one of the
following two values:
o 「現在状態レコード」がインタフェース上で受信した問合せに応えてノー
ドによって送られます。これはそのインタフェースでの、ひとつのマルチ
キャストアドレスに関する現在の受信状態を報告します。現在状態レコー
ドのレコードタイプは次の２値の１つであるかもしれません：
Value Name and Meaning
値 名前と意味
----- ----------------
1 MODE_IS_INCLUDE - indicates that the interface has a filter
mode of INCLUDE for the specified multicast address. The
Source Address [i] fields in this Multicast Address Record
contain the interface's source list for the specified
multicast address. A MODE_IS_INCLUDE Record is never sent
with an empty source list.
1 MODE_IS_INCLUDEはインタフェースが指定されたマルチキャストア
ドレスのINCLUDEフィルタモードであることを示します。このマル
チキャストアドレスレコードのソースアドレス［ｉ］フィールド
は指定されたマルチキャストアドレスに対するインタフェースの
ソースリストを含んでいます。MODE_IS_INCLUDEレコードは空の
ソースリストで送ってはなりません。
2 MODE_IS_EXCLUDE - indicates that the interface has a filter
mode of EXCLUDE for the specified multicast address. The
Source Address [i] fields in this Multicast Address Record
contain the interface's source list for the specified
multicast address, if it is non-empty.
2 MODE_IS_EXCLUDEはインタフェースが指定されたマルチキャストア
ドレスに対してEXCLUDEフィルタモードであることを示します。こ
のマルチキャストアドレスレコードのソースアドレス［ｉ］フィー
ルドは、もし空でなければ、指定されたマルチキャストアドレス
に対するインタフェースのソースリストを含んでいます。
o A "Filter Mode Change Record" is sent by a node whenever a local
invocation of IPv6MulticastListen causes a change of the filter
mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
INCLUDE) of the interface-level state entry for a particular
multicast address, whether the source list changes at the same
time or not. The Record is included in a Report sent from the
interface on which the change occurred. The Record Type of a
Filter Mode Change Record may be one of the following two values:
o 「フィルタモード変更レコード」は、IPv6MulticastListenのローカル要
求が特定のマルチキャストアドレスのインターフェースレベル状態項目の
フィルタモードを変えた場合（すなわち、INCLUDEからEXCLUDEあるいは
EXCLUDEからINCLUDEに）、ソースリストが同時に変化するか否かにかか
わらず、ノードによって送られます。「レコード」は変更が起こったイ
ンタフェースから送られた報告に含められます。フィルタモードチェン
ジレコードの記録タイプは次の２値の１つであるかもしれません：
3 CHANGE_TO_INCLUDE_MODE - indicates that the interface has
changed to INCLUDE filter mode for the specified multicast
address. The Source Address [i] fields in this Multicast
Address Record contain the interface's new source list for
the specified multicast address, if it is non-empty.
3 CHANGE_TO_INCLUDE_MODEはインタフェースの指定されたマルチキャ
ストアドレスのフィルタモードがINCLUDEに変化したことを示します。
このマルチキャストアドレスレコードのソースアドレス［ｉ］フィー
ルドは、もし空でなければ、指定されたマルチキャストアドレスの
インタフェースの新しいソースリストを含んでいます。
4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
changed to EXCLUDE filter mode for the specified multicast
address. The Source Address [i] fields in this Multicast
Address Record contain the interface's new source list for
the specified multicast address, if it is non-empty.
4 CHANGE_TO_EXCLUDE_MODEはインタフェースの指定されたマルチキャ
ストアドレスのフィルタモードがEXCLUDEに変化したことを示します。
このマルチキャストアドレスレコードのソースアドレス［ｉ］フィー
ルドは、もしそれが空でないなら、指定されたマルチキャストアド
レスのインタフェースの新しいソースリストを含んでいます。
o A "Source List Change Record" is sent by a node whenever a local
invocation of IPv6MulticastListen causes a change of source list
that is *not* coincident with a change of filter mode, of the
interface-level state entry for a particular multicast address.
The Record is included in a Report sent from the interface on
which the change occurred. The Record Type of a Source List
Change Record may be one of the following two values:
o 「ソースリスト変更レコード」は、IPv6MulticastListenのローカル要求
が、フィルタモードの変更を*起こさず*に、特定のマルチキャストアドレ
スのインタフェースレベル状態項目のソースリストの変更をもたらす時に
ノードによって送られます。「レコード」は変更が起こったインタフェー
スから送らる報告を含みます。ソースリスト変更レコードの記録タイプは
次の２値の１つであるかもしれません：
5 ALLOW_NEW_SOURCES - indicates that the Source Address [i]
fields in this Multicast Address Record contain a list of
the additional sources that the node wishes to listen to,
for packets sent to the specified multicast address. If
the change was to an INCLUDE source list, these are the
addresses that were added to the list; if the change was to
an EXCLUDE source list, these are the addresses that were
deleted from the list.
5 ALLOW_NEW_SOURCESこのマルチキャストアドレスレコードのソースア
ドレス［ｉ］フィールドが、指定されたマルチキャストアドレス宛
のパケットで受信を望まない追加のソースのリストを含んでいるこ
とを示します。もし変更がINCLUDEソースリストへ対してなら、これ
らはリストに加えられたアドレスです；もし変更がEXCLUDEソースリ
ストへであったなら、これらはリストからの削除されたアドレスです。
6 BLOCK_OLD_SOURCES - indicates that the Source Address [i]
fields in this Multicast Address Record contain a list of
the sources that the node no longer wishes to listen to,
for packets sent to the specified multicast address. If the
change was to an INCLUDE source list, these are the
addresses that were deleted from the list; if the change
was to an EXCLUDE source list, these are the addresses that
were added to the list.
6 BLOCK_OLD_SOURCES−このマルチキャストアドレスレコードのソース
アドレス［ｉ］フィールドは、指定されたマルチキャストアドレス
に送られるパケットで、ノードが受信を望まない情報源のリストを
含んでいることを示します。もし変更がINCLUDE ソースリストへで
あったなら、これらはリストからの削除されたアドレスです；もし
変更がEXCLUDEソースリストへであったなら、これらはリストに加え
られたアドレスです。
If a change of source list results in both allowing new sources and
blocking old sources, then two Multicast Address Records are sent for
the same multicast address, one of type ALLOW_NEW_SOURCES and one of
type BLOCK_OLD_SOURCES.
もしソースリストの変更が新しいソースの許可と古いソースの停止の両方を
起こすなら、２つのマルチキャストアドレスレコード、ALLOW_NEW_SOURCESタ
イプとBLOCK_OLD_SOURCESタイプ、が同じマルチキャストアドレスに対して送
られます。
We use the term "State Change Record" to refer to either a Filter
Mode Change Record or a Source List Change Record.
我々はフィルタモード変更レコードあるいはソースリスト変更レコードを参
照するために用語「状態変更レコード」を使います。
Multicast Address Records with an unrecognized Record Type value MUST
be silently ignored, with the rest of the report being processed.
認識できないレコードタイプ値を持つマルチキャストアドレスレコードは、
報告の残りを処理して、静かに無視しなければなりません(MUST)。
In the rest of this document, we use the following notation to
describe the contents of a Multicast Address Record that pertains to
a particular multicast address:
この文書の残りで、我々は特定のマルチキャストアドレスに関係があるマル
チキャストアドレスレコードの中身を記述するために次の表記を使います：
IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x
IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x
TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x
TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x
ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x
BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x
where x is either:
xはどちらかです。
o a capital letter (e.g., "A") to represent the set of source
addresses,
o ソースアドレスの集合を表すための大文字（例えば、「Ａ」）、
or
あるいは
o a set expression (e.g., "A+B"), where "A+B" means the union of
sets A and B, "A*B" means the intersection of sets A and B, and
"A-B" means the removal of all elements of set B from set A.
o 集合式（例えば、「Ａ＋Ｂ」）、「Ａ＋Ｂ」が和集合を意味し、
「Ａ＊Ｂ」が共通集合を示し、「Ａ−Ｂ」差集合を意味します。
5.2.13. Source Addresses for Reports
5.2.13. 報告のソースアドレス
An MLDv2 Report MUST be sent with a valid IPv6 link-local source
address, or the unspecified address (::), if the sending interface
has not acquired a valid link-local address yet. Sending reports
with the unspecified address is allowed to support the use of IP
multicast in the Neighbor Discovery Protocol [RFC2461]. For
stateless autoconfiguration, as defined in [RFC2462], a node is
required to join several IPv6 multicast groups, in order to perform
Duplicate Address Detection (DAD). Prior to DAD, the only address
the reporting node has for the sending interface is a tentative one,
which cannot be used for communication. Thus, the unspecified
address must be used.
ＭＬＤｖ２報告は正当なＩＰｖ６リンクローカルソースアドレスか、もし送
信しているインタフェースがまだ有効なリンクローカルアドレスを獲得して
いなければ、特定されていないアドレス（::）で送られなくてはなりません
(MUST)。特定されていないアドレスで報告を送ることは近隣探索プロトコル
[RFC2461]でＩＰマルチキャストの使用をサポートすることを許します。ステー
トレス自動設定のために、[RFC2462]で定義されるように、ノードが重複アド
レス発見（ＤＡＤ）を行うために、いくつかのＩＰｖ６マルチキャストグルー
プに加入するように要求されます。ＤＡＤの前に、報告ノードが送信インタ
フェースのために持つアドレスは仮であり、そして通信に使うことができま
せん。それで、特定されていないアドレスが使われなくてはなりません。
On the other hand, routers MUST silently discard a message that is
not sent with a valid link-local address, without taking any action
on the contents of the packet. Thus, a Report is discarded if the
router cannot identify the source address of the packet as belonging
to a link connected to the interface on which the packet was
received. A Report sent with the unspecified address is also
discarded by the router. This enhances security, as unidentified
reporting nodes cannot influence the state of the MLDv2 router(s).
Nevertheless, the reporting node has modified its listening state for
multicast addresses that are contained in the Multicast Address
Records of the Report message. From now on, it will treat packets
sent to those multicast addresses according to this new listening
state. Once a valid link-local address is available, a node SHOULD
generate new MLDv2 Report messages for all multicast addresses joined
on the interface.
他方、ルータは正当なリンクローカルアドレスで送られないメッセージを、
パケットの中身を見ずに、静かに捨てなくてはなりません(MUST)。それで、
もしルータがパケットのソースアドレスがパケットを受信したインターフェー
スの接続するリンクに属すると認識できないなら、報告が捨てられます。特
定されていないアドレスで送られた報告が同じくルータによって捨てられま
す。これは、正体不明の報告ノードがＭＬＤｖ２ルータの状態に影響を与え
ることができないから、セキュリティを拡張します。にもかかわらず、報告
ノードは報告メッセージのマルチキャストアドレスレコードにあるマルチキャ
ストアドレスの受信状態を修正します。その時から、ノードは新しい受信状
態に従って、マルチキャストアドレスに送られたパケットを扱うでしょう。
正当なリンクローカルアドレスが利用可能になると、ノードは、インタフェー
ス上で受信する全てのマルチキャストアドレスのために新しいＭＬＤｖ２報
告メッセージを生成するべきです(SHOULD)。
5.2.14. Destination Addresses for Reports
5.2.14. 報告の宛先アドレス
Version 2 Multicast Listener Reports are sent with an IP destination
address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
routers listen (see section 11 for IANA considerations related to
this special destination address). A node that operates in version 1
compatibility mode (see details in section 8) sends version 1 Reports
to the multicast address specified in the Multicast Address field of
the Report. In addition, a node MUST accept and process any version
1 Report whose IP Destination Address field contains *any* of the
IPv6 addresses (unicast or multicast) assigned to the interface on
which the Report arrives. This might be useful, e.g., for debugging
purposes.
マルチキャスト受信者報告がＩＰ宛先アドレスFF02:0:0:0:0:0:0:16に送られ、
全てのＭＬＤｖ２対応のマルチキャストルータが受信します（この特別な宛
先アドレスと関係する１１章のＩＡＮＡの考慮を参照）。バージョン１互換
モードで稼働するノード（詳細は８章参照）が報告のマルチキャストアドレ
スフィールドに指定されるマルチキャストアドレスへバージョン１報告を送
ります。加えて、ノードが、ＩＰ宛先アドレスフィールドに報告を受信する
インターフェースに割当てられたＩＰｖ６アドレス（ユニキャストあるいは
マルチキャスト）のどれかを含むバージョン１の報告でも受け入れて、処理
しなくてはなりません(MUST)。これは、例えば、デバッグ目的で、有用かも
しれません。
5.2.15. Multicast Listener Report Size
5.2.15. マルチキャスト受信者報告の大きさ
If the set of Multicast Address Records required in a Report does not
fit within the size limit of a single Report message (as determined
by the MTU of the link on which it will be sent), the Multicast
Address Records are sent in as many Report messages as needed to
report the entire set.
もし報告で必要とされるマルチキャストアドレスレコードの集合がひとつの
報告メッセージの大きさの限界（報告を送るリンクのＭＴＵで決定される）
を越えるなら、集合全体を報告するのに必要なだけけの数の報告メッセージ
で送られる必要があります。
If a single Multicast Address Record contains so many source
addresses that it does not fit within the size limit of a single
Report message, then:
もしひとつのマルチキャストアドレスレコードが、ひとつの報告メッセージ
の大きさを越えるほど多くのソースアドレスを含んでいるなら：
o if its Type is not IS_EX or TO_EX, it is split into multiple
Multicast Address Records; each such record contains a different
subset of the source addresses, and is sent in a separate Report.
o もしそのタイプがIS_EXかTO_EXではないなら、これは多数のマルチキャス
トアドレスレコードに分けられます；それぞれのレコードはソースアドレ
ス集合の異なる部分集合を含み、そして別の報告で送られます。
o if its Type is IS_EX or TO_EX, a single Multicast Address Record
is sent, with as many source addresses as can fit; the remaining
source addresses are not reported. Although the choice of which
sources to report is arbitrary, it is preferable to report the
same set of sources in each subsequent report, rather than
reporting different sources each time.
o もしそのタイプがIS_EXかTO_EXであるなら、入るだけのソースアドレスを
含む、ひとつのマルチキャストアドレスレコードが送られます；残りのソー
スアドレスは報告されません。どのソースの報告をするかの選択は任意で
あるが、それぞれの時間に異なるソースを報告するより、次の報告で同じ
ソースの集合を報告することは望ましいです。
6. Protocol Description for Multicast Address Listeners
6. マルチキャストアドレス受信者のためのプロトコル記述
MLD is an asymmetric protocol, as it specifies separate behaviors for
multicast address listeners -- that is, hosts or routers that listen
to multicast packets -- and multicast routers. This section
describes the part of MLDv2 that applies to all multicast address
listeners. (Note that a multicast router that is also a multicast
address listener performs both parts of MLDv2; it receives and it
responds to its own MLD messages, as well as to those of its
neighbors.) The multicast router part of MLDv2 is described in
section 7.
ＭＬＤは、マルチキャストアドレス受信者−すなわちホストやマルチキャス
トパケットを受信するルータ−とマルチキャストルータに別の行動を指定す
るから、非対称プロトコルです。この章はすべてのマルチキャストアドレス
受信者に適用するＭＬＤｖ２の部分を記述します。（マルチキャストアドレ
ス受信者でもあるマルチキャストルータがＭＬＤｖ２の両方の部分を実行す
ることに注意してください；これは近隣からのＭＬＤメッセージ同様に自身
のＭＬＤメッセージ受信し返答します。）ＭＬＤｖ２のマルチキャストルー
タ部分は７章で記述されます。
A node performs the protocol described in this section over all
interfaces on which multicast reception is supported, even if more
than one of those interfaces are connected to the same link.
ノードは、たとえ複数のインタフェースが同じリンクに接続していても、マ
ルチキャスト受信がサポートされるすべてのインタフェース上でこの章で記
述された、プロトコルを行います。
For interoperability with multicast routers that run the MLDv1
protocol, nodes maintain a Host Compatibility Mode variable for each
interface on which multicast reception is supported. This section
describes the behavior of multicast address listener nodes on
interfaces for which Host Compatibility Mode = MLDv2. The algorithm
for determining Host Compatibility Mode, and the behavior if its
value is set to MLDv1, are described in section 8.
ＭＬＤｖ１プロトコルを動かすマルチキャストルータとの互換性のために、
ノードはマルチキャスト受信がサポートされるそれぞれのインタフェースで
ホスト互換モード変数を維持します。この章は、ノード互換モード＝ＭＬＤ
ｖ２のインタフェース上で、マルチキャストアドレス受信者ノードの行動を
記述します。ホスト互換モードを決定するアルゴリズムと、もしその値がＭ
ＬＤｖ１に設定されたときの行動は、８章で記述されます。
The link-scope all-nodes multicast address, (FF02::1), is handled as
a special case. On all nodes -- that is all hosts and routers,
including multicast routers -- listening to packets destined to the
all-nodes multicast address, from all sources, is permanently enabled
on all interfaces on which multicast listening is supported. No MLD
messages are ever sent regarding neither the link-scope all-nodes
multicast address, nor any multicast address of scope 0 (reserved) or
1 (node-local).
リンク範囲全ノードマルチキャストアドレス(FF02::2）は、特別なケースと
して扱われます。すべてのノードで−マルチキャストルータを含むすべての
ホストとルータで−すべてのソースからの、全ノードマルチキャストアドレ
ス宛のパケットを受信し、マルチキャストをサポートするすべてのインタフェー
ス上で永久に使用可能です。リンク範囲全ノードマルチキャストアドレスや
範囲０（予約）や１（ノードローカル）のマルチキャストアドレスに関する
ＭＬＤメッセージが送られません。
There are three types of events that trigger MLDv2 protocol actions
on an interface:
インタフェースでＭＬＤｖ２プロトコル行動を引き起こす３つのイベント種
別があります：
o a change of the per-interface listening state, caused by a local
invocation of IPv6MulticastListen;
o IPv6MulticastListenのローカル呼出しによって起こされたインターフェー
ス毎の受信状態変更；
o the firing of a specific timer;
o 特定のタイマーのタイムアウト；
o the reception of a Query.
o 質問の受信。
(Received MLD messages of types other than Query are silently
ignored, except as required for interoperation with nodes that
implement MLDv1.)
（質問以外の種類の受信ＭＬＤメッセージは、ＭＬＤｖ１を実行するノード
で相互運用のために必要とされるとして以外に、静かに無視されます。）
The following subsections describe the actions to be taken for each
case. Timer and counter names appear in square brackets. Default
values for those timers and counters are specified in section 9.
次の詳細はそれぞれの事例で取られる行動を記述します。タイマとカウンタ
名が角括弧で現われます。これらのタイマとカウンタのデフォルト値が９章
で指定されます。
6.1. Action on Change of Per-Interface State
6.1. インタフェース毎状態の変更の行動
An invocation of IPv6MulticastListen may cause the multicast
listening state of an interface to change, according to the rules in
section 4.2. Each such change affects the per-interface entry for a
single multicast address.
４.２章の規則によりIPv6MulticastListen呼出しは、インタフェースのマル
チキャスト受信状態を変化させるかもしれません。このような変更は、ひと
つのマルチキャストアドレスのインターフェース毎状態のそれぞれの項目に
影響を与えます。
A change of per-interface state causes the node to immediately
transmit a State Change Report from that interface. The type and
contents of the Multicast Address Record(s) in that Report are
determined by comparing the filter mode and source list for the
affected multicast address before and after the change, according to
the table below. If no per-interface state existed for that
multicast address before the change (i.e., the change consisted of
creating a new per-interface record), or if no state exists after the
change (i.e., the change consisted of deleting a per-interface
record), then the "non-existent" state is considered to have an
INCLUDE filter mode and an empty source list.
インタフェース毎状態の変化は、ノードがそのインタフェースからすぐに状
態変更報告を伝達させる結果になります。報告のマルチキャストアドレスレ
コードの種類と内容は、影響を受けたマルチキャストアドレスのフィルタモー
ドとソースリストの変更前と後を比較することによって、下記の表により決
定できます。もし変更前にそのマルチキャストアドレスのインターフェース
毎の状態がないなら（すなわち、変更が新しいインターフェース毎のレコー
ドを作るなら）、あるいはもし変更後に状態が存在しないなら（すなわち、
変更がインターフェース毎のレコードを削除するなら）、それで「非実在」
状態はINCLUDEフィルタモードとソースリストを持つと考えられます。
Old State New State State Change Record Sent
旧状態 新状態 状態変更レコード送信
--------- --------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)
EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)
INCLUDE (A) EXCLUDE (B) TO_EX (B)
EXCLUDE (A) INCLUDE (B) TO_IN (B)
If the computed source list for either an ALLOW or a BLOCK State
Change Record is empty, that record is omitted from the Report.
もしALLOWあるいはBLOCK状態変更レコードのために計算されたソースリスト
が空であるなら、そのレコードは報告から削除されます。
To cover the possibility of the State Change Report being missed by
one or more multicast routers, [Robustness Variable] - 1
retransmissions are scheduled, through a Retransmission Timer, at
intervals chosen at random from the range (0, [Unsolicited Report
Interval]).
状態変更報告をマルチキャストルータがミスする可能性に対応するために、
範囲（０、[望まれない報告間隔]）からランダムに選ばれた再送タイマに
よって、[信頼性変数]-1の再送が予定されます。
If more changes to the same per-interface state entry occur before
all the retransmissions of the State Change Report for the first
change have been completed, each such additional change triggers the
immediate transmission of a new State Change Report.
もし最初の変更のための状態変更報告のすべての再送が完了する前に、同じ
インターフェース毎の状態の項目へのもっと多くの変更が起こるなら、この
ような追加の変更が新しい状態変更報告の即刻の送信を引き起こします。
The contents of the new Report are calculated as follows:
新しい報告の内容は次のように計算されます：
o As for the first Report, the per-interface state for the affected
multicast address before and after the latest change is compared.
o 最初の報告に対して、最近の変更の前と後の影響を受けたマルチキャスト
アドレスのインターフェース毎の状態が比較されます。
o The records that express the difference are built according to the
table above. Nevertheless, these records are not transmitted in a
separate message, but they are instead merged with the contents of
the pending report, to create the new State Change Report. The
rules for calculating this merged report are described below.
o 相違を表現するレコードは上記の表に従って構築されます。しかし、これ
らのレコードは別のメッセージで伝達されません、これらは新しい状態変
更報告を作るために、実行中の報告の内容と統合されます。この統合され
た報告を計算するための規則は以下に記述されます。
The transmission of the merged State Change Report terminates
retransmissions of the earlier State Change Reports for the same
multicast address, and becomes the first of [Robustness Variable]
transmissions of the new State Change Reports. These transmissions
are necessary in order to ensure that each instance of state change
is transmitted at least [Robustness Variable] times.
合併された状態変更報告の送信は同じマルチキャストアドレスのためのより
早い状態変更報告の再送を終了させ、そして新しい状態変更報告の［信頼性
変数］回の送信の最初になります。これらの送信はそれぞれの状態変化が最
少の［信頼性変数］回で伝達されることを保証するために必要です。
Each time a source is included in the difference report calculated
above, retransmission state for that source needs to be maintained
until [Robustness Variable] State Change Reports have been sent by
the node. This is done in order to ensure that a series of
successive state changes do not break the protocol robustness.
Sources in retransmission state can be kept in a per multicast
address Retransmission List, with a Source Retransmission Counter
associated to each source in the list. When a source is included in
the list, its counter is set to [Robustness Variable]. Each time a
State Change Report is sent the counter is decreased by one unit.
When the counter reaches zero, the source is deleted from the
Retransmission List for that multicast address.
ソースが上で計算した相違に含められるたびに、そのソースのための再送状
態が、［信頼性変数］回の状態変更報告がノードによって送られるまで、維
持される必要があります。これは一連の連続した状態変更がプロトコルの安
定を絶ち切らないことを保証するためにされます。再送状態のソースは、リ
ストのそれぞれのソースに関するソース再送カウンタと共に、マルチキャス
トアドレス再送毎のリストに維持されます。リストにソースが追加される度
に、そのカウンタは［信頼性変数］に設定されます。状態変更報告が送られ
るたびに、カウンタは１単位づつ減少します。カウンタがゼロに達する時、
ソースはそのマルチキャストアドレスの再送リストから削除されます。
If the per-interface listening change that triggers the new report is
a filter mode change, then the next [Robustness Variable] State
Change Reports will include a Filter Mode Change Record. This
applies even if any number of source list changes occur in that
period. The node has to maintain retransmission state for the
multicast address until the [Robustness Variable] State Change
Reports have been sent. This can be done through a per multicast
address Filter Mode Retransmission Counter. When the filter mode
changes, the counter is set to [Robustness Variable]. Each time a
State Change Report is sent the counter is decreased by one unit.
When the counter reaches zero, i.e., [Robustness Variable] State
Change Reports with Filter Mode Change Records have been transmitted
after the last filter mode change, and if source list changes have
resulted in additional reports being scheduled, then the next State
Change Report will include Source List Change Records.
もし新しい報告を引き起こすインターフェース毎の受信状態の変更がフィル
タモード変更であるなら、次の［信頼性変数］回の状態変更報告はフィルタ
モード変更レコードを含むでしょう。これはその期間にソースリスト変更が
何度起きても適用されます。ノードは［信頼性変数］回の状態変更報告が送
られるまで、マルチキャストアドレスの再送状態を維持しなければなりませ
ん。これはマルチキャストアドレス毎のフィルタモード再送カウンタででき
ます。フィルタモードが変れば、カウンタが［信頼性変数］に設定されます。
状態変更報告が送られるたびに、カウンタは１単位づつ減少します。カウン
タがゼロに達する時、すなわち、フィルタモード変更後に、フィルタモード
変更レコードが［信頼性変数］回の状態変更報告が再送されたら、そしても
しソースリスト変更が追加の報告が予定されるという結果になったなら、次
の状態変更報告はソースリスト変更レコードを含むでしょう。
Each time a per-interface listening state change triggers the
Immediate transmission of a new State Change Report, its contents are
determined as follows. If the report should contain a Filter Mode
Change Record, i.e., the Filter Mode Retransmission Counter for that
multicast address has a value higher than zero, then, if the current
filter mode of the interface is INCLUDE, a TO_IN record is included
in the report; otherwise a TO_EX record is included. If instead the
report should contain Source List Change Records, i.e., the Filter
Mode Retransmission Counter for that multicast address is zero, an
ALLOW and a BLOCK record is included. The contents of these records
are built according to the table below.
インターフェース毎の受信状態変更が新しい状態変更報告の即刻の送信を引
き起こすたびに、その内容は次のように決定されます。もし報告がフィルタ
モード変更レコードを含んでいるべきなら、すなわち、そのマルチキャスト
アドレスのフィルタモード再送カウンタがゼロより大きいなら、もしインタ
フェースの現在のフィルタモードがINCLUDEであるなら、TO_INレコードが報
告に含められます；さもなければTO_EXレコードが含まれます。もし代わりの
報告がソースリスト変更レコードを含んでいたなら、すなわち、そのマルチ
キャストアドレスのフィルタモード再送カウンタがゼロなら、ALLOWとブロッ
クレコードが含まれます。これらのレコードの中身は下表に従って構築され
ます。
Record Sources included
レコード 含まれるソース
------ ----------------
TO_IN All in the current per-interface state that must be
forwarded
現在のインターフェース毎の状態のすべてが転送されなくてはなら
ない。
TO_EX All in the current per-interface state that must be
blocked
現在のインターフェース毎の状態のすべてをブロックしなければな
らない。
ALLOW All with retransmission state (i.e., all sources from the
Retransmission List) that must be forwarded
再送状態の全て（すなわち、すべての再送リストのソース）が転送
されなくてはならない。
BLOCK All with retransmission state that must be blocked
再送状態の全てがブロックされなければならない。
If the computed source list for either an ALLOW or a BLOCK record is
empty, that record is omitted from the State Change Report.
もしALLOWあるいはBLOCK レコードのための計算されたソースリストが空であ
るなら、そのレコードは状態変更報告から除かれます。
Note: When the first State Change Report is sent, the non-existent
pending report to merge with can be treated as a Source Change Report
with empty ALLOW and BLOCK records (no sources have retransmission
state).
メモ：最初の状態変更報告が送られる時、合併するべき報告がなければ（再
送状態を持つソースがない）、それは空のALLOWやBLOCKレコードのソース変
更報告と扱うことができます。
The building of a scheduled State Change Report, triggered by the
firing of a Retransmission Timer, instead of a per-interface
listening state change, is described in section 6.3.
インターフェース毎の受信状態変更ではなく、再送タイマによって引き起こ
され、状態変更報告の予定の構築は６.３で記述されます。
6.2. Action on Reception of a Query
6.2. 問合せ受信時の行動
Upon reception of an MLD message that contains a Query, the node
checks if the source address of the message is a valid link-local
address, if the Hop Limit is set to 1, and if the Router Alert option
is present in the Hop-By-Hop Options header of the IPv6 packet. If
any of these checks fails, the packet is dropped.
問合せを含むＭＬＤメッセージを受信したノードはメッセージのソースアド
レスが正当なリンクローカルアドレスであるかどうか、ホップ限界が１に設
定されるかどうか、そしてルータ警告オプションがＩＰｖ６パケットのホッ
プ毎オプションヘッダに存在しているかどうか調べます。もしこれらの検査
のどれかが失敗するなら、パケットは廃棄されます。
If the validity of the MLD message is verified, the node starts to
process the Query. Instead of responding immediately, the node
delays its response by a random amount of time, bounded by the
Maximum Response Delay value derived from the Maximum Response Code
in the received Query message. A node may receive a variety of
Queries on different interfaces and of different kinds (e.g., General
Queries, Multicast Address Specific Queries, and Multicast Address
and Source Specific Queries), each of which may require its own
delayed response.
もしＭＬＤメッセージの正当性が確かめられるなら、ノードは問合せを処理
し始めます。すぐに返答する代わりに、ノードは受信した問合せメッセージ
の最大応答コードから得られた最大の回答遅延値にを限界として、任意の量
の時間その応答を延期します。ノードが異なるインタフェース上で異なる種
類の問合せを受け取るかもしれません（例えば、一般問合せとマルチキャス
トアドレス特定問合せとマルチキャストアドレスとソース特定問合せ）、そ
してそのそれぞれで遅延応答を必要とするかもしれません。
Before scheduling a response to a Query, the node must first consider
previously scheduled pending responses and, in many cases, schedule a
combined response. Therefore, for each of its interfaces on which it
operates the listener part of the MLDv2 protocol, the node must be
able to maintain the following state:
質問に対する応答を予定する前に、ノードは最初に、前に予定された応答を
考慮し、そして、多くの場合、結合された応答をしなくてはなりません。そ
れ故に、ＭＬＤｖ２プロトコルの受信部を実行するそれぞれのインタフェー
スで、ノードは次の状態を維持することができなければなりません：
o an Interface Timer for scheduling responses to General Queries;
o 一般問合せに対する応答のインタフェースタイマー；
o a Multicast Address Timer for scheduling responses to Multicast
Address (and Source) Specific Queries, for each multicast address
the node has to report on;
o ノードが報告しなければならないそれぞれのマルチキャストアドレスのた
めの、マルチキャストアドレス（とソース）特定問合せに対する応答のた
めの、マルチキャストアドレスタイマー；
o a per-multicast-address list of sources to be reported in response
to a Multicast Address and Source Specific Query.
o マルチキャストアドレスとソース特定問合せに応答するためのマルチキャ
ストアドレス毎のソースリスト。
When a new valid General Query arrives on an interface, the node
checks whether it has any per-interface listening state record to
report on, or not. Similarly, when a new valid Multicast Address
(and Source) Specific Query arrives on an interface, the node checks
whether it has a per-interface listening state record that
corresponds to the queried multicast address (and source), or not. If
it does, a delay for a response is randomly selected in the range (0,
[Maximum Response Delay]), where Maximum Response Delay is derived
from the Maximum Response Code inserted in the received Query
message. The following rules are then used to determine if a Report
needs to be scheduled or not, and the type of Report to schedule.
(The rules are considered in order and only the first matching rule
is applied.)
新しい正当な一般問合せがインタフェースの上に到着する時、ノードは報告
するべきインターフェース毎の受信状態レコードがあるかどうか調べます。
同様に、新しい正当なマルチキャストアドレス（とソース）特定問合せがイ
ンタフェース上に到着する時、ノードは尋ねられたマルチキャストアドレス
（とソース）に対応する、インターフェース毎の受信状態レコードを持って
いるかどうか調べます。もしあれば、応答のための遅延が範囲（０、［最大
応答遅延］）からランダムに選択されます、ここで最大の応答遅延が受信し
た問合せメッセージに挿入された最大応答コードから得られます。次の規則
は報告の必要があるかどうかと報告の種類を決定するために使われます。
（規則は順番に考慮され、そして最初の一致規則だけが適用されます。）
1. If there is a pending response to a previous General Query
scheduled sooner than the selected delay, no additional response
needs to be scheduled.
1. もし選択された遅延より早く予定されている一般問合せに対する応答があ
るなら、追加の応答をする必要がありません。
2. If the received Query is a General Query, the Interface Timer is
used to schedule a response to the General Query after the
selected delay. Any previously pending response to a General
Query is canceled.
2. もし受信した問合せが一般問合せであるなら、インタフェースタイマーは
選択された遅延後に一般問合せで応答するために使われます。一般問合せ
に対する前の応答予定は中止されます。
3. If the received Query is a Multicast Address Specific Query or a
Multicast Address and Source Specific Query and there is no
pending response to a previous Query for this multicast address,
then the Multicast Address Timer is used to schedule a report. If
the received Query is a Multicast Address and Source Specific
Query, the list of queried sources is recorded to be used when
generating a response.
3. もし受信した問合せがマルチキャストアドレス特定問合せあるいはマルチ
キャストアドレスとソース特定問合せであるなら、そしてこのマルチキャ
ストアドレスのための前の問合せに対する応答予定がないなら、マルチキャ
ストアドレスタイマーは報告を予定するために使われます。もし受信した
質問がマルチキャストアドレスとソース特定問合せであるなら、問い合わ
せられたソースのリストは、応答を生成するときに使われるために記録さ
れます。
4. If there is already a pending response to a previous Query
scheduled for this multicast address, and either the new Query is
a Multicast Address Specific Query or the recorded source list
associated with the multicast address is empty, then the multicast
address source list is cleared and a single response is scheduled,
using the Multicast Address Timer. The new response is scheduled
to be sent at the earliest of the remaining time for the pending
report and the selected delay.
4. もしこのマルチキャストアドレスのために予定された前の問合せに対する
応答予定がすでにあり、そして新しい問合せがマルチキャストアドレス特
定問合せであるか、マルチキャストアドレスと結び付けられた記録された
ソースリストが空であるなら、マルチキャストアドレスソースリストはキャ
ンセルされ、そしてひとつの応答がマルチキャストアドレスタイマーを使っ
て、予定されます。新しい応答は予定していた報告の遅延時間の残りと、
選択された遅延の早いほうで送られるように予定されます。
5. If the received Query is a Multicast Address and Source Specific
Query and there is a pending response for this multicast address
with a non-empty source list, then the multicast address source
list is augmented to contain the list of sources in the new Query,
and a single response is scheduled using the Multicast Address
Timer. The new response is scheduled to be sent at the earliest
of the remaining time for the pending report and the selected
delay.
5. もし受信した問合せがマルチキャストアドレスとソース特定問合せであり、
そしてこのマルチキャストアドレスのための空でないソースリストの応答
があるなら、マルチキャストアドレスソースリストは新しい問合せのソー
スリストを含むように拡張されます、そしてひとつの応答がマルチキャス
トアドレスタイマーを使って予定されます。新しい応答は予定していた報
告の遅延時間の残りと、選択された遅延の早いほうで送られるように予定
されます。
6.3. Action on Timer Expiration
6.3. タイマ期限後の行動
There are several timers that, upon expiration, trigger protocol
actions on an MLDv2 Multicast Address Listener node. All these
actions are related to pending reports scheduled by the node.
ＭＬＤｖ２マルチキャストアドレス受信ノード上に、タイムアウトでプロト
コル行動を引き起こすいくつかのタイマがあります。これらすべての行動は
ノードによって予定された報告と関係があります。
1. If the expired timer is the Interface Timer (i.e., there is a
pending response to a General Query), then one Current State
Record is sent for each multicast address for which the specified
interface has listening state, as described in section 4.2. The
Current State Record carries the multicast address and its
1. もしタイムアウトしたタイマがインタフェースタイマ（すなわち、一般問
合せに対する予定した応答がある）なら、４.２章で記述されるように、
指定されたインタフェースのセクション受信状態にあるそれぞれのマルチ
キャストアドレスの現在の状態レコードが１つ送られます。
associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and
Source list. Multiple Current State Records are packed into
individual Report messages, to the extent possible.
現在の状態レコードはマルチキャストアドレスとそれに関連づけられた
フィルタモード（MODE_IS_INCLUDEあるいはMODE_IS_EXCLUDE）とソースリ
ストを運びます。
This naive algorithm may result in bursts of packets when a node
listens to a large number of multicast addresses. Instead of
using a single Interface Timer, implementations are recommended to
spread transmission of such Report messages over the interval (0,
[Maximum Response Delay]). Note that any such implementation MUST
avoid the "ack-implosion" problem, i.e., MUST NOT send a Report
immediately upon reception of a General Query.
多数の現在の状態レコードが可能な限り個別の報告メッセージの中に入れ
られます。このネイティブのアルゴリズムは、ノードが多数のマルチキャ
ストアドレスを受信する時は、パケットの爆発をもたらすかもしれません。
ひとつのインタフェースタイマを使う代わりに、実装が範囲（０、［最大
応答遅延］）でこのような報告メッセージの送信を分散することが勧めら
れます。このような実装は「応答破裂」問題を避けなくてはならない(MUST)
ことを指摘します、すなわち、一般問合せ受信後に報告をすぐに送信して
はなりません(MUST NOT)。
2. If the expired timer is a Multicast Address Timer and the list of
recorded sources for that multicast address is empty (i.e., there
is a pending response to a Multicast Address Specific Query), then
if, and only if, the interface has listening state for that
multicast address, a single Current State Record is sent for that
address. The Current State Record carries the multicast address
and its associated filter mode (MODE_IS_INCLUDE or
MODE_IS_EXCLUDE) and source list, if any.
2. もしタイムアウトしたタイマがマルチキャストアドレスタイマで、そして
そのマルチキャストアドレスのための記録されたソースのリストが空であ
るなら（すなわち、マルチキャストアドレス特定問合せに対する応答予定
があるなら）、その場合に限り、インタフェースはそのマルチキャストア
ドレスの受信状態を持ち、ひとつの現在の状態レコードがそのアドレスの
ために送られます。現在の状態レコードは、マルチキャストアドレスとそ
れに関連づけられたフィルタモード（MODE_IS_INCLUDEあるいは
MODE_IS_EXCLUDE）と、もしあれば、ソースリストを運びます。
3. If the expired timer is a Multicast Address Timer and the list of
recorded sources for that multicast address is non-empty (i.e.,
there is a pending response to a Multicast Address and Source
Specific Query), then if, and only if, the interface has listening
state for that multicast address, the contents of the
corresponding Current State Record are determined from the per-
interface state and the pending response record, as specified in
the following table:
3. もしタイムアウトしたタイマがマルチキャストアドレスタイマで、そのマ
ルチキャストアドレスのための記録されたソースのリストが空でないなら
（すなわち、マルチキャストアドレスとソース特定問合せに対する予定し
た応答があるなら）、その場合に限り、インタフェースはマルチキャスト
アドレス対して受信状態を持ち、対応する現在の状態レコードのの内容が、
以下の表により、インターフェース毎状態と予定した応答から決定されま
す：
set of sources in the
per-interface state pending response record Current State Record
インターフェース毎 応答予定の回答レコード
の状態 のソースの集合 現在の状態レコード
------------------- ----------------------- --------------------
INCLUDE (A) B IS_IN (A*B)
EXCLUDE (A) B IS_IN (B-A)
If the resulting Current State Record has an empty set of source
addresses, then no response is sent. After the required Report
messages have been generated, the source lists associated with any
reported multicast addresses are cleared.
もし結果として生じる現在の状態レコードが空のソースアドレス集合を持つ
なら、応答が送られません。必要とされる報告メッセージが生成された後、
報告されたマルチキャストアドレスと関連したソースリストはクリアされま
す。
4. If the expired timer is a Retransmission Timer for a multicast
address (i.e., there is a pending State Change Report for that
multicast address), the contents of the report are determined as
follows. If the report should contain a Filter Mode Change
Record, i.e., the Filter Mode Retransmission Counter for that
multicast address has a value higher than zero, then, if the
current filter mode of the interface is INCLUDE, a TO_IN record is
included in the report; otherwise a TO_EX record is included. In
both cases, the Filter Mode Retransmission Counter for that
multicast address is decremented by one unit after the
transmission of the report.
4. もしタイムアウトしたタイマがマルチキャストアドレスに対する再送タイ
マなら（すなわち、そのマルチキャストアドレスのための状態変更報告が
あるなら）、報告の内容は次のように決定されます。もし報告がフィルタ
モード変更レコードを含んでいるべきなら、すなわち、そのマルチキャス
トアドレスのフィルタモード再送カウンタがゼロより大きい値を持つなら、
もしインタフェースの現在のフィルタモードがINCLUDEであるならTO_INレ
コードが報告に含められます、さもなければTO_EXレコードが含まれます。
両方の場合で、そのマルチキャストアドレスのためのフィルタモード再送
カウンタは報告の送信後に１単位減少します。
If instead the report should contain Source List Change Records,
i.e., the Filter Mode Retransmission Counter for that multicast
address is zero, an ALLOW and a BLOCK record is included. The
contents of these records are built according to the table below:
もし報告がソースリスト変更レコードを含んでいるなら、すなわち、その
マルチキャストアドレスのためのフィルタモード再送カウンタがゼロなら、
ALLOWとBLOCKレコードが含まれます。これらのレコードの中身は下の表に
従って構築されます：
Record Sources included
レコード 含まれるソース
------ ----------------
TO_IN All in the current per-interface state that must be
forwarded
TO_IN 現在のインターフェース毎の状態の転送であるすべて。
TO_EX All in the current per-interface state that must be
blocked
TO_EX 現在のインターフェース毎の状態のブロックであるすべて。
ALLOW All with retransmission state (i.e., all sources from the
Retransmission List) that must be forwarded. For each
included source, its Source Retransmission Counter is
decreased with one unit after the transmission of the
report. If the counter reaches zero, the source is
deleted from the Retransmission List for that multicast
address.
ALLOW 転送である再送状態のすべて（すなわち、再送リストのソース
の全て）。それぞれの含まれるソースに対し、そのソース再送
カウンタは報告の伝達後に１単位減少します。もしカウンタが
ゼロに達するなら、そのマルチキャストアドレスの再送リスト
からソースは削除されます。
BLOCK All with retransmission state (i.e., all sources from the
Retransmission List) that must be blocked. For each
included source, its Source Retransmission Counter is
decreased with one unit after the transmission of the
report. If the counter reaches zero, the source is
deleted from the Retransmission List for that multicast
address.
BLOCK ブロックである再送状態のすべて（すなわち、すべての再送リ
ストのソース）。それぞれの含まれるソースに対し、そのソー
ス再送カウンタは報告の伝達後に１単位減少します。もしカウ
ンタがゼロに達するなら、そのマルチキャストアドレスの再送
リストからソースは削除されます。
If the computed source list for either an ALLOW or a BLOCK record
is empty, that record is omitted from the State Change Report.
もしALLOWかBLOCKレコードのための計算されたソースリストが空であるな
ら、そのレコードは状態変更報告から除かれます。
7. Description of the Protocol for Multicast Routers
7. マルチキャストルータのためのプロトコルの記述
The purpose of MLD is to enable each multicast router to learn, for
each of its directly attached links, which multicast addresses have
listeners on that link. MLD version 2 adds the capability for a
multicast router to also learn which *sources* have listeners among
the neighboring nodes, for packets sent to any particular multicast
address. The information gathered by MLD is provided to whichever
multicast routing protocol is used by the router, in order to ensure
that multicast packets are delivered to all links where there are
interested listeners.
ＭＬＤの目的はそれぞれのマルチキャストルータが、その直接接続するリン
クのそれぞれで、リンク上でどのマルチキャストアドレスに受信者がいるか
学ぶことができるようにすることです。ＭＬＤバージョン２はマルチキャス
トルータに、特定のマルチキャストアドレスに送ったパケットで、どの*ソー
ス*に対して隣接ノードの受信者がいるかを学ぶ能力を追加します。ＭＬＤに
よって集められた情報は受信者がいるすべてのリンクにマルチキャストパケッ
トが配達されることを保証するために、ルータによって使われるマルチキャ
ストルーティングプロトコルにも供給されます。
This section describes the part of MLDv2 that is performed by
multicast routers. Multicast routers may themselves become multicast
address listeners, and therefore also perform the multicast listener
part of MLDv2, described in section 6.
この章はマルチキャストルータによって行われるＭＬＤｖ２の役割を記述し
ます。マルチキャストルータ自身がマルチキャストアドレス受信者になり、
そして６章で記述されたＭＬＤｖ２のマルチキャスト聞き手役割も行っても
よいです。
A multicast router performs the protocol described in this section
over each of its directly attached links. If a multicast router has
more than one interface to the same link, it only needs to operate
this protocol over one of those interfaces.
マルチキャストルータがその直接接続されているリンクのそれぞれの上でこ
の章で記述されたプロトコルを実行します。もしマルチキャストルータが同
じリンクへ複数のインタフェースを持っているなら、それらのインタフェー
スの１つでこのプロトコルを操作する必要があるだけです。
For each interface over which the router operates the MLD protocol,
the router must configure that interface to listen to all link-layer
multicast addresses 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 [RFC2464]; in the case of an
Ethernet interface that does not support the filtering of such a
multicast address range, it must be configured to accept ALL Ethernet
multicast addresses, in order to meet the requirements of MLD.
ルータがＭＬＤプロトコルを動かすそれぞれのインタフェースで、ルータは
ＩＰｖ６マルチキャストが生成するすべてのリンクレイヤマルチキャストア
ドレスを受信するようにインタフェースの設定をしなくてはなりません。例
えば、イーサネット接続ルータがそのイーサネットアドレス受信フィルタで
１６進数で３３３３で始まるすべてのイーサネットマルチキャストアドレス
を受信するようにしなくてはなりません[RFC2464]；このようなマルチキャス
トアドレス範囲のフィルタをサポートしないイーサネットインタフェースの
場合は、ＭＬＤの必要条件を満たすために、すべてのイーサネットマルチキャ
ストアドレスを受け入れるように設定されなくてはなりません。
On each interface over which this protocol is being run, the router
MUST enable reception of the link-scope "all MLDv2-capable routers"
multicast address from all sources, and MUST perform the multicast
address listener part of MLDv2 for that address on that interface.
このプロトコルが動作するそれぞれのインタフェース上で、ルータはすべて
のソースからのリンク範囲の「全ＭＬＤｖ２対応のルータ」マルチキャスト
アドレスの受信を可能にしなくてはならならず(MUST)、そしてそのインタ
フェース上のそのアドレスのためにＭＬＤｖ２のマルチキャストアドレス受
信者役割を行わなくてはなりません(MUST)。
Multicast routers only need to know that *at least one* node on an
attached link listens to packets for a particular multicast address
from a particular source; a multicast router is not required to
*individually* keep track of the interests of each neighboring node.
(Nevertheless, see Appendix A2 item 1 for discussion.)
マルチキャストルータは接続したリンク上で、特定のソースからの特定のマ
ルチキャストアドレスのパケットを受信する、*少なくとも１つ*のノードを
知る必要があるだけです；マルチキャストルータは*個々*の隣接するノード
の受信を記録・追跡するように要求されません。（にもかかわらず、議論の
ため、付録Ａ２の１項を見てください。）
MLDv2 is backward compatible with the MLDv1 protocol. For a detailed
description of compatibility issues see section 8.
ＭＬＤｖ２はＭＬＤｖ１プロトコルと後方互換性があります。互換性の詳細
な記述は８章を見ます。
7.1. Conditions for MLD Queries
7.1. ＭＬＤ問合せのための状態
The behavior of a router that implements the MLDv2 protocol depends
on whether there are several multicast routers on the same subnet, or
not. If it is the case, a querier election mechanism (described in
section 7.6.2) is used to elect a single multicast router to be in
Querier state. All the multicast routers on the subnet listen to the
messages sent by multicast address listeners, and maintain the same
multicast listening information state, so that they can quickly and
correctly take over the querier functionality, should the present
Querier fail. Nevertheless, it is only the Querier that sends
periodical or triggered query messages on the subnet.
ＭＬＤｖ２プロトコルを実行するルータの行動は、同じサブネット上に、い
くつかのマルチキャストルータがあるかどうかによります。もしそうである
なら、（７.６.２章で記述する）問合者選出メカニズムが一つのマルチキャ
ストルータを問合者状態に選出するために使われます。サブネット上のすべ
てのマルチキャストルータはマルチキャストアドレス受信者によって送られ
るメッセージを受信し、そして同じマルチキャスト受信情報状態を維持しま
す、それでもし現在の問合者が故障したなら、すばやく正確に問合者機能を
引き継ぐことができます。にもかかわらず、周期的あるいはトリガの問合せ
メッセージをサブネット上に送るのは問合者だけです。
The Querier periodically sends General Queries to request Multicast
Address Listener information from an attached link. These queries
are used to build and refresh the Multicast Address Listener state of
routers on attached links.
問合者はマルチキャストアドレス受信者情報を要求するために、接続リンク
から周期的に一般問合せを送ります。これらの問合せは接続リンク上のルー
タにマルチキャストアドレス受信者状態を形成し更新するために使われます。
Nodes respond to these queries by reporting their Multicast Address
Listening state (and set of sources they listen to) with Current
State Multicast Address Records in MLDv2 Multicast Listener Reports.
ノードが、ＭＬＤｖ２マルチキャスト受信者報告で、現在の状態マルチキャ
ストアドレスレコードのマルチキャストアドレス受信状態（と受信するソー
スのリスト）を報告することによって、これらの質問に返答します。
As a listener of a multicast address, a node may express interest in
listening or not listening to traffic from particular sources. As
the desired listening state of a node changes, it reports these
changes using Filter Mode Change Records or Source List Change
Records. These records indicate an explicit state change in a
multicast address at a node in either the Multicast Address Record's
source list or its filter mode. When Multicast Address Listening is
terminated at a node or traffic from a particular source is no longer
desired, the Querier must query for other listeners of the multicast
address or of the source before deleting the multicast address (or
source) from its Multicast Address Listener state and pruning its
traffic.
マルチキャストアドレス受信者として、ノードが特定のソースからのトラ
フィックを受信する、あるいは受信しないと表現するかもしれません。ノー
ドの望ましい受信状態が変化する時、これらの変更をフィルタモード変更レ
コードあるいはソースリスト変更レコードを使うことで報告します。これら
のレコードはノードにおいてマルチキャストアドレスに対するマルチキャス
トアドレスレコードのソースリストかフィルタモードの明示的な状態変更を
示します。ノードでマルチキャストアドレス受信を止めるか、あるいは特定
のソースからのトラフィックが望まれない時、問合者はそのマルチキャスト
アドレス受信者状態からマルチキャストアドレス（あるいはソース）を削除
して、そしてそのトラフィック削減する前にマルチキャストアドレスのある
いはソースの他の受信者のために質問しなくてはなりません。
To enable all nodes on a link to respond to changes in multicast
address listening, the Querier sends specific queries. A Multicast
Address Specific Query is sent to verify that there are no nodes that
listen to the specified multicast address or to "rebuild" the
listening state for a particular multicast address. Multicast
Address Specific Queries are sent when the Querier receives a State
Change Record indicating that a node ceases to listen to a multicast
address. They are also sent in order to enable a fast transition of
a router from EXCLUDE to INCLUDE mode, in case a received State
Change Record motivates this action.
リンク上のすべてのノードが受信マルチキャストアドレスの変更に返答する
のを可能にするために、問合者は特定の問合せを送ります。マルチキャスト
アドレス特定問合せが指定されたマルチキャストアドレスを受信するノード
がないことを確かめるか、あるいは特定のマルチキャストアドレスの受信状
態を「再建」するために送られます。マルチキャストアドレス特定問合せは、
問合者が、ノードがマルチキャストアドレスの受信をやめたことを示してい
る状態変更レコードを受け取る時に、送られます。それらは、受信状態変更
レコードがルータをEXCLUDEからINCLUDEモードに移行させる際に、この行動
をすばやく可能にするために送られます。
A Multicast Address and Source Specific Query is used to verify that
there are no nodes on a link which listen to traffic from a specific
set of sources. Multicast Address and Source Specific Queries list
sources for a particular multicast address which have been requested
to no longer be forwarded. This query is sent by the Querier in
order to learn if any node listens to packets sent to the specified
multicast address, from the specified source addresses. Multicast
Address and Source Specific Queries are only sent in response to
State Change Records and never in response to Current State Records.
Section 5.1.13 describes each query in more detail.
マルチキャストアドレスとソース特定問合せがリンク上に特定のソース集合
からのトラフィックを受信するノードがないことを確かめるために使われま
す。マルチキャストアドレスとソース特定問合せは転送の中止を要請された
特定のマルチキャストアドレスのためのソースをリストアップします。この
問合せは指定されたソースアドレスから、指定されたマルチキャストアドレ
ス宛のパケットをノードが受信するかどうか学ぶための問合者によって送ら
れます。マルチキャストアドレスとソース特定問合せは、現在の状態レコー
ドに応えてではなく、状態変更レコードに応えて送るだけす。５.１.１３章
が各質問のより細部を記述します。
7.2. MLD State Maintained by Multicast Routers
7.2. マルチキャストルータの維持するＭＬＤ状態
Multicast routers that implement the MLDv2 protocol keep state per
multicast address per attached link. This multicast address state
consists of a filter mode, a list of sources, and various timers. For
each attached link on which MLD runs, a multicast router records the
listening state for that link. That state conceptually consists of a
set of records of the form:
ＭＬＤｖ２プロトコルを実行するマルチキャストルータが接続するリンク毎
にマルチキャストアドレス毎に状態を維持します。このマルチキャストアド
レス状態はフィルタモードとソースと種々なタイマのリストから成り立ちま
す。ＭＬＤが動作するそれぞれの接続リンクで、マルチキャストルータがそ
のリンクの受信状態を記録します。その状態は概念的に以下の形式のレコー
ドの集合から成り立ちます：
(IPv6 multicast address, Filter Timer,
Router Filter Mode, (source records) )
(ＩＰｖ６マルチキャストアドレス、フィルタタイマ、
ルータフィルタモード、(ソースレコード) )
Each source record is of the form:
(IPv6 source address, source timer)
それぞれのソースレコードが以下の形式です：
(ＩＰｖ６ソースアドレス、ソースタイマ)
If all sources for a multicast address are listened to, an empty
source record list is kept with the Router Filter Mode set to
EXCLUDE. This means that nodes on this link want all sources for
this multicast address to be forwarded. This is the MLDv2 equivalent
of an MLDv1 listening state.
もしすべてのマルチキャストアドレスのソースから受信するなら、空のソー
スレコードリストがEXCLUDEルータフィルタモード集合で維持されます。これ
はこのリンク上のノードが全てのソースからのこのマルチキャストアドレス
を転送される事を望むことを意味します。これはＭＬＤｖ１受信状態のＭＬ
Ｄｖ２同等物です。
7.2.1. Definition of Router Filter Mode
7.2.1. ルータフィルタモードの定義
To reduce internal state, MLDv2 routers keep a filter mode per
multicast address per attached link. This filter mode is used to
summarize the total listening state of a multicast address to a
minimum set such that all nodes' listening states are respected. The
filter mode may change in response to the reception of particular
types of Multicast Address Records or when certain timer conditions
occur. In the following sections, we use the term "Router Filter
Mode" to refer to the filter mode of a particular multicast address
within a router. Section 7.4 describes the changes of the Router
Filter Mode per Multicast Address Record received.
内部状態を減らすために、ＭＬＤｖ２ルータが接続リンク毎にマルチキャス
トアドレス毎にフィルタモードを維持します。このフィルタモードは、すべ
てのノードの受信を考慮した最小集合に、マルチキャストアドレスの完全な
受信状態を要約するために使われます。特定のタイプのマルチキャストアド
レスレコードあるいはある特定のタイマ状態が存在する時の受信によりフィ
ルタモードが変化するかもしれません。次章で、我々はルータの中で特定の
マルチキャストアドレスのフィルタモードを参照するために用語「ルータ
フィルタモード」を使います。７.４章がレコードが受信したマルチキャスト
アドレス毎のルータフィルタモードの変更を記述します。
A router is in INCLUDE mode for a specific multicast address on a
given interface if all the listeners on the link interested in that
address are in INCLUDE mode. The router state is represented through
the notation INCLUDE (A), where A is called the "Include List". The
Include List is the set of sources that one or more listeners on the
link have requested to receive. All the sources from the Include
List will be forwarded by the router. Any other source that is not
in the Include List will be blocked by the router.
もし特定のマルチキャストアドレスを受信する全てのリンク上の受信者が
INCLUDEモードなら、ルータがそのインタフェースの特定のマルチキャストア
ドレスでINCLUDEモードです。ルータ状態はINCLUDE (A)と表記します、ここ
でＡは「組込リスト」と呼ばれます。組込リストは１つ以上のリンク上の受
信者が受信したいと頼んだソースの集合です。組込リストのすべてのソース
はルータにによって転送されるでしょう。組込リスト以外のソースはルータ
に止められるでしょう。
A router is in EXCLUDE mode for a specific multicast address on a
given interface if there is at least one listener in EXCLUDE mode
interested in that address on the link. Conceptually, when a
Multicast Address Record is received, the Router Filter Mode for that
multicast address is updated to cover all the requested sources using
the least amount of state. As a rule, once a Multicast Address
Record with a filter mode of EXCLUDE is received, the Router Filter
Mode for that multicast address will be set to EXCLUDE. Nevertheless,
if all nodes with a multicast address record having filter mode set
to EXCLUDE cease reporting, it is desirable for the Router Filter
Mode for that multicast address to transition back to INCLUDE mode.
This transition occurs when the Filter Timer expires, and is
explained in detail in section 7.5.
もし特定のマルチキャストアドレスを受信するリンク上にうち少なくとも１
つのEXCLUDEモードの受信者がいれば、ルータはそのインタフェース上の特定
のマルチキャストアドレスに対してEXCLUDEモードです。概念的に、マルチキャ
ストアドレスレコードを受信する時、そのマルチキャストアドレスのための
ルータフィルタモードは最少量の状態を使って、すべての求められたソースを
カバーするように更新されます。規則として、EXCLUDEフィルタモードのマルチ
キャストアドレスレコードを受信すると、そのマルチキャストアドレスのルー
ターフィルタモードはEXCLUDEに設定されるでしょう。にもかかわらず、もしす
べてのEXCLUDEフィルタモードのマルチキャストアドレスレコードを持つノード
が報告を停止するなら、そのマルチキャストアドレスのルータフィルタモード
をINCLUDEモードに移行することは望ましいです。この移行は、フィルタタイマ
がタイムアウトするときに起こり、７.５章で詳細を説明します。
When the router is in EXCLUDE mode, the router state is represented
through the notation EXCLUDE (X,Y), where X is called the "Requested
List" and Y is called the "Exclude List". All sources, except those
from the Exclude List, will be forwarded by the router. The
Requested List has no effect on forwarding. Nevertheless, it has to
be maintained for several reasons, as explained in section 7.2.3.
ルータ EXCLUDEモードにある時、ルータ状態はEXCLUDE (X,Y)で上限されます。
ここでＸはは「要求リスト」と呼ばれます、そしてＹが「除外リスト」と呼
ばれます。除外リストからの以外は、すべてのソースはルータによって転送
されるでしょう。要求リストは転送に対する効果を持っていません。にもか
かわらず、それは、７.２.３章で説明したように、いくつかの理由のために
維持されなければなりません。
The exact handling of both the INCLUDE and EXCLUDE mode router state,
according to the received reports, is presented in details in Tables
7.4.1 and 7.4.2.
INCLUDEとEXCLUDEモードルータ状態の正確な取り扱いは、受信報告に従い、
表７.４.１と７.４.２に詳細を提示します。
7.2.2. Definition of Filter Timers
7.2.2. フィルタタイマの定義
The Filter Timer is only used when the router is in EXCLUDE mode for
a specific multicast address, and it represents the time for the
Router Filter Mode of the multicast address to expire and switch to
INCLUDE mode. A Filter Timer is a decrementing timer with a lower
bound of zero. One Filter Timer exists per multicast address record.
Filter Timers are updated according to the types of Multicast Address
Records received.
フィルタタイマは、ルータが特定のマルチキャストアドレスでEXCLUDEモード
にある時にだけ使います、そしてこれはマルチキャストアドレスのルータフィ
ルタモードの期限が切れて、INCLUDEモードに切り替える時を表します。フィ
ルタタイマがゼロを下限として減少するタイマです。マルチキャストアドレ
スレコード毎に１つのフィルタタイマが存在します。フィルタタイマはマル
チキャストアドレスレコードの受信タイプに従って更新されます。
If a Filter Timer expires, with the Router Filter Mode for that
multicast address being EXCLUDE, it means that there are no more
listeners in EXCLUDE mode on the attached link. At this point, the
router transitions to INCLUDE filter mode. Section 7.5 describes the
actions taken when a Filter Timer expires while in EXCLUDE mode.
マルチキャストアドレスのルータフィルタモードがEXCLUDEの時、もしフィル
タタイマがタイムアウトするなら、これは接続するリンクにEXCLUDEモードの
受信者がいないことを意味します。この時点で、ルータはINCLUDEフィルタモー
ドに移行します。７.５章が、フィルタタイマがEXCLUDEモードである時にタ
イムアウトしたときの行動を記述します。
The following table summarizes the role of the Filter Timer. Section
7.4 describes the details of setting the Filter Timer per type of
Multicast Address Record received.
次の表はフィルタタイマの役割を要約します。７.４章が受信したマルチキャ
ストアドレスレコードタイプ毎に、フィルタタイマの設定の細部を記述します。
Router Filter
Filter Mode Timer Value Actions/Comments
ルータフィルタモード フィルタタイマ値 動作／コメント
----------- ----------------- ----------------
INCLUDE Not Used All listeners in
INCLUDE mode.
使用しない 全受信者がINCLUDEモード
EXCLUDE Timer > 0 At least one listener
in EXCLUDE mode.
少なくとも１受信者が
EXCLUDEモード
EXCLUDE Timer == 0 No more listeners in
EXCLUDE mode for the
multicast address.
If the Requested List
is empty, delete
Multicast Address
Record. If not, switch
to INCLUDE filter mode;
the sources in the
Requested List are
moved to the Include
List, and the Exclude
List is deleted.
このマルチキャストアドレス
のEXCLUDEモードの受信者はな
し。もし要求リストが空であ
るなら、マルチキャストアド
レスレコードを削除してくだ
さい。もしそうでなければ、
フィルタモードをINCLUDEに交
換してください；要求リスト
のソースは組込リストに移動
します、そして除外リストは
削除されます。
7.2.3. Definition of Source Timers
7.2.3. ソースタイマの定義
A Source Timer is a decrementing timer with a lower bound of zero.
One Source Timer is kept per source record. Source timers are
updated according to the type and filter mode of the Multicast
Address Record received. Section 7.4 describes the setting of source
timers per type of Multicast Address Records received.
ソースタイマはゼロを下限とした減少することタイマです。１つのソースタ
イマがソースレコード毎に保持されます。ソースタイマが受信したマルチキャ
ストアドレスレコードのタイプとフィルタモードに従って更新されます。
７.４章が受信したマルチキャストアドレスレコードのタイプ毎にソースタ
イマの設定を記述します。
In the following, abbreviations are used for several variables (all
of which are described in detail in section 9). The variable MALI
stands for the Multicast Address Listening Interval, which is the
time in which multicast address listening state will time out. The
variable LLQT is the Last Listener Query Time, which is the total
time the router should wait for a report, after the Querier has sent
the first query. During this time, the Querier should send [Last
Member Query Count]-1 retransmissions of the query. LLQT represents
the "leave latency", or the difference between the transmission of a
listener state change and the modification of the information passed
to the routing protocol.
以下で、いくつかの変数で省略が使われます（そのすべてが９章の詳細で記
述されます）。変数MALIはマルチキャストアドレス受信間隔を表し、そして
これはマルチキャストアドレス受信状態がタイムアウトする時です。変数
LLQTは最終受信者問合せ時間で、これは問合者が最初の問合せを送った後、
ルータが報告を待つべき合計時間です。この間に、問合者は［最終メンバ質
問カウント］-1の質問の再送を行うべきです。LLQTは「離脱遅延」、あるい
は受信者状態変化の送信と、ルーティングプロトコルに渡した情報の修正の
差をあらわします。
If the router is in INCLUDE filter mode, a source can be added to the
current Include List if a listener in INCLUDE mode sends a Current
State or a State Change Report which includes that source. Each
source from the Include List is associated with a source timer that
is updated whenever a listener in INCLUDE mode sends a report that
confirms its interest in that specific source. If the timer of a
source from the Include List expires, the source is deleted from the
Include List. If there are no more source records left, the
multicast address record is deleted from the router.
もしルータがINCLUDEフィルタモードなら、もしINCLUDEモードの受信者がソー
スを含む現在状態報告あるいは状態変更報告を送るなら、ソースを現在の現
在の組込リストに追加できます。それぞれの組込リストのソースはソースタ
イマと結び付けられ、ソースタイマは、INCLUDEモードの受信者がそのソース
に対しての受信を確証する報告を送る時はいつでも更新されるます。もし組
込リストのソースのタイマがタイムアウトするなら、ソースは組込リストか
ら削除されます。もし残されたソースレコードがないなら、マルチキャスト
アドレスレコードはルータから削除されます。
Besides this "soft leave" mechanism, there is also a "fast leave"
scheme in MLDv2; it is also based on the use of source timers. When
a node in INCLUDE mode expresses its desire to stop listening to a
specific source, all the multicast routers on the link lower their
timer for that source to a small interval of LLQT milliseconds. The
Querier then sends then a Multicast Address and Source Specific
Query, to verify whether there are other listeners for that source on
the link, or not. If a corresponding report is received before the
timer expires, all the multicast routers on the link update their
source timer. If not, the source is deleted from the Include List.
The handling of the Include List, according to the received reports,
is detailed in Tables 7.4.1 and 7.4.2.
この「ソフト離脱」メカニズムのほかに、ＭＬＤｖ２に同じく「速い休暇」
があります；これは同じくソースタイマの使用に基づいています。INCLUDE
モードのノードが特定のソースからの受信をやめる事を表現する時、リンク
上のすべてのマルチキャストルータは、LLQTミリセカンドの小さい時間分、
ソースのタイマを減らします。問合者はリンクの上にそのソースの他の受信
者がいるかどうか確かめるために、マルチキャストアドレスとソース特定問
合せを送ります。もしタイマがタイムアウトする前に対応する報告を受信す
るなら、リンク上のすべてのマルチキャストルータはソースタイマを更新し
ます。もしそうでなければ、ソースは組込リストから削除されます。組込リ
ストの取り扱いは、受信報告に依存して、表７.４.１と７.４.２で詳述され
ます。
Source timers are treated differently when the Router Filter Mode for
a multicast address is EXCLUDE. For sources from the Requested List
the source timers have running values; these sources are forwarded by
the router. For sources from the Exclude List the source timers are
set to zero; these sources are blocked by the router. If the timer
of a source from the Requested List expires, the source is moved to
the Exclude List. The router informs then the routing protocol that
there is no longer a listener on the link interested in traffic from
this source.
ソースタイマは、マルチキャストアドレスのルーターフィルタモードが
EXCLUDEである時は、扱いが違なります。要求リストのソースのソースタイマ
は実行値を持ちます；これらのソースはルータによって転送されます。除外
リストのソースはソースタイマがゼロに設定されます；これらのソースはルー
タによって止められます。もし要求リストのソースのタイマがタイムアウト
するなら、ソースは除外リストに動かされます。ルータはこのソースからの
トラフィックを受信する受信者がリンク上にいないとルーティングプロトコ
ルに通知します。
The router has to maintain the Requested List for two reasons:
ルータは２つの理由で要求リストをサポートしなければなりません：
o To keep track of sources that listeners in INCLUDE mode listen to.
This is necessary in order to assure a seamless transition of the
router to INCLUDE mode, when there will be no listener in EXCLUDE
mode left. This transition should not interrupt the flow of
traffic to the listeners in INCLUDE mode still interested in that
multicast address. Therefore, at the moment of the transition,
the Requested List should represent the set of sources that nodes
in INCLUDE mode have explicitly requested.
o INCLUDEモードで受信者が受信するソースを記録・追跡するために。これ
はEXCLUDEモードの受信者がいなくなるときにINCLUDEモードにルータのス
ムーズな移行を保証するために必要です。この移行はINCLUDEモードでの
そのマルチキャストアドレスを受信する受信者のトラフィックの流れを中
断するべきではありません。それ故に、移行の際に、要求リストは
INCLUDEモードのノードが明示的に要求するソースの集合の代理を務める
べきです。
When the router switches to INCLUDE mode, the sources in the
Requested List are moved to the Include List, and the Exclude List
is deleted. Before the switch, the Requested List can contain an
inexact guess at the sources that listeners in INCLUDE mode listen
to - might be too large or too small. These inexactitudes are due
to the fact that the Requested List is also used for fast blocking
purposes, as described below. If such a fast blocking is
required, some sources may be deleted from the Requested List (as
shown in Tables 7.4.1 and 7.4.2) in order to reduce router state.
Nevertheless, in each such case the Filter Timer is updated as
well. Therefore, listeners in INCLUDE mode will have enough time,
before an eventual switching, to reconfirm their interest in the
eliminated source(s), and rebuild the Requested List accordingly.
The protocol ensures that when a switch to INCLUDE mode occurs,
the Requested List will be accurate. Details about the transition
of the router to INCLUDE mode are presented in Appendix A3.
ルータがINCLUDEモードに切り替わる時、要求リストのソースは組込リス
トに動かされます、そして除外リストは削除されます。切り替え前に、要
求リストはINCLUDEモードの受信者が受信するソースの不正確な推測を含
ます−大きすぎか小さすぎかもしれません。これらの不正確さは、下に記
述されるように、要求リストが速い阻止の目的でも使われる事実のためで
す。もしこのような速い阻止が必要とされるなら、あるソースがルータ状
態を減らすため要求リストから（表７.４.１と７.４.２に示されるように）
削除されるかもしれません。にもかかわらず、どの場合もフィルタタイマ
が更新されます。それ故に、INCLUDEモードの受信者が、最終切り替え前
に、排除されたソースに対する受信を確認して、そしてそれ相応に要求リ
ストを再建する十分な時間を持つでしょう。プロトコルはINCLUDEモード
への切り替えが起こる時、要求リストが正確であるであろうことを保証し
ます。INCLUDEモードへのルータ移行についての詳細が付録Ａ３で提出さ
れます。
o To allow a fast blocking of previously unblocked sources. If the
router receives a report that contains such a request, the
concerned sources are added to the Requested List. Their timers
are set to a small interval of LLQT milliseconds, and a Multicast
Address and Source Specific Query is sent by the Querier, to check
whether there are nodes on the link still interested in those
sources, or not. If no node confirms its interest in receiving a
specific source, the timer of that source expires. Then, the
source is moved from the Requested List to the Exclude List. From
then on, the source will be blocked by the router.
o 前に送信を始めたソースをすばやく止めることを許すために。もしルータ
がこのような要請を含んでいる報告を受け取るなら、問題のソースはは要
求リストに加えられます。それらのタイマーはＬＬＱＴミリ秒の小さい間
隔に設定されます、そしてまだリンクの上にそれらのソースに興味を持っ
たノードがあるかどうか調べるために、マルチキャストアドレスとソース
特定の問合せが問合者によって行われます。もしノードがその、特定のソー
スを受けることに対しての興味を示さないなら、そのソースのタイマはタ
イムアウトします。それから、ソースは要求リストから除外リストに動か
されます。その時から、ソースはルータによって止められます。
The handling of the EXCLUDE mode router state, according to the
received reports, is detailed in Tables 7.4.1 and 7.4.2.
受信報告によるEXCLUDEモードルータ状態の取り扱いは、表７.４.１と
７.４.２で詳述されます。
When the Router Filter Mode for a multicast address is EXCLUDE,
source records are only deleted when the Filter Timer expires, or
when newly received Multicast Address Records modify the source
record list of the router.
マルチキャストアドレスのルータフィルタモードがEXCLUDEである時、ソース
レコードはフィルタタイマがタイムアウトする時、あるいは新たに受信した
マルチキャストアドレスレコードがルータのソースレコードリストを修正す
る時にだけ削除されます。
7.3. MLDv2 Source Specific Forwarding Rules
7.3. ＭＬＤｖ２ソース固有転送規則
When a multicast router receives a datagram from a source destined to
a particular multicast address, a decision has to be made whether to
forward the datagram on an attached link or not. The multicast
routing protocol in use is in charge of this decision, and should use
the MLDv2 information to ensure that all sources/multicast addresses
that have listeners on a link are forwarded to that link. MLDv2
information does not override multicast routing information; for
example, if the MLDv2 filter mode for a multicast address is EXCLUDE,
a router may still forward packets for excluded sources to a transit
link.
マルチキャストルータが特定のマルチキャストアドレス宛のソースからのデー
タグラムを受け取る時、接続リンク上にデータグラムを転送するべきかどう
か決断がされなければなりません。使用中のマルチキャストルーティングプ
ロトコルはこの決定の責任があり、そしてリンク上に受信者がいるすべての
ソース／マルチキャストアドレスがそのリンクに転送されることを保証する
ためにＭＬＤｖ２情報を使うべきです。ＭＬＤｖ２情報はマルチキャストルー
ティング情報より優先ではありません；例えば、もしマルチキャストアドレ
スのＭＬＤｖ２フィルタモードがEXCLUDEであるなら、ルータが転送リンクに
対象外のソースのパケットを転送してもよいです。
To summarize, the following table describes the forwarding
suggestions made by MLDv2 to the routing protocol for traffic
originating from a source destined to a multicast address. It also
summarizes the actions taken upon the expiration of a source timer
based on the Router Filter Mode of the multicast address.
要約すると、次の表は、ソースからマルチキャストアドレス宛のトラフィッ
クのルーティングプロトコルへの、ＭＬＤｖ２からの転送提案を記述します。
これは同じくマルチキャストアドレスのルータフィルタモードに基づいてソー
スタイマのタイムアウト時の行動を要約します。
Router
Filter Mode Source Timer Value Action
ルータ ソースタイマ値 行動
フィルタモード
----------- ------------------ ------
INCLUDE TIMER > 0 Suggest to forward traffic
from source
ソースからのトラフィックの転送
を提案。
INCLUDE TIMER == 0 Suggest to stop forwarding
traffic from source and
remove source record. If
there are no more source
records, delete multicast
address record
ソースからのトラヒックの転送の
停止の提案とソースレコードの削
除。もしこれ以上のソースレコー
ドがないなら、マルチキャストア
ドレスレコードを削除。
EXCLUDE TIMER > 0 Suggest to forward traffic
from source
ソースからのトラフィックの転送
を提案。
EXCLUDE TIMER == 0 Suggest to not forward
traffic from source. Move
the source from the
Requested List to the
Exclude List (DO NOT remove
source record)
ソースからのトラフィックを転送
しない事を提案してください。ソー
スを要求リストから除外リストに
動かしてください（ソースレコー
ドを削除しないこと）。
EXCLUDE No Source Element Suggest to forward traffic
from all sources
すべてのソースからのトラフィッ
クの転送を提案。
7.4. Action on Reception of Reports
7.4. 報告受信時の行動
Upon reception of an MLD message that contains a Report, the router
checks if the source address of the message is a valid link-local
address, if the Hop Limit is set to 1, and if the Router Alert option
is present in the Hop-By-Hop Options header of the IPv6 packet. If
any of these checks fails, the packet is dropped. If the validity of
the MLD message is verified, the router starts to process the Report.
報告を含むＭＬＤメッセージを受信したルータはメッセージのソースアドレ
スが正当なリンクローカルアドレスであるかどうか、ホップ限界が１に設定
されているかどうか、ルータ警告オプションがＩＰｖ６パケットのホップ毎
オプションヘッダに存在しているかどうか調べます。もしこれらの検査のど
れかが失敗するなら、パケットは廃棄されます。もしＭＬＤメッセージの正
当性が確かめられるなら、ルータは報告を処理し始めます。
7.4.1. Reception of Current State Records
7.4.1. 現在状態レコードの受信
When receiving Current State Records, a router updates both its
Filter Timer and its source timers. In some circumstances, the
reception of a type of multicast address record will cause the Router
Filter Mode for that multicast address to change. The table below
describes the actions, with respect to state and timers, that occur
to a router's state upon reception of Current State Records.
現在状態レコードを受信する時、ルータがそのフィルタタイマとそのソース
タイマの両方を最新のものにします。ある状況で、１つのタイプのマルチキャ
ストアドレスレコードの受信はそのマルチキャストアドレスのルータフィル
タモードの変更を起こすでしょう。下記の表は現在状態レコードを受信した
ルータの状態とタイマに関する行動を記述します。
If the router is in INCLUDE filter mode for a multicast address, we
will use the notation INCLUDE (A), where A denotes the associated
Include List. If the router is in EXCLUDE filter mode for a
multicast address, we will use the notation EXCLUDE (X,Y), where X
and Y denote the associated Requested List and Exclude List
respectively.
もしルータがマルチキャストアドレスに対しINCLUDEフィルタモードであるな
ら、我々は表記INCLUDE(A)を使い、Aが関連する組込リストを示します。もし
ルータがマルチキャストアドレスに対しEXCLUDEフィルタモードであるなら、
我々は表記EXCLUDE(X,Y)を使い、ここでXとYがそれぞれ関係する要求リスト
と除外リストを示します。
Within the "Actions" section of the router state tables, we use the
notation '(A)=J', which means that the set A of source records should
have their source timers set to value J. 'Delete (A)' means that the
set A of source records should be deleted. 'Filter Timer = J' means
that the Filter Timer for the multicast address should be set to
value J.
ルータ状態表の「行動」部で、我々は表記'(A)=J'を使います、これはソース
レコード集合Aは値がJのソースタイマを持つことを意味します。'Delete (A)'
はソースレコード集合Aが削除されるべきことを意味します。'Filter Timer
= J'はマルチキャストアドレスのフィルタタイマにJを設定すべきことを意味
します。
Router State Report Received New Router State Actions
ルータ状態 受信報告 新しいルータ状態 行動
------------ --------------- ---------------- -------
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI
INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0
Delete (A-B)
Filter Timer=MALI
EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=MALI
EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI
Delete (X-A)
Delete (Y-A)
Filter Timer=MALI
7.4.2. Reception of Filter Mode Change and Source List Change Records
7.4.2. フィルタモード変更とソースリスト変更レコードの受信
When a change in the global state of a multicast address occurs in a
node, the node sends either a Source List Change Record or a Filter
Mode Change Record for that multicast address. As with Current State
Records, routers must act upon these records and possibly change
their own state to reflect the new listening state of the link.
マルチキャストアドレスのグローバルな状態変更がノードで起こる時、ノー
ドはそのマルチキャストアドレスのソースリスト変更レコードあるいはフィ
ルタモード変更レコードを送ります。現在の状態レコードと同じように、ルー
タがリンクの新しい受信状態を反映するためにこれらのレコードに対して行
動を起こして、できる限りそれら自身の状態を変えなくてはなりません。
The Querier must query sources or multicast addresses that are
requested to be no longer forwarded. When a router queries or
receives a query for a specific set of sources, it lowers its source
timers for those sources to a small interval of Last Listener Query
Time milliseconds. If multicast address records are received in
response to the queries which express interest in listening the
queried sources, the corresponding timers are updated.
問合者はもう転送されないように要請されるソースあるいはマルチキャスト
アドレスを問い合わせなくてはなりません。ルータがソースの特定の集合の
問合せをするか問い合わせを受け取る時、最終受信者問合せ時間ミリ秒へ、
それらのソースのソースタイマを下げます。もし問合せに対する、質問され
たものの受信を表現する、マルチキャストアドレスレコードを受信するなら、
対応するタイマーは更新されます。
Multicast Address Specific queries can also be used in order to
enable a fast transition of a router from EXCLUDE to INCLUDE mode, in
case a received Multicast Address Record motivates this action. The
Filter Timer for that multicast address is lowered to a small
interval of Last Listener Query Time milliseconds. If any multicast
address records that express EXCLUDE mode interest in the multicast
address are received within this interval, the Filter Timer is
updated and the suggestion to the routing protocol to forward the
multicast address stands without any interruption. If not, the
router will switch to INCLUDE filter mode for that multicast address.
マルチキャストアドレス固有の問合せは、受信マルチキャストアドレスレコー
ドがこの行動を求める場合に備えて、 EXCLUDEからINCLUDEモードへのルータ
の速い移行を可能にするために使うことができます。そのマルチキャストア
ドレスのためのフィルタタイマは最後の受信者質問時間ミリ秒の小さい間隔
に下げられます。もしマルチキャストアドレスに対してEXCLUDEモード受信を
表現するマルチキャストアドレスレコードがこの間隔の内に受け取られるな
ら、フィルタタイマは更新されます、そしてマルチキャストアドレスを転送
するためのルーティングプロトコルへの提案は妨害なしに発生します。もし
そうでなければ、ルータはそのマルチキャストアドレスをINCLUDEフィルタモー
ドに変えるでしょう。
During the query period (i.e., Last Listener Query Time milliseconds)
the MLD component in the router continues to suggest to the routing
protocol to forward traffic from the multicast addresses or sources
that are queried. It is not until after Last Listener Query Time
milliseconds without receiving a record that expresses interest in
the queried multicast address or sources that the router may prune
the multicast address or sources from the link.
問合せ期間（すなわち、最終受信者問合せ時間ミリ秒）にルータのＭＬＤコ
ンポーネントは、ルーティングプロトコルにトラフィックを転送するべきマ
ルチキャストアドレスあるいはソースを示唆し続けます。最終受信者問合せ
時間ミリ秒後に、照会されたマルチキャストアドレスかソースに対する受信
を表現するレコードを受け取らなければ、ルータはリンクからマルチキャス
トアドレスあるいはソースを削除してもよいです。
The following table describes the changes in multicast address state
and the action(s) taken when receiving either Filter Mode Change or
Source List Change Records. This table also describes the queries
which are sent by the Querier when a particular report is received.
次の表は、フィルタモード変化あるいはソースリスト変更レコードを受け取
る時、マルチキャストアドレス状態変化と行動を記述します。この表はは同
じく、特定の報告を受信する時、問合者によって送られる質問を記述します。
We use the following notation for describing the queries that are
sent. We use the notation 'Q(MA)' to describe a Multicast Address
Specific Query to the MA multicast address. We use the notation
'Q(MA,A)' to describe a Multicast Address and Source Specific Query
to the MA multicast address with source list A. If source list A is
null as a result of the action (e.g. A*B), then no query is sent as a
result of the operation.
我々は送る質問を記述するために次の表記を使います。我々はＭＡマルチキャ
ストアドレスへのマルチキャストアドレス特定問合せを記述するために表記
'Q(MA)'を使います。我々はソースリストＡからＭＡマルチキャストアドレ
スへのマルチキャストアドレスとソース特定問合せを記述するために表記
'Q(MA,A)'を使います。もしソースリストＡが行動の結果として空であるな
ら（例えばA*B)、オペレーションの結果として質問は送られません。
In order to maintain protocol robustness, queries defined in the
Actions column of the table below need to be transmitted [Last
Listener Query Count] times, once every [Last Listener Query
Interval] period.
プロトコルの強靭性のために、下記の表の行動欄で定義された質問は、
[Last Listener Query Interval]間隔で、[Last Listener Query Count]回
送信します。
If while scheduling new queries, there are already pending queries to
be retransmitted for the same multicast address, the new and pending
queries have to be merged. In addition, received host reports for a
multicast address with pending queries may affect the contents of
those queries. Section 7.6.3. describes the process of building and
maintaining the state of pending queries.
もし新しい問合せをする時に、すでに同じマルチキャストアドレスの再送待
ちの問合せがあるなら、新しいのと、再送待ちの問合せは合併されなければ
なりません。加えて、再送待ちの問合せがあるマルチキャストアドレスへの
受信ホスト報告がそれらの問合せの中身に影響を与えるかもしれません。
７.６.３章が再送待ちの質問の状態を形成して、持続するプロセスを記述し
ます。
Router State Report Received New Router State Actions
------------ --------------- ---------------- -------
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=MALI
INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(MA,A*B)
INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Send Q(MA,A*B)
Filter Timer=MALI
INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=MALI
Send Q(MA,A-B)
EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=MALI
EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y) =
Filter Timer
Send Q(MA,A-Y)
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y) =
Filter Timer
Delete (X-A)
Delete (Y-A)
Send Q(MA,A-Y)
Filter Timer=MALI
EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=MALI
Send Q(MA,X-A)
Send Q(MA)
7.5. Switching Router Filter Modes
7.5. ルータフィルタモード切り替え
The Filter Timer is used as a mechanism for transitioning the Router
Filter Mode from EXCLUDE to INCLUDE.
フィルタタイマはルーターフィルタモードをEXCLUDEからINCLUDEへ移行させ
るメカニズムとして使われます。
When a Filter Timer expires with a Router Filter Mode of EXCLUDE, a
router assumes that there are no nodes with a *filter mode* of
EXCLUDE present on the attached link. Thus, the router transitions
to INCLUDE filter mode for the multicast address.
フィルタタイマがEXCLUDEのルータフィルタモードでタイムアウトする時、ルー
タは接続リンク上にEXCLUDEの*フィルタモード*ノードがないと想定します。
それで、ルータはマルチキャストアドレスに対してINCLUDEフィルタモードに
移行します。
A router uses the sources from the Requested List as its state for
the switch to a filter mode of INCLUDE. Sources from the Requested
List are moved in the Include List, while sources from the Exclude
List are deleted. For example, if a router's state for a multicast
address is EXCLUDE(X,Y) and the Filter Timer expires for that
multicast address, the router switches to filter mode of INCLUDE with
state INCLUDE(X). If at the moment of the switch the Requested List
(X) is empty, the multicast address record is deleted from the
router.
ルータがINCLUDEフィルタモードに切り替ると要求リストからのソースをその
状態として使います。要求リストのソースが組込リストで動かされる、他方
除外リストのソースが削除されます。例えば、もしルータのマルチキャスト
アドレスの状態がEXCLUDE(X,Y)で、そのマルチキャストアドレスのフィルタ
タイマがタイムアウトするなら、ルータはINCLUDE(X)状態のINCLUDEフィルタ
モードに切り替えます。もし切り替え時点で要求リスト(X)が空であるなら、
マルチキャストアドレスレコードはルータから削除されます。
7.6. Action on Reception of Queries
7.6. 質問の受信時の行動
Upon reception of an MLD message that contains a Query, the router
checks if the source address of the message is a valid link-local
address, if the Hop Limit is set to 1, and if the Router Alert option
is present in the Hop-By-Hop Options header of the IPv6 packet. If
any of these checks fails, the packet is dropped.
問合せを含んでいるＭＬＤメッセージを受信したら、ルータはメッセージの
ソースアドレスが正当なリンクローカルアドレスであるかどうか、ホップ限
界が１に設定されてるかどうか、そしてルータ警告オプションがＩＰｖ６パ
ケットのホップ毎オプションヘッダに存在しているかどうか調べます。もし
これらのチェックのいずれかが失敗するなら、パケットは廃棄されます。
If the validity of the MLD message is verified, the router starts to
process the Query.
もしＭＬＤメッセージの正当性が確かめられるなら、ルータは質問を処理し
始めます。
7.6.1. Timer Updates
7.6.1. タイマ更新
MLDv2 uses the Suppress Router-Side Processing flag to ensure
robustness, as explained in section 2.1. When a router sends or
receives a query with a clear Suppress Router-Side Processing flag,
it must update its timers to reflect the correct timeout values for
the multicast address or sources being queried. The following table
describes the timer actions when sending or receiving a Multicast
Address Specific or Multicast Address and Source Specific Query with
the Suppress Router-Side Processing flag not set.
ＭＬＤｖ２は、２.１章で説明したように、強靭性を保証するためにルータ側
処理抑制フラグを使います。ルータが明確なルータ側処理抑制フラグで質問
を送るか受ける時、マルチキャストアドレスあるいはソースを尋ねらること
に関して正しいタイムアウト値を反映するためにそのタイマを更新しなくて
はなりません。次の表はルータ側処理抑制フラグが設定されていないマルチ
キャストアドレスあるいはマルチキャストアドレスとソース特定問合せを送
信あるいは受信する時のタイマ行動を記述します。
Query Action
問合 行動
----- ------
Q(MA,A) Source Timers for sources in A are lowered to LLQT
ＡのソースのソースタイマをLLQTに下げます。
Q(MA) Filter Timer is lowered to LLQT
フィルタタイマはLLQTに下げられます。
When a router sends or receives a query with the Suppress Router-Side
Processing flag set, it will not update its timers.
ルータがルータ側処理抑制フラグの設定された質問を送信するか受信する時、
タイマを更新しないでしょう。
7.6.2. Querier Election
7.6.2. 問合者選出
MLDv2 elects a single router per subnet to be in Querier state; all
the other routers on the subnet should be in Non-Querier state. MLDv2
uses the same querier election mechanism as MLDv1, namely the IPv6
address. When a router starts operating on a subnet, by default it
considers itself as being the Querier. Thus, it sends several
General Queries separated by a small time interval (see sections 9.6
and 9.7 for details).
ＭＬＤｖ２はサブネット毎に１つのルータが問合者状態であるように選出し
ます；サブネット上のすべての他のルータは非問合者状態にあるべきです。
ＭＬＤｖ２はＭＬＤｖ１と同じ問合者選出メカニズム、すなわちＩＰｖ６ア
ドレスを用います。ルータがサブネットで動作し始める時、デフォルトで自
分自身を問合者であると考えます。それで、いくつかの一般問合せを短い間
隔で送ります（詳細は９.６章と９.７章を見てください）。
When a router receives a query with a lower IPv6 address than its
own, it sets the Other Querier Present timer to Other Querier Present
Timeout; if it was previously in Querier state, it switches to Non-
Querier state and ceases to send queries on the link. After the
Other Querier Present timer expires, it should re-enter the Querier
state and begin sending General Queries.
ルータが自分自身より小さいＩＰｖ６アドレスで問合せを受け取る時、他問
合者存在タイマを他問合者存在タイムアウトに設定します；もし前に問合者
状態にあったなら、非問合者状態に変わり、そして問合せをリンクの上に送
ることをやめます。他の問合者存在タイマがタイムアウトすると、問合者状
態に再びなり、一般問合せを送り始めるべきです。
All MLDv2 queries MUST be sent with the FE80::/64 link-local source
address prefix. Therefore, for the purpose of MLDv2 querier
election, an IPv6 address A is considered to be lower than an IPv6
address B if the interface ID represented by the last 64 bits of
address A, in big-endian bit order, is lower than the interface ID
represented by the last 64 bits of address B.
すべてのＭＬＤｖ２の質問はFE80::/64リンクローカルソースアドレスプレ
フィックスで送られなくてはなりません(MUST)。そのために、ＭＬＤｖ２問
合者選出の目的で、もしアドレスＡの最後の６４ビットで表されるインタ
フェースＩＤが、アドレスＢの最後の６４ビットで表されるインタフェー
スＩＤより、ビッグエンディアンビット順で小さいなら、ＩＰｖ６アドレ
スＡがＩＰｖ６アドレスＢより小さいと考えられます。
7.6.3. Building and Sending Specific Queries
7.6.3. 特定の質問の構築と送信
7.6.3.1. Building and Sending Multicast Address Specific Queries
7.6.3.1. マルチキャストアドレス特定問合せの構築と質問
When a table action "Send Q(MA)" is encountered, the Filter Timer
must be lowered to LLQT. The Querier must then immediately send a
Multicast Address Specific query as well as schedule [Last Listener
Query Count - 1] query retransmissions to be sent every [Last
Listener Query Interval], over [Last Listener Query Time].
表の行動"Send Q(MA)"に遭遇する時、フィルタタイマはLLQTに下げられな
くてはなりません。問合者はすぐにマルチキャストアドレス特定質問を送
らなければなりません、そして[最終受信者問合せ時間]以上に、[最終受信
者問合せ間隔]で[最終受信者問合せカウント-1]回の再送を予定しなけれ
ばなりません。
When transmitting a Multicast Address Specific Query, if the Filter
Timer is larger than LLQT, the "Suppress Router-Side Processing" bit
is set in the query message.
マルチキャストアドレス特定問合せを伝達する時、もしフィルタタイマが
LLQTより大きいなら、問合せメッセージで「ルータ側処理抑制」ビットが設
定されています。
7.6.3.2. Building and Sending Multicast Address and Source Specific
Queries
7.6.3.2. マルチキャストアドレスとソース特定問合せの構築と送信
When a table action "Send Q(MA,X)" is encountered by the Querier in
the table in section 7.4.2, the following actions must be performed
for each of the sources in X that send to multicast address MA, with
source timer larger than LLQT:
７.４.２の表で問合者が表の行動"Send Q(MA,X)"に遭遇する時、次の行動が
マルチキャストアドレスMA宛に送る、LLQTより大きいソースタイマの各ソー
スXに対して行われなくてはなりません：
o Lower source timer to LLQT;
o LLQTにソースタイマを下げます；
o Add the sources to the Retransmission List;
o 再送リストにソースを追加します；
o Set the Source Retransmission Counter for each source to [Last
Listener Query Count].
o 各ソースのソース再送カウンタを[最終受信者質問カウント]に設定して
ください。
The Querier must then immediately send a Multicast Address and Source
Specific Query as well as schedule [Last Listener Query Count -1]
query retransmissions to be sent every [Last Listener Query
Interval], over [Last Listener Query Time]. The contents of these
queries are calculated as follows.
問合者すぐにマルチキャストアドレスとソース特定問合せを送り、[最終受
信者質問時間]で、各[最終受信者質問間隔]で[最終受信者質問カウンタ]回
の問合せ再送のスケジュールを組みます。これらの質問の内容は次のよう
に計算されます。
When building a Multicast Address and Source Specific Query for a
multicast address MA, two separate query messages are sent for the
multicast address. The first one has the "Suppress Router-Side
Processing" bit set and contains all the sources with retransmission
state (i.e., sources from the Retransmission List of that multicast
address), and timers greater than LLQT. The second has the "Suppress
Router-Side Processing" bit clear and contains all the sources with
retransmission state and timers lower or equal to LLQT. If either of
the two calculated messages does not contain any sources, then its
transmission is suppressed.
マルチキャストアドレスMAのためにマルチキャストアドレスとソース特定問
合せを構築する時、２つの別の質問メッセージがマルチキャストアドレスの
ために送られます。最初のが「ルータ側処理抑制」ビットが設定され、再送
状態でタイマがLLQTより大きい全てのソース（すなわち、そのマルチキャス
トアドレスの再送リストのソース）を含みます。第２のは「ルータ側処理抑
制」ビットがクリアされ、再送状態でタイマがLLQT以下の全てのソースを含
んでいます。もし２つの計算されたメッセージのいずれかがソースを含まな
いなら、その伝達は抑制されます。
Note: If a Multicast Address Specific query is scheduled to be
transmitted at the same time as a Multicast Address and Source
specific query for the same multicast address, then transmission of
the Multicast Address and Source Specific message with the "Suppress
Router-Side Processing" bit set may be suppressed.
ノート：もしマルチキャストアドレス特定問合せが、同じマルチキャストア
ドレスのマルチキャストアドレスとソース特定問合せと同時に再送になるな
ら、「ルータ側処理抑制」ビットが設定されたマルチキャストアドレスとソー
ス特定メッセージの送信は抑制されるかもしれません。
8. Interoperation with MLDv1
8. ＭＬＤｖ１との相互運用
MLD version 2 hosts and routers interoperate with hosts and routers
that have not yet been upgraded to MLDv2. This compatibility is
maintained by hosts and routers taking appropriate actions depending
on the versions of MLD operating on hosts and routers within a
network.
ＭＬＤバージョン２ホストとルータがまだＭＬＤｖ２にアップグレードされ
ていないホストやルータと一緒に動作します。この互換性はホストとルータ
がネットワーク上のＭＬＤのバージョンに適切な行動をする事で維持されま
す。
8.1. Query Version Distinctions
8.1. 問合せバージョンの区別
The MLD version of a Multicast Listener Query message is determined
as follows:
マルチキャスト受信者問合メッセージのＭＬＤバージョンは次のように決意
します：
MLDv1 Query: length = 24 octets
ＭＬＤｖ１問合：長さ＝２４オクテット
MLDv2 Query: length >= 28 octets
ＭＬＤｖ２問合：長さ≧２８オクテット
Query messages that do not match any of the above conditions (e.g., a
Query of length 26 octets) MUST be silently ignored.
上記の条件のいずれとも一致しない質問メッセージ（例えば、長さ２６オク
テットの質問）は静かに無視されなくてはなりません(MUST)。
8.2. Multicast Address Listener Behavior
8.2. マルチキャストアドレス受信者行動
8.2.1. In the Presence of MLDv1 Routers
8.2.1. ＭＬＤｖ１ルータがある場合
In order to be compatible with MLDv1 routers, MLDv2 hosts MUST
operate in version 1 compatibility mode. MLDv2 hosts MUST keep state
per local interface regarding the compatibility mode of each attached
link. A host's compatibility mode is determined from the Host
Compatibility Mode variable which can be in one of the two states:
MLDv1 or MLDv2.
ＭＬＤｖ１ルータと両立できるために、ＭＬＤｖ２ホストがバージョン１互
換モードで動作しなくてはなりません(MUST)。ＭＬＤｖ２ホストがそれぞれ
の接続リンクの互換モードに関してローカルインタフェース毎に状態を維持
しなくてはなりません(MUST)。ホストの互換モードは２つの状態のどちらか
にあるホスト互換モード変数で決定されます：ＭＬＤｖ１あるいはＭＬＤｖ２。
The Host Compatibility Mode of an interface is set to MLDv1 whenever
an MLDv1 Multicast Address Listener Query is received on that
interface. At the same time, the Older Version Querier Present timer
for the interface is set to Older Version Querier Present Timeout
seconds. The timer is re-set whenever a new MLDv1 Query is received
on that interface. If the Older Version Querier Present timer
expires, the host switches back to Host Compatibility Mode of MLDv2.
インタフェースのホスト互換性モードは、ＭＬＤｖ１マルチキャストアドレ
ス受信者問合せをそのインタフェース上で受け取る時にＭＬＤｖ１に設定さ
れます。同時に、インタフェースの旧バージョン問合存在タイマは現在の旧
バージョン問合者存在タイムアウト秒に設定されます。タイマは、新しい
ＭＬＤｖ１問合せをそのインタフェース上に受け取る毎に設定されます。も
し旧バージョン問合者存在タイマがタイムアウトするなら、ホストは
ＭＬＤｖ２のホスト互換モードに変わります。
When Host Compatibility Mode is MLDv2, a host acts using the MLDv2
protocol on that interface. When Host Compatibility Mode is MLDv1, a
host acts in MLDv1 compatibility mode, using only the MLDv1 protocol,
on that interface.
ホスト互換モードがＭＬＤｖ２である時、ホストがそのインタフェース上で
ＭＬＤｖ２プロトコルを使って行動をします。ホスト互換モードがＭＬＤｖ
１である時、ホストがそのインタフェースの上でＭＬＤｖ１プロトコルだけ
を使っうＭＬＤｖ１互換モードで行動します。
An MLDv1 Querier will send General Queries with the Maximum Response
Code set to the desired Maximum Response Delay, i.e., the full range
of this field is linear and the exponential algorithm described in
section 5.1.3. is not used.
ＭＬＤｖ１問合者が一般問合せで最大応答コードに望ましい最大応答遅延を
送るでしょう、すなわち、このフィールドの最大範囲は線形で、そして
５.１.３章.で記述された指数のアルゴリズムは使われません。
Whenever a host changes its compatibility mode, it cancels all its
pending responses and retransmission timers.
ホストがその互換モードを変える時は、すべてその実施待ちの回答と再送タ
イマを中止します。
8.2.2. In the Presence of MLDv1 Multicast Address Listeners
8.2.2. ＭＬＤｖ１マルチキャストアドレス受信者が存在する場合
An MLDv2 host may be placed on a link where there are MLDv1 hosts. A
host MAY allow its MLDv2 Multicast Listener Report to be suppressed
by a Version 1 Multicast Listener Report.
ＭＬＤｖ２ホストがＭＬＤｖ１ホストがあるリンク上に置かれるかもしれま
せん。ホストがバージョン１マルチキャスト受信者報告で抑制されるＭＬＤ
ｖ２マルチキャスト受信者報告を許すかもしれません(MAY)。
8.3. Multicast Router Behavior
8.3. マルチキャストルーター行動
8.3.1. In the Presence of MLDv1 Routers
8.3.1. ＭＬＤｖ１ルータがある場合
MLDv2 routers may be placed on a network where there is at least one
MLDv1 router. The following requirements apply:
ＭＬＤｖ２ルータは少なくとも１つのＭＬＤｖ１ルータがあるネットワーク
上に置かれるかもしれません。次の必要条件は適用されます：
o If an MLDv1 router is present on the link, the Querier MUST use
the lowest version of MLD present on the network. This must be
administratively assured. Routers that desire to be compatible
with MLDv1 MUST have a configuration option to act in MLDv1 mode;
if an MLDv1 router is present on the link, the system
administrator must explicitly configure all MLDv2 routers to act
in MLDv1 mode. When in MLDv1 mode, the Querier MUST send periodic
General Queries truncated at the Multicast Address field (i.e., 24
bytes long), and SHOULD also warn about receiving an MLDv2 Query
(such warnings must be rate-limited). The Querier MUST also fill
in the Maximum Response Delay in the Maximum Response Code field,
i.e., the exponential algorithm described in section 5.1.3. is not
used.
o もしＭＬＤｖ１ルータがリンクの上に存在しているなら、問合者はネット
ワーク上に存在する最も低いＭＬＤのバージョンを使わなくてはなりませ
ん(MUST)。これは管理的に確実であるに違いありません。ＭＬＤｖ１と両
立を望むルータはＭＬＤｖ１モードで行動をする設定オプションを持って
いなくてはなりません(MUST)；もしＭＬＤｖ１ルータがリンク上に存在し
ているなら、システム管理者は明示的にすべてのＭＬＤｖ２ルータをＭＬ
Ｄｖ１モードで動作するように設定しなくてはなりません。ＭＬＤｖ１モー
ド時に、問合者は周期的に、マルチキャストアドレスフィールドを切り捨
てた（すなわち、２４バイト長の）、一般問合せを送らなければならず
(MUST)、そしてＭＬＤｖ２質問の受信に対して警告をすべきです(SHOULD)
（このような警告は率を限定されるに違いありません）。問合者は最大の
回答コードフィールドに、同じく最大の回答遅延を記入しなくてはなりま
せん(MUST)、すなわち５.１.３章で記述された指数アルゴリズムは使われ
ません。
o If a router is not explicitly configured to use MLDv1 and receives
an MLDv1 General Query, it SHOULD log a warning. These warnings
MUST be rate-limited.
o もしルータが明示的にＭＬＤｖ１を使うように設定されず、そしてＭＬＤ
ｖ１一般問合せを受信するなら、警告をログファイルに書くべきです
(SHOULD)。これらの警告は率限定されているに違いありません(MUST)。
8.3.2. In the Presence of MLDv1 Multicast Address Listeners
8.3.2. ＭＬＤｖ１マルチキャストアドレス受信者が存在する場合
MLDv2 routers may be placed on a network where there are hosts that
have not yet been upgraded to MLDv2. In order to be compatible with
MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility
mode. MLDv2 routers keep a compatibility mode per multicast address
record. The compatibility mode of a multicast address is determined
from the Multicast Address Compatibility Mode variable, which can be
in one of the two following states: MLDv1 or MLDv2.
ＭＬＤｖ２ルータはＭＬＤｖ２に更新されていないホストがあるネットワー
ク上に置かれるかもしれません。ＭＬＤｖ１ホストと互換性のために、ＭＬ
Ｄｖ２ルータはバージョン１の互換モードで動作しなくてはなりません(MUST)。
ＭＬＤｖ２ルータがマルチキャストアドレスレコード毎に互換性モードを維
持します。マルチキャストアドレスの互換モードはマルチキャストアドレス
互換モード変数から決定され、そしてこれは２つの次の状態です：
ＭＬＤｖ１あるいはＭＬＤｖ２。
The Multicast Address Compatibility Mode of a multicast address
record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is
received for that multicast address. At the same time, the Older
Version Host Present timer for the multicast address is set to Older
Version Host Present Timeout seconds. The timer is re-set whenever a
new MLDv1 Report is received for that multicast address. If the
Older Version Host Present timer expires, the router switches back to
Multicast Address Compatibility Mode of MLDv2 for that multicast
address.
マルチキャストアドレスレコードのマルチキャストアドレス互換性モードは、
そのマルチキャストアドレスに対してＭＬＤｖ１マルチキャスト受信者報告
を受信したらＭＬＤｖ１に設定されます。同時に、マルチキャストアドレス
の旧バージョンホスト存在タイマは、旧バージョンホスト存在タイムアウト
秒に設定されます。タイマは、そのマルチキャストアドレスの新しいＭＬＤ
ｖ１報告を受信するたびにリセットされます。もし旧バージョンホスト存在
タイマがタイムアウトするなら、ルータはそのマルチキャストアドレスのマ
ルチキャストアドレス互換モードをＭＬＤｖ２に戻します。
Note that when a router switches back to MLDv2 Multicast Address
Compatibility Mode for a multicast address, it takes some time to
regain source-specific state information. Source-specific
information will be learned during the next General Query, but
sources that should be blocked will not be blocked until [Multicast
Address Listening Interval] after that.
ルータがマルチキャストアドレスに対してマルチキャストアドレス互換モー
ドをＭＬＤｖ２に戻すとき、ソース特定状態情報を回復するのにいくらかの
時間を要することを注意を払ってください。ソース特定情報が次の一般問合
せの間に学ばれるでしょう、しかし止めるべきソースはその後[マルチキャス
トアドレス受信者間隔]まで止まらないでしょう。
When Multicast Address Compatibility Mode is MLDv2, a router acts
using the MLDv2 protocol for that multicast address. When Multicast
Address Compatibility Mode is MLDv1, a router internally translates
the following MLDv1 messages for that multicast address to their
MLDv2 equivalents:
マルチキャストアドレス互換モードがＭＬＤｖ２である時、ルータがそのマ
ルチキャストアドレスでＭＬＤｖ２プロトコルを使って行動をします。マル
チキャストアドレス互換モードがＭＬＤｖ１である時、ルータはそのマルチ
キャストアドレスのＭＬＤｖ１メッセージを内部でＭＬＤｖ２同等物に翻訳
します：
MLDv1 Message MLDv2 Equivalent
ＭＬＤｖ１メッセージ ＭＬＤｖ２同等物
------------- ----------------
Report IS_EX( {} )
Done TO_IN( {} )
MLDv2 BLOCK messages are ignored, as are source-lists in TO_EX()
messages (i.e., any TO_EX() message is treated as TO_EX( {} )). On
the other hand, the Querier continues to send MLDv2 queries,
regardless of its Multicast Address Compatibility Mode.
ＭＬＤｖ２ブロックメッセージがTO_EX()メッセージのソースリストとして無
視されます（すなわち、どんなTO_EX()メッセージもTO_EX( {} )として扱わ
れます）。他方問合者は、そのマルチキャストアドレス互換モードにかかわ
らず、ＭＬＤｖ２問合せの送信を継続します。
9. List of Timers, Counters, and their Default Values
9. タイマとカウンタとそれらのデフォルト値のリスト
Most of these timers are configurable. If non-default settings are
used, they MUST be consistent among all nodes on a single link. Note
that parentheses are used to group expressions to make the algebra
clear.
これらのタイマの大部分が設定可能です。もし非デフォルト設定が使われる
なら、それらはひとつのリンク上にすべてのノードで整合しなくてはなりま
せん(MUST)。明確化のために表現をまとめるカッコが使われることに注意を
払ってください。
9.1. Robustness Variable
9.1. 信頼性変数
The Robustness Variable allows tuning for the expected packet loss on
a link. If a link is expected to be lossy, the value of the
Robustness Variable may be increased. MLD is robust to [Robustness
Variable] - 1 packet losses. The value of the Robustness Variable
MUST NOT be zero, and SHOULD NOT be one. Default value: 2.
信頼性変数はリンク上で予想されるパケット損失の調整を許します。もしリ
ンクのロスが大きいと期待されるなら、信頼性変数の値は増やされるかもし
れません。ＭＬＤは[信頼性変数-1]のパケット損失に対して強靭です。信頼
性変数の値はゼロであってはならならず(MUST NOT)、１であるべきではあり
ません(SHOULD NOT)。デフォルト価値：２。
9.2. Query Interval
9.2. 質問間隔
The Query Interval variable denotes the interval between General
Queries sent by the Querier. Default value: 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.
[質問間隔]を変えることによって、管理者ががリンク上のＭＬＤメッセージ
数を調整してもよいです；より大きい値がＭＬＤの質問をより少なくします。
9.3. Query Response Interval
9.3. 質問回答間隔
The Maximum Response Delay used to calculate the Maximum Response
Code inserted into the periodic General Queries. Default value:
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 host 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].
[質問回答間隔]を変えることによって、管理者がリンク上のＭＬＤメッセー
ジの集中度を調整してもよいです；より大きい値が、ホスト回答をより大き
い間隔に広げるので、トラフィックをより少なく集中させます。[質問回答間
隔]で表される秒数は[質問間隔]より少いに違いありません。
9.4. Multicast Address Listening Interval
9.4. マルチキャストアドレス受信間隔
The Multicast Address Listening Interval (MALI) is the amount of time
that must pass before a multicast router decides there are no more
listeners of a multicast address or a particular source on a link.
This value MUST be ([Robustness Variable] times [Query Interval])
plus [Query Response Interval].
マルチキャストアドレス受信間隔（ＭＡＬＩ）は、マルチキャストルータが
リンクにこれ以上のマルチキャストアドレスあるいは特定のソースの受信者
がいないと決定する前に、待たなくてはならない時間量です。この値は
（[信頼性変数]×[質問間隔]）＋[質問応答間隔]に違いありません(MUST)。
9.5. Other Querier Present Timeout
9.5. 他問合者存在タイムアウト
The Other Querier Present Timeout is the length of time that must
pass before a multicast router decides that there is no longer
another multicast router which should be the Querier. This value
MUST be ([Robustness Variable] times ([Query Interval]) plus (one
half of [Query Response Interval]).
他問合者存在タイムアウトは、マルチキャストルータが問合者であるべき他
のマルチキャストルータがないと決定する前に待たなくてはならない時間の
長さです。この値は（[信頼性変数]×[質問間隔]）＋（[質問応答間隔]の
２分の１）に違いありません(MUST)。
9.6. Startup Query Interval
9.6. 始動質問間隔
The Startup Query Interval is the interval between General Queries
sent by a Querier on startup. Default value: 1/4 the [Query
Interval].
始動質問間隔は問合者が起動時に送る一般問合せの間隔です。デフォルト値：
[質問間隔]の１／４。
9.7. Startup Query Count
9.7. 起動質問カウント
The Startup Query Count is the number of Queries sent out on startup,
separated by the Startup Query Interval. Default value: [Robustness
Variable].
起動質問カウントは起動時に、起動質問間隔で、送られる質問の数です。
デフォルト値：[Robustness Variable]。
9.8. Last Listener Query Interval
9.8. 最終受信者質問間隔
The Last Listener Query Interval is the Maximum Response Delay used
to calculate the Maximum Response Code inserted into Multicast
Address Specific Queries sent in response to Version 1 Multicast
Listener Done messages. It is also the Maximum Response Delay used
to calculate the Maximum Response Code inserted into Multicast
Address and Source Specific Query messages. Default value: 1000 (1
second).
最終受信者質問間隔は、バージョン１マルチキャスト受信者完了メッセージ
に応えて送られるマルチキャストアドレス特定問合せに挿入される最大回答
コードを計算するために使われます。これはまたマルチキャストアドレスと
ソース特定問合せメッセージに挿入された最大回答コードを計算するために
使われる最大応答遅延です。デフォルト値：１０００（１秒）。
Note that for values of LLQI greater than 32.768 seconds, a limited
set of values can be represented, corresponding to sequential values
of Maximum Response Code. When converting a configured time to a
Maximum Response Code value, it is recommended to use the exact value
if possible, or the next lower value if the requested value is not
exactly representable.
３２.７６８秒より大きいＬＬＱＩ値のために、最大回答コードの連続的な
値に対応して、限定された値だけが表現できる事に注意を払ってください。
設定された時間を最大の回答コード値に換える時、もし可能なら正確な値を、
もし求められた値を正確に表示することができないなら次のより低い値を使
うことが勧められます。
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 a multicast address or source.
この価値はリンクの「離脱遅延」を修正するために調整されるかもしれませ
ん。値を減らすとマルチキャストアドレスあるいはソースの最後の受信者の
離脱の検出する時間を減らします。
9.9. Last Listener Query Count
9.9. 最終受信者質問カウント
The Last Listener Query Count is the number of Multicast Address
Specific Queries sent before the router assumes there are no local
listeners. The Last Listener Query Count is also the number of
Multicast Address and Source Specific Queries sent before the router
assumes there are no listeners for a particular source. Default
value: [Robustness Variable].
最終受信者質問カウントは、ルータがローカル受信者がいないと想定する前
に、送るマルチキャストアドレス特定問合せの数です。最終受信者質問せカ
ウントは、ルータが特定のソースの受信者がいないと想定する前に、送られ
るマルチキャストアドレスとソース特定質問の数です。デフォルト値：
[信頼性変数]。
9.10. Last Listener Query Time
9.10. 最終受信者質問時間
The Last Listener Query Time is the time value represented by the
Last Listener Query Interval, multiplied by [Last Listener Query
Count]. It is not a tunable value, but may be tuned by changing its
components.
最終受信者質問時間は、最終受信者質問間隔と[最終受信者質問カウント]の
積で表される時間値です。これは設定可能な値ではありませんが、コンポー
ネントを変えることで調整できるかもしれません。
9.11. Unsolicited Report Interval
9.11. 望まれない報告間隔
The Unsolicited Report Interval is the time between repetitions of a
node's initial report of interest in a multicast address. Default
value: 1 second.
望まれない報告間隔はマルチキャストアドレスに対するノードの受信の最初
の報告の間隔です。デフォルト値：１秒。
9.12. Older Version Querier Present Timeout
9.12. 旧版問合者存在タイムアウト
The Older Version Querier Present Timeout is the time-out for
transitioning a host back to MLDv2 Host Compatibility Mode. When an
MLDv1 query is received, MLDv2 hosts set their Older Version Querier
Present Timer to [Older Version Querier Present Timeout].
旧版問合者存在タイムアウトはホストがＭＬＤｖ２ホスト互換モードに戻る
までにタイムアウト時間です。ＭＬＤｖ１の質問を受信する時、ＭＬＤｖ２
ホストは旧版問合者存在タイマを[旧版問合者存在タイムアウト]に設定しま
す。
This value MUST be ([Robustness Variable] times (the [Query Interval]
in the last Query received)) plus ([Query Response Interval]).
この値は（[信頼性変数]×（最後の質問の[問合せ間隔]））＋
（[質問応答間隔]）に違いありません(MUST)。
9.13. Older Version Host Present Timeout
9.13. 旧版ホスト存在タイムアウト
The Older Version Host Present Timeout is the time-out for
transitioning a router back to MLDv2 Multicast Address Compatibility
Mode for a specific multicast address. When an MLDv1 report is
received for that multicast address, routers set their Older Version
Host Present Timer to [Older Version Host Present Timeout].
旧版ホスト存在タイムアウトは、ルータが特定のマルチキャストアドレスに
対してＭＬＤｖ２マルチキャストアドレス互換モードから戻るまでのタイム
アウトです。そのマルチキャストアドレスのＭＬＤｖ１報告を受信する時、
ルータはその旧版ホスト存在タイマを［旧版ホスト存在タイムアウト］に設
定します。
This value MUST be ([Robustness Variable] times [Query Interval])
plus ([Query Response Interval]).
この値は（[信頼性変数]×[質問間隔]）＋（[質問応答間隔]）に違いありま
せん(MUST)。
9.14. Configuring timers
9.14. タイマの設定
This section is meant to provide advice to network administrators on
how to tune these settings to their network. Ambitious router
implementations might tune these settings dynamically based upon
changing characteristics of the network.
この章は、どのようにネットワークのこれらの設定を調整するべきかについ
て、ネットワーク管理者に助言を供給することを意図します。意欲的なルー
タ実装がネットワークの特性に応じて動的にこれらの設定を調整するかもし
れません。
9.14.1. Robustness Variable
9.14.1. 信頼性変数
The Robustness Variable tunes MLD to expected losses on a link.
MLDv2 is robust to [Robustness Variable] - 1 packet losses, e.g., if
the Robustness Variable is set to the default value of 2, MLDv2 is
robust to a single packet loss but may operate imperfectly if more
losses occur. On lossy links, the value of the Robustness Variable
should be increased to allow for the expected level of packet loss.
However, increasing the value of the Robustness Variable increases
the leave latency of the link (the time between when the last
listener stops listening to a source or multicast address and when
the traffic stops flowing).
信頼性変数はリンク上で予想される損失に対してＭＬＤを調整します。ＭＬ
Ｄｖ２は[信頼性変数]−１のパケット損失に対して強靭で、例えば、もし信
頼性変数がデフォルト値の２に設定されるなら、ＭＬＤｖ２はひとつのパケッ
ト損失に対して強靭です、しかし、もしより多くの損失が起こるなら、不完
全に動作するかもしれません。損失の多いリンク上で、信頼性変数値はパケッ
ト損失の予想レベルを考慮して増加されるべきです。しかしながら、信頼性
変数値を増やすことはリンクの離脱遅延（最後の受信者がソースあるいはマ
ルチキャストアドレスの受信をやめる時からトラフィック流出が止まるまで
の時間）を増やします。
9.14.2. Query Interval
9.14.2. 質問間隔
The overall level of periodic MLD traffic is inversely proportional
to the Query Interval. A longer Query Interval results in a lower
overall level of MLD traffic. The value of the Query Interval MUST
be equal to or greater than the Maximum Response Delay used to
calculate the Maximum Response Code inserted in General Query
messages.
周期的なＭＬＤトラフィックの全体的なレベルは質問間隔逆比例します。よ
り長い質問間隔は全体的なＭＬＤトラフィックをより低いレベルにします。
問合せ間隔の値は一般問合せメッセージに挿入された最大回答コードを計算
するために使った最大応答遅延以上であるに違いありません(MUST)。
9.14.3. Maximum Response Delay
9.14.3. 最大応答遅延
The burstiness of MLD traffic is inversely proportional to the
Maximum Response Delay. A longer Maximum Response Delay will spread
Report messages over a longer interval. However, a longer Maximum
Response Delay in Multicast Address Specific and Multicast Address
And Source Specific Queries extends the leave latency (the time
between when the last listener stops listening to a source or
multicast address and when the traffic stops flowing.) The expected
rate of Report messages can be calculated by dividing the expected
number of Reporters by the Maximum Response Delay. The Maximum
Response Delay may be dynamically calculated per Query by using the
expected number of Reporters for that Query as follows:
ＭＬＤトラフィックの集中性は最大応答遅延に反比例しています。より長い
最大応答遅延がより長い間隔に報告メッセージを広めるでしょう。しかしな
がら、マルチキャストアドレス特定とマルチキャストアドレスとソース特定
問合せのより長い最大回答遅延は離脱遅延（最後の受信者がソースあるいは
マルチキャストアドレスの受信を止めてから、トラフィック流出が止まるま
での時間）を長くします。報告メッセージの期待された率は予想される報告
の数を最大応答遅延で割ることで計算できます。最大応答遅延は次のように
質問に対する報告の予想される数を使って、質問毎に動的に計算されるかも
しれません：
Query Type Expected number of Reporters
質問タイプ 予想される報告の数。
---------- ----------------------------
General Query All nodes on link
一般問合せ すべてのリンク上のノード。
Multicast Address Specific Query All nodes on the link that had
expressed interest in the
multicast address
マルチキャストアドレ マルチキャストアドレスに対して受
ス特定問合せ 信を示したすべてのリンク上のノード。
Multicast Address and Source All nodes on the link that had
Specific Query expressed interest in the source
and multicast address
マルチキャストアドレスと ソースとマルチキャストアドレスに
ソース特定問合せ 対受信を示したすべてのリンク上の
ノード。
A router is not required to calculate these populations or tune the
Maximum Response Delay dynamically; these are simply guidelines.
ルータがこれらの数を計算するか、あるいは動的に最大応答遅延を調整する
ように要求されません；これらはただ助言です。
10. Security Considerations
10. セキュリティの考察
We consider the ramifications of a forged message of each type. Note
that before processing an MLD message, nodes verify if the source
address of the message is a valid link-local address (or the
unspecified address), if the Hop Limit is set to 1, and if the Router
Alert option is present in the Hop-By-Hop Options header of the IPv6
packet. If any of these checks fails, the packet is dropped. This
defends the MLDv2 nodes from acting on forged MLD messages originated
off-link. Therefore, in the following we discuss only the effects of
on-link forgery.
我々はそれぞれのタイプの偽造されたメッセージの成り行きを考慮します。
ＭＬＤメッセージを処理する前に、ノードがメッセージのソースアドレスが
正当なリンクローカルアドレス（あるいは特定されていないアドレス）であ
るかどうか、ホップ限界が１に設定されるかどうか、そしてルータ警告オプ
ションがＩＰｖ６パケットのホップ毎オプションヘッダに存在しているかど
うか確かめることに注意を払ってください。もしこれらのチェックのどれか
が失敗するなら、パケットは廃棄されます。これはリンク外で偽造されたＭ
ＬＤメッセージによる動作からＭＬＤｖ２ノードを守ります。それ故に、以
下でただリンク上の偽造の効果だけを論じます。
10.1. Query Message
10.1. 質問メッセージ
A forged Query message from a machine with a lower IPv6 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
Multicast Listener Done Messages, traffic might flow to multicast
addresses with no listeners for up to [Multicast Address Listener
Interval].
現在の問合者より低いＩＰｖ６アドレスを持っている機械からの偽造された
質問メッセージは、問合者任務を偽造者に割り当てられさせるでしょう。も
し偽造者がそれ以上の質問メッセージを送らないなら、他のルータの他問合
者存在タイマはタイムアウトし、そして１つのルータが問合者の役割を再開
するでしょう。この間に、もし偽造者がマルチキャスト受信完了メッセージ
を無視するなら、トラフィックが最大[マルチキャストアドレス受信者間隔]
の間、受信者がいないマルチキャストアドレスが流れるかもしれません。
A forged Version 1 Query message will put MLDv2 listeners on that
link in MLDv1 Host Compatibility Mode. This scenario can be avoided
by providing MLDv2 hosts with a configuration option to ignore
Version 1 messages completely.
偽造された１版の問合せメッセージはリンク上のＭＬＤｖ２受信者をＭＬＤ
ｖ１ホスト互換モードにするでしょう。このシナリオは完全に１版メッセー
ジを無視する設定をＭＬＤｖ２ホストに提供することにで避けることができ
ます。
A DoS attack on a node could be staged through forged Multicast
Address and Source Specific Queries. The attacker can find out about
the listening state of a specific node with a general query. After
that it could send a large number of Multicast Address and Source
Specific Queries, each with a large source list and/or long Maximum
Response Delay. The node will have to store and maintain the sources
specified in all of those queries for as long as it takes to send the
delayed response. This would consume both memory and CPU cycles in
order to augment the recorded sources with the source lists included
in the successive queries.
偽装マルチキャストアドレスとソース特定問合せを通してノード上のサービ
ス妨害攻撃の可能性があります。攻撃者は一般的な質問で特定のノードの受
信状態を発見することができます。その後に、それぞれが大きなソースリス
トや長い最大応答遅延をもつ、多数のマルチキャストアドレスとソース特定
問合せを送ることができます。ノードはそれらすべての問合せで指定された
ソースを、遅延応答で指定された送信時まで、保存し維持しなければならな
いでしょう。これは連続した問合せに含まれるソースリストに記録されたソー
スを増により、メモリとＣＰＵサイクルの両方を消費するでしょう。
To protect against such a DoS attack, a node stack implementation
could restrict the number of Multicast Address and Source Specific
Queries per multicast address within this interval, and/or record
only a limited number of sources.
このようなサービス妨害攻撃から保護するために、ノードスタック実装がこ
の期間のマルチキャストアドレス毎にマルチキャストアドレスとソース特定
問合せの数を限定し、そして限定された数のソースのだけを記録できます。
10.2. Current State Report messages
10.2. 現在状態報告メッセージ
A forged Report message may cause multicast routers to think there
are listeners of a multicast address on a link when there are not.
Nevertheless, since listening to a multicast address on a host is
generally an unprivileged operation, a local user may trivially gain
the same result without forging any messages.
偽造された報告メッセージはマルチキャストルータにリンクに実際にはいな
いマルチキャストアドレス受信者がいると思わせるかもしれません。にもか
かわらず、ホスト上でマルチキャストアドレスを受信する事は一般に非特権
オペレーションであるので、ローカルユーザがメッセージを偽造せずに同じ
結果を得る事ができます。
A forged Version 1 Report Message may put a router into MLDv1
Multicast Address Compatibility Mode for a particular multicast
address, meaning that the router will ignore MLDv2 source specific
state messages. This can cause traffic to flow from unwanted sources
for up to [Multicast Address Listener Interval]. This can be solved
by providing routers with a configuration switch to ignore Version 1
messages completely. This breaks automatic compatibility with
Version 1 hosts, so it should only be used in situations where source
filtering is critical.
偽造された１版の報告メッセージは、ルータがＭＬＤｖ２ソース特定状態メッ
セージを無視することを意味し、特定のマルチキャストアドレスに対してルー
タをＭＬＤｖ１マルチキャストアドレス互換モードにするかもしれません。
これはトラフィックを最大[マルチキャストアドレス受信者間隔]の間、不要
なソースから流すことができます。これは完全に１版のメッセージを無視す
る設定スイッチをルータに提供することによって解決できます。これは１版
のホストとの自動的な互換性を失わせます、それでこれはソースフィルタが
重要な状態でだけ使うべきです。
10.3. State Change Report messages
10.3. 状態変更報告メッセージ
A forged State Change Report message will cause the Querier to send
out Multicast Address Specific or Multicast Address and Source
Specific Queries for the multicast address in question. This causes
extra processing on each router and on each listener of the multicast
address, but cannot cause loss of desired traffic.
偽造された状態変更報告メッセージは問合者にそのマルチキャストアドレス
のマルチキャストアドレス特定あるいはマルチキャストアドレスとソース特
定問合せを送らせるでしょう。これはそれぞれのルータとそれぞれのマルチ
キャストアドレス受信者に余分の処理を起こします、しかし望ましいトラ
フィックの損失を起こすことができません。
11. IANA Considerations
11. ＩＡＮＡの考慮
IANA has assigned the IPv6 link-local multicast address
FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described
in section 5.2.14. Version 2 Multicast Listener Reports will be sent
to this special address.
ＩＡＮＡは、５.２.１４章で記述されるように「全ＭＬＤｖ２対応のルータ」
と呼ばれる、ＩＰｖ６リンクローカルマルチキャストアドレス
FF02:0:0:0:0:0:0:16を割り当てました。２版マルチキャスト受信者報告が
この特別なアドレスに送られるでしょう。
In addition, IANA has assigned the ICMPv6 message type value of 143
for Version 2 Multicast Listener Report messages, as specified in
section 4.
加えて、ＩＡＮＡは、４章で指定されるように、２版マルチキャスト受信者
報告メッセージのためにＩＣＭＰｖ６メッセージタイプ値１４３を割り当て
ました。
12. References
12. 参考文献
12.1. Normative References
12.1. 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option," RFC 2711, October 1999.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture, RFC 3513, April 2003.
12.2. Informative References
12.2. 有益な参考文献
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source- Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
13. Acknowledgments
13. 謝辞
We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont,
Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark,
Shinsuke Suzuki, Margaret Wasserman, Bert Wijnen, and Remi Zara for
their valuable comments and suggestions on this document.
我々は貴重なコメントとこの文書の提案に対してHitoshi AsaedaとRandy
BushとFrancis DupontとTed HardieとRuss HousleyとKonstantin Kabassanov
とErik NordmarkとShinsuke SuzukiとMargaret WassermanとBert Wijnen
とRemi Zaraに感謝します。
APPENDIX A. Design Rationale
付録Ａ。 デザイン原理
A.1. The Need for State Change Messages
A.1. 状態変更メッセージの必要性
MLDv2 specifies two types of Multicast Listener Reports: Current
State and State Change. This section describes the rationale for the
need for both these types of Reports.
ＭＬＤｖ２はマルチキャスト受信者報告の２つの種類を指定します：現在状
態と状態変更。この章は両方のこれらのタイプの報告の必要性の原理を記述
します。
Routers need to distinguish Multicast Listener Reports that were sent
in response to Queries from those that were sent as a result of a
change in the per-interface state. Multicast Listener Reports that
are sent in response to Multicast Address Listener Queries are used
mainly to refresh the existing state at the router; they typically do
not cause transitions in state at the router. Multicast Listener
Reports that are sent in response to changes in the per-interface
state require the router to take some action in response to the
received report (see Section 7.4.).
ルータが問合せに応えて送られたマルチキャスト受信者報告をインターフェー
ス毎の状態の変更の結果として送られたのと区別する必要があります。マル
チキャストアドレス受信者問合に応えて送られるマルチキャスト受信者報告
は主にルータの既存の状態を更新するために使われます；それらは典型的に
ルータで状態遷移を起こしません。インターフェース毎の状態の変更に応え
て送られるマルチキャスト受信者報告がルータの受信した報告に応えてある
行動をとるように要求します（７.４章参照）。
The inability to distinguish between the two types of reports would
force a router to treat all Multicast Listener Reports as potential
changes in state and could result in increased processing at the
router as well as an increase in MLD traffic on the link.
報告の２つの種類を区別することができなければ、ルータはすべてのマルチ
キャスト受信者報告を状態変更の可能性があるものと取り扱うことになり、
そしてルータ処理同様にリンク上のＭＬＤトラフィックの増加をもたらすで
しょう。
A.2. Host Suppression
A.2. ホスト抑制
In MLDv1, a host would not send a pending multicast listener report
if a similar report was sent by another listener on the link. In
MLDv2, the suppression of multicast listener reports has been
removed. The following points explain this decision.
ＭＬＤｖ１で、もし類似の報告がリンク上の他の受信者から送られたなら、
ホストは予定したマルチキャスト受信者報告を送らないでしょう。ＭＬＤｖ
２で、マルチキャスト受信者報告の抑制は削除されました。次の点はこの決
定を説明します。
1. Routers may want to track per-host multicast listener status on an
interface. This would allow routers to implement fast leaves
(e.g., for layered multicast congestion control schemes), as well
as track listener status for possible security or accounting
purposes. The present specification does not require routers to
implement per-host tracking. Nevertheless, the lack of host
suppression in MLDv2 makes possible to implement either
proprietary or future standard behavior of multicast routers that
would support per-host tracking, while being fully interoperable
with MLDv2 listeners and routers that implement the exact behavior
described in this specification.
1. ルータがインタフェース上でホスト毎のマルチキャスト受信状態の追跡を
望むかもしれません。これはルータに即時離脱（例えば、層状マルチキャ
スト輻輳制御案）やセキュリティや課金のための受信者状態追跡の実行を
許すでしょう。現在の指定はルータにホスト毎の追跡を実装するように要
求しません。にもかかわらず、ＭＬＤｖ２でのホスト抑圧の欠如は、専用
もしくは将来の標準で、この仕様に完全に準拠するＭＬＤｖ２受信者とルー
タと協調動作可能なまま、ホスト毎の追跡を支援するルータを導入するこ
とが可能であるようにします。
2. Multicast Listener Report suppression does not work well on
bridged LANs. Many bridges and Layer2/Layer3 switches that
implement MLD snooping do not forward MLD messages across LAN
segments in order to prevent multicast listener report
suppression.
2. ブリッジＬＡＮでマルチキャスト受信者報告抑制がうまく機能しません。
ＭＬＤ覗き見をサポートする多数のブリッジや２層／３層スイッチが、マ
ルチキャスト受信者報告抑圧を妨げるため、ＬＡＮセグメントを越えるＭ
ＬＤメッセージを転送しません。
3. By eliminating multicast listener report suppression, hosts have
fewer messages to process; this leads to a simpler state machine
implementation.
3. マルチキャスト受信者報告抑圧を排除することによって、ホストが処理す
るメッセージが減ります；これはより単純な状態遷移を導きます。
4. In MLDv2, a single multicast listener report now bundles multiple
multicast address records to decrease the number of packets sent.
In comparison, the previous version of MLD required that each
multicast address be reported in a separate message.
4. ＭＬＤｖ２で、送信パケット数を減少させるためにひとつのマルチキャス
ト受信者報告に多数のマルチキャストアドレスレコードをまとめます。比
較すると、ＭＬＤの前のバージョンはそれぞれのマルチキャストアドレス
が別のメッセージで報告されることを要求しました。
A.3. Switching router filter modes from EXCLUDE to INCLUDE
A.3. EXCLUDEからINCLUDEへのルータフィルタモード切替
If on a link there are nodes in both EXCLUDE and INCLUDE modes for a
single multicast address, the router must be in EXCLUDE mode as well
(see section 7.2.1). In EXCLUDE mode, a router forwards traffic from
all sources except those in the Exclude List. If all nodes in
EXCLUDE mode cease to exist or to listen, it would be desirable for
the router to switch back to INCLUDE mode seamlessly, without
interrupting the flow of traffic to existing listeners.
もしリンクにひとつのマルチキャストアドレスに対してEXCLUDEとINCLUDEモー
ドの両方にノードがあるなら、ルータはEXCLUDEモードでなければなりません
（７.２.１章参照）。EXCLUDEモードで、ルータは除外リスト以外のすべての
ソースからのトラフィックを転送します。もしすべてのEXCLUDEモードのノー
ドが存在や受信をやめるなら、既存の受信トラフィック流を中断しないでス
ムーズにINCLUDEモードに切替わることはルータにとって望ましいでしょう。
One of the ways to accomplish this is for routers to keep track of
all sources that nodes that are in INCLUDE mode listen to, even
though the router itself is in EXCLUDE mode. If the Filter Timer for
a multicast address expires, it implies that there are no nodes in
EXCLUDE mode on the link (otherwise a multicast listener report from
that node would have refreshed the Filter Timer). The router can
then switch to INCLUDE mode seamlessly; sources from the Requested
List are moved to the Include List, while sources from the Exclude
List are deleted.
これを達成する方法の１つは、ルータ自身がEXCLUDEモードであっても、ルー
タがINCLUDEモードのノードの全てのソースを追跡することです。もしマルチ
キャストアドレスのフィルタタイマがタイムアウトするなら、それはリンク
にEXCLUDEモードにノードがないことを意味します（さもなければそのノード
からのマルチキャスト受信報告がフィルタタイマを更新したでしょう）。ルー
タはスムーズにINCLUDEモードに切替えることができます；要求リストのソー
スは組込リストに動かされる、他方除外リストのソースが削除されます。
APPENDIX B. Summary of Changes from MLDv1
付録Ｂ。 ＭＬＤｖ１からの変更の要約
The following is a summary of changes from MLDv1, specified in RFC
2710.
以下がＲＦＣ２７１０で指定されたＭＬＤｖ１からの変更の要約です。
o MLDv2 introduces source filtering.
o ＭＬＤｖ２はソースフィルタを導入します。
o The IP service interface of MLDv2 nodes is modified accordingly.
It enables the specification of a filter mode and a source list.
o ＭＬＤｖ２ノードのＩＰサービスインタフェースはそれ相応に修正されま
す。これはフィルタモードとソースリストの仕様を可能にします。
o An MLDv2 node keeps per-socket and per-interface multicast
listening states that include a filter mode and a source list for
each multicast address. This enables packet filtering based on a
socket's multicast reception state.
o ＭＬＤｖ２ノードがそれぞれのマルチキャストアドレスのためにフィルタ
モードとソースリストを含むソケット毎とインターフェース毎のマルチキャ
スト受信状態を保持します。これはソケットのマルチキャスト受信状態に
基づいたパケットフィルタリングを可能にします。
o MLDv2 state kept on routers includes a filter mode and a list of
sources and source timers for each multicast address that has
listeners on the link. MLDv1 routers kept only the list of
multicast addresses.
o ルータ上のＭＬＤｖ２状態は、リンク上に受信者がいるそれぞれのマルチ
キャストアドレスのためにフィルタモードとソースとソースタイマのリス
トを含みます。ＭＬＤｖ１ルータはただマルチキャストアドレスのリスト
だけを保持しました。
o Queries include additional fields (section 5.1).
o 質問が追加のフィールド（５.１章）を含みます。
o The S flag (Suppress Router-Side Processing) is included in
queries in order to fix robustness issues.
o Ｓフラグ（ルータ側処理抑制）は強靭性問題を直すための問合せに含めら
れます。
o The Querier's Robustness Variable and Query Interval Code are
included in Queries in order to synchronize all MLDv2 routers
connected to the same link.
o 問合者の信頼性変数と問合せ間隔コードは、同じリンクで接続したすべて
のＭＬＤｖ２ルータを同期させるために問合せに含められます。
o A new Query type (Multicast Address and Source Specific Query) is
introduced.
o 新しい質問タイプ（マルチキャストアドレスとソース特定問合せ）が導入
されます。
o The Maximum Response Delay is not directly included in the Query
anymore. Instead, an exponential algorithm is used to calculate
its value, based on the Maximum Response Code included in the
Query. The maximum value is increased from 65535 milliseconds to
about 140 minutes.
o 最大回答遅延は直接質問に含められません。その代わりに、問合せに含め
られた最大回答コードに基づいていてその値を計算するために、指数アル
ゴリズムが使われます。最大の値は６５５３５ミリ秒からおよそ１４０分
まで増やされます。
o Reports include Multicast Address Records. Information on the
listening state for several different multicast addresses can be
included in the same Report message.
o 報告がマルチキャストアドレスレコードを含みます。いくつかの異なるマ
ルチキャストアドレスのための受信状態情報を同じ報告メッセージに含め
ることができます。
o Reports are sent to the "all MLDv2-capable multicast routers"
address, instead of the multicast address the host listens to, as
in MLDv1. This facilitates the operation of layer-2 snooping
switches.
o 報告が、ＭＬＤｖ１でのホストが受信するマルチキャストアドレスの代わ
りに、「全ＭＬＤｖ２対応マルチキャストルータ」アドレスに送られます。
これは２層覗き見スイッチの運用を容易にします。
o There is no "host suppression", as in MLDv1. All nodes send
Report messages.
o ＭＬＤｖ１の「ホスト抑制」がありません。すべてのノードは報告メッセー
ジを送ります。
o Unsolicited Reports, announcing changes in receiver listening
state, are sent [Robustness Variable] times. RFC 2710 is less
explicit.
o 受信者の受信状態変更を公表する、望まれない報告は[信頼性変数]回、
送られます。ＲＦＣ２７１０はあいまいです。
o There are no Done messages.
o Ｄｏｎｅメッセージがありません。
o Interoperability with MLDv1 systems is achieved by MLDv2 state
operations.
o ＭＬＤｖ１システムとの互換性がＭＬＤｖ２状態運用によって成し遂げら
れます。
o In order to ensure interoperability, hosts maintain a Host
Compatibility Mode variable and an Older Version Querier Present
timer per interface. Routers maintain a Multicast Address
Compatibility Mode variable and an Older Version Host Present
timer per multicast address.
o 互換性を保証するために、ホストがインタフェース毎にホスト互換モード
変数と旧版問合者存在タイマを維持します。ルータがマルチキャストアド
レス毎にマルチキャストアドレス互換モード変数と旧バージョンホスト存
在タイマを維持します。
Editors' Contact Information
編集者への連絡情報
Rolland Vida
LIP6, Universite Pierre et Marie Curie
8, rue du Capitaine Scott
75015 Paris, France
Phone: +33-1.44.27.30.58
EMail: Rolland.Vida@lip6.fr
Luis Henrique Maciel Kosmalski Costa
LIP6, Universite Pierre et Marie Curie
8, rue du Capitaine Scott
75015 Paris, France
Phone: +33-1.44.27.30.58
EMail: Luis.Costa@lip6.fr
Authors' Addresses
著者のアドレス
This document was written by:
この文書は下記の者により書かれました：
Rolland Vida, LIP6
EMail: Rolland.Vida@lip6.fr
Luis Henrique Maciel Kosmalski Costa, LIP6
EMail: Luis.Costa@lip6.fr
Serge Fdida, LIP6
EMail: Serge.Fdida@lip6.fr
Steve Deering, Cisco Systems, Inc.
EMail: deering@cisco.com
Bill Fenner, AT&T Labs - Research
EMail: fenner@research.att.com
Isidor Kouvelas, Cisco Systems, Inc.
EMail: kouvelas@cisco.com
Brian Haberman, Caspian Networks
EMail: brian@innovationslab.net
This document is the translation of [RFC3376] for IPv6 semantics. It
was elaborated based on the translation of (RFC 2236) into [RFC2710].
この文書はＩＰｖ６意味論の[RFC3376]の解釈です。これは(RFC 2236)の
[RFC2710]への解釈に基づいて詳述されました。
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。