[要約] RFC 3376は、IGMPv3の仕様を定義しており、マルチキャストグループの管理を改善することを目的としています。IGMPv3は、ホストがマルチキャストグループへの参加や離脱を効率的に行うためのプロトコルです。
Network Working Group B. Cain
Request for Comments: 3376 Cereva Networks
Obsoletes: 2236 S. Deering
Category: Standards Track I. Kouvelas
Cisco Systems
B. Fenner
AT&T Labs - Research
A. Thyagarajan
Ericsson
October 2002
Internet Group Management Protocol, Version 3
インターネットグループ管理プロトコル、バージョン3
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
Abstract
概要
This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.
このドキュメントでは、インターネットグループ管理プロトコルIGMPv3のバージョン3を指定しています。IGMPは、IPv4システムが隣接マルチキャストルータにIPマルチキャストグループメンバシップを報告するために使用されるプロトコルです。IGMPのバージョン3は、「ソースフィルタリング」のサポート、つまり、特定のソースアドレスからのみ*のみ*のみを受信するための関心を報告する能力を追加します。。その情報は、特定のソースからのマルチキャストパケットをネットワークに配信するのを避けるためにマルチキャストルーティングプロトコルによって使用されてもよい。
This document obsoletes RFC 2236.
この文書はRFC 2236を廃止します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Service Interface for Requesting IP Multicast Reception . 3
3. Multicast Reception State Maintained by Systems . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
5. Description of the Protocol for Group Members . . . . . . . . 19
6. Description of the Protocol for Multicast Routers . . . . . . 24
7. Interoperation with Older Versions of IGMP. . . . . . . . . . 35
8. List of Timers, Counters, and Their Default Values. . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
12. Normative References. . . . . . . . . . . . . . . . . . . . . 47
13. Informative References. . . . . . . . . . . . . . . . . . . . 47
Appendix A. Design Rationale. . . . . . . . . . . . . . . . . 49
Appendix B. Summary of changes from IGMPv2. . . . . . . . . . 50
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 53
The Internet Group Management Protocol (IGMP) is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to any neighboring multicast routers. Note that an IP multicast router may itself be a member of one or more multicast groups, in which case it performs both the "multicast router part" of the protocol (to collect the membership information needed by its multicast routing protocol) and the "group member part" of the protocol (to inform itself and other, neighboring multicast routers of its memberships).
インターネットグループ管理プロトコル（IGMP）は、IPv4システム（ホストとルーター）が使用して、IPマルチキャストグループメンバーシップを隣接するマルチキャストルータに報告します。IPマルチキャストルータ自体が1つ以上のマルチキャストグループのメンバーである可能性があるため、プロトコルの「マルチキャストルータ部」（マルチキャストルーティングプロトコルに必要なメンバーシップ情報を収集する）と「グループ」の両方を実行します。プロトコルのメンバー部分（自分自身やその他のメンバーシップの隣接マルチキャストルータ）。
IGMP is also used for other IP multicast management functions, using message types other than those used for group membership reporting. This document specifies only the group membership reporting functions and messages.
IGMPは、グループメンバーシップレポートに使用されているもの以外のメッセージタイプを使用して、他のIPマルチキャスト管理機能にも使用されます。このドキュメントでは、グループメンバーシップレポート作成機能とメッセージのみを指定します。
This document specifies Version 3 of IGMP. Version 1, specified in [RFC-1112], was the first widely-deployed version and the first version to become an Internet Standard. Version 2, specified in [RFC-2236], added support for "low leave latency", that is, a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network. Version 3 adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, as required to support Source-Specific Multicast [SSM], or from *all but* specific source addresses, sent to a particular multicast address. Version 3 is designed to be interoperable with Versions 1 and 2.
このドキュメントはIGMPのバージョン3を指定します。[RFC-1112]で指定されているバージョン1は、インターネット規格になる最初の広範な展開版と最初のバージョンでした。[RFC-2236]で指定されているバージョン2、「LOW LATENCEY」のサポート、つまりマルチキャストルータが存在する特定のグループのメンバーが存在しなくなるのにかかる時間の短縮です。接続ネットワークバージョン3は、ソース固有のマルチキャスト[SSM]をサポートするために必要に応じて、Source Filteringのサポート、つまりパケットの受信能力*のみ*のみを報告する能力を特定の送信元アドレスから報告します。特定のマルチキャストアドレスに送信された特定の送信元アドレス。バージョン3はバージョン1と2と相互運用可能になるように設計されています。
Multicast Listener Discovery (MLD) is used in a similar way by IPv6 systems. MLD version 1 [MLD] implements the functionality of IGMP version 2; MLD version 2 [MLDv2] implements the functionality of IGMP version 3.
マルチキャストリスナーディスカバリ（MLD）は、IPv6システムによって同様の方法で使用されます。MLDバージョン1 [MLD] IGMPバージョン2の機能を実装しています。MLDバージョン2 [MLDv2] IGMPバージョン3の機能を実装しています。
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 [RFC-2119]. Due to the lack of italics, emphasis is indicated herein by bracketing a word or phrase in "*" characters.
資本化されたキーワードは「必須」、「必須」、「必須」、「SEQUR」、「しない」、「「推奨」、「推奨」、「5月」、および「オプション」、「オプション」[RFC-2119]に記載されているように解釈されます。イタリック体が不足しているため、「*」文字で単語やフレーズを括弧で囲むことによって強調が示されています。
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 and disable reception of packets sent to specific IP multicast addresses. In order to take full advantage of the capabilities of IGMPv3, a system's IP service interface must support the following operation:
IPシステム内では、（少なくとも概念的に）IPレイヤが特定のIPマルチキャストアドレスに送信されたパケットの受信を有効にし無効にするためにIPレイヤに依頼するために（少なくとも概念的に）IPレイヤーに依頼する。IGMPv3の機能を最大限に活用するには、システムのIPサービスインタフェースが次の操作をサポートしている必要があります。
IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list )
IPMulticastListen（ソケット、インタフェース、マルチキャストアドレス、フィルタモード、ソースリスト）
where:
ただし：
o "socket" is an implementation-specific parameter used to distinguish among different requesting entities (e.g., programs or processes) within the system; the socket parameter of BSD Unix system calls is a specific example.
o "socket"は、システム内のさまざまな要求エンティティ（例えば、プログラムやプロセス）を区別するために使用される実装固有のパラメータです。BSD UNIXシステムコールのSocketパラメータは具体例です。
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 the endpoint of 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 system (perhaps established by system configuration). If reception of the same multicast address is desired on more than one interface, IPMulticastListen is invoked separately for each desired interface.
o 「インタフェース」は、指定されたマルチキャストアドレスの受信を有効または無効にするネットワークインタフェースのローカル識別子です。インタフェースは、物理的（例えば、イーサネットインターフェース）または仮想（例えば、フレームリレー仮想回線の終点またはIPインポーラトトンネルのエンドポイント）であり得る。実装は、特別な「未指定」値をインターフェイスパラメータとして渡すことを可能にし、その場合、要求はシステムの「プライマリ」または「デフォルト」インターフェースに適用されます（おそらくシステム構成によって確立された）。同じマルチキャストアドレスの受信が複数のインタフェースで望まれる場合、IPMulticastListenは所望のインタフェースごとに個別に呼び出されます。
o "multicast-address" is the IP multicast address, or group, to which the request pertains. If reception of more than one multicast address on a given interface is desired, IPMulticastListen is invoked separately for each desired multicast address.
o 「マルチキャストアドレス」は、要求が関係するIPマルチキャストアドレスまたはグループです。特定のインターフェイス上の複数のマルチキャストアドレスの受信が望まれる場合、IPMulticastListenは所望のマルチキャストアドレスごとに個別に呼び出される。
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 those IP source addresses listed in the source-list parameter. In EXCLUDE mode, reception of packets sent to the given multicast address is requested from all IP source addresses *except* those listed in the source-list parameter.
o 「フィルタモード」は含めるか除外することができます。インクルードモードでは、指定されたマルチキャストアドレスに送信されたパケットの受信が、source-listパラメータにリストされているIPソースアドレスから*のみ*のみを要求されます。除外モードでは、指定されたマルチキャストアドレスに送信されたパケットの受信は、source-listパラメータにリストされているものを除くすべてのIP送信元アドレス*から要求されます。
o "source-list" is an unordered list of zero or more IP 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, but that limit MUST NOT be less than 64 addresses per list. When an operation causes the source list size limit to be exceeded, the service interface MUST return an error.
o "source-list"は、フィルタモードに応じて、マルチキャスト受信が望まれるか望まれないゼロまたはそれ以上のIPユニキャストアドレスの順序付けられていないリストです。実装は、ソースリストのサイズに制限を課すかもしれませんが、その制限はリストごとに64個以上のアドレスを下回る必要があります。操作によってソースリストサイズ制限を超えると、サービスインタフェースはエラーを返す必要があります。
For a given combination of socket, interface, and multicast address, only a single filter mode and source list can be in effect at any one time. However, either the filter mode or the source list, or both, may be changed by subsequent IPMulticastListen requests that specify the same socket, interface, and multicast address. Each subsequent request completely replaces any earlier request for the given socket, interface and multicast address.
ソケット、インタフェース、およびマルチキャストアドレスの指定された組み合わせでは、単一のフィルタモードとソースリストのみが一度に有効になる可能性があります。ただし、フィルタモードまたはソースリスト、またはその両方は、同じソケット、インターフェイス、およびマルチキャストアドレスを指定する後続のIPMulticastListen要求によって変更されます。後続の各要求は、特定のソケット、インターフェイス、およびマルチキャストアドレスに対する以前の要求を完全に置き換えます。
Previous versions of IGMP did not support source filters and had a simpler service interface consisting of Join and Leave operations to enable and disable reception of a given multicast address (from *all* sources) on a given interface. The equivalent operations in the new service interface follow:
以前のバージョンのIGMPは、ソースフィルタをサポートしていませんでした。新しいサービスインタフェースでの同等の操作は次のとおりです。
The Join operation is equivalent to
結合操作はに相当します
IPMulticastListen ( socket, interface, multicast-address, EXCLUDE, {} )
IPMulticastListen（ソケット、インタフェース、マルチキャストアドレス、除外、{}）
and the Leave operation is equivalent to:
そして休暇操作は次のとおりです。
IPMulticastListen ( socket, interface, multicast-address, INCLUDE, {} )
IPMulticastListen（ソケット、インタフェース、マルチキャストアドレス、include、{}）
where {} is an empty source list.
{}は空のソースリストです。
An example of an API providing the capabilities outlined in this service interface is in [FILTER-API].
このサービスインタフェースに概説されている機能を提供するAPIの例は[フィルタ-API]にあります。
For each socket on which IPMulticastListen has been invoked, the system records the desired multicast reception state for that socket. That state conceptually consists of a set of records of the form:
IPMulticastListenが呼び出された各ソケットに対して、システムはそのソケットに対して目的のマルチキャスト受信状態を記録します。その状態は概念的にフォームの一連のレコードで構成されています。
(interface, multicast-address, filter-mode, source-list)
（インターフェース、マルチキャストアドレス、フィルタモード、ソースリスト）
The socket state evolves in response to each invocation of IPMulticastListen on the socket, as follows:
次のように、ソケット状態は、ソケット上のIPMulticastListenの各呼び出しに応答して進化します。
o If the requested filter mode is INCLUDE *and* the requested source list is empty, then the entry corresponding to the requested interface and multicast address is deleted if present. If no such entry is present, the request is ignored.
o 要求されたフィルタモードに*および*要求されたソースリストが空の場合、要求されたインターフェイスとマルチキャストアドレスに対応するエントリが存在する場合には削除されます。そのようなエントリが存在しない場合、要求は無視されます。
o If the requested filter mode is EXCLUDE *or* the requested source list is non-empty, then the entry corresponding 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 要求されたフィルタモードが除外*または*要求されたソースリストが空でない場合、要求されたインターフェイスとマルチキャストアドレスに対応するエントリが存在する場合は、要求されたフィルタモードとソースリストを含むように変更されます。そのようなエントリが存在しない場合は、要求に指定されたパラメータを使用して新しいエントリが作成されます。
In addition to the per-socket multicast reception state, a system must also maintain or compute multicast reception state for each of its interfaces. That state conceptually consists of a set of records of the form:
ソケットごとのマルチキャスト受信状態に加えて、システムはそのインタフェースごとにマルチキャスト受信状態を維持または計算する必要があります。その状態は概念的にフォームの一連のレコードで構成されています。
(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 the per-socket state 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で次の操作を呼び出すとします。
IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
IPMulticastListen（S1、I、M、INCLUDE、{A、B、C}）
requesting reception on interface i of packets sent to multicast address m, *only* if they come from source a, b, or c. Suppose another application or process invokes the following operation on socket s2:
マルチキャストアドレスMに送信されたパケットのインターフェイスIの受信を要求する。*ソースA、B、またはCから来た場合は*。別のアプリケーションまたはプロセスがソケットS2で次の操作を呼び出すとします。
IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
IPMulticastListen（S2、I、M、{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 reception state of interface i for multicast address m has filter mode INCLUDE and source list {a, b, c, d}.
同じマルチキャストアドレスmに送信されたパケットの同じインタフェースi上での受信を要求する。*それらがソースB、C、またはDから来た場合は*。両方のソケットの受信要件を満たすためには、インタフェースIが、ソースA、B、C、またはDのいずれかからMに送信されるパケットを受信する必要がある。したがって、この例では、マルチキャストアドレスMのインタフェースIの受信状態は、フィルタモード、およびソースリスト{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 listening on a particular socket depends on the multicast reception 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 will be delivered on socket s1 but not on socket s2. Note that IGMP Queries and Reports are not subject to source filtering and must always be processed by hosts and routers.
マルチキャストパケットがIP層によってインターフェースから受け入れられた後、その後のアプリケーションへのその後の配信または特定のソケットをリッスンするプロセスのリスニングは、そのソケットのマルチキャスト受信状態に依存している[おそらく他の条件、例えばトランスポート - レイヤーポートソケットがバインドされています。したがって、上記の例では、パケットがマルチキャストアドレスMに到着した場合、マルチキャストアドレスMと送信元アドレスAを介して、ソケットS1で配信され、ソケットS2では提供されない。IGMPクエリとレポートはソースフィルタリングの影響を受けず、常にホストとルータで処理する必要があります。
Filtering of packets based upon a socket's multicast reception state is a new feature of this service interface. The previous service interface [RFC1112] described no filtering based upon multicast join state; rather, a join on a socket simply caused the host to join a group on the given interface, and packets destined for that group could be delivered to all sockets whether they had joined or not.
ソケットのマルチキャスト受信状態に基づくパケットのフィルタリングは、このサービスインタフェースの新機能です。以前のサービスインタフェース[RFC1112]は、マルチキャスト結合状態に基づいてフィルタリングされていない。むしろ、ソケット上の結合は、ホストが与えられたインターフェイス上のグループに参加するだけで、そのグループ宛てのパケットは、それらが参加したかどうかにかかわらず、すべてのソケットに配信される可能性があります。
The general rules for deriving the per-interface state from the per-socket state are as follows: For each distinct (interface, multicast-address) pair that appears in any socket state, a per-interface record is created for that multicast address on that interface. Considering all socket records containing the same (interface, multicast-address) pair,
ソケットごとの状態からインターフェイスごとの状態を導出するための一般的な規則は次のとおりです。ソケット状態にある各区別（インターフェイス、マルチキャストアドレス）ペアでは、そのマルチキャストアドレスのインターフェイスごとのレコードが作成されます。そのインターフェース。同じ（インターフェース、マルチキャストアドレス）ペアを含むすべてのソケットレコードを考えると、
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 * any *のようなレコードのフィルタモードが除外されている場合、インターフェイスレコードのフィルタモードは除外され、インターフェイスレコードのソースリストは除外モードでのすべてのソケットレコードのソースリストの交差点で、それらのソースを引いたものです。includeモードで任意のソケットレコードに表示されるアドレス。たとえば、インターフェイス上のマルチキャストアドレスMのソケットレコードが次のとおりです。
from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3: ( i, m, INCLUDE, {d, e, f} )
then the corresponding interface record on interface i is:
次に、インターフェイスiの対応するインタフェースレコードは次のとおりです。
( m, EXCLUDE, {b, c} )
（m、除外、{b、c}）
If a fourth socket is added, such as:
次のような4番目のソケットが追加された場合
from socket s4: ( i, m, EXCLUDE, {} )
then the interface record becomes:
その後、インターフェイスレコードは次のようになります。
( m, EXCLUDE, {} )
（m、除外、{}）
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 * all *のようなレコードのフィルタモードが含まれている場合、インターフェイスレコードのフィルタモードにはインターフェイスレコードが含まれ、インターフェイスレコードのソースリストはすべてのソケットレコードのソースリストの共用体です。たとえば、インターフェイス上のマルチキャストアドレス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} )
（m、{a、b、c、d、e、f}）
An implementation MUST NOT use an EXCLUDE interface record to represent a group when all sockets for this group are in INCLUDE state. If system resource limits are reached when an interface state source list is calculated, an error MUST be returned to the application which requested the operation.
このグループのすべてのソケットに含まれている場合、実装は除外インターフェイスレコードを使用しないでください。インターフェイス状態のソースリストが計算されるとシステムリソースの制限に達すると、操作を要求したアプリケーションにエラーが返されなければなりません。
The above rules for deriving the interface state are (re-)evaluated whenever an IPMulticastListen invocation modifies the socket state by adding, deleting, or modifying a per-socket state record. Note that a change of socket state does not necessarily result in a change of interface state.
インタフェース状態を導出するための上記の規則は、Socket™ごとの状態レコードを追加、削除、または変更することによって、IPMulticastListen呼び出しがソケット状態を変更するたびに評価されます。なお、ソケット状態の変更は必ずしもインタフェース状態の変更をもたらすわけではありません。
IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2. Every IGMP message described in this document is sent with an IP Time-to-Live of 1, IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option [RFC-2113] in its IP header. IGMP message types are registered by the IANA [IANA-REG] as described by [RFC-3228].
IGMPメッセージはIPv4データグラムにカプセル化されており、2のIPプロトコル番号はIPプロトコル番号で、このドキュメントに記載されているすべてのIGMPメッセージは1のIP時間からIPのIP優先順位（例：サービス0xC0の種類）で送信されます。IPヘッダーのIP Router Alertオプション[RFC-2113]を搭載しています。IGMPメッセージタイプは、[RFC-3228]で説明されているIANA [IANA-REG]によって登録されています。
There are two IGMP message types of concern to the IGMPv3 protocol described in this document:
このドキュメントに記載されているIGMPv3プロトコルには、IGMPメッセージタイプの関心事が2つあります。
Type Number (hex) Message Name
----------------- ------------
0x11 Membership Query
0x11メンバーシップクエリ
0x22 Version 3 Membership Report
0x22バージョン3メンバーシップレポート
An implementation of IGMPv3 MUST also support the following three message types, for interoperation with previous versions of IGMP (see section 7):
IGMPv3の実装は、以前のバージョンのIGMPとの相互運用のための、次の3つのメッセージタイプもサポートしなければなりません（セクション7を参照）。
0x12 Version 1 Membership Report [RFC-1112]
0x12バージョン1メンバーシップレポート[RFC-1112]
0x16 Version 2 Membership Report [RFC-2236]
0x16バージョン2メンバーシップレポート[RFC-2236]
0x17 Version 2 Leave Group [RFC-2236]
0x17バージョン2グループ[RFC-2236]
Unrecognized message types MUST be silently ignored. Other message types may be used by newer versions or extensions of IGMP, by multicast routing protocols, or for other uses.
認識されていないメッセージタイプは黙って無視される必要があります。他のメッセージタイプは、マルチキャストルーティングプロトコル、または他の用途のために、IGMPの新しいバージョンまたは拡張機能によって使用されます。
In this document, unless otherwise qualified, the capitalized words "Query" and "Report" refer to IGMP Membership Queries and IGMP Version 3 Membership Reports, respectively.
この文書では、特に適格でない限り、大文字の単語「照会」と「報告」は、それぞれIGMPメンバーシップクエリとIGMPバージョン3メンバーシップレポートを参照してください。
Membership Queries are sent by IP multicast routers to query the multicast reception state of neighboring interfaces. Queries have the following format:
メンバーシップクエリは、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 = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- . -+
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Max Resp Code field specifies the maximum time allowed before sending a responding report. The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows:
[Max Resp Code]フィールドは、応答レポートを送信する前に許可される最大時間を指定します。最大resp時間と呼ばれる実際の時間は、1/10秒単位で表され、次のようにMAX RESPコードから派生します。
If Max Resp Code < 128, Max Resp Time = Max Resp Code
Max Resp Code <128、最大Resp Time = Max Respコード
If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows:
MAX RESPコード> = 128の場合、最大RESPコードは次のように浮動小数点値を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
Max Resp Time = (mant | 0x10) << (exp + 3)
Small values of Max Resp Time allow IGMPv3 routers to tune the "leave latency" (the time between the moment the last host leaves a group and the moment the routing protocol is notified that there are no more members). Larger values, especially in the exponential range, allow tuning of the burstiness of IGMP traffic on a network.
Max Resptichの小さい値は、IGMPv3ルータが「待ち時間を残す」（最後のホストがグループを離れ、ルーティングプロトコルがこれ以上メンバーがないことを通知された瞬間の間の時間）を調整できます。特に指数範囲では、値が大きいほど、ネットワーク上のIGMPトラフィックのバーネスの調整が可能になります。
The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet. [RFC-1071]
チェックサムは、IGMPメッセージ全体（IPペイロード全体）の補数和を16ビットのものです。チェックサムを計算するために、チェックサムフィールドはゼロに設定されます。パケットを受信すると、パケットを処理する前にチェックサムを検証する必要があります。[RFC-1071]
The Group Address field is set to zero when sending a General Query, and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query (see section 4.1.9, below).
Group Addressフィールドは、一般的なクエリを送信するときにゼロに設定され、グループ固有のクエリまたはグループおよびソース固有のクエリを送信するときに照会されるIPマルチキャストアドレスに設定されます（下記のセクション4.1.9を参照）。
The Resv field is set to zero on transmission, and ignored on reception.
Resvフィールドは送信時にゼロに設定され、受信時に無視されます。
When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. It does not, however, 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 group member.
1に設定すると、Sフラグは、クエリを聞くときに実行された通常のタイマ更新を抑制するための受信マルチキャストルータに、受信マルチキャストルータを示します。ただし、グループメンバーである結果として、ルータが実行する必要があるクエリのQuerierElectionまたは通常の「ホスト側」処理を抑制することはできません。
If non-zero, the QRV field contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. If the querier's [Robustness Variable] exceeds 7, the maximum value of the QRV field, the QRV is set to zero. 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 the receivers use the default [Robustness Variable] value specified in section 8.1 or a statically configured value.
ゼロ以外の場合、QRVフィールドは、クエリア、すなわちクエリの送信者によって使用される[堅牢性変数]値を含む。QUERIERの[ロバストネス変数]が7を超える場合は、QRVフィールドの最大値、QRVはゼロに設定されます。ルータは、最近受信したQRVがゼロでない限り、最後に受信したクエリからQRV値を採用しています。この場合、受信機はセクション8.1または静的に設定されているデフォルトの[堅牢性変数]値を使用します。値。
The Querier's Query Interval Code field specifies the [Query Interval] used by the querier. The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows: If QQIC < 128, QQI = QQIC
クエリアの[クエリ間隔コード]フィールドは、クエリアによって使用される[クエリ間隔]を指定します。クエリアのクエリ間隔（QQI）と呼ばれる実際の間隔は秒単位で表され、次のようにQuerierのクエリ間隔コードから派生しています.QQIC <128、QQI = QQIC
If QQIC >= 128, QQIC represents a floating-point value as follows:
QQIC> = 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 8.2.
現在のクエリアではないマルチキャストルータは、最後に受信したQQIがゼロでない限り、最近受信したクエリからQQI値を自分の[クエリ間隔]値として採用します。その場合、受信ルータはデフォルトの[クエリ間隔]値を使用します。セクション8.2で指定してください。
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 Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. This number is limited by the MTU of the network over which the Query is transmitted. For example, on an Ethernet with an MTU of 1500 octets, the IP header including the Router Alert option consumes 24 octets, and the IGMP fields up to including the Number of Sources (N) field consume 12 octets, leaving 1464 octets for source addresses, which limits the number of source addresses to 366 (1464/4).
sources（n）フィールドの数は、クエリに存在する送信元アドレスの数を指定します。この数は、一般的なクエリまたはグループ固有のクエリではゼロ、グループとソース固有のクエリではゼロ以外です。この数は、クエリが送信されるネットワークのMTUによって制限されます。たとえば、1500オクテットのMTUを搭載したイーサネットでは、Router Alertオプションを含むIPヘッダーが24オクテットを消費し、Sources（N）フィールドの数が消費されているIGMPフィールド（N）は12オクテットを消費します。これにより、ソースアドレスの数が366（1464/4）に制限されます。
The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in the Number of Sources (N) field.
送信元アドレス[i]フィールドは、nのIPユニキャストアドレスのベクトルです。ここで、nはソース数（n）フィールドの値です。
If the Packet Length field in the IP header of a received Query indicates that there are additional octets of data present, beyond the fields described here, IGMPv3 implementations MUST include those octets in the computation to verify the received IGMP Checksum, but MUST otherwise ignore those additional octets. When sending a Query, an IGMPv3 implementation MUST NOT include additional octets beyond the fields described here.
受信したクエリのIPヘッダーの[パケット長]フィールドが、ここで説明されているフィールドを超えて、存在するデータのオクテットがあることを示している場合、IGMPv3実装は、受信したIGMPチェックサムを検証するために計算内のオクテットを含める必要がありますが、それ以外の場合は無視する必要があります。追加のオクテット。クエリを送信するとき、IGMPv3実装は、ここで説明されているフィールドを超えて追加のオクテットを含んではいけません。
There are three variants of the Query message:
クエリメッセージには3つの変形があります。
1. A "General Query" is sent by a multicast router to learn the complete multicast reception state of the neighboring interfaces (that is, the interfaces attached to the network on which the Query is transmitted). In a General Query, both the Group Address field and the Number of Sources (N) field are zero.
1. 「一般的なクエリ」は、隣接インタフェースの完全なマルチキャスト受信状態（つまり、クエリが送信されるネットワークに接続されているインタフェース）を学習するためにマルチキャストルータによって送信されます。一般的なクエリでは、グループアドレスフィールドとソース数（N）フィールドの両方がゼロです。
2. A "Group-Specific Query" is sent by a multicast router to learn the reception state, with respect to a *single* multicast address, of the neighboring interfaces. In a Group-Specific Query, the Group Address field contains the multicast address of interest, and the Number of Sources (N) field contains zero.
2. 「グループ固有のクエリ」は、隣接インタフェースの*単一*マルチキャストアドレスに関して、受信状態を学習するためにマルチキャストルータによって送信されます。グループ固有のクエリでは、グループアドレスフィールドには関心のあるマルチキャストアドレスが含まれており、ソース数（n）フィールドの数にはゼロが含まれています。
3. A "Group-and-Source-Specific Query" is sent by a multicast router to learn if any neighboring interface desires reception of packets sent to a specified multicast address, from any of a specified list of sources. In a Group-and-Source-Specific Query, the Group Address field contains the multicast address of interest, and the Source Address [i] fields contain the source address(es) of interest.
3. 「グループとソース固有のクエリ」は、指定されたマルチキャストアドレスに送信されたパケットの受信が、指定されたソースのリストのいずれかから、隣接するインターフェイスが望まれるかどうかを学習するためにマルチキャストルータによって送信されます。グループとソース固有のクエリでは、グループアドレスフィールドには関心のあるマルチキャストアドレスが含まれ、ソースアドレス[i]フィールドには関心のある送信元アドレスが含まれています。
In IGMPv3, General Queries are sent with an IP destination address of 224.0.0.1, the all-systems multicast address. Group-Specific and Group-and-Source-Specific Queries are sent with an IP destination address equal to the multicast address of interest. *However*, a system 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.
IGMPv3では、一般的なクエリはIP宛先アドレス224.0.0.1、オールシステムマルチキャストアドレスで送信されます。グループ固有のクエリとグループとソース固有のクエリは、IP宛先アドレスを使用して関心のあるマルチキャストアドレスと同じです。*ただし*、システムは、クエリが到着するインターフェイスに割り当てられているアドレス（ユニキャストまたはマルチキャスト）のアドレス（ユニキャストまたはマルチキャスト）を含むクエリを受け入れて処理する必要があります。
Version 3 Membership Reports are sent by IP systems to report (to neighboring routers) the current multicast reception state, or changes in the multicast reception state, of their interfaces. Reports have the following format:
バージョン3メンバーシップレポートは、現在のマルチキャスト受信状態、またはインターフェイスのマルチキャスト受信状態の変更を報告するために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 = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each Group 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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved fields are set to zero on transmission, and ignored on reception.
予約フィールドは送信時にゼロに設定され、受信時に無視されます。
The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a message.
チェックサムは、IGMPメッセージ全体（IPペイロード全体）の補数和を16ビットのものです。チェックサムを計算するために、チェックサムフィールドはゼロに設定されます。パケットを受信すると、メッセージを処理する前にチェックサムを検証する必要があります。
The Number of Group Records (M) field specifies how many Group Records are present in this Report.
Group Records（M）フィールド数このレポートに存在するグループレコードの数を指定します。
Each Group Record is a block of fields containing information pertaining to the sender's membership in a single multicast group on the interface from which the Report is sent.
各グループレコードは、レポートが送信されるインターフェイス上の単一のマルチキャストグループ内の送信者のメンバーシップに関する情報を含むフィールドのブロックです。
See section 4.2.12, below.
下記の4.2.12節を参照してください。
The Aux Data Len field contains the length of the Auxiliary Data field in this Group Record, in units of 32-bit words. It may contain zero, to indicate the absence of any auxiliary data.
AUXデータLENフィールドには、このグループレコードの補助データフィールドの長さが32ビットワード単位で含まれています。補助データがないことを示すために、ゼロを含めることができます。
The Number of Sources (N) field specifies how many source addresses are present in this Group Record.
Sources（N）フィールドの数は、このグループレコードに存在する送信元アドレスの数を指定します。
The Multicast Address field contains the IP multicast address to which this Group Record pertains.
マルチキャストアドレスフィールドには、このグループレコードが関連するIPマルチキャストアドレスが含まれています。
The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in this record's Number of Sources (N) field.
送信元アドレス[i]フィールドは、N IPユニキャストアドレスのベクトルです。ここで、nはこのレコードのソース数（n）フィールドの値です。
The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. The protocol specified in this document, IGMPv3, does not define any auxiliary data. Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, and MUST ignore any auxiliary data present in any received Group Record. The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field.
補助データフィールドが存在する場合は、このグループレコードに関する追加情報が含まれています。このドキュメントIGMPV3で指定されているプロトコルは、補助データを定義しません。したがって、IGMPv3の実装は、任意の送信グループレコード内の補助データ（すなわち、AUXデータLENフィールドをゼロに設定する必要があります）を含めてはならず、受信したグループレコードに存在する補助データを無視する必要があります。補助データフィールドのセマンティクスと内部エンコーディングは、このフィールドを使用するIGMPの将来のバージョンまたは拡張によって定義されます。
If the Packet Length field in the IP header of a received Report indicates that there are additional octets of data present, beyond the last Group Record, IGMPv3 implementations MUST include those octets in the computation to verify the received IGMP Checksum, but MUST otherwise ignore those additional octets. When sending a Report, an IGMPv3 implementation MUST NOT include additional octets beyond the last Group Record.
受信したレポートのIPヘッダーの[パケット長]フィールドが、最後のグループレコードを超えて、最後のグループレコードを超えて、受信したIGMPチェックサムを確認するために、IGMPv3実装はそれらのオクテットを含める必要がありますが、それ以外の場合はそれらを無視する必要があります。追加のオクテット。レポートを送信するとき、IGMPv3実装は最後のグループレコードを超えて追加のオクテットを含んではいけません。
There are a number of different types of Group Records that may be included in a Report message:
レポートメッセージに含まれている可能性がある多数の異なる種類のグループレコードがあります。
o A "Current-State Record" is sent by a system in response to a Query received on an interface. It reports the current reception 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つの値のいずれかになります。
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 Group Record contain the interface's source list for the specified multicast address, if it is non-empty.
1 MODE_IS_INCLUDE - 指定されたマルチキャストアドレスのインターフェイスがインクルードモードのフィルタモードを持つことを示します。このグループレコードの送信元アドレス[i]フィールドには、空いていない場合は、指定されたマルチキャストアドレスのインターフェイスのソースリストが含まれています。
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 Group Record contain the interface's source list for the specified multicast address, if it is non-empty.
2 MODE_IS_EXCLUDE - 指定されたマルチキャストアドレスの除外のフィルタモードがあることを示します。このグループレコードの送信元アドレス[i]フィールドには、空いていない場合は、指定されたマルチキャストアドレスのインターフェイスのソースリストが含まれています。
o A "Filter-Mode-Change Record" is sent by a system whenever a local invocation of IPMulticastListen 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. 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 IPMulticastListenのローカル呼び出しがフィルタモードの変更を引き起こすたびに、「フィルタモード変更レコード」はシステムによって送信されます（つまり、インターフェイスレベルの状態の変更、または除外から含める）。特定のマルチキャストアドレスのエントリ。レコードは、変更が発生したインターフェイスから送信されたレポートに含まれています。フィルタモード変更レコードのレコードタイプは、次の2つの値のいずれかになります。
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 Group Record contain the interface's new source list for the specified multicast address, if it is non-empty.
3 change_to_include_mode - 指定されたマルチキャストアドレスのフィルタモードを含めるようにインタフェースが変更されたことを示します。このグループレコードの送信元アドレス[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 Group Record contain the interface's new source list for the specified multicast address, if it is non-empty.
4 change_to_exclude_mode - 指定されたマルチキャストアドレスのフィルタモードを除外するようにインタフェースが変更されたことを示します。このグループレコードの送信元アドレス[i]フィールドには、空いていない場合は、指定されたマルチキャストアドレスのインターフェイスの新しいソースリストが含まれています。
o A "Source-List-Change Record" is sent by a system whenever a local invocation of IPMulticastListen 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 「ソースリスト変更レコード」は、IPMulticastListenのローカル呼び出しがフィルタモードの変更と一致しないソースリストの変更をシステムによって送信されます。住所。レコードは、変更が発生したインターフェイスから送信されたレポートに含まれています。ソースリスト変更レコードのレコードタイプは、次の2つの値のいずれかになります。
5 ALLOW_NEW_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the additional sources that the system wishes to hear from, 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]フィールドには、指定されたマルチキャストアドレスに送信されたパケットのためにシステムが聞きたい追加のソースのリストが含まれていることを示します。変更がインクルードソースリストにあった場合、これらはリストに追加されたアドレスです。変更が除外元リストに変更された場合は、リストから削除されたアドレスです。
6 BLOCK_OLD_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the sources that the system no longer wishes to hear from, 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]フィールドには、システムが指定したソースのリストが、指定されたマルチキャストアドレスに送信されたパケットのリストが含まれていることを示します。変更がインクルードソースリストにあった場合、これらはリストから削除されたアドレスです。変更が除外元リストに変更された場合、これらはリストに追加されたアドレスです。
If a change of source list results in both allowing new sources and blocking old sources, then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES.
ソースリストの変更が新しいソースと古いソースのブロックを許可すると、2つのグループレコードが同じマルチキャストアドレスで送信され、2つのグループレコードが同じマルチキャストアドレスで送信されます。
We use the term "State-Change Record" to refer to either a Filter-Mode-Change Record or a Source-List-Change Record.
フィルタモード変更レコードまたはソースリスト変更レコードを参照するには、「状態変更レコード」という用語を使用します。
Unrecognized Record Type values MUST be silently ignored.
認識されていないレコードタイプの値は黙って無視される必要があります。
An IGMP report is sent with a valid IP source address for the destination subnet. The 0.0.0.0 source address may be used by a system that has not yet acquired an IP address. Note that the 0.0.0.0 source address may simultaneously be used by multiple systems on a LAN. Routers MUST accept a report with a source address of 0.0.0.0.
IGMPレポートは、宛先サブネットの有効なIP送信元アドレスを使用して送信されます。0.0.0.0の送信元アドレスは、まだIPアドレスを取得していないシステムによって使用されてもよい。0.0.0.0の送信元アドレスは、LAN上の複数のシステムによって同時に使用されることがあります。ルータは、送信元アドレスを0.0.0.0のレポートを受け入れる必要があります。
Version 3 Reports are sent with an IP destination address of 224.0.0.22, to which all IGMPv3-capable multicast routers listen. A system that is operating in version 1 or version 2 compatibility modes sends version 1 or version 2 Reports to the multicast group specified in the Group Address field of the Report. In addition, a system MUST accept and process any version 1 or version 2 Report whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Report arrives.
バージョン3のレポートは、IGMPv3対応マルチキャストルータがすべて待機している224.0.0.22のIP宛先アドレスを使用して送信されます。バージョン1またはバージョン2の互換モードで動作しているシステムは、レポートのグループアドレスフィールドで指定されたマルチキャストグループにバージョン1またはバージョン2のレポートを送信します。さらに、システムは、レポートが到着するインターフェイスに割り当てられているアドレス（ユニキャストまたはマルチキャスト）のアドレス（ユニキャストまたはマルチキャスト）を含むバージョン1またはバージョン2レポートを受け入れて処理する必要があります。
In the rest of this document, we use the following notation to describe the contents of a Group Record pertaining 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
is_in（x） - タイプMODE_IS_INCLUDE、送信元アドレスX IS_EX（X） - タイプMODE_IS_EXCLUDE、ソースアドレスX TO_IN（X） - タイプCHANGE_TO_INCLUDE_MODE、ソースアドレスX TO_EX（X） - タイプCHANGE_TO_EXCLUDE_MODE、送信元アドレスX×TYPEallow_new_sources、送信元アドレスXブロック（x） - タイプblock_old_sources、送信元アドレスx
where x is either:
ここで、xは次のいずれかです。
o a capital letter (e.g., "A") to represent the set of source addresses, or
o ソースアドレスのセットを表す大文字（例えば、 "A"）、または
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 「ab」はセットAとBの連合を意味します。「A * B」とは、セットAとBの交差点を意味し、「AB」はセットのすべての要素の削除を意味します。bセットAから
If the set of Group Records required in a Report does not fit within the size limit of a single Report message (as determined by the MTU of the network on which it will be sent), the Group Records are sent in as many Report messages as needed to report the entire set.
レポートに必要なグループレコードのセットが単一のレポートメッセージのサイズ制限内に収まりない場合（送信されるネットワークのMTUによって決定されるように）、グループレコードは同じレポートメッセージで送信されます。セット全体を報告する必要がありました。
If a single Group Record contains so many source addresses that it does not fit within the size limit of a single Report message, if its Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is split into multiple Group Records, each containing a different subset of the source addresses and each sent in a separate Report message. If its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single Group Record is sent, containing as many source addresses as can fit, and the remaining source addresses are not reported; though 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.
単一のグループレコードに単一のレポートメッセージのサイズ制限に適合していない多くのソースアドレスが含まれている場合、そのタイプがMODE_IS_EXCLUDEまたはCHANGE_TO_EXCLUDE_MODEではない場合、それは複数のグループレコードに分割され、それぞれがソースの異なるサブセットを含む複数のグループレコードに分割されます。アドレスとそれぞれが別のレポートメッセージで送信されます。その型がmode_is_excludeまたはchange_to_exclude_modeの場合、単一のグループレコードが送信される可能性があるものと同じ数の送信元アドレスを含む、残りの送信元アドレスは報告されません。レポートするソースが任意であるかの選択は、毎回異なるソースを報告するのではなく、後続の各レポートに同じセットを報告することが望ましいです。
IGMP is an asymmetric protocol, specifying separate behaviors for group members -- that is, hosts or routers that wish to receive multicast packets -- and multicast routers. This section describes the part of IGMPv3 that applies to all group members. (Note that a multicast router that is also a group member performs both parts of IGMPv3, receiving and responding to its own IGMP message transmissions as well as those of its neighbors. The multicast router part of IGMPv3 is described in section 6.)
IGMPは非対称プロトコルで、グループメンバーの別の動作を指定しています。つまり、マルチキャストパケットとマルチキャストルータを受信したいホストまたはルーターです。このセクションでは、すべてのグループメンバーに適用されるIGMPv3の一部について説明します。（グループメンバーでもあるマルチキャストルータは、IGMPv3の両方の部分をそれ自身のIGMPメッセージ送信に受信して応答します.IGMPv3のマルチキャストルータ部分はセクション6で説明されています。
A system performs the protocol described in this section over all interfaces on which multicast reception is supported, even if more than one of those interfaces is connected to the same network.
システムは、これらのインタフェースの複数のインタフェースが同じネットワークに接続されている場合でも、マルチキャスト受信がサポートされているすべてのインターフェイスを介してこのセクションに記載されているプロトコルを実行します。
For interoperability with multicast routers running older versions of IGMP, systems maintain a MulticastRouterVersion variable for each interface on which multicast reception is supported. This section describes the behavior of group member systems on interfaces for which MulticastRouterVersion = 3. The algorithm for determining MulticastRouterVersion, and the behavior for versions other than 3, are described in section 7.
古いバージョンのIGMPを実行しているマルチキャストルータとの相互運用性の場合、システムはマルチキャスト受信がサポートされているインターフェイスごとにMultiCastRoutVersion変数を維持します。このセクションでは、MultiCastRoutErversion = 3のインターフェイス上のグループメンバシステムの動作について説明します。
The all-systems multicast address, 224.0.0.1, is handled as a special case. On all systems -- that is all hosts and routers, including multicast routers -- reception of packets destined to the all-systems multicast address, from all sources, is permanently enabled on all interfaces on which multicast reception is supported. No IGMP messages are ever sent regarding the all-systems multicast address.
All Systemsマルチキャストアドレス224.0.0.1は、特別な場合として処理されます。すべてのシステムでは、マルチキャストルータを含むすべてのホストとルーターです。All Systemsマルチキャストアドレスに関して、IGMPメッセージは送信されません。
There are two types of events that trigger IGMPv3 protocol actions on an interface:
IGMPv3プロトコルアクションをインターフェイス上にトリガーするイベントには2種類あります。
o a change of the interface reception state, caused by a local invocation of IPMulticastListen.
o IPMulticastListenのローカル呼び出しによって引き起こされるインタフェース受信状態の変更。
o reception of a Query.
o クエリの受信
(Received IGMP messages of types other than Query are silently ignored, except as required for interoperation with earlier versions of IGMP.) The following subsections describe the actions to be taken for each of these two cases. In those descriptions, timer and counter names appear in square brackets. The default values for those timers and counters are specified in section 8.
（以前のバージョンのIGMPとの相互運用に必要な場合を除き、クエリ以外のタイプのIGMPメッセージは黙って無視されます。）以下のサブセクションでは、これら2つのケースのそれぞれについて取得する行動について説明します。これらの説明では、タイマー名とカウンタ名が角かっこに表示されます。これらのタイマーとカウンタのデフォルト値はセクション8で指定されています。
An invocation of IPMulticastListen may cause the multicast reception state of an interface to change, according to the rules in section 3.2. Each such change affects the per-interface entry for a single multicast address.
IPMulticastListenの呼び出しは、セクション3.2の規則に従って、インターフェイスのマルチキャスト受信状態を変更する可能性があります。そのような変更ごとに、単一のマルチキャストアドレスのインターフェイスごとのエントリが影響します。
A change of interface state causes the system to immediately transmit a State-Change Report from that interface. The type and contents of the Group 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 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 a filter mode of INCLUDE and an empty source list.
インタフェース状態の変更により、システムはそのインタフェースから直ちに状態変更レポートを送信します。そのレポートのグループレコードの種類と内容は、以下の表に従って、影響を受けるマルチキャストアドレスのフィルタモードとソースリストを比較することによって決定されます。変更前のマルチキャストアドレスに対してインタフェース状態が存在しない場合（つまり、インターフェイスごとのレコードごとの新しい除去された変更が発生した場合）、または変更の後に状態がない場合（つまり、インターフェイスごとのレコードの削除が完成した変更）その場合、「存在しない」状態は、インクルードのフィルタモードと空のソースリストを持つと考えられます。
Old State New State State-Change Record Sent
--------- --------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)
（a）を含む（b）許容（b）、ブロック（a - b）を含む。
EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)
除外（a）除外（b）許可（a-b）、ブロック（B-A）
INCLUDE (A) EXCLUDE (B) TO_EX (B)
（a）exclude（b）to_ex（b）を含める
EXCLUDE (A) INCLUDE (B) TO_IN (B)
除外（a）は（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 message.
許可またはブロック状態変更レコードのいずれかの計算元リストが空の場合、そのレコードはレポートメッセージから省略されます。
To cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable] - 1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]).
状態変更報告書が1つ以上のマルチキャストルータによって見逃される可能性をカバーするために、範囲からランダムに選択された間隔で、rbasustness変数 - 1回（0、[非請求レポート間隔]））で再送される。
If more changes to the same 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 transmitted report are calculated as follows. As was done with the first report, the interface state for the affected group before and after the latest change is compared. The report records expressing the difference are built according to the table above. However these records are not transmitted in a message but instead merged with the contents of the pending report, to create the new State-Change report. The rules for merging the difference report resulting from the state change and the pending report are described below.
新しい送信レポートの内容は次のように計算されます。最初のレポートで行われたように、最新の変更前後の影響を受けたグループのインターフェイス状態が比較されます。違いを表すレポートレコードは、上の表に従って構築されています。ただし、これらのレコードはメッセージで送信されず、代わりに保留中のレポートの内容とマージされ、新しい状態変更レポートを作成します。状態変化と保留レポートとの差分レポートをマージするための規則を以下に説明します。
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 State-Change Reports.
マージされた状態変化レポートの送信は、同じマルチキャストアドレスについて以前の状態変更レポートの再送信を終了し、常時変更レポートの[ロバストネス変数]の送信の最初のものとなります。
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 host. This is done in order to ensure that a series of successive state changes do not break the protocol robustness.
上記の差分レポートにソースが含まれるたびに、その送信元の再送信状態は、[堅牢性変数]の状態変更レポートがホストによって送信されるまで維持される必要があります。これは、一連の連続した状態の変化がプロトコルの堅牢性を損なわないようにするために行われます。
If the interface reception-state 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 host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. When [Robustness Variable] State-Change reports with Filter-Mode-Change records have been transmitted after the last filter-mode change, and if source-list changes to the interface reception have scheduled additional reports, then the next State-Change report will include Source-List-Change records.
新しいレポートをトリガーするインタフェース受信状態の変更がフィルタモードの変更である場合、次の[堅牢性変数]状態変更レポートにはフィルタモード変更レコードが含まれます。その期間にいくつものソースリストの変更が発生しても当てはまります。ホストは、[ロバストネス変数]状態変更レポートが送信されるまで、グループの再送信状態を維持する必要があります。[ロバストネス変数]フィルタモード変更レコードを使用した状態変更レポートが最後のフィルタモードの変更後に送信され、インターフェイス受信へのsource-listが追加のレポートを変更した場合は、次の状態変更レポートがあります。ソースリスト変更レコードを含めます。
Each time a State-Change Report is transmitted, the contents are determined as follows. If the report should contain a Filter-Mode-Change record, 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, an ALLOW and a BLOCK record are included. The contents of these records are built according to the table below.
状態変更レポートが送信されるたびに、内容は次のように決定されます。レポートにフィルタモード変更レコードが含まれている場合は、インターフェイスの現在のフィルタモードに含まれている場合は、TO_INレコードがレポートに含まれています。そうしないと、TO_EXレコードが含まれています。代わりにレポートにソースリスト変更レコードを含める必要がある場合は、許可とブロックレコードが含まれます。これらのレコードの内容は以下の表に従って構築されています。
Record Sources included
------ ----------------
TO_IN All in the current interface state that must be forwarded
TO_EX All in the current interface state that must be blocked
ALLOW All with retransmission state 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.
許可またはブロックレコードのいずれかの計算元リストが空の場合、そのレコードは状態変更レポートから省略されます。
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).
注意：最初の状態変更レポートが送信されると、存在しない保留中のレポートがマージされ、空の許可およびブロックレコードを使用したソース変更レポートとして扱うことができます（ソースは再送信状態はありません）。
When a system receives a Query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message. A system may receive a variety of Queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response.
システムがクエリを受信するとすぐには応答しません。代わりに、受信したクエリメッセージのMAX RESPコードから導出された最大Resp Time値によって制限された、ランダムな時間による応答を遅らせます。システムは、異なるインターフェースおよび異なる種類のさまざまなクエリ（例えば、一般的なクエリ、グループ固有のクエリ、およびグループおよびソース固有のクエリ）を受信することができ、それぞれが独自の遅延応答を必要とする可能性があります。
Before scheduling a response to a Query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the system must be able to maintain the following state:
クエリに対する応答をスケジュールする前に、システムは最初に以前にスケジュールされた保留中の応答を検討しなければならず、多くの場合、合計応答をスケジュールします。したがって、システムは次の状態を維持できなければなりません。
o A timer per interface for scheduling responses to General Queries.
o 一般的なクエリに対する応答をスケジュールするためのインターフェイスごとのタイマー。
o A per-group and interface timer for scheduling responses to Group-Specific and Group-and-Source-Specific Queries.
o グループ固有のクエリとグループとソース固有のクエリへの応答をスケジューリングするためのグループごとのインタフェースタイマー。
o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query.
o グループとソース固有のクエリに対する応答に報告されるソースのグループおよびインタフェースリスト。
When a new Query with the Router-Alert option arrives on an interface, provided the system has state to report, a delay for a response is randomly selected in the range (0, [Max Resp Time]) where Max Resp Time is derived from Max Resp Code in the received Query message. The following rules are then used to determine if a Report needs to be scheduled and the type of Report to schedule. The rules are considered in order and only the first matching rule is applied.
システムが報告する状態にある状態にある場合は、Router-Alertオプションを使用した新しいクエリがインターフェイスに到着した場合、最大Resplimeが派生した範囲（0、[Max Resptime]）で応答の遅延がランダムに選択されます。受信したクエリメッセージで最大RESPコード。次の規則を使用して、レポートをスケジュールする必要があるかどうかを判断し、スケジュールするレポートの種類を判断します。規則は順番に検討され、最初の一致規則のみが適用されます。
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 Group-Specific Query or a Group-and-Source-Specific Query and there is no pending response to a previous Query for this group, then the group timer is used to schedule a report. If the received Query is a Group-and-Source-Specific Query, the list of queried sources is recorded to be used when generating a response.
3. 受信したクエリがグループ固有のクエリまたはグループとソース固有のクエリであり、このグループの前のクエリに対する保留中の応答がない場合、グループタイマーはレポートをスケジュールするために使用されます。受信したクエリがグループとソース固有のクエリである場合、照会されたソースのリストは応答を生成するときに使用されるように記録されます。
4. If there already is a pending response to a previous Query scheduled for this group, and either the new Query is a Group-Specific Query or the recorded source-list associated with the group is empty, then the group source-list is cleared and a single response is scheduled using the group 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 Group-and-Source-Specific Query and there is a pending response for this group with a non-empty source-list, then the group source list is augmented to contain the list of sources in the new Query and a single response is scheduled using the group 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. 受信したクエリがグループとソース固有のクエリであり、空でないソースリストを使用してこのグループに対して保留中の応答がある場合、グループソースリストは新しいクエリ内のソースのリストを含むように拡張されます。単一の応答は、グループタイマーを使用してスケジュールされます。新しい応答は、保留中のレポートと選択された遅延のための残りの時間の最も早い時期に送信される予定です。
When the timer in a pending response record expires, the system transmits, on the associated interface, one or more Report messages carrying one or more Current-State Records (see section 4.2.12), as follows:
保留中の応答レコードのタイマーが期限切れになると、システムは、次のように、1つまたは複数の電流状態レコードを搭載した1つまたは複数のレポートメッセージ（4.2.12項を参照）を送信する（セクション4.2.12を参照）。
1. If the expired timer is the interface timer (i.e., it 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 reception state, as described in section 3.2. The Current-State Record carries the multicast address and its 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.
1. 期限切れタイマがインターフェースタイマである場合（すなわち、一般的なクエリに対する保留応答である）、セクション3.2で説明されているように、指定されたインターフェースが受信状態を有するマルチキャストアドレスごとに1つの電流状態レコードが送信される。現在の状態レコードは、マルチキャストアドレスとそれに関連するフィルタモード（MODE_IS_INCLUDEまたはMODE_IS_EXCLUDE）とソースリストを搬送します。可能な限り、複数の電流状態レコードが個々のレポートメッセージにパックされます。
This naive algorithm may result in bursts of packets when a system is a member of a large number of groups. Instead of using a single interface timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Max Resp Time]). Note that any such implementation MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a Report immediately on reception of a General Query.
このナイーブアルゴリズムは、システムが多数のグループのメンバーであるときにパケットのバーストをもたらす可能性があります。単一のインタフェースタイマーを使用する代わりに、インターバル（0、[最大RESP TIME]）にわたるそのようなレポートメッセージの送信を拡散するために実装を推奨します。そのような実装は、一般的なクエリの受信にすぐにレポートを送信してはいけません。
2. If the expired timer is a group timer and the list of recorded sources for the that group is empty (i.e., it is a pending response to a Group-Specific Query), then if and only if the interface has reception state for that group 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.
2. 期限切れのタイマーがグループタイマーであり、そのグループの記録されたソースのリストが空の場合（つまり、グループ固有のクエリに対する保留中の応答）、次にそのグループアドレスの受信状態がある場合に限り、そのアドレスのために単一の電流状態レコードが送信されます。現在の状態レコードは、マルチキャストアドレスとそれに関連するフィルタモード（MODE_IS_INCLUDEまたはMODE_IS_EXCLUDE）とソースリストを搬送します。
3. If the expired timer is a group timer and the list of recorded sources for that group is non-empty (i.e., it is a pending response to a Group-and-Source-Specific Query), then if and only if the interface has reception state for that group address, the contents of the responding Current-State Record is determined from the interface state and the pending response record, as specified in the following table:
3. 期限切れタイマーがグループタイマーであり、そのグループの記録されたソースのリストが空でない場合（つまり、グループおよびソース固有のクエリに対する保留中の応答）、次にインターフェイスが受信した場合に限り、そのグループアドレスの状態、応答している電流状態レコードの内容は、次の表で指定されているように、インターフェイス状態と保留中の応答レコードから決定されます。
set of sources in the
interface state pending response record Current-State Record
--------------- ----------------------- --------------------
INCLUDE (A) B IS_IN (A*B)
（a）b is_in（a * b）を含める
EXCLUDE (A) B IS_IN (B-A)
除外（a）b is_in（B-A）
If the resulting Current-State Record has an empty set of source addresses, then no response is sent.
結果の電流状態レコードに空のソースアドレスのセットがある場合は、応答は送信されません。
Finally, after any required Report messages have been generated, the source lists associated with any reported groups are cleared.
最後に、必要なレポートメッセージが生成された後、報告されたグループに関連付けられているソースリストがクリアされます。
The purpose of IGMP is to enable each multicast router to learn, for each of its directly attached networks, which multicast addresses are of interest to the systems attached to those networks. IGMP version 3 adds the capability for a multicast router to also learn which *sources* are of interest to neighboring systems, for packets sent to any particular multicast address. The information gathered by IGMP is provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all networks where there are interested receivers.
IGMPの目的は、各マルチキャストルータがその直接接続されたネットワークごとに、それらのネットワークに接続されているシステムにとって関心があることを可能にするために、各マルチキャストルータを有効にすることです。IGMPバージョン3は、特定のマルチキャストアドレスに送信されたパケットについて、マルチキャストルータの機能を追加します。IGMPによって収集された情報は、マルチキャストパケットが興味のある受信機があるすべてのネットワークに配信されるようにするために、ルータによってどのマルチキャストルーティングプロトコルが使用されているかに提供される。
This section describes the part of IGMPv3 that is performed by multicast routers. Multicast routers may also themselves become members of multicast groups, and therefore also perform the group member part of IGMPv3, described in section 5.
このセクションでは、マルチキャストルータによって実行されるIGMPv3の一部について説明します。マルチキャストルータもマルチキャストグループのメンバーになり、したがってセクション5で説明されているIGMPv3のグループメンバー部分も実行することができる。
A multicast router performs the protocol described in this section over each of its directly-attached networks. If a multicast router has more than one interface to the same network, it only needs to operate this protocol over one of those interfaces. On each interface over which this protocol is being run, the router MUST enable reception of multicast address 224.0.0.22, from all sources (and MUST perform the group member part of IGMPv3 for that address on that interface).
マルチキャストルータは、その直接接続されているネットワークの各々にこのセクションに記載されているプロトコルを実行します。マルチキャストルータに同じネットワークへのインタフェースが複数ある場合は、それらのインターフェイスの1つを介してこのプロトコルを操作するだけで済みます。このプロトコルが実行されている各インターフェイスで、ルータはすべてのソースからマルチキャストアドレス224.0.0.22の受信を有効にしなければなりません（そしてそのインターフェイス上のそのアドレスのIGMPv3のグループメンバー部分を実行する必要があります）。
Multicast routers need to know only that *at least one* system on an attached network is interested in packets to a particular multicast address from a particular source; a multicast router is not required to keep track of the interests of each individual neighboring system. (However, see Appendix A.2 point 1 for discussion.)
マルチキャストルータは、添付のネットワーク上の少なくとも1つのシステムのみを知る必要があります。特定のソースから特定のマルチキャストアドレスへのパケットに興味があります。マルチキャストルータは、各隣接システムの利益を追跡するために必要とされない。（ただし、説明のために付録A.2ポイント1を参照してください。）
IGMPv3 is backward compatible with previous versions of the IGMP protocol. In order to remain backward compatible with older IGMP systems, IGMPv3 multicast routers MUST also implement versions 1 and 2 of the protocol (see section 7).
IGMPv3は、以前のバージョンのIGMPプロトコルと下位互換性があります。古いIGMPシステムとの後方互換性のあるままにするために、IGMPv3マルチキャストルータはプロトコルのバージョン1と2を実装する必要があります（セクション7を参照）。
Multicast routers send General Queries periodically to request group membership information from an attached network. These queries are used to build and refresh the group membership state of systems on attached networks. Systems respond to these queries by reporting their group membership state (and their desired set of sources) with Current-State Group Records in IGMPv3 Membership Reports.
マルチキャストルータは、添付のネットワークからグループメンバーシップ情報を要求するために定期的に一般的なクエリを送信します。これらのクエリは、接続ネットワーク上のシステムのグループメンバーシップ状態を構築して更新するために使用されます。システムは、IGMPv3メンバーシップレポートの現在の状態グループレコードを使用して、グループメンバーシップの状態（およびその希望のソースのセット）を報告することによってこれらのクエリに応答します。
As a member of a multicast group, a system may express interest in receiving or not receiving traffic from particular sources. As the desired reception state of a system changes, it reports these changes using Filter-Mode-Change Records or Source-List-Change Records. These records indicate an explicit state change in a group at a system in either the group record's source list or its filter-mode. When a group membership is terminated at a system or traffic from a particular source is no longer desired, a multicast router must query for other members of the group or listeners of the source before deleting the group (or source) and pruning its traffic.
マルチキャストグループのメンバーとして、システムは特定のソースからのトラフィックを受信または受信していないことに関心を表明することがあります。システムの望ましい受信状態が変化すると、フィルタモード変更レコードまたはソースリスト変更レコードを使用してこれらの変更を報告します。これらのレコードは、グループレコードのソースリストまたはそのフィルタモードのシステムのグループ内の明示的な状態変化を示します。グループメンバーシップがシステムメンバーシップが特定のソースから終了したり、特定のソースからのトラフィックを終了したりすると、グループ（またはソース）を削除してトラフィックを枝縮らす前に、マルチキャストルータがソースのグループまたはリスナーの他のメンバーを問い合わせる必要があります。
To enable all systems on a network to respond to changes in group membership, multicast routers send specific queries. A Group-Specific Query is sent to verify there are no systems that desire reception of the specified group or to "rebuild" the desired reception state for a particular group. Group-Specific Queries are sent when a router receives a State-Change record indicating a system is leaving a group.
ネットワーク上のすべてのシステムをグループメンバーシップの変更に応答できるようにするには、マルチキャストルータは特定のクエリを送信します。グループ固有のクエリが送信され、特定のグループの受信を希望するシステムがない、または特定のグループの受信状態を「再構築」するシステムがないことを確認します。ルータがシステムを残していることを示す状態変更レコードを受信したときにグループ固有のクエリが送信されます。
A Group-and-Source Specific Query is used to verify there are no systems on a network which desire to receive traffic from a set of sources. Group-and-Source Specific Queries list sources for a particular group which have been requested to no longer be forwarded. This query is sent by a multicast router to learn if any systems desire reception of packets to the specified group address from the specified source addresses. Group-and-Source Specific Queries are only sent in response to State-Change Records and never in response to Current-State Records. Section 4.1.11 describes each query in more detail.
グループとソース固有のクエリを使用して、一連のソースからトラフィックを受信したいネットワーク上にシステムがないことを確認します。転送されなくなったように要求された特定のグループのグループとソース固有のクエリリストソース。このクエリは、指定された送信元アドレスから指定されたグループアドレスへのパケットの受信を望むかどうかを学習するためにマルチキャストルータによって送信されます。グループとソース固有のクエリは、状態変更レコードに応答して送信され、現在の状態レコードに応答してはなりません。セクション4.1.11に各クエリについて詳しく説明します。
Multicast routers implementing IGMPv3 keep state per group per attached network. This group state consists of a filter-mode, a list of sources, and various timers. For each attached network running IGMP, a multicast router records the desired reception state for that network. That state conceptually consists of a set of records of the form:
IGMPv3を実装するマルチキャストルータは、添付されたネットワークごとにグループごとに状態を保存します。このグループの状態は、フィルタモード、ソースのリスト、およびさまざまなタイマーで構成されています。IGMPを実行している各接続ネットワークについて、マルチキャストルータはそのネットワークに対して望ましい受信状態を記録します。その状態は概念的にフォームの一連のレコードで構成されています。
(multicast address, group timer, filter-mode, (source records))
（マルチキャストアドレス、グループタイマー、フィルタモード、（ソースレコード））
Each source record is of the form:
各ソースレコードは次の形式です。
(source address, source timer)
（送信元アドレス、ソースタイマー）
If all sources within a given group are desired, an empty source record list is kept with filter-mode set to EXCLUDE. This means hosts on this network want all sources for this group to be forwarded. This is the IGMPv3 equivalent to a IGMPv1 or IGMPv2 group join.
特定のグループ内のすべてのソースが望まれる場合は、空のソースレコードリストが除外されるフィルタモードセットに保存されます。つまりこのネットワーク上のホストは、このグループのすべてのソースを転送することを意味します。これは、IGMPv1またはIGMPv2グループ結合と同等のIGMPv3です。
To reduce internal state, IGMPv3 routers keep a filter-mode per group per attached network. This filter-mode is used to condense the total desired reception state of a group to a minimum set such that all systems' memberships are satisfied. This filter-mode may change in response to the reception of particular types of group 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 group within a router. Section 6.4 describes the changes of a router filter-mode per group record received.
内部状態を減らすために、IGMPv3ルータは添付のネットワークごとにグループごとにフィルタモードを保持します。このフィルタモードは、すべてのシステムのメンバーシップが満たされるように、グループの総希望の受信状態を最小セットに集めるために使用されます。このフィルタモードは、特定の種類のグループレコードの受信または特定のタイマー状態が発生したときに変わる可能性があります。次のセクションでは、ルータ内の特定のグループのフィルタモードを参照するために「ルータフィルタモード」という用語を使用します。セクション6.4に、受信したグループレコードあたりのルータフィルタモードの変更を示します。
Conceptually, when a group record is received, the router filter-mode for that group is updated to cover all the requested sources using the least amount of state. As a rule, once a group record with a filter-mode of EXCLUDE is received, the router filter-mode for that group will be EXCLUDE.
概念的には、グループレコードを受信すると、そのグループのルータフィルタモードが更新され、最小限の状態を使用してすべての要求されたソースがカバーされます。ルールとして、フィルタモードの除外のグループレコードが受信されると、そのグループのルータフィルタモードは除外されます。
When a router filter-mode for a group is EXCLUDE, the source record list contains two types of sources. The first type is the set which represents conflicts in the desired reception state; this set must be forwarded by some router on the network. The second type is the set of sources which hosts have requested to not be forwarded. Appendix A describes the reasons for keeping this second set when in EXCLUDE mode.
グループのルータフィルタモードが除外されると、ソースレコードリストには2種類のソースが含まれています。最初のタイプは、目的の受信状態の競合を表すセットです。このセットはネットワーク上のいくつかのルータによって転送されなければなりません。2番目の型は、ホストが転送されないように要求されたソースのセットです。付録Aでは、この2番目のセットを除外モードに保つ理由について説明します。
When a router filter-mode for a group is INCLUDE, the source record list is the list of sources desired for the group. This is the total desired set of sources for that group. Each source in the source record list must be forwarded by some router on the network.
グループのルータフィルタモードに含まれる場合、ソースレコードリストはグループに必要なソースのリストです。これはそのグループのための合計希望の原因です。ソースレコードリスト内の各ソースは、ネットワーク上のいくつかのルータによって転送されなければなりません。
Because a reported group record with a filter-mode of EXCLUDE will cause a router to transition its filter-mode for that group to EXCLUDE, a mechanism for transitioning a router's filter-mode back to INCLUDE must exist. If all systems with a group record in EXCLUDE filter-mode cease reporting, it is desirable for the router filter-mode for that group to transition back to INCLUDE mode. This transition occurs when the group timer expires and is explained in detail in section 6.5.
除外のフィルタモードで報告されたグループレコードは、ルータがそのグループのフィルタモードを除外するようになるため、ルータのフィルタモードを遷移させるためのメカニズムが存在している必要があります。グループレコードを含むすべてのシステムがフィルタモードの除外の報告を除外すると、そのグループのルータフィルタモードが遷移してモードを遷移させることが望ましいです。この遷移は、グループタイマーが期限切れになったときに発生し、6.5項で詳細に説明されています。
The group timer is only used when a group is in EXCLUDE mode and it represents the time for the *filter-mode* of the group to expire and switch to INCLUDE mode. We define a group timer as a decrementing timer with a lower bound of zero kept per group per attached network. Group timers are updated according to the types of group records received.
グループタイマは、グループが除外モードになっている場合にのみ使用され、グループの*フィルタモード*の*フィルタモード*が期限切れになり、インクルードモードに切り替えます。添付のネットワークごとにグループごとに保存されているゼロの下限を持つデクリメントタイマーとしてグループタイマーを定義します。グループタイマーは、受信したグループレコードの種類に応じて更新されます。
A group timer expiring when a router filter-mode for the group is EXCLUDE means there are no listeners on the attached network in EXCLUDE mode. At this point, a router will transition to INCLUDE filter-mode. Section 6.5 describes the actions taken when a group timer expires while in EXCLUDE mode.
グループのルータフィルタモードが除外されると、除外モードでは添付のネットワーク上にリスナーがない場合のグループタイマが期限切れになります。この時点で、ルータはフィルタモードを含むように遷移します。セクション6.5は、グループタイマーが除外モードで有効期限が切れたときに取られたアクションを説明しています。
The following table summarizes the role of the group timer. Section 6.4 describes the details of setting the group timer per type of group record received.
次の表は、グループタイマーの役割をまとめたものです。6.4節では、受信したグループレコードの種類ごとのグループタイマーの設定の詳細について説明します。
Group
Filter-Mode Group Timer Value Actions/Comments
----------- ----------------- ----------------
INCLUDE Timer >= 0 All members in INCLUDE mode.
INCLUDEモードのすべてのメンバー> = 0すべてのメンバーを含めます。
EXCLUDE Timer > 0 At least one member in EXCLUDE mode.
除外モードで少なくとも1つのメンバーを除外します。
EXCLUDE Timer == 0 No more listeners to group. If all source timers have expired then delete Group Record. If there are still source record timers running, switch to INCLUDE filter-mode using those source records with running timers as the INCLUDE source record state.
Timer == 0を除外するグループへのリスナーはもうありません。すべてのソースタイマーが期限切れになった場合は、グループレコードを削除します。まだソースレコードタイマが実行されている場合は、インクルードソースレコードの状態としてタイマーを実行してこれらのソースレコードを使用してフィルタモードを含めるように切り替えます。
A source timer is kept per source record and is a decrementing timer with a lower bound of zero. Source timers are updated according to the type and filter-mode of the group record received. Source timers are always updated (for a particular group) whenever the source is present in a received record for that group. Section 6.4 describes the setting of source timers per type of group records received.
ソースタイマはソースレコードごとに保持され、ゼロの下限を持つデクリメントタイマです。ソースタイマは、受信したグループレコードの種類とフィルタモードに従って更新されます。ソースが受信したレコードにそのグループの受信レコードに存在するたびに、ソースタイマーは常に（特定のグループの場合）更新されます。セクション6.4に、受信したグループレコードの種類ごとのソースタイマの設定を示します。
A source record with a running timer with a router filter-mode for the group of INCLUDE means that there is currently one or more systems (in INCLUDE filter-mode) which desire to receive that source. If a source timer expires with a router filter-mode for the group of INCLUDE, the router concludes that traffic from this particular source is no longer desired on the attached network, and deletes the associated source record.
includeのグループのルータフィルタモードを持つ実行タイマーを持つソースレコードは、そのソースを受け取りたいシステム（INCLUDEフィルタモード）が現在1つ以上あることを意味します。ソースタイマーがインクルードのグループに対してルータフィルタモードで有効期限が切れると、ルータは添付のネットワーク上でこの特定のソースからのトラフィックが望まれなくなり、関連するソースレコードを削除します。
Source timers are treated differently when a router filter-mode for a group is EXCLUDE. If a source record has a running timer with a router filter-mode for the group of EXCLUDE, it means that at least one system desires the source. It should therefore be forwarded by a router on the network. Appendix A describes the reasons for keeping state for sources that have been requested to be forwarded while in EXCLUDE state.
グループのルータフィルタモードが除外されると、ソースタイマは異なる方法で扱われます。ソースレコードが除外のグループに対してルータフィルタモードを持つ実行タイマーを持つ場合、それは少なくとも1つのシステムがソースを望むことを意味します。したがって、ネットワーク上のルータによって転送されるべきです。付録Aは、除外状態で転送されるように要求されたソースの状態を保持する理由を説明しています。
If a source timer expires with a router filter-mode for the group of EXCLUDE, the router informs the routing protocol that there is no longer a receiver on the network interested in traffic from this source.
ソースタイマーが除外のグループのルータフィルタモードで有効期限が切れると、ルータはルーティングプロトコルに、このソースからのトラフィックに関心のあるネットワーク上の受信側がなくなることを通知します。
When a router filter-mode for a group is EXCLUDE, source records are only deleted when the group timer expires. Section 6.3 describes the actions that should be taken dependent upon the value of a source timer.
グループのルータフィルタモードが除外されると、グループタイマーが期限切れになると、ソースレコードは削除されます。セクション6.3は、ソースタイマの値に依存するべきアクションを説明しています。
When a multicast router receives a datagram from a source destined to a particular group, a decision has to be made whether to forward the datagram onto an attached network or not. The multicast routing protocol in use is in charge of this decision, and should use the IGMPv3 information to ensure that all sources/groups desired on a subnetwork are forwarded to that subnetwork. IGMPv3 information does not override multicast routing information; for example, if the IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward packets for excluded sources to a transit subnet.
マルチキャストルータが特定のグループ宛のソースからデータグラムを受信すると、データグラムを接続ネットワークに転送するかどうかを決定する必要があります。使用中のマルチキャストルーティングプロトコルはこの決定を担当しており、IGMPv3情報を使用して、サブネットワーク上で必要なすべてのソース/グループがそのサブネットワークに転送されるようにします。IGMPv3情報はマルチキャストルーティング情報をオーバーライドしません。たとえば、GのIGMPv3フィルタモードグループが除外されている場合、ルータは除外されたソースのパケットをトランジットサブネットに転送することがあります。
To summarize, the following table describes the forwarding suggestions made by IGMP to the routing protocol for traffic originating from a source destined to a group. It also summarizes the actions taken upon the expiration of a source timer based on the router filter-mode of the group.
要約すると、次の表は、グループに宛てられたソースから発生するトラフィックのルーティングプロトコルにIGMPによって行われた転送提案を示しています。グループのルータフィルタモードに基づいて、ソースタイマの有効期限切れにかかるアクションもまとめています。
Group
Filter-Mode Source Timer Value Action
----------- ------------------ ------
INCLUDE TIMER > 0 Suggest to forward traffic from source
Timerを含める> 0からのトラフィックを転送することをお勧めします。
INCLUDE TIMER == 0 Suggest to stop forwarding traffic from source and remove source record. If there are no more source records for the group, delete group record.
INCLUDE TIMER == 0ソースからトラフィックを転送したり、ソースレコードを削除したりすることをお勧めします。グループのソースレコードがこれ以上ない場合は、グループレコードを削除します。
INCLUDE No Source Elements Suggest to not forward source
ソース要素を入力しないソースを転送しないことをお勧めします
EXCLUDE TIMER > 0 Suggest to forward traffic from source
除外タイマー> 0からのトラフィックを転送することをお勧めします
EXCLUDE TIMER == 0 Suggest to not forward traffic from source (DO NOT remove record)
除外Timer == 0トラフィックをソースから転送しないように提案する（レコードを削除しないでください）
EXCLUDE No Source Elements Suggest to forward traffic from source
ソース要素を除外するソースからトラフィックを転送することを提案する
When receiving Current-State Records, a router updates both its group and source timers. In some circumstances, the reception of a type of group record will cause the router filter-mode for that group 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.
現在の状態レコードを受信すると、ルータはそのグループと送信元の両方のタイマを更新します。状況によっては、グループレコードの種類の受信によって、そのグループのルータフィルタモードが変更されます。以下の表は、電流状態レコードを受信したときにルータの状態に発生する状態とタイマに関するアクションについて説明しています。
The following notation is used to describe the updating of source timers. The notation ( A, B ) will be used to represent the total number of sources for a particular group, where
ソースタイマーの更新を説明するために、以下の表記法が使用されます。表記（A、B）は、特定のグループのソースの総数を表すために使用されます。
A = set of source records whose source timers > 0 (Sources that at least one host has requested to be forwarded) B = set of source records whose source timers = 0 (Sources that IGMP will suggest to the routing protocol not to forward)
A =ソースタイマ> 0（少なくとも1つのホストが転送される要求されたソース）B =ソースタイマ= 0のソースレコードのセット（IGMPが転送しないルーティングプロトコルに推奨するソース）
Note that there will only be two sets when a router's filter-mode for a group is EXCLUDE. When a router's filter-mode for a group is INCLUDE, a single set is used to describe the set of sources requested to be forwarded (e.g., simply (A)).
グループのルータのフィルタモードが除外されると、2つのセットがあります。グループのルータのフィルタモードが含まれる場合、単一のセットが転送されるように要求される要求されたソースのセットを記述するために使用される（例えば、単に（a））。
In the following tables, abbreviations are used for several variables (all of which are described in detail in section 8). The variable GMI is an abbreviation for the Group Membership Interval, which is the time in which group memberships will time out. The variable LMQT is an abbreviation for the Last Member Query Time, which is the total time spent after Last Member Query Count retransmissions. LMQT represents the "leave latency", or the difference between the transmission of a membership change and the change in the information given to the routing protocol.
以下の表では、いくつかの変数に略語が使用されます（すべて、セクション8で詳細に説明されています）。変数GMIは、グループメンバーシップ間隔の略語です。これは、グループメンバーシップがタイムアウトする時刻です。変数LMQTは、最後のメンバークエリ時刻の省略形です。これは、最後のメンバークエリ数の再送信の後に費やされた合計時間です。LMQTは、「待ち時間のまま」、または会員変更の送信とルーティングプロトコルに与えられた情報の変化の差を表します。
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. 'Group Timer=J' means that the Group Timer for the group should be set to value J.
ルータ状態表の「アクション」セクションでは、表記「A = J」を使用します。つまり、ソースレコードのセットAにソースタイマが値Jに設定されている必要があることを意味します。 'delete a'を設定することを意味します。ソースレコードの削除は削除されます。'Group Timer = J'は、グループのグループタイマーを値Jに設定する必要があることを意味します。
Router State Report Rec'd New Router State Actions
------------ ------------ ---------------- -------
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI
（a）is_in（b）を含む（a b）（b）= gmi
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 Delete (A-B) Group Timer=GMI
IS_EX（B）除外（a * b、b-a）（b-a）= 0グループタイマ= gmi
EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI
除外（x、y）is_in（a）除外（x a、y-a）（a）= gmi
EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=GMI Delete (X-A) Delete (Y-A) Group Timer=GMI
除外（x、y）IS_EX（a）除外（a-y、y * a）（a-x-y）= GMI削除（x-a）delete（y-a）グループTIMER = GMI
When a change in the global state of a group occurs in a system, the system sends either a Source-List-Change Record or a Filter-Mode-Change Record for that group. As with Current-State Records, routers must act upon these records and possibly change their own state to reflect the new desired membership state of the network.
システム内でグループのグローバル状態の変更が発生すると、システムはそのグループのソースリスト変更レコードまたはフィルタモード変更レコードを送信します。現在の状態レコードと同様に、ルーターはこれらのレコードに行動し、ネットワークの新しい希望のメンバーシップ状態を反映するように独自の状態を変更する必要があります。
Routers must query sources that are requested to be no longer forwarded to a group. 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 Member Query Time seconds. If group records are received in response to the queries which express interest in receiving traffic from the queried sources, the corresponding timers are updated.
ルータは、グループに転送されなくなるように要求されたソースを照会する必要があります。ルータが特定のソースセットのクエリをクエリまたは受信すると、それらのソースのソースタイマが最後のメンバークエリの時間秒の小さな間隔に低下します。照会されたソースからトラフィックを受信するための関心を表明するクエリに応答してグループレコードを受信した場合、対応するタイマーが更新されます。
Similarly, when a router queries a specific group, it lowers its group timer for that group to a small interval of Last Member Query Time seconds. If any group records expressing EXCLUDE mode interest in the group are received within the interval, the group timer for the group is updated and the suggestion to the routing protocol to forward the group stands without any interruption.
同様に、ルータが特定のグループに問い合わせると、そのグループのグループタイマが最後のメンバークエリの時間秒の小さな間隔に低下します。グループ内の除外モードの関心を表現するグループレコードが区間内に受信された場合、グループのグループタイマーが更新され、ルーティングプロトコルへの提案が中断されずにスタンドを表します。
During a query period (i.e., Last Member Query Time seconds), the IGMP component in the router continues to suggest to the routing protocol that it forwards traffic from the groups or sources that it is querying. It is not until after Last Member Query Time seconds without receiving a record expressing interest in the queried group or sources that the router may prune the group or sources from the network.
クエリ期間（すなわち、最後のメンバクエリ時間秒）の間、ルータ内のIGMPコンポーネントは、それが照会しているグループまたはソースからトラフィックを転送するルーティングプロトコルを提案し続けます。ルータがネットワークからグループまたはソースをプリューューしている可能性があるクエリグループまたはソースに興味を表すレコードを受信せずに、最後のメンバクエリ時間秒以降はまでではありません。
The following table describes the changes in group 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 which are sent. We use the notation 'Q(G)' to describe a Group-Specific Query to G. We use the notation 'Q(G,A)' to describe a Group-and-Source Specific Query to G 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.
送信されるクエリを記述するための以下の表記法を使用します。gをGにグループ固有のクエリを記述するには、表記「g）」を使用します。ソースリストAを使用してGグループとソース固有のクエリをgに記述するために、表記「Q（g、a）」を使用します。アクションの結果としてsource-list aがnull（例えば、a * b）である場合は、操作の結果としてクエリは送信されません。
In order to maintain protocol robustness, queries sent by actions in the table below need to be transmitted [Last Member Query Count] times, once every [Last Member Query Interval].
プロトコルの堅牢性を維持するために、以下の表のアクションによって送信されたクエリを[最後のメンバークエリ数]時刻が[最後のメンバークエリ間隔]に1回送信される必要があります。
If while scheduling new queries, there are already pending queries to be retransmitted for the same group, the new and pending queries have to be merged. In addition, received host reports for a group with pending queries may affect the contents of those queries. Section 6.6.3 describes the process of building and maintaining the state of pending queries.
新しいクエリをスケジュールするときに、同じグループに再送信されるクエリがすでに保留中のクエリがあり、新規および保留中のクエリをマージする必要があります。さらに、保留中のクエリを持つグループの受信ホストレポートは、それらのクエリの内容に影響を与える可能性があります。セクション6.6.3は、保留中のクエリの状態を構築し維持するプロセスを説明しています。
Router State Report Rec'd New Router State Actions
------------ ------------ ---------------- -------
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=GMI
（a）を含む（b）が含まれる（a b）（b）= gmiを含む。
INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(G,A*B)
（a）ブロック（b）を含む（a）送信q（g、a * b）を含む。
INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 Delete (A-B) Send Q(G,A*B) Group Timer=GMI
インクルード（a）to_ex（b）除外（a * b、b-a）（b-a）= 0削除（a-b）送信q（g、a * b）グループタイマー= gmi
INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=GMI Send Q(G,A-B)
（a）to_in（b）を含む（a b）（b）= gmi送信q（g、a - b）
EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=GMI
除外（x、y）許可（a）除外（x a、y-a）（a）= gmi
EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer Send Q(G,A-Y)
除外（x、y）ブロック（a）除外（x（a-y）、y）（a-x-y）=グループタイマー送信q（g、a-y）
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer Delete (X-A) Delete (Y-A) Send Q(G,A-Y) Group Timer=GMI
除外（x、y）to_ex（a）除外（a-y、y * a）（a-x-y）=グループタイマの削除（x-a）delete（y-a）送信q（g、a-y）グループタイマ= gmi
EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI Send Q(G,X-A) Send Q(G)
除外（x、y）to_in（a）除外（x a、y-a）（a）= gmi send q（g、x-a）送信q（g）
The group timer is used as a mechanism for transitioning the router filter-mode from EXCLUDE to INCLUDE.
グループタイマは、ルータフィルタモードをexcelludeから含めるメカニズムとして使用されます。
When a group timer expires with a router filter-mode of EXCLUDE, a router assumes that there are no systems with a *filter-mode* of EXCLUDE present on the attached network. When a router's filter-mode for a group is EXCLUDE and the group timer expires, the router filter-mode for the group transitions to INCLUDE.
グループタイマーが除外のルータフィルタモードで有効期限が切れると、ルータは添付のネットワーク上に存在する除外の*フィルタモード*を持つシステムがないと見なします。グループのルータのフィルタモードが除外され、グループタイマーが期限切れになると、グループ遷移のルータフィルタモードが含まれます。
A router uses source records with running source timers as its state for the switch to a filter-mode of INCLUDE. If there are any source records with source timers greater than zero (i.e., requested to be forwarded), a router switches to filter-mode of INCLUDE using those source records. Source records whose timers are zero (from the previous EXCLUDE mode) are deleted.
ルータは、インクルードのフィルタモードへのスイッチの状態として、ソースタイマーを実行してソースレコードを使用します。ソースタイマをゼロより大きい（すなわち転送されるように要求される）ソースレコードがある場合、ルータはそれらのソースレコードを使用するインクルードのフィルタモードに切り替わる。（前回の除外モードから）タイマーがゼロであるソースレコードは削除されます。
For example, if a router's state for a group is EXCLUDE(X,Y) and the group timer expires for that group, the router switches to filter-mode of INCLUDE with state INCLUDE(X).
たとえば、グループのルータの状態が除外され（X、Y）とグループタイマーがそのグループの期限切れになると、ルータはSTATEのフィルタモードに切り替わります（X）。
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 group or sources being queried. The following table describes the timer actions when sending or receiving a Group-Specific or Group-and-Source Specific Query with the Suppress Router-Side Processing flag not set.
ルータがルータ側処理フラグをクリアしてクエリを送信または受信すると、クエリされているグループまたはソースの正しいタイムアウト値を反映するようにそのタイマを更新する必要があります。次の表に、ルータ側処理フラグが設定されていない状態で、グループ固有またはグループおよびソース固有のクエリを送信または受信したときのタイマーアクションを示します。
Query Action
----- ------
Q(G,A) Source Timer for sources in A are lowered to LMQT
Q(G) Group Timer is lowered to LMQT
When a router sends or receives a query with the Suppress Router-Side Processing flag set, it will not update its timers.
ルータが抑制されたルータ側処理フラグを設定してクエリを送信または受信すると、そのタイマーが更新されません。
IGMPv3 elects a single querier per subnet using the same querier election mechanism as IGMPv2, namely by IP address. When a router receives a query with a lower IP address, it sets the Other-Querier-Present timer to Other Querier Present Interval and ceases to send queries on the network if it was the previously elected querier. After its Other-Querier Present timer expires, it should begin sending General Queries.
IGMPv3は、IGMPv2と同じQuerier選挙メカニズムを使用してサブネットごとに単一のクエリアを選択します。つまり、IPアドレスによって。ルータがIPアドレスが低いクエリを受信すると、他のクエリアの現在のタイマーを他のクエリアの現在の間隔に設定し、以前に選択されたクエリアである場合はネットワーク上のクエリを送信しなくなります。他のクエリエの現在のタイマーが期限切れになると、一般的なクエリの送信を開始します。
If a router receives an older version query, it MUST use the oldest version of IGMP on the network. For a detailed description of compatibility issues between IGMP versions see section 7.
ルータが古いバージョンクエリを受信した場合は、ネットワーク上で最も古いバージョンのIGMPを使用する必要があります。IGMPバージョン間の互換性の問題の詳細については、7を参照してください。
When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time].
テーブルアクション「送信Q（g）」が発生した場合、グループタイマーはLMQTに低下する必要があります。ルータは、[最後のメンバクエリ間隔]を介して[最後のメンバクエリ間隔]ごとに[最後のメンバクエリ間隔]を送信するクエリの再送信と同様に、ルータはすぐにグループ固有のクエリを送信する必要があります。
When transmitting a group specific query, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.
グループ固有クエリを送信する場合、グループタイマがLMQTより大きい場合は、クエリメッセージに「ルータ側処理の抑制」ビットが設定される。
When a table action "Send Q(G,X)" is encountered by a querier in the table in section 6.4.2, the following actions must be performed for each of the sources in X of group G, with source timer larger than LMQT:
6.4.2項の表のクエリアによってテーブルアクション "Send Q（g、x）"が照らされている場合、グループGのXの各ソースに対して次のアクションを実行する必要があります。：
o Set number of retransmissions for each source to [Last Member Query Count].
o 各ソースの再送信数を[最後のメンバークエリ数]に設定します。
o Lower source timer to LMQT.
o LMQTへのソースタイマー。
The router must then immediately send a group and source specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. The contents of these queries are calculated as follows.
ルータは、スケジュール[最後のメンバクエリ間隔]を介して[最後のメンバクエリ間隔]を送信するクエリの再送信をすぐに送信する必要があります。これらのクエリの内容は次のように計算されます。
When building a group and source specific query for a group G, two separate query messages are sent for the group. The first one has the "Suppress Router-Side Processing" bit set and contains all the sources with retransmission state and timers greater than LMQT. The second has the "Suppress Router-Side Processing" bit clear and contains all the sources with retransmission state and timers lower or equal to LMQT. If either of the two calculated messages does not contain any sources, then its transmission is suppressed.
グループGに対してグループとソース固有のクエリを構築するときは、グループに対して2つの別々のクエリメッセージが送信されます。最初のものは、「ルータ側処理を抑制する」ビットを設定し、再送状態を有する全てのソースとLMQTよりも大きいタイマを含む。2つ目は、「ルータ側の処理を抑制する」ビットがクリアされ、再送状態とタイマがLMQTに下または等しいすべてのソースを含む。2つの計算メッセージのいずれかにソースが含まれていない場合、その送信は抑制されます。
Note: If a group specific query is scheduled to be transmitted at the same time as a group and source specific query for the same group, then transmission of the group and source specific message with the "Suppress Router-Side Processing" bit set may be suppressed.
注：グループ固有のクエリが、同じグループのグループとソース固有のクエリと同時に送信されるようにスケジュールされている場合は、[ルータ側処理の抑制]ビットセットを使用してグループとソース固有のメッセージの送信ができます。抑制されました。
IGMP version 3 hosts and routers interoperate with hosts and routers that have not yet been upgraded to IGMPv3. This compatibility is maintained by hosts and routers taking appropriate actions depending on the versions of IGMP operating on hosts and routers within a network.
IGMPバージョン3ホストとルータは、まだIGMPv3にアップグレードされていないホストとルータと相互運用しています。この互換性は、ホストとネットワーク内のルータで動作するIGMPのバージョンに応じて、ホストとルータによって維持されます。
The IGMP version of a Membership Query message is determined as follows:
メンバーシップクエリメッセージのIGMPバージョンは次のように決定されます。
IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero
IGMPv1クエリ：length = 8オクテットと最大呼び出しコードフィールドはゼロです
IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-zero
IGMPv2クエリ：length = 8オクテットとMAX RESPコードフィールドはゼロ以外です
IGMPv3 Query: length >= 12 octets
Query messages that do not match any of the above conditions (e.g., a Query of length 10 octets) MUST be silently ignored.
上記の条件（例えば、長さ10オクテットのクエリ）と一致しないクエリメッセージは、黙って無視されなければなりません。
In order to be compatible with older version routers, IGMPv3 hosts MUST operate in version 1 and version 2 compatibility modes. IGMPv3 hosts MUST keep state per local interface regarding the compatibility mode of each attached network. A host's compatibility mode is determined from the Host Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface and is dependent on the version of General Queries heard on that interface as well as the Older Version Querier Present timers for the interface.
古いバージョンルータと互換性があるため、IGMPv3ホストはバージョン1およびバージョン2の互換モードで動作する必要があります。IGMPv3ホストは、添付された各ネットワークの互換性モードに関するローカルインターフェイスごとに状態を保持する必要があります。ホストの互換モードは、IGMPv1、IgMPv2、またはIGMPv3の3つの状態のうちの1つにあることができるホスト互換モード変数から決定されます。この変数はインターフェイスごとに保持され、そのインターフェイスで聞いた一般的なクエリのバージョン、およびインターフェイスの古いバージョンのクエリアが表示されます。
In order to switch gracefully between versions of IGMP, hosts keep both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present timer per interface. IGMPv1 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv1 Membership Query is received. IGMPv2 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv2 General Query is received.
IGMPのバージョンの間に正常に切り替えるために、ホストはIGMPv1クエリアプレゼントタイマーとIGMPv2クエリアプレゼントタイマーの両方をインターフェイスごとに保持します。IGMPv1 Querier exelentは、IGMPv1メンバーシップクエリが受信されるたびに、古いバージョンのクエリア現在のタイムアウト秒に設定されています。IGMPv2 Querier exelentは、IGMPv2一般クエリが受信されるたびに、古いバージョンのクエリア現在のタイムアウト秒に設定されています。
The Host Compatibility Mode of an interface changes whenever an older version query (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv2 if it has a running IGMPv2 Querier Present timer. If it does not have a running IGMPv2 Querier Present timer then it switches to Host Compatibility of IGMPv3. When the IGMPv2 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv3.
古いバージョンのクエリ（現在の互換モードより）が聞こえるとき、または特定のタイマー条件が発生したときはいつでもインタフェースの互換性モードが変わります。IGMPv1 Querierが存在するタイマーが期限切れになると、実行中のIGMPv2 Quelier Timerが実行されている場合は、ホストがIGMPv2のホスト互換モードに切り替わります。実行中のIGMPv2 Querier aumentyタイマーがない場合は、IGMPv3のホスト互換性に切り替わります。IGMPv2 Querierが存在するタイマーが期限切れになると、ホストはIGMPv3のホスト互換モードに切り替わります。
The Host Compatibility Mode variable is based on whether an older version General query was heard in the last Older Version Querier Present Timeout seconds. The Host Compatibility Mode is set depending on the following:
ホスト互換モード変数は、最後に古いバージョンのクエリア現在のタイムアウト秒で古いバージョンの一般クエリが聞こえたかどうかに基づいています。次の点に応じて、ホスト互換モードが設定されています。
Host Compatibility Mode Timer State
----------------------- -----------
IGMPv3 (default) IGMPv2 Querier Present not running and IGMPv1 Querier Present not running
IGMPv3（デフォルト）IGMPv2クエリアが実行されていないとIGMPv1クエリアが実行されていない
IGMPv2 IGMPv2 Querier Present running and IGMPv1 Querier Present not running
IGMPv2 IGMPv2クエリアが現在実行されていて、実行されていないIGMPv1クエリアが存在する
IGMPv1 IGMPv1 Querier Present running
IGMPv1 IGMPv1クエリアが稼働しています
If a host receives a query which causes its Querier Present timers to be updated and correspondingly its compatibility mode, it should switch compatibility modes immediately.
ホストがクエリアを受信したクエリを受信した場合、そのクエリアのプレゼントタイマを更新し、それに対応してその互換モードでは、互換モードをすぐに切り替える必要があります。
When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3 protocol on that interface. When Host Compatibility Mode is IGMPv2, a host acts in IGMPv2 compatibility mode, using only the IGMPv2 protocol, on that interface. When Host Compatibility Mode is IGMPv1, a host acts in IGMPv1 compatibility mode, using only the IGMPv1 protocol on that interface.
ホスト互換モードがIGMPv3の場合、ホストはそのインターフェイス上のIGMPv3プロトコルを使用して機能します。ホスト互換モードがIGMPv2の場合、そのインターフェイス上のIGMPv2プロトコルのみを使用して、IGMPv2互換モードでホストが機能します。ホスト互換モードがIGMPv1の場合、ホストはそのインターフェイス上のIGMPv1プロトコルのみを使用して、IGMPv1互換モードで機能します。
An IGMPv1 router will send General Queries with the Max Resp Code set to 0. This MUST be interpreted as a value of 100 (10 seconds).
IGMPv1ルータはMAX RESPコードを0に設定して一般的なクエリを送信します。これは、100（10秒）の値として解釈されます。
An IGMPv2 router will send General Queries with the Max Resp Code set to the desired Max Resp Time, i.e., the full range of this field is linear and the exponential algorithm described in section 4.1.1 is not used.
IGMPv2ルーターは、MAX RESPコードセットを所望のMAX RESP時間に設定して一般的なクエリを送信します。すなわち、このフィールドの全範囲は線形であり、セクション4.1.1で説明されている指数関数アルゴリズムは使用されていません。
Whenever a host changes its compatibility mode, it cancels all its pending response and retransmission timers.
ホストがその互換性モードを変更するたびに、それはそのすべてのその保留中の応答と再送信タイマーを取り消します。
An IGMPv3 host may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 Membership Record to be suppressed by either a Version 1 Membership Report, or a Version 2 Membership Report.
IGMPv3ホストは、まだIGMPv3にアップグレードされていないホストがあるネットワーク上に置かれます。ホストは、そのIGMPv3メンバーシップレコードをバージョン1メンバーシップレポートまたはバージョン2メンバーシップレポートのいずれかによって抑制することができます。
IGMPv3 routers may be placed on a network where at least one router on the network has not yet been upgraded to IGMPv3. The following requirements apply:
IGMPv3ルータは、ネットワーク上の少なくとも1つのルータがまだIGMPv3にアップグレードされていないネットワーク上に配置されることがあります。以下の要件が適用されます。
o If any older versions of IGMP are present on routers, the querier MUST use the lowest version of IGMP present on the network. This must be administratively assured; routers that desire to be compatible with IGMPv1 and IGMPv2 MUST have a configuration option to act in IGMPv1 or IGMPv2 compatibility modes. When in IGMPv1 mode, routers MUST send Periodic Queries with a Max Resp Code of 0 and truncated at the Group Address field (i.e., 8 bytes long), and MUST ignore Leave Group messages. They SHOULD also warn about receiving an IGMPv2 or IGMPv3 query, although such warnings MUST be rate-limited. When in IGMPv2 mode, routers MUST send Periodic Queries truncated at the Group Address field (i.e., 8 bytes long), and SHOULD also warn about receiving an IGMPv3 query (such warnings MUST be rate-limited). They also MUST fill in the Max Resp Time in the Max Resp Code field, i.e., the exponential algorithm described in section 4.1.1 is not used.
o より古いバージョンのIGMPがルータに存在する場合、クエリアはネットワーク上に存在するIGMPの最下位バージョンを使用する必要があります。これは管理上保証されなければなりません。IGMPv1とIGMPv2と互換性があることを望むルータには、IGMPv1またはIGMPv2互換モードで動作する構成オプションが必要です。IGMPv1モードでは、ルーターはMAX RESPコード0で定期クエリを送信し、グループアドレスフィールド（すなわち、8バイト長）で切り捨てられ、[グループのまま）メッセージを無視する必要があります。そのような警告はrate-limitedでなければなりませんが、それらはIGMPv2またはIGMPv3クエリを受信することを警告する必要があります。IGMPv2モードでは、ルーターはグループアドレスフィールド（すなわち、8バイト長）で切り捨てられた周期的なクエリを送信する必要があります。また、IGMPv3クエリを受信することについて警告する必要があります（そのような警告はrate-limits-requirs-limited）。また、MAX RESPコードフィールド、すなわちセクション4.1.1で説明されている指数関数アルゴリズムを使用しないでください。
o If a router is not explicitly configured to use IGMPv1 or IGMPv2 and hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a warning. These warnings MUST be rate-limited.
o ルータがIGMPv1またはIGMPv2を使用してIGMPv1クエリまたはIGMPv2一般クエリを使用するように明示的に設定されていない場合は、警告を記録する必要があります。これらの警告はrate-limitedでなければなりません。
IGMPv3 routers may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. In order to be compatible with older version hosts, IGMPv3 routers MUST operate in version 1 and version 2 compatibility modes. IGMPv3 routers keep a compatibility mode per group record. A group's compatibility mode is determined from the Group Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per group record and is dependent on the version of Membership Reports heard for that group as well as the Older Version Host Present timer for the group.
IGMPv3ルータは、まだIGMPv3にアップグレードされていないホストがあるネットワーク上に配置することができます。古いバージョンのホストと互換性があるため、IGMPv3ルータはバージョン1およびバージョン2の互換モードで動作する必要があります。IGMPv3ルータグループレコードごとに互換性モードを保存します。グループの互換性モードは、IGMPv1、IgMPv2、またはIgMPv3の3つの状態のうちの1つにあり得るグループ互換モード変数から決定されます。この変数はグループレコードごとに保持され、そのグループに対して聞いたメンバーシップレポートのバージョン、およびグループの古いバージョンのホストに依存しています。
In order to switch gracefully between versions of IGMP, routers keep an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per group record. The IGMPv1 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv1 Membership Report is received. The IGMPv2 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv2 Membership Report is received.
IGMPのバージョン間で優雅に切り替えるために、ルータはIGMPv1ホストに存在するタイマーとグループレコードごとのIGMPv2ホストが存在します。IGMPv1ホストプレゼントタイマーは、IGMPv1メンバーシップレポートを受信したときに、古いバージョンホストの現在のタイムアウト秒に設定されています。IGMPv2 Host Present Timerは、IGMPv2メンバーシップレポートを受信したときにTimeout Secondsを古いバージョンのホストに設定されています。
The Group Compatibility Mode of a group record changes whenever an older version report (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Host Present timer expires, a router switches to Group Compatibility mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it does not have a running IGMPv2 Host Present timer then it switches to Group Compatibility of IGMPv3. When the IGMPv2 Host Present timer expires and the IGMPv1 Host Present timer is not running, a router switches to Group Compatibility mode of IGMPv3. Note that when a group switches back to IGMPv3 mode, 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 [Group Membership Interval] after that.
グループレコードのグループ互換モード（現在の互換モードよりも現在の互換モードより）が聞こえたり、特定のタイマー条件が発生したときに変更されます。IGMPv1ホストがタイマーの有効期限が切れると、Running IGMPv2ホストが存在する場合は、IGMPv2のグループ互換モードに切り替わります。実行中のIGMPv2ホストが表示されていない場合は、IGMPv3のグループの互換性に切り替わります。IGMPv2ホストが存在するタイマーの有効期限が切れて、IGMPv1ホストの存在タイマーが実行されていない場合、ルータはIGMPv3のグループ互換モードに切り替わります。グループがIGMPv3モードに戻ると、ソース固有の状態情報を取り戻すために時間がかかります。次の一般的なクエリの間にソース固有の情報が学習されますが、ブロックされるべきソースはその後[グループメンバーシップ間隔]までブロックされません。
The Group Compatibility Mode variable is based on whether an older
version report was heard in the last Older Version Host Present
Timeout seconds. The Group Compatibility Mode is set depending on
the following:
Group Compatibility Mode Timer State
------------------------ -----------
IGMPv3 (default) IGMPv2 Host Present not running and IGMPv1 Host Present not running
IGMPv3（デフォルト）IGMPv2ホストが実行されていない、およびIGMPv1ホストが実行されていない
IGMPv2 IGMPv2 Host Present running and IGMPv1 Host Present not running
実行されていないIGMPv2 IGMPv2ホストが現在実行されていません。
IGMPv1 IGMPv1 Host Present running
IGMPv1 IGMPv1ホストが走っています
If a router receives a report which causes its older Host Present timers to be updated and correspondingly its compatibility mode, it SHOULD switch compatibility modes immediately.
ルータが古いホストを更新するレポートを受信した場合は、タイマを更新し、対応する互換性モードで、互換モードをすぐに切り替える必要があります。
When Group Compatibility Mode is IGMPv3, a router acts using the IGMPv3 protocol for that group.
グループ互換モードがIGMPv3の場合、ルータはそのグループのIGMPv3プロトコルを使用して機能します。
When Group Compatibility Mode is IGMPv2, a router internally translates the following IGMPv2 messages for that group to their IGMPv3 equivalents:
グループ互換モードがIGMPv2の場合、ルータはそのグループの次のIGMPv2メッセージをIGMPv3換算に内部的に変換します。
IGMPv2 Message IGMPv3 Equivalent
-------------- -----------------
Report IS_EX( {} )
Leave TO_IN( {} )
IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX() messages (i.e., any TO_EX() message is treated as TO_EX( {} )).
IGMPv3ブロックメッセージは、to_ex（）メッセージ（すなわち、任意のto_ex（）メッセージ）と同様に無視されます（すなわち、任意のto_ex（）メッセージはto_ex（{}））。
When Group Compatibility Mode is IGMPv1, a router internally translates the following IGMPv1 and IGMPv2 messages for that group to their IGMPv3 equivalents:
グループ互換モードがIGMPv1の場合、ルータはそのグループの次のIGMPv1メッセージとIGMPv2メッセージをIGMPv3換算に内部的に変換します。
IGMP Message IGMPv3 Equivalent
------------ -----------------
v1 Report IS_EX( {} )
v2 Report IS_EX( {} )
In addition to ignoring IGMPv3 BLOCK messages and source-lists in TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave messages and IGMPv3 TO_IN() messages are also ignored.
IGMPv2グループ互換モードのようにIGMPv3ブロックメッセージとsource-listsを無視することに加えて、IGMPv2メッセージとIGMPv3 TO_IN（）メッセージも無視されます。
Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all systems on a single link. Note that parentheses are used to group expressions to make the algebra clear.
これらのタイマーのほとんどは設定可能です。デフォルト以外の設定が使用されている場合、それらは単一のリンク上のすべてのシステム間で一貫性がなければなりません。代数を明確にするために式をグループ化するために括弧が使用されていることに注意してください。
The Robustness Variable allows tuning for the expected packet loss on a network. If a network is expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2
堅牢性変数は、ネットワーク上で予想されるパケット損失のための調整を可能にします。ネットワークが損失があると予想される場合は、堅牢性変数を増やすことができます。IGMPは（堅牢性変数 - 1）パケット損失に堅牢です。堅牢性変数はゼロにしてはならず、1つずつではありません。デフォルト：2
The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds.
クエリ間隔は、クエリアによって送信された一般的なクエリ間の間隔です。デフォルト：125秒
By varying the [Query Interval], an administrator may tune the number of IGMP messages on the network; larger values cause IGMP Queries to be sent less often.
[クエリ間隔]を変えることによって、管理者はネットワーク上のIGMPメッセージの数を調整することができます。値が大きいほど、IGMPクエリは頻繁に送信されることがあります。
The Max Response Time used to calculate the Max Resp Code inserted into the periodic General Queries. Default: 100 (10 seconds)
周期的な一般的なクエリに挿入されたMAX RESPコードを計算するために使用される最大応答時間。デフォルト：100（10秒）
By varying the [Query Response Interval], an administrator may tune the burstiness of IGMP messages on the network; 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].
[クエリ応答間隔]を変えることによって、管理者はネットワーク上のIGMPメッセージのバースト性を調整することができます。値が大きいほど、ホスト応答が大きい間隔で拡散されるため、トラフィックが少ないバーストが少なくなります。[クエリ応答間隔]で表される秒数は[クエリ間隔]より小さくなければなりません。
The Group Membership Interval is the amount of time that must pass before a multicast router decides there are no more members of a group or a particular source on a network.
グループメンバーシップ間隔は、マルチキャストルータがネットワーク上のグループまたは特定のソースのメンバがないと判断するまでに合格しなければならない時間です。
This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
この値は（（ロバストネス変数）時間（クエリ間隔））とプラス（1つのクエリ応答間隔）でなければなりません。
The Other Querier Present Interval is the length of time that must pass before a multicast router decides that there is no longer another multicast router which should be the querier. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval).
他のQuerier現在の間隔は、マルチキャストルータがQuerierになる必要がある別のマルチキャストルータがなくなると判断しなければならない時間の長さです。この値は（（耐圧変数）時間（クエリ間隔））と（1つのクエリ応答間隔の半分）でなければなりません。
The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval.
起動クエリ間隔は、起動時にクエリアによって送信された一般クエリ間の間隔です。デフォルト：1/4クエリ間隔。
The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable.
起動クエリ数は、起動時に区切られた起動時に送信されたクエリの数です。デフォルト：堅牢性変数。
The Last Member Query Interval is the Max Response Time used to calculate the Max Resp Code inserted into Group-Specific Queries sent in response to Leave Group messages. It is also the Max Response Time used in calculating the Max Resp Code for Group-and-Source-Specific Query messages. Default: 10 (1 second)
最後のメンバクエリ間隔は、Leave Groupメッセージに応答して送信されたグループ固有のクエリに挿入されたMAX Respコードを計算するために使用される最大応答時間です。グループとソース固有のクエリメッセージのMAX RESPコードの計算に使用される最大応答時間です。デフォルト：10（1秒）
Note that for values of LMQI greater than 12.8 seconds, a limited set of values can be represented, corresponding to sequential values of Max Resp Code. When converting a configured time to a Max Resp 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.
12.8秒を超えるLMQIの値については、限られた値のセットを表すことができます。設定された時間を最大RESPコード値に変換するときは、可能であれば正確な値を使用することをお勧めします。要求された値が正確に表現できない場合は、次の値を使用することをお勧めします。
This value may be tuned to modify the "leave latency" of the network. A reduced value results in reduced time to detect the loss of the last member of a group or source.
この値は、ネットワークの「待ち時間を残す」を変更するために調整されてもよい。値が縮小された値は、グループまたはソースの最後のメンバーの損失を検出するために時間を短縮します。
The Last Member Query Count is the number of Group-Specific Queries sent before the router assumes there are no local members. The Last Member Query Count is also the number of Group-and-Source-Specific Queries sent before the router assumes there are no listeners for a particular source. Default: the Robustness Variable.
最後のメンバークエリ数は、ルータがローカルメンバーがないと見なされる前に送信されたグループ固有のクエリの数です。最後のメンバークエリカウントは、ルータが特定のソースのリスナーがないと見なされる前に送信されたグループとソース固有のクエリの数もあります。デフォルト：堅牢性変数。
The Last Member Query Time is the time value represented by the Last Member Query Interval, multiplied by the Last Member Query Count. It is not a tunable value, but may be tuned by changing its components.
最後のメンバークエリ時間は、最後のメンバークエリ間隔で表される時間値で、最後のメンバークエリ数を掛けます。調整可能な値ではありませんが、そのコンポーネントを変更することによって調整される可能性があります。
The Unsolicited Report Interval is the time between repetitions of a host's initial report of membership in a group. Default: 1 second.
迷惑な報告間隔は、グループ内のメンバーシップのホストの初期レポートの繰り返しの間の時間です。デフォルト：1秒。
The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval.
古いバージョンのクエリア間隔は、古いバージョンのクエリが聞こえたら、ホストをIGMPv3モードに移行するためのタイムアウトです。古いバージョンのクエリが受信されると、Hostsは古いバージョンのクエリアが古いバージョンのクエリア間隔に存在するタイマーを設定します。
This value MUST be ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval).
この値は（（ROBUSTNESS変数）時間（最後のクエリのクエリ間隔））とプラス（1つのクエリ応答間隔）でなければなりません。
The Older Host Present Interval is the time-out for transitioning a group back to IGMPv3 mode once an older version report is sent for that group. When an older version report is received, routers set their Older Host Present Timer to Older Host Present Interval.
古いホスト現在の間隔は、古いバージョンのレポートがそのグループに対して送信されたら、グループをIGMPv3モードに移行するためのタイムアウトです。古いバージョンのレポートを受信すると、ルーターは古いホストに存在するタイマーを古いホスト現在の間隔に設定します。
This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
この値は（（ロバストネス変数）時間（クエリ間隔））とプラス（1つのクエリ応答間隔）でなければなりません。
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.
このセクションは、これらの設定をネットワークに調整する方法についてネットワーク管理者にアドバイスを提供することを目的としています。野心的なルータの実装は、ネットワークの特性の変化に基づいてこれらの設定を動的に調整する可能性があります。
The Robustness Variable tunes IGMP to expected losses on a link. IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if the Robustness Variable is set to the default value of 2, IGMPv3 is robust to a single packet loss but may operate imperfectly if more losses occur. On lossy subnetworks, the Robustness Variable should be increased to allow for the expected level of packet loss. However, increasing the Robustness Variable increases the leave latency of the subnetwork. (The leave latency is the time between when the last member stops listening to a source or group and when the traffic stops flowing.)
ロバストネス変数は、リンク上の予想損失からIGMPを調整します。IGMPv3は堅牢な（堅牢性変数 - 1）パケット損失、例えば、耐圧変数がデフォルト値2に設定されている場合、IGMPv3は単一のパケット損失に対して堅牢であるが、より多くの損失が発生した場合に不完全に動作する可能性がある。損失のあるサブネットワークでは、予想されるパケット損失レベルを可能にするために堅牢性変数を増やす必要があります。ただし、ロバストネス変数を増やすと、サブネットワークの待ち時間が表示されます。（遅延待ち時間は、最後のメンバーがソースまたはグループの聴取を停止し、トラフィックが流れる停止時の間の時間です。）
The overall level of periodic IGMP traffic is inversely proportional to the Query Interval. A longer Query Interval results in a lower overall level of IGMP traffic. The Query Interval MUST be equal to or longer than the Max Response Time inserted in General Query messages.
周期的IGMPトラフィックの全体的なレベルは、クエリ間隔に反比例します。より長いクエリ間隔は、IGMPトラフィックの全体レベルが低いとなります。クエリ間隔は、一般的なクエリメッセージに挿入された最大応答時間以上でなければなりません。
The burstiness of IGMP traffic is inversely proportional to the Max Response Time. A longer Max Response Time will spread Report messages over a longer interval. However, a longer Max Response Time in Group-Specific and Source-and-Group-Specific Queries extends the leave latency. (The leave latency is the time between when the last member stops listening to a source or group and when the traffic stops flowing.) The expected rate of Report messages can be calculated by dividing the expected number of Reporters by the Max Response Time. The Max Response Time may be dynamically calculated per Query by using the expected number of Reporters for that Query as follows:
IGMPトラフィックのバーシネスは最大応答時間に反比例します。より長い最大応答時間は、レポートメッセージを長期間にわたって拡散します。ただし、グループ固有のクエリとソースおよびグループ固有のクエリでの最大応答時間が長いほど、遅延待ち時間が拡張されます。最後のメンバーがソースまたはグループへのリスニングを停止し、トラフィックが流れる停止時の時間間の時間です。）予想されるレポートメッセージの期待値は、予想されるレポーター数を最大応答時間で割ることによって計算できます。最大応答時間は、次のようにそのクエリの予想されるレポーター数を使用して、クエリごとに動的に計算できます。
Query Type Expected number of Reporters
---------- ----------------------------
General Query All systems on subnetwork
一般的なサブネットワーク上のすべてのシステムをクエリします
Group-Specific Query All systems that had expressed interest in the group on the subnetwork
グループ固有のクエリサブネットワーク上のグループに興味を表明したすべてのシステム
Source-and-Group- All systems on the subnetwork that had Specific Query expressed interest in the source and group
ソース-およびグループ - 特定のクエリを持つサブネットワーク上のすべてのシステムは、ソースとグループに興味を表明しました。
A router is not required to calculate these populations or tune the Max Response Time dynamically; these are simply guidelines.
これらの個体群を計算するか、最大応答時間を動的に調整するためにルータが必要ではありません。これらは単にガイドラインです。
We consider the ramifications of a forged message of each type, and describe the usage of IPSEC AH to authenticate messages if desired.
必要に応じてメッセージを認証するためのIPsec AHの使用方法を説明します。
A forged Query message from a machine with a lower IP address than the current Querier will cause Querier duties to be assigned to the forger. If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. During this time, if the forger ignores Leave Messages, traffic might flow to groups with no members for up to [Group Membership Interval].
現在のクエリアよりも低いIPアドレスを持つマシンからの偽造クエリメッセージは、QUERIER業務をフォージャーに割り当てます。フォーガーがこれ以上クエリメッセージを送信しない場合、他のルータの他のQuerier Present Timerはタイムアウトし、クエリアの役割を再開します。この間、フォーガーがメッセージを残しても、トラフィックはグループメンバーシップ間隔のメンバーなしでグループに流れます。
A DoS attack on a host could be staged through forged Group-and-Source-Specific Queries. The attacker can find out about membership of a specific host with a general query. After that it could send a large number of Group-and-Source-Specific queries, each with a large source list and the Maximum Response Time set to a large value. The host 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.
ホストへのDOS攻撃は、偽造グループとソース固有のクエリを介してステージングできます。攻撃者は、一般的なクエリを使用して特定のホストのメンバーシップについて知ることができます。その後、多数のグループとソース固有のクエリを送信することができ、それぞれが大きなソースリストを持つ最大応答時間が大きい値に設定されます。ホストは、遅延応答を送信するのにかかる限り、それらのクエリのすべてで指定されたソースを保存および維持する必要があります。これは、連続するクエリに含まれているソースリストで記録されたソースを増大させるために、メモリとCPUサイクルの両方を消費します。
To protect against such a DoS attack, a host stack implementation could restrict the number of Group-and-Source-Specific Queries per group membership within this interval, and/or record only a limited number of sources.
このようなDOS攻撃から保護するために、ホストスタックの実装は、この間隔内のグループメンバーシップごとのグループとソース固有のクエリの数を制限し、および/または限られた数のソースのみを記録することができます。
Forged Query messages from the local network can be easily traced. There are three measures necessary to defend against externally forged Queries:
ローカルネットワークからの偽造されたクエリメッセージは簡単にトレースできます。外部鍛造クエリに対して守るために必要な3つの対策があります。
o Routers SHOULD NOT forward Queries. This is easier for a router to accomplish if the Query carries the Router-Alert option.
o ルーターはクエリを転送しないでください。クエリがRouter-Alertオプションを搭載している場合は、ルータが実行できる方が簡単です。
o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert option.
o ホストは、router-alertオプションなしでV2またはV3クエリを無視します。
o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a multicast address other than 224.0.0.1, the all-systems address.
o ホストは、v1、v2、またはv3一般クエリを無視する必要があります。
A forged Report message may cause multicast routers to think there are members of a group on a network when there are not. Forged Report messages from the local network are meaningless, since joining a group on a host is generally an unprivileged operation, so a local user may trivially gain the same result without forging any messages. Forged Report messages from external sources are more troublesome; there are two defenses against externally forged Reports: o Ignore the Report if you cannot identify the source address of the packet as belonging to a network assigned to the interface on which the packet was received. This solution means that Reports sent by mobile hosts without addresses on the local network will be ignored. Report messages with a source address of 0.0.0.0 SHOULD be accepted on any interface.
鍛造レポートメッセージは、マルチキャストルータがネットワーク上のグループのメンバーがあると考えることがある可能性があります。ホスト上のグループを結合することは一般に非特権の操作であるため、ローカルネットワークからの偽信レポートメッセージは一般に非特権の操作であるため、メッセージを偽造することなく同じ結果を著しく得ることができます。外部ソースからの偽造レポートメッセージはより面倒です。外部から鍛造されたレポートに対しては2つの防御があります.oパケットが受信されたインターフェイスに割り当てられているネットワークに属するパケットの送信元アドレスを識別できない場合は、レポートを無視してください。このソリューションは、ローカルネットワーク上のアドレスなしでモバイルホストによって送信されたレポートが無視されることを意味します。0.0.0.0の送信元アドレスを持つ報告メッセージは、どのインターフェイスでも受け入れられます。
o Ignore Report messages without Router Alert options [RFC-2113], and require that routers not forward Report messages. (The requirement is not a requirement of generalized filtering in the forwarding path, since the packets already have Router Alert options in them.) This solution breaks backwards compatibility with implementations of IGMPv1 or earlier versions of IGMPv2 which did not require Router Alert.
o Reporter Alertオプション[RFC-2113]なしでレポートメッセージを無視し、ルータがレポートメッセージを転送しないようにする必要があります。このソリューションは、IGMPv1または以前のバージョンのIGMPv2の実装との互換性を解決するため、Router Alertを必要としないIGMPv2の実装との互換性を解決します。
A forged Version 1 Report Message may put a router into "version 1 members present" state for a particular group, meaning that the router will ignore Leave messages. This can cause traffic to flow to groups with no members for up to [Group Membership 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 should only be used in situations where "fast leave" is critical.
鍛造バージョン1レポートメッセージは、特定のグループに対して「バージョン1メンバー存在」状態にルータを置くことができます。つまり、ルータはMessageを無視します。これにより、トラフィックがグループメンバシップ間隔までのメンバーなしでグループに流れ込むことがあります。これは、バージョン1メッセージを完全に無視するための構成スイッチを使用してルータを提供することで解決できます。これはバージョン1のホストとの自動互換性を解消するので、「早い休暇」が重要である状況でのみ使用する必要があります。
A forged Version 2 Report Message may put a router into "version 2 members present" state for a particular group, meaning that the router will ignore IGMPv3 source-specific state messages. This can cause traffic to flow from unwanted sources for up to [Group Membership Interval]. This can be solved by providing routers with a configuration switch to ignore Version 2 messages completely. This breaks automatic compatibility with Version 2 hosts, so should only be used in situations where source include and exclude is critical.
鍛造バージョン2レポートメッセージは、特定のグループに対してルータを「バージョン2メンバー存在」状態にすることができます。つまり、ルータはIGMPv3ソース固有の状態メッセージを無視します。これにより、トラフィックが不要なソースから最大[グループメンバーシップ間隔]に流れる可能性があります。これは、バージョン2メッセージを完全に無視するための構成スイッチを使用してルータを提供することで解決できます。これはバージョン2のホストとの自動互換性を解消するので、source includeとexcludeが重要である状況でのみ使用する必要があります。
A forged State-Change Report message will cause the Querier to send out Group-Specific or Source-and-Group-Specific Queries for the group in question. This causes extra processing on each router and on each member of the group, but can not cause loss of desired traffic. There are two defenses against externally forged State-Change Report messages: o Ignore the State-Change Report message if you cannot identify the source address of the packet as belonging to a subnet assigned to the interface on which the packet was received. This solution means that State-Change Report messages sent by mobile hosts without addresses on the local subnet will be ignored. State-Change Report messages with a source address of 0.0.0.0 SHOULD be accepted on any interface.
鍛造状態変更レポートメッセージには、クエリアが問題のグループに対してグループ固有またはグループ固有のクエリを送信します。これにより、各ルータおよびグループの各メンバーで追加の処理が発生しますが、希望のトラフィックの損失を引き起こすことはできません。外部から鍛造状態変更レポートメッセージに対する2つの防御があります。oパケットが受信されたインターフェイスに割り当てられているサブネットに属するパケットの送信元アドレスを識別できない場合は、状態変更レポートメッセージを無視します。このソリューションは、ローカルサブネット上のアドレスなしでモバイルホストによって送信された状態変更レポートメッセージが無視されます。0.0.0.0の送信元アドレスを持つ状態変更レポートメッセージは、どのインターフェイスでも受け入れられます。
o Ignore State-Change Report messages without Router Alert options [RFC-2113], and require that routers not forward State-Change Report messages. (The requirement is not a requirement of generalized filtering in the forwarding path, since the packets already have Router Alert options in them.)
o ルータアラートオプション[RFC-2113]のない状態変更レポートメッセージを無視し、ルータが状態変更レポートメッセージを転送しないようにする必要があります。（この要件は、パケットにはすでにルータの警告オプションがすでに持っているため、転送パスの一般化されたフィルタリングの要件ではありません。）
In addition to these measures, IPSEC in Authentication Header mode [AH] may be used to protect against remote attacks by ensuring that IGMPv3 messages came from a system on the LAN (or, more specifically, a system with the proper key). When using IPSEC, the messages sent to 224.0.0.1 and 224.0.0.22 should be authenticated using AH. When keying, there are two possibilities:
これらの尺度に加えて、認証ヘッダモードでのIPsecは、IGMPv3メッセージがLAN上のシステムからのシステム（より具体的には適切なキーを有するシステム）から来たことを確認することによって、リモート攻撃から保護するために使用され得る。IPsecを使用する場合、224.0.0.1と224.0.0.22に送信されたメッセージは、AHを使用して認証されるべきです。キーイングの場合、2つの可能性があります。
1. Use a symmetric signature algorithm with a single key for the LAN (or a key for each group). This allows validation that a packet was sent by a system with the key. This has the limitation that any system with the key can forge a message; it is not possible to authenticate the individual sender precisely. It also requires disabling IPSec's Replay Protection.
1. LANの単一キー（または各グループの鍵）で対称署名アルゴリズムを使用してください。これにより、パケットがキーでシステムによって送信されたことを検証できます。これには、キーを持つシステムがメッセージを偽造できるという制限があります。個々の送信者を正確に認証することは不可能です。また、IPsecの再生保護を無効にする必要があります。
2. When appropriate key management standards have been developed, use an asymmetric signature algorithm. All systems need to know the public key of all routers, and all routers need to know the public key of all systems. This requires a large amount of key management but has the advantage that senders can be authenticated individually so e.g., a host cannot forge a message that only routers should be allowed to send.
2. 適切な鍵管理基準が開発された場合は、非対称署名アルゴリズムを使用してください。すべてのシステムはすべてのルーターの公開鍵を知る必要があり、すべてのルーターはすべてのシステムの公開鍵を知る必要があります。これには大量の鍵管理が必要ですが、送信者は個別に認証できるという利点があります。
This solution only directly applies to Query and Leave messages in IGMPv1 and IGMPv2, since Reports are sent to the group being reported and it is not feasible to agree on a key for host-to-router communication for arbitrary multicast groups.
報告されているグループに送信されるグループに送信されるため、このソリューションは直接適用され、任意のマルチキャストグループのためのホスト間通信のためのキーに同意することが不可能であるため、このソリューションはIGMPv1とIGMPv2にメッセージを残します。
All IGMP types described in this document are already assigned in [IANA-REG].
この文書に記載されているすべてのIGMPタイプは、[IANA-REG]にすでに割り当てられています。
We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert, Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for comments and suggestions on this document.
私たちは、Ran Atkinson、Luis Costa、Toerless Eckert、Dino Farinaccci、Serge Fdida、Wilbert de Graaf、Sumit Gupta、Mark Handley、Bob Quinn、Michael Speer、Dave Thaler、Rolland Vidaをコメントや提案のためのRolland Vidaに感謝します。
Portions of the text of this document were copied from [RFC-1112] and [RFC-2236].
この文書のテキストの一部は[RFC-1112]から[RFC-2236]からコピーされました。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[ああ]ケント、S.およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[IANA-REG] http://www.iana.org/assignments/igmp-type-numbers
[RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC-1112] Theering、S.、IPマルチキャストの「ホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC-2113] Katz, D., "IP Router Alert Option," RFC 2113, February, 1997.
[RFC-2113] Katz、D.、「IP Router Alert Option」RFC 2113、1997年2月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] BRADNER、S。、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC-2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC-3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002.
[RFC-3228] Fenner、B.、「IANA検討事項IGMP（Inter Internet Group Management Protocol（IGMP）」、BCP 57、RFC 3228、2002年2月。
[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC-1071] Braden、R.、Borman、D.およびC.パーリッジ、「インターネットチェックサムのコンピューティング」、RFC 1071、1988年9月。
[FILTER-API] Thaler, D., B. Fenner, and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.
[フィルタ-API] Thaler、D.、B.Fenner、B.Quinn、Multicast Source Filtersの「ソケットインタフェース拡張」、進行中の作業。
[SSM] Bhattacharyya, S., et. al., "An Overview of Source-Specific Multicast (SSM)", Work in Progress.
[SSM] Bhattacharyya、S.。「ソース固有のマルチキャスト（SSM）の概要」、進行中の作業。
[MLD] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[MLD] Theering、S.、Fenner、W.およびB. Haberman、「IPv6のMulticast Listener Discovery（MLD）」、RFC 2710、1999年10月。
[MLDV2] Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Work in Progress.
[MLDV2] VIDA、R.、L. Costa、S. Fdida、S.Theering、B.Fenner、I. Kouvelas、B.B.Baberman、「Multicast Listenter Discovery Version 2（MLDV2）は、進行中です。
IGMPv3 specifies two types of Membership Reports: Current-State and State Change. This section describes the rationale for the need for both these types of Reports.
IGMPv3は、現在の状態と状態の変更の2種類の会員報告書を指定します。このセクションでは、これらのレポートの両方を必要とするための根拠について説明します。
Routers need to distinguish Membership Reports that were sent in response to Queries from those that were sent as a result of a change in interface state. Membership reports that are sent in response to Membership Queries are used mainly to refresh the existing state at the router; they typically do not cause transitions in state at the router. Membership Reports that are sent in response to changes in interface state require the router to take some action in response to the received report (see Section 6.4).
ルータは、インターフェイス状態の変更の結果として送信されたものからクエリに応答して送信されたメンバーシップレポートを区別する必要があります。メンバーシップクエリに応答して送信されるメンバーシップレポートは、主にルータで既存の状態を更新するために使用されます。それらは通常、ルータの状態の遷移を引き起こさない。インタフェース状態の変更に応じて送信されるメンバーシップレポートは、受信したレポートに応答してルータが何らかの行動を起こす必要があります（6.4項を参照）。
The inability to distinguish between the two types of reports would force a router to treat all Membership Reports as potential changes in state and could result in increased processing at the router as well as an increase in IGMP traffic on the network.
2つのタイプのレポートを区別できないことは、ルータがすべてのメンバーシップレポートを状態の変化を潜在的な変更として扱うように強制し、ルータでの処理とネットワーク上のIGMPトラフィックの増加をもたらす可能性があります。
In IGMPv1 and IGMPv2, a host would cancel sending a pending membership reports if a similar report was observed from another member on the network. In IGMPv3, this suppression of host membership reports has been removed. The following points explain the reasons behind this decision.
IGMPv1とIGMPv2では、ネットワーク上の他のメンバーから同様の報告が観察された場合、ホストは保留中のメンバーシップレポートを送信することになります。IGMPv3では、このホストメンバーシップレポートのこの抑制は削除されました。次の点は、この決定の背後にある理由を説明しています。
1. Routers may want to track per-host membership status on an interface. This allows routers to implement fast leaves (e.g., for layered multicast congestion control schemes) as well as track membership status for possible accounting purposes.
1. ルータは、インターフェイス上のホストごとのメンバーシップステータスを追跡したい場合があります。これにより、ルータは、可能な会計処理の目的で、高速葉（例えば、積層マルチキャスト輻輳制御方式の場合）を実装することができます。
2. Membership Report suppression does not work well on bridged LANs. Many bridges and Layer2/Layer3 switches that implement IGMP snooping do not forward IGMP messages across LAN segments in order to prevent membership report suppression. Removing membership report suppression eases the job of these IGMP snooping devices.
2. メンバーシップレポート抑制はブリッジLANではうまく機能しません。IGMPスヌーピングを実装する多くのブリッジとLayer2 / Layer3スイッチは、会員レポートの抑制を防ぐためにLANセグメント間でIGMPメッセージを転送しません。メンバーシップレポートの抑制抑制は、これらのIGMPスヌーピングデバイスのジョブを簡単にします。
3. By eliminating membership report suppression, hosts have fewer messages to process; this leads to a simpler state machine implementation.
3. メンバーシップレポートの抑制を排除することで、ホストには処理するメッセージが少なくなります。これにより、より単純な状態機械の実装が可能になります。
4. In IGMPv3, a single membership report now bundles multiple multicast group records to decrease the number of packets sent. In comparison, the previous versions of IGMP required that each multicast group be reported in a separate message.
4. IGMPv3では、単一のメンバーシップレポートでは、送信されたパケットの数を減らすために複数のマルチキャストグループレコードをバンドルします。対照的に、以前のバージョンのIGMPは、各マルチキャストグループが別のメッセージで報告されることを要求されます。
If there exist hosts in both EXCLUDE and INCLUDE modes for a single multicast group in a network, the router must be in EXCLUDE mode as well (see section 6.2.1). In EXCLUDE mode, a router forwards traffic from all sources unless that source exists in the exclusion source list. If all hosts in EXCLUDE mode cease to exist, it would be desirable for the router to switch back to INCLUDE mode seamlessly without interrupting the flow of traffic to existing receivers.
ネットワーク内の単一のマルチキャストグループのモードを除外および含めるホストがある場合、ルータは除外モードにも必要です（セクション6.2.1を参照）。除外モードでは、そのソースが除外元リストに存在しない限り、ルータはすべてのソースからトラフィックを転送します。除外モードのすべてのホストが存在するが存在しない場合、ルータが既存の受信機へのトラフィックの流れを中断することなくシームレスにモードを切り替えることが望ましいであろう。
One of the ways to accomplish this is for routers to keep track of all sources desired by hosts that are in INCLUDE mode even though the router itself is in EXCLUDE mode. If the group timer now expires in EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode on the network (otherwise a membership report from that host would have refreshed the group timer). The router can then switch to INCLUDE mode seamlessly with the list of sources currently being forwarded in its source list.
これを達成する方法の1つは、ルーター自体が除外モードにある場合でも、インクルードモードにあるホストによって必要なすべてのソースを追跡するためのものです。グループタイマが除外モードで有効期限が切れた場合、ネットワーク上の除外モードにホストがないことを意味します（それ以外の場合はそのホストからのメンバーシップレポートはグループタイマを更新しました）。その後、ルータは、ソースリストに現在転送されているソースのリストとシームレスにインクルードモードを切り替えることができます。
While the main additional feature of IGMPv3 is the addition of source filtering, the following is a summary of other changes from RFC 2236.
IGMPv3の主な追加機能はソースフィルタリングの追加ですが、次のことはRFC 2236からの他の変更の概要です。
o State is maintained as Group + List-of-Sources, not simply Group as in IGMPv2.
o 州は、IGMPv2のように単純にグループ化されていないグループリストのソースとして維持されます。
o Interoperability with IGMPv1 and IGMPv2 systems is defined as operations on the IGMPv3 state.
o IGMPv1およびIgMPv2系との相互運用性は、IGMPv3状態の操作として定義されています。
o The IP Service Interface has changed to allow specification of source-lists.
o source-listsの指定を許可するようにIPサービスインタフェースが変更されました。
o The Querier includes its Robustness Variable and Query Interval in Query packets to allow synchronization of these variables on non-Queriers.
o クエリアは、クエリパケット内のその堅牢性変数とクエリ間隔を含み、これらの変数を非クエリエに同期させることを可能にします。
o The Max Response Time in Query messages has an exponential range, changing the maximum from 25.5 seconds to about 53 minutes, for use on links with huge numbers of systems.
o クエリメッセージの最大応答時間には、膨大な数のシステムとのリンクで使用するための最大値が25.5秒から約53分にわたって変更されます。
o Hosts retransmit state-change messages for increased robustness.
o ホストは、堅牢性を高めたために状態変更メッセージを再送信します。
o Additional data sections are defined to allow later extensions.
o 追加のデータセクションは、後で拡張機能を許可するように定義されています。
o Report packets are sent to 224.0.0.22, to assist layer-2 switches in "snooping".
o レポートパケットは224.0.0.22に送られ、「スヌーピング」のレイヤ2スイッチを支援します。
o Report packets can contain multiple group records, to allow reporting of full current state using fewer packets.
o レポートパケットには、より少ないパケットを使用して全電流状態の報告を可能にするために、複数のグループレコードを含めることができます。
o Hosts no longer perform suppression, to simplify implementations and permit explicit membership tracking.
o 実装を簡素化し、明示的なメンバーシップ追跡を許可するために、ホストは抑制を実行しなくなりました。
o New Suppress Router-Side Processing (S) flag in Query messages fixes robustness issues which were also present in IGMPv2.
o クエリメッセージ内の新しい抑制ルータ側処理（S）フラグは、IGMPv2にも存在した堅牢性の問題を修正します。
Authors' Addresses
著者の住所
Brad Cain Cereva Networks
Brad Cain Cerevaネットワーク
Steve Deering Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134-1706
Steve Theering Cisco Systems、Inc。170 Tasman Drive San Jose、CA 95134-1706
Phone: +1-408-527-8213
EMail: deering@cisco.com
Bill Fenner AT&T Labs - Research 75 Willow Rd. Menlo Park, CA 94025
Bill Fenner AT＆T Labs - Research 75 Willow RD。Menlo Park、CA 94025
Phone: +1-650-330-7893
EMail: fenner@research.att.com
Isidor Kouvelas Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134-1706
Isidor Kouvelas Cisco Systems、Inc。170 Tasman Drive San Jose、CA 95134-1706
Phone: +1-408-525-0727
EMail: kouvelas@cisco.com
Ajit Thyagarajan Ericsson IP Infrastructure
AJIT Thyagarajan Ericsson IPインフラストラクチャー
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書と翻訳はコピーされている可能性があり、他の文書にはコピーされ、その実装を説明するか、またはその実装を説明するか、またはその実装を支援することができ、コピーされ、公開され、分散され、すべての種類の制限なしに準備、コピー上記の著作権通知とこの段落がそのようなすべてのコピーや派生的な作品に含まれているとしました。ただし、この文書自体は、インターネット規格を開発するために必要な場合を除き、インターネット社会や他のインターネット組織への参照を削除するなど、著作権社会やその他のインターネット組織への参照を除去することはできません。インターネット標準プロセスに従う必要があるか、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた権限は永続的であり、インターネット社会やその後継者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。