[要約] RFC 2236は、IGMPv2(Internet Group Management Protocol, Version 2)に関する仕様書であり、マルチキャストグループの管理と通信を可能にするプロトコルです。このRFCの目的は、ネットワーク上のホストがマルチキャストグループに参加したり、脱退したりするための標準的な手順を提供することです。

Network Working Group                                            W. Fenner
Request for Comments: 2236                                      Xerox PARC
Updates: 1112                                                November 1997
Category: Standards Track
        

Internet Group Management Protocol, Version 2

インターネットグループ管理プロトコル、バージョン2

Status of this Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (1997). All Rights Reserved.

Copyright(C)The Internet Society(1997)。全著作権所有。

Abstract

概要

This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112.

このメモは、IPホストがマルチキャストグループメンバーシップをルーターに報告するために使用するIGMPv2について説明しています。 STD 5、RFC 1112を更新します。

IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.

IGMPv2を使用すると、グループメンバーシップの終了をルーティングプロトコルにすばやく報告できます。これは、高帯域幅のマルチキャストグループや、揮発性の高いグループメンバーシップを持つサブネットにとって重要です。

This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s).

このドキュメントは、Internet Engineering Task Force内のInter-Domain Multicast Routingワーキンググループの製品です。コメントは募集されており、idmr @ cs.ucl.ac.ukのワーキンググループのメーリングリストや作成者に送信する必要があります。

1. Definitions
1. 定義

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC 2119]で説明されているように解釈されます。

2. Introduction
2. はじめに

The Internet Group Management Protocol (IGMP) is used by IP hosts to report their multicast group memberships to any immediately-neighboring multicast routers. This memo describes only the use of IGMP between hosts and routers to determine group membership. Routers that are members of multicast groups are expected to behave as hosts as well as routers, and may even respond to their own queries. IGMP may also be used between routers, but such use is not specified here.

IPグループはインターネットグループ管理プロトコル(IGMP)を使用して、マルチキャストグループメンバーシップを隣接するマルチキャストルーターに報告します。このメモは、グループメンバーシップを決定するためのホストとルーター間のIGMPの使用のみを説明しています。マルチキャストグループのメンバーであるルーターは、ルーターとしてだけでなくホストとしても動作し、独自のクエリに応答することもできます。 IGMPはルーター間でも使用できますが、そのような使用法はここでは指定しません。

Like ICMP, IGMP is a integral part of IP. It is required to be implemented by all hosts wishing to receive IP multicasts. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. All IGMP messages described in this document are sent with IP TTL 1, and contain the IP Router Alert option [RFC 2113] in their IP header. All IGMP messages of concern to hosts have the following format:

ICMPと同様に、IGMPはIPの不可欠な部分です。 IPマルチキャストの受信を希望するすべてのホストで実装する必要があります。 IGMPメッセージは、IPプロトコル番号2のIPデータグラムにカプセル化されます。このドキュメントで説明するすべてのIGMPメッセージはIP TTL 1で送信され、IPヘッダーにIPルーターアラートオプション[RFC 2113]が含まれます。ホストに関係するすべてのIGMPメッセージの形式は次のとおりです。

    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     | Max Resp Time |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
2.1. Type
2.1. タイプ

There are three types of IGMP messages of concern to the host-router interaction:

ホストとルータの相互作用に関係する3つのタイプのIGMPメッセージがあります。

0x11 = Membership Query There are two sub-types of Membership Query messages: - General Query, used to learn which groups have members on an attached network. - Group-Specific Query, used to learn if a particular group has any members on an attached network.

0x11 =メンバーシップクエリメンバーシップクエリメッセージには、次の2つのサブタイプがあります。-一般的なクエリ。接続されたネットワーク上にメンバーがいるグループを知るために使用されます。 -特定のグループが接続されたネットワーク上にメンバーを持っているかどうかを知るために使用されるグループ固有のクエリ。

These two messages are differentiated by the Group Address, as described in section 1.4 . Membership Query messages are referred to simply as "Query" messages.

セクション1.4で説明されているように、これら2つのメッセージはグループアドレスによって区別されます。メンバーシップクエリメッセージは、単に「クエリ」メッセージと呼ばれます。

   0x16 = Version 2 Membership Report
        
   0x17 = Leave Group
        

There is an additional type of message, for backwards-compatibility with IGMPv1:

IGMPv1との下位互換性のために、追加のタイプのメッセージがあります。

0x12 = Version 1 Membership Report This document refers to Membership Reports simply as "Reports". When no version is specified, the statement applies equally to both versions.

0x12 =バージョン1メンバーシップレポートこのドキュメントでは、メンバーシップレポートを単に「レポート」と呼びます。バージョンが指定されていない場合、ステートメントは両方のバージョンに等しく適用されます。

Unrecognized message types should be silently ignored. New message types may be used by newer versions of IGMP, by multicast routing protocols, or other uses.

認識されないメッセージタイプは無視されます。新しいメッセージタイプは、新しいバージョンのIGMP、マルチキャストルーティングプロトコル、またはその他の用途で使用できます。

2.2. Max Response Time
2.2. 最大応答時間

The Max Response Time field is meaningful only in Membership Query messages, and specifies the maximum allowed time before sending a responding report in units of 1/10 second. In all other messages, it is set to zero by the sender and ignored by receivers.

[最大応答時間]フィールドは、メンバーシップクエリメッセージでのみ意味があり、応答レポートを送信するまでの最大許容時間を1/10秒単位で指定します。他のすべてのメッセージでは、送信者によってゼロに設定され、受信者によって無視されます。

Varying this setting allows IGMPv2 routers to tune the "leave latency" (the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members), as discussed in section 7.8. It also allows tuning of the burstiness of IGMP traffic on a subnet, as discussed in section 7.3.

セクション7.8で説明したように、この設定を変更することで、IGMPv2ルーターは「離脱待ち時間」(最後のホストがグループを離脱してから、ルーティングプロトコルにメンバーがなくなったことが通知されるまでの時間)を調整できます。セクション7.3で説明するように、サブネット上のIGMPトラフィックのバースト性を調整することもできます。

2.3. Checksum
2.3. チェックサム

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 transmitting packets, the checksum MUST be computed and inserted into this field. When receiving packets, the checksum MUST be verified before processing a packet.

チェックサムは、IGMPメッセージ全体(IPペイロード全体)の1の補数合計の16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドはゼロに設定されます。パケットを送信するときは、チェックサムを計算してこのフィールドに挿入する必要があります。パケットを受信するときは、パケットを処理する前にチェックサムを検証する必要があります。

2.4. Group Address
2.4. グループアドレス

In a Membership Query message, the group address field is set to zero when sending a General Query, and set to the group address being queried when sending a Group-Specific Query.

メンバーシップクエリメッセージでは、一般クエリを送信するときにグループアドレスフィールドがゼロに設定され、グループ固有クエリを送信するときにクエリされるグループアドレスに設定されます。

In a Membership Report or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left.

Membership ReportまたはLeave Groupメッセージでは、グループアドレスフィールドに、レポートまたは残されたグループのIPマルチキャストグループアドレスが保持されます。

2.5. Other fields
2.5. その他の分野

Note that IGMP messages may be longer than 8 octets, especially future backwards-compatible versions of IGMP. As long as the Type is one that is recognized, an IGMPv2 implementation MUST ignore anything past the first 8 octets while processing the packet. However, the IGMP checksum is always computed over the whole IP payload, not just over the first 8 octets.

