この文書はRFC3810の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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
       IPv6のためのマルチキャスト受信者探索2版(MLDv2)

Status of this Memo
この文書の状態


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (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.
   この文書はRFC2710を更新します、そしてこれはマルチキャスト受信
   者探索プロトコルの2版(MLDv2)を指定します。MLDは直接接続す
   るリンク上でマルチキャストの受信者の存在を見つけて、それらの隣接する
   ノードがどのマルチキャストアドレスを受信するか知るためにIPv6ルー
   タによって使われます。MLDv2はMLDv1と同時使用可能であるよう
   意図されます。MLDv2は特定のソースアドレスからの特定のマルチキャ
   ストアドレスだけ、あるいは特定のソースアドレス以外のすべてのソースア
   ドレスからの特定のマルチキャストアドレスだけノードが聞く報告をする能
   力を加えます。

Table of Contents
目次

   1.  Introduction
   1.  はじめに
   2.  Protocol Overview
   2.  プロトコル概観
   3.  The Service Interface for Requesting IP Multicast Reception
   3.  IPマルチキャスト受信を求めるサービスインタフェース
   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.  MLDv1との相互運用
   9.  List of Timers, Counters, and their Default Values
   9.  タイマとカウンタとそれらのデフォルト値のリスト
   10. Security Considerations
   10. セキュリティの考察
   11. IANA Considerations
   11. IANAの考慮
   12. References
   12. 参考文献
   13. Acknowledgments
   13. 謝辞
   APPENDIX A.  Design Rationale
   付録A。  デザイン原理
   APPENDIX B.  Summary of Changes from MLDv1
   付録B。  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.
   マルチキャスト受信者探索プロトコル(MLD)は、直接接続するリンク上
   のマルチキャストの受信者(すなわち、マルチキャストパケットを受信する
   ことを望むノード)の存在を見つけて、特にそれらの隣接するノードがどの
   マルチキャストアドレスを受信したいか知るためにIPv6ルータによって
   使われます。マルチキャストルータ自身が、マルチキャストアドレスの受信
   者であるかもしれないことに注意してください;この場合これは、一方でマ
   ルチキャストルーティングプロトコルに必要としたマルチキャストの受信者
   の情報を集めて、他方それ自身と他の隣接するマルチキャストルータに受信
   者の状態を伝えるために、プロトコルの「マルチキャストルータの役割」と
   「マルチキャストアドレスの受信者の役割」の両方を行います。

   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.
   この文書はMLDの2版を指定します。MLDの前の版は[RFC2710]で指定さ
   れます。この文書で我々はそれをMLDv1と述べるでしょう。MLDv2
   はIPv6のためのIGMPv3[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.
   MLDv2プロトコルは、MLDv1と比較して、「ソースフィルタリング」
   に対するサポート、すなわち、ソース特定マルチキャスト[RFC3569]のサポー
   トで要求されるように、ノードが特定のソースアドレスからのパケット*だけ*、
   あるいは特定のソース*以外*からマルチキャストアドレスに送られたパケッ
   トだけに興味を持つと報告する能力を加えます。MLDv2はMLDv1と
   同時使用可能であるよう意図されます。

   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.
   MLDは非対称プロトコルです;マルチキャストアドレスの受信者(すなわ
   ち、マルチキャストパケットを受信するホストあるいはルータ)とマルチキャ
   ストルータに別の行動を指定します。MLDの目的は、それぞれのマルチキャ
   ストルータが直接接続されているそれぞれのリンクで、どのマルチキャスト
   アドレスとどのソースアドレスに受信者がいあるかを学ぶことができるよう
   にすることです。MLDによって集められた情報は、マルチキャストパケッ
   トを受信者がいるすべてのリンクに配達することを保証するために、ルータ
   の使用するマルチキャストルーティングプロトコルに供給されます。

   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.)
   マルチキャストルータは接続するリンク上で、特定マルチキャストアドレス
   と特定ソースアドレスで、*少なくとも1つ*のノードがパケットを受信して
   いる、ということを知る必要があるだけです;マルチキャストルータは
   *個々に*それぞれの隣接するノードの受信パケットを記録・追跡するように
   要求されません。(にもかかわらず、論議のために付録A2の項目1を見て
   ください。)

   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.
   マルチキャストルータはその直接接続されているリンクのそれぞれの上で
   (7章で細部を記述する)MLDv2プロトコルの*ルータ役*を行います。
   もしマルチキャストルータが複数のインタフェースで同じリンクに接続した
   なら、そのインタフェースの1つでだけプロトコルを操作する必要がありま
   す。ルータ行動は、同じサブネット上に、いくつかのマルチキャストルータ
   があるかどうかによります。もしそうなら、(7.6.2章で記述された)問
   合者選出メカニズムが一つのマルチキャストルータが問合者状態にいるよう
   に使われます。このルータは問合者と呼ばれます。すべてのサブネット上の
   マルチキャストルータはマルチキャストアドレス受信者から送られるメッセー
   ジを受信し、そして同じマルチキャスト受信情報状態を維持します、それで
   もし現在の問合者が失敗したなら、彼らは問合者の役割を引き継ぐことがで
   きます。にもかかわらず、問合者はただ周期的であるか、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.
   マルチキャストアドレス受信者は、たとえインタフェースのいくつかが同じ
   リンクに接続していても、マルチキャスト受信がサポートされるすべてのイ
   ンタフェース上で(6章で細部で記述された)MLDv2プロトコルの*受
   信者の役割*を行います。

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.
   マルチキャストアドレス受信者ノード上で走る上位レイヤプロトコルとアプ
   リケーションが特定のマルチキャストアドレスに送ったパケットの受信を可
   能にするかどうかIPレイヤに尋ねる(3章で記述された)特定のサービス
   インタフェース呼び出しを使います。ノードはサービスインタフェース呼び
   出しがされたそれぞれのソケットのためにマルチキャストアドレス受信状態
   を維持します(4.1章)。このソケット毎のマルチキャスト受信状態に加え
   て、ノードがインターフェース毎にマルチキャスト受信状態を維持するか計
   算しなければなりません。概念的に、この状態は、それぞれのレコードがI
   Pv6マルチキャストアドレスとフィルタモードとソースリストを含んでい
   る、レコード集合から成り立ちます。フィルタモードは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.
   特定のインタフェースで、マルチキャストアドレス毎に最大1つのレコード
   が存在します。このインターフェース毎の状態はソケット毎状態から得られ
   ますが、異なったソケットが同じマルチキャストアドレスとインタフェース
   で異なるフィルタモードやソースリストを持っている時は違うかもしれませ
   ん。IPレイヤでインタフェースからマルチキャストパケットを受信した後、
   そのソケットに接続したアプリケーションへの次の配達はそのソケットのマ
   ルチキャスト受信状態(そして多分ソケットがどの輸送レイヤポートと接続
   しているかなど他の条件)に依存します。MLDv2メッセージがフィルタ
   ソースの適用を受けず、そして常にホストとルータによって処理されなくて
   はならないことに注意を払ってください。

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.
   MLDv2問合せメッセージに3つのタイプがあります:一般的問合せと、
   マルチキャストアドレス特定問合せと、マルチキャストアドレスとソース特
   定問合せ。問合者は接続リンクからマルチキャストアドレス受信者情報を学
   ぶために、周期的に一般問合せを送ります。これらの問合せはリンク上のす
   べてのマルチキャストルータのマルチキャストアドレス受信者状態の生成と
   更新に使われます。

   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.
   ノードは、すべてのリンク上のMLDv2ルータが聞く特定のマルチキャス
   トアドレスに送られた現在状態報告メッセージを通して、インターフェース
   毎のマルチキャストアドレス受信状態を報告することによって、これらの問
   合せに返答します。他方、もしノードの受信状態が変化するなら、ノード状
   態変更報告メッセージを通してすぐにこれらの変更を報告します。状態変更
   報告はフィルタモード変更記録、ソースリスト変更記録、あるいは両方の種
   類の記録を含んでいます。報告メッセージの詳細な記述が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.
   ルータと受信者の状態の変更の両方が主に特定のタイマの期限切れや、ML
   Dメッセージの受信によって引き起こされます(受信状態変化が同じくサー
   ビスインタフェース呼出しによって引き起こされえます)。従って、プロト
   コル強靭性を確保するために、メッセージ交換の可能な頼りなさに関係なく、
   メッセージが数回再送されます。さらに、タイマはメッセージ損失の可能性
   と再送待ちを考慮して定められています。

   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.
   リンクに負荷をかけ過ぎないために定期的な一般問合せと現在状態報告はこ
   の規則を適用しません;一般にこれらのメッセージの主な目的は既存の状態
   の更新で、状態変更を起こさないと想定されます。それで、たとえそのよう
   なメッセージが1つ失われるとしても、対応する状態は次の報告時期に更新
   されるでしょう。

   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).
   現在状態報告に対して、状態変更報告は、マルチキャストルータの誤りを避
   けるために、数回再送されます。再送回数はいわゆる信頼性変数に頼ります。
   この変数はリンク上で予想されるパケット損失に従ってプロトコル調整を許
   します。もしリンクの損失が多そうなら(例えば、無線の接続)、信頼性変
   数の値は増やされるかもしれません。MLDは[信頼性変数]-1パケットの
   損失に対して強靭です。この文書は信頼性変数のデフォルト値として2を推
   薦します(9.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.
   もし最初の変更の状態変更報告のすべての再送が完了する前に、同じインター
   フェース状態項目に対する変更が起るなら、それぞれの追加の変更が新しい
   状態変更報告の即時送信を起こします。6.1章はどのようにこの新しい報告
   の内容が計算されるか示します。新しい状態変更報告の再送は、それぞれの
   状態変化が最少の[信頼性変数]回数伝達されることを保証するように、ス
   ケジュールされるでしょう。

   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.
   それで、問合者は指定されたマルチキャストアドレスを聞いているノードが
   まだいるかどうか確かめるためにマルチキャストアドレス特定問合せを送り
   ます。同様に、問合者は、特定のソースの指定されたマルチキャストアドレ
   スを聞いているノードがまだいるかどうか確かめるためにマルチキャストア
   ドレスとソース特定問合せを送ります。5.1.13章がより多くの細部でそ
   れぞれの質問を記述します。

   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.
   マルチキャストアドレス特定問合せとマルチキャストアドレスとソース特定
   問合せの両方は、現在状態報告に応えてではなく、状態変更報告に応えて送
   られるだけです。この報告の2つの種類の間の区別は、ルータがすべてのマ
   ルチキャスト受信者報告を状態変更の可能性と扱うのを避けるために必要と
   されます。この場合、2.2章で細部を記述するMLDv2の急速離脱メカニ
   ズムは、もし状態変更報告を失い現在状態報告 だけがルータに受信された際
   に、効率的ではないかもしれません。にもかかわらず、これはルータの処理
   の増加を避けとリンク上のMLDトラヒックを減らします。2つの報告種別
   を区別する必要のより詳細は付録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.
   前に述るように、プロトコル強靭性を保証するために、すべての問合せは、
   周期一般問合せ以外、所定の時間間隔内で数回再送されます。再送回数は信
   頼性変数に頼ります。もし新しい問合せのスケジュールをする際に、同じマ
   ルチキャストアドレスの再送待ちの問合せがあるなら、新しい問合せと再送
   待ちの問合せは合併されなければなりません。加えて、待ち状態の問合せの
   マルチキャストアドレスに対するホスト報告の受信は、これらの問合せの中
   身に影響を与えるかもしれません。待ち状態の質問の状態の生成と維持の処
   理は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.
   プロトコルロ強靭性がSフラグ(ルータ側処理抑制)の使用を通して拡張さ
   れています。上記のように、問合者がマルチキャストアドレス特定あるいは
   マルチキャストアドレスとソース特定問合せを送る時、多くの質問の再送が
   予定されます。元(最初)の質問でSフラグは明確です。問合者がこの問合
   せを送る時、そのマルチキャストアドレス(あるいはソース)に対するタイ
   マを特定の値に設定します;同様に、問合せを受け取る非問合者のマルチキャ
   ストルータもそのタイマを設定します。次の質問の送信時刻を待つ間に、問
   合者はタイマを更新する報告を受け取るかもしれません。予定された問合せ
   は非問合者ルータの状態が現在の問合者(非問合者のルータが最初の問合せ
   を受取れなかったかもしれない)と同期する状態になることを保証するため
   に、送られなければなりません。にもかかわらず、タイマは正当な応答を受
   信しているので、再び設定するべきではありません。それ故に、次の質問で
   問合者はSフラグを設定します。

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.
   (問合者状態にいるか否かにかかわらず)MLDv2を実行するマルチキャ
   ストルータが接続されているリンク毎にマルチキャストアドレス毎に状態を
   維持します。このマルチキャストアドレス受信状態は、フィルタモード、
   フィルタタイマ、ソースリスト、リストのそれぞれのソースに関連づけられ
   たタイマから成り立ちます。フィルタモード (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モードで
   す。ルータ状態は、Aが「組み込みリスト」と呼ばれるソースリストであれ
   ば、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.
   この「ソフト離脱」メカニズムのほかに、MLDv2「速い離脱」案があり
   ます;これもソースタイマの使用に基づいています。INCLUDEモードのノード
   が特定のソースからの受信をやめる事を示す時、リンク上のすべてのマルチ
   キャストルータはそのソースのタイマに特定の値を設定します。問合者は、
   リンク上にそのソースの他の聞き手がいるかどうか確かめるために、マルチ
   キャストアドレスとソース特定問合せを送ります。もしこのソースを含む報
   告がタイマ期限前に受け取られるなら、リンク上のすべてのマルチキャスト
   ルータはソースタイマを更新します。もしそうでなければ、ソースは組込リ
   ストから削除されます。組込リストの取り扱いは、報告の受信に関連して、
   表7.4.1と表7.4.2で詳述されます。

   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.
   もしリンク上でそのアドレスのために少なくとも1人の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は「除外リスト」と呼ばれます。すべて
   のソースは、それらが除外リストになければ、ルータによって転送されるで
   しょう。要求リストは転送に対する効果を持ちません。にもかかわらず、ルー
   タは2つの理由で要求リストを維持しなければなりません:

   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モードで受信者の受信するソースの不正確な推測を含む事
      ができ−大きすぎか、あるいは小すぎかもしれません。これらの不正確さ
      は、下記のように、即時停止の目的で使われる事実のためです。もしこの
      ような即時停止が必要とされるなら、(表7.4.1と7.4.2に示される
      ように)あるソースがルータ状態を減らすための要求リストから削除され
      るかもしれません。にもかかわらず、このような場合フィルタタイマが更
      新されます。それ故に、INCLUDEモードの受信者が、最終切替前に、削除
      されたソースに対しての受信要求を再確認し、適切な要求リストを再建す
      る十分な時間を持つでしょう。プロトコルはINCLUDEモードへの切替が起
      こる時、要求リストが正確であろうことを保証します。ルータのINCLUDE
      モードへの移行の細部が付録A3で提出されます。
   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モードルータ状態の取り扱いは、受信報告により、表7.4.1と
   7.4.2で詳述されます。

   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.
   MLDv2ルータとこの文書で記述された受信者の行動の両方がMLDv1
   ホストとルータと後方互換性を保証するために定義されました。互換性問題
   が8章で詳述されます。

3.  The Service Interface for Requesting IP Multicast Reception
3.  IPマルチキャスト受信を求めるサービスインタフェース

   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:
   IPシステムの中で、上位レイヤプロトコルあるいはアプリケーションプロ
   グラムによって使われる、特定のIPマルチキャストアドレス宛のパケット
   の受信が可能か否かをIPレイヤを尋ねるたサービスインタフェースが(少
   なくとも概念的に)あります。MLDv2の能力の完全な利用をするために、
   ノードのIPサービスインタフェースは次のオペレーションをサポートしな
   くてはなりません:

      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  「ソケット」はノードの中で異なる要求者(例えば、プログラム、プロセ
      ス)を識別するために使われる実装固有のパラメータです;BSD UN
      IXシステム呼出しのソケットパラメータは個々の事例です。

   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  「インターフェース」はネットワークインタフェースのローカルな識別子
      で、その上で指定されたマルチキャストアドレスの受信が使用可能である
      か使用不能になるはずです。インタフェースが物理的(例えば、イーサネッ
      トインタフェース)かもしれないし、仮想(例えば、フレームリレー仮想
      回路の終端あるいはIP上のIPトンネル」)であるかもしれません。実
      装が特別な「特定されていない」値をインタフェースパラメータとして渡
      されることを許すかもしれず、このの場合要求は(多分システム設定で確
      立された)ノードの「主」あるいは「デフォルト」インタフェースに当て
      はまるでしょう。もし同じマルチキャストアドレスの受信が1つ以上のイ
      ンタフェースで望まれるなら、 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  「IPv6マルチキャストアドレス」は要請に関係するマルチキャストア
      ドレスです。もし指定のインタフェース上で1つ以上のマルチキャストア
      ドレスの受信を望むなら、それぞれのアドレスに対して
      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  「ソースリスト」は0個以上の順序なしのユニキャストアドレスのリスト
      で、フィルタモードに依存して、マルチキャスト受信を望むか望まないか
      を指定します。実装がソースリストの大きさに限度を課すかもしれません
      (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.
   あるソケットとインタフェースとIPv6マルチキャストアドレスの組合せ
   に対して、同時に1つのフィルタモードとソースリストだけが実施され得ま
   す。にもかかわらず、フィルタモードあるいはソースリストあるいは両方が、
   同じソケットとインタフェースとIPv6マルチキャストアドレスを指定す
   る次の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:
   MLDv1プロトコルはソースフィルタをサポートせず、より単純なサービ
   スインタフェースを持ちました;これは指定インターフェースの(*全ての*
   ソースからの)指定のマルチキャストアドレスの受信の軌道と停止のための
   受信開始と受信終了オペレーションからなります。新しいサービスインタ
   フェースでの等価なオペレーションは次の通りです:

   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].
   このサービスインタフェースで概説された能力を供給するAPIの例が
   [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:
   特定のインターフェースでマルチキャストアドレス毎にせいぜい1つのレコー
   ドが存在します。このインターフェース毎の状態はソケット毎状態から得ら
   れます、が、同じマルチキャストアドレスとインタフェースでも異なるソケッ
   トでは異なったフィルタモードやソースリストを持つかもしれません。例え
   ば、1つのアプリケーションあるいはプロセスがソケット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.
   マルチキャストパケットがインタフェースからIPレイヤに受け入れられた
   後、その特定のソケットのマルチキャスト受信状態(そして多分ソケットが
   結合する輸送レイヤポートのような、他の条件)に依存して特定のソケット
   で受信するアプリケーションかプロセスへ次の配達が行われます。それで、
   上記の例で、もし宛先マルチキャストアドレスmでソースアドレスaのパケッ
   トがインターフェースiに到着するなら、パケットはソケットs1に配達される
   が、s2に配達されないでしょう。MLDv2メッセージがソースフィルタの
   適用を受けず、そして常にホストとルータによって処理されなくてはならな
   いことに注意してください。

   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モードのソケットレコー
      ドに現われるそれらのソースアドレスを差し引いたものです。例えば、も
      しインタフェースiの上のマルチキャストアドレス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:
      インタフェースiの対応するインタフェースレコードは以下です:

         ( m, EXCLUDE, {b, c} )

      If a fourth socket is added, such as:
      もし以下の4番目のソケットが追加されるなら:
 
         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で、インタフェースレコードのソー
      スリストはすべてのソケットレコードのソースリストの和です。例えば、
      もしインタフェースiの上のマルチキャストアドレス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:
      インタフェースiの対応するインタフェースレコードは以下です:

         ( 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.)
   MLDv2はICMPv6の副プロトコルです、すなわち、MLDv2メッ
   セージタイプはICMPv6メッセージの部分集合です、そしてMLDv2
   メッセージが前にある次のヘッダ値の58によって他のIPv6パケットと
   区別されます。すべてのこの文書で記述されたMLDv2メッセージは、リ
   ンクローカルIPv6ソースアドレスと、IPv6ホップ限界が1と、ホッ
   プ毎オプションヘッダのIPv6ルータ警告オプション[RFC2711]で送られな
   くてはなりません。(ルータ警告オプションは、ルータ自身が受信しないI
   Pv6マルチキャストアドレスに送られたMLDv2メッセージをルータに
   調べさせるために必要です。)もし送信インタフェースのためにまだ正当な
   リンクローカルIPv6ソースアドレスが獲得されていなかったなら、特定
   されていないアドレス[RFC3513]のソースアドレスでMLDv2報告を送るこ
   とができます。(詳細は5.2.13章を見てください。)

   There are two MLD message types of concern to the MLDv2 protocol
   described in this document:
   この文書に記述されたMLDv2プロトコルに関する2つのMLDメッセー
   ジ種別があります:

   o  Multicast Listener Query (Type = decimal 130)
   o  マルチキャスト受信者問合(種別=十進数130)。

   o  Version 2 Multicast Listener Report (Type = decimal 143).  See
      section 11 for IANA considerations.
   o  2版マルチキャスト受信者報告(種別=十進数143)。11章のIAN
      A考慮を見てください。

   To assure the interoperability with nodes that implement MLDv1 (see
   section 8), an implementation of MLDv2 must also support the
   following two message types:
   MLDv1を実行するノードとの互換性を保証するために(8章参照)、M
   LDv2実装が次の2つのメッセージ種別をサポートしなくてはなりません:

   o  Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710]
   o  1版マルチキャスト受信者幇助区(種別=十進数131)[RFC2710]。

   o  Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710]
   o  1版マルチキャスト受信終了(種別=十進数132)[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)。
   他のメッセージ種別がMLDの新しい版あるいは拡張や、マルチキャストルー
   ティングプロトコルや、あるいは他の使用のために使われるかもしれません。

   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.
   この文書で、特に記述がなければそれぞれ、大文字で始まる用語「問合せ」
   と「報告」はMLDマルチキャスト受信者問合と、MLD2版マルチキャス
   ト受信報告の事です。

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.
   標準的なICMPv6チェックサム;これは全部のMLDv2メッセージと
   IPv6ヘッダーフィールドの「疑似ヘッダ」[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
   もし最大応答コード<32768であるなら、。
      最大応答遅延=最大応答コードです。

   If Maximum Response Code >=32768, Maximum Response Code represents a
   floating-point value as follows:
   もし最大応答コード≧32768なら、最大応答コードは以下の浮動小数点
   値を示します:

       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.
   最大応答遅延の小さい値はMLDv2ルータが「離脱遅延」(リンク上の最
   後のノードが特定のマルチキャストアドレスを聞くことをやめる瞬間と、ルー
   ティングプロトコルがそのアドレスの受信者がいないと知るまでの間の時間)
   を調整することを許します。特に指数の範囲の、より大きい価は、リンク上
   のMLDトラフィックの輻輳調整を許します。

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.10章参照)。

5.1.7.  S Flag (Suppress Router-Side Processing)
5.1.7.  Sフラグ(ルータ側処理抑制)

   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.
   1が設定される時、Sフラグは受信マルチキャストルータが問合せを受けた
   時の通常のタイマ更新を抑制する事を意味します。にもかかわらず、これは
   問合者選出や、マルチキャスト受信者自身として実行を要求されるルータで
   の問合せの通常の「ホスト側」処理を抑制しません。

5.1.8.  QRV (Querier's Robustness Variable)
5.1.8.  QRV(問合者信頼性変数)

   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フィールドは問合者によって使われた[信
   頼性変数]値を含んでいます。もし問合者の[信頼性変数]が7(QRV
   フィールドの最大値)を越えるなら、 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.
   ルータは最も最近受信されたQRVがゼロでなければ最も最近受信した問合
   せのQRV値を自身の[信頼性変数]値として採用します、もしゼロなら
   9.1章で示されるデフォルト[信頼性変数]値か、静的に設定された値を
   使います。

5.1.9.  QQIC (Querier's Query Interval Code)
5.1.9.  QQIC(問合者質問間隔コード)

   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:
   問合者の問合せ間隔コードフィールドは問合者の使用する[問合せ間隔]を
   指定します。問合者問合間隔(QQI)と呼ばれる実際の間隔は、秒単位で
   示され、次のように問合者の問合せ間隔コードから得られます:

   If QQIC < 128, QQI = QQIC
   もしQQIC<128なら、QQI=QQIC

   If QQIC >= 128, QQIC represents a floating-point value as follows:
   もし最大応答コード≧128なら、QQICは以下の浮動小数点値を示し
   ます:

       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.
   現在の問合者でないマルチキャストルータが、その最も最近受信したQQI
   がゼロではなかったなら、最も最近受信した問合せのQQI値を自身のもの
   [問合間隔]値として採用します、ゼロの場合受信ルータは9.2章で指定さ
   れるデフォルト[問合間隔]値を使用します。

5.1.10.  Number of Sources (N)
5.1.10.  ソース数(N)

   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).
   ソース数(N)フィールドは何個のソースアドレスが問合せに存在している
   か明示します。この数は一般問合せやマルチキャストアドレス特定問合せで
   ゼロで、マルチキャストアドレスとソース特定問合せでゼロ以外です。この
   数は問合せが伝達されるリンクのMTUによって制限されます。例えば、
   1500のオクテットのイーサーリンクで、IPv6ヘッダ(40オクテッ
   ト)とルータ警告オプションを含むホップ毎拡張ヘッダ(8オクテット)は
   48オクテットになります;ソース数(N)までのMLDフィールドは28
   オクテットです;ソースアドレスのための残りは1424オクテットなので、
   ソースアドレスの数の限界は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]フィールドはnユニキャストアドレスの列です、ここでn
   はソース数(N)フィールドの値です。

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.
   もし受信問合せのIPv6ヘッダのペイロード長フィールドが、ここに記載
   した以外に追加のデータがあることを示すなら、MLDv2実装は受信ML
   Dチェックサム検査でこれらのオクテットを計算しなければならない(MUST)
   が、それ以外は追加のオクテットを無視しなくてはなりません(MUST)。質問
   を送る時、MLDv2実装は上記フィールド以外に追加オクテットを含んで
   はなりません(MUST NOT)。

5.1.13.  Query Variants
5.1.13.  質問の種類

   There are three variants of the Query message:
   質問メッセージの3つの種類があります:

   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  「一般問合せ」は、接続リンク上でどのマルチキャストアドレスに受信者
      がいるか学ぶために問合者によって行われます。一般問合せで、マルチキャ
      ストアドレスフィールドとソース数(N)フィールドの両方がゼロです。

   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  「マルチキャストアドレス特定問合せ」は接続しているリンク上で、特定
      のマルチキャストアドレスの受信者がいるかどうか学ぶために問合者によっ
      て行われます。マルチキャストアドレス特定問合せで、マルチキャストア
      ドレスフィールドは対象となるマルチキャストアドレスを含み、他方ソー
      ス数(N)フィールドはゼロが設定されます。

   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  「マルチキャストアドレスとソース特定問合せ」は接続しているリンク上
      で、指定されたソースからの特定のマルチキャストアドレスの受信者がい
      るかどうか学ぶために問合者によって行われます。マルチキャストアドレ
      スとソース特定問合せでマルチキャストアドレスフィールドは対象となる
      マルチキャストアドレスを含み、ソースアドレス[i]フィールドは対象
      となるソースアドレスを含みます。

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.
   すべてのMLDv2問合せは正当なIPv6リンクローカルソースアドレス
   で送られなくてはなりません(MUST)。もしノード(ルータあるいはホスト)
   が特定されていないアドレス(::)のIPv6ソースアドレスを設定した問合
   せメッセージを受け取るなら、あるいは正当なIPv6リンクローカルアド
   レスでないアドレスで受取るなら、静かにメッセージを捨てなくてはならず
   (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.
   MLDv2で、一般問合せはリンク範囲の全ノードマルチキャストアドレス
   (FF02::1)に送られます。マルチキャストアドレス特定問合せとマルチキャス
   トアドレスとソース特定問合せは対象のマルチキャストアドレスと等しいI
   P宛先アドレスで送られます。*しかしながら*ノードがIP宛先アドレスに、
   問合せを受信したインターフェースに割当てられたアドレス(ユニキャスト
   とマルチキャスト)を含む、問合せを受け入れて処理しなければなしません
   (MUST)。これは、例えば、デバッグの目的で有用であるかもしれません。

5.2.  Version 2 Multicast Listener Report Message
5.2.  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:
   2版マルチキャスト受信者報告はが(隣接するルータに)現在のマルチキャ
   ストの受信状態、あるいは、それらのインタフェースの、マルチキャスト受
   信状態の変更を報告するためにIPノードによって送られます。報告は次の
   フォーマットです:

     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.
   標準的なICMPv6チェックサム;これは全部のMLDv2メッセージと、
   IPv6ヘッダーフィールドの「疑似ヘッダ」[RFC2460, RFC2463]をカバー
   します。チェックサムを計算するために、チェックサムフィールドはゼロを
   設定されます。パケットを受信する時、チェックサムはこれを処理する前に
   実証されなくてはなりません(MUST)。

5.2.3.  Nr of Mcast Address Records (M)
5.2.3.  NrあるいはMcastアドレスレコード(M)

   The Nr of Mcast Address Records (M) field specifies how many
   Multicast Address Records are present in this Report.
   NrあるいはMcastアドレスレコード(M)フィールドは何個のマルチキャスト
   アドレスレコードがこの報告で存在しているか明示します。

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.
   それぞれのマルチキャストアドレスレコードは報告を送るインタフェース上
   で送信者が受信する1つのマルチキャストアドレスの情報を含むフィールド
   の塊です。

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.12章を見てください。

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.
   補助データ長フィールドは、32ビット単位で、このマルチキャストアドレ
   スレコードの補助データフィールドの長さを含んでいます。これは補助デー
   タがない事を示すために、ゼロを含んでいるかもしれません。

5.2.7.  Number of Sources (N)
5.2.7.  ソースの数(N)

   The Number of Sources (N) field specifies how many source addresses
   are present in this Multicast Address Record.
   ソースの数(N)フィールドは何個のソースアドレスがこのマルチキャスト
   アドレスレコードで存在しているか明示します。

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.  ソースアドレス[i]

   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.
   ソースアドレス[i]フィールドはn個のユニキャストアドレスのベクトル
   で、そしてnはこのレコードのソースの数(N)フィールドの値です。

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.
   補助データフィールドは、もし存在するなら、このマルチキャストアドレス
   レコードに関係ある追加情報を含んでいます。この文書で指定されたプロト
   コル、MLDv2、は補助データを定義しません。それ故に、MLDv2実
   装が伝達されたマルチキャストアドレスレコードにどんな補助データも含ん
   ではならず(MUST NOT)(すなわち、補助データ長フィールドはゼロを設定し
   なければならない(MUST))、そして受信マルチキャストアドレスレコードの
   このようなデータの存在を無視しなくてはなりません(MUST)。意味と補助デー
   タフィールドの内部のコーディングはこのフィールドを使う将来のバージョ
   ンあるいはMLD拡張で定義されるはずです。

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.
   もし受信した報告のIPv6ヘッダのペイロード長フィールドが追加のオク
   テットデータがあることを示すなら、最後のマルチキャストアドレスレコー
   ド以降は、MLDv2実装は受信MLDチェックサム検査の計算にそれらの
   オクテットを含めなくてはなりません(MUST)が、それ以外は追加のオクテッ
   トを無視しなくてはなりません(MUST)。報告を送る時、MLDv2実装が最
   後のマルチキャストアドレスレコード以降に追加オクテットを含んではなり
   ません(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  「現在状態レコード」がインタフェース上で受信した問合せに応えてノー
      ドによって送られます。これはそのインタフェースでの、ひとつのマルチ
      キャストアドレスに関する現在の受信状態を報告します。現在状態レコー
      ドのレコードタイプは次の2値の1つであるかもしれません:

      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フィルタモードであることを示します。このマル
             チキャストアドレスレコードのソースアドレス[i]フィールド
             は指定されたマルチキャストアドレスに対するインタフェースの
             ソースリストを含んでいます。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フィルタモードであることを示します。こ
             のマルチキャストアドレスレコードのソースアドレス[i]フィー
             ルドは、もし空でなければ、指定されたマルチキャストアドレス
             に対するインタフェースのソースリストを含んでいます。

   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に)、ソースリストが同時に変化するか否かにかか
      わらず、ノードによって送られます。「レコード」は変更が起こったイ
      ンタフェースから送られた報告に含められます。フィルタモードチェン
      ジレコードの記録タイプは次の2値の1つであるかもしれません:

      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に変化したことを示します。
           このマルチキャストアドレスレコードのソースアドレス[i]フィー
           ルドは、もし空でなければ、指定されたマルチキャストアドレスの
           インタフェースの新しいソースリストを含んでいます。

      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に変化したことを示します。
           このマルチキャストアドレスレコードのソースアドレス[i]フィー
           ルドは、もしそれが空でないなら、指定されたマルチキャストアド
           レスのインタフェースの新しいソースリストを含んでいます。

   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のローカル要求
      が、フィルタモードの変更を*起こさず*に、特定のマルチキャストアドレ
      スのインタフェースレベル状態項目のソースリストの変更をもたらす時に
      ノードによって送られます。「レコード」は変更が起こったインタフェー
      スから送らる報告を含みます。ソースリスト変更レコードの記録タイプは
      次の2値の1つであるかもしれません:

      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このマルチキャストアドレスレコードのソースア
           ドレス[i]フィールドが、指定されたマルチキャストアドレス宛
           のパケットで受信を望まない追加のソースのリストを含んでいるこ
           とを示します。もし変更が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−このマルチキャストアドレスレコードのソース
           アドレス[i]フィールドは、指定されたマルチキャストアドレス
           に送られるパケットで、ノードが受信を望まない情報源のリストを
           含んでいることを示します。もし変更が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.
   もしソースリストの変更が新しいソースの許可と古いソースの停止の両方を
   起こすなら、2つのマルチキャストアドレスレコード、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  ソースアドレスの集合を表すための大文字(例えば、「A」)、

      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  集合式(例えば、「A+B」)、「A+B」が和集合を意味し、
      「A*B」が共通集合を示し、「A−B」差集合を意味します。

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.
   MLDv2報告は正当なIPv6リンクローカルソースアドレスか、もし送
   信しているインタフェースがまだ有効なリンクローカルアドレスを獲得して
   いなければ、特定されていないアドレス(::)で送られなくてはなりません
   (MUST)。特定されていないアドレスで報告を送ることは近隣探索プロトコル
   [RFC2461]でIPマルチキャストの使用をサポートすることを許します。ステー
   トレス自動設定のために、[RFC2462]で定義されるように、ノードが重複アド
   レス発見(DAD)を行うために、いくつかのIPv6マルチキャストグルー
   プに加入するように要求されます。DADの前に、報告ノードが送信インタ
   フェースのために持つアドレスは仮であり、そして通信に使うことができま
   せん。それで、特定されていないアドレスが使われなくてはなりません。

   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)。それで、
   もしルータがパケットのソースアドレスがパケットを受信したインターフェー
   スの接続するリンクに属すると認識できないなら、報告が捨てられます。特
   定されていないアドレスで送られた報告が同じくルータによって捨てられま
   す。これは、正体不明の報告ノードがMLDv2ルータの状態に影響を与え
   ることができないから、セキュリティを拡張します。にもかかわらず、報告
   ノードは報告メッセージのマルチキャストアドレスレコードにあるマルチキャ
   ストアドレスの受信状態を修正します。その時から、ノードは新しい受信状
   態に従って、マルチキャストアドレスに送られたパケットを扱うでしょう。
   正当なリンクローカルアドレスが利用可能になると、ノードは、インタフェー
   ス上で受信する全てのマルチキャストアドレスのために新しいMLDv2報
   告メッセージを生成するべきです(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.
   マルチキャスト受信者報告がIP宛先アドレスFF02:0:0:0:0:0:0:16に送られ、
   全てのMLDv2対応のマルチキャストルータが受信します(この特別な宛
   先アドレスと関係する11章のIANAの考慮を参照)。バージョン1互換
   モードで稼働するノード(詳細は8章参照)が報告のマルチキャストアドレ
   スフィールドに指定されるマルチキャストアドレスへバージョン1報告を送
   ります。加えて、ノードが、IP宛先アドレスフィールドに報告を受信する
   インターフェースに割当てられたIPv6アドレス(ユニキャストあるいは
   マルチキャスト)のどれかを含むバージョン1の報告でも受け入れて、処理
   しなくてはなりません(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.
   もし報告で必要とされるマルチキャストアドレスレコードの集合がひとつの
   報告メッセージの大きさの限界(報告を送るリンクのMTUで決定される)
   を越えるなら、集合全体を報告するのに必要なだけけの数の報告メッセージ
   で送られる必要があります。

   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.
   MLDは、マルチキャストアドレス受信者−すなわちホストやマルチキャス
   トパケットを受信するルータ−とマルチキャストルータに別の行動を指定す
   るから、非対称プロトコルです。この章はすべてのマルチキャストアドレス
   受信者に適用するMLDv2の部分を記述します。(マルチキャストアドレ
   ス受信者でもあるマルチキャストルータがMLDv2の両方の部分を実行す
   ることに注意してください;これは近隣からのMLDメッセージ同様に自身
   のMLDメッセージ受信し返答します。)MLDv2のマルチキャストルー
   タ部分は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.
   MLDv1プロトコルを動かすマルチキャストルータとの互換性のために、
   ノードはマルチキャスト受信がサポートされるそれぞれのインタフェースで
   ホスト互換モード変数を維持します。この章は、ノード互換モード=MLD
   v2のインタフェース上で、マルチキャストアドレス受信者ノードの行動を
   記述します。ホスト互換モードを決定するアルゴリズムと、もしその値がM
   LDv1に設定されたときの行動は、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)は、特別なケースと
   して扱われます。すべてのノードで−マルチキャストルータを含むすべての
   ホストとルータで−すべてのソースからの、全ノードマルチキャストアドレ
   ス宛のパケットを受信し、マルチキャストをサポートするすべてのインタフェー
   ス上で永久に使用可能です。リンク範囲全ノードマルチキャストアドレスや
   範囲0(予約)や1(ノードローカル)のマルチキャストアドレスに関する
   MLDメッセージが送られません。

   There are three types of events that trigger MLDv2 protocol actions
   on an interface:
   インタフェースでMLDv2プロトコル行動を引き起こす3つのイベント種
   別があります:

   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.)
   (質問以外の種類の受信MLDメッセージは、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.
   次の詳細はそれぞれの事例で取られる行動を記述します。タイマとカウンタ
   名が角括弧で現われます。これらのタイマとカウンタのデフォルト値が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.
   4.2章の規則により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]).
   状態変更報告をマルチキャストルータがミスする可能性に対応するために、
   範囲(0、[望まれない報告間隔])からランダムに選ばれた再送タイマに
   よって、[信頼性変数]-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.
   ソースが上で計算した相違に含められるたびに、そのソースのための再送状
   態が、[信頼性変数]回の状態変更報告がノードによって送られるまで、維
   持される必要があります。これは一連の連続した状態変更がプロトコルの安
   定を絶ち切らないことを保証するためにされます。再送状態のソースは、リ
   ストのそれぞれのソースに関するソース再送カウンタと共に、マルチキャス
   トアドレス再送毎のリストに維持されます。リストにソースが追加される度
   に、そのカウンタは[信頼性変数]に設定されます。状態変更報告が送られ
   るたびに、カウンタは1単位づつ減少します。カウンタがゼロに達する時、
   ソースはそのマルチキャストアドレスの再送リストから削除されます。

   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.
   もし新しい報告を引き起こすインターフェース毎の受信状態の変更がフィル
   タモード変更であるなら、次の[信頼性変数]回の状態変更報告はフィルタ
   モード変更レコードを含むでしょう。これはその期間にソースリスト変更が
   何度起きても適用されます。ノードは[信頼性変数]回の状態変更報告が送
   られるまで、マルチキャストアドレスの再送状態を維持しなければなりませ
   ん。これはマルチキャストアドレス毎のフィルタモード再送カウンタででき
   ます。フィルタモードが変れば、カウンタが[信頼性変数]に設定されます。
   状態変更報告が送られるたびに、カウンタは1単位づつ減少します。カウン
   タがゼロに達する時、すなわち、フィルタモード変更後に、フィルタモード
   変更レコードが[信頼性変数]回の状態変更報告が再送されたら、そしても
   しソースリスト変更が追加の報告が予定されるという結果になったなら、次
   の状態変更報告はソースリスト変更レコードを含むでしょう。

   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.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.
   問合せを含むMLDメッセージを受信したノードはメッセージのソースアド
   レスが正当なリンクローカルアドレスであるかどうか、ホップ限界が1に設
   定されるかどうか、そしてルータ警告オプションがIPv6パケットのホッ
   プ毎オプションヘッダに存在しているかどうか調べます。もしこれらの検査
   のどれかが失敗するなら、パケットは廃棄されます。

   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.
   もしMLDメッセージの正当性が確かめられるなら、ノードは問合せを処理
   し始めます。すぐに返答する代わりに、ノードは受信した問合せメッセージ
   の最大応答コードから得られた最大の回答遅延値にを限界として、任意の量
   の時間その応答を延期します。ノードが異なるインタフェース上で異なる種
   類の問合せを受け取るかもしれません(例えば、一般問合せとマルチキャス
   トアドレス特定問合せとマルチキャストアドレスとソース特定問合せ)、そ
   してそのそれぞれで遅延応答を必要とするかもしれません。

   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:
   質問に対する応答を予定する前に、ノードは最初に、前に予定された応答を
   考慮し、そして、多くの場合、結合された応答をしなくてはなりません。そ
   れ故に、MLDv2プロトコルの受信部を実行するそれぞれのインタフェー
   スで、ノードは次の状態を維持することができなければなりません:

   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.)
   新しい正当な一般問合せがインタフェースの上に到着する時、ノードは報告
   するべきインターフェース毎の受信状態レコードがあるかどうか調べます。
   同様に、新しい正当なマルチキャストアドレス(とソース)特定問合せがイ
   ンタフェース上に到着する時、ノードは尋ねられたマルチキャストアドレス
   (とソース)に対応する、インターフェース毎の受信状態レコードを持って
   いるかどうか調べます。もしあれば、応答のための遅延が範囲(0、[最大
   応答遅延])からランダムに選択されます、ここで最大の応答遅延が受信し
   た問合せメッセージに挿入された最大応答コードから得られます。次の規則
   は報告の必要があるかどうかと報告の種類を決定するために使われます。
   (規則は順番に考慮され、そして最初の一致規則だけが適用されます。)

   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.
   MLDv2マルチキャストアドレス受信ノード上に、タイムアウトでプロト
   コル行動を引き起こすいくつかのタイマがあります。これらすべての行動は
   ノードによって予定された報告と関係があります。

   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. もしタイムアウトしたタイマがインタフェースタイマ(すなわち、一般問
      合せに対する予定した応答がある)なら、4.2章で記述されるように、
      指定されたインタフェースのセクション受信状態にあるそれぞれのマルチ
      キャストアドレスの現在の状態レコードが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.
      多数の現在の状態レコードが可能な限り個別の報告メッセージの中に入れ
      られます。このネイティブのアルゴリズムは、ノードが多数のマルチキャ
      ストアドレスを受信する時は、パケットの爆発をもたらすかもしれません。
      ひとつのインタフェースタイマを使う代わりに、実装が範囲(0、[最大
      応答遅延])でこのような報告メッセージの送信を分散することが勧めら
      れます。このような実装は「応答破裂」問題を避けなくてはならない(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レコードが含まれます。
      両方の場合で、そのマルチキャストアドレスのためのフィルタモード再送
      カウンタは報告の送信後に1単位減少します。

      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    転送である再送状態のすべて(すなわち、再送リストのソース
               の全て)。それぞれの含まれるソースに対し、そのソース再送
               カウンタは報告の伝達後に1単位減少します。もしカウンタが
               ゼロに達するなら、そのマルチキャストアドレスの再送リスト
               からソースは削除されます。
      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    ブロックである再送状態のすべて(すなわち、すべての再送リ
               ストのソース)。それぞれの含まれるソースに対し、そのソー
               ス再送カウンタは報告の伝達後に1単位減少します。もしカウ
               ンタがゼロに達するなら、そのマルチキャストアドレスの再送
               リストからソースは削除されます。

      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.
   MLDの目的はそれぞれのマルチキャストルータが、その直接接続するリン
   クのそれぞれで、リンク上でどのマルチキャストアドレスに受信者がいるか
   学ぶことができるようにすることです。MLDバージョン2はマルチキャス
   トルータに、特定のマルチキャストアドレスに送ったパケットで、どの*ソー
   ス*に対して隣接ノードの受信者がいるかを学ぶ能力を追加します。MLDに
   よって集められた情報は受信者がいるすべてのリンクにマルチキャストパケッ
   トが配達されることを保証するために、ルータによって使われるマルチキャ
   ストルーティングプロトコルにも供給されます。

   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.
   この章はマルチキャストルータによって行われるMLDv2の役割を記述し
   ます。マルチキャストルータ自身がマルチキャストアドレス受信者になり、
   そして6章で記述されたMLDv2のマルチキャスト聞き手役割も行っても
   よいです。

   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.
   マルチキャストルータがその直接接続されているリンクのそれぞれの上でこ
   の章で記述されたプロトコルを実行します。もしマルチキャストルータが同
   じリンクへ複数のインタフェースを持っているなら、それらのインタフェー
   スの1つでこのプロトコルを操作する必要があるだけです。

   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.
   ルータがMLDプロトコルを動かすそれぞれのインタフェースで、ルータは
   IPv6マルチキャストが生成するすべてのリンクレイヤマルチキャストア
   ドレスを受信するようにインタフェースの設定をしなくてはなりません。例
   えば、イーサネット接続ルータがそのイーサネットアドレス受信フィルタで
   16進数で3333で始まるすべてのイーサネットマルチキャストアドレス
   を受信するようにしなくてはなりません[RFC2464];このようなマルチキャス
   トアドレス範囲のフィルタをサポートしないイーサネットインタフェースの
   場合は、MLDの必要条件を満たすために、すべてのイーサネットマルチキャ
   ストアドレスを受け入れるように設定されなくてはなりません。

   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.
   このプロトコルが動作するそれぞれのインタフェース上で、ルータはすべて
   のソースからのリンク範囲の「全MLDv2対応のルータ」マルチキャスト
   アドレスの受信を可能にしなくてはならならず(MUST)、そしてそのインタ
   フェース上のそのアドレスのためにMLDv2のマルチキャストアドレス受
   信者役割を行わなくてはなりません(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.)
   マルチキャストルータは接続したリンク上で、特定のソースからの特定のマ
   ルチキャストアドレスのパケットを受信する、*少なくとも1つ*のノードを
   知る必要があるだけです;マルチキャストルータは*個々*の隣接するノード
   の受信を記録・追跡するように要求されません。(にもかかわらず、議論の
   ため、付録A2の1項を見てください。)

   MLDv2 is backward compatible with the MLDv1 protocol.  For a detailed
   description of compatibility issues see section 8.
   MLDv2はMLDv1プロトコルと後方互換性があります。互換性の詳細
   な記述は8章を見ます。

7.1.  Conditions for MLD Queries
7.1.  MLD問合せのための状態

   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.
   MLDv2プロトコルを実行するルータの行動は、同じサブネット上に、い
   くつかのマルチキャストルータがあるかどうかによります。もしそうである
   なら、(7.6.2章で記述する)問合者選出メカニズムが一つのマルチキャ
   ストルータを問合者状態に選出するために使われます。サブネット上のすべ
   てのマルチキャストルータはマルチキャストアドレス受信者によって送られ
   るメッセージを受信し、そして同じマルチキャスト受信情報状態を維持しま
   す、それでもし現在の問合者が故障したなら、すばやく正確に問合者機能を
   引き継ぐことができます。にもかかわらず、周期的あるいはトリガの問合せ
   メッセージをサブネット上に送るのは問合者だけです。

   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.
   ノードが、MLDv2マルチキャスト受信者報告で、現在の状態マルチキャ
   ストアドレスレコードのマルチキャストアドレス受信状態(と受信するソー
   スのリスト)を報告することによって、これらの質問に返答します。

   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.
   マルチキャストアドレスとソース特定問合せがリンク上に特定のソース集合
   からのトラフィックを受信するノードがないことを確かめるために使われま
   す。マルチキャストアドレスとソース特定問合せは転送の中止を要請された
   特定のマルチキャストアドレスのためのソースをリストアップします。この
   問合せは指定されたソースアドレスから、指定されたマルチキャストアドレ
   ス宛のパケットをノードが受信するかどうか学ぶための問合者によって送ら
   れます。マルチキャストアドレスとソース特定問合せは、現在の状態レコー
   ドに応えてではなく、状態変更レコードに応えて送るだけす。5.1.13章
   が各質問のより細部を記述します。

7.2.  MLD State Maintained by Multicast Routers
7.2.  マルチキャストルータの維持するMLD状態

   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:
   MLDv2プロトコルを実行するマルチキャストルータが接続するリンク毎
   にマルチキャストアドレス毎に状態を維持します。このマルチキャストアド
   レス状態はフィルタモードとソースと種々なタイマのリストから成り立ちま
   す。MLDが動作するそれぞれの接続リンクで、マルチキャストルータがそ
   のリンクの受信状態を記録します。その状態は概念的に以下の形式のレコー
   ドの集合から成り立ちます:

      (IPv6 multicast address, Filter Timer,
       Router Filter Mode, (source records) )
      (IPv6マルチキャストアドレス、フィルタタイマ、
       ルータフィルタモード、(ソースレコード) )

   Each source record is of the form:

      (IPv6 source address, source timer)
   それぞれのソースレコードが以下の形式です:
      (IPv6ソースアドレス、ソースタイマ)

   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ルータフィルタモード集合で維持されます。これ
   はこのリンク上のノードが全てのソースからのこのマルチキャストアドレス
   を転送される事を望むことを意味します。これはMLDv1受信状態のML
   Dv2同等物です。

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.
   内部状態を減らすために、MLDv2ルータが接続リンク毎にマルチキャス
   トアドレス毎にフィルタモードを維持します。このフィルタモードは、すべ
   てのノードの受信を考慮した最小集合に、マルチキャストアドレスの完全な
   受信状態を要約するために使われます。特定のタイプのマルチキャストアド
   レスレコードあるいはある特定のタイマ状態が存在する時の受信によりフィ
   ルタモードが変化するかもしれません。次章で、我々はルータの中で特定の
   マルチキャストアドレスのフィルタモードを参照するために用語「ルータ
   フィルタモード」を使います。7.4章がレコードが受信したマルチキャスト
   アドレス毎のルータフィルタモードの変更を記述します。

   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は「組込リスト」と呼ばれます。組込リストは1つ以上のリンク上の受
   信者が受信したいと頼んだソースの集合です。組込リストのすべてのソース
   はルータにによって転送されるでしょう。組込リスト以外のソースはルータ
   に止められるでしょう。

   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.
   もし特定のマルチキャストアドレスを受信するリンク上にうち少なくとも1
   つのEXCLUDEモードの受信者がいれば、ルータはそのインタフェース上の特定
   のマルチキャストアドレスに対してEXCLUDEモードです。概念的に、マルチキャ
   ストアドレスレコードを受信する時、そのマルチキャストアドレスのための
   ルータフィルタモードは最少量の状態を使って、すべての求められたソースを
   カバーするように更新されます。規則として、EXCLUDEフィルタモードのマルチ
   キャストアドレスレコードを受信すると、そのマルチキャストアドレスのルー
   ターフィルタモードはEXCLUDEに設定されるでしょう。にもかかわらず、もしす
   べてのEXCLUDEフィルタモードのマルチキャストアドレスレコードを持つノード
   が報告を停止するなら、そのマルチキャストアドレスのルータフィルタモード
   をINCLUDEモードに移行することは望ましいです。この移行は、フィルタタイマ
   がタイムアウトするときに起こり、7.5章で詳細を説明します。

   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)で上限されます。
   ここでXはは「要求リスト」と呼ばれます、そしてYが「除外リスト」と呼
   ばれます。除外リストからの以外は、すべてのソースはルータによって転送
   されるでしょう。要求リストは転送に対する効果を持っていません。にもか
   かわらず、それは、7.2.3章で説明したように、いくつかの理由のために
   維持されなければなりません。

   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.4.1と7.4.2に詳細を提示します。

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モードに切り替える時を表します。フィ
   ルタタイマがゼロを下限として減少するタイマです。マルチキャストアドレ
   スレコード毎に1つのフィルタタイマが存在します。フィルタタイマはマル
   チキャストアドレスレコードの受信タイプに従って更新されます。

   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フィルタモー
   ドに移行します。7.5章が、フィルタタイマが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.
   次の表はフィルタタイマの役割を要約します。7.4章が受信したマルチキャ
   ストアドレスレコードタイプ毎に、フィルタタイマの設定の細部を記述します。

     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.
                                             少なくとも1受信者が
                                             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.
   ソースタイマはゼロを下限とした減少することタイマです。1つのソースタ
   イマがソースレコード毎に保持されます。ソースタイマが受信したマルチキャ
   ストアドレスレコードのタイプとフィルタモードに従って更新されます。
   7.4章が受信したマルチキャストアドレスレコードのタイプ毎にソースタ
   イマの設定を記述します。

   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.
   以下で、いくつかの変数で省略が使われます(そのすべてが9章の詳細で記
   述されます)。変数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.
   この「ソフト離脱」メカニズムのほかに、MLDv2に同じく「速い休暇」
   があります;これは同じくソースタイマの使用に基づいています。INCLUDE
   モードのノードが特定のソースからの受信をやめる事を表現する時、リンク
   上のすべてのマルチキャストルータは、LLQTミリセカンドの小さい時間分、
   ソースのタイマを減らします。問合者はリンクの上にそのソースの他の受信
   者がいるかどうか確かめるために、マルチキャストアドレスとソース特定問
   合せを送ります。もしタイマがタイムアウトする前に対応する報告を受信す
   るなら、リンク上のすべてのマルチキャストルータはソースタイマを更新し
   ます。もしそうでなければ、ソースは組込リストから削除されます。組込リ
   ストの取り扱いは、受信報告に依存して、表7.4.1と7.4.2で詳述され
   ます。

   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:
   ルータは2つの理由で要求リストをサポートしなければなりません:

   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モードの受信者が受信するソースの不正確な推測を含
      ます−大きすぎか小さすぎかもしれません。これらの不正確さは、下に記
      述されるように、要求リストが速い阻止の目的でも使われる事実のためで
      す。もしこのような速い阻止が必要とされるなら、あるソースがルータ状
      態を減らすため要求リストから(表7.4.1と7.4.2に示されるように)
      削除されるかもしれません。にもかかわらず、どの場合もフィルタタイマ
      が更新されます。それ故に、INCLUDEモードの受信者が、最終切り替え前
      に、排除されたソースに対する受信を確認して、そしてそれ相応に要求リ
      ストを再建する十分な時間を持つでしょう。プロトコルはINCLUDEモード
      への切り替えが起こる時、要求リストが正確であるであろうことを保証し
      ます。INCLUDEモードへのルータ移行についての詳細が付録A3で提出さ
      れます。

   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  前に送信を始めたソースをすばやく止めることを許すために。もしルータ
      がこのような要請を含んでいる報告を受け取るなら、問題のソースはは要
      求リストに加えられます。それらのタイマーはLLQTミリ秒の小さい間
      隔に設定されます、そしてまだリンクの上にそれらのソースに興味を持っ
      たノードがあるかどうか調べるために、マルチキャストアドレスとソース
      特定の問合せが問合者によって行われます。もしノードがその、特定のソー
      スを受けることに対しての興味を示さないなら、そのソースのタイマはタ
      イムアウトします。それから、ソースは要求リストから除外リストに動か
      されます。その時から、ソースはルータによって止められます。

   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モードルータ状態の取り扱いは、表7.4.1と
   7.4.2で詳述されます。

   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.  MLDv2ソース固有転送規則

   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.
   マルチキャストルータが特定のマルチキャストアドレス宛のソースからのデー
   タグラムを受け取る時、接続リンク上にデータグラムを転送するべきかどう
   か決断がされなければなりません。使用中のマルチキャストルーティングプ
   ロトコルはこの決定の責任があり、そしてリンク上に受信者がいるすべての
   ソース/マルチキャストアドレスがそのリンクに転送されることを保証する
   ためにMLDv2情報を使うべきです。MLDv2情報はマルチキャストルー
   ティング情報より優先ではありません;例えば、もしマルチキャストアドレ
   スのMLDv2フィルタモードが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.
   要約すると、次の表は、ソースからマルチキャストアドレス宛のトラフィッ
   クのルーティングプロトコルへの、MLDv2からの転送提案を記述します。
   これは同じくマルチキャストアドレスのルータフィルタモードに基づいてソー
   スタイマのタイムアウト時の行動を要約します。

     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.
   報告を含むMLDメッセージを受信したルータはメッセージのソースアドレ
   スが正当なリンクローカルアドレスであるかどうか、ホップ限界が1に設定
   されているかどうか、ルータ警告オプションがIPv6パケットのホップ毎
   オプションヘッダに存在しているかどうか調べます。もしこれらの検査のど
   れかが失敗するなら、パケットは廃棄されます。もしMLDメッセージの正
   当性が確かめられるなら、ルータは報告を処理し始めます。

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.
   現在状態レコードを受信する時、ルータがそのフィルタタイマとそのソース
   タイマの両方を最新のものにします。ある状況で、1つのタイプのマルチキャ
   ストアドレスレコードの受信はそのマルチキャストアドレスのルータフィル
   タモードの変更を起こすでしょう。下記の表は現在状態レコードを受信した
   ルータの状態とタイマに関する行動を記述します。

   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.
   問合せ期間(すなわち、最終受信者問合せ時間ミリ秒)にルータのMLDコ
   ンポーネントは、ルーティングプロトコルにトラフィックを転送するべきマ
   ルチキャストアドレスあるいはソースを示唆し続けます。最終受信者問合せ
   時間ミリ秒後に、照会されたマルチキャストアドレスかソースに対する受信
   を表現するレコードを受け取らなければ、ルータはリンクからマルチキャス
   トアドレスあるいはソースを削除してもよいです。

   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.
   我々は送る質問を記述するために次の表記を使います。我々はMAマルチキャ
   ストアドレスへのマルチキャストアドレス特定問合せを記述するために表記
   'Q(MA)'を使います。我々はソースリストAからMAマルチキャストアドレ
   スへのマルチキャストアドレスとソース特定問合せを記述するために表記
   'Q(MA,A)'を使います。もしソースリスト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.
   もし新しい問合せをする時に、すでに同じマルチキャストアドレスの再送待
   ちの問合せがあるなら、新しいのと、再送待ちの問合せは合併されなければ
   なりません。加えて、再送待ちの問合せがあるマルチキャストアドレスへの
   受信ホスト報告がそれらの問合せの中身に影響を与えるかもしれません。
   7.6.3章が再送待ちの質問の状態を形成して、持続するプロセスを記述し
   ます。
 

   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.
   問合せを含んでいるMLDメッセージを受信したら、ルータはメッセージの
   ソースアドレスが正当なリンクローカルアドレスであるかどうか、ホップ限
   界が1に設定されてるかどうか、そしてルータ警告オプションがIPv6パ
   ケットのホップ毎オプションヘッダに存在しているかどうか調べます。もし
   これらのチェックのいずれかが失敗するなら、パケットは廃棄されます。

   If the validity of the MLD message is verified, the router starts to
   process the Query.
   もしMLDメッセージの正当性が確かめられるなら、ルータは質問を処理し
   始めます。

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.
   MLDv2は、2.1章で説明したように、強靭性を保証するためにルータ側
   処理抑制フラグを使います。ルータが明確なルータ側処理抑制フラグで質問
   を送るか受ける時、マルチキャストアドレスあるいはソースを尋ねらること
   に関して正しいタイムアウト値を反映するためにそのタイマを更新しなくて
   はなりません。次の表はルータ側処理抑制フラグが設定されていないマルチ
   キャストアドレスあるいはマルチキャストアドレスとソース特定問合せを送
   信あるいは受信する時のタイマ行動を記述します。

   Query       Action
   問合        行動
   -----       ------
   Q(MA,A)     Source Timers for sources in A are lowered to LLQT
               Aのソースのソースタイマを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).
   MLDv2はサブネット毎に1つのルータが問合者状態であるように選出し
   ます;サブネット上のすべての他のルータは非問合者状態にあるべきです。
   MLDv2はMLDv1と同じ問合者選出メカニズム、すなわちIPv6ア
   ドレスを用います。ルータがサブネットで動作し始める時、デフォルトで自
   分自身を問合者であると考えます。それで、いくつかの一般問合せを短い間
   隔で送ります(詳細は9.6章と9.7章を見てください)。

   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.
   ルータが自分自身より小さいIPv6アドレスで問合せを受け取る時、他問
   合者存在タイマを他問合者存在タイムアウトに設定します;もし前に問合者
   状態にあったなら、非問合者状態に変わり、そして問合せをリンクの上に送
   ることをやめます。他の問合者存在タイマがタイムアウトすると、問合者状
   態に再びなり、一般問合せを送り始めるべきです。

   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.
   すべてのMLDv2の質問はFE80::/64リンクローカルソースアドレスプレ
   フィックスで送られなくてはなりません(MUST)。そのために、MLDv2問
   合者選出の目的で、もしアドレスAの最後の64ビットで表されるインタ
   フェースIDが、アドレスBの最後の64ビットで表されるインタフェー
   スIDより、ビッグエンディアンビット順で小さいなら、IPv6アドレ
   スAがIPv6アドレスBより小さいと考えられます。

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:
   7.4.2の表で問合者が表の行動"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のためにマルチキャストアドレスとソース特定問
   合せを構築する時、2つの別の質問メッセージがマルチキャストアドレスの
   ために送られます。最初のが「ルータ側処理抑制」ビットが設定され、再送
   状態でタイマがLLQTより大きい全てのソース(すなわち、そのマルチキャス
   トアドレスの再送リストのソース)を含みます。第2のは「ルータ側処理抑
   制」ビットがクリアされ、再送状態でタイマがLLQT以下の全てのソースを含
   んでいます。もし2つの計算されたメッセージのいずれかがソースを含まな
   いなら、その伝達は抑制されます。

   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.  MLDv1との相互運用

   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.
   MLDバージョン2ホストとルータがまだMLDv2にアップグレードされ
   ていないホストやルータと一緒に動作します。この互換性はホストとルータ
   がネットワーク上のMLDのバージョンに適切な行動をする事で維持されま
   す。

