Network Working Group W. Fenner Request for Comments: 2236 Xerox PARC Updates: 1112 November 1997 Category: Standards Track Internet Group Management Protocol, Version 2 |IGMP Version 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. |このドキュメントはインターネットコミュニティに対してインターネット |スタンダードトラックプロトコルを規定し、 改善のための議論や提案を |要求するものである。このプロトコルの状態と標準化の状況については、 |"Internet Official Protocol Standards"(STD 1) の最新版を参照のこと。 |このメモの配布に制限はない。 Copyright Notice |著作権表示 Copyright (C) The Internet Society (1997). All Rights Reserved. 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, RFC1112のアップデートである。 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). |このドキュメントは IETF( Internet Engineering Task Force )の IDMR |(Inter-Domain Multicast Routing)作業グループの成果である。コメント |を募集しており、作業グループのメーリングリスト idmr@cs.ucl.ac.uk |及び/又は 著者に申し出てもらいたい。 1. Definitions |定義 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" は RFC2119 での説明で解釈される。 2. Introduction |はじめに 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. |IGMP ( Internet Group Management Protocol ) は、IPホストによって、 |それらが、マルチキャストグループのメンバであることを、直接に接続 |されたマルチキャストルータに対して報告するために使用される。この |メモは、グループのメンバを決定するために、ホストとルータ間で使用 |される 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 Router Alert オプション[RFC 2133]を |そのIPヘッダの中に含む。ホストに関する全ての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 |タイプ There are three types of IGMP messages of concern to the host- router interaction: |ホストルータで、相互に関係するIGMPのメッセージには3つのタイプがある。 0x11 = Membership Query |メンバー問い合わせ There are two sub-types of Membership Query messages: |Membership Query メッセージには2つのサブタイプがある。 - General Query, used to learn which groups have members on an attached network. |General Query, 接続されたネットワークで、(1以上の)グループの |持つメンバを知るために使用される。 - Group-Specific Query, used to learn if a particular group has any members on an attached network. |Group-Specific Query, 接続されたネットワークで、個々の |グループの持つメンバを知るために使用される。 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.4章の誤り】で記述するように、 これら2つのメッ |セージは 、グループアドレスによって記述される。 Membership |Query メッセージは単に "Query" メッセージと呼ばれる。 0x16 = Version 2 Membership Report |バージョン2 メンバーレポート 0x17 = Leave Group |グループ離脱 There is an additional type of message, for backwards-compatibility with IGMPv1: |次は、IGMPv1との過去互換のために、追加されたメッセージである。 0x12 = Version 1 Membership Report |バージョン2 メンバーレポート This document refers to Membership Reports simply as "Reports". When no version is specified, the statement applies equally to both versions. |このドキュメントでは、Membership Report の事を単に "Report" と |呼ぶ。バージョンの記述がない場合、記述は両方のバージョンに同じ |く適用される。 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 |最大応答時間 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. |Max Response Time フィールドは Membership Query メッセージの時にだけ |意味を持ち、応答レポートの送信に許容される(待ち)時間を、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章【訳注:8.8章の誤り】で議論するように、この設定の変更はIGMPv2 |ルータで "leave latency (潜在離脱時間)" (最後のホストがグループを |去った時刻と、ルーティングプロトコルが、 もうメンバがいないことに |気づいた時刻との差)を調整するために許容される。さらに 7.3 章 【訳 |注:8.3章の誤り】で記述されるように、サブネットでのIGMPトラフィッ |クのバースト性のために調整することが許容される。 2.3. Checksum |チェックサム 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の補数である。チェックサムの計算のためのチェック |サムフィールドは 0 に設定される。パケット送信時、チェックサムは計算 |されてこのフィールドにいれなければならない(MUST)。パケット受信時、 |チェックサムはパケットを処理する前に確認しなければならない(MUST)。 2.4. Group Address |グループアドレス 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. |Membership Queryメッセージでは、General Query 送信時に、グループ |アドレスフィールドには 0 が設定され、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 |その他のフィールド 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メッセージは、特にIGMPの将来の後方互換を考え、8オクテットよりも |長くてもよいことに注意すること。 タイプが認められるものである限り、 |IGMPv2 の実装は、 パケットを処理するのに、最初の8オクテットをこえる |いかなるものも無視しなければならない(MUST)。しかしIGMP チェックサム |は、最初の8オクテットだけではなく、常にIPのペイロード間が計算される。 3. Protocol Description |プロトコルの記述 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つと考えてよい: Querier (/ Query送信ルータ) 又は Non-Querier |(/ Query非送信ルータ)。通常、Querierは物理的なネットワーク毎に一 |つだけ存在する。 すべてのマルチキャストルータは、それぞれの物理 |ネットワークで、Querier として立ち上がる。もしマルチキャストルー |タが、より低い IPアドレスを持つルータからの Query メッセージを聞 |いたならば、そのネットワークにおいて (ルータは) Non-Querier にな |らなければならない(MUST)。もしルータが他のルータから[Other Querier | Present Interval ]の間 Query を聞かなければ、そのルータは Querier |の役割を続行する。ルータは[Query Interval]で定期的に、このルータ |が Querier になっている接続されたインタフェースそれぞれに General | Query をメンバ情報を求めるために送信する。 起動時に、ルータは素 |早くそして確実にメンバ情報を決定するために、互いに正確に [Startup | Query Interval] の間隔で [Startup Query Count]の General Queryを |送信すべきである(SHOULD)。General Query は全てのシステムのマルチ |キャストグループ(224.0.0.1)に対して Group Address フィールドが 0 |で、Max Response Timeフィールドが [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. |ホストが General Query を受信したならば、 Query を受信したインタ |フェースの、メンバのそれぞれのグループ (全システムグループを除く)の |それぞれに対して遅延タイマを設定する。 それぞれのタイマは、ホストで |可能な最も高いクロックの精度を利用して Query パケットに示されている |Max Response Timeの範囲(0 から Max Response Time)から選択した異なる |乱数が設定される。 ホストが Group-Specific Query を受信し、それが |Query を受信したインタフェースのメンバであるならば、グループのQuery |のために、上のようにして、範囲 ( 0 から Max Response Time) から選択 |した乱数を遅延タイマに設定する。 もしタイマが既に作動しているならば、 |要求された Max Response Time が、作動中のタイマの残りの値よりも小さ |い時に限り乱数を再設定する。 グループのタイマが時間切れになった時に |は、ホストはグループに向けて IPのTTLを 1として、Version 2 Membership | Report をマルチキャストする。 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. |ルータが Report を受信したならば、Report が受信されたネットワーク |のマルチキャストグループメンバのリストに、 レポートされたグループ |を追加し、メンバ用タイマを [Group Membership Interval] に設定する。 |繰り返される Reportはタイマをリフレッシュする。もし、このタイマが |時間切れになる前に、 特定のグループからの Report の受信がなければ、 |ルータは、 そのグループがローカルメンバを持ってなく、 接続された |ネットワーク上のグループへ、他で生成されたマルチキャスト(パケット) |を転送する必要がないと考える。 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). |ホストがマルチキャストグループに参加する時、それが、そのネットワー |クにおいて、そのグループの最初のメンバであった場合、そのグループに |対して自発的に Version 2 Membership Report を直ちに送信すべきで |ある。最初の Membership Report が失われたり、壊れたりする可能性を |カバーするために、 [Unsolicited Report Interval]で少し遅らせた後に、 |一、二度、再送することを推奨する。( これを達成するための簡単な方法 |は、最初の Version 2 Membership Reportを送信して、そのグループから |Group-Specific Query を受信したかのように振舞い、そして、適切にタ |イマを設定することである。) 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. |ホストがマルチキャストグループから離脱する場合、もしそれが、その |グループに Membership Report で Query に応答した最後のホストなら |ば、全ルータマルチキャストグループ(224.0.0.2)に Leave Group メッ |セージを送るべきである。もし Query に応答した最後のホストでなけ |れば、 サブネットの他に存在するメンバに対して何も送らなくてよい |(MAY)。これは、トラフィックを減少させるためのオプションである; |応答した最後のホストであるか否かを記憶するための十分な記憶装置が |ないホストの場合、グループから去る時に、常に Leave Groupメッセー |ジを送信してもよい(MAY)。 ルータはこの標準よりも古いバージョンの |実装を許容するために(他にルータが)残っているグループに向かっての、 |Leave Group メッセージを許容する。Leave Group メッセージは全ルー |タグループに向けられる、なぜなら、他のグループメンバはホストがグ |ループから離脱したことを知る必要はないが、 そのグループへのメッ |セージの発信は有害ではないためである。 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. |Querier が(メッセージを)受け取ったインタフェースにおいて、グループ |メンバをもつグループへの Leave Group メッセージを受信した時、[Last |Member Query Count]回の Group-Specific Queriesを[Last Member Query | Interval]毎に、残ったグループの(メンバ)に向かって送信する。これら |の Group-Specific Queriesは Max Response 時間に [Last Member Query |Interval] を設定する。もし、最後に Query を完了したものの応答時間の |後になっても Reportが受信できなかった場合、ルータはそれ以上、グルー |プはローカルメンバを持っていないとみなす。この間 non-Querier に向け |てのいかなる Querier の送信も無視される; そのルータは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. |Non-QuerierはLeave Groupメッセージを無視しなければならない(MUST)、 |そして Querier は (メッセージを)受け取ったインタフェースにおいて、 |グループメンバがいない Leave Group メッセージを無視すべきである |(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. |non-Querierが Group-Specific Queryメッセージを受信した時、もし |メッセージに記述された、 [ Last Member Query Count ] 倍の Max |Response Time よりも、存在するグループメンバタイマの方が大きけ |れば、その値を、そのグループメンバタイマにセットする。 4. Compatibility with IGMPv1 Routers |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 にアップグレードされていない Querier |ルータのあるサブネットに置く事ができる。(これには)以下の実装が要求 |される: 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ルータは Max Response Time を 0 に設定して、General |Query を送信するであろう。これを100 (10秒) の値として解釈 |しなければならない(MUST)。 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ルータは、その Query の応答として、Version 1 Membership |Report を期待し、Version 2 Membership Report に注意を払わない。 |それゆえ、マルチキャスト Querier がそのインタフェースで IGMPv1 |又は IGMPv2 のどちらであるかを記述するための状態変数をそれぞれ |のインタフェース毎に保持しなければならない(MUST)。 この変数は |最近[Version 1 Router Present Timeout]秒以内に、IGMPv1の問い合 |わせを聞いたか否かを基準にしなければならず(MUST)、最後に聞いた、 |Query を基準にしてはならない(MUST NOT)。この状態変数は、Query |に対する応答の Membership Reports と同様、自発的な Membership |Reports のタイプを決定するために、使用しなければならない(MUST)。 An IGMPv2 host MAY suppress Leave Group messages on a network where the Querier is using IGMPv1. |IGMPv2 ホストは、IGMPv1 を使用する Query のネットワークにおいて |Leave Group メッセージは抑止すべきである(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 ルータが存在するならば、Query は IGMPv1 を |使用しなければならない(MUST)。 IGMPv1 の使用は、ネットワークに |IGMPv1ルータが存在するか否かを動的に決定する信頼できる方法がな |いならば、手動で設定しなければならない。実装では、これらのルー |タに IGMPv1 の使用を可能にするための方法をシステム管理者に提供 |すべきである[MAY];明確な設定がない場合、設定は IGMPv2 を デフ |ォルトにしなければならない[MUST]。IGMPv1モード時、ルータは 0の | Max Response Time の Periodic(周期的な)Query を送信しなければ |ならず(MUST)、Leave Group メッセージを無視しなければならない。 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 Query |を聞いたならば、警告を記録すべきである(SHOULD)。これらの警告は |レート制限しなければならない(MUST)。 5. Compatibility with IGMPv1 Hosts |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. |そのホストは Version 1 Membership Report か Version 2 Membership |Report のどちらででも、 Membership Report を抑止することを可能に |しなければならない(MUST)。 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: |IGMP ルータは、まだ 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]. |もしルータが Version 1 Membership Report を受信したならば、 |レポートを聞いたグループのメンバで、バージョン1のホストが |存在することを記録するタイマを設定しなければならない(MUST)。 |このタイマは [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 |ホスト状態図 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: |ホストのふるまいは、 以下の状態遷移図によって、より正確に記述される。 |ホストは、いかなる1つのネットワークインタフェースにおいて、いかなる |1つのIPマルチキャストグループに関しても、3つのおこりうる状態の1つに |なるであろう。 - "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. |"Non-Member(非メンバ)"状態、ホストがインタフェースのそのグループ |に属していない時である。これは全てのネットワークインタフェースに |おいて、全てのメンバの初期状態である;これはホストに記憶容量を要 |求しない。 - "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. |"Idle Member (アイドルメンバ)"状態、ホストがそのインタフェースの |メンバに属しており、そのメンバに対してレポート遅延タイマを動作さ |せていない時である。 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. |"join group(グループ加入)"は、ホストがそのインタフェースのグループ |に加入することを決定した時に発生する。これは Non-Member 状態の時に |のみ発生するであろう。 - "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. |"leave group(グループ離脱)"は、ホストがそのインタフェースのグ |ループから離脱することを決定した時に発生する。これは Delaying |Member 状態と Idle Member 状態の時にのみ発生するであろう。 - "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. |"query receiverd(Query受信)"は、妥当な General Membership Query |メッセージあるいは、妥当な Group-Specific Membership Query メッ |セージのどちらかを受信した時に発生する。妥当であるためには Query |メッセージは少なくとも8オクテットの長さを持ち、正しいIGMP チェッ |クサムを持っていなければならない。IGMPヘッダのグループアドレスは、 |ゼロ(General Queryの場合)又は妥当なマルチキャストアドレス (Group- |Specific Query の場合)でなければならない。 General Query は Query |が受信されたインタフェース全てのメンバに提供される。Group-Specific | Query は Query が受信されたインタフェースの1つのグループのメンバ |に適用される。Query は Non-Member状態のメンバには無視される。 - "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. |"repoprt received(レポート受信)"は、妥当な IGMP Membership Report |( バージョン1 又は バージョン2 )を受信した時に発生する。妥当である |ためには、Report メッセージは、少なくとも8オクテットの長さを持ち、 |正しい IGMP チェックサムを持っていなければならない。 Membership |Reportは、その Membership Reportが受信されたインタフェースにおいて、 |その Membership Report によって識別されるグループのメンバにだけ適用 |される。これは Non-Member あるいは Idle Member 状態のメンバには無視 |される。 - "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(タイマ満了)"は、インタフェース上のグループのレポート |遅延タイマが満了した時に発生する。これは、 Delaying Member 状態の時 |のみ発生する。 All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states. |他のすべてのイベント、例えば不正な IGMP メッセージや、Query 又は |Report 以外の 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 report(レポート送信)"。 |レポートのタイプはインタフェースの状態によって決定される。Report |メッセージはレポートされているグループに向けて送信される。 - "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). |インタフェースのグループに対する、"send leave(離脱メッセージ送信)"。 |インタフェース状態が、IGMPv1 が起動している Querier であることを示 |しているならば、この動作はスキップすべきである(SHOULD)。レポートし |た最後のホストであることを示すフラグがクリアされていれば、この動作 |はスキップすることができる(MAY)。 Leave Message は全ルータグループ |(224.0.0.2)に向けて送信される。 - "set flag" that we were the last host to send a report for this group. |このグループに対して、レポートを最後に送信したホストであることを |示す"set flag(フラグ設定)"。 - "clear flag" since we were not the last host to send a report for this group. |このグループ対して、レポートを最後に送信したホストでないことを |示す"clear flag(フラグ解除)"。 - "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] ]. |このインタフェースのグループに対する"start timer(タイマ起動)"。 |これは Query に記述された Max Response time で、間隔 (0, Max |Response Time)から均等に選んだ値が使用される。もしこれが、期待 |されていない Report であるならば、間隔(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". |"start timer"に記述した、間隔 (0, [Max Response Time])から均等に |選ばれた遅延値を使用して、インタフェースのグループに対して新しい |値を(設定する)"reset timer(タイマ再設定)"。 - "stop timer" for the group on the interface. |インタフェースのグループに対する、"stop timer(タイマ停止)"。 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. |全システムグループ(アドレス 224.0.0.1)は、特別なケースとして扱われる。 |インタフェース毎で、そのグループのホストは Idle Member 状態で始まり、 |他の状態には決して遷移しなく、さらに、そのグループに対してレポートも |決して送信しない。 In addition, a host may be in one of two possible states with respect to any single network interface: |加えて、どのような1インタフェースに関しても、2つのとりうる状態の |うちの1つとなるであろう。 - "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(IGMPv1ルータ存在せず)"、 ホストが、 |[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 Router Present(IGMPv1ルータ存在)"、ホストが[Version 1 |Router Present Timeout]の間に、IGMPv1 スタイルの Queryを聞いて |いる時。 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 query received(IGMPv1 Query 受信)"、Max Response | Time フィールドが、0 に設定された Query を受信した時。 - "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. |"set timer(タイマ設定)"、最大値[Version 1 Router Present |Timeout]をタイマに設定して、(再)始動する。 ________________ | | | | | No IGMPv1 | | Router | | Present | | | ---->| |---- | | | | | |________________| | timer expires | | IGMPv1 query | ________________ | received | | | | (set timer) | | | | | | | | -----| IGMPv1 |<--- | Router | | Present | | | ---->| |---- | |________________| | | | | IGMPv1 query received | | (set timer) | --------------------------- 7. Router State Diagram |ルータ状態図 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: |ルータは、いかなる1つの接続されたネットワークに関しても、2つの |とりうる状態の1つになるであろう。 - "Querier", when this router is designated to transmit IGMP Membership Queries on this network. |"Querier"、ルータが、このネットワークで IGMP Membership Queries |を送信するよう、指名された時。 - "Non-Querier", when there is another router designated to transmit IGMP membership Queries on this network. |"Non-Querier"、このネットワークに IGMP Membership Queries を |送信することを指名された、他のルータがある時。 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 timer expired (Query Timer 満了)"は、Query 送信の |ために設定したタイマが満了した時に発生する。 - "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. |"query received from a router with a lower IP address( Query |をより低いIPアドレスを持つルータから受信)"は、同じネットワー |クで、より低い IPアドレスを持つルータからの、IGMP Membership |Query を受信した時に発生する。 - "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. |"other querier present timer expired( Other Querier Present |Timer の満了)"は、そのネットワークでより低いIPアドレスを持つ、 |他の Querier の存在を記録するために設定されたタイマが満了した |時に発生する。 There are three actions that may be taken in response to the above events: | 上のイベントの応答として取られる、3つの動作がある。 - "start general query timer" for the attached network. |接続されたネットワークへの"start general query timer (General | Query Timer 起動)"。 - "start other querier present timer" for the attached network [Other Querier Present Interval]. |接続されたネットワークへの [Other Querier Present Interval] の、 |"start other querier present timer(Other Querier Present Timerの |起動)"。 - "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]. |接続されたネットワークへの "send general query (General Queryの |送信)"。General Query は、全システムグループ(224.0.0.1)に向けて |送信され、[Query Response Interval] の Max Respons Time を持つ。 -------------------------------- _______|________ 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. |ルータは全ての接続されたネットワークで、Initial 状態で開始され、 |そして、すぐに Querier 状態に移動する。 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: |加えて、メンバを持つグループの記録を残すためにルータはいかなる |1 つの接続されたネットワークの、 いかなる1つのIPマルチキャスト |グループに関しても、4つのおこりうる状態の1つになるであろう: - "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. |"No Members Present(メンバ非存在)" 状態、 このマルチキャスト |グループで、レポートを送信するネットワークに対してホストがな |い時。これはルータの全てのグループの初期状態である;ルータに |記憶容量を要求しない。 - "Members Present" state, when there is a host on the network which has sent a Membership Report for this multicast group. |"Members Present(メンバ存在)"状態。このマルチキャストグループに |おいて、Membership Reportを送信するネットワークに、ホストが存在 |する時。 - "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. |"Version 1 Members Present(バージョン1メンバ存在)状態、このマルチ |キャストグループにおいて、 ネットワークで Version 1 Membership |Report を送信する IGMPv1 ホストが存在する時。 - "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 |メッセージを受信したが、まだ、そのマルチキャストグループに |対しての Membership Report を聞いていない場合。 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 report received(v2レポート受信)"は、そのインタフェースで、 |そのグループの Version 2 Membership Report を受信した時に発生 |する。有効であるためには、Report メッセージは少なくとも 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 report received(v1レポート受信)" は、そのインタフェースで |そのグループの Version 1 Membership Report を受信した時に発生 |する。(v2と)同じ有効な条件を適用する。 - "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 |グループの Leave Message を受信した時に発生する。有効である |ためには、Report メッセージは少なくとも 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. |"retransmit timer expired(再送タイマ満了)"は、group-specific | Membership Query 再送のために設定したタイマが満了した時に、 |発生する。 - "v1 host timer expired" occurs when the timer set to note the presence of version 1 hosts as group members expires. |"v1 host timer expired(v1ホストタイマ満了)"は、グループメンバに |バージョン1の存在を記録するために設定されたタイマが満了した時に |発生する。 There are six possible actions that may be taken in response to the above events: |上のイベントの応答して取られる、3つの動作がある。 - "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(タイマ起動)" |- これはまた、もしタイマが現在既に稼働しているならば、 その初期値 |[Group Membership Interval]にタイマを再設定する。 - "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 timer*(タイマ起動*)" |この代替動作は、タイマを、このルータが Querier であるならば、[Last |Member Query Interval] * [Last Member Query Count] に、 あるいは、 |このルータが non-Querier であれば、 パケットに記述されている [Max |Response Time] * [Last Member Query Count] に設定する。 - "start retransmit timer" for the group membership on the interface [Last Member Query Interval]. |インタフェースのグループメンバーのために [Last Member Query | Interval] で "start retransmit timer(再送タイマ起動)" - "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. |インタフェースのグループメンバのための"start v1 host timer(v1 |ホストタイマ起動)"、 これはまた、タイマが現在既に稼働している |ならば、その初期値[Group Membership Interval]にタイマを再設定 |する。 - "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]. |接続されたネットワークのグループに対する "send group-specific | query (Qroup-Specific Query送信)"。Group-Specific Query は、 |[Last Member Query Interval] の Max Response Time を持って、 |問い合わせるグループに向けて送信される。 - "notify routing +" notify the routing protocol that there are members of this group on this connected network. |"notify routing +(ルーティング通知+)" は この接続されたネット |ワークに、このグループのメンバが存在することをルーティングプロ |トコルに通知する。 - "notify routing -" notify the routing protocol that there are no longer any members of this group on this connected network. |"notify routing -(ルーティング通知−)" は この接続されたネット |ワークに、このグループのメンバが存在しないことをルーティングプ |ロトコルに通知する。 The state diagram for a router in Querier state follows: |Querier 状態でのルータの状態図を以下に示す。 ________________ ----------------------------| |<----------------------- | | |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状態のルータの状態図は同じである、しかし non-Querier |は、いかなるメッセージは送信せず、メッセージの受けつけにより移動 |するだけである。non-Querier は、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 |タイマのリストとデフォルトの値 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. |これらのほとんどのタイマは設定変更可能である。もしデフォルト以外の |設定を使用するならば、それらは 1つのリンクにおいて、全てのルータ間 |で一貫していなければならない。代数学的に明確にするために、数式をグ |ループ化するために丸括弧が使用されていることに注意。 8.1. Robustness Variable |信頼性変数 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 |Robustness Variable は、サブネットで、予測されたパケットロスを調整する |ことを可能にする。サブネットがよりロスすると予想されるならば Robustness | Variable は増加させられる。IGMPはパケットロスを(Robustness Variable-1) |とする。 Robustness Variable はゼロにしてはならず(MUST NOT)、1 にすべき |ではない(SHOULD NOT)。デフォルト: 2 8.2. Query Interval |Query 間隔 The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds. | Query Intervalは、Querier によって General Queries を送信する間隔 |である。デフォルト: 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. |[Query Interval]の変更によって、管理者はサブネットでの IGMPの |メッセージ数を調整してもよい;より大きな値は、IGMP Queries を |たびたび送ることを減らす。 8.3. Query Response Interval |Quey 応答間隔 The Max Response Time inserted into the periodic General Queries. Default: 100 (10 seconds) |Max Response Time(最大応答時間) は 周期的な General Query に |挿入される。デフォルト: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 |グループメンバ間隔 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). |Group Membership Interval は、マルチキャストルータがもうそれ以上 |ネットワークのグループにメンバーがないと決定するまでにかかる時間 |の合計である。この値は((Robustness Variable)*(Query Interval)) |+ (Query Response Interval)でなければならない(MUST)。 8.5. Other Querier Present Interval |(他 Querier 存在(確認)間隔 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 は 他にもはや Querier になるマルチ |キャストルータが存在しないことを、マルチキャストルータが判断する |までにかかる時間の長さである。この値は ((Robustness Variable) * | (Query Interval) + Query Response Interval / 2) でなければならな |い。 8.6. Startup Query Interval |起動 Query 間隔 The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval. |Startup Query Interval は起動時に Querier によって送信される |General Queries の間隔である。デフォルト: Query Interval / 4 8.7. Startup Query Count |起動 Query 回数 The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable. |Startup Query Count は Startup Query Interval 刻みで、起動時に |送出される Query の数である。デフォルト:Robustness Variable 8.8. Last Member Query Interval |最終メンバ Query 間隔 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 Queries 送信時にいれられる Max Response Time であ |り、Group-Specific Query メッセージ間の時間の合計【訳注:すなわち |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. |この値はネットワークの "leave latency"の変更のために調整される。 |値の減少は、グループの最後のメンバーが消滅したことをを検出する |時間を減少させる結果を生む。 8.9. Last Member Query Count |最終メンバ Query 回数 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 は ルータがローカルメンバーがないと考える |までに、Group-Specific Queries を送信する回数である。デフォルト: |Robustness Variable 8.10. Unsolicited Report Interval |自発的 Report 間隔 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 はグループのメンバーのホストの最初の |Report を受け取るまでの時間である。デフォルト: 10秒 8.11. Version 1 Router Present Timeout |バージョン 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. |Version 1 Router Present Timeoutはいかなる IGMPv2 メッセージを |送信する前に、Version 1 Query を聞くまで、ホストが待たなければ |ならない時間の長さである。 9. Message destinations |メッセージの宛先 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 Message を送信 |する。ルータは過去互換のために、そのようなホストから残されたグ |ループに対して送られる Leave Messages を許容すべきである。しか |しながら、 全てのケースで、ホストはこの仕様に従って、 全ルータ |アドレス宛に送信しなければならない。 10. Security Considerations |セキュリティに関する考察 We consider the ramifications of a forged message of each type. |我々は、タイプ毎の偽造されたメッセージを細かく考える。 Query Message: |Query メッセージ 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]. |現在の Querier よりも低いIPアドレスを持つマシンからの、偽造された |Query メッセージは、 Querier がその偽造者に、義務を割り当ててしまう |要因となる。もし偽造者がそれ以降、それ以上の Query メッセージを送信 |しなければ、他のルータの Other Querier Present タイマがタイムアウト |して、一つ(のルータ)が Querier の役割を再開する。この間もし偽造者が |Leave Message を無視するならば、 トラフィックは [ Group Membership |Interval] まで、メンバのないグループに対して流れるかもしれない。 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. |メンバのいるグループに対して送信される、偽造された Queryメッ |セージは、グループのメンバであるホストに、それらのメンバを報告 |させる原因となる。 これは LAN で、余分なトラフィックを少し発生 |させるが、プロトコルの問題は発生しない。 Report messages: |Report メッセージ 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: |偽造された Report は、マルチキャストルータに、サブネットのグループ |にメンバがいない時に、そのメンバーがいると思わせる要因となるであろう。 |ローカルなサブネットからの偽造された Report メッセージは、グループ |にホストを追加することが、通常、非特権的な操作であるので、無意味であ |り、ローカルユーザは、偽造したこのようなメッセージがなくても、同じ |結果を平凡に得ることができる。外部ソースからの偽造されたメッセージ |は、より面倒である。外部からの偽造された Report に対して 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. |パケットのソースアドレスが、パケットが受信されたインタフェースに |割り当てたサブネットに属することを認証できなかったならば、Report |を無視する。この解決方法は、Report がローカルサブネットのアドレス |を持たない移動ホストによって送られたレポートを無視することを意味 |する。 - 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. |Router Alert オプション[RFC 2113]なしの Report メッセージを無視し、 |ルータが Report メッセージを転送しないことを要求する。(この要求は |転送パスに汎用のフィルタの実装を要求しない、 なぜならパケットは既 |にその中に、Router Alert オプションを持っているためである)。 この |解決は、 Router Alert を必要としなかった、この仕様のより古いバー |ジョンの実装との過去互換を壊してしまう。 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: |偽造された Version 1 Report Message はルータを特定のグループで |"Version 1 Members Present" 状態にしてしまい、 (これは) ルータが、 |Leave Message を無視することを意味する。これは [Group Membership | Interval]まで、メンバーのないグループにトラフィックを流すことを |強いることができる。偽造された V1 Report に対して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 Report に対する防御として、パケットのソースアド |レスが、パケットが受信されたインタフェースに割り当てたサブネット |に属することが認証できなかったならば、Report を無視する。この解 |決方法は、ローカルサブネットのアドレスを持たない移動ホストによっ |て送られた V1 Report を無視することを意味する。 - 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. |Version 1 メッセージを完全に無視するよう設定したスイッチを持つ |ルータの供給。これは自動的に Version 1 ホストとの互換性を壊す、 |それゆえ、「高速な離脱」が厳しく要求される状況においてのみ使用 |される。この解決方法は、ローカルサブネットからの偽造された V1 | Reportに対しても、同様に保護する。 Leave message: |Leave メッセージ 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メッセージは、問い合わせるのにグループに対して |Group-Specific Queries を Querier に送出させる要因となる。これは |それぞれのルータとグループのそれぞれのメンバーに余分なプロセスを |発生を強いるが、要求されているトラフィックを損失させることはでき |ない。外部で偽造された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. |Router Alert オプション[RFC 2113]なしの Leave メッセージを無視し、 |ルータが Leave メッセージを転送しないことを要求する。(この要求は |転送パスに汎用のフィルタの実装を要求しない、 なぜならパケットは既 |にその中に、Router Alert オプションを持っているためである)。 この |解決は、 Router Alert を必要としなかった、この仕様のより古いバー |ジョンの実装との過去互換を壊してしまう。 11. Acknowledgments |謝辞 IGMPv2 was designed by Rosen Sharma and Steve Deering. | IGMPv2 は Rosen Sharma と Steve Deering によって設計された。 12. References |参考 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 2113 Katz, D., "IP Router Alert Option," RFC 2113, February 1997. RFC 1112 Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 13. Appendix I - Changes from IGMPv1 |付録I - IGMPv1 からの変更 The IGMPv1 "Version" and "Type" fields are combined into a single "Type" field. |IGMPv1 の "Version" 及び "Type" フィールドは一つの "Type" フィー |ルドに結合された。 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 Type が Version 2 Membership Report に割り当てられたので、 |ルータは IGMPv1 と IGMPv2 の ホスト報告の違いを、知ることができる。 A new IGMP Type is created for the IGMPv2 Leave Group message. |新しい IGMP Type が IGMPv2 Leave Group メッセージのために作成された。 The Membership Query message is changed so that a previously unused field contains a new value, the Max Response Time. |Membership Query メッセージは、以前は使用されていなかったフィールドに |新たな値、Max Response Time を含むよう変更された。 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 のスペックは、今 Querier 選定メカニズムを指定している。IGMPv1 |では、Querier の選定は、マルチキャストルーティングプロトコルにまで残 |されていて、異なるプロトコルには異なるメカニズムが使用された。これは、 |ネットワーク毎に1を超えるQuerierが(存在する)結果となりうる、そのため、 |選定メカニズムは IGMPv2 で標準化された。しかしながら、これは、IGMPv2 |ルータを、異なる Querier 選定メカニズムを使用する IGMPv1 ルータと共存 |させようとする時に、注意しなければならないことを意味する。 とりわけ、 |IGMPv2 ルータが、一部のネットワークで IGMPv1 ルータとして振舞うことが |可能でなければならない場合において。この動作は(以下を)含むことが要求 |される。 - Set the Max Response Time field to 0 in all queries. |すべてのQuery で Max Response Timeフィールドに 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 のスペックは Membership Query と Membership Report に対する |正当性チェックの必要条件を緩めている。実装をアップグレードする際、 |所属しないことのいかなるチェックも削除することを確実にすべきである。 The IGMPv2 spec requires the presence of the IP Router Alert option [RFC 2113] in all packets described in this memo. |IGMPv2 のスペックは、このメモに記述されているすべてのパケットについて |IP Router Alert オプション [RFC 2113]の存在を要求する。 14. Author's Address |筆者のアドレス William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: +1 650 812 4816 EMail: fenner@parc.xerox.com 15. Full Copyright Statement |著作件全文 Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。