IGMPメッセージは、8オクテットよりも長くなる可能性があることに注意してください。特に、IGMPの将来の下位互換バージョンです。タイプが認識されるタイプである限り、IGMPv2実装は、パケットの処理中に最初の8オクテットを超えるものをすべて無視する必要があります。ただし、IGMPチェックサムは、最初の8オクテットだけでなく、常にIPペイロード全体で計算されます。

3. Protocol Description
3. プロトコルの説明

Note that defaults for timer values are described later in this document. Timer and counter names appear in square brackets.

タイマー値のデフォルトについては、このドキュメントの後半で説明します。タイマーとカウンターの名前は角括弧内に表示されます。

The term "interface" is sometimes used in this document to mean "the primary interface on an attached network"; if a router has multiple physical interfaces on a single network this protocol need only run on one of them. Hosts, on the other hand, need to perform their actions on all interfaces that have memberships associated with them.

このドキュメントでは、「インターフェイス」という用語が「接続されたネットワークのプライマリインターフェイス」を意味する場合があります。ルーターが単一のネットワーク上に複数の物理インターフェイスを備えている場合、このプロトコルはそのうちの1つでのみ実行する必要があります。一方、ホストは、メンバーシップが関連付けられているすべてのインターフェースでアクションを実行する必要があります。

Multicast routers use IGMP to learn which groups have members on each of their attached physical networks. A multicast router keeps a list of multicast group memberships for each attached network, and a timer for each membership. "Multicast group memberships" means the presence of at least one member of a multicast group on a given attached network, not a list of all of the members. With respect to each of its attached networks, a multicast router may assume one of two roles: Querier or Non-Querier. There is normally only one Querier per physical network. All multicast routers start up as a Querier on each attached network. If a multicast router hears a Query message from a router with a lower IP address, it MUST become a Non-Querier on that network. If a router has not heard a Query message from another router for [Other Querier Present Interval], it resumes the role of Querier. Routers periodically [Query Interval] send a General Query on each attached network for which this router is the Querier, to solicit membership information. On startup, a router SHOULD send [Startup Query Count] General Queries spaced closely together [Startup Query Interval] in order to quickly and reliably determine membership information. A General Query is addressed to the all-systems multicast group (224.0.0.1), has a Group Address field of 0, and has a Max Response Time of [Query Response Interval].

マルチキャストルーターはIGMPを使用して、接続されている各物理ネットワークにメンバーがいるグループを学習します。マルチキャストルーターは、接続されている各ネットワークのマルチキャストグループメンバーシップのリストと、各メンバーシップのタイマーを保持しています。 「マルチキャストグループメンバーシップ」とは、すべてのメンバーのリストではなく、特定の接続されたネットワーク上にマルチキャストグループの少なくとも1つのメンバーが存在することを意味します。接続されている各ネットワークに関して、マルチキャストルーターは、クエリアまたは非クエリアの2つの役割のいずれかを引き受けます。通常、物理ネットワークごとにクエリアは1つだけです。すべてのマルチキャストルーターは、接続されている各ネットワークのクエリアとして起動します。マルチキャストルーターがより低いIPアドレスのルーターからクエリメッセージを聞く場合、そのルーターはそのネットワーク上で非クエリャーになる必要があります。ルーターが[Other Querier Present Interval]について別のルーターからのクエリメッセージを聞いていない場合、ルーターはクエリアの役割を再開します。ルーターは定期的に[クエリ間隔]メンバーシップ情報を要求するために、このルーターがクエリアである接続された各ネットワークに一般クエリを送信します。起動時に、ルーターはメンバーシップ情報を迅速かつ確実に決定するために、[Startup Query Count] General Queriesを間隔を空けて[Startup Query Interval]送信する必要があります(SHOULD)。 General Queryは、全システムマルチキャストグループ(224.0.0.1)宛てで、Group Addressフィールドが0で、最大応答時間が[Query Response Interval]です。

When a host receives a General Query, it sets delay timers for each group (excluding the all-systems group) of which it is a member on the interface from which it received the query. Each timer is set to a different random value, using the highest clock granularity available on the host, selected from the range (0, Max Response Time] with Max Response Time as specified in the Query packet. When a host receives a Group-Specific Query, it sets a delay timer to a random value selected from the range (0, Max Response Time] as above for the group being queried if it is a member on the interface from which it received the query. If a timer for the group is already running, it is reset to the random value only if the requested Max Response Time is less than the remaining value of the running timer. When a group's timer expires, the host multicasts a Version 2 Membership Report to the group, with IP TTL of 1. If the host receives another host's Report (version 1 or 2) while it has a timer running, it stops its timer for the specified group and does not send a Report, in order to suppress duplicate Reports.

ホストは、一般クエリを受信すると、クエリを受信したインターフェイスのメンバーである各グループ(全システムグループを除く)に遅延タイマーを設定します。各タイマーは、クエリパケットで指定された最大応答時間の範囲(0、最大応答時間)から選択された、ホストで使用可能な最高のクロック粒度を使用して、異なるランダム値に設定されます。ホストがグループ固有のクエリでは、クエリを受信したインターフェイスのメンバーである場合、クエリ対象のグループについて、上記の範囲(0、最大応答時間)から選択されたランダムな値に遅延タイマーを設定します。グループのタイマーがは既に実行中です。要求された最大応答時間が実行中のタイマーの残りの値よりも小さい場合にのみ、ランダムな値にリセットされます。グループのタイマーが期限切れになると、ホストはIP TTLを使用してバージョン2メンバーシップレポートをグループにマルチキャストしますタイマーの実行中にホストが別のホストのレポート(バージョン1または2)を受信した場合、重複するレポートを抑制するために、指定されたグループのタイマーを停止し、レポートを送信しません。

When a router receives a Report, it adds the group being reported to the list of multicast group memberships on the network on which it received the Report and sets the timer for the membership to the [Group Membership Interval]. Repeated Reports refresh the timer. If no Reports are received for a particular group before this timer has expired, the router assumes that the group has no local members and that it need not forward remotely-originated multicasts for that group onto the attached network.

ルータはレポートを受信すると、レポートを受信したネットワーク上のマルチキャストグループメンバーシップのリストにレポートされているグループを追加し、メンバーシップのタイマーを[Group Membership Interval]に設定します。繰り返しレポートはタイマーを更新します。このタイマーの期限が切れる前に特定のグループのレポートが受信されない場合、ルーターはそのグループにローカルメンバーがなく、そのグループのリモート発信マルチキャストを接続されたネットワークに転送する必要がないと見なします。

When a host joins a multicast group, it should immediately transmit an unsolicited Version 2 Membership Report for that group, in case it is the first member of that group on the network. To cover the possibility of the initial Membership Report being lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to accomplish this is to send the initial Version 2 Membership Report and then act as if a Group-Specific Query was received for that group, and set a timer appropriately).

ホストがマルチキャストグループに参加すると、ネットワーク上のそのグループの最初のメンバーである場合に備えて、そのグループの非請求バージョン2メンバーシップレポートをすぐに送信する必要があります。最初のメンバーシップレポートが失われたり破損したりする可能性をカバーするために、少し遅れて1〜2回繰り返すことをお勧めします[未承諾レポートの間隔]。 (これを行う簡単な方法は、最初のバージョン2メンバーシップレポートを送信し、そのグループのグループ固有のクエリを受信したかのように動作し、タイマーを適切に設定することです)。

When a host leaves a multicast group, if it was the last host to reply to a Query with a Membership Report for that group, it SHOULD send a Leave Group message to the all-routers multicast group (224.0.0.2). If it was not the last host to reply to a Query, it MAY send nothing as there must be another member on the subnet. This is an optimization to reduce traffic; a host without sufficient storage to remember whether or not it was the last host to reply MAY always send a Leave Group message when it leaves a group. Routers SHOULD accept a Leave Group message addressed to the group being left, in order to accommodate implementations of an earlier version of this standard. Leave Group messages are addressed to the all-routers group because other group members have no need to know that a host has left the group, but it does no harm to address the message to the group.