8.1.  Query Version Distinctions
8.1.  問合せバージョンの区別

   The MLD version of a Multicast Listener Query message is determined
   as follows:
   マルチキャスト受信者問合メッセージのMLDバージョンは次のように決意
   します:

   MLDv1 Query: length = 24 octets
   MLDv1問合:長さ=24オクテット

   MLDv2 Query: length >= 28 octets
   MLDv2問合:長さ≧28オクテット

   Query messages that do not match any of the above conditions (e.g., a
   Query of length 26 octets) MUST be silently ignored.
   上記の条件のいずれとも一致しない質問メッセージ(例えば、長さ26オク
   テットの質問)は静かに無視されなくてはなりません(MUST)。

8.2.  Multicast Address Listener Behavior
8.2.  マルチキャストアドレス受信者行動

8.2.1.  In the Presence of MLDv1 Routers
8.2.1.  MLDv1ルータがある場合

   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.
   MLDv1ルータと両立できるために、MLDv2ホストがバージョン1互
   換モードで動作しなくてはなりません(MUST)。MLDv2ホストがそれぞれ
   の接続リンクの互換モードに関してローカルインタフェース毎に状態を維持
   しなくてはなりません(MUST)。ホストの互換モードは2つの状態のどちらか
   にあるホスト互換モード変数で決定されます:MLDv1あるいはMLDv2。

   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.
   インタフェースのホスト互換性モードは、MLDv1マルチキャストアドレ
   ス受信者問合せをそのインタフェース上で受け取る時にMLDv1に設定さ
   れます。同時に、インタフェースの旧バージョン問合存在タイマは現在の旧
   バージョン問合者存在タイムアウト秒に設定されます。タイマは、新しい
   MLDv1問合せをそのインタフェース上に受け取る毎に設定されます。も
   し旧バージョン問合者存在タイマがタイムアウトするなら、ホストは
   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.
   ホスト互換モードがMLDv2である時、ホストがそのインタフェース上で
   MLDv2プロトコルを使って行動をします。ホスト互換モードがMLDv
   1である時、ホストがそのインタフェースの上でMLDv1プロトコルだけ
   を使っうMLDv1互換モードで行動します。

   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.
   MLDv1問合者が一般問合せで最大応答コードに望ましい最大応答遅延を
   送るでしょう、すなわち、このフィールドの最大範囲は線形で、そして
   5.1.3章.で記述された指数のアルゴリズムは使われません。

   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.  MLDv1マルチキャストアドレス受信者が存在する場合

   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.
   MLDv2ホストがMLDv1ホストがあるリンク上に置かれるかもしれま
   せん。ホストがバージョン1マルチキャスト受信者報告で抑制されるMLD
   v2マルチキャスト受信者報告を許すかもしれません(MAY)。

