RFC2236 日本語訳
2236 Internet Group Management Protocol, Version 2. W. Fenner. November 1997. (Format: TXT=51048 bytes) (Obsoleted by RFC3376) (Updates RFC1112) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Fenner Request for Comments: 2236 Xerox PARC Updates: 1112 November 1997 Category: Standards Track
コメントを求めるワーキンググループW.フェナーの要求をネットワークでつないでください: 2236のゼロックスPARCアップデート: 1112 1997年11月のカテゴリ: 標準化過程
Internet Group Management Protocol, Version 2
インターネットグループ管理プロトコル、バージョン2
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(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を記録します。 それはSTD5、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).
このドキュメントはインターネット・エンジニアリング・タスク・フォースの中のInter-ドメインMulticastルート設定ワーキンググループの製品です。 コメントは、請求されて、 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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
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
インターネットGroup Managementプロトコル(IGMP)は、どんなすぐに隣接しているマルチキャストルータにも彼らのマルチキャストグループ会員資格を報告するのにIPホストによって使用されます。 このメモは、グループ会員資格を決定するためにホストとルータの間でIGMPの使用だけについて説明します。 マルチキャストグループのメンバーであるルータが振る舞うと予想されます。
Fenner Standards Track [Page 1] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[1ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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はルータの間で使用されるかもしれませんが、そのような使用はここで指定されません。
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ヘッダーにIP TTL1と共に送られて、IP Router Alertオプション[RFC2113]を含んでいます。 ホストにとって、重要なすべての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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| マックスResp Time| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Type
2.1. タイプ
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:
- 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.
0×11 = 会員資格Query Thereは2つのサブタイプに関するMembership Queryメッセージです: - どのグループにメンバーが付属ネットワークにいるかを学ぶのに使用されるQuery司令官。 - 特定のグループで何かメンバーが付属ネットワークにいるかどうか学ぶのに使用されるグループ特有の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.
これらの2つのメッセージがGroup Addressによって差別化されます、セクション1.4で説明されるように。会員資格Queryメッセージは単に「質問」メッセージと呼ばれます。
0x16 = Version 2 Membership Report
0×16 =バージョン2会員資格レポート
0x17 = Leave Group
0×17 = 休暇は分類されます。
There is an additional type of message, for backwards-compatibility with IGMPv1:
追加タイプに関するメッセージがIGMPv1との遅れている互換性のためにあります:
0x12 = Version 1 Membership Report
0×12 =バージョン1会員資格レポート
Fenner Standards Track [Page 2] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[2ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
This document refers to Membership Reports simply as "Reports". When no version is specified, the statement applies equally to both versions.
このドキュメントは単に「レポート」とMembership Reportsを呼びます。 バージョンが全く指定されないとき、声明は等しく両方のバージョンに適用されます。
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. マックス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.
マックスResponse Time分野は、Membership Queryメッセージだけで重要であり、応じるレポートを送る前の最大の許容時にユニットの2番目を指定します。 他のすべてのメッセージでは、それは、送付者によってゼロに設定されて、受信機によって無視されます。
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に許容されます。 また、それは、サブネットに関するIGMPトラフィックのburstinessセクション7.3で議論するように調整するのを許容します。
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.
Membership Queryメッセージでは、Group特有のQueryを送るとき、グループアドレス・フィールドは、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の将来の後方にコンパチブルバージョンであるかもしれないことに注意してください。 Typeが認識されるものである限り、IGMPv2実装はパケットを処理している間、最初の8つの八重奏を超えて何でも無視しなければなりません。 しかしながら、IGMPチェックサムは最初の8つの八重奏だけの上計算されるのではなく、全体のIPペイロードの上いつも計算されます。
Fenner Standards Track [Page 3] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[3ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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つを仮定するかもしれません: Querierか非Querier。 通常、1物理ネットワークあたり1Querierしかありません。 すべてのマルチキャストルータがそれぞれの付属ネットワークのQuerierとして始動します。 マルチキャストルータが低いIPアドレスでルータからQueryメッセージを聞くなら、それはそのネットワークでNon-Querierにならなければなりません。 ルータが[他のQuerier Present Interval]に関して別のルータからQueryメッセージを聞いていないなら、それはQuerierの役割を再開します。 ルータは定期的にこのルータが会員資格情報に請求するためにはQuerierであるそれぞれの付属ネットワークにQuery司令官を送ります[質問Interval]。 始動、SHOULDが会員資格情報をすぐに、そして確かに決定するために密接に一緒に区切られたQueries司令官[始動Query Interval]を送る[始動Query Count]ルータに関して。 Query司令官がオールシステムマルチキャストグループに扱われる、(224.0 .0 .1) 0のGroup Address分野を持っていて、[質問Response Interval]のマックスResponse Timeを持っています。
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
ホストがQuery司令官を受け取るとき、それは質問を受けたインタフェースのメンバーである各グループ(オールシステムグループを除いた)にディレイタイマを設定します。 各タイマは異なった無作為の値に設定されます、ホストで利用可能で、範囲から選択された最も高い時計粒状を使用して(0、マックスResponse Time、マックスResponse Timeと共に、ホストがQueryパケットで.いつかを指定するのでGroup-詳細Queryを受け取って、範囲から選択された無作為の値にディレイタイマを設定する、(0 それが質問を受けたインタフェースのメンバーであるなら質問されるグループのための上のマックスResponse Time; . 要求されたマックスResponse Timeである場合にだけ無作為の値にリセットされて、実行タイマの残余価値以下はいつです。グループのためのタイマが既に動いているなら、それが動いている、グループのタイマは期限が切れて、ホストマルチキャストはグループへのバージョン2Membership Reportです、1のIP TTLと共にホストが別のものを受けます。
Fenner Standards Track [Page 4] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[4ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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.
ホストのReport(バージョン1か2)がそれである間、タイマを動かして、指定されたグループのためにタイマを止めて、Reportを送りません、写しReportsを抑圧するために。
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を受けて、会員資格にタイマを設定するネットワークのマルチキャストグループ会員資格のリストに報告されるグループを加える、[グループMembership Interval。] 繰り返されたReportsはタイマをリフレッシュします。 このタイマが期限が切れる前に特定のグループのためにReportsを全く受け取らないなら、ルータはグループには地元会員が全くいないで、そのグループのために離れて溯源されたマルチキャストを付属ネットワークに送る必要はないと仮定します。
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).
ホストがすぐにマルチキャストグループに加わるとき、そのグループのために求められていないバージョン2Membership Reportを伝えるべきです、それが第1代ネットワークに関するそのグループのメンバーであるといけないので。 なくされているか、または破損する初期のMembership Reportの可能性をカバーするために、それが少し遅れ[求められていないReport Interval]の後に一度か二度繰り返されるのは、お勧めです。 (これを達成する簡単な方法は、適切に初期のバージョン2Membership Reportを送って、次に、まるでそのグループのためにGroup特有の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がそれがaで疑問に答える最後のホストであったなら分類して、それがSHOULDである、オールルータマルチキャストグループにLeave Groupメッセージを送ってください、(224.0 .0 .2)。 疑問に答える最後のホストでなかったなら、別のメンバーがサブネットにいるに違いないので、それは何も送らないかもしれません。 これはトラフィックを減少させる最適化です。 それがグループを出るとき、それが返答する最後のホストであったかどうかを覚えていることができるくらいのストレージのないホストはいつもLeave Groupメッセージを送るかもしれません。 ルータSHOULDは残されるグループに扱われたLeave Groupメッセージを受け入れます、この規格の以前のバージョンの実装を収容するために。 他のグループのメンバーにはホストが仲間から抜けましたが、それにグループにメッセージを扱うために危害を加えないのを知る必要が全くないので、メッセージが扱われる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メッセージを受け取るとき、グループ特有のQueriesを送る、[メンバーQuery Countを持続します]あらゆる、[メンバーQuery Intervalを持続します] グループに残されます。 これらのGroup特有のQueriesは[最後のメンバーQuery Interval]に彼らのマックスResponse時間を決めさせます。 最後の質問の応答時間が期限が切れた後にどんなReportsも受け取られていないなら、ルータは、グループには地元会員が全くいないと仮定します、上です。 非Querier変遷へのどんなQuerierもこの間に無視されます。 同じルータはGroup特有のQueriesを送り続けます。
Fenner Standards Track [Page 5] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[5ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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.
非QueriersはLeave Groupメッセージを無視しなければなりません、そして、Queriers SHOULDはグループのメンバーが全くレセプションインタフェースにいないLeave Groupメッセージを無視します。
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.
非QuerierがGroup特有のQueryメッセージを受け取るとき、既存のグループ会員資格タイマがマックスResponse Timeがメッセージで指定した[メンバー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ホストはサブネットにQuerierルータがまだ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ルータはResponse Timeが0に設定するマックスと一緒にいるQueries司令官を送るでしょう。 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ルータは、Queriesに対応してバージョン1Membership Reportsを予想して、バージョン2Membership Reportsに注意を向けないでしょう。 したがって、州の変数を各インタフェースに保たなければなりません、そのインタフェースのマルチキャストQuerierが実行しているIGMPv1かそれともIGMPv2であるかを説明して。 この変数は、IGMPv1質問が最終で聞かれたかどうかに基づいている[バージョン1Router Present Timeout]秒でなければならなく、Queryが聞いた最終タイプに基づいてはいけません。 Queriesに対応したMembership Reportsと同様に求められていないMembership ReportsのためにMembership Reportsのどんなタイプを送ったらよいかを決めるのにこの州の変数を使用しなければなりません。
An IGMPv2 host MAY suppress Leave Group messages on a network
where the Querier is using IGMPv1.
IGMPv2ホストはQuerierがIGMPv1を使用しているネットワークに関するLeave Groupメッセージを削除するかもしれません。
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ルータが存在しているなら、querierはIGMPv1を使用しなければなりません。 行政上IGMPv1の使用を構成しなければなりません、IGMPv1ルータがネットワークに存在しているかどうかダイナミックに決定するどんな信頼できる方法もないとき。 実装はシステム管理者が彼らのルータにおけるIGMPv1の使用を可能にする方法を提供するかもしれません。 明白な構成がないとき、構成はIGMPv2をデフォルトとしなければなりません。 ルータがIGMPv1モードで0のマックスResponse TimeとPeriodic Queriesを送らなければならなくて、Leave Groupメッセージを無視しなければならないとき。 それら、また、SHOULDはそのような警告がレートで限らなければなりませんが、IGMPv2質問を受けることに関して警告します。
Fenner Standards Track [Page 6] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[6ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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.
aであるなら、ルータは、IGMPv1を使用するために明らかに構成されないで、IGMPv1 Queryを聞いて、それはSHOULDログa警告です。 これらの警告はレートで限らなければなりません。
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.
ホストは、Membership Reportがバージョン1Membership Reportかバージョン2Membership Reportのどちらかによって抑圧されるのを許さなければなりません。
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].
ルータがバージョン1Membership Reportを受けるなら、それは、タイマにホストが提示するそれがレポートを聞いたグループのメンバーであるバージョン1があることに注意するように設定しなければなりません。 このタイマが同じであるべきである、[グループ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つの可能な州の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.
- ホストがインタフェースに関するグループに属さないときの「非メンバー」状態。 これはすべてのネットワーク・インターフェースのすべての会員資格のための初期状態です。 それはホストでストレージを全く必要としません。
- "Delaying Member" state, when the host belongs to the group on the
interface and has a report delay timer running for that membership.
- 「メンバーを遅らせ」て、ホストがインタフェースに関するグループに属して、レポートを持っているときにはその会員資格のためのタイマ実行を遅らせるように述べてください。
- "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.
- ホストがインタフェースに関するグループに属して、レポートディレイタイマをその会員資格に立候補させないときの「活動していないメンバー」状態。
Fenner Standards Track [Page 7] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[7ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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.
- ホストが、インタフェースに関するグループに加わると決めると、「グループに加わってください」は起こります。 それはNon-加盟国だけで起こるかもしれません。
- "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.
- ホストが、インタフェースで仲間から抜けると決めると、「休暇は分類すること」が起こります。 それはDelayingメンバーとIdleメンバー州だけに起こるかもしれません。
- "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.
- ホストが有効な一般Membership Queryメッセージか有効なGroup特有のMembership Queryメッセージのどちらかを受け取るとき、「質問は受信したこと」が起こります。 Queryメッセージは、長い間の少なくとも8つの八重奏であり、有効に、なるように正しいIGMPチェックサムを持たなければなりません。 IGMPヘッダーのグループアドレスは、ゼロ(Query司令官)か有効なマルチキャストグループアドレスのどちらかであるに違いありません(Group特有のQuery)。 Query司令官はQueryが受け取られているインタフェースのすべての会員資格に適用します。 Group特有のQueryはQueryが受け取られているインタフェースでただ一つのグループで会員資格に適用します。 質問はNon-加盟国における会員資格のために無視されます。
- "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 Membership Reportメッセージ(バージョン1かバージョン2)を受け取るとき、「レポートは受信したこと」が起こります。 Reportメッセージは、長い間の少なくとも8つの八重奏であり、有効に、なるように正しいIGMPチェックサムを持たなければなりません。 Membership ReportはMembership Reportによって特定されたグループで会員資格だけに適用します、Membership Reportが受け取られているインタフェースで。 それはNon-メンバーかIdleメンバー状態の会員資格のために無視されます。
- "timer expired" occurs when the report delay timer for the group on
the interface expires. It may occur only in the Delaying Member
state.
- インタフェースに関するグループのためのレポートディレイタイマが期限が切れると、「タイマは期限が切れたこと」が起こります。 それはDelayingメンバー状態だけに起こるかもしれません。
All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states.
QueryかReport以外の無効の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.
- インタフェースに関するグループのための「レポートを送ってください。」 レポートのタイプはインタフェースの状態のそばで決定しています。 報告されるグループにReport Messageを送ります。
Fenner Standards Track [Page 8] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[8ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
- "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).
- インタフェースに関するグループのための「休暇を送ってください。」 界面準位がQuerierを言うなら、実行しているIGMPv1、この動作はSHOULDです。スキップされます。 私たちが報告する最後のホストであったと言う旗がきれいにされるなら、この動作はサボられるかもしれません。 Leave Messageを送る、すべて、-、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] ].
- インタフェースに関するグループのための「タイマを始動してください」、マックスResponse時間がQueryで指定される間隔(0、マックスResponse Time]から一様に選ばれた遅れ値を使用して。これが求められていないReportであるなら、タイマは間隔から一様に選ばれた遅れ値に設定されます(0、[求められていない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、マックスResponse Time]から一様に選ばれた遅れ値を使用して、「スタートタイマ」で説明されるように。
- "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.
以下の州のダイヤグラムでは、全部で、それぞれの状態遷移アークはそして括弧(変遷の間に取られたどんな行動)で変遷を引き起こすイベントでラベルされます。 変遷がいつもイベントによって引き起こされることに注意してください。 動きが条件付きであっても、変遷はまだ起こっています。
Fenner Standards Track [Page 9] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[9ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
________________
| |
| |
| |
| |
--------->| 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) |
-------------------
________________ | | | | | | | | --------->| 非会員| <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、|、|、|、|、| |________________| | | | | | グループを出てください。| グループに加わってください。| グループを出てください。| (タイマを止めてください、| (レポートを送ってください、|、(休暇を送ってください| | セット旗であるなら休暇を送ってください、|、旗のセット) | 旗のセット) | スタートタイマである、) | ________|________ | ________|________ | | <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 質問は受信されました。| | | メンバーを遅らせます。| (スタートタイマ) | 活動していないメンバー| ---->| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| レポートは受信されました。| | | | | (| | | | | 停止タイマ、明確な旗) | | | |_________________|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|_________________| | 質問は受信されました。| タイマは期限が切れました。| (| (| レポート、マックスResp Timeを送ってください| 旗を設定してください)| <の現在のタイマであるならタイマをリセットします) | -------------------
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メンバー状態で始まって、別の状態に決して移行しないで、またそのグループのためにレポートを決して送りません。
In addition, a host may be in one of two possible states with respect to any single network interface:
さらに、どんな単一のネットワーク・インターフェースに関してもホストは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.
- 「いいえ、IGMPv1 Router Present」、ホストが、IGMPv1が質問を流行に合わせると聞いていないとき[バージョン1Router Present Timeout。] これは初期状態です。
- "IGMPv1 Router Present", when the host has heard an IGMPv1 style
query within the [Version 1 Router Present Timeout].
- "IGMPv1 Router Present"、ホストがIGMPv1を聞いたときには中で質問を流行に合わせてください、[バージョン1Router Present Timeout。]
Fenner Standards Track [Page 10] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[10ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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.
- ホストは0に設定されたマックスResponse Time分野で質問を受けます「IGMPv1質問は受信した」。
- "timer expires", when the timer set to note the presence of an
IGMPv1 router 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.
- タイマを最大限に設定する「セットタイマ」値[バージョン1Router Present Timeout]とそれを始める(re。)
________________
| |
| |
| No IGMPv1 |
| Router |
| Present |
| |
---->| |----
| | | |
| |________________| |
timer expires | | IGMPv1 query
| ________________ | received
| | | | (set timer)
| | | |
| | | |
-----| IGMPv1 |<---
| Router |
| Present |
| |
---->| |----
| |________________| |
| |
| IGMPv1 query received |
| (set timer) |
---------------------------
________________ | | | | | IGMPv1がありません。| | ルータ| | プレゼント| | | ---->| |---- | | | | | |________________| | タイマは期限が切れます。| | IGMPv1質問| ________________ | 受信します。| | | | (セットタイマ) | | | | | | | | -----| IGMPv1| <、-、--、| ルータ| | プレゼント| | | ---->| |---- | |________________| | | | | IGMPv1質問は受信されました。| | (セットタイマ) | ---------------------------
Fenner Standards Track [Page 11] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[11ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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つの可能な州の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.
- このネットワークでIGMP会員資格Queriesを伝えるために指定された別のルータがあるときの「非Querier。」
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アドレスでルータからIGMP Membership Queryを受け取るとき、「低いIPアドレスでルータから受けられた質問」は起こります。
- "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アドレスがある別のquerierの存在が期限が切れることに注意するためにセットしたとき、「他の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 other querier present timer" for the attached network [Other
Querier Present Interval].
- 付属ネットワーク[他のQuerier Present Interval]のための「他のquerierの現在のタイマを始動してください。」
- "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].
- 付属ネットワークの「一般的な質問を送ってください。」 オールシステムグループに司令官のQueryを送る、(224.0、.0、.1)、[質問Response Interval]のマックスResponse Timeを持っています。
Fenner Standards Track [Page 12] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[12ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
--------------------------------
_______|________ 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) |
---------------------------
-------------------------------- _______|________ 情報を得てください。タイマについて質問してください。| --------- | | 期限が切れます。| | 初期|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| (send general query, | --------- (send gen. q., | | set gen. q. timer) | set initial gen. q. | |<---------------------- timer) | Querier| | | -----| | <、-、--、|、|、|、|、| |________________| | aから受けられた質問| | aが低い他のquerierルータ| | 現在のタイマIPアドレス| | 期限が切れます。(他のquerierを設定してください。| ________________ | (一般的な現在のタイマを送ります) | | | | 質問、セットに情報を得ます。 | | | | q. タイマ) | | | | ---->| 非|---- | Querier| | | | | ---->| |---- | |________________| | | aから受けられた質問| | 下側のIPがあるルータ| | アドレス| | (他のquerierを設定してください| | 現在のタイマ) | ---------------------------
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:
さらに、グループにはメンバーがいる道を保つために、どんなただ一つの付属ネットワークに関するどんなただ一つの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.
- ホストが全くネットワークの一員でないときに、「メンバーPresentがありません」状態であり、どれが発信したかがこのマルチキャストグループを届け出ます。 これはルータに関するすべてのグループのための初期状態です。 それはルータにおけるストレージを全く必要としません。
- "Members Present" state, when there is a host on the network which
has sent a Membership Report for this multicast group.
- 「メンバーPresent」は、ホストがいつによるこのマルチキャストグループのためにMembership Reportを送ったネットワークの一員であるかと述べます。
Fenner Standards Track [Page 13] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[13ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
- "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メンバーPresent」は、IGMPv1ホストがいつによるこのマルチキャストグループのためにバージョン1Membership Reportを送ったネットワークの一員であるかと述べます。
- "Checking Membership" state, when the router has received a
Leave Group message but has not yet heard a Membership Report for
the multicast group.
- 「照合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.
- ルータがインタフェースに関するグループのためにバージョン2Membership Reportを受けるとき、「v2レポートは受信したこと」が起こります。 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.
- ルータがインタフェースに関するグループのためのバージョン1Membershipレポートを受け取るとき、「v1レポートは受信したこと」が起こります。 同じ正当性要件は適用されます。
- "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.
- ルータがインタフェースに関するグループへのIGMP Group Leaveメッセージを受け取るとき、「休暇は受信したこと」が起こります。 Leaveメッセージは、長い間の少なくとも8つの八重奏でなければならなく、有効に、なるように正しいIGMPチェックサムを持たなければなりません。
- "timer expired" occurs when the timer set for a group membership
expires.
- タイマが会員資格が吐き出すグループのためにセットしたとき、「タイマは期限が切れたこと」が起こります。
- "retransmit timer expired" occurs when the timer set to retransmit
a group-specific Membership Query expires.
- グループ特有のMembership Queryを再送するように設定されたタイマが期限が切れると、「再送信タイマは期限が切れたこと」が起こります。
- "v1 host timer expired" occurs when the timer set to note the
presence of version 1 hosts as group members expires.
- タイマがグループのメンバーとしてのバージョン1ホストの存在が期限が切れることに注意するためにセットしたとき、「v1ホストタイマは期限が切れたこと」が起こります。
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.
- インタフェースのグループ会員資格のための「タイマを始動してください」--また、タイマが現在動いているなら、初期の値[グループ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.
- この代替の動作はこのルータがQuerierであるか[マックスResponse Time]コネがパケット*であるなら[メンバーQuery Intervalを持続します]*[メンバーQuery Countを持続する]にタイマを設定します。インタフェースのグループ会員資格のための「スタートタイマ*」--[メンバーQuery Countを持続します] このルータが非Querierであるなら。
Fenner Standards Track [Page 14] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[14ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
- "start retransmit timer" for the group membership on the interface
[Last Member Query Interval].
- インタフェース[メンバー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ホストタイマ」は初期の値[グループ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].
- 付属ネットワークに関するグループのための「グループ特有の質問を送ってください。」 Group特有のQueryは質問されるグループに送られて、[最後のメンバーQuery Interval]のマックスResponse Timeを持っています。
- "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:
Querier状態のルータのための州のダイヤグラムは従います:
Fenner Standards Track [Page 15] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[15ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
________________
----------------------------| |<-----------------------
| | |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) |
----------------- --------------------------
________________ ----------------------------| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |タイマは期限が切れました。| | タイマは期限が切れました。| |(ルーティングに通知してください、-、|、|、(ルーティングに通知してください、-、)、| メンバーがありません| rxmt tmrをきれいにしてください、) | | ------->| プレゼント| <、-、-、-、-、-、--、|、|、|、|、|、|、| |v1レポートrecはそうするでしょう。| | | | ------------ | |(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レポートは受信されました。| | | | | | (スタートタイマ) | | | | | 出席者| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| チェックします。| | | ----->|、| 休暇は受信されました。| 会員資格| | | | | | (| | | | | | | タイマ*、スタートrexmtタイマを始動してください|、|、|、|、|、|、|、発信、g-s質問) | | | | | --->| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| |_________________| |______________| | | | |v2レポートrecはそうするでしょう。| | | | | | |(スタートタイマ) | |v1レポートrecはそうするでしょう。|v1レポートrecはそうするでしょう。| | | ---------------- |(| (| | | タイマ、v1ホストを始めてください| v1ホストタイマを始動してください)| スタートタイマ、スタートv1は|接待します| | tmr______________V__ |タイマ) | | |expはそうするでしょう。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| ------| | | | | バージョン1|タイマは期限が切れました。| | | 出席者|(ルーティングに通知してください、-、) | ------->| |------------------------------------------- | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ------->|_________________| v1レポートrecはそうするでしょう。| | v2レポートrecはそうするでしょう。| | (| | タイマ、(スタートタイマ)を始めてください| | スタートv1ホストタイマ) | ----------------- --------------------------
Fenner Standards Track [Page 16] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[16ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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状態のルータのための州のダイヤグラムが同様ですが、非Queriersはどんなメッセージも送らないで、非Queriersが、Membership Reportメッセージがバージョン1かそれともバージョン2であるかを気にかけないというメッセージreception.Noteによって運転されるだけです。
________________
| |
| |
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) |
-----------------
________________ | | | | タイマは期限が切れました。| |タイマが期限が切れた、(ルーティングに通知してください、-、)| メンバーがありません。|(ルーティングに通知してください、-、) --------->| プレゼント| <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、|、|、|、|、| |________________| | | | | | |レポートは受信されました。| | |(| | | ルーティング+、スタートタイマに通知します) | ________|________ | ________|________ | | <、-、-、-、-、-、-、-、--、|、|、|、| レポートは受信されました。| | | | (スタートタイマ) | | | 出席者| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| チェックします。| | | g-s質問recはそうするでしょう。| 会員資格| | | (スタートタイマ*) | | ---->| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |_________________| |_________________| | レポートは受信されました。| | (スタートタイマ) | -----------------
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
Robustness Variableは、サブネットにおける予想されたパケット損失で調整するのを許容します。 サブネットが損失性であると予想されるなら、Robustness Variableは増強されるかもしれません。 IGMPは(丈夫さVariable-1)パケット損失に強健です。 Robustness Variableはゼロであるはずがありません、そして、SHOULD NOTは1にゼロです。 デフォルト: 2
Fenner Standards Track [Page 17] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[17ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
8.2. Query Interval
8.2. 質問間隔
The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds.
Query IntervalはQuerierによって送られた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.
異なる、[質問Interval]、管理者はサブネットに関するIGMPメッセージの数を調整するかもしれません。 より大きい値で、よりしばしばIGMP Queriesを送ります。
8.3. Query Response Interval
8.3. 質問応答間隔
The Max Response Time inserted into the periodic General Queries. Default: 100 (10 seconds)
マックスResponse Timeは司令官のQueriesを周期的に挿入しました。 デフォルト: 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].
異なる、[質問Response Interval]、管理者はサブネットに関するIGMPメッセージのburstinessを調整するかもしれません。 ホスト応答が、より大きい間隔にわたって広げられるとき、より大きい値は、より少ないトラフィックburstyを作ります。 数、[質問Response Interval]必須によって表された秒では、より少なくいてください、[質問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).
Group Membership Intervalはマルチキャストルータが、ネットワークに関するグループのそれ以上のメンバーが全くいないと決める前に経過しなければならない時間です。 この値は(Robustness Variable)回(Query Interval)と(1Query Response Interval)でなければならない。
8.5. Other Querier Present Interval
8.5. 他の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であるべきである別のマルチキャストルータがもうないと決める前に経過しなければならない時間の長さです。 この値はそのうえ(1Query Response Intervalの半分)、((Robustness Variable)回(Query Interval))でなければなりません。
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.
Startup Query IntervalはQuerierによって始動に送られたQueries司令官の間隔です。 デフォルト: 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.
Startup Query CountはStartup Query Intervalによって切り離された始動で出されたQueriesの数です。 デフォルト: 丈夫さ変数。
Fenner Standards Track [Page 18] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[18ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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メンバーQuery IntervalはLeave Groupメッセージに対応して送られたGroup特有のQueriesに挿入されたマックスResponse Timeであり、また、Group特有の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メンバーQuery Countはルータが、地元会員が全くいないと仮定する前に送られたGroup特有のQueriesの数です。 デフォルト: 丈夫さ変数。
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.
バージョン1Router Present TimeoutはどんなIGMPv2メッセージも送るかもしれない前にバージョン1Queryを聞いた後にどれくらい長いホストが待たなければならないかということです。 値: 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)
メッセージタイプ目的地グループ------------ ----------------- Query司令官、すべて、-、SYSTEMS、(224.0.0.1)グループ詳細Queryのグループの存在の質問されたMembership Reportのグループの存在の報告されたLeave Message、すべて、-、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 Messagesを送ります。 ルータSHOULDは存在が後方にの利益のためでそのようなホストとの互換性を残したグループに扱われたLeave Messagesを受け入れます。 しかしながら、すべての場合では、ホストが発信しなければならない、すべて、-、ROUTERS、この仕様で言いなりになるために、扱います。
Fenner Standards Track [Page 19] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[19ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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].
現在のQuerierより低いIPアドレスがあるマシンからの偽造Queryメッセージで、Querier義務を捏造者に割り当てるでしょう。 次に、捏造者が、より多くのQueryメッセージ、他のルータのどんなOther Querier Presentタイマにも意志を送らないなら、タイムアウトとある意志がQuerierの役割を再開します。 この間に、捏造者がLeave Messagesを無視するなら、トラフィックは[グループ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:
メッセージを報告してください:
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つのディフェンスが外部的に鍛造された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 Reports sent by mobile hosts without addresses on the local
subnet will be ignored.
- パケットが受け取られたインタフェースに割り当てられたサブネットに属すとしてパケットのソースアドレスを特定できないなら、Reportを無視してください。 このソリューションは、地方のサブネットでアドレスなしでモバイルホストによって送られたReportsが無視されることを意味します。
- 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オプション[RFC2113]なしでReportメッセージを無視してください、そして、ルータがメッセージをReportに転送しないのを必要であってください。 (要件は推進経路の一般化されたフィルタリングの要件ではありません、パケットがそれらに既にRouter Alertオプションを持つので。) このソリューションは後方にRouter Alertを必要としなかったこの仕様の以前のバージョンの実装との互換性を壊します。
Fenner Standards Track [Page 20] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[20ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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偽造Report Messageが特定のグループのために「バージョン1出席者」状態にルータを入れるかもしれません、ルータがLeaveメッセージを無視することを意味して。 これで、トラフィックは[グループMembership Interval]までメンバーなしでグループに注ぐことができます。 2つのディフェンスが偽造v1 Reportsに反対しています:
- 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 Reportsに対して防御するには、パケットが受け取られたインタフェースに割り当てられたサブネットに属すとしてパケットのソースアドレスを特定できないなら、Reportを無視してください。 このソリューションは、地方のサブネットでアドレスなしでモバイルホストによって送られたv1 Reportsが無視されることを意味します。
- 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メッセージで、Querierは問題のグループのためにGroupの特定のQueriesを出すでしょう。 これが、各ルータの上と、そして、グループの各メンバーの上で付加的な処理を引き起こしますが、必要なトラフィックの損失をもたらすことができません。 2つのディフェンスが外部的に鍛造されたLeaveメッセージに反対しています:
- 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オプション[RFC2113]なしでLeaveメッセージを無視してください、そして、ルータがメッセージをLeaveに転送しないのを必要であってください。 (要件は推進経路の一般化されたフィルタリングの要件ではありません、パケットがそれらに既にRouter Alertオプションを持つので。) このソリューションは後方にRouter Alertを必要としなかったこの仕様の以前のバージョンの実装との互換性を壊します。
11. Acknowledgments
11. 承認
IGMPv2 was designed by Rosen Sharma and Steve Deering.
IGMPv2はローゼン・シャルマとスティーブ・デアリングによって設計されました。
Fenner Standards Track [Page 21] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[21ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
12. References
12. 参照
RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2119ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
RFC 2113 Katz, D., "IP Router Alert Option," RFC 2113,
February 1997.
RFC2113キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
RFC 1112 Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, August 1989.
RFC1112デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
Fenner Standards Track [Page 22] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[22ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
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 Typeがバージョン2Membership 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メッセージを変えるので、以前に未使用の分野は新しい値、マックス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ネットワークあたり1querierをもたらすことができました、したがって、選挙メカニズムがIGMPv2で標準化されました。 しかしながら、これは、IGMPv2ルータが異なったquerier選挙メカニズムを使用するIGMPv1ルータと共存しようとしているとき、注意しなければならないことを意味します。 特に、それは、そうするために構成されるならIGMPv2ルータがIGMPv1ルータとして特定のネットワークに機能できなければならないことを意味します。 必要である動作は:
- Set the Max Response Time field to 0 in all queries.
- すべての質問でマックス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 QueriesとMembership Reportsのために正当性照合に関する要件を弛緩します。 実現をアップグレードさせるときには、属しないあらゆるチェックを必ず取り除いてください。
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オプション[RFC2113]を存在に要求します。
14. Author's Address
14. 作者のアドレス
William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: +1 650 812 4816
パロアルト、カリフォルニア 94304が電話をするウィリアムC.フェナーゼロックスPARC3333コヨーテヒル道路: +1 650 812 4816
EMail: fenner@parc.xerox.com
メール: fenner@parc.xerox.com
Fenner Standards Track [Page 23] RFC 2236 Internet Group Management Protocol November 1997
フェナー標準化過程[23ページ]RFC2236インターネット集団経営は1997年11月に議定書を作ります。
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Fenner Standards Track [Page 24]
フェナー標準化過程[24ページ]
一覧
スポンサーリンク