ホストがマルチキャストグループを脱退するとき、それがそのグループのメンバーシップレポートを含むクエリに応答する最後のホストである場合、すべてのルーターのマルチキャストグループ(224.0.0.2)に脱退グループメッセージを送信する必要があります(SHOULD)。クエリに応答する最後のホストではない場合、サブネット上に別のメンバーが存在する必要があるため、何も送信しない場合があります。これは、トラフィックを削減するための最適化です。返信する最後のホストであったかどうかを覚えておくのに十分なストレージがないホストは、グループを脱退するときに常にグループ脱退メッセージを送信する場合があります。ルーターは、この標準の以前のバージョンの実装に対応するために、離脱するグループ宛の離脱グループメッセージを受け入れる必要があります(SHOULD)。他のグループメンバーは、ホストがグループを脱退したことを知る必要はありませんが、グループにメッセージを送信しても害はありません。

When a Querier receives a Leave Group message for a group that has group members on the reception interface, it sends [Last Member Query Count] Group-Specific Queries every [Last Member Query Interval] to the group being left. These Group-Specific Queries have their Max Response time set to [Last Member Query Interval]. If no Reports are received after the response time of the last query expires, the routers assume that the group has no local members, as above. Any Querier to non-Querier transition is ignored during this time; the same router keeps sending the Group-Specific Queries.

クエリアは、受信インターフェイスにグループメンバーがいるグループのグループ離脱メッセージを受信すると、[最後のメンバークエリの数]のグループ固有のクエリを[最後のメンバーのクエリ間隔]ごとに残されたグループに送信します。これらのグループ固有のクエリでは、最大応答時間が[最後のメンバーのクエリ間隔]に設定されています。最後のクエリの応答時間が経過してもレポートが受信されない場合、ルーターは上記のようにグループにローカルメンバーがないと想定します。この間、クエリアから非クエリアへの移行は無視されます。同じルーターがグループ固有のクエリを送信し続けます。

Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD ignore Leave Group messages for which there are no group members on the reception interface.

非クエリアは脱退グループメッセージを無視する必要があり、クエリアは、受信インターフェイスにグループメンバーがいない脱退グループメッセージを無視する必要があります(SHOULD)。

When a non-Querier receives a Group-Specific Query message, if its existing group membership timer is greater than [Last Member Query Count] times the Max Response Time specified in the message, it sets its group membership timer to that value.

非クエリアがグループ固有のクエリメッセージを受信すると、その既存のグループメンバーシップタイマーが[Last Member Query Count]にメッセージで指定された最大応答時間を掛けた値より大きい場合、グループメンバーシップタイマーをその値に設定します。

4. Compatibility with IGMPv1 Routers
4. IGMPv1ルーターとの互換性

An IGMPv2 host may be placed on a subnet where the Querier router has not yet been upgraded to IGMPv2. The following requirements apply:

IGMPv2ホストは、クエリアルーターがまだIGMPv2にアップグレードされていないサブネット上に配置されている可能性があります。次の要件が適用されます。

The IGMPv1 router will send General Queries with the Max Response Time set to 0. This MUST be interpreted as a value of 100 (10 seconds).

IGMPv1ルーターは、最大応答時間を0に設定して一般クエリを送信します。これは、100(10秒)の値として解釈される必要があります。

The IGMPv1 router expects Version 1 Membership Reports in response to its Queries, and will not pay attention to Version 2 Membership Reports. Therefore, a state variable MUST be kept for each interface, describing whether the multicast Querier on that interface is running IGMPv1 or IGMPv2. This variable MUST be based upon whether or not an IGMPv1 query was heard in the last [Version 1 Router Present Timeout] seconds, and MUST NOT be based upon the type of the last Query heard. This state variable MUST be used to decide what type of Membership Reports to send for unsolicited Membership Reports as well as Membership Reports in response to Queries.

IGMPv1ルーターは、クエリへの応答としてバージョン1メンバーシップレポートを想定しており、バージョン2メンバーシップレポートには注意を払いません。したがって、各インターフェイスの状態変数は、そのインターフェイスのマルチキャストクエリアがIGMPv1とIGMPv2のどちらを実行しているかを記述する必要があります。この変数は、最後の[Version 1 Router Present Timeout]秒にIGMPv1クエリが受信されたかどうかに基づく必要があり、最後に受信されたクエリのタイプに基づいてはなりません。この状態変数は、クエリに応答して、非送信請求メンバーシップレポートおよびメンバーシップレポートに送信するメンバーシップレポートのタイプを決定するために使用する必要があります。

An IGMPv2 host MAY suppress Leave Group messages on a network where the Querier is using IGMPv1.

IGMPv2ホストは、クエリアがIGMPv1を使用しているネットワーク上のグループ脱退メッセージを抑制してもよい(MAY)。

An IGMPv2 router may be placed on a subnet where at least one router on the subnet has not yet been upgraded to IGMPv2. The following requirements apply:

IGMPv2ルーターは、サブネット上の少なくとも1つのルーターがまだIGMPv2にアップグレードされていないサブネット上に配置できます。次の要件が適用されます。

If any IGMPv1 routers are present, the querier MUST use IGMPv1. The use of IGMPv1 must be administratively configured, as there is no reliable way of dynamically determining whether IGMPv1 routers are present on a network. Implementations MAY provide a way for system administrators to enable the use of IGMPv1 on their routers; in the absence of explicit configuration, the configuration MUST default to IGMPv2. When in IGMPv1 mode, routers MUST send Periodic Queries with a Max Response Time of 0, and MUST ignore Leave Group messages. They SHOULD also warn about receiving an IGMPv2 query, although such warnings MUST be rate-limited.

IGMPv1ルーターが存在する場合、クエリアはIGMPv1を使用する必要があります。 IGMPv1ルーターがネットワーク上に存在するかどうかを動的に決定する信頼できる方法がないため、IGMPv1の使用は管理上構成する必要があります。実装は、システム管理者がルーターでIGMPv1の使用を有効にする方法を提供する場合があります。明示的な設定がない場合、設定はデフォルトでIGMPv2にする必要があります。 IGMPv1モードの場合、ルーターは最大応答時間が0の定期クエリを送信する必要があり、Leave Groupメッセージを無視する必要があります。それらはまた、IGMPv2クエリの受信について警告する必要がありますが、そのような警告はレート制限されている必要があります。

If a router is not explicitly configured to use IGMPv1 and hears an IGMPv1 Query, it SHOULD log a warning. These warnings MUST be rate-limited.

ルーターがIGMPv1を使用するように明示的に構成されておらず、IGMPv1クエリを聞く場合、警告をログに記録する必要があります(SHOULD)。これらの警告はレート制限されている必要があります。

5. Compatibility with IGMPv1 Hosts
5. IGMPv1ホストとの互換性

An IGMPv2 host may be placed on a subnet where there are hosts that have not yet been upgraded to IGMPv2. The following requirement applies:

IGMPv2ホストは、まだIGMPv2にアップグレードされていないホストがあるサブネット上に配置できます。次の要件が適用されます。

The host MUST allow its Membership Report to be suppressed by either a Version 1 Membership Report or a Version 2 Membership Report.

ホストは、そのメンバーシップレポートがバージョン1メンバーシップレポートまたはバージョン2メンバーシップレポートによって抑制されることを許可する必要があります。

An IGMPv2 router may be placed on a subnet where there are hosts that have not yet been upgraded to IGMPv2. The following requirements apply:

IGMPv2にまだアップグレードされていないホストが存在するサブネット上に、IGMPv2ルーターを配置できます。次の要件が適用されます。

If a router receives a Version 1 Membership Report, it MUST set a timer to note that there are version 1 hosts present which are members of the group for which it heard the report. This timer should be the same as the [Group Membership Interval].

ルータがバージョン1メンバーシップレポートを受信する場合、タイマーを設定して、レポートを聞いたグループのメンバーであるバージョン1ホストが存在することを通知する必要があります。このタイマーは、[Group Membership Interval]と同じである必要があります。

If there are version 1 hosts present for a particular group, a router MUST ignore any Leave Group messages that it receives for that group.

特定のグループにバージョン1のホストが存在する場合、ルーターは、そのグループに対して受信するLeave Groupメッセージを無視する必要があります。

6. Host State Diagram
6. ホストの状態図

Host behavior is more formally specified by the state transition diagram below. A host may be in one of three possible states with respect to any single IP multicast group on any single network interface:

ホストの動作は、以下の状態遷移図でより正式に指定されています。ホストは、単一のネットワークインターフェイス上の単一のIPマルチキャストグループに関して、次の3つの状態のいずれかになります。

- "Non-Member" state, when the host does not belong to the group on the interface. This is the initial state for all memberships on all network interfaces; it requires no storage in the host.

- 「非メンバー」状態、ホストがインターフェース上のグループに属していない場合。これは、すべてのネットワークインターフェイスのすべてのメンバーシップの初期状態です。ホストにストレージは必要ありません。

- "Delaying Member" state, when the host belongs to the group on the interface and has a report delay timer running for that membership.

- 「Delaying Member」状態。ホストがインターフェース上のグループに属しており、そのメンバーシップに対してレポート遅延タイマーが実行されている場合。

- "Idle Member" state, when the host belongs to the group on the interface and does not have a report delay timer running for that membership.

- 「アイドルメンバー」状態。ホストがインターフェース上のグループに属しており、そのメンバーシップに対して実行中のレポート遅延タイマーがない場合。

There are five significant events that can cause IGMP state transitions:

IGMP状態遷移を引き起こす可能性のある5つの重要なイベントがあります。

- "join group" occurs when the host decides to join the group on the interface. It may occur only in the Non-Member state.

- 「グループに参加」は、ホストがインターフェイス上のグループに参加することを決定したときに発生します。非メンバー状態でのみ発生する可能性があります。

- "leave group" occurs when the host decides to leave the group on the interface. It may occur only in the Delaying Member and Idle Member states.

- 「グループの脱退」は、ホストがインターフェイス上のグループを脱退することを決定したときに発生します。遅延メンバーとアイドルメンバーの状態でのみ発生する可能性があります。

- "query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query). A General Query applies to all memberships on the interface from which the Query is received. A Group-Specific Query applies to membership in a single group on the interface from which the Query is received. Queries are ignored for memberships in the Non-Member state.

- 「クエリ受信」は、ホストが有効な一般メンバーシップクエリメッセージまたは有効なグループ固有のメンバーシップクエリメッセージを受信したときに発生します。クエリメッセージが有効であるためには、8オクテット以上で、正しいIGMPチェックサムが必要です。 IGMPヘッダーのグループアドレスは、ゼロ(一般クエリ)または有効なマルチキャストグループアドレス(グループ固有クエリ)でなければなりません。一般クエリは、クエリの受信元であるインターフェイスのすべてのメンバーシップに適用されます。グループ固有のクエリは、クエリを受信したインターフェイス上の単一グループのメンバーシップに適用されます。非メンバー状態のメンバーシップのクエリは無視されます。

- "report received" occurs when the host receives a valid IGMP Membership Report message (Version 1 or Version 2). To be valid, the Report message must be at least 8 octets long and have a correct IGMP checksum. A Membership Report applies only to the membership in the group identified by the Membership Report, on the interface from which the Membership Report is received. It is ignored for memberships in the Non-Member or Idle Member state.

- 「レポート受信」は、ホストが有効なIGMPメンバーシップレポートメッセージ(バージョン1またはバージョン2)を受信したときに発生します。有効であるためには、レポートメッセージの長さが8オクテット以上で、正しいIGMPチェックサムが必要です。メンバーシップレポートは、メンバーシップレポートの受信元のインターフェイスで、メンバーシップレポートによって識別されるグループのメンバーシップにのみ適用されます。非メンバーまたはアイドルメンバー状態のメンバーシップでは無視されます。

- "timer expired" occurs when the report delay timer for the group on the interface expires. It may occur only in the Delaying Member state.

- 「timer expired」は、インターフェイス上のグループのレポート遅延タイマーが期限切れになったときに発生します。遅延メンバー状態でのみ発生する可能性があります。

All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states.

無効なIGMPメッセージの受信や、クエリまたはレポート以外のIGMPメッセージなど、他のすべてのイベントは、すべての状態で無視されます。

There are seven possible actions that may be taken in response to the above events:

上記のイベントに対応して実行できるアクションは7つあります。

- "send report" for the group on the interface. The type of report is determined by the state of the interface. The Report Message is sent to the group being reported.

- インターフェイス上のグループの「レポートを送信」。レポートのタイプは、インターフェースの状態によって決まります。レポートメッセージは、レポートされるグループに送信されます。

- "send leave" for the group on the interface. If the interface state says the Querier is running IGMPv1, this action SHOULD be skipped. If the flag saying we were the last host to report is cleared, this action MAY be skipped. The Leave Message is sent to the ALL-ROUTERS group (224.0.0.2).

- インターフェイス上のグループの「休暇を送る」。インターフェースの状態で、クエリアがIGMPv1を実行していることが示されている場合、このアクションはスキップする必要があります(SHOULD)。私たちが最後に報告したホストであるというフラグがクリアされている場合、このアクションはスキップされる場合があります。 LeaveメッセージはALL-ROUTERSグループ(224.0.0.2)に送信されます。

- "set flag" that we were the last host to send a report for this group.

- このグループにレポートを送信する最後のホストである「フラグを設定」。

- "clear flag" since we were not the last host to send a report for this group.

- このグループにレポートを送信した最後のホストではないため、「フラグをクリア」します。

- "start timer" for the group on the interface, using a delay value chosen uniformly from the interval (0, Max Response Time], where Max Response time is specified in the Query. If this is an unsolicited Report, the timer is set to a delay value chosen uniformly from the interval (0, [Unsolicited Report Interval] ].

- 間隔(0、最大応答時間)から一律に選択された遅延値を使用して、インターフェース上のグループの「タイマーを開始」します。最大応答時間はクエリで指定されます。これが非送信請求レポートの場合、タイマーは間隔(0、[Unsolicited Report Interval]]から均一に選択された遅延値。

- "reset timer" for the group on the interface to a new value, using a delay value chosen uniformly from the interval (0, Max Response Time], as described in "start timer".

- 「タイマーの開始」で説明されているように、間隔(0、最大応答時間)から一律に選択された遅延値を使用して、インターフェイス上のグループの「タイマーをリセット」して新しい値にします。

- "stop timer" for the group on the interface.

- インターフェイス上のグループの「タイマーの停止」。

In all of the following state diagrams, each state transition arc is labeled with the event that causes the transition, and, in parentheses, any actions taken during the transition. Note that the transition is always triggered by the event; even if the action is conditional, the transition still occurs.