8.3.  Multicast Router Behavior
8.3.  マルチキャストルーター行動

8.3.1.  In the Presence of MLDv1 Routers
8.3.1.  MLDv1ルータがある場合

   MLDv2 routers may be placed on a network where there is at least one
   MLDv1 router.  The following requirements apply:
   MLDv2ルータは少なくとも1つのMLDv1ルータがあるネットワーク
   上に置かれるかもしれません。次の必要条件は適用されます:

   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  もしMLDv1ルータがリンクの上に存在しているなら、問合者はネット
      ワーク上に存在する最も低いMLDのバージョンを使わなくてはなりませ
      ん(MUST)。これは管理的に確実であるに違いありません。MLDv1と両
      立を望むルータはMLDv1モードで行動をする設定オプションを持って
      いなくてはなりません(MUST);もしMLDv1ルータがリンク上に存在し
      ているなら、システム管理者は明示的にすべてのMLDv2ルータをML
      Dv1モードで動作するように設定しなくてはなりません。MLDv1モー
      ド時に、問合者は周期的に、マルチキャストアドレスフィールドを切り捨
      てた(すなわち、24バイト長の)、一般問合せを送らなければならず
      (MUST)、そしてMLDv2質問の受信に対して警告をすべきです(SHOULD)
      (このような警告は率を限定されるに違いありません)。問合者は最大の
      回答コードフィールドに、同じく最大の回答遅延を記入しなくてはなりま
      せん(MUST)、すなわち5.1.3章で記述された指数アルゴリズムは使われ
      ません。

   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  もしルータが明示的にMLDv1を使うように設定されず、そしてMLD
      v1一般問合せを受信するなら、警告をログファイルに書くべきです
      (SHOULD)。これらの警告は率限定されているに違いありません(MUST)。