以下のすべての状態図では、各状態遷移アークには、遷移を引き起こすイベント、および括弧内に、遷移中に行われたアクションがラベル付けされています。遷移は常にイベントによってトリガーされることに注意してください。アクションが条件付きであっても、遷移は発生します。

                              ________________
                             |                |
                             |                |
                             |                |
                             |                |
                   --------->|   Non-Member   |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  | leave group       | join group       | leave group
                  | (stop timer,      |(send report,     | (send leave
                  |  send leave if    | set flag,        |  if flag set)
                  |  flag set)        | start timer)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |                    |                 |
         |                 |<-------------------|                 |
         |                 |   query received   |                 |
         | Delaying Member |    (start timer)   |   Idle Member   |
    ---->|                 |------------------->|                 |
   |     |                 |   report received  |                 |
   |     |                 |    (stop timer,    |                 |
   |     |                 |     clear flag)    |                 |
   |     |_________________|------------------->|_________________|
   | query received    |        timer expired
   | (reset timer if   |        (send report,
   |  Max Resp Time    |         set flag)
   |  < current timer) |
    -------------------
        

The all-systems group (address 224.0.0.1) is handled as a special case. The host starts in Idle Member state for that group on every interface, never transitions to another state, and never sends a report for that group.

all-systemsグループ(アドレス224.0.0.1)は、特殊なケースとして処理されます。ホストは、すべてのインターフェイスでそのグループのアイドルメンバー状態で開始し、別の状態に遷移したり、そのグループのレポートを送信したりすることはありません。

In addition, a host may be in one of two possible states with respect to any single network interface:

さらに、ホストは、単一のネットワークインターフェイスに関して、次の2つの状態のいずれかになる可能性があります。

- "No IGMPv1 Router Present", when the host has not heard an IGMPv1 style query for the [Version 1 Router Present Timeout]. This is the initial state.

- 「No IGMPv1 Router Present」、ホストが[Version 1 Router Present Timeout]のIGMPv1スタイルのクエリを聞いていない場合。これが初期状態です。

- "IGMPv1 Router Present", when the host has heard an IGMPv1 style query within the [Version 1 Router Present Timeout].

- 「IGMPv1ルーター存在」、ホストが[バージョン1ルーター存在タイムアウト]内にIGMPv1スタイルのクエリを受信した場合。

There are two events that can cause state transitions:

状態遷移を引き起こす可能性のある2つのイベントがあります。

- "IGMPv1 query received", when the host receives a query with the Max Response Time field set to 0.

- 「IGMPv1クエリを受信しました」、ホストが最大応答時間フィールドを0に設定してクエリを受信した場合。

- "timer expires", when the timer set to note the presence of an IGMPv1 router expires.

- 「timer expires」、IGMPv1ルーターの存在を通知するように設定されたタイマーが期限切れになった場合。

And a single action that can be triggered by an event:

そして、イベントによってトリガーできる単一のアクション:

- "set timer", setting the timer to its maximum value [Version 1 Router Present Timeout] and (re)starting it.

- 「タイマーの設定」、タイマーを最大値に設定し[バージョン1ルーター存在タイムアウト]、(再)起動します。

                              ________________
                             |                |
                             |                |
                             |   No IGMPv1    |
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |                |    |
                       |     |________________|    |
         timer expires |                           | IGMPv1 query
                       |      ________________     | received
                       |     |                |    | (set timer)
                       |     |                |    |
                       |     |                |    |
                        -----|     IGMPv1     |<---
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |________________|    |
                       |                           |
                       | IGMPv1 query received     |
                       | (set timer)               |
                        ---------------------------
        
7. Router State Diagram
7. ルーター状態図

Router behavior is more formally specified by the state transition diagrams below.

ルーターの動作は、以下の状態遷移図でより正式に指定されています。

A router may be in one of two possible states with respect to any single attached network:

ルーターは、接続されている単一のネットワークに関して、次の2つの状態のいずれかになります。

- "Querier", when this router is designated to transmit IGMP Membership Queries on this network.

- 「クエリア」、このルーターがこのネットワークでIGMPメンバーシップクエリを送信するように指定されている場合。

- "Non-Querier", when there is another router designated to transmit IGMP membership Queries on this network.

- 「Non-Querier」、このネットワーク上でIGMPメンバーシップクエリを送信するように指定された別のルーターがある場合。

The following three events can cause the router to change states:

次の3つのイベントにより、ルーターの状態が変化する可能性があります。

- "query timer expired" occurs when the timer set for query transmission expires.

- 「クエリタイマーの期限切れ」は、クエリの送信に設定されたタイマーが期限切れになったときに発生します。

- "query received from a router with a lower IP address" occurs when an IGMP Membership Query is received from a router on the same network with a lower IP address.

- 「低いIPアドレスのルーターから受信したクエリ」は、同じネットワーク上のルーターから低いIPアドレスのルーターからIGMPメンバーシップクエリを受信したときに発生します。

- "other querier present timer expired" occurs when the timer set to note the presence of another querier with a lower IP address on the network expires.

- 「その他のクエリア存在タイマーの期限が切れました」は、ネットワーク上でより低いIPアドレスを持つ別のクエリアの存在を記録するように設定されたタイマーが期限切れになったときに発生します。

There are three actions that may be taken in response to the above events:

上記のイベントに応じて実行できるアクションは3つあります。

- "start general query timer" for the attached network.

- 接続されたネットワークの「一般クエリタイマーを開始」します。

- "start other querier present timer" for the attached network [Other Querier Present Interval].

- 接続されているネットワークの[他のクエリア存在タイマーを開始する] [他のクエリア存在間隔]。

- "send general query" on the attached network. The General Query is sent to the all-systems group (224.0.0.1), and has a Max Response Time of [Query Response Interval].

- 接続されたネットワークで「一般クエリを送信」し​​ます。 General Queryは、全システムグループ(224.0.0.1)に送信され、最大応答時間は[Query Response Interval]です。

                                      --------------------------------
                              _______|________  gen. query timer      |
  ---------                  |                |        expired        |
 | Initial |---------------->|                | (send general query,  |
  ---------  (send gen. q.,  |                |  set gen. q. timer)   |
        set initial gen. q.  |                |<----------------------
              timer)         |    Querier     |
                             |                |
                        -----|                |<---
                       |     |                |    |
                       |     |________________|    |
 query received from a |                           | other querier
 router with a lower   |                           | present timer
 IP address            |                           | expired
 (set other querier    |      ________________     | (send general
  present timer)       |     |                |    |  query,set gen.
                       |     |                |    |  q. timer)
                       |     |                |    |
                        ---->|      Non       |----
                             |    Querier     |
                             |                |
                             |                |
                        ---->|                |----
                       |     |________________|    |
                       | query received from a     |
                       | router with a lower IP    |
                       | address                   |
                       | (set other querier        |
                       |  present timer)           |
                        ---------------------------
        

A router should start in the Initial state on all attached networks, and immediately move to Querier state.

ルーターは、接続されているすべてのネットワークで初期状態で起動し、すぐにクエリア状態に移行する必要があります。

In addition, to keep track of which groups have members, a router may be in one of four possible states with respect to any single IP multicast group on any single attached network:

さらに、どのグループにメンバーがあるかを追跡するために、ルーターは、単一の接続されたネットワーク上の単一のIPマルチキャストグループに関して、4つの可能な状態のいずれかになります。

- "No Members Present" state, when there are no hosts on the network which have sent reports for this multicast group. This is the initial state for all groups on the router; it requires no storage in the router.

- このマルチキャストグループのレポートを送信したホストがネットワーク上にない場合、「メンバーが存在しない」状態。これは、ルーター上のすべてのグループの初期状態です。ルータにストレージは必要ありません。

- "Members Present" state, when there is a host on the network which has sent a Membership Report for this multicast group.

- このマルチキャストグループのメンバーシップレポートを送信したホストがネットワーク上にある場合、「メンバーが存在する」状態。

- "Version 1 Members Present" state, when there is an IGMPv1 host on the network which has sent a Version 1 Membership Report for this multicast group.

- このマルチキャストグループのバージョン1メンバーシップレポートを送信したIGMPv1ホストがネットワーク上にある場合、「バージョン1メンバーが存在する」状態。

- "Checking Membership" state, when the router has received a Leave Group message but has not yet heard a Membership Report for the multicast group.

- 「Checking Membership」状態。ルータがLeave Groupメッセージを受信したが、マルチキャストグループのメンバーシップレポートをまだ聞いていない場合。

There are six significant events that can cause router state transitions:

ルータの状態遷移を引き起こす可能性のある6つの重要なイベントがあります。

- "v2 report received" occurs when the router receives a Version 2 Membership Report for the group on the interface. To be valid, the Report message must be at least 8 octets long and must have a correct IGMP checksum.

- 「v2レポートの受信」は、ルーターがインターフェース上のグループのバージョン2メンバーシップレポートを受信したときに発生します。有効であるためには、レポートメッセージの長さが8オクテット以上で、正しいIGMPチェックサムが必要です。

- "v1 report received" occurs when the router receives a Version 1 Membership report for the group on the interface. The same validity requirements apply.

- 「v1レポートの受信」は、ルーターがインターフェース上のグループのバージョン1メンバーシップレポートを受信したときに発生します。同じ有効性要件が適用されます。

- "leave received" occurs when the router receives an IGMP Group Leave message for the group on the interface. To be valid, the Leave message must be at least 8 octets long and must have a correct IGMP checksum.

- 「leave received」は、ルータがインターフェイス上のグループのIGMP Group Leaveメッセージを受信したときに発生します。有効にするには、Leaveメッセージの長さが8オクテット以上で、正しいIGMPチェックサムが必要です。

- "timer expired" occurs when the timer set for a group membership expires.

- 「timer expired」は、グループメンバーシップに設定されたタイマーが期限切れになったときに発生します。

- "retransmit timer expired" occurs when the timer set to retransmit a group-specific Membership Query expires.

- 「再送信タイマーの期限切れ」は、グループ固有のメンバーシップクエリを再送信するように設定されたタイマーが期限切れになったときに発生します。

- "v1 host timer expired" occurs when the timer set to note the presence of version 1 hosts as group members expires.

- 「v1ホストタイマーの期限切れ」は、グループメンバーが期限切れになるときにバージョン1ホストの存在を記録するようにタイマーが設定されている場合に発生します。

There are six possible actions that may be taken in response to the above events:

上記のイベントに対応して実行できるアクションは6つあります。

- "start timer" for the group membership on the interface - also resets the timer to its initial value [Group Membership Interval] if the timer is currently running.

- インターフェイス上のグループメンバーシップの「タイマーを開始」-タイマーが現在実行中の場合は、タイマーを初期値[グループメンバーシップ間隔]にリセットします。

- "start timer*" for the group membership on the interface - this alternate action sets the timer to [Last Member Query Interval] * [Last Member Query Count] if this router is a Querier, or the [Max Response Time] in the packet * [Last Member Query Count] if this router is a non-Querier.

- インターフェイス上のグループメンバーシップの「タイマーの開始」-この代替アクションは、このルーターがクエリアである場合、タイマーを[最後のメンバーのクエリ間隔] * [最後のメンバーのクエリ数]に設定するか、パケットの[最大応答時間] * [最後のメンバーのクエリ数]このルーターが非クエリである場合。

- "start retransmit timer" for the group membership on the interface [Last Member Query Interval].

- インターフェイスのグループメンバーシップの「再送信タイマーの開始」[Last Member Query Interval]。

- "start v1 host timer" for the group membership on the interface, also resets the timer to its initial value [Group Membership Interval] if the timer is currently running.

- インターフェイスのグループメンバーシップの「v1ホストタイマーを開始」は、タイマーが現在実行中の場合、タイマーを初期値[グループメンバーシップ間隔]にもリセットします。

- "send group-specific query" for the group on the attached network. The Group-Specific Query is sent to the group being queried, and has a Max Response Time of [Last Member Query Interval].

- 接続されたネットワーク上のグループに対する「グループ固有のクエリを送信する」。グループ固有のクエリは、クエリ対象のグループに送信され、最大応答時間は[最後のメンバーのクエリ間隔]になります。

- "notify routing +" notify the routing protocol that there are members of this group on this connected network.

- 「ルーティングの通知+」は、この接続されたネットワーク上にこのグループのメンバーがいることをルーティングプロトコルに通知します。

- "notify routing -" notify the routing protocol that there are no longer any members of this group on this connected network.

- 「ルーティングの通知-」は、この接続されたネットワーク上にこのグループのメンバーがなくなったことをルーティングプロトコルに通知します。

The state diagram for a router in Querier state follows:

クエリア状態のルーターの状態図は次のとおりです。

                              ________________
 ----------------------------|                |<-----------------------
|                            |                |timer expired           |
|               timer expired|                |(notify routing -,      |
|          (notify routing -)|   No Members   |clear rxmt tmr)         |
|                    ------->|    Present     |<-------                |
|                   |        |                |       |                |
|v1 report rec'd    |        |                |       |  ------------  |
|(notify routing +, |        |________________|       | | rexmt timer| |
| start timer,      |                    |            | |  expired   | |
| start v1 host     |  v2 report received|            | | (send g-s  | |
|  timer)           |  (notify routing +,|            | |  query,    | |
|                   |        start timer)|            | |  st rxmt   | |
|         __________|______              |       _____|_|______  tmr)| |
|        |                 |<------------       |              |     | |
|        |                 |                    |              |<----- |
|        |                 | v2 report received |              |       |
|        |                 | (start timer)      |              |       |
|        | Members Present |<-------------------|    Checking  |       |
|  ----->|                 | leave received     |   Membership |       |
| |      |                 | (start timer*,     |              |       |
| |      |                 |  start rexmt timer,|              |       |
| |      |                 |  send g-s query)   |              |       |
| |  --->|                 |------------------->|              |       |
| | |    |_________________|                    |______________|       |
| | |v2 report rec'd |  |                          |                   |
| | |(start timer)   |  |v1 report rec'd           |v1 report rec'd    |
| |  ----------------   |(start timer,             |(start timer,      |
| |v1 host              | start v1 host timer)     | start v1 host     |
| |tmr    ______________V__                        | timer)            |
| |exp'd |                 |<----------------------                    |
|  ------|                 |                                           |
|        |    Version 1    |timer expired                              |
|        | Members Present |(notify routing -)                         |
 ------->|                 |-------------------------------------------
         |                 |<--------------------
 ------->|_________________| v1 report rec'd     |
| v2 report rec'd |   |   (start timer,          |
| (start timer)   |   |    start v1 host timer)  |
 -----------------     --------------------------
        

The state diagram for a router in Non-Querier state is similar, but non-Queriers do not send any messages and are only driven by message reception.Note that non-Queriers do not care whether a Membership Report message is Version 1 or Version 2.

Non-Querier状態のルーターの状態図も同様ですが、非Queriesはメッセージを送信せず、メッセージ受信によってのみ駆動されます。Queer以外は、Membership Reportメッセージがバージョン1であるかバージョン2であるかを気にしません。 。

                              ________________
                             |                |
                             |                |
                timer expired|                |timer expired
           (notify routing -)|   No Members   |(notify routing -)
                   --------->|    Present     |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  |                   |report received   |
                  |                   |(notify routing +,|
                  |                   | start timer)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |  report received   |                 |
         |                 |  (start timer)     |                 |
         | Members Present |<-------------------|     Checking    |
         |                 | g-s query rec'd    |    Membership   |
         |                 | (start timer*)     |                 |
    ---->|                 |------------------->|                 |
   |     |_________________|                    |_________________|
   | report received |
   | (start timer)   |
    -----------------
        
8. List of timers and default values
8. タイマーとデフォルト値のリスト

Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all routers on a single link. Note that parentheses are used to group expressions to make the algebra clear.

これらのタイマーのほとんどは構成可能です。デフォルト以外の設定を使用する場合、それらは単一リンク上のすべてのルーター間で一貫している必要があります。括弧は代数を明確にするために式をグループ化するために使用されることに注意してください。

8.1. Robustness Variable
8.1. ロバストネス変数

The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet 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は(Robustness Variable-1)パケット損失に対してロバストです。ロバストネス変数は0であってはならず、1であってはなりません。デフォルト:2

8.2. Query Interval
8.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 subnet; larger values cause IGMP Queries to be sent less often.

[クエリ間隔]を変更することにより、管理者はサブネット上のIGMPメッセージの数を調整できます。値が大きいほど、IGMPクエリの送信頻度が低くなります。

8.3. Query Response Interval
8.3. クエリ応答間隔

The Max Response Time inserted into the periodic General Queries. Default: 100 (10 seconds)

定期的な一般クエリに挿入される最大応答時間。デフォルト:100(10秒)

By varying the [Query Response Interval], an administrator may tune the burstiness of IGMP messages on the subnet; 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].

[Query Response Interval]を変更することにより、管理者はサブネット上のIGMPメッセージのバースト性を調整できます。ホストの応答がより大きな間隔で分散されるため、値が大きいほどトラフィックのバースト性が低くなります。 [Query Response Interval]で表される秒数は、[Query Interval]未満である必要があります。

8.4. Group Membership Interval
8.4. グループメンバーシップの間隔

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 on a network. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).

グループメンバーシップ間隔は、マルチキャストルーターがネットワーク上のグループのメンバーがこれ以上存在しないと判断するまでに経過する必要がある時間です。この値は、((ロバストネス変数)倍(クエリ間隔))に(1つのクエリ応答間隔)を足したものでなければなりません。

8.5. Other Querier Present Interval
8.5. その他のクエリアの存在間隔

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).

Other Querier Present Intervalは、マルチキャストルータがクエリアとなる別のマルチキャストルータが存在しないと判断するまでに経過する必要がある時間の長さです。この値は、((ロバストネス変数)倍(クエリ間隔))プラス(1つのクエリ応答間隔の半分)でなければなりません。

8.6. Startup Query Interval
8.6. 起動クエリ間隔

The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval.

スタートアップクエリ間隔は、起動時にクエリアによって送信される一般的なクエリ間の間隔です。デフォルト:クエリ間隔の1/4。

8.7. Startup Query Count
8.7. スタートアップクエリ数

The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable.

スタートアップクエリ数は、スタートアップ時に送信されるクエリの数で、スタートアップクエリ間隔で区切られます。デフォルト:ロバストネス変数。

8.8. Last Member Query Interval
8.8. 最後のメンバーのクエリ間隔

The Last Member Query Interval is the Max Response Time inserted into Group-Specific Queries sent in response to Leave Group messages, and is also the amount of time between Group-Specific Query messages. Default: 10 (1 second)

Last Member Query Intervalは、Leave Groupメッセージへの応答として送信されるGroup-Specificクエリに挿入される最大応答時間であり、Group-Specific Queryメッセージ間の時間でもあります。デフォルト:10(1秒)

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.

この値を調整して、ネットワークの「脱退待ち時間」を変更できます。値を小さくすると、グループの最後のメンバーの喪失を検出する時間が短くなります。

8.9. Last Member Query Count
8.9. 最後のメンバーのクエリ数

The Last Member Query Count is the number of Group-Specific Queries sent before the router assumes there are no local members. Default: the Robustness Variable.

Last Member Query Countは、ルーターがローカルメンバーがないと想定する前に送信されるグループ固有のクエリの数です。デフォルト:ロバストネス変数。

8.10. Unsolicited Report Interval
8.10. 非送信請求レポートの間隔

The Unsolicited Report Interval is the time between repetitions of a host's initial report of membership in a group. Default: 10 seconds.

Unsolicited Report Intervalは、グループのメンバーシップに関するホストの初期レポートを繰り返す間の時間です。デフォルト:10秒。

8.11. Version 1 Router Present Timeout
8.11. バージョン1ルーター存在タイムアウト

The Version 1 Router Present Timeout is how long a host must wait after hearing a Version 1 Query before it may send any IGMPv2 messages. Value: 400 seconds.

バージョン1ルーター存在タイムアウトは、ホストがバージョン1クエリを聞いた後、IGMPv2メッセージを送信するまでに待機する必要がある時間です。値:400秒。

9. Message destinations
9. メッセージの宛先

This information is provided elsewhere in the document, but is summarized here for convenience.

この情報は、ドキュメントの他の場所で提供されていますが、便宜上ここにまとめられています。

   Message Type                  Destination Group
   ------------                  -----------------
   General Query                 ALL-SYSTEMS (224.0.0.1)
   Group-Specific Query          The group being queried
   Membership Report             The group being reported
   Leave Message                 ALL-ROUTERS (224.0.0.2)
        

Note: in older (i.e., non-standard and now obsolete) versions of IGMPv2, hosts send Leave Messages to the group being left. A router SHOULD accept Leave Messages addressed to the group being left in the interests of backwards compatibility with such hosts. In all cases, however, hosts MUST send to the ALL-ROUTERS address to be compliant with this specification.

注:IGMPv2の古い(つまり、非標準で現在は使用されていない)バージョンでは、ホストは離脱するグループにLeaveメッセージを送信します。ルータは、そのようなホストとの下位互換性のために、残されているグループ宛てのLeaveメッセージを受け入れる必要があります(SHOULD)。ただし、すべての場合において、ホストはこの仕様に準拠するためにALL-ROUTERSアドレスに送信する必要があります。

10. Security Considerations
10. セキュリティに関する考慮事項

We consider the ramifications of a forged message of each type.

各タイプの偽造メッセージの影響について検討します。

Query Message:

クエリメッセージ:

A forged Query message from a machine with a lower IP address than the current Querier will cause Querier duties to be assigned to the forger. If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. During this time, if the forger ignores Leave Messages, traffic might flow to groups with no members for up to [Group Membership Interval].

現在のクエリアよりもIPアドレスが低いマシンからの偽のクエリメッセージにより、クエリアの職務が偽者に割り当てられます。その後、偽造者がクエリメッセージを送信しなくなった場合、他のルーターのその他のクエリア存在タイマーがタイムアウトし、クエリアの役割を再開します。この間、偽造者がメッセージを残すを無視した場合、トラフィックはメンバーのないグループに最大[グループメンバーシップ間隔]まで流れる可能性があります。

A forged Query message sent to a group with members will cause the hosts which are members of the group to report their memberships. This causes a small amount of extra traffic on the LAN, but causes no protocol problems.

メンバーを持つグループに送信された偽造クエリメッセージにより、グループのメンバーであるホストがメンバーシップを報告します。これにより、LANに少量の余分なトラフィックが発生しますが、プロトコルの問題は発生しません。

Report messages:

レポートメッセージ:

A forged Report message may cause multicast routers to think there are members of a group on a subnet when there are not. Forged Report messages from the local subnet 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:

偽造されたレポートメッセージにより、マルチキャストルーターはサブネット上にグループのメンバーが存在しないと見なす場合があります。ローカルサブネットからの偽造レポートメッセージは意味がありません。通常、ホスト上のグループへの参加は特権のない操作であるため、ローカルユーザーはメッセージを偽造せずに同じ結果を得る可能性があります。外部ソースからの偽造レポートメッセージはより厄介です。外部で偽造されたレポートに対する防御策は2つあります。

- Ignore the Report 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 Reports sent by mobile hosts without addresses on the local subnet will be ignored.

- パケットの送信元アドレスが、パケットが受信されたインターフェイスに割り当てられたサブネットに属していると識別できない場合は、レポートを無視してください。このソリューションは、ローカルサブネット上のアドレスなしでモバイルホストによって送信されたレポートが無視されることを意味します。

- 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 earlier versions of this specification which did not require Router Alert.

- ルーターアラートオプションのないレポートメッセージを無視し[RFC 2113]、ルーターがレポートメッセージを転送しないように要求します。 (この要件は、パケットにルーターアラートオプションが既に含まれているため、転送パスでの一般化されたフィルタリングの要件ではありません)。このソリューションは、ルーターアラートを必要としないこの仕様の以前のバージョンの実装との下位互換性を壊します。

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]. There are two defenses against forged v1 Reports:

偽造されたバージョン1レポートメッセージは、ルーターを特定のグループの「バージョン1メンバーが存在する」状態にする可能性があります。つまり、ルーターはLeaveメッセージを無視します。これにより、[グループメンバーシップ間隔]まで、メンバーのないグループにトラフィックが流れる可能性があります。偽造されたv1レポートに対する防御策は2つあります。

- To defend against externally sourced v1 Reports, ignore the Report 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 v1 Reports sent by mobile hosts without addresses on the local subnet will be ignored.

- 外部からのv1レポートを防御するには、パケットの送信元アドレスが、パケットが受信されたインターフェイスに割り当てられたサブネットに属していると識別できない場合は、レポートを無視してください。このソリューションは、ローカルサブネット上のアドレスなしでモバイルホストによって送信されたv1レポートが無視されることを意味します。

- Provide 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. This solution protects against forged version 1 reports from the local subnet as well.

- バージョン1のメッセージを完全に無視する構成スイッチをルーターに提供します。これはバージョン1ホストとの自動互換性を損なうため、「高速脱退」が重要な状況でのみ使用する必要があります。このソリューションは、ローカルサブネットからの偽造バージョン1レポートからも保護します。

Leave message:

メッセージを残す:

A forged Leave message will cause the Querier to send out 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 Leave messages:

偽造されたLeaveメッセージにより、クエリアは問題のグループのグループ固有のクエリを送信します。これにより、各ルーターおよびグループの各メンバーで追加の処理が発生しますが、必要なトラフィックが失われることはありません。外部で作成されたLeaveメッセージに対する2つの防御策があります。

- Ignore the Leave 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 Leave messages sent by mobile hosts without addresses on the local subnet will be ignored.

- パケットの送信元アドレスを、パケットを受信したインターフェイスに割り当てられたサブネットに属しているものとして識別できない場合は、Leaveメッセージを無視してください。このソリューションは、ローカルサブネット上のアドレスなしでモバイルホストによって送信されたLeaveメッセージが無視されることを意味します。

- Ignore Leave messages without Router Alert options [RFC 2113], and require that routers not forward Leave 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 earlier versions of this specification which did not require Router Alert.

- ルータアラートオプションなしのLeaveメッセージを無視し[RFC 2113]、ルータがLeaveメッセージを転送しないように要求します。 (この要件は、パケットにルーターアラートオプションが既に含まれているため、転送パスでの一般化されたフィルタリングの要件ではありません)。このソリューションは、ルーターアラートを必要としないこの仕様の以前のバージョンの実装との下位互換性を壊します。

11. Acknowledgments
11. 謝辞

IGMPv2 was designed by Rosen Sharma and Steve Deering.

IGMPv2は、Rosen SharmaとSteve Deeringによって設計されました。

12. References
12. 参考文献

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 2113 Katz, D., "IP Router Alert Option," RFC 2113, February 1997.

RFC 2113 Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。

RFC 1112 Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

RFC 1112 Deering、S。、「Host Extensions for IP Multicasting」、STD 5、RFC 1112、1989年8月。

13. Appendix I - Changes from IGMPv1
13. 付録I-IGMPv1からの変更

The IGMPv1 "Version" and "Type" fields are combined into a single "Type" field.

IGMPv1の「バージョン」および「タイプ」フィールドは、単一の「タイプ」フィールドに結合されます。

A new IGMP Type is assigned to Version 2 Membership Report messages, so a router may tell the difference between an IGMPv1 and IGMPv2 host report.

新しいIGMPタイプがバージョン2メンバーシップレポートメッセージに割り当てられるため、ルーターはIGMPv1とIGMPv2のホストレポートの違いを知ることができます。

A new IGMP Type is created for the IGMPv2 Leave Group message.

IGMPv2 Leave Groupメッセージ用に新しいIGMPタイプが作成されます。

The Membership Query message is changed so that a previously unused field contains a new value, the Max Response Time.

Membership Queryメッセージが変更され、以前に使用されなかったフィールドに新しい値である最大応答時間が含まれるようになりました。

The IGMPv2 spec now specifies a querier election mechanism. In IGMPv1, the querier election was left up to the multicast routing protocol, and different protocols used different mechanisms. This could result in more than one querier per network, so the election mechanism has been standardized in IGMPv2. However, this means that care must be taken when an IGMPv2 router is trying to coexist with an IGMPv1 router that uses a different querier election mechanism. In particular, it means that an IGMPv2 router must be able to act as an IGMPv1 router on a particular network if configured to do so. The actions required include:

IGMPv2仕様は、クエリア選択メカニズムを指定するようになりました。 IGMPv1では、クエリア選択はマルチキャストルーティングプロトコルに任され、プロトコルごとに異なるメカニズムが使用されていました。これにより、ネットワークごとに複数のクエリアが発生する可能性があるため、選択メカニズムはIGMPv2で標準化されています。ただし、これは、IGMPv2ルーターが異なるクエリア選択メカニズムを使用するIGMPv1ルーターと共存しようとする場合は注意が必要であることを意味します。特に、IGMPv2ルーターが構成されている場合、特定のネットワーク上でIGMPv1ルーターとして機能できる必要があります。必要なアクションは次のとおりです。

- Set the Max Response Time field to 0 in all queries.

- すべてのクエリで[最大応答時間]フィールドを0に設定します。

- Ignore Leave Group messages.

- Leave Groupメッセージを無視します。

The IGMPv2 spec relaxes the requirements on validity-checking for Membership Queries and Membership Reports. When upgrading an implementation, be sure to remove any checks that do not belong.

IGMPv2仕様では、メンバーシップクエリとメンバーシップレポートの有効性チェックの要件が緩和されています。実装をアップグレードするときは、属していないチェックを必ず削除してください。

The IGMPv2 spec requires the presence of the IP Router Alert option [RFC 2113] in all packets described in this memo.

IGMPv2仕様では、このメモに記載されているすべてのパケットにIPルーターアラートオプション[RFC 2113]が存在する必要があります。

14. Author's Address
14. 著者のアドレス

William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: +1 650 812 4816

William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto、CA 94304電話:+1 650 812 4816

   EMail: fenner@parc.xerox.com
        
15. 完全な著作権表示

Copyright (C) The Internet Society (1997). All Rights Reserved.

Copyright(C)The Internet Society(1997)。全著作権所有。

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。