8.3.2.  In the Presence of MLDv1 Multicast Address Listeners
8.3.2.  MLDv1マルチキャストアドレス受信者が存在する場合

   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.
   MLDv2ルータはMLDv2に更新されていないホストがあるネットワー
   ク上に置かれるかもしれません。MLDv1ホストと互換性のために、ML
   Dv2ルータはバージョン1の互換モードで動作しなくてはなりません(MUST)。
   MLDv2ルータがマルチキャストアドレスレコード毎に互換性モードを維
   持します。マルチキャストアドレスの互換モードはマルチキャストアドレス
   互換モード変数から決定され、そしてこれは2つの次の状態です:
   MLDv1あるいはMLDv2。

   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.
   マルチキャストアドレスレコードのマルチキャストアドレス互換性モードは、
   そのマルチキャストアドレスに対してMLDv1マルチキャスト受信者報告
   を受信したらMLDv1に設定されます。同時に、マルチキャストアドレス
   の旧バージョンホスト存在タイマは、旧バージョンホスト存在タイムアウト
   秒に設定されます。タイマは、そのマルチキャストアドレスの新しいMLD
   v1報告を受信するたびにリセットされます。もし旧バージョンホスト存在
   タイマがタイムアウトするなら、ルータはそのマルチキャストアドレスのマ
   ルチキャストアドレス互換モードをMLDv2に戻します。

   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.
   ルータがマルチキャストアドレスに対してマルチキャストアドレス互換モー
   ドをMLDv2に戻すとき、ソース特定状態情報を回復するのにいくらかの
   時間を要することを注意を払ってください。ソース特定情報が次の一般問合
   せの間に学ばれるでしょう、しかし止めるべきソースはその後[マルチキャス
   トアドレス受信者間隔]まで止まらないでしょう。

   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:
   マルチキャストアドレス互換モードがMLDv2である時、ルータがそのマ
   ルチキャストアドレスでMLDv2プロトコルを使って行動をします。マル
   チキャストアドレス互換モードがMLDv1である時、ルータはそのマルチ
   キャストアドレスのMLDv1メッセージを内部でMLDv2同等物に翻訳
   します:

   MLDv1 Message                 MLDv2 Equivalent
   MLDv1メッセージ          MLDv2同等物
   -------------                 ----------------

      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.
   MLDv2ブロックメッセージがTO_EX()メッセージのソースリストとして無
   視されます(すなわち、どんなTO_EX()メッセージもTO_EX( {} )として扱わ
   れます)。他方問合者は、そのマルチキャストアドレス互換モードにかかわ
   らず、MLDv2問合せの送信を継続します。

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.
   信頼性変数はリンク上で予想されるパケット損失の調整を許します。もしリ
   ンクのロスが大きいと期待されるなら、信頼性変数の値は増やされるかもし
   れません。MLDは[信頼性変数-1]のパケット損失に対して強靭です。信頼
   性変数の値はゼロであってはならならず(MUST NOT)、1であるべきではあり
   ません(SHOULD NOT)。デフォルト価値:2。

9.2.  Query Interval
9.2.  質問間隔

   The Query Interval variable denotes the interval between General
   Queries sent by the Querier.  Default value: 125 seconds.
   質問間隔変数は問合者によって送られた一般問合せの間隔を示します。デ
   フォルト値:125秒。

   By varying the [Query Interval], an administrator may tune the number
   of MLD messages on the link; larger values cause MLD Queries to be
   sent less often.
   [質問間隔]を変えることによって、管理者ががリンク上のMLDメッセージ
   数を調整してもよいです;より大きい値がMLDの質問をより少なくします。

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)
   最大回答遅延は周期的な一般問合せに挿入された最大回答コードを計算する
   のに使います。デフォルト値:10000(10秒)。

   By varying the [Query Response Interval], an administrator may tune
   the burstiness of MLD messages on the link; larger values make the
   traffic less bursty, as 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].
   [質問回答間隔]を変えることによって、管理者がリンク上のMLDメッセー
   ジの集中度を調整してもよいです;より大きい値が、ホスト回答をより大き
   い間隔に広げるので、トラフィックをより少なく集中させます。[質問回答間
   隔]で表される秒数は[質問間隔]より少いに違いありません。

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].
   マルチキャストアドレス受信間隔(MALI)は、マルチキャストルータが
   リンクにこれ以上のマルチキャストアドレスあるいは特定のソースの受信者
   がいないと決定する前に、待たなくてはならない時間量です。この値は
   ([信頼性変数]×[質問間隔])+[質問応答間隔]に違いありません(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]).
   他問合者存在タイムアウトは、マルチキャストルータが問合者であるべき他
   のマルチキャストルータがないと決定する前に待たなくてはならない時間の
   長さです。この値は([信頼性変数]×[質問間隔])+([質問応答間隔]の
   2分の1)に違いありません(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].
   始動質問間隔は問合者が起動時に送る一般問合せの間隔です。デフォルト値:
   [質問間隔]の1/4。

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).
   最終受信者質問間隔は、バージョン1マルチキャスト受信者完了メッセージ
   に応えて送られるマルチキャストアドレス特定問合せに挿入される最大回答
   コードを計算するために使われます。これはまたマルチキャストアドレスと
   ソース特定問合せメッセージに挿入された最大回答コードを計算するために
   使われる最大応答遅延です。デフォルト値:1000(1秒)。

   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.
   32.768秒より大きいLLQI値のために、最大回答コードの連続的な
   値に対応して、限定された値だけが表現できる事に注意を払ってください。
   設定された時間を最大の回答コード値に換える時、もし可能なら正確な値を、
   もし求められた値を正確に表示することができないなら次のより低い値を使
   うことが勧められます。

   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.
   望まれない報告間隔はマルチキャストアドレスに対するノードの受信の最初
   の報告の間隔です。デフォルト値:1秒。

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].
   旧版問合者存在タイムアウトはホストがMLDv2ホスト互換モードに戻る
   までにタイムアウト時間です。MLDv1の質問を受信する時、MLDv2
   ホストは旧版問合者存在タイマを[旧版問合者存在タイムアウト]に設定しま
   す。

   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].
   旧版ホスト存在タイムアウトは、ルータが特定のマルチキャストアドレスに
   対してMLDv2マルチキャストアドレス互換モードから戻るまでのタイム
   アウトです。そのマルチキャストアドレスのMLDv1報告を受信する時、
   ルータはその旧版ホスト存在タイマを[旧版ホスト存在タイムアウト]に設
   定します。

   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).
   信頼性変数はリンク上で予想される損失に対してMLDを調整します。ML
   Dv2は[信頼性変数]−1のパケット損失に対して強靭で、例えば、もし信
   頼性変数がデフォルト値の2に設定されるなら、MLDv2はひとつのパケッ
   ト損失に対して強靭です、しかし、もしより多くの損失が起こるなら、不完
   全に動作するかもしれません。損失の多いリンク上で、信頼性変数値はパケッ
   ト損失の予想レベルを考慮して増加されるべきです。しかしながら、信頼性
   変数値を増やすことはリンクの離脱遅延(最後の受信者がソースあるいはマ
   ルチキャストアドレスの受信をやめる時からトラフィック流出が止まるまで
   の時間)を増やします。
 
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.
   周期的なMLDトラフィックの全体的なレベルは質問間隔逆比例します。よ
   り長い質問間隔は全体的なMLDトラフィックをより低いレベルにします。
   問合せ間隔の値は一般問合せメッセージに挿入された最大回答コードを計算
   するために使った最大応答遅延以上であるに違いありません(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:
   MLDトラフィックの集中性は最大応答遅延に反比例しています。より長い
   最大応答遅延がより長い間隔に報告メッセージを広めるでしょう。しかしな
   がら、マルチキャストアドレス特定とマルチキャストアドレスとソース特定
   問合せのより長い最大回答遅延は離脱遅延(最後の受信者がソースあるいは
   マルチキャストアドレスの受信を止めてから、トラフィック流出が止まるま
   での時間)を長くします。報告メッセージの期待された率は予想される報告
   の数を最大応答遅延で割ることで計算できます。最大応答遅延は次のように
   質問に対する報告の予想される数を使って、質問毎に動的に計算されるかも
   しれません:

   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.
   我々はそれぞれのタイプの偽造されたメッセージの成り行きを考慮します。
   MLDメッセージを処理する前に、ノードがメッセージのソースアドレスが
   正当なリンクローカルアドレス(あるいは特定されていないアドレス)であ
   るかどうか、ホップ限界が1に設定されるかどうか、そしてルータ警告オプ
   ションがIPv6パケットのホップ毎オプションヘッダに存在しているかど
   うか確かめることに注意を払ってください。もしこれらのチェックのどれか
   が失敗するなら、パケットは廃棄されます。これはリンク外で偽造されたM
   LDメッセージによる動作からMLDv2ノードを守ります。それ故に、以
   下でただリンク上の偽造の効果だけを論じます。

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].
   現在の問合者より低いIPv6アドレスを持っている機械からの偽造された
   質問メッセージは、問合者任務を偽造者に割り当てられさせるでしょう。も
   し偽造者がそれ以上の質問メッセージを送らないなら、他のルータの他問合
   者存在タイマはタイムアウトし、そして1つのルータが問合者の役割を再開
   するでしょう。この間に、もし偽造者がマルチキャスト受信完了メッセージ
   を無視するなら、トラフィックが最大[マルチキャストアドレス受信者間隔]
   の間、受信者がいないマルチキャストアドレスが流れるかもしれません。

   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.
   偽造された1版の問合せメッセージはリンク上のMLDv2受信者をMLD
   v1ホスト互換モードにするでしょう。このシナリオは完全に1版メッセー
   ジを無視する設定をMLDv2ホストに提供することにで避けることができ
   ます。

   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.
   偽装マルチキャストアドレスとソース特定問合せを通してノード上のサービ
   ス妨害攻撃の可能性があります。攻撃者は一般的な質問で特定のノードの受
   信状態を発見することができます。その後に、それぞれが大きなソースリス
   トや長い最大応答遅延をもつ、多数のマルチキャストアドレスとソース特定
   問合せを送ることができます。ノードはそれらすべての問合せで指定された
   ソースを、遅延応答で指定された送信時まで、保存し維持しなければならな
   いでしょう。これは連続した問合せに含まれるソースリストに記録されたソー
   スを増により、メモリとCPUサイクルの両方を消費するでしょう。

   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.
   偽造された1版の報告メッセージは、ルータがMLDv2ソース特定状態メッ
   セージを無視することを意味し、特定のマルチキャストアドレスに対してルー
   タをMLDv1マルチキャストアドレス互換モードにするかもしれません。
   これはトラフィックを最大[マルチキャストアドレス受信者間隔]の間、不要
   なソースから流すことができます。これは完全に1版のメッセージを無視す
   る設定スイッチをルータに提供することによって解決できます。これは1版
   のホストとの自動的な互換性を失わせます、それでこれはソースフィルタが
   重要な状態でだけ使うべきです。

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の考慮

   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.
   IANAは、5.2.14章で記述されるように「全MLDv2対応のルータ」
   と呼ばれる、IPv6リンクローカルマルチキャストアドレス
   FF02:0:0:0:0:0:0:16を割り当てました。2版マルチキャスト受信者報告が
   この特別なアドレスに送られるでしょう。

   In addition, IANA has assigned the ICMPv6 message type value of 143
   for Version 2 Multicast Listener Report messages, as specified in
   section 4.
   加えて、IANAは、4章で指定されるように、2版マルチキャスト受信者
   報告メッセージのためにICMPv6メッセージタイプ値143を割り当て
   ました。

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。  デザイン原理

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.
   MLDv2はマルチキャスト受信者報告の2つの種類を指定します:現在状
   態と状態変更。この章は両方のこれらのタイプの報告の必要性の原理を記述
   します。

   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.).
   ルータが問合せに応えて送られたマルチキャスト受信者報告をインターフェー
   ス毎の状態の変更の結果として送られたのと区別する必要があります。マル
   チキャストアドレス受信者問合に応えて送られるマルチキャスト受信者報告
   は主にルータの既存の状態を更新するために使われます;それらは典型的に
   ルータで状態遷移を起こしません。インターフェース毎の状態の変更に応え
   て送られるマルチキャスト受信者報告がルータの受信した報告に応えてある
   行動をとるように要求します(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.
   報告の2つの種類を区別することができなければ、ルータはすべてのマルチ
   キャスト受信者報告を状態変更の可能性があるものと取り扱うことになり、
   そしてルータ処理同様にリンク上のMLDトラフィックの増加をもたらすで
   しょう。

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.
   MLDv1で、もし類似の報告がリンク上の他の受信者から送られたなら、
   ホストは予定したマルチキャスト受信者報告を送らないでしょう。MLDv
   2で、マルチキャスト受信者報告の抑制は削除されました。次の点はこの決
   定を説明します。

   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. ルータがインタフェース上でホスト毎のマルチキャスト受信状態の追跡を
      望むかもしれません。これはルータに即時離脱(例えば、層状マルチキャ
      スト輻輳制御案)やセキュリティや課金のための受信者状態追跡の実行を
      許すでしょう。現在の指定はルータにホスト毎の追跡を実装するように要
      求しません。にもかかわらず、MLDv2でのホスト抑圧の欠如は、専用
      もしくは将来の標準で、この仕様に完全に準拠するMLDv2受信者とルー
      タと協調動作可能なまま、ホスト毎の追跡を支援するルータを導入するこ
      とが可能であるようにします。

   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. ブリッジLANでマルチキャスト受信者報告抑制がうまく機能しません。
      MLD覗き見をサポートする多数のブリッジや2層/3層スイッチが、マ
      ルチキャスト受信者報告抑圧を妨げるため、LANセグメントを越えるM
      LDメッセージを転送しません。

   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. MLDv2で、送信パケット数を減少させるためにひとつのマルチキャス
      ト受信者報告に多数のマルチキャストアドレスレコードをまとめます。比
      較すると、MLDの前のバージョンはそれぞれのマルチキャストアドレス
      が別のメッセージで報告されることを要求しました。

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モードでなければなりません
   (7.2.1章参照)。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.
   これを達成する方法の1つは、ルータ自身がEXCLUDEモードであっても、ルー
   タがINCLUDEモードのノードの全てのソースを追跡することです。もしマルチ
   キャストアドレスのフィルタタイマがタイムアウトするなら、それはリンク
   にEXCLUDEモードにノードがないことを意味します(さもなければそのノード
   からのマルチキャスト受信報告がフィルタタイマを更新したでしょう)。ルー
   タはスムーズにINCLUDEモードに切替えることができます;要求リストのソー
   スは組込リストに動かされる、他方除外リストのソースが削除されます。

APPENDIX B.  Summary of Changes from MLDv1
付録B。  MLDv1からの変更の要約

   The following is a summary of changes from MLDv1, specified in RFC
   2710.
   以下がRFC2710で指定されたMLDv1からの変更の要約です。

   o  MLDv2 introduces source filtering.
   o  MLDv2はソースフィルタを導入します。

   o  The IP service interface of MLDv2 nodes is modified accordingly.
      It enables the specification of a filter mode and a source list.
   o  MLDv2ノードのIPサービスインタフェースはそれ相応に修正されま
      す。これはフィルタモードとソースリストの仕様を可能にします。

   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  MLDv2ノードがそれぞれのマルチキャストアドレスのためにフィルタ
      モードとソースリストを含むソケット毎とインターフェース毎のマルチキャ
      スト受信状態を保持します。これはソケットのマルチキャスト受信状態に
      基づいたパケットフィルタリングを可能にします。

   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  ルータ上のMLDv2状態は、リンク上に受信者がいるそれぞれのマルチ
      キャストアドレスのためにフィルタモードとソースとソースタイマのリス
      トを含みます。MLDv1ルータはただマルチキャストアドレスのリスト
      だけを保持しました。

   o  Queries include additional fields (section 5.1).
   o  質問が追加のフィールド(5.1章)を含みます。

   o  The S flag (Suppress Router-Side Processing) is included in
      queries in order to fix robustness issues.
   o  Sフラグ(ルータ側処理抑制)は強靭性問題を直すための問合せに含めら
      れます。

   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  問合者の信頼性変数と問合せ間隔コードは、同じリンクで接続したすべて
      のMLDv2ルータを同期させるために問合せに含められます。

   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  最大回答遅延は直接質問に含められません。その代わりに、問合せに含め
      られた最大回答コードに基づいていてその値を計算するために、指数アル
      ゴリズムが使われます。最大の値は65535ミリ秒からおよそ140分
      まで増やされます。

   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  報告が、MLDv1でのホストが受信するマルチキャストアドレスの代わ
      りに、「全MLDv2対応マルチキャストルータ」アドレスに送られます。
      これは2層覗き見スイッチの運用を容易にします。

   o  There is no "host suppression", as in MLDv1.  All nodes send
      Report messages.
   o  MLDv1の「ホスト抑制」がありません。すべてのノードは報告メッセー
      ジを送ります。

   o  Unsolicited Reports, announcing changes in receiver listening
      state, are sent [Robustness Variable] times.  RFC 2710 is less
      explicit.
   o  受信者の受信状態変更を公表する、望まれない報告は[信頼性変数]回、
      送られます。RFC2710はあいまいです。

   o  There are no Done messages.
   o  Doneメッセージがありません。

   o  Interoperability with MLDv1 systems is achieved by MLDv2 state
      operations.
   o  MLDv1システムとの互換性がMLDv2状態運用によって成し遂げら
      れます。

   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].
   この文書はIPv6意味論の[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.
   著作権(C)インターネット学会(2004)。この文書はBCP78に含
   まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
   は著者がすべての権利を維持します。

   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.
   この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンラインIPR
   貯蔵庫で得られます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So