RFC3376 日本語訳
3376 Internet Group Management Protocol, Version 3. B. Cain, S.Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. October 2002. (Format: TXT=119726 bytes) (Obsoletes RFC2236) (Updated by RFC4604) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Cain
Request for Comments: 3376 Cereva Networks
Obsoletes: 2236 S. Deering
Category: Standards Track I. Kouvelas
Cisco Systems
B. Fenner
AT&T Labs - Research
A. Thyagarajan
Ericsson
October 2002
コメントを求めるワーキンググループB.カイン要求をネットワークでつないでください: 3376のCerevaネットワークが以下を時代遅れにします。 2236秒間デアリングカテゴリ: 標準化過程I.KouvelasシスコシステムズB.フェナーAT&T研究室--研究A.Thyagarajanエリクソン2002年10月
Internet Group Management Protocol, Version 3
インターネットグループ管理プロトコル、バージョン3
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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.
IGMPv3、このドキュメントはインターネットGroup Managementプロトコルのバージョン3を指定します。 IGMPはIPv4システムによって使用される、それらのIPマルチキャストグループ会員資格を隣接しているマルチキャストルータに報告するプロトコルです。 IGMPのバージョン3は「ソースフィルタリング」のサポートを加えます、すなわち、システムがパケットを受けることへの関心を報告する能力。**からの特定のソースアドレス、または、*特定のソースを除いた皆が扱う*だけ、が特定のマルチキャストアドレスに発信しました。 その情報はマルチキャストルーティング・プロトコルによって使用されて、特定のソースからどんな関心がある受信機もないネットワークまでマルチキャストパケットを提供するのを避けるかもしれません。
This document obsoletes RFC 2236.
このドキュメントはRFC2236を時代遅れにします。
Cain, et. al. Standards Track [Page 1] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[1ページ]RFC3376IGMPv3 October 2002
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Service Interface for Requesting IP Multicast Reception . 3
3. Multicast Reception State Maintained by Systems . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
5. Description of the Protocol for Group Members . . . . . . . . 19
6. Description of the Protocol for Multicast Routers . . . . . . 24
7. Interoperation with Older Versions of IGMP. . . . . . . . . . 35
8. List of Timers, Counters, and Their Default Values. . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
12. Normative References. . . . . . . . . . . . . . . . . . . . . 47
13. Informative References. . . . . . . . . . . . . . . . . . . . 47
Appendix A. Design Rationale. . . . . . . . . . . . . . . . . 49
Appendix B. Summary of changes from IGMPv2. . . . . . . . . . 50
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 53
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IPマルチキャストレセプション. 3 3を要求するためのサービスインタフェース。 システム. . . . . . . 5 4によって維持されたマルチキャストレセプション状態。 メッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . . . . 7 5。 グループのメンバー. . . . . . . . 19 6のためのプロトコルの記述。 マルチキャストルータ. . . . . . 24 7のためのプロトコルの記述。 IGMPの旧式のバージョンがあるInteroperation。 . . . . . . . . . 35 8. タイマ、カウンタ、およびそれらのデフォルト値のリスト。 . . . . . 40 9. セキュリティ問題. . . . . . . . . . . . . . . . . . . 43 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . 47 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 47 12。 引用規格。 . . . . . . . . . . . . . . . . . . . . 47 13. 有益な参照。 . . . . . . . . . . . . . . . . . . . 47付録A.は原理を設計します。 . . . . . . . . . . . . . . . . 49 IGMPv2からの変化の付録B.Summary。 . . . . . . . . . 50人の作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 52 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 53
1. Introduction
1. 序論
The Internet Group Management Protocol (IGMP) is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to any neighboring multicast routers. Note that an IP multicast router may itself be a member of one or more multicast groups, in which case it performs both the "multicast router part" of the protocol (to collect the membership information needed by its multicast routing protocol) and the "group member part" of the protocol (to inform itself and other, neighboring multicast routers of its memberships).
IPv4システム(ホストとルータ)によってインターネットGroup Managementプロトコル(IGMP)は使用されて、それらのIPマルチキャストグループ会員資格をどんな隣接しているマルチキャストルータにも報告します。 1つ以上のマルチキャストのメンバーがグループであったならIPマルチキャストルータがそうするかもしれないことにそれ自体で注意してください。その場合では、それはプロトコル(マルチキャストルーティング・プロトコルによって必要とされた会員資格情報を集める)の「マルチキャストルータ部分」とプロトコル(それ自体、および会員資格の他の、そして、隣接しているマルチキャストルータを知らせる)の「グループメンバー部分」の両方を実行します。
IGMP is also used for other IP multicast management functions, using message types other than those used for group membership reporting. This document specifies only the group membership reporting functions and messages.
また、IGMPは他のIPマルチキャスト管理機能に使用されます、グループ会員資格報告に使用されるもの以外のメッセージタイプを使用して。 このドキュメントはグループ会員資格報告機能とメッセージだけを指定します。
This document specifies Version 3 of IGMP. Version 1, specified in [RFC-1112], was the first widely-deployed version and the first version to become an Internet Standard. Version 2, specified in [RFC-2236], added support for "low leave latency", that is, a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network. Version 3 adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, as required to support Source-Specific Multicast [SSM], or from *all but* specific source addresses, sent to a particular multicast address. Version 3 is designed to be interoperable with Versions 1 and 2.
このドキュメントはIGMPのバージョン3を指定します。 [RFC-1112]で指定されたバージョン1は、最初の広く配布しているバージョンとインターネットStandardになる最初のバージョンでした。 [RFC-2236]で指定されたバージョン2は「安値は潜在を残す」(すなわち、わざわざマルチキャストルータが付属ネットワークの現在の特定のグループのどんなメンバーももういないことをそれが学ぶ減少)サポートを加えました。 バージョン3は「ソースフィルタリング」のサポートを加えます、すなわち、システムがパケットだけを受けることへの関心を報告する能力。*特定のソースアドレスから、必要に応じて、サポートのSource特有のMulticast[SSM]、または、*特定のソースを除いた皆が扱う*から、特定のマルチキャストアドレスは発信しています。 バージョン3は、バージョン1と2で共同利用できるように設計されています。
Cain, et. al. Standards Track [Page 2] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[2ページ]RFC3376IGMPv3 October 2002
Multicast Listener Discovery (MLD) is used in a similar way by IPv6 systems. MLD version 1 [MLD] implements the functionality of IGMP version 2; MLD version 2 [MLDv2] implements the functionality of IGMP version 3.
マルチキャストListenerディスカバリー(MLD)はIPv6システムによって同様の方法で使用されます。MLDバージョン1[MLD]はIGMPバージョン2の機能性を実装します。 MLDバージョン2[MLDv2]はIGMPバージョン3の機能性を実装します。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Due to the lack of italics, emphasis is indicated herein by bracketing a word or phrase in "*" characters.
大文字で書かれたキーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか? イタリックの不足のため、強調は、「*」キャラクタの単語か句に腕木を付けることによって、ここに示されます。
2. The Service Interface for Requesting IP Multicast Reception
2. IPマルチキャストレセプションを要求するためのサービスインタフェース
Within an IP system, there is (at least conceptually) a service interface used by upper-layer protocols or application programs to ask the IP layer to enable and disable reception of packets sent to specific IP multicast addresses. In order to take full advantage of the capabilities of IGMPv3, a system's IP service interface must support the following operation:
IPシステムの中に、上側の層のプロトコルかアプリケーション・プログラムによって使用される、特定のIPマルチキャストアドレスに送られたパケットのレセプションを可能にして、無効にするようにIP層に頼むサービスインタフェースがあります(少なくとも概念的に)。 IGMPv3の能力を最大限に利用するために、システムのIPサービスインタフェースは以下の操作をサポートしなければなりません:
IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list )
IPMulticastListen(ソケット、インタフェース、マルチキャストアドレス、フィルタモード、ソース・リスト)
where:
どこ:
o "socket" is an implementation-specific parameter used to
distinguish among different requesting entities (e.g., programs or
processes) within the system; the socket parameter of BSD Unix
system calls is a specific example.
o 「ソケット」はシステムの中の異なった要求実体(例えば、プログラムかプロセス)の中で区別するのに使用される実装特有のパラメタです。 BSD Unixシステムコールのソケットパラメタは特定の例です。
o "interface" is a local identifier of the network interface on which
reception of the specified multicast address is to be enabled or
disabled. Interfaces may be physical (e.g., an Ethernet interface)
or virtual (e.g., the endpoint of a Frame Relay virtual circuit or
the endpoint of an IP-in-IP "tunnel"). An implementation may allow
a special "unspecified" value to be passed as the interface
parameter, in which case the request would apply to the "primary"
or "default" interface of the system (perhaps established by system
configuration). If reception of the same multicast address is
desired on more than one interface, IPMulticastListen is invoked
separately for each desired interface.
o 「インタフェース」は指定されたマルチキャストアドレスのレセプションが可能にされることになっているか、または無効にされることになっているネットワーク・インターフェースのローカルの識別子です。 身体検査が(例えば、イーサネットインタフェース)か仮想であったなら(例えば、IPにおけるIP「トンネル」のFrame Relayの仮想の回路か終点の終点)、インタフェースはそうするかもしれません。 特別な「不特定」の値はインタフェース・パラメータとして実装で通るかもしれません、その場合、要求がシステム(恐らくシステム構成によって設立される)の「予備選挙」か「デフォルト」インタフェースに申し込まれるでしょう。 同じマルチキャストアドレスのレセプションが1つ以上のインタフェースで望まれているなら、IPMulticastListenは別々にそれぞれの必要なインタフェースへ呼び出されます。
o "multicast-address" is the IP multicast address, or group, to which
the request pertains. If reception of more than one multicast
address on a given interface is desired, IPMulticastListen is
invoked separately for each desired multicast address.
o 「マルチキャストアドレス」は、IPマルチキャストアドレス、またはグループです。(要求はそのグループに関係します)。 与えられたインタフェースにおける1つ以上のマルチキャストアドレスのレセプションが望まれているなら、IPMulticastListenはそれぞれの必要なマルチキャストアドレスのために別々に呼び出されます。
Cain, et. al. Standards Track [Page 3] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[3ページ]RFC3376IGMPv3 October 2002
o "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode,
reception of packets sent to the specified multicast address is
requested *only* from those IP source addresses listed in the
source-list parameter. In EXCLUDE mode, reception of packets sent
to the given multicast address is requested from all IP source
addresses *except* those listed in the source-list parameter.
o 「フィルタモード」は、INCLUDEかEXCLUDEのどちらかであるかもしれません。 INCLUDEモードで、指定されたマルチキャストアドレスに送られたパケットのレセプションは*要求されていて、それらのIPソースアドレスからの*だけ、がソース・リストパラメタに記載したということです。 EXCLUDEモードで、与えられたマルチキャストアドレスに送られたパケットのレセプションはものがソース・リストパラメタに記載した*を除いたすべてのIPソースアドレス*から要求されます。
o "source-list" is an unordered list of zero or more IP unicast
addresses from which multicast reception is desired or not desired,
depending on the filter mode. An implementation MAY impose a limit
on the size of source lists, but that limit MUST NOT be less than
64 addresses per list. When an operation causes the source list
size limit to be exceeded, the service interface MUST return an
error.
o 「ソース・リスト」はマルチキャストレセプションが望まれているか、または望まれていないIPユニキャストが扱うゼロか以上の順不同のリストです、フィルタモードによって。 実装はソース・リストのサイズで指し値するかもしれませんが、1リストあたりその限界は64未満のアドレスであるはずがありません。 操作でソース・リストサイズ限界を超えていると、サービスインタフェースは誤りを返さなければなりません。
For a given combination of socket, interface, and multicast address, only a single filter mode and source list can be in effect at any one time. However, either the filter mode or the source list, or both, may be changed by subsequent IPMulticastListen requests that specify the same socket, interface, and multicast address. Each subsequent request completely replaces any earlier request for the given socket, interface and multicast address.
ソケットの与えられた組み合わせには、連結してください。そうすれば、マルチキャストアドレス、ただ一つのフィルタモード、およびソース・リストだけがいかなる時も、有効である場合があります。 しかしながら、同じソケット、インタフェース、およびマルチキャストアドレスを指定するその後のIPMulticastListen要求でフィルタモードソース・リスト、または両方のどちらかを変えるかもしれません。 それぞれのその後の要求は与えられたソケット、インタフェース、およびマルチキャストアドレスを求めるどんな以前の要求にも完全に取って代わります。
Previous versions of IGMP did not support source filters and had a simpler service interface consisting of Join and Leave operations to enable and disable reception of a given multicast address (from *all* sources) on a given interface. The equivalent operations in the new service interface follow:
IGMPの旧バージョンは、ソースにフィルタを支えないで、与えられたマルチキャストアドレスのレセプションが与えられたインタフェースの(*からのすべての*ソース)であると可能にして、無効にするためにJoinとLeave操作から成るより簡単なサービスインタフェースを持っていました。 新しいサービスインタフェースでの同等な操作は続きます:
The Join operation is equivalent to
操作が相当しているJoin
IPMulticastListen ( socket, interface, multicast-address,
EXCLUDE, {} )
IPMulticastListen(ソケット、インタフェース、マルチキャストアドレス、EXCLUDE、)
and the Leave operation is equivalent to:
そして、Leave操作は以下に同等です。
IPMulticastListen ( socket, interface, multicast-address,
INCLUDE, {} )
IPMulticastListen(ソケット、インタフェース、マルチキャストアドレス、INCLUDE、)
where {} is an empty source list.
どこ、空のソース・リストはそうであるか。
An example of an API providing the capabilities outlined in this service interface is in [FILTER-API].
このサービスインタフェースに概説された能力を提供するAPIに関する例が[FILTER-API]にあります。
Cain, et. al. Standards Track [Page 4] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[4ページ]RFC3376IGMPv3 October 2002
3. Multicast Reception State Maintained by Systems
3. システムによって維持されたマルチキャストレセプション状態
3.1. Socket State
3.1. ソケット状態
For each socket on which IPMulticastListen has been invoked, the system records the desired multicast reception state for that socket. That state conceptually consists of a set of records of the form:
IPMulticastListenが呼び出された各ソケットに関しては、システムはそのソケットのために必要なマルチキャストレセプション状態を記録します。 その状態はフォームに関する記録のセットから概念的に成ります:
(interface, multicast-address, filter-mode, source-list)
(インタフェース、マルチキャストアドレス、フィルタモード、ソース・リスト)
The socket state evolves in response to each invocation of IPMulticastListen on the socket, as follows:
ソケット状態は以下の通りソケットでIPMulticastListenの各実施に対応して発展します:
o If the requested filter mode is INCLUDE *and* the requested source
list is empty, then the entry corresponding to the requested
interface and multicast address is deleted if present. If no such
entry is present, the request is ignored.
o *要求されたフィルタモードがINCLUDE*であり、要求されたソース・リストが空であるなら、存在しているなら、要求されたインタフェースとマルチキャストアドレスに対応するエントリーは削除されます。 そのようなどれかエントリーが存在していないなら、要求は無視されます。
o If the requested filter mode is EXCLUDE *or* the requested source
list is non-empty, then the entry corresponding to the requested
interface and multicast address, if present, is changed to contain
the requested filter mode and source list. If no such entry is
present, a new entry is created, using the parameters specified in
the request.
o *要求されたフィルタモードがEXCLUDE*であるか要求されたソース・リストが非空であるなら、存在しているなら、要求されたフィルタモードとソース・リストを含むように要求されたインタフェースとマルチキャストアドレスに対応するエントリーを変えます。 そのようなどれかエントリーが存在していないなら、要求で指定されたパラメタを使用して、新しいエントリーは作成されます。
3.2. Interface State
3.2. 界面準位
In addition to the per-socket multicast reception state, a system
must also maintain or compute multicast reception state for each of
its interfaces. That state conceptually consists of a set of
records of the form:
1ソケットあたりのマルチキャストレセプション状態に加えて、システムは、また、マルチキャストレセプション状態をそれぞれのインタフェースに維持しなければならないか、または計算しなければなりません。 その状態はフォームに関する記録のセットから概念的に成ります:
(multicast-address, filter-mode, source-list)
(マルチキャストアドレス、フィルタモード、ソース・リスト)
At most one record per multicast-address exists for a given
interface. This per-interface state is derived from the per-socket
state, but may differ from the per-socket state when different
sockets have differing filter modes and/or source lists for the
same multicast address and interface. For example, suppose one
application or process invokes the following operation on socket
s1:
高々、マルチキャストアドレスあたり1つの記録が与えられたインタフェースに存在しています。 1ソケットあたりの状態からこの界面準位を得ます、異なったソケットに同じマルチキャストアドレスのための異なったフィルタモード、そして/または、ソース・リストがあるとき、1ソケットあたりの状態と異なっていて、連結するかもしれないのを除いて。 例えば、1つのアプリケーションかプロセスがソケットs1に以下の操作を呼び出すと仮定してください:
IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
IPMulticastListen(s1、i、m、INCLUDE、a、b、c)
requesting reception on interface i of packets sent to multicast
address m, *only* if they come from source a, b, or c. Suppose
another application or process invokes the following operation on
socket s2:
パケットのインタフェースiでレセプションを要求するのはマルチキャストアドレスmに発信しました、**ソースa、b、またはcから来る場合にだけ。 別のアプリケーションかプロセスがソケットs2に以下の操作を呼び出すと仮定してください:
Cain, et. al. Standards Track [Page 5] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[5ページ]RFC3376IGMPv3 October 2002
IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
IPMulticastListen(s2、i、m、INCLUDE、b、c、d)
requesting reception on the same interface i of packets sent to the
same multicast address m, *only* if they come from sources b, c, or
d. In order to satisfy the reception requirements of both sockets,
it is necessary for interface i to receive packets sent to m from
any one of the sources a, b, c, or d. Thus, in this example, the
reception state of interface i for multicast address m has filter
mode INCLUDE and source list {a, b, c, d}.
パケットの同じインタフェースiでレセプションを要求するのは同じマルチキャストアドレスmに発信しました、**ソースb、c、またはdから来る場合にだけ。 両方のソケットのレセプション要件を満たすために、インタフェースiがソースa、b、c、またはdのいずれからもmに送られたパケットを受けるのが必要です。 したがって、この例では、マルチキャストアドレスmインタフェースiのレセプション州はフィルタモードINCLUDEと情報筋にa、b、c、dを記載させます。
After a multicast packet has been accepted from an interface by the
IP layer, its subsequent delivery to the application or process
listening on a particular socket depends on the multicast reception
state of that socket [and possibly also on other conditions, such
as what transport-layer port the socket is bound to]. So, in the
above example, if a packet arrives on interface i, destined to
multicast address m, with source address a, it will be delivered on
socket s1 but not on socket s2. Note that IGMP Queries and Reports
are not subject to source filtering and must always be processed by
hosts and routers.
IP層のそばでインタフェースからマルチキャストパケットを受け入れた後に、特定のソケットの上に聴かれるアプリケーションかプロセスへのその後の配送はそのソケット[そしてことによるとソケットがどんなトランスポート層ポートに制限されているかなどの他の条件でも]のマルチキャストレセプション状態に依存します。 それは、それで、パケットがソースと共にマルチキャストアドレスmに運命づけられたインタフェースiで到着するなら、上記の例では、aを扱ってください、そして、ソケットs1で提供されますが、ソケットs2で提供されるというわけではないでしょう。 IGMP QueriesとReportsをソースフィルタリングを受けることがなくて、ホストとルータでいつも処理しなければならないことに注意してください。
Filtering of packets based upon a socket's multicast reception
state is a new feature of this service interface. The previous
service interface [RFC1112] described no filtering based upon
multicast join state; rather, a join on a socket simply caused the
host to join a group on the given interface, and packets destined
for that group could be delivered to all sockets whether they had
joined or not.
ソケットのマルチキャストレセプション状態に基づくパケットのフィルタリングはこのサービスインタフェースに関する新機能です。 マルチキャストに基づく前のサービスインタフェース[RFC1112]説明されたノーフィルタリングは状態に加わります。 むしろ、aは当然のことのインタフェースで仲間に入ることが単にホストに引き起こされたソケットを合します、そして、それらが接合したか否かに関係なく、そのグループのために運命づけられたパケットはすべてのソケットに提供できました。
The general rules for deriving the per-interface state from the
per-socket state are as follows: For each distinct (interface,
multicast-address) pair that appears in any socket state, a per-
interface record is created for that multicast address on that
interface. Considering all socket records containing the same
(interface, multicast-address) pair,
1ソケットあたりの状態から界面準位を得るための総則は以下の通りです: それぞれの異なった(インタフェース、マルチキャストアドレス)組に関して、それはどんなソケット状態にも現れます、a、-、インタフェース記録がそのマルチキャストアドレスのためにそのインタフェースで作成されます。 同じ(インタフェース、マルチキャストアドレス)組を含んでいて、すべてのソケットを考えるのは記録します。
o if *any* such record has a filter mode of EXCLUDE, then the filter
mode of the interface record is EXCLUDE, and the source list of the
interface record is the intersection of the source lists of all
socket records in EXCLUDE mode, minus those source addresses that
appear in any socket record in INCLUDE mode. For example, if the
socket records for multicast address m on interface i are:
o **そのような記録にEXCLUDEのフィルタモードがいくらかあるなら、インタフェース記録のフィルタモードはEXCLUDEです、そして、インタフェース記録に関するソース・リストはEXCLUDEモードによるすべてのソケット記録に関するソース・リストの交差点です、INCLUDEモードによるどんなソケット記録にも現れるそれらのソースアドレスを引いて。 例えば、ソケットであるなら、インタフェースiのマルチキャストアドレスm記録は以下の通りです。
from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3: ( i, m, INCLUDE, {d, e, f} )
ソケットs1から: (i、m、EXCLUDE、a、b、c、d) ソケットs2から: (i、m、EXCLUDE、b、c、d、e) ソケットs3から: (i、m、INCLUDE、d、e、f)
Cain, et. al. Standards Track [Page 6] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[6ページ]RFC3376IGMPv3 October 2002
then the corresponding interface record on interface i is:
そして、インタフェースiに関する対応するインタフェース記録は以下の通りです。
( m, EXCLUDE, {b, c} )
(m、EXCLUDE、b、c)
If a fourth socket is added, such as:
4分の1であるなら、ソケットは以下のように加えられます。
from socket s4: ( i, m, EXCLUDE, {} )
ソケットs4から: (i、m、EXCLUDE、)
then the interface record becomes:
次に、インタフェース記録はなります:
( m, EXCLUDE, {} )
(m、EXCLUDE、)
o if *all* such records have a filter mode of INCLUDE, then the
filter mode of the interface record is INCLUDE, and the source list
of the interface record is the union of the source lists of all the
socket records. For example, if the socket records for multicast
address m on interface i are:
o *そのようなものが記録するすべての*がINCLUDEのフィルタモードを持っているなら、インタフェース記録のフィルタモードはINCLUDEです、そして、インタフェース記録に関するソース・リストはすべてのソケット記録に関するソース・リストの組合です。 例えば、ソケットであるなら、インタフェースiのマルチキャストアドレスm記録は以下の通りです。
from socket s1: ( i, m, INCLUDE, {a, b, c} )
from socket s2: ( i, m, INCLUDE, {b, c, d} )
from socket s3: ( i, m, INCLUDE, {e, f} )
ソケットs1から: (i、m、INCLUDE、a、b、c) ソケットs2から: (i、m、INCLUDE、b、c、d) ソケットs3から: (i、m、INCLUDE、e、f)
then the corresponding interface record on interface i is:
そして、インタフェースiに関する対応するインタフェース記録は以下の通りです。
( m, INCLUDE, {a, b, c, d, e, f} )
(m、INCLUDE、a、b、c、d、e、f)
An implementation MUST NOT use an EXCLUDE interface record to
represent a group when all sockets for this group are in INCLUDE
state. If system resource limits are reached when an interface
state source list is calculated, an error MUST be returned to the
application which requested the operation.
実装は、このグループのためのすべてのソケットがINCLUDE状態にあるとき、グループを代表するのにEXCLUDEインタフェース記録を使用してはいけません。 界面準位ソース・リストが計算されるとき、システム資源限界に達しているなら、操作を要求したアプリケーションに誤りを返さなければなりません。
The above rules for deriving the interface state are (re-)evaluated whenever an IPMulticastListen invocation modifies the socket state by adding, deleting, or modifying a per-socket state record. Note that a change of socket state does not necessarily result in a change of interface state.
界面準位を引き出すための上の規則がそうである、(再、)、IPMulticastListen実施が加えるのによる削除しているソケット状態を変更するときはいつも、評価されるか、または1ソケットあたり1つの状態を変更して、記録してください。 ソケット状態の変化が必ず界面準位の変化をもたらすというわけではないことに注意してください。
4. Message Formats
4. メッセージ・フォーマット
IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2. Every IGMP message described in this document is sent with an IP Time-to-Live of 1, IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option [RFC-2113] in its IP header. IGMP message types are registered by the IANA [IANA-REG] as described by [RFC-3228].
IGMPメッセージはIPv4データグラムで2のIPプロトコル番号でカプセル化されます。 本書では説明されたあらゆるIGMPメッセージが、生きるIP Timeと共に1、Internetwork Control(例えば、Service 0xc0のType)のIP Precedenceについて送られて、IPヘッダーでIP Router Alertオプション[RFC-2113]を運びます。 [RFC-3228]によって説明されるようにIGMPメッセージタイプはIANA[IANA-REG]によって示されます。
Cain, et. al. Standards Track [Page 7] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[7ページ]RFC3376IGMPv3 October 2002
There are two IGMP message types of concern to the IGMPv3 protocol described in this document:
本書では説明されたIGMPv3プロトコルに重要な2つのIGMPメッセージタイプがあります:
Type Number (hex) Message Name
----------------- ------------
形式数(十六進法)メッセージ名----------------- ------------
0x11 Membership Query
0×11会員資格質問
0x22 Version 3 Membership Report
0×22 バージョン3会員資格レポート
An implementation of IGMPv3 MUST also support the following three message types, for interoperation with previous versions of IGMP (see section 7):
また、IGMPv3の実装は、以下の3メッセージがタイプであるとサポートしなければなりません、IGMPの旧バージョンがあるinteroperationのために(セクション7を見てください):
0x12 Version 1 Membership Report [RFC-1112]
0×12 バージョン1会員資格レポート[RFC-1112]
0x16 Version 2 Membership Report [RFC-2236]
0×16 バージョン2会員資格レポート[RFC-2236]
0x17 Version 2 Leave Group [RFC-2236]
0×17 バージョン2はグループを出ます。[RFC-2236]
Unrecognized message types MUST be silently ignored. Other message types may be used by newer versions or extensions of IGMP, by multicast routing protocols, or for other uses.
静かに認識されていないメッセージタイプを無視しなければなりません。 他のメッセージタイプはIGMPの、より新しいバージョンか拡大、マルチキャストルーティング・プロトコル、または他の用途に使用されるかもしれません。
In this document, unless otherwise qualified, the capitalized words "Query" and "Report" refer to IGMP Membership Queries and IGMP Version 3 Membership Reports, respectively.
本書では、別の方法で資格がない場合、大文字で書かれた単語は、IGMP Membership QueriesとIGMPバージョン3Membership Reportsがそれぞれ言及すると「質問し」て、「報告します」。
4.1. Membership Query Message
4.1. 会員資格質問メッセージ
Membership Queries are sent by IP multicast routers to query the multicast reception state of neighboring interfaces. Queries have the following format:
IPマルチキャストルータで会員資格Queriesを送って、インタフェースを近所付き合いさせるマルチキャストレセプション状態について質問します。 質問には、以下の形式があります:
Cain, et. al. Standards Track [Page 8] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[8ページ]RFC3376IGMPv3 October 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- . -+
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x11をタイプしてください。| マックスResp Code| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv|S| QRV| QQIC| ソース(N)の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス[1]| +- -+ | ソースアドレス[2]| +- . -+ . . . . . . +- -+ | ソースアドレス[N]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Max Resp Code
4.1.1. マックスResp Code
The Max Resp Code field specifies the maximum time allowed before sending a responding report. The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows:
応じるレポートを送る前に、マックスResp Code分野は最大の日限を指定します。 マックスResp Timeと呼ばれる実際の日限を、ユニットの2番目に表して、以下のマックスResp Codeから得ます:
If Max Resp Code < 128, Max Resp Time = Max Resp Code
マックスRespが<128をコード化するなら、マックスResp TimeはマックスResp Codeと等しいです。
If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows:
マックスResp Code>=128であるなら、マックスResp Codeは以下の浮動小数点の値を表します:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1| exp| mant| +-+-+-+-+-+-+-+-+
Max Resp Time = (mant | 0x10) << (exp + 3)
マックスResp Timeは<<と等しいです(mant| 0×10)。(exp+3)
Small values of Max Resp Time allow IGMPv3 routers to tune the "leave latency" (the time between the moment the last host leaves a group and the moment the routing protocol is notified that there are no more members). Larger values, especially in the exponential range, allow tuning of the burstiness of IGMP traffic on a network.
マックスResp Timeの小さい値が調整するルータをIGMPv3に許容する、「潜在を残してください。」(最後のホストがグループを残す瞬間、ルーティング・プロトコルがそれ以上のメンバーが全くいないように通知される瞬間の間の時間) 特に指数の範囲では、より大きい値が、ネットワークに調整するのをIGMPトラフィックのburstinessを許容します。
Cain, et. al. Standards Track [Page 9] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[9ページ]RFC3376IGMPv3 October 2002
4.1.2. Checksum
4.1.2. チェックサム
The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet. [RFC-1071]
Checksumは全体のIGMPメッセージ(全体のIPペイロード)の1の補数合計の16ビットの1の補数です。 チェックサムを計算するのにおいて、Checksum分野はゼロに設定されます。 パケットを受けるとき、パケットを処理する前に、チェックサムについて確かめなければなりません。 [RFC-1071]
4.1.3. Group Address
4.1.3. グループアドレス
The Group Address field is set to zero when sending a General Query, and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query (see section 4.1.9, below).
Group特有のQueryかGroupの、そして、ソース特有のQueryを送るとき質問されるIPマルチキャストアドレスにQuery司令官、およびセットを送るとき、Group Address分野はゼロに設定されます(以下でセクション4.1.9を見てください)。
4.1.4. Resv (Reserved)
4.1.4. Resv(予約される)です。
The Resv field is set to zero on transmission, and ignored on reception.
Resv分野は、トランスミッションのときにゼロに設定されて、レセプションで無視されます。
4.1.5. S Flag (Suppress Router-Side Processing)
4.1.5. S旗(ルータサイド処理を抑圧します)
When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. It does not, however, suppress the querier election or the normal "host-side" processing of a Query that a router may be required to perform as a consequence of itself being a group member.
1つに設定されると、S Flagは、Queryを聞くのに実行する通常のタイマアップデートを抑圧することになっているのをどんな受信マルチキャストルータにも示します。 しかしながら、それは、グループのメンバーであるのでquerier選挙かルータがそれ自体の結果として実行するのに必要であるかもしれないQueryの通常の「ホスト側」処理を抑圧しません。
4.1.6. QRV (Querier's Robustness Variable)
4.1.6. QRV(Querierの丈夫さ変数)
If non-zero, the QRV field contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. If the querier's [Robustness Variable] exceeds 7, the maximum value of the QRV field, the QRV is set to zero. Routers adopt the QRV value from the most recently received Query as their own [Robustness Variable] value, unless that most recently received QRV was zero, in which case the receivers use the default [Robustness Variable] value specified in section 8.1 or a statically configured value.
非ゼロであるなら、QRV分野はすなわち、querier、Queryの送付者によって使用された[丈夫さVariable]値を含んでいます。 querierのもの[丈夫さVariable]が7、QRV分野の最大値を超えているなら、QRVはゼロに用意ができています。 それら自身の[丈夫さVariable]が評価するようにルータは最も最近容認されたQueryからQRV値を採用します、そのごく最近容認されたQRVがゼロでなかったなら、その場合、受信機がセクション8.1で指定されたデフォルト[丈夫さVariable]値か静的に構成された値を使用します。
4.1.7. QQIC (Querier's Query Interval Code)
4.1.7. QQIC(Querierの質問間隔コード)
The Querier's Query Interval Code field specifies the [Query Interval] used by the querier. The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows:
QuerierのQuery Interval Code分野が指定する、querierによって使用された[質問Interval。] QuerierのQuery Interval(QQI)と呼ばれる実際の間隔を、ユニットの秒に表して、以下のQuerierのQuery Interval Codeから得ます:
Cain, et. al. Standards Track [Page 10] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[10ページ]RFC3376IGMPv3 October 2002
If QQIC < 128, QQI = QQIC
QQIC<128、QQIがQQICと等しいなら
If QQIC >= 128, QQIC represents a floating-point value as follows:
QQIC>=128であるなら、QQICは以下の浮動小数点の値を表します:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1| exp| mant| +-+-+-+-+-+-+-+-+
QQI = (mant | 0x10) << (exp + 3)
QQIは<<と等しいです(mant| 0×10)。(exp+3)
Multicast routers that are not the current querier adopt the QQI value from the most recently received Query as their own [Query Interval] value, unless that most recently received QQI was zero, in which case the receiving routers use the default [Query Interval] value specified in section 8.2.
それら自身の[質問Interval]が評価するようにデフォルト[質問Interval]値がセクション8.2で受信ルータが使用するどのケースを指定したかで現在のquerierでないマルチキャストルータはそのごく最近容認されたQQIがゼロでなかったなら最も最近容認されたQueryからQQI値を採用します。
4.1.8. Number of Sources (N)
4.1.8. ソースの数(N)
The Number of Sources (N) field specifies how many source addresses are present in the Query. This number is zero in a General Query or a Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. This number is limited by the MTU of the network over which the Query is transmitted. For example, on an Ethernet with an MTU of 1500 octets, the IP header including the Router Alert option consumes 24 octets, and the IGMP fields up to including the Number of Sources (N) field consume 12 octets, leaving 1464 octets for source addresses, which limits the number of source addresses to 366 (1464/4).
Sources(N)分野のNumberは、Queryでいくつのソースアドレスが存在しているかを指定します。 この数は、Query司令官かGroup特有のQueryのゼロと、Groupの、そして、ソース特有のQueryの非ゼロです。 この数はQueryが伝えられるネットワークのMTUによって制限されます。 例えば、1500の八重奏のMTUがあるイーサネットでは、Router Alertオプションを含むIPヘッダーは24の八重奏を消費します、そして、Sources(N)のNumberを含んでいるまでの分野がさばくIGMPは12の八重奏を消費します、ソースアドレス(ソースアドレスの数を366(1464/4)に制限するもの)に1464の八重奏を残して
4.1.9. Source Address [i]
4.1.9. ソースアドレス[i]
The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in the Number of Sources (N) field.
Source Address[i]分野はn IPユニキャストアドレスのベクトルです。そこでは、nがSources(N)分野のNumberの値です。
4.1.10. Additional Data
4.1.10. 追加データ
If the Packet Length field in the IP header of a received Query indicates that there are additional octets of data present, beyond the fields described here, IGMPv3 implementations MUST include those octets in the computation to verify the received IGMP Checksum, but MUST otherwise ignore those additional octets. When sending a Query, an IGMPv3 implementation MUST NOT include additional octets beyond the fields described here.
容認されたQueryのIPヘッダーのPacket Length分野が、ここで説明された分野を超えた現在のデータの追加八重奏があるのを示すなら、IGMPv3実装は、容認されたIGMP Checksumについて確かめるために計算におけるそれらの八重奏を含まなければなりませんが、別の方法でそれらの追加八重奏を無視しなければなりません。 Queryを送るとき、IGMPv3実装はここで説明された分野を超えて追加八重奏を含んではいけません。
Cain, et. al. Standards Track [Page 11] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[11ページ]RFC3376IGMPv3 October 2002
4.1.11. Query Variants
4.1.11. 質問異形
There are three variants of the Query message:
Queryメッセージの3つの異形があります:
1. A "General Query" is sent by a multicast router to learn the
complete multicast reception state of the neighboring interfaces
(that is, the interfaces attached to the network on which the
Query is transmitted). In a General Query, both the Group Address
field and the Number of Sources (N) field are zero.
1. マルチキャストルータで「一般質問」を送って、近所付き合いの完全なマルチキャストレセプション状態が連結することを(すなわち、インタフェースはQueryが伝えられるネットワークに付きました)学びます。 Query司令官では、Group Address分野とSources(N)のNumberがさばく両方がゼロです。
2. A "Group-Specific Query" is sent by a multicast router to learn
the reception state, with respect to a *single* multicast address,
of the neighboring interfaces. In a Group-Specific Query, the
Group Address field contains the multicast address of interest,
and the Number of Sources (N) field contains zero.
2. マルチキャストルータで「グループ特有の質問」を送って、レセプション状態を学びます、隣接しているインタフェースの*ただ一つの*マルチキャストアドレスに関して。 Group特有のQueryでは、Group Address分野は興味深いマルチキャストアドレスを含んでいます、そして、Sources(N)分野のNumberはゼロを含んでいます。
3. A "Group-and-Source-Specific Query" is sent by a multicast router
to learn if any neighboring interface desires reception of packets
sent to a specified multicast address, from any of a specified
list of sources. In a Group-and-Source-Specific Query, the Group
Address field contains the multicast address of interest, and the
Source Address [i] fields contain the source address(es) of
interest.
3. マルチキャストルータで「グループの、そして、ソース特有の質問」を送って、もしあればパケットのレセプションが指定されたマルチキャストアドレスに送った隣接しているインタフェース願望を学びます、ソースに関する明細表のいずれからも。 Groupの、そして、ソース特有のQueryでは、Group Address分野は興味深いマルチキャストアドレスを含んでいます、そして、Source Address[i]分野は興味深いソースアドレス(es)を含んでいます。
4.1.12. IP Destination Addresses for Queries
4.1.12. 質問のためのIP送付先アドレス
In IGMPv3, General Queries are sent with an IP destination address of 224.0.0.1, the all-systems multicast address. Group-Specific and Group-and-Source-Specific Queries are sent with an IP destination address equal to the multicast address of interest. *However*, a system MUST accept and process any Query whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Query arrives.
IGMPv3では、224.0の受信者IPアドレスと共にQueries司令官を送ります。.0 .1、オールシステムマルチキャストアドレス。 マルチキャストアドレスと等しい受信者IPアドレスが興味深い状態でグループ特有の、そして、Groupの、そして、ソース特有のQueriesを送ります。 **しかしながら、システムは、IP Destination Address分野がアドレス(ユニキャストかマルチキャスト)のどんな*もQueryが到着するインタフェースに割り当てた*を含むどんなQueryも受け入れて、処理しなければなりません。
4.2. Version 3 Membership Report Message
4.2. バージョン3会員資格レポートメッセージ
Version 3 Membership Reports are sent by IP systems to report (to neighboring routers) the current multicast reception state, or changes in the multicast reception state, of their interfaces. Reports have the following format:
バージョン3Membership ReportsはIPシステムで送って、現在のマルチキャストレセプション状態を報告するか(隣接しているルータに)、またはそれらのインタフェースのマルチキャストレセプション状態で変化します。 レポートには、以下の形式があります:
Cain, et. al. Standards Track [Page 12] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[12ページ]RFC3376IGMPv3 October 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x22をタイプしてください。| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| グループ・レコード(M)の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 記録[1]を分類してください…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 記録[2]を分類してください…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 記録[M]を分類してください…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cain, et. al. Standards Track [Page 13] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[13ページ]RFC3376IGMPv3 October 2002
where each Group Record has the following internal format:
各Group Recordが以下を内部にするところでは、以下をフォーマットしてください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- -+
. . .
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | レコード種類| 補助のDataレン| ソース(N)の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースアドレス[1]| +- -+ | ソースアドレス[2]| +- -+ . . . . . . . . . +- -+ | ソースアドレス[N]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 補助のデータ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.1. Reserved
4.2.1. 予約されます。
The Reserved fields are set to zero on transmission, and ignored on reception.
Reserved分野は、トランスミッションのときにゼロに設定されて、レセプションで無視されます。
4.2.2. Checksum
4.2.2. チェックサム
The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a message.
Checksumは全体のIGMPメッセージ(全体のIPペイロード)の1の補数合計の16ビットの1の補数です。 チェックサムを計算するのにおいて、Checksum分野はゼロに設定されます。 パケットを受けるとき、メッセージを処理する前に、チェックサムについて確かめなければなりません。
4.2.3. Number of Group Records (M)
4.2.3. グループ・レコードの数(M)
The Number of Group Records (M) field specifies how many Group Records are present in this Report.
Group Records(M)分野のNumberは、このReportでいくつのGroup Recordsが存在しているかを指定します。
4.2.4. Group Record
4.2.4. グループ・レコード
Each Group Record is a block of fields containing information pertaining to the sender's membership in a single multicast group on the interface from which the Report is sent.
各Group RecordはReportが送られるインタフェースに関するただ一つのマルチキャストグループで送付者の会員資格に関係する情報を含む1ブロックの分野です。
Cain, et. al. Standards Track [Page 14] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[14ページ]RFC3376IGMPv3 October 2002
4.2.5. Record Type
4.2.5. レコード種類
See section 4.2.12, below.
セクション4.2.12未満を見てください。
4.2.6. Aux Data Len
4.2.6. 補助のDataレン
The Aux Data Len field contains the length of the Auxiliary Data field in this Group Record, in units of 32-bit words. It may contain zero, to indicate the absence of any auxiliary data.
Aux Dataレン分野はこのGroup RecordのAuxiliary Data分野の長さを含んでいます、ユニットの32ビットの単語で。 それは、どんな補助のデータの欠如も示すためにゼロを含むかもしれません。
4.2.7. Number of Sources (N)
4.2.7. ソースの数(N)
The Number of Sources (N) field specifies how many source addresses are present in this Group Record.
Sources(N)分野のNumberは、このGroup Recordでいくつのソースアドレスが存在しているかを指定します。
4.2.8. Multicast Address
4.2.8. マルチキャストアドレス
The Multicast Address field contains the IP multicast address to which this Group Record pertains.
Multicast Address分野はこのGroup Recordが関係するIPマルチキャストアドレスを含んでいます。
4.2.9. Source Address [i]
4.2.9. ソースアドレス[i]
The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in this record's Number of Sources (N) field.
Source Address[i]分野はSources(N)のNumberがさばくn IPユニキャストアドレスのベクトルです。そこでは、nが記録のこのところの値です。
4.2.10. Auxiliary Data
4.2.10. 補助のデータ
The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. The protocol specified in this document, IGMPv3, does not define any auxiliary data. Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, and MUST ignore any auxiliary data present in any received Group Record. The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field.
存在しているなら、Auxiliary Data分野はこのGroup Recordに関係する追加情報を含んでいます。 本書では指定されたプロトコル(IGMPv3)は少しの補助のデータも定義しません。 したがって、IGMPv3の実装は、どんな伝えられたGroup Recordにも少しの補助のデータも含んではいけなくて(すなわち、Aux Dataレン分野をゼロに設定しなければなりません)、どんな容認されたGroup Recordの現在のどんな補助のデータも無視しなければなりません。 Auxiliary Data分野の意味論と内部のコード化はこの分野を使用するIGMPのどんな将来のバージョンや拡大でも定義されることです。
4.2.11. Additional Data
4.2.11. 追加データ
If the Packet Length field in the IP header of a received Report indicates that there are additional octets of data present, beyond the last Group Record, IGMPv3 implementations MUST include those octets in the computation to verify the received IGMP Checksum, but MUST otherwise ignore those additional octets. When sending a Report, an IGMPv3 implementation MUST NOT include additional octets beyond the last Group Record.
容認されたReportのIPヘッダーのPacket Length分野が、最後のGroup Recordを超えた現在のデータの追加八重奏があるのを示すなら、IGMPv3実装は、容認されたIGMP Checksumについて確かめるために計算におけるそれらの八重奏を含まなければなりませんが、別の方法でそれらの追加八重奏を無視しなければなりません。 Reportを送るとき、IGMPv3実装は最後のGroup Recordを超えて追加八重奏を含んではいけません。
Cain, et. al. Standards Track [Page 15] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[15ページ]RFC3376IGMPv3 October 2002
4.2.12. Group Record Types
4.2.12. グループ・レコードタイプ
There are a number of different types of Group Records that may be included in a Report message:
Reportメッセージに含まれるかもしれないGroup Recordsの多くの異なったタイプがあります:
o A "Current-State Record" is sent by a system in response to a Query
received on an interface. It reports the current reception state
of that interface, with respect to a single multicast address. The
Record Type of a Current-State Record may be one of the following
two values:
o システムはインタフェースに受け取られたQueryに対応して「現状記録」を送ります。 それはただ一つのマルチキャストアドレスに関してそのインタフェースの現在のレセプション状態を報告します。 Current-州のRecordのRecord Typeは以下の2つの値の1つであるかもしれません:
Value Name and Meaning
----- ----------------
値の名と意味----- ----------------
1 MODE_IS_INCLUDE - indicates that the interface has a
filter mode of INCLUDE for the specified multicast
address. The Source Address [i] fields in this Group
Record contain the interface's source list for the
specified multicast address, if it is non-empty.
1 MODE_は_INCLUDEです--インタフェースには指定されたマルチキャストアドレスのためのINCLUDEのフィルタモードがあるのを示します。 このGroup RecordのSource Address[i]分野は指定されたマルチキャストアドレスのためのインタフェースのソース・リストを含んでいます、それが非空であるなら。
2 MODE_IS_EXCLUDE - indicates that the interface has a
filter mode of EXCLUDE for the specified multicast
address. The Source Address [i] fields in this Group
Record contain the interface's source list for the
specified multicast address, if it is non-empty.
2 MODE_は_EXCLUDEです--インタフェースには指定されたマルチキャストアドレスのためのEXCLUDEのフィルタモードがあるのを示します。 このGroup RecordのSource Address[i]分野は指定されたマルチキャストアドレスのためのインタフェースのソース・リストを含んでいます、それが非空であるなら。
o A "Filter-Mode-Change Record" is sent by a system whenever a local
invocation of IPMulticastListen causes a change of the filter mode
(i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
INCLUDE), of the interface-level state entry for a particular
multicast address. The Record is included in a Report sent from
the interface on which the change occurred. The Record Type of a
Filter-Mode-Change Record may be one of the following two values:
o IPMulticastListenの地方の実施がフィルタモード(すなわち、INCLUDEからEXCLUDEまでEXCLUDEからINCLUDEまでの変化)、特定のマルチキャストアドレスのためのインタフェースレベル州のエントリーの変化を引き起こすときはいつも、システムは「フィルタモード変更記録」を送ります。 Recordは変化が起こったインタフェースから送られたReportに含まれています。 Filterモード変化RecordのRecord Typeは以下の2つの値の1つであるかもしれません:
3 CHANGE_TO_INCLUDE_MODE - indicates that the interface
has changed to INCLUDE filter mode for the specified
multicast address. The Source Address [i] fields
in this Group Record contain the interface's new
source list for the specified multicast address,
if it is non-empty.
3 CHANGE_TO_INCLUDE_MODE--インタフェースが指定されたマルチキャストアドレスのためにINCLUDEフィルタモードに変化したのを示します。 このGroup RecordのSource Address[i]分野は指定されたマルチキャストアドレスのためのインタフェースの新しいソース・リストを含んでいます、それが非空であるなら。
4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface
has changed to EXCLUDE filter mode for the specified
multicast address. The Source Address [i] fields
in this Group Record contain the interface's new
source list for the specified multicast address,
if it is non-empty.
4 CHANGE_TO_EXCLUDE_MODE--インタフェースが指定されたマルチキャストアドレスのためにEXCLUDEフィルタモードに変化したのを示します。 このGroup RecordのSource Address[i]分野は指定されたマルチキャストアドレスのためのインタフェースの新しいソース・リストを含んでいます、それが非空であるなら。
Cain, et. al. Standards Track [Page 16] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[16ページ]RFC3376IGMPv3 October 2002
o A "Source-List-Change Record" is sent by a system whenever a local
invocation of IPMulticastListen causes a change of source list that
is *not* coincident with a change of filter mode, of the
interface-level state entry for a particular multicast address.
The Record is included in a Report sent from the interface on which
the change occurred. The Record Type of a Source-List-Change
Record may be one of the following two values:
o IPMulticastListenの地方の実施がフィルタモード、特定のマルチキャストアドレスのためのインタフェースレベル州のエントリーの変化で*コインシデンスではなく、*であるソース・リストの変化を引き起こすときはいつも、システムは「ソースリスト改訂記録」を送ります。 Recordは変化が起こったインタフェースから送られたReportに含まれています。 Sourceリスト変化RecordのRecord Typeは以下の2つの値の1つであるかもしれません:
5 ALLOW_NEW_SOURCES - indicates that the Source Address
[i] fields in this Group Record contain a list of the
additional sources that the system wishes to
hear from, for packets sent to the specified
multicast address. If the change was to an INCLUDE
source list, these are the addresses that were added
to the list; if the change was to an EXCLUDE source
list, these are the addresses that were deleted from
the list.
5 ALLOW_NEW_SOURCES--指定されたマルチキャストアドレスに送られたパケットのためにこのGroup RecordのSource Address[i]分野がシステムが連絡をいただきたがっている追加ソースのリストを含むのを示します。 INCLUDEソース・リストに変化があったなら、これらはリストに追加されたアドレスです。 EXCLUDEソース・リストに変化があったなら、これらはリストから削除されたアドレスです。
6 BLOCK_OLD_SOURCES - indicates that the Source Address
[i] fields in this Group Record contain a list of the
sources that the system no longer wishes to
hear from, for packets sent to the specified
multicast address. If the change was to an INCLUDE
source list, these are the addresses that were
deleted from the list; if the change was to an
EXCLUDE source list, these are the addresses that
were added to the list.
6 BLOCK_OLD_SOURCES--指定されたマルチキャストアドレスに送られたパケットのためにこのGroup RecordのSource Address[i]分野がシステムがもう連絡をいただきたがっていないソースのリストを含むのを示します。 INCLUDEソース・リストに変化があったなら、これらはリストから削除されたアドレスです。 EXCLUDEソース・リストに変化があったなら、これらはリストに追加されたアドレスです。
If a change of source list results in both allowing new sources and blocking old sources, then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES.
新しいソースと年取ったソースを妨げるのを許容しながらソース・リストの変化が両方をもたらすなら、同じマルチキャストアドレス、タイプALLOW_NEW_SOURCESの1つ、およびタイプBLOCK_OLD_SOURCESの1つのために2Group Recordsを送ります。
We use the term "State-Change Record" to refer to either a Filter- Mode-Change Record or a Source-List-Change Record.
私たちは、Filterモード変化RecordかSourceリスト変化Recordのどちらかについて言及するのに「州改訂記録」という用語を使用します。
Unrecognized Record Type values MUST be silently ignored.
静かに認識されていないRecord Type値を無視しなければなりません。
4.2.13. IP Source Addresses for Reports
4.2.13. レポートのためのIPソースアドレス
An IGMP report is sent with a valid IP source address for the destination subnet. The 0.0.0.0 source address may be used by a system that has not yet acquired an IP address. Note that the 0.0.0.0 source address may simultaneously be used by multiple systems on a LAN. Routers MUST accept a report with a source address of 0.0.0.0.
目的地サブネットのための有効なIPソースアドレスと共にIGMPレポートを送ります。 0.0.0.0ソースアドレスはまだIPアドレスを習得していないシステムによって使用されるかもしれません。 0.0.0.0ソースアドレスが同時にLANの複数のシステムによって使用されるかもしれないことに注意してください。 ルータは.0がソースが.0に0.0を扱うaでレポートを受け入れなければなりません。
Cain, et. al. Standards Track [Page 17] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[17ページ]RFC3376IGMPv3 October 2002
4.2.14. IP Destination Addresses for Reports
4.2.14. レポートのためのIP送付先アドレス
Version 3 Reports are sent with an IP destination address of 224.0.0.22, to which all IGMPv3-capable multicast routers listen. A system that is operating in version 1 or version 2 compatibility modes sends version 1 or version 2 Reports to the multicast group specified in the Group Address field of the Report. In addition, a system MUST accept and process any version 1 or version 2 Report whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Report arrives.
224.0の受信者IPアドレスと共にバージョン3Reportsを送ります。.0 .22 すべてのIGMPv3できるマルチキャストルータが聴かれる。 バージョン1かバージョン2互換性モードで作動しているシステムはReportのGroup Address分野で指定されたマルチキャストグループにバージョン1かバージョン2Reportsを送ります。 さらに、システムは、IP Destination Address分野がアドレス(ユニキャストかマルチキャスト)のどんな*もReportが到着するインタフェースに割り当てた*を含むどんなバージョン1かバージョン2Reportも受け入れて、処理しなければなりません。
4.2.15. Notation for Group Records
4.2.15. グループ・レコードのための記法
In the rest of this document, we use the following notation to describe the contents of a Group Record pertaining to a particular multicast address:
このドキュメントの残りでは、私たちは特定のマルチキャストアドレスに関係するGroup Recordのコンテンツについて説明するのに以下の記法を使用します:
IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x
IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x
TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x
TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x
ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x
BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x
_IN(x)ソースアドレスxは_EX(x)です--タイプMODE_が_INCLUDEである、タイプMODE_は_EXCLUDEです、ソースアドレスx TO_IN(x)はタイプCHANGE_TO_INCLUDE_MODE、ソースアドレスx TO_EX(x)--CHANGE_TO_EXCLUDE_MODEをタイプするソースアドレスx ALLOW(x)--ALLOW_NEW_SOURCESをタイプするソースアドレスx BLOCK(x)--BLOCK_OLD_SOURCESをタイプするソースアドレスxですか?
where x is either:
xがどちらかであるところ:
o a capital letter (e.g., "A") to represent the set of source
addresses, or
o またはソースアドレスのセットを表す大文字(例えば、「A」)。
o a set expression (e.g., "A+B"), where "A+B" means the union of sets
A and B, "A*B" means the intersection of sets A and B, and "A-B"
means the removal of all elements of set B from set A.
o セット式(例えば、「A+B」)、「A+B」がセットAとBの組合を意味するところで「*B」はセットAとBの交差点を意味します、そして、「A-B」はセットAからセットBのすべての要素の取り外しを意味します。
4.2.16. Membership Report Size
4.2.16. 会員資格レポートサイズ
If the set of Group Records required in a Report does not fit within the size limit of a single Report message (as determined by the MTU of the network on which it will be sent), the Group Records are sent in as many Report messages as needed to report the entire set.
Reportで必要であるGroup Recordsのセットがただ一つのReportメッセージのサイズ限界の中で合わないなら(それが送られるネットワークのMTUによって決定されるように)、全体のセットを報告するのが必要であるのと同じくらい多くのReportメッセージでGroup Recordsを送ります。
If a single Group Record contains so many source addresses that it does not fit within the size limit of a single Report message, if its Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is split into multiple Group Records, each containing a different subset of the source addresses and each sent in a separate Report message. If its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single Group Record is sent, containing as many source addresses as can fit, and
それがする多くのソースアドレスがTypeがMODE_でないならただ一つのReportメッセージのサイズ限界の中で合わないで、Group Recordが含むシングルが_EXCLUDEかCHANGE_TO_EXCLUDE_MODEであるなら、それは複数のGroup Recordsに分けられます、それぞれソースアドレスと別々のReportメッセージで送られたそれぞれの異なった部分集合を含んでいて。 そしてTypeによるMODE_が_EXCLUDEかCHANGE_TO_EXCLUDE_MODEであるということであるなら、a独身のGroup Recordを送ります、合うことができるのと同じくらい多くのソースアドレスを含んでいて。
Cain, et. al. Standards Track [Page 18] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[18ページ]RFC3376IGMPv3 October 2002
the remaining source addresses are not reported; though the choice of which sources to report is arbitrary, it is preferable to report the same set of sources in each subsequent report, rather than reporting different sources each time.
残っているソースアドレスは報告されません。 選択はどのソースを報告するかを任意ですが、その都度さまざまな原因を報告するよりそれぞれのその後のレポートでむしろ同じセットの源を報告するのは望ましいです。
5. Description of the Protocol for Group Members
5. グループのメンバーのためのプロトコルの記述
IGMP is an asymmetric protocol, specifying separate behaviors for group members -- that is, hosts or routers that wish to receive multicast packets -- and multicast routers. This section describes the part of IGMPv3 that applies to all group members. (Note that a multicast router that is also a group member performs both parts of IGMPv3, receiving and responding to its own IGMP message transmissions as well as those of its neighbors. The multicast router part of IGMPv3 is described in section 6.)
IGMPは非対称のプロトコルです、グループのメンバーのための別々の振舞いを指定して--すなわち、ホストかルータマルチキャストパケットを受けるというその願望、およびマルチキャストルータ。 このセクションはすべてのグループのメンバーに適用するIGMPv3の部分について説明します。 (またグループのメンバーであるマルチキャストルータがIGMPv3の両方の部分を実行することに注意してください、隣人のものと同様にそれ自身のIGMPメッセージ送信に受信して、応じて。 IGMPv3のマルチキャストルータ部分はセクション6で説明されます。)
A system performs the protocol described in this section over all interfaces on which multicast reception is supported, even if more than one of those interfaces is connected to the same network.
システムはマルチキャストレセプションがサポートされるすべてのインタフェースにわたってこのセクションで説明されたプロトコルを実行します、それらのインタフェースの1つ以上が同じネットワークに関連づけられても。
For interoperability with multicast routers running older versions of IGMP, systems maintain a MulticastRouterVersion variable for each interface on which multicast reception is supported. This section describes the behavior of group member systems on interfaces for which MulticastRouterVersion = 3. The algorithm for determining MulticastRouterVersion, and the behavior for versions other than 3, are described in section 7.
マルチキャストルータがIGMPの旧式のバージョンを実行している相互運用性のために、システムはマルチキャストレセプションがサポートされる各インタフェースに可変にMulticastRouterVersionを維持します。 このセクションはどのMulticastRouterVersion=3のためにインタフェースにおけるグループメンバーシステムの働きについて説明するか。 MulticastRouterVersionを決定するためのアルゴリズム、および3以外のバージョンのための振舞いはセクション7で説明されます。
The all-systems multicast address, 224.0.0.1, is handled as a special case. On all systems -- that is all hosts and routers, including multicast routers -- reception of packets destined to the all-systems multicast address, from all sources, is permanently enabled on all interfaces on which multicast reception is supported. No IGMP messages are ever sent regarding the all-systems multicast address.
マルチキャストが224.0に.0を扱うオールシステム.1、特殊なものとして扱われます。 それは、すべてのホストとルータです、マルチキャストルータを含んでいてすべてのシステムの上では、すべてのソースから、オールシステムマルチキャストアドレスに運命づけられたパケットのレセプションは永久に、マルチキャストレセプションがサポートされるすべてのインタフェースで可能にされます。 今までに、オールシステムマルチキャストアドレスに関してIGMPメッセージを全く送りません。
There are two types of events that trigger IGMPv3 protocol actions on an interface:
IGMPv3プロトコル動作の引き金となる2つのタイプのイベントがインタフェースにあります:
o a change of the interface reception state, caused by a local
invocation of IPMulticastListen.
o IPMulticastListenの地方の実施によって引き起こされたインタフェースレセプション状態の変化。
o reception of a Query.
o Queryのレセプション。
(Received IGMP messages of types other than Query are silently ignored, except as required for interoperation with earlier versions of IGMP.)
(Query以外のタイプの受信されたIGMPメッセージは静かに無視されて、interoperationのために必要に応じてIGMPの以前のバージョンで除いてください。)
Cain, et. al. Standards Track [Page 19] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[19ページ]RFC3376IGMPv3 October 2002
The following subsections describe the actions to be taken for each of these two cases. In those descriptions, timer and counter names appear in square brackets. The default values for those timers and counters are specified in section 8.
以下の小区分は、それぞれに関するこれらの2つのケースに取るために動作について説明します。 それらの記述では、タイマとカウンタ名は角括弧に現れます。 それらのタイマとカウンタへのデフォルト値はセクション8で指定されます。
5.1. Action on Change of Interface State
5.1. 界面準位の変化への動作
An invocation of IPMulticastListen may cause the multicast reception state of an interface to change, according to the rules in section 3.2. Each such change affects the per-interface entry for a single multicast address.
インタフェースのマルチキャストレセプション状態はIPMulticastListenの実施で変化するかもしれません、セクション3.2の規則に従って。 そのような各変化はただ一つのマルチキャストアドレスのための1インタフェースあたりのエントリーに影響します。
A change of interface state causes the system to immediately transmit a State-Change Report from that interface. The type and contents of the Group Record(s) in that Report are determined by comparing the filter mode and source list for the affected multicast address before and after the change, according to the table below. If no interface state existed for that multicast address before the change (i.e., the change consisted of creating a new per-interface record), or if no state exists after the change (i.e., the change consisted of deleting a per-interface record), then the "non-existent" state is considered to have a filter mode of INCLUDE and an empty source list.
界面準位の変化で、システムはすぐに、そのインタフェースから州-変化Reportを伝えます。 それのGroup Record(s)のタイプとコンテンツは変化の前後に影響を受けるマルチキャストアドレスのためにフィルタモードとソースを比較することによって、記載しますReportが決心している、以下のテーブルに従って。 界面準位が全くそのマルチキャストアドレスのために変化の前に存在しなかったか(すなわち、変化は1インタフェースあたり1つの新しい記録を作成するのから成りました)、または状態が全く変化の後に存在しないなら(すなわち、変化は1インタフェースあたり1つの記録を削除するのから成りました)、INCLUDEのフィルタモードと空のソース・リストが「実在しません、な」状態にあると考えられます。
Old State New State State-Change Record Sent
--------- --------- ------------------------
古い州の新しい州の州改訂記録は発信しました。--------- --------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)
(A) (B)が許容するインクルードを含めてください、(B-a)、ブロック(A-B)
EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)
除外、(A)が除く、(B) (A-B)、ブロックを許してください。(B-a)
INCLUDE (A) EXCLUDE (B) TO_EX (B)
インクルード(A)は_元の連れ合いまで(B)を除きます。(B)
EXCLUDE (A) INCLUDE (B) TO_IN (B)
(A) インクルード(B)を_INまで除いてください。(B)
If the computed source list for either an ALLOW or a BLOCK State- Change Record is empty, that record is omitted from the Report message.
州変化RecordがALLOWかBLOCKのどちらかのための計算されたソース・リストであるなら空である、その記録はReportメッセージから省略されます。
To cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable] - 1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]).
1つ以上のマルチキャストルータでいなくて寂しくさせる州-変化Reportの可能性をカバーするために、それは再送されます[丈夫さVariable]--範囲(0、[求められていないReport Interval])から無作為に選ばれた間隔で、もうひとつの回。
If more changes to the same interface state entry occur before all the retransmissions of the State-Change Report for the first change have been completed, each such additional change triggers the immediate transmission of a new State-Change Report.
同じ界面準位エントリーへの、より多くの変化が州-変化のすべての「再-トランスミッション」の前に起こるなら、最初の変化のためのReportは完成して、そのような各付加的な変化は新しい州-変化Reportの即座のトランスミッションの引き金となります。
Cain, et. al. Standards Track [Page 20] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[20ページ]RFC3376IGMPv3 October 2002
The contents of the new transmitted report are calculated as follows. As was done with the first report, the interface state for the affected group before and after the latest change is compared. The report records expressing the difference are built according to the table above. However these records are not transmitted in a message but instead merged with the contents of the pending report, to create the new State-Change report. The rules for merging the difference report resulting from the state change and the pending report are described below.
新しい伝えられたレポートのコンテンツは以下の通り計算されています。 最初のレポートでしたように、最新の変化の前後に影響を受けるグループのための界面準位は比較されます。 上のテーブルに応じて、違いを言い表すレポート記録は築き上げられます。 しかしながら、これらの記録は、新しい州-変更報告書を作成するためにメッセージで伝えられませんが、代わりに未定のレポートのコンテンツに合併されています。 州の変化と未定のレポートから生じる違いのレポートを合併するための規則は以下で説明されます。
The transmission of the merged State-Change Report terminates retransmissions of the earlier State-Change Reports for the same multicast address, and becomes the first of [Robustness Variable] transmissions of State-Change Reports.
合併している州-変化Reportのトランスミッションは、同じマルチキャストアドレスのための以前の州-変化Reportsの「再-トランスミッション」を終えて、州-変化Reportsの[丈夫さVariable]トランスミッションの1番目になります。
Each time a source is included in the difference report calculated above, retransmission state for that source needs to be maintained until [Robustness Variable] State-Change reports have been sent by the host. This is done in order to ensure that a series of successive state changes do not break the protocol robustness.
ソースが上で計算された違いのレポートに含まれている各回、そのソースへの「再-トランスミッション」州は[丈夫さVariable]州変更報告書がホストによって送られるまで維持される必要があります。 一連の連続した州の変化がプロトコル丈夫さを壊さないのを確実にするためにこれをします。
If the interface reception-state change that triggers the new report is a filter-mode change, then the next [Robustness Variable] State- Change Reports will include a Filter-Mode-Change record. This applies even if any number of source-list changes occur in that period. The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. When [Robustness Variable] State-Change reports with Filter-Mode- Change records have been transmitted after the last filter-mode change, and if source-list changes to the interface reception have scheduled additional reports, then the next State-Change report will include Source-List-Change records.
最新の報告の引き金となるインタフェースレセプション州の変化がフィルタモード変更であるなら、次の[丈夫さVariable]州の変化ReportsはFilterモード改訂記録を含むでしょう。 いろいろなソース・リスト変化がその時代に起こっても、これは適用されます。 ホストはグループのために[丈夫さVariable]州変更報告書を送るまで「再-トランスミッション」状態を維持しなければなりません。 最後のフィルタモード変更とインタフェースレセプションへのソース・リスト変化が追加レポートの計画をしたかどうかの後にFilter-モード改訂記録がある[丈夫さVariable]州変更報告書が伝えられたなら、次の州-変更報告書はSourceリスト改訂記録を含むでしょう。
Each time a State-Change Report is transmitted, the contents are determined as follows. If the report should contain a Filter-Mode- Change record, then if the current filter-mode of the interface is INCLUDE, a TO_IN record is included in the report, otherwise a TO_EX record is included. If instead the report should contain Source- List-Change records, an ALLOW and a BLOCK record are included. The contents of these records are built according to the table below.
内容はその都度州-変化Reportが伝えられることを以下の通り決定しています。 レポートがFilter-モード改訂記録を含んでいるなら、TO_IN記録はインタフェースの現在のフィルタモードがINCLUDEであるなら、レポートに含まれています。さもなければ、TO_EX記録は含まれています。 代わりに、レポートがSourceリスト改訂記録を含むべきであるか、そして、ALLOWとBLOCK記録は含まれています。 以下のテーブルに応じて、これらの記録の内容は築き上げられます。
Record Sources included
------ ----------------
TO_IN All in the current interface state that must be forwarded
TO_EX All in the current interface state that must be blocked
ALLOW All with retransmission state that must be forwarded
BLOCK All with retransmission state that must be blocked
Sourcesを含んでいて、記録してください。------ ---------------- 妨げなければならない「再-トランスミッション」状態があるBLOCK Allを送らなければならない「再-トランスミッション」状態がある妨げられたALLOW Allであるに違いない現在の界面準位でTO_EX Allを送らなければならない現在の界面準位のTO_IN All
Cain, et. al. Standards Track [Page 21] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[21ページ]RFC3376IGMPv3 October 2002
If the computed source list for either an ALLOW or a BLOCK record is empty, that record is omitted from the State-Change report.
ALLOWかBLOCK記録のどちらかのための計算されたソース・リストが空であるなら、その記録は州-変更報告書から省略されます。
Note: When the first State-Change report is sent, the non-existent pending report to merge with, can be treated as a source-change report with empty ALLOW and BLOCK records (no sources have retransmission state).
以下に注意してください。 合併する実在しない未定のレポート、最初の州-変更報告書を送るとき、空のALLOWとBLOCKがあるソース変更報告書として扱われた記録(どんなソースにも、「再-トランスミッション」状態がない)は送ることができます。
5.2. Action on Reception of a Query
5.2. 質問のレセプションへの動作
When a system receives a Query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message. A system may receive a variety of Queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response.
システムがすぐにQueryを受けるとき、それは応じません。 代わりに、それは、受信されたQueryメッセージで無作為の時間までに応答を遅らせて、マックスResp Codeから得られたマックスResp Time価値でバウンドしました。 それの異なったインタフェースのさまざまなQueries、および異種(例えば、Queries司令官(Group特有のQueries)とGroupの、そして、ソース特有のQueries)がそれぞれそれ自身の遅延応答を必要とするかもしれないシステムは受信されるかもしれません。
Before scheduling a response to a Query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the system must be able to maintain the following state:
Queryへの応答の計画をする前に、システムは、最初に、以前に予定されている未定の応答を考えて、多くの場合、結合した応答の計画をしなければなりません。 したがって、システムは以下の状態を維持できなければなりません:
o A timer per interface for scheduling responses to General Queries.
o Queries司令官へのスケジューリング応答のためのインタフェースあたり1個のタイマ。
o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.
o Groupの特定の、そして、Groupの、そして、ソース特有のQueriesへのスケジューリング応答のためのグループとインタフェースタイマ。
o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.
o Groupの、そして、ソース特有のQueryへの応答で報告されるべきソースのグループとインタフェースリスト。
When a new Query with the Router-Alert option arrives on an interface, provided the system has state to report, a delay for a response is randomly selected in the range (0, [Max Resp Time]) where Max Resp Time is derived from Max Resp Code in the received Query message. The following rules are then used to determine if a Report needs to be scheduled and the type of Report to schedule. The rules are considered in order and only the first matching rule is applied.
システムに報告する状態があるならRouter-警戒オプションがある新しいQueryがインタフェースで到着するとき、応答のための遅れはマックスResp Timeが受信されたQueryメッセージでマックスResp Codeから得られる範囲(0、[マックスResp Time])で手当たりしだいに選択されます。 Reportが、予定される必要があるか、そして、Reportのタイプが計画をすることを決定するのにおいて以下の規則はその時、使用されています。 規則は整然とすると考えられます、そして、最初の合っている規則だけが申し込まれます。
1. If there is a pending response to a previous General Query
scheduled sooner than the selected delay, no additional response
needs to be scheduled.
1. Queryが選択された遅れより早く計画をした前の司令官への未定の応答があれば、どんな追加応答も、予定される必要がありません。
2. If the received Query is a General Query, the interface timer is
used to schedule a response to the General Query after the
selected delay. Any previously pending response to a General
Query is canceled.
2. 容認されたQueryがQuery司令官であるなら、インタフェースタイマは、選択された遅れの後に司令官のQueryへの応答の計画をするのに使用されます。 Query司令官へのどんな以前に未定の応答も中止されます。
Cain, et. al. Standards Track [Page 22] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[22ページ]RFC3376IGMPv3 October 2002
3. If the received Query is a Group-Specific Query or a Group-and-
Source-Specific Query and there is no pending response to a
previous Query for this group, then the group timer is used to
schedule a report. If the received Query is a Group-and-Source-
Specific Query, the list of queried sources is recorded to be used
when generating a response.
3. そして、そして、容認されたQueryがGroup特有のQueryかGroupである、-、-、ソース特有のQuery、このグループのための前のQueryへのどんな未定の応答もなくて、次に、グループタイマは、レポートの計画をするのに使用されます。 そして、容認されたQueryがGroupである、-、-ソース特有のQuery、質問されたソースのリストは、応答を生成するとき、使用されるために記録されます。
4. If there already is a pending response to a previous Query
scheduled for this group, and either the new Query is a Group-
Specific Query or the recorded source-list associated with the
group is empty, then the group source-list is cleared and a single
response is scheduled using the group timer. The new response is
scheduled to be sent at the earliest of the remaining time for the
pending report and the selected delay.
4. このグループのために予定されていた前のQueryへの未定の応答が既にあって、新しいQueryがGroupの特定のQueryであるかグループに関連している記録されたソース・リストが空であるなら、グループソース・リストはきれいにされます、そして、ただ一つの応答は、グループタイマを使用することで予定されています。 未定のレポートと選択された遅れのための残っている時に最も早々新しい応答は送られる予定です。
5. If the received Query is a Group-and-Source-Specific Query and
there is a pending response for this group with a non-empty
source-list, then the group source list is augmented to contain
the list of sources in the new Query and a single response is
scheduled using the group timer. The new response is scheduled to
be sent at the earliest of the remaining time for the pending
report and the selected delay.
5. 容認されたQueryがGroupの、そして、ソース特有のQueryであり、このグループのための未定の応答が非空のソース・リストと共にあれば、グループソース・リストは新しいQueryにソースのリストを含むように増大します、そして、ただ一つの応答は、グループタイマを使用することで予定されています。 未定のレポートと選択された遅れのための残っている時に最も早々新しい応答は送られる予定です。
When the timer in a pending response record expires, the system transmits, on the associated interface, one or more Report messages carrying one or more Current-State Records (see section 4.2.12), as follows:
未定の応答記録のタイマが期限が切れると、システムは1Current-州のRecordsを運びながら、関連インタフェースで1つ以上のReportメッセージを送ります(セクション4.2.12を見てください)、以下の通りです:
1. If the expired timer is the interface timer (i.e., it is a pending
response to a General Query), then one Current-State Record is
sent for each multicast address for which the specified interface
has reception state, as described in section 3.2. The Current-
State Record carries the multicast address and its associated
filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.
Multiple Current-State Records are packed into individual Report
messages, to the extent possible.
1. 満期のタイマがインタフェースタイマ(すなわち、それはQuery司令官への未定の応答である)であるなら、指定されたインタフェースにはレセプション状態があるそれぞれのマルチキャストアドレスのために1Current-州のRecordを送ります、セクション3.2で説明されるように。 Current州のRecordはそのマルチキャストアドレス、関連フィルタモード(MODE_は_INCLUDEであるかMODE_は_EXCLUDEである)、およびソース・リストを運びます。 複数のCurrent-州のRecordsが可能な範囲への個々のReportメッセージに詰め込まれます。
This naive algorithm may result in bursts of packets when a system
is a member of a large number of groups. Instead of using a
single interface timer, implementations are recommended to spread
transmission of such Report messages over the interval (0, [Max
Resp Time]). Note that any such implementation MUST avoid the
"ack-implosion" problem, i.e., MUST NOT send a Report immediately
on reception of a General Query.
システムが多くのグループのメンバーであるときに、このナイーブなアルゴリズムはパケットの炸裂をもたらすかもしれません。 単一のインタフェースタイマを使用することの代わりに、実装が間隔(0、[マックスResp Time])の上にそのようなReportメッセージの伝達を広げることが勧められます。 すなわち、どんなそのような実装も「ack-内部破裂」問題を避けなければならないというメモはすぐQuery司令官のレセプションにReportを送ってはいけません。
Cain, et. al. Standards Track [Page 23] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[23ページ]RFC3376IGMPv3 October 2002
2. If the expired timer is a group timer and the list of recorded
sources for the that group is empty (i.e., it is a pending
response to a Group-Specific Query), then if and only if the
interface has reception state for that group address, a single
Current-State Record is sent for that address. The Current-State
Record carries the multicast address and its associated filter
mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.
2. 満期のタイマがグループタイマと記録されたソースのリストである、そのグループは空です(すなわち、それはGroup特有のQueryへの未定の応答です)、そして単に、インタフェースには、そのグループアドレス(Recordがそのアドレスのために送られる単一のCurrent-州)のためのレセプション状態があります。 Current-州のRecordはそのマルチキャストアドレス、関連フィルタモード(MODE_は_INCLUDEであるかMODE_は_EXCLUDEである)、およびソース・リストを運びます。
3. If the expired timer is a group timer and the list of recorded
sources for that group is non-empty (i.e., it is a pending
response to a Group-and-Source-Specific Query), then if and only
if the interface has reception state for that group address, the
contents of the responding Current-State Record is determined from
the interface state and the pending response record, as specified
in the following table:
3. そして、満期のタイマがグループタイマであるか、そして、そのグループのための記録されたソースのリストは非空です(すなわち、それはGroupの、そして、ソース特有のQueryへの未定の応答です)、そしてインタフェースにそのグループアドレスのためのレセプション状態がある場合にだけ、応じるCurrent-州のRecordのコンテンツは界面準位と未定の応答記録から決定しています、以下のテーブルで指定されるように:
set of sources in the
interface state pending response record Current-State Record
--------------- ----------------------- --------------------
界面準位応答の未定の記録Current-州のRecordのソースのセット--------------- ----------------------- --------------------
INCLUDE (A) B IS_IN (A*B)
_中にインクルード(A)Bがあります。(*B)
EXCLUDE (A) B IS_IN (B-A)
除外、(A) _中にBがあります。(B-a)
If the resulting Current-State Record has an empty set of source addresses, then no response is sent.
結果として起こるCurrent-州のRecordにソースアドレスの空集合があるなら、応答を全く送りません。
Finally, after any required Report messages have been generated, the source lists associated with any reported groups are cleared.
最終的に、どんな必要なReportメッセージも生成された後にいずれにも関連しているソース・リストは、グループがクリアされると報告しました。
6. Description of the Protocol for Multicast Routers
6. マルチキャストルータのためのプロトコルの記述
The purpose of IGMP is to enable each multicast router to learn, for each of its directly attached networks, which multicast addresses are of interest to the systems attached to those networks. IGMP version 3 adds the capability for a multicast router to also learn which *sources* are of interest to neighboring systems, for packets sent to any particular multicast address. The information gathered by IGMP is provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all networks where there are interested receivers.
IGMPの目的はそれぞれのマルチキャストルータが、それぞれの直接付属しているネットワークのためにどのマルチキャストアドレスがそれらのネットワークに取り付けられたシステムに興味深いかを学ぶのを可能にすることです。 IGMPバージョン3はまたマルチキャストルータがどの*ソース*が隣接しているシステムに興味深いかを学ぶ能力を加えます、どんな特定のマルチキャストアドレスにも送られたパケットのために。 ルータによって使用されているマルチキャストルーティング・プロトコルにIGMPによって集められた情報を提供します、マルチキャストパケットが関心がある受信機があるすべてのネットワークに提供されるのを確実にするために。
This section describes the part of IGMPv3 that is performed by multicast routers. Multicast routers may also themselves become members of multicast groups, and therefore also perform the group member part of IGMPv3, described in section 5.
このセクションはマルチキャストルータによって実行されるIGMPv3の部分について説明します。 また、マルチキャストグループのメンバーになって、したがって、また、IGMPv3のグループメンバー部分を実行して、セクション5で説明されて、マルチキャストルータは自分たちでそうするかもしれません。
Cain, et. al. Standards Track [Page 24] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[24ページ]RFC3376IGMPv3 October 2002
A multicast router performs the protocol described in this section over each of its directly-attached networks. If a multicast router has more than one interface to the same network, it only needs to operate this protocol over one of those interfaces. On each interface over which this protocol is being run, the router MUST enable reception of multicast address 224.0.0.22, from all sources (and MUST perform the group member part of IGMPv3 for that address on that interface).
マルチキャストルータはそれぞれの直接付属しているネットワークの上でこのセクションで説明されたプロトコルを実行します。 マルチキャストルータが同じネットワークに1つ以上のインタフェースを持っているなら、それは、それらのインタフェースのこのプロトコル1以上を操作する必要があるだけです。 このプロトコルが実行されている各インタフェースでは、ルータがマルチキャストアドレスのレセプションを可能にしなければならない、224.0、.0、.22、すべてのソース(そして、そのインタフェースに関するそのアドレスのためにIGMPv3のグループメンバー部分を実行しなければならない)から。
Multicast routers need to know only that *at least one* system on an attached network is interested in packets to a particular multicast address from a particular source; a multicast router is not required to keep track of the interests of each individual neighboring system. (However, see Appendix A.2 point 1 for discussion.)
マルチキャストルータは、*付属ネットワークの少なくとも1台の*システムしか特定のソースからの特定のマルチキャストアドレスへのパケットに興味を持っていないのを知る必要があります。 マルチキャストルータは、システムを近所付き合いさせるそれぞれの個人の関心の動向をおさえるのに必要ではありません。 (しかしながら、議論に関してAppendix A.2点1がわかってください。)
IGMPv3 is backward compatible with previous versions of the IGMP protocol. In order to remain backward compatible with older IGMP systems, IGMPv3 multicast routers MUST also implement versions 1 and 2 of the protocol (see section 7).
IGMPv3はIGMPプロトコルの旧バージョンと互換性があった状態で後方です。 また、後方により古いIGMPシステムと互換性があったままで残るために、IGMPv3マルチキャストルータはプロトコルのバージョン1と2を実装しなければなりません(セクション7を見てください)。
6.1. Conditions for IGMP Queries
6.1. IGMP質問のための状態
Multicast routers send General Queries periodically to request group membership information from an attached network. These queries are used to build and refresh the group membership state of systems on attached networks. Systems respond to these queries by reporting their group membership state (and their desired set of sources) with Current-State Group Records in IGMPv3 Membership Reports.
マルチキャストルータは、付属ネットワークからグループ会員資格情報を要求するために定期的にQueries司令官を送ります。 これらの質問は、付属ネットワークでシステムのグループ会員資格事情を築き上げて、リフレッシュするのに使用されます。 システムは、IGMPv3 Membership ReportsのCurrent-州のGroup Recordsと共にそれらのグループ会員資格状態(そして、それらの必要なセットの源)を報告することによって、これらの質問に反応します。
As a member of a multicast group, a system may express interest in receiving or not receiving traffic from particular sources. As the desired reception state of a system changes, it reports these changes using Filter-Mode-Change Records or Source-List-Change Records. These records indicate an explicit state change in a group at a system in either the group record's source list or its filter-mode. When a group membership is terminated at a system or traffic from a particular source is no longer desired, a multicast router must query for other members of the group or listeners of the source before deleting the group (or source) and pruning its traffic.
マルチキャストグループのメンバーとして、システムは特定のソースから受信トラフィックではなく、受信への関心を示すかもしれません。 システムの必要なレセプション事情が変化するとき、それは、Filterモード変化RecordsかSourceリスト変化Recordsを使用することでこれらの変化を報告します。 これらの記録はシステムのグループ・レコードのソース・リストかそのフィルタモードのどちらかによるグループにおける明白な州の変化を示します。 グループ会員資格がシステムで終えられるか、または特定のソースからのトラフィックがもう望まれていないとき、マルチキャストルータはグループ(または、ソース)と刈り込みを削除する前のグループの他のメンバーかソースのリスナーのためにトラフィックについて質問しなければなりません。
To enable all systems on a network to respond to changes in group membership, multicast routers send specific queries. A Group- Specific Query is sent to verify there are no systems that desire reception of the specified group or to "rebuild" the desired reception state for a particular group. Group-Specific Queries are sent when a router receives a State-Change record indicating a system is leaving a group.
ネットワークのすべてのシステムがグループ会員資格における変化に反応するのを可能にするために、マルチキャストルータは特定の質問を送ります。 特定のQueryがそこで確かめるために送られるGroupは特定のグループのために指定されたグループか「再建」への必要なレセプション状態の受付を望んでいるシステムではありません。 システムがグループを出ているのを示しながらルータが州-改訂記録を受け取るとき、グループ特有のQueriesを送ります。
Cain, et. al. Standards Track [Page 25] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[25ページ]RFC3376IGMPv3 October 2002
A Group-and-Source Specific Query is used to verify there are no systems on a network which desire to receive traffic from a set of sources. Group-and-Source Specific Queries list sources for a particular group which have been requested to no longer be forwarded. This query is sent by a multicast router to learn if any systems desire reception of packets to the specified group address from the specified source addresses. Group-and-Source Specific Queries are only sent in response to State-Change Records and never in response to Current-State Records. Section 4.1.11 describes each query in more detail.
GroupとソースSpecific Queryによるそこで確かめるのにおいて使用されているのが、ネットワークで1セットの源からトラフィックを受けることを望んでいるシステムでないということです。 グループとソースSpecific Queriesはもう進められないよう要求されている特定のグループのためにソースを記載します。 マルチキャストルータでこの質問を送って、指定されたソースアドレスから何かシステムが指定されたグループアドレスにパケットのレセプションを望んでいるかどうか学びます。 州-変化Recordsに対応してCurrent-州のRecordsに対応してグループとソースSpecific Queriesを決して送るだけではありません。 セクション4.1 .11 さらに詳細に各質問を説明します。
6.2. IGMP State Maintained by Multicast Routers
6.2. マルチキャストルータによって維持されたIGMP状態
Multicast routers implementing IGMPv3 keep state per group per attached network. This group state consists of a filter-mode, a list of sources, and various timers. For each attached network running IGMP, a multicast router records the desired reception state for that network. That state conceptually consists of a set of records of the form:
IGMPv3を実装するマルチキャストルータが付属ネットワーク単位で1グループあたりの状態を維持します。 このグループ状態はフィルタモード、ソースのリスト、および様々なタイマから成ります。 それぞれの付属ネットワーク実行IGMPに関しては、マルチキャストルータはそのネットワークのために必要なレセプション状態を記録します。 その状態はフォームに関する記録のセットから概念的に成ります:
(multicast address, group timer, filter-mode, (source records))
(マルチキャストアドレス、グループタイマ、フィルタモード(ソース記録))
Each source record is of the form:
それぞれのソース記録はフォームのものです:
(source address, source timer)
(ソースアドレス、ソースタイマ)
If all sources within a given group are desired, an empty source record list is kept with filter-mode set to EXCLUDE. This means hosts on this network want all sources for this group to be forwarded. This is the IGMPv3 equivalent to a IGMPv1 or IGMPv2 group join.
与えられたグループの中のすべてのソースが望まれているなら、ソースの空の記録リストはEXCLUDEに設定されたフィルタモードで保たれます。 これは、このネットワークのホストがこのグループが転送されるすべてのソースが欲しいことを意味します。 これはIGMPv1に同等なIGMPv3であるかIGMPv2グループが加わります。
6.2.1. Definition of Router Filter-Mode
6.2.1. ルータフィルタモードの定義
To reduce internal state, IGMPv3 routers keep a filter-mode per group per attached network. This filter-mode is used to condense the total desired reception state of a group to a minimum set such that all systems' memberships are satisfied. This filter-mode may change in response to the reception of particular types of group records or when certain timer conditions occur. In the following sections, we use the term "router filter-mode" to refer to the filter-mode of a particular group within a router. Section 6.4 describes the changes of a router filter-mode per group record received.
内部の状態を減少させるために、IGMPv3ルータは付属ネットワーク単位で1グループあたり1つのフィルタモードを保ちます。 このフィルタモードがグループの総必要なレセプション状態を最小のセットに凝縮するのに使用されるので、すべてのシステムの会員資格は満たされています。 このフィルタモードは特定のタイプに関するグループ・レコードかそれともあるタイマ状態がいつ現れるかに関するレセプションに対応して変化するかもしれません。 以下のセクションでは、私たちは、ルータの中に特定のグループのフィルタモードを示すのに「ルータフィルタモード」という用語を使用します。 セクション6.4は1グループ・レコードあたりのフィルタモードが受けたルータの変化について説明します。
Cain, et. al. Standards Track [Page 26] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[26ページ]RFC3376IGMPv3 October 2002
Conceptually, when a group record is received, the router filter-mode for that group is updated to cover all the requested sources using the least amount of state. As a rule, once a group record with a filter-mode of EXCLUDE is received, the router filter-mode for that group will be EXCLUDE.
グループ・レコードが受信されているとき、概念的に、状態の最小量を使用することですべての要求されたソースをカバーするためにそのグループのためのルータフィルタモードをアップデートします。 原則として、EXCLUDEのフィルタモードがあるグループ・レコードがいったん受信されるようになると、そのグループのためのルータフィルタモードはEXCLUDEになるでしょう。
When a router filter-mode for a group is EXCLUDE, the source record list contains two types of sources. The first type is the set which represents conflicts in the desired reception state; this set must be forwarded by some router on the network. The second type is the set of sources which hosts have requested to not be forwarded. Appendix A describes the reasons for keeping this second set when in EXCLUDE mode.
グループのためのルータフィルタモードがEXCLUDEであるときに、ソース記録リストは2つのタイプの源を入れてあます。 最初のタイプは必要なレセプション状態での闘争を表すセットです。 ネットワークの何らかのルータはこのセットを進めなければなりません。 2番目のタイプはホストが進められないよう要求したソースのセットです。 EXCLUDEモードで説明するとき、付録Aはこの秒を決め続ける理由について説明します。
When a router filter-mode for a group is INCLUDE, the source record list is the list of sources desired for the group. This is the total desired set of sources for that group. Each source in the source record list must be forwarded by some router on the network.
グループのためのルータフィルタモードがINCLUDEであるときに、ソース記録リストはグループのために望まれていたソースのリストです。 これはそのグループのための総必要なセットの源です。 ネットワークの何らかのルータはソース記録リストの各ソースを転送しなければなりません。
Because a reported group record with a filter-mode of EXCLUDE will cause a router to transition its filter-mode for that group to EXCLUDE, a mechanism for transitioning a router's filter-mode back to INCLUDE must exist. If all systems with a group record in EXCLUDE filter-mode cease reporting, it is desirable for the router filter- mode for that group to transition back to INCLUDE mode. This transition occurs when the group timer expires and is explained in detail in section 6.5.
EXCLUDEのフィルタモードがある報告されたグループ・レコードがそれのために変遷へのフィルタモードをルータに引き起こして、移行して、INCLUDEへのルータのフィルタモードが存在しなければならないので、EXCLUDE、メカニズムに分類してください。 EXCLUDEフィルタモードによるグループ・レコードがあるすべてのシステムがやむなら、ルータに、それが望ましいと報告して、そのグループのためにINCLUDEモードへの変遷にモードをフィルターにかけてください。 この変遷は、グループタイマが期限が切れると起こって、セクション6.5で詳細に説明されます。
6.2.2. Definition of Group Timers
6.2.2. グループタイマの定義
The group timer is only used when a group is in EXCLUDE mode and it represents the time for the *filter-mode* of the group to expire and switch to INCLUDE mode. We define a group timer as a decrementing timer with a lower bound of zero kept per group per attached network. Group timers are updated according to the types of group records received.
グループがEXCLUDEモードであるときだけ、グループタイマは使用されます、そして、それはグループの*フィルタモード*がINCLUDEモードに期限が切れて、切り替わる時間を表します。 ゼロの下界がグループ単位で保たれている状態で、私たちは付属ネットワーク単位でグループタイマを減少タイマと定義します。 記録が受け取ったグループのタイプに従って、グループタイマをアップデートします。
A group timer expiring when a router filter-mode for the group is EXCLUDE means there are no listeners on the attached network in EXCLUDE mode. At this point, a router will transition to INCLUDE filter-mode. Section 6.5 describes the actions taken when a group timer expires while in EXCLUDE mode.
グループのためのルータフィルタモードがEXCLUDEであるときに期限が切れるグループタイマは、リスナーが全くEXCLUDEモードで、付属ネットワークの一員でないことを意味します。 ここに、ルータはINCLUDEフィルタモードへの変遷がそうするでしょう。 セクション6.5はEXCLUDEモードで説明している間、グループタイマが期限が切れるとき取られた行動について説明します。
The following table summarizes the role of the group timer. Section 6.4 describes the details of setting the group timer per type of group record received.
以下のテーブルはグループタイマの役割をまとめます。 セクション6.4はグループ・レコードのタイプあたりのグループタイマが受けた設定の細部について説明します。
Cain, et. al. Standards Track [Page 27] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[27ページ]RFC3376IGMPv3 October 2002
Group
Filter-Mode Group Timer Value Actions/Comments
----------- ----------------- ----------------
グループフィルタモードグループタイマ値の動作/コメント----------- ----------------- ----------------
INCLUDE Timer >= 0 All members in INCLUDE
mode.
INCLUDE Timer>はINCLUDEモードで0人のAllメンバーと等しいです。
EXCLUDE Timer > 0 At least one member in
EXCLUDE mode.
EXCLUDEモードによるEXCLUDE Timer>0At最少のものメンバー。
EXCLUDE Timer == 0 No more listeners to
group. If all source
timers have expired then
delete Group Record.
If there are still
source record timers
running, switch to
INCLUDE filter-mode
using those source records
with running timers as the
INCLUDE source record
state.
EXCLUDE Timer=、0 分類するそれ以上のリスナーがありません。 すべてのソースタイマが期限が切れたなら、Group Recordを削除してください。 動くソース記録タイマがまだあれば、INCLUDEソース記録状態として実行タイマがあるそれらのソース記録を使用することでINCLUDEフィルタモードに切り替わってください。
6.2.3. Definition of Source Timers
6.2.3. ソースタイマの定義
A source timer is kept per source record and is a decrementing timer with a lower bound of zero. Source timers are updated according to the type and filter-mode of the group record received. Source timers are always updated (for a particular group) whenever the source is present in a received record for that group. Section 6.4 describes the setting of source timers per type of group records received.
ソースタイマは、ソース記録単位で保たれて、ゼロの下界がある減少タイマです。 タイプに従って、ソースタイマをアップデートしました、そして、グループのフィルタモード記録は受信されました。 ソースがそのグループのための受信された記録に出席しているときはいつも、いつもソースタイマをアップデートします(特定のグループのために)。 セクション6.4はグループ・レコードのタイプあたりのタイマが受け取ったソースの設定について説明します。
A source record with a running timer with a router filter-mode for the group of INCLUDE means that there is currently one or more systems (in INCLUDE filter-mode) which desire to receive that source. If a source timer expires with a router filter-mode for the group of INCLUDE, the router concludes that traffic from this particular source is no longer desired on the attached network, and deletes the associated source record.
INCLUDEのグループのためのルータフィルタモードがある実行タイマがあるソース記録は、そのソースを受け取ることを望んでいる1台以上のシステム(INCLUDEフィルタモードによる)が現在あることを意味します。 ソースタイマがINCLUDEのグループのためのルータフィルタモードで期限が切れるなら、ルータは、この特定のソースからのトラフィックがもう付属ネットワークで望まれていなくて、関連ソース記録を削除すると結論を下します。
Source timers are treated differently when a router filter-mode for a group is EXCLUDE. If a source record has a running timer with a router filter-mode for the group of EXCLUDE, it means that at least one system desires the source. It should therefore be forwarded by a router on the network. Appendix A describes the reasons for keeping state for sources that have been requested to be forwarded while in EXCLUDE state.
グループのためのルータフィルタモードがEXCLUDEであるときに、ソースタイマは異なって扱われます。 ソース記録にEXCLUDEのグループのためのルータフィルタモードがある実行タイマがあるなら、それは、少なくとも1台のシステムがソースを望んでいることを意味します。 したがって、ネットワークのルータはそれを進めるべきです。 EXCLUDE状態にある間、付録Aはキープ状態の理由について進められるよう要求されているソースに説明します。
Cain, et. al. Standards Track [Page 28] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[28ページ]RFC3376IGMPv3 October 2002
If a source timer expires with a router filter-mode for the group of EXCLUDE, the router informs the routing protocol that there is no longer a receiver on the network interested in traffic from this source.
ソースタイマがEXCLUDEのグループのためのルータフィルタモードで期限が切れるなら、ルータは、受信機がもうこのソースからトラフィックに興味を持っているネットワークにないことをルーティング・プロトコルに知らせます。
When a router filter-mode for a group is EXCLUDE, source records are only deleted when the group timer expires. Section 6.3 describes the actions that should be taken dependent upon the value of a source timer.
グループのためのルータフィルタモードがEXCLUDEであるときに、グループタイマが期限が切れるときだけ、ソース記録は削除されます。 セクション6.3はソースタイマの値で取られた扶養家族であるべきである動作について説明します。
6.3. IGMPv3 Source-Specific Forwarding Rules
6.3. IGMPv3のソース特有の推進規則
When a multicast router receives a datagram from a source destined to a particular group, a decision has to be made whether to forward the datagram onto an attached network or not. The multicast routing protocol in use is in charge of this decision, and should use the IGMPv3 information to ensure that all sources/groups desired on a subnetwork are forwarded to that subnetwork. IGMPv3 information does not override multicast routing information; for example, if the IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward packets for excluded sources to a transit subnet.
マルチキャストルータが特定のグループに運命づけられたソースからデータグラムを受けるとき、付属ネットワークにデータグラムを送るかどうかという決定をしなければなりません。 使用中のマルチキャストルーティング・プロトコルは、この決定を担当してあって、サブネットワークで必要なすべてのソース/グループがそのサブネットワークに転送されるのを保証するのにIGMPv3情報を使用するべきです。 IGMPv3情報はマルチキャストルーティング情報に優越しません。 例えば、GのためのIGMPv3フィルタモードグループがEXCLUDEであるなら、ルータはまだトランジットサブネットへの除かれたソースにパケットを送っているかもしれません。
To summarize, the following table describes the forwarding suggestions made by IGMP to the routing protocol for traffic originating from a source destined to a group. It also summarizes the actions taken upon the expiration of a source timer based on the router filter-mode of the group.
まとめるために説明する、以下のテーブルはグループに運命づけられたソースから発するトラフィックのためにIGMPによってルーティング・プロトコルにされた推進提案について説明します。 また、それはグループのルータフィルタモードに基づくソースタイマの満了が持っていかれた動作をまとめます。
Group
Filter-Mode Source Timer Value Action
----------- ------------------ ------
グループフィルタモードソースタイマ値の動作----------- ------------------ ------
INCLUDE TIMER > 0 Suggest to forward traffic
from source
ソースからトラフィックを進めるINCLUDE TIMER>0Suggest
INCLUDE TIMER == 0 Suggest to stop forwarding
traffic from source and
remove source record. If
there are no more source
records for the group, delete
group record.
ソースからトラフィックを進めるのを止めて、ソースを外す0INCLUDE TIMER=Suggestは記録します。 グループのためのそれ以上のソース記録が全くなければ、グループ・レコードを削除してください。
INCLUDE No Source Elements Suggest to not forward source
ソースを転送しないSourceのElementsのINCLUDEノーSuggest
EXCLUDE TIMER > 0 Suggest to forward traffic
from source
ソースからトラフィックを進めるEXCLUDE TIMER>0Suggest
Cain, et. al. Standards Track [Page 29] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[29ページ]RFC3376IGMPv3 October 2002
EXCLUDE TIMER == 0 Suggest to not forward
traffic from source
(DO NOT remove record)
ソースからトラフィックを進めない0EXCLUDE TIMER=Suggest(記録を取り除きません)
EXCLUDE No Source Elements Suggest to forward traffic
from source
ソースからトラフィックを進めるSourceのElementsのEXCLUDEノーSuggest
6.4. Action on Reception of Reports
6.4. レポートのレセプションへの動作
6.4.1. Reception of Current-State Records
6.4.1. 現状記録のレセプション
When receiving Current-State Records, a router updates both its group and source timers. In some circumstances, the reception of a type of group record will cause the router filter-mode for that group to change. The table below describes the actions, with respect to state and timers that occur to a router's state upon reception of Current- State Records.
Current-州のRecordsを受けるとき、ルータはグループとソースタイマの両方をアップデートします。 いくつかの事情では、一種のグループ・レコードのレセプションは変えるそのグループのためにルータフィルタモードを引き起こすでしょう。 以下のテーブルは動作について説明します、Current州のRecordsのレセプションでルータの状態の心に浮かぶ状態とタイマに関して。
The following notation is used to describe the updating of source timers. The notation ( A, B ) will be used to represent the total number of sources for a particular group, where
以下の記法は、ソースタイマのアップデートについて説明するのに使用されます。 記法(A、B)は特定のグループのためにソースの総数を表すのに使用されるでしょう、どこ
A = set of source records whose source timers > 0 (Sources that at
least one host has requested to be forwarded)
B = set of source records whose source timers = 0 (Sources that IGMP
will suggest to the routing protocol not to forward)
>0(少なくとも1人のホストが進められるよう要求したソース)B=が設定するソースのソースタイマがソースタイマ=0を記録するソース記録の=セット(IGMPが進めないルーティング・プロトコルに勧めるソース)
Note that there will only be two sets when a router's filter-mode for a group is EXCLUDE. When a router's filter-mode for a group is INCLUDE, a single set is used to describe the set of sources requested to be forwarded (e.g., simply (A)).
グループのためのルータのフィルタモードがEXCLUDEであるときに、2セットしかないことに注意してください。 グループのためのルータのフィルタモードがINCLUDEであるときに、1セットは、進められるよう要求されたソース(例えば、単に(A))のセットについて説明するのに使用されます。
In the following tables, abbreviations are used for several variables (all of which are described in detail in section 8). The variable GMI is an abbreviation for the Group Membership Interval, which is the time in which group memberships will time out. The variable LMQT is an abbreviation for the Last Member Query Time, which is the total time spent after Last Member Query Count retransmissions. LMQT represents the "leave latency", or the difference between the transmission of a membership change and the change in the information given to the routing protocol.
以下のテーブルでは、略語はいくつかの変数(それのすべてがセクション8で詳細に説明される)に使用されます。 可変GMIがGroup Membership Intervalのための略語である、どれがどのグループ会員資格に時間であるかはタイムアウトがそうするでしょう。 可変LMQTはLastメンバーQuery Timeのための略語です。(Query TimeはLastメンバーQuery Count retransmissionsの後に費やされた合計時です)。 LMQTが表す、「潜在を残してください」、または、会員資格変化のトランスミッションと変化のルーティング・プロトコルに与えられた情報の違い。
Within the "Actions" section of the router state tables, we use the notation 'A=J', which means that the set A of source records should have their source timers set to value J. 'Delete A' means that the set A of source records should be deleted. 'Group Timer=J' means that the Group Timer for the group should be set to value J.
ルータステートテーブルの「動作」セクションの中では、私たちは記法'A=J'を使用します。(それは、それらのソースタイマがソース記録のAでJ. 'Aを削除してください'を評価するように設定するべきであるセットが、ソース記録のセットAが削除されるべきであることを意味することを意味します)。 'グループTimer=J'は、グループのためのGroup TimerがJを評価するように用意ができるべきであることを意味します。
Cain, et. al. Standards Track [Page 30] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[30ページ]RFC3376IGMPv3 October 2002
Router State Report Rec'd New Router State Actions ------------ ------------ ---------------- -------
ルータ州のレポートRecが新しくそうするだろう、ルータ州の行為------------ ------------ ---------------- -------
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI
インクルード(A)は(B) (B) インクルード(A+B)=GMIの_です。
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
インクルード(A)が元の(B)が除く_である、(*B、B-a)、(B-a)=0は(A-B)グループタイマ=GMIを削除します。
EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI
除外、(X、Y)がIN(A)が除く_である、(X+A、Y a)(A)はGMIと等しいです。
EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=GMI
Delete (X-A)
Delete (Y-A)
Group Timer=GMI
除外、(X、Y)が元の連れ合い(A)が除く_である、(A-Y、Y*a)(A-X-Y)=GMIが削除する、(X-a)が削除する、(Y-a)が分類されたタイマ=GMI
6.4.2. Reception of Filter-Mode-Change and Source-List-Change Records
6.4.2. フィルタモード変更とソースリスト改訂記録のレセプション
When a change in the global state of a group occurs in a system, the system sends either a Source-List-Change Record or a Filter-Mode- Change Record for that group. As with Current-State Records, routers must act upon these records and possibly change their own state to reflect the new desired membership state of the network.
グループのグローバルな状態の変化がシステムに起こると、システムはそれのためのRecordが分類するSourceリスト変化RecordかFilter-モード変化のどちらかを送ります。 Current-州のRecordsなら、ルータは、これらの記録に作用して、ネットワークの新しい必要な会員資格事情を反映するためにことによるとそれら自身の状態を変えなければなりません。
Routers must query sources that are requested to be no longer forwarded to a group. When a router queries or receives a query for a specific set of sources, it lowers its source timers for those sources to a small interval of Last Member Query Time seconds. If group records are received in response to the queries which express interest in receiving traffic from the queried sources, the corresponding timers are updated.
ルータはもうグループに送られないよう要求されているソースについて質問しなければなりません。 ルータが特定のセットの源に質問を質問するか、または受けるとき、それはLastメンバーQuery Time秒の小さい間隔までソースタイマをそれらのソースに下ろします。 質問されたソースからトラフィックを受けることへの関心を示す質問に対応してグループ・レコードを受け取るなら、対応するタイマをアップデートします。
Similarly, when a router queries a specific group, it lowers its group timer for that group to a small interval of Last Member Query Time seconds. If any group records expressing EXCLUDE mode interest in the group are received within the interval, the group timer for the group is updated and the suggestion to the routing protocol to forward the group stands without any interruption.
ルータが特定のグループについて質問するとき、同様に、それはそのグループのためにLastメンバーQuery Time秒の小さい間隔にグループタイマを下ろします。 間隔中に何かグループへのEXCLUDEモード関心を示すグループ・レコードを受け取るなら、グループのためのグループタイマをアップデートします、そして、グループを転送するルーティング・プロトコルへの提案は少しも中断なしで立ちます。
During a query period (i.e., Last Member Query Time seconds), the IGMP component in the router continues to suggest to the routing protocol that it forwards traffic from the groups or sources that it is querying. It is not until after Last Member Query Time seconds without receiving a record expressing interest in the queried group or sources that the router may prune the group or sources from the network.
質問の期間(すなわち、LastメンバーQuery Time秒)、ルータにおけるIGMPの部品は、質問しているグループかソースからトラフィックを進めるのをルーティング・プロトコルに示し続けています。 質問されたグループかソースへの関心を示す記録を受け取ることのないLastメンバーQuery Time秒の後までルータはネットワークからのグループかソースを剪定しないかもしれません。
Cain, et. al. Standards Track [Page 31] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[31ページ]RFC3376IGMPv3 October 2002
The following table describes the changes in group state and the action(s) taken when receiving either Filter-Mode-Change or Source- List-Change Records. This table also describes the queries which are sent by the querier when a particular report is received.
以下のテーブルはFilterモード変化かSourceリスト変化のどちらかRecordsを受けるとき取られたグループ状態と行動における変化について説明します。 また、このテーブルは詳細な報告書が受け取られているときquerierによって送られる質問を説明します。
We use the following notation for describing the queries which are sent. We use the notation 'Q(G)' to describe a Group-Specific Query to G. We use the notation 'Q(G,A)' to describe a Group-and-Source Specific Query to G with source-list A. If source-list A is null as a result of the action (e.g., A*B) then no query is sent as a result of the operation.
私たちは、送られる質問を説明するのに以下の記法を使用します。 私たちは、G.We使用へのGroup特有のQuery記法'Q(G、A)'についてソース・リストA.でGroupとソースSpecific QueryについてGに説明するために説明するのに記法'Q(G)'を使用します。Ifソース・リストAは動作(例えば、A*B)の結果、ヌルであり、次に、操作の結果、質問を全く送りません。
In order to maintain protocol robustness, queries sent by actions in the table below need to be transmitted [Last Member Query Count] times, once every [Last Member Query Interval].
一度プロトコル丈夫さ、テーブルでの動作で伝えられた[メンバーQuery Countを持続する]回である必要性に送られた質問を維持する、あらゆる、[メンバーQuery Intervalを持続します。]
If while scheduling new queries, there are already pending queries to be retransmitted for the same group, the new and pending queries have to be merged. In addition, received host reports for a group with pending queries may affect the contents of those queries. Section 6.6.3 describes the process of building and maintaining the state of pending queries.
同じグループのために再送されるために未定の質問が新しい質問の計画をしている間、既にあれば、新しくて未定の質問は合併されなければなりません。 さらに、未定の質問があるグループのための受け取られていているホストレポートはそれらの質問のコンテンツに影響するかもしれません。 セクション6.6 .3 未定の質問の状態を造って、維持するプロセスについて説明します。
Router State Report Rec'd New Router State Actions ------------ ------------ ---------------- -------
ルータ州のレポートRecが新しくそうするだろう、ルータ州の行為------------ ------------ ---------------- -------
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=GMI
インクルード(A)は(B) (B) インクルード(A+B)=GMIを許容します。
INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(G,A*B)
インクルード(A)ブロック(B)インクルード(A)はQを送ります。(G、*B)
INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Send Q(G,A*B)
Group Timer=GMI
_元の連れ合い(B)へのインクルード(A)が除く、(*B、B-a)、(=0が削除するB-a)(A-B)はQ(G、*B)グループタイマ=GMIを送ります。
INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=GMI
Send Q(G,A-B)
(B) (B)=GMIがQを送るインクルード(A+B)で_に(A)を含めてください。(G、A-B)
EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=GMI
除外、(X、Y)が(A)を許容する、除外、(X+A、Y a)(A)はGMIと等しいです。
EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer
Send Q(G,A-Y)
グループ(A)が除くブロック(X+(A-Y)、Y)(A-X-Y)=タイマがQを送る(X、Y)を除いてください。(G、A-Y)
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
元の連れ合い(A)が除く_まで(X、Y)を除いてください、(グループA-Y、Y*a)(A-X-Y)=タイマが削除する、(X-a)が削除する、(Y-a)が発信しているQ(G、A-Y)グループタイマ=GMI
Cain, et. al. Standards Track [Page 32] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[32ページ]RFC3376IGMPv3 October 2002
EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI
Send Q(G,X-A)
Send Q(G)
IN(A)が除く_まで(X、Y)を除いてください、(X+A、Y a)(A)=GMIがQを送る、(G、X-a)が発信しているQ(G)
6.5. Switching Router Filter-Modes
6.5. 切り換えルータフィルタモード
The group timer is used as a mechanism for transitioning the router filter-mode from EXCLUDE to INCLUDE.
グループタイマは移行にメカニズムとして使用されます。EXCLUDEからINCLUDEまでのルータフィルタモード。
When a group timer expires with a router filter-mode of EXCLUDE, a router assumes that there are no systems with a *filter-mode* of EXCLUDE present on the attached network. When a router's filter-mode for a group is EXCLUDE and the group timer expires, the router filter-mode for the group transitions to INCLUDE.
グループタイマがEXCLUDEのルータフィルタモードで期限が切れると、ルータは、付属ネットワークの現在のEXCLUDEの*フィルタモード*があるシステムが全くないと仮定します。 グループのためのルータのフィルタモードがEXCLUDEであり、グループタイマが期限が切れると、グループのためのルータフィルタモードはINCLUDEに移行します。
A router uses source records with running source timers as its state for the switch to a filter-mode of INCLUDE. If there are any source records with source timers greater than zero (i.e., requested to be forwarded), a router switches to filter-mode of INCLUDE using those source records. Source records whose timers are zero (from the previous EXCLUDE mode) are deleted.
ルータはスイッチに状態として実行ソースタイマがあるソース記録をINCLUDEのフィルタモードに使用します。 何かソースタイマがゼロ(すなわち、進められるよう要求されている)よりすばらしいソース記録があれば、ルータは、それらのソース記録を使用することでINCLUDEのフィルタモードに切り替わります。 タイマがゼロ(前のEXCLUDEモードからの)であるソース記録は削除されます。
For example, if a router's state for a group is EXCLUDE(X,Y) and the group timer expires for that group, the router switches to filter- mode of INCLUDE with state INCLUDE(X).
例えば、グループのためのルータの状態がEXCLUDE(X、Y)であり、グループタイマがそのグループのために期限が切れるなら、ルータは、州のINCLUDE(X)と共にINCLUDEのモードをフィルターにかけるために切り替わります。
6.6. Action on Reception of Queries
6.6. 質問のレセプションへの動作
6.6.1. Timer Updates
6.6.1. タイマアップデート
When a router sends or receives a query with a clear Suppress Router-Side Processing flag, it must update its timers to reflect the correct timeout values for the group or sources being queried. The following table describes the timer actions when sending or receiving a Group-Specific or Group-and-Source Specific Query with the Suppress Router-Side Processing flag not set.
ルータが明確なSuppress Router-サイドProcessing旗で質問を送るか、または受けるとき、それは、正しいタイムアウト値を質問されているグループかソースに反映するためにタイマをアップデートしなければなりません。 Suppress Router-サイドProcessing旗があるSpecific Queryが設定しないGroup-詳細かGroupとソースを送るか、または受け取るとき、以下のテーブルはタイマ動作について説明します。
Query Action
----- ------
Q(G,A) Source Timer for sources in A are lowered to LMQT
Q(G) Group Timer is lowered to LMQT
質問動作----- ------ AのソースがLMQT Q(G)グループTimerに下ろされるので、Q(G、A)ソースTimerはLMQTに下ろされます。
When a router sends or receives a query with the Suppress Router-Side Processing flag set, it will not update its timers.
ルータがSuppress Router-サイドProcessing旗のセットによる質問を送るか、または受けるとき、それはタイマをアップデートしないでしょう。
Cain, et. al. Standards Track [Page 33] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[33ページ]RFC3376IGMPv3 October 2002
6.6.2. Querier Election
6.6.2. Querier選挙
IGMPv3 elects a single querier per subnet using the same querier election mechanism as IGMPv2, namely by IP address. When a router receives a query with a lower IP address, it sets the Other-Querier- Present timer to Other Querier Present Interval and ceases to send queries on the network if it was the previously elected querier. After its Other-Querier Present timer expires, it should begin sending General Queries.
IGMPv3は、すなわち、IGMPv2、IPアドレスで同じquerier選挙メカニズムを使用することで1サブネットあたり1単一のquerierを選出します。 ルータが低いIPアドレスで質問を受けるとき、それは、Other-Querierの現在のタイマをOther Querier Present Intervalに設定して、以前に選出されたquerierであったなら質問をネットワークに送るのをやめます。 Other-Querier Presentタイマが期限が切れた後に、それは、Queries司令官を送り始めるべきです。
If a router receives an older version query, it MUST use the oldest version of IGMP on the network. For a detailed description of compatibility issues between IGMP versions see section 7.
ルータが旧式のバージョン質問を受けるなら、それはネットワークでIGMPの最も古いバージョンを使用しなければなりません。 IGMPバージョンの間の互換性の問題の詳述に関しては、セクション7を見てください。
6.6.3. Building and Sending Specific Queries
6.6.3. 特定の質問を組み込んで、送ります。
6.6.3.1. Building and Sending Group Specific Queries
6.6.3.1. グループの特定の質問を組み込んで、送ります。
When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time].
テーブル動作「Q(G)を送ってください」が遭遇すると、グループタイマをLMQTに下ろさなければなりません。 次に、ルータがすぐに送るためにスケジュール[最後のメンバーQuery Count--1]質問「再-トランスミッション」と同様にグループ詳細質問を送らなければならない、あらゆる、[メンバーQuery Intervalを持続します] [最後のメンバーQuery Time]の上で。
When transmitting a group specific query, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.
グループタイマがLMQTより大きいならグループの特定の質問を伝えるとき、噛み付かれた「ルータサイド処理を抑圧してください」は質問メッセージに設定されます。
6.6.3.2. Building and Sending Group and Source Specific Queries
6.6.3.2. グループとソースの特定の質問を組み込んで、送ります。
When a table action "Send Q(G,X)" is encountered by a querier in the table in section 6.4.2, the following actions must be performed for each of the sources in X of group G, with source timer larger than LMQT:
テーブル動作「Q(G、X)を送ってください」がセクション6.4.2でテーブルのquerierによって遭遇されるとき、グループGのXのそれぞれの源に以下の動作を実行しなければなりません、ソースタイマがLMQTより大きい状態で:
o Set number of retransmissions for each source to [Last Member Query
Count].
o [最後のメンバーQuery Count]への各ソースに「再-トランスミッション」の数を設定してください。
o Lower source timer to LMQT.
o ソースタイマをLMQTに下ろしてください。
The router must then immediately send a group and source specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. The contents of these queries are calculated as follows.
次に、ルータがすぐに送るためにスケジュール[最後のメンバーQuery Count--1]質問「再-トランスミッション」と同様にグループとソースの特定の質問を送らなければならない、あらゆる、[メンバーQuery Intervalを持続します] [最後のメンバーQuery Time]の上で。 これらの質問のコンテンツは以下の通り計算されています。
Cain, et. al. Standards Track [Page 34] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[34ページ]RFC3376IGMPv3 October 2002
When building a group and source specific query for a group G, two separate query messages are sent for the group. The first one has the "Suppress Router-Side Processing" bit set and contains all the sources with retransmission state and timers greater than LMQT. The second has the "Suppress Router-Side Processing" bit clear and contains all the sources with retransmission state and timers lower or equal to LMQT. If either of the two calculated messages does not contain any sources, then its transmission is suppressed.
グループGのためにグループとソースの特定の質問を組み込むとき、グループのために2つの別々の質問メッセージを送ります。 「再-トランスミッション」状態とタイマがLMQTより大きい状態で、最初のものは、「ルータサイド処理を抑圧してください」というビットを設定させて、すべてのソースを含んでいます。 2番目は、はっきりと噛み付かれた「ルータサイド処理を抑圧してください」を持っていて、LMQTと下側の、または、等しい「再-トランスミッション」状態とタイマですべてのソースを含んでいます。 どちらの2つの計算されたメッセージもどんなソースも含んでいないなら、トランスミッションは抑圧されます。
Note: If a group specific query is scheduled to be transmitted at the same time as a group and source specific query for the same group, then transmission of the group and source specific message with the "Suppress Router-Side Processing" bit set may be suppressed.
以下に注意してください。 グループであるなら、グループとソースの特定の質問と同時に同じグループのために特定の質問は伝えられる予定であり、次に、セットした「ルータサイド処理を抑圧してください」が噛み付かれていたグループとソースの特定のメッセージの伝達は抑圧されるかもしれません。
7. Interoperation With Older Versions of IGMP
7. IGMPの旧式のバージョンがあるInteroperation
IGMP version 3 hosts and routers interoperate with hosts and routers that have not yet been upgraded to IGMPv3. This compatibility is maintained by hosts and routers taking appropriate actions depending on the versions of IGMP operating on hosts and routers within a network.
IGMPバージョン3 ホストとルータはまだIGMPv3にアップグレードしていないホストとルータで共同利用します。 この互換性はIGMPがネットワークの中でホストとルータを作動させるバージョンによる適切な行動を取るホストとルータによって維持されます。
7.1. Query Version Distinctions
7.1. 質問バージョン区別
The IGMP version of a Membership Query message is determined as follows:
Membership QueryメッセージのIGMPバージョンは以下の通り決定しています:
IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero
IGMPv1は以下について質問します。 8つの八重奏とマックスResp Codeがさばく長さ=はゼロです。
IGMPv2 Query: length = 8 octets AND Max Resp Code field is
non-zero
IGMPv2は以下について質問します。 8つの八重奏とマックスResp Codeがさばく長さ=は非ゼロです。
IGMPv3 Query: length >= 12 octets
IGMPv3は以下について質問します。 長さの>は12の八重奏と等しいです。
Query messages that do not match any of the above conditions (e.g., a Query of length 10 octets) MUST be silently ignored.
静かに上記の条件(例えば、長さの10八重奏のQuery)のいずれにも合っていない質問メッセージを無視しなければなりません。
7.2. Group Member Behavior
7.2. グループメンバーの振舞い
7.2.1. In the Presence of Older Version Queriers
7.2.1. 旧式のバージョンQueriersの面前で
In order to be compatible with older version routers, IGMPv3 hosts MUST operate in version 1 and version 2 compatibility modes. IGMPv3 hosts MUST keep state per local interface regarding the compatibility mode of each attached network. A host's compatibility mode is
旧式のバージョンルータと互換性があるように、IGMPv3ホストはバージョン1とバージョン2互換性モードで働かなければなりません。 IGMPv3ホストはそれぞれの付属ネットワークの互換性モードに関して1局所界面あたりの状態を維持しなければなりません。 ホストの互換性モードはそうです。
Cain, et. al. Standards Track [Page 35] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[35ページ]RFC3376IGMPv3 October 2002
determined from the Host Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface and is dependent on the version of General Queries heard on that interface as well as the Older Version Querier Present timers for the interface.
3つの州の1つにあることができるHost Compatibility Mode変数から断固とする: IGMPv1、IGMPv2またはIGMPv3。 この変数は、インタフェース単位で保たれて、インタフェースへのオールダーバージョンQuerier Presentタイマと同様にそのインタフェースで聞かれたQueries司令官のバージョンに依存しています。
In order to switch gracefully between versions of IGMP, hosts keep both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present timer per interface. IGMPv1 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv1 Membership Query is received. IGMPv2 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv2 General Query is received.
優雅にIGMPのバージョンを切り換えるために、ホストは、両方がIGMPv1 Querier Presentタイマと1インタフェースあたり1個のIGMPv2 Querier Presentタイマであることを保ちます。 IGMPv1 Membership Queryが受け取られているときはいつも、IGMPv1 Querier PresentはオールダーバージョンQuerier Present Timeout秒に用意ができています。 IGMPv2Query司令官が受け取られているときはいつも、IGMPv2 Querier PresentはオールダーバージョンQuerier Present Timeout秒に用意ができています。
The Host Compatibility Mode of an interface changes whenever an older version query (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv2 if it has a running IGMPv2 Querier Present timer. If it does not have a running IGMPv2 Querier Present timer then it switches to Host Compatibility of IGMPv3. When the IGMPv2 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv3.
旧式のバージョン質問(現在の互換性モードより)が聞かれるときはいつも、あるタイマ状態が現れると、インタフェースのHost Compatibility Modeは変化します。 IGMPv1 Querier Presentタイマが期限が切れると、実行IGMPv2 Querier Presentタイマを持っているなら、ホストはIGMPv2のHost Compatibilityモードに切り替わります。 実行IGMPv2 Querier Presentタイマを持っていないなら、それはIGMPv3のHost Compatibilityに切り替わります。 IGMPv2 Querier Presentタイマが期限が切れると、ホストはIGMPv3のHost Compatibilityモードに切り替わります。
The Host Compatibility Mode variable is based on whether an older version General query was heard in the last Older Version Querier Present Timeout seconds. The Host Compatibility Mode is set depending on the following:
Host Compatibility Mode変数は旧式のバージョン一般質問が最後のオールダーバージョンQuerier Present Timeout秒に聞かれたかどうか基づいています。 Host Compatibility Modeは以下によるのを用意ができています:
Host Compatibility Mode Timer State ----------------------- -----------
ホスト互換性モードタイマ状態----------------------- -----------
IGMPv3 (default) IGMPv2 Querier Present not running
and IGMPv1 Querier Present not running
稼働ではなく、稼働ではなく、IGMPv3(デフォルト)IGMPv2 Querier PresentとIGMPv1 Querier Present
IGMPv2 IGMPv2 Querier Present running
and IGMPv1 Querier Present not running
稼働ではなく、IGMPv2 IGMPv2 Querier Present稼働とIGMPv1 Querier Present
IGMPv1 IGMPv1 Querier Present running
IGMPv1 IGMPv1 Querier Present稼働
If a host receives a query which causes its Querier Present timers to be updated and correspondingly its compatibility mode, it should switch compatibility modes immediately.
ホストがQuerier Presentタイマをアップデートする質問を受けるなら、互換性モードでありそれはすぐに、互換性モードを対応する、切り換えるべきです。
When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3 protocol on that interface. When Host Compatibility Mode is IGMPv2, a host acts in IGMPv2 compatibility mode, using only the IGMPv2 protocol, on that interface. When Host Compatibility Mode is IGMPv1, a host acts in IGMPv1 compatibility mode, using only the IGMPv1 protocol on that interface.
Host Compatibility ModeがIGMPv3であるときに、ホストは、そのインタフェースでIGMPv3プロトコルを使用することで行動します。 Host Compatibility ModeがIGMPv2であるときに、ホストはIGMPv2互換性モードで行動します、IGMPv2プロトコルだけを使用して、そのインタフェースで。 Host Compatibility ModeがIGMPv1であるときに、ホストはIGMPv1互換性モードで行動します、そのインタフェースでIGMPv1プロトコルだけを使用して。
Cain, et. al. Standards Track [Page 36] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[36ページ]RFC3376IGMPv3 October 2002
An IGMPv1 router will send General Queries with the Max Resp Code set to 0. This MUST be interpreted as a value of 100 (10 seconds).
IGMPv1ルータはResp Codeが0に設定するマックスと一緒にいるQueries司令官を送るでしょう。 100(10秒)の値としてこれを解釈しなければなりません。
An IGMPv2 router will send General Queries with the Max Resp Code set to the desired Max Resp Time, i.e., the full range of this field is linear and the exponential algorithm described in section 4.1.1 is not used.
IGMPv2ルータはResp Codeが必要なマックスResp Timeに設定するマックスと一緒にいるQueries司令官を送るでしょう、そして、すなわち、この分野の最大限の範囲は直線的です、そして、セクション4.1.1で説明された指数のアルゴリズムは使用されていません。
Whenever a host changes its compatibility mode, it cancels all its pending response and retransmission timers.
ホストが互換性モードを変えるときはいつも、それはそのすべての未定の応答と再送信タイマーを中止します。
7.2.2. In the Presence of Older Version Group Members
7.2.2. 旧式のバージョングループのメンバーの面前で
An IGMPv3 host may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 Membership Record to be suppressed by either a Version 1 Membership Report, or a Version 2 Membership Report.
IGMPv3ホストはまだIGMPv3にアップグレードしていないホストが一員であるネットワークに置かれるかもしれません。 ホストは、IGMPv3 Membership Recordがバージョン1Membership Reportかバージョン2Membership Reportのどちらかによって抑圧されるのを許すかもしれません。
7.3. Multicast Router Behavior
7.3. マルチキャストルータの振舞い
7.3.1. In the Presence of Older Version Queriers
7.3.1. 旧式のバージョンQueriersの面前で
IGMPv3 routers may be placed on a network where at least one router on the network has not yet been upgraded to IGMPv3. The following requirements apply:
IGMPv3ルータはネットワークの少なくとも1つのルータがまだIGMPv3にアップグレードしていないネットワークに置かれるかもしれません。 以下の要件は適用されます:
o If any older versions of IGMP are present on routers, the querier
MUST use the lowest version of IGMP present on the network. This
must be administratively assured; routers that desire to be
compatible with IGMPv1 and IGMPv2 MUST have a configuration option
to act in IGMPv1 or IGMPv2 compatibility modes. When in IGMPv1
mode, routers MUST send Periodic Queries with a Max Resp Code of 0
and truncated at the Group Address field (i.e., 8 bytes long), and
MUST ignore Leave Group messages. They SHOULD also warn about
receiving an IGMPv2 or IGMPv3 query, although such warnings MUST be
rate-limited. When in IGMPv2 mode, routers MUST send Periodic
Queries truncated at the Group Address field (i.e., 8 bytes long),
and SHOULD also warn about receiving an IGMPv3 query (such warnings
MUST be rate-limited). They also MUST fill in the Max Resp Time in
the Max Resp Code field, i.e., the exponential algorithm described
in section 4.1.1 is not used.
o IGMPの何か旧式のバージョンがルータに存在しているなら、querierはネットワークの現在のIGMPの最も低いバージョンを使用しなければなりません。 行政上これを保証しなければなりません。 ルータのIGMPv1と互換性があるその願望とIGMPv2には、IGMPv1で行動する設定オプションかIGMPv2互換性モードがなければなりません。 ルータがIGMPv1モードで0のマックスResp Codeと共にPeriodic Queriesを送らなければならなくて、Group Address分野で(すなわち、8バイト長)に先端を切らせて、Leave Groupメッセージを無視しなければならないとき。 それら、また、SHOULDはそのような警告がレートで限らなければなりませんが、IGMPv2かIGMPv3質問を受けることに関して警告します。 IGMPv2モードで、ルータがGroup Address分野(すなわち、8バイト長)で先端を切られたPeriodic Queriesを送らなければならなくて、また、SHOULDがIGMPv3質問を受けることに関して警告するとき(そのような警告はレートで限らなければなりません)。 また、彼らはマックスResp Code分野にマックスResp Timeに記入しなければなりません、すなわち、セクション4.1.1で説明された指数のアルゴリズムが使用されていません。
o If a router is not explicitly configured to use IGMPv1 or IGMPv2
and hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a
warning. These warnings MUST be rate-limited.
o aであるなら、ルータは、IGMPv1かIGMPv2を使用するために明らかに構成されないで、IGMPv1 QueryかIGMPv2の司令官のQueryを聞いて、それはSHOULDログa警告です。 これらの警告はレートで限らなければなりません。
Cain, et. al. Standards Track [Page 37] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[37ページ]RFC3376IGMPv3 October 2002
7.3.2. In the Presence of Older Version Group Members
7.3.2. 旧式のバージョングループのメンバーの面前で
IGMPv3 routers may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. In order to be compatible with older version hosts, IGMPv3 routers MUST operate in version 1 and version 2 compatibility modes. IGMPv3 routers keep a compatibility mode per group record. A group's compatibility mode is determined from the Group Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per group record and is dependent on the version of Membership Reports heard for that group as well as the Older Version Host Present timer for the group.
IGMPv3ルータはまだIGMPv3にアップグレードしていないホストが一員であるネットワークに置かれるかもしれません。 旧式のバージョンホストと互換性があるように、IGMPv3ルータはバージョン1とバージョン2互換性モードで作動しなければなりません。 IGMPv3ルータは、1グループ・レコードあたり互換性がモードであることを保ちます。 グループの互換性モードは3つの州の1つにあることができるGroup Compatibility Mode変数から決定しています: IGMPv1、IGMPv2またはIGMPv3。 この変数は、グループ・レコード単位で保たれて、グループのためのオールダーバージョンHost Presentタイマと同様にそのグループに関して聞かれたMembership Reportsのバージョンに依存しています。
In order to switch gracefully between versions of IGMP, routers keep an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per group record. The IGMPv1 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv1 Membership Report is received. The IGMPv2 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv2 Membership Report is received.
優雅にIGMPのバージョンを切り換えるために、ルータはIGMPv1 Host Presentタイマと1グループ・レコードあたり1個のIGMPv2 Host Presentタイマを保ちます。 IGMPv1 Membership Reportが受け取られているときはいつも、IGMPv1 Host PresentタイマはオールダーバージョンHost Present Timeout秒に設定されます。 IGMPv2 Membership Reportが受け取られているときはいつも、IGMPv2 Host PresentタイマはオールダーバージョンHost Present Timeout秒に設定されます。
The Group Compatibility Mode of a group record changes whenever an older version report (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Host Present timer expires, a router switches to Group Compatibility mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it does not have a running IGMPv2 Host Present timer then it switches to Group Compatibility of IGMPv3. When the IGMPv2 Host Present timer expires and the IGMPv1 Host Present timer is not running, a router switches to Group Compatibility mode of IGMPv3. Note that when a group switches back to IGMPv3 mode, it takes some time to regain source- specific state information. Source-specific information will be learned during the next General Query, but sources that should be blocked will not be blocked until [Group Membership Interval] after that.
旧式のバージョンレポート(現在の互換性モードより)が聞かれるときはいつも、あるタイマ状態が現れると、グループ・レコードのGroup Compatibility Modeは変化します。 IGMPv1 Host Presentタイマが期限が切れると、実行IGMPv2 Host Presentタイマを持っているなら、ルータはIGMPv2のGroup Compatibilityモードに切り替わります。 実行IGMPv2 Host Presentタイマを持っていないなら、それはIGMPv3のGroup Compatibilityに切り替わります。 IGMPv2 Host Presentタイマが期限が切れて、IGMPv1 Host Presentタイマが動いていないとき、ルータはIGMPv3のGroup Compatibilityモードに切り替わります。 グループがIGMPv3モードに元に戻るとき、ソースの特定の州の情報を取り戻すにはいくらかの時間がかかることに注意してください。 ソース特殊情報は次の司令官のQueryの間学習されるでしょうが、妨げられるべきであるソースはその後に[グループMembership Interval]まで妨げられないでしょう。
The Group Compatibility Mode variable is based on whether an older version report was heard in the last Older Version Host Present Timeout seconds. The Group Compatibility Mode is set depending on the following:
Group Compatibility Mode変数は旧式のバージョンレポートが最後のオールダーバージョンHost Present Timeout秒に聞かれたかどうか基づいています。 Group Compatibility Modeは以下によるのを用意ができています:
Cain, et. al. Standards Track [Page 38] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[38ページ]RFC3376IGMPv3 October 2002
Group Compatibility Mode Timer State ------------------------ -----------
グループ互換性モードタイマ状態------------------------ -----------
IGMPv3 (default) IGMPv2 Host Present not running
and IGMPv1 Host Present not running
稼働ではなく、稼働ではなく、IGMPv3(デフォルト)IGMPv2 Host PresentとIGMPv1 Host Present
IGMPv2 IGMPv2 Host Present running
and IGMPv1 Host Present not running
稼働ではなく、IGMPv2 IGMPv2 Host Present稼働とIGMPv1 Host Present
IGMPv1 IGMPv1 Host Present running
IGMPv1 IGMPv1 Host Present稼働
If a router receives a report which causes its older Host Present timers to be updated and correspondingly its compatibility mode, it SHOULD switch compatibility modes immediately.
ルータが、より古いHost Presentタイマを対応するアップデートするレポートを受け取る、互換性モード、それ、SHOULDはすぐに、互換性モードを切り換えます。
When Group Compatibility Mode is IGMPv3, a router acts using the IGMPv3 protocol for that group.
Group Compatibility ModeがIGMPv3であるときに、ルータは、そのグループにIGMPv3プロトコルを使用することで行動します。
When Group Compatibility Mode is IGMPv2, a router internally translates the following IGMPv2 messages for that group to their IGMPv3 equivalents:
Group Compatibility ModeがIGMPv2であるときに、ルータは内部的にそのグループへの以下のIGMPv2メッセージをそれらのIGMPv3同等物に翻訳します:
IGMPv2 Message IGMPv3 Equivalent
-------------- -----------------
IGMPv2メッセージIGMPv3同等物-------------- -----------------
Report IS_EX( {} )
レポートは_元の連れ合いです。( {} )
Leave TO_IN( {} )
_INにむけて発ってください。( {} )
IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX()
messages (i.e., any TO_EX() message is treated as TO_EX( {} )).
IGMPv3 BLOCKメッセージは無視されます、TO_EX()メッセージのソース・リストのように(すなわちどんなTO_EX()メッセージもTO_EXとして扱われる、()
When Group Compatibility Mode is IGMPv1, a router internally translates the following IGMPv1 and IGMPv2 messages for that group to their IGMPv3 equivalents:
Group Compatibility ModeがIGMPv1であるときに、ルータは内部的にそのグループへの以下のIGMPv1とIGMPv2メッセージをそれらのIGMPv3同等物に翻訳します:
IGMP Message IGMPv3 Equivalent
------------ -----------------
IGMPメッセージIGMPv3同等物------------ -----------------
v1 Report IS_EX( {} )
v1 Reportは_EXです。( {} )
v2 Report IS_EX( {} )
v2 Reportは_EXです。( {} )
In addition to ignoring IGMPv3 BLOCK messages and source-lists in TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave messages and IGMPv3 TO_IN() messages are also ignored.
また、IGMPv2 Group Compatibility ModeのようにTO_EX()メッセージのIGMPv3 BLOCKメッセージとソース・リストを無視することに加えて、IGMPv2 LeaveメッセージとIGMPv3 TO_IN()メッセージは無視されます。
Cain, et. al. Standards Track [Page 39] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[39ページ]RFC3376IGMPv3 October 2002
8. List of Timers, Counters and Their Default Values
8. タイマ、カウンタ、およびそれらのデフォルト値のリスト
Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all systems on a single link. Note that parentheses are used to group expressions to make the algebra clear.
これらのタイマの大部分は構成可能です。 非既定の設定が使用されているなら、それらは単一のリンクの上のすべてのシステムの中で一貫しているに違いありません。 括弧が代数を明らかにするために式を分類するのに使用されることに注意してください。
8.1. Robustness Variable
8.1. 丈夫さ変数
The Robustness Variable allows tuning for the expected packet loss on a network. If a network is expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2
Robustness Variableは、ネットワークにおける予想されたパケット損失で調整するのを許容します。 ネットワークが損失性であると予想されるなら、Robustness Variableは増強されるかもしれません。 IGMPは(丈夫さVariable--1)パケット損失に強健です。 Robustness Variableはゼロであるはずがありません、そして、SHOULD NOTは1にゼロです。 デフォルト: 2
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 network; 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 used to calculate the Max Resp Code inserted into the periodic General Queries. Default: 100 (10 seconds)
マックスResponse Timeは以前はよく周期的な司令官のQueriesに挿入されたマックスResp Codeについて計算していました。 デフォルト: 100 (10秒)
By varying the [Query Response Interval], an administrator may tune the burstiness of IGMP messages on the network; larger values make the traffic less bursty, as host responses are spread out over a larger interval. The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].
異なる、[質問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 or a particular source on a network.
Group Membership Intervalはマルチキャストルータが、ネットワークのグループか特定のソースのそれ以上のメンバーが全くいないと決める前に経過しなければならない時間です。
This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
この値は(Robustness Variable)回(Query Interval)と(1Query Response Interval)でなければならない。
Cain, et. al. Standards Track [Page 40] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[40ページ]RFC3376IGMPv3 October 2002
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の数です。 デフォルト: 丈夫さ変数。
8.8. Last Member Query Interval
8.8. 最後のメンバー質問間隔
The Last Member Query Interval is the Max Response Time used to calculate the Max Resp Code inserted into Group-Specific Queries sent in response to Leave Group messages. It is also the Max Response Time used in calculating the Max Resp Code for Group-and-Source- Specific Query messages. Default: 10 (1 second)
LastメンバーQuery IntervalはResponse TimeがLeave Groupメッセージに対応して送られたGroup特有のQueriesに挿入されたマックスResp Codeについて計算するのに使用したマックスです。 そして、また、それがGroupのためにマックスResp Codeについて計算する際に使用されるマックスResponse Timeである、-、-ソース特有のQueryは通信します。 デフォルト: 10 (1秒)
Note that for values of LMQI greater than 12.8 seconds, a limited set of values can be represented, corresponding to sequential values of Max Resp Code. When converting a configured time to a Max Resp Code value, it is recommended to use the exact value if possible, or the next lower value if the requested value is not exactly representable.
12.8秒以上のLMQIの値において、限られたセットの値を表すことができることに注意してください、マックスResp Codeの連続した値に対応しています。 マックスResp Code価値に構成された時間を変換するとき、できれば、正確な値を使用するのがお勧めである、または要求された値があるなら、次の下側の値はまさに「表-可能」されません。
This value may be tuned to modify the "leave latency" of the network. A reduced value results in reduced time to detect the loss of the last member of a group or source.
「潜在を残してください。」この値が変更するために調整されるかもしれない、ネットワークについて。 減少している値はグループかソースの最後のメンバーの損失を検出する減少している時間で結果として生じます。
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. The Last Member Query Count is also the number of Group-and-Source-Specific Queries sent before the router assumes there are no listeners for a particular source. Default: the Robustness Variable.
LastメンバーQuery Countはルータが、地元会員が全くいないと仮定する前に送られたGroup特有のQueriesの数です。 また、LastメンバーQuery Countはルータが、特定のソースへのリスナーが全くいないと仮定する前に送られたGroupの、そして、ソース特有のQueriesの数です。 デフォルト: 丈夫さ変数。
Cain, et. al. Standards Track [Page 41] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[41ページ]RFC3376IGMPv3 October 2002
8.10. Last Member Query Time
8.10. 最後のメンバー質問時間
The Last Member Query Time is the time value represented by the Last Member Query Interval, multiplied by the Last Member Query Count. It is not a tunable value, but may be tuned by changing its components.
LastメンバーQuery TimeはLastメンバーQuery Countが掛けられたLastメンバーQuery Intervalによって表された時間的価値です。 それは、調整可能な値ではありませんが、コンポーネントを変えることによって、調整されるかもしれません。
8.11. Unsolicited Report Interval
8.11. 求められていないレポート間隔
The Unsolicited Report Interval is the time between repetitions of a host's initial report of membership in a group. Default: 1 second.
Unsolicited Report Intervalはグループにおける、ホストの会員資格の初期のレポートの複写の間の時間です。 デフォルト: 1 2番目に。
8.12. Older Version Querier Present Timeout
8.12. 旧式のバージョンのQuerierの現在のタイムアウト
The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval.
旧式のバージョン質問がいったん聞かれると、オールダーバージョンQuerier IntervalはホストがIGMPv3モードに支持する移行のためのタイムアウトです。 旧式のバージョン質問が受け取られているとき、ホストは彼らのオールダーバージョンQuerier Present TimerをオールダーバージョンQuerier Intervalに設定します。
This value MUST be ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval).
この値はそのうえ(1Query Response Interval)、((Robustness Variable)回(最後のQueryのQuery Intervalは受信した))でなければなりません。
8.13. Older Host Present Interval
8.13. より古いホスト現在の間隔
The Older Host Present Interval is the time-out for transitioning a group back to IGMPv3 mode once an older version report is sent for that group. When an older version report is received, routers set their Older Host Present Timer to Older Host Present Interval.
そのグループのためにいったん旧式のバージョンレポートを送ると、オールダーHost Present IntervalはグループがIGMPv3モードに支持する移行のためのタイムアウトです。 旧式のバージョンレポートが受け取られているとき、ルータはそれらのオールダーHost Present TimerをオールダーHost Present Intervalに設定します。
This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
この値は(Robustness Variable)回(Query Interval)と(1Query Response Interval)でなければならない。
8.14. Configuring Timers
8.14. タイマを構成します。
This section is meant to provide advice to network administrators on how to tune these settings to their network. Ambitious router implementations might tune these settings dynamically based upon changing characteristics of the network.
このセクションはどうそれらのネットワークにこれらの設定を調整するかのネットワーク管理者にアドバイスを提供することになっています。 野心満々のルータ実装はダイナミックにネットワークの特性を変えるのに基づくこれらの設定を調整するかもしれません。
8.14.1. Robustness Variable
8.14.1. 丈夫さ変数
The Robustness Variable tunes IGMP to expected losses on a link. IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if the Robustness Variable is set to the default value of 2, IGMPv3 is robust to a single packet loss but may operate imperfectly if more
Robustness Variableはリンクの上に期待損失にIGMPを調整します。 IGMPv3は(丈夫さVariable--1)パケット損失に強健です、例えば、Robustness Variableが2のデフォルト値に用意ができているなら、IGMPv3は単一のパケット損失に強健ですが、より多くなら、不完全に作動するかもしれません。
Cain, et. al. Standards Track [Page 42] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[42ページ]RFC3376IGMPv3 October 2002
losses occur. On lossy subnetworks, the Robustness Variable should be increased to allow for the expected level of packet loss. However, increasing the Robustness Variable increases the leave latency of the subnetwork. (The leave latency is the time between when the last member stops listening to a source or group and when the traffic stops flowing.)
損失は発生します。 損失性サブネットワークでは、Robustness Variableは、パケット損失の予想水準を考慮するために増強されるべきです。 しかしながら、Robustness Variableを増強すると、休暇は増強されます。サブネットワークの潜在。 (休暇、間の最後のメンバーが止まる時がソースかグループを聴いていて、トラフィックが流れるのを止める潜在)。
8.14.2. Query Interval
8.14.2. 質問間隔
The overall level of periodic IGMP traffic is inversely proportional to the Query Interval. A longer Query Interval results in a lower overall level of IGMP traffic. The Query Interval MUST be equal to or longer than the Max Response Time inserted in General Query messages.
総合的なレベルの周期的なIGMPトラフィックは逆にQuery Intervalに変化しています。 より長いQuery Intervalは下側の総合的なレベルのIGMPトラフィックをもたらします。 Query IntervalはQuery司令官に挿入されたマックスResponse Timeより等しいか長いメッセージであるに違いありません。
8.14.3. Max Response Time
8.14.3. マックスResponse Time
The burstiness of IGMP traffic is inversely proportional to the Max Response Time. A longer Max Response Time will spread Report messages over a longer interval. However, a longer Max Response Time in Group-Specific and Source-and-Group-Specific Queries extends the leave latency. (The leave latency is the time between when the last member stops listening to a source or group and when the traffic stops flowing.) The expected rate of Report messages can be calculated by dividing the expected number of Reporters by the Max Response Time. The Max Response Time may be dynamically calculated per Query by using the expected number of Reporters for that Query as follows:
IGMPトラフィックのburstinessは逆にマックスResponse Timeに変化しています。 より長いマックスResponse Timeは、より長い間隔にわたってReportメッセージを広げるでしょう。 しかしながら、より長いマックスResponse TimeはGroup特有の、そして、Sourceの、そして、グループ特有のQueriesで休暇を広げています。潜在。 (休暇、間の最後のメンバーが止まる時がソースかグループを聴いていて、トラフィックが流れるのを止める潜在)。 Reportersの予想された数をマックスResponse Timeに割ることによって、Reportメッセージの予想されたレートについて計算できます。 マックスResponse TimeはQuery単位でダイナミックに以下のそのQueryにReportersの予想された数を使用することによって、計算されるかもしれません:
Query Type Expected number of Reporters
---------- ----------------------------
Reportersの質問Type Expected番号---------- ----------------------------
General Query All systems on subnetwork
サブネットワークの上の一般Query Allシステム
Group-Specific Query All systems that had expressed interest
in the group on the subnetwork
サブネットワークに関するグループへの関心を示したグループ特有のQuery Allシステム
Source-and-Group- All systems on the subnetwork that had
Specific Query expressed interest in the source and group
ソース、-、-Specific Queryを持っていたサブネットワークの上のすべてを分類しているシステムはソースとグループへの関心を示しました。
A router is not required to calculate these populations or tune the Max Response Time dynamically; these are simply guidelines.
ルータはこれらの人口について計算するか、またはダイナミックにマックスResponse Timeを調整するのに必要ではありません。 これらは単にガイドラインです。
9. Security Considerations
9. セキュリティ問題
We consider the ramifications of a forged message of each type, and describe the usage of IPSEC AH to authenticate messages if desired.
私たちは、それぞれのタイプの偽造メッセージの分岐を考えて、望まれているなら、メッセージを認証するためにIPSEC AHの使用法を説明します。
Cain, et. al. Standards Track [Page 43] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[43ページ]RFC3376IGMPv3 October 2002
9.1. Query Message
9.1. 質問メッセージ
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 DoS attack on a host could be staged through forged Group-and- Source-Specific Queries. The attacker can find out about membership of a specific host with a general query. After that it could send a large number of Group-and-Source-Specific queries, each with a large source list and the Maximum Response Time set to a large value. The host will have to store and maintain the sources specified in all of those queries for as long as it takes to send the delayed response. This would consume both memory and CPU cycles in order to augment the recorded sources with the source lists included in the successive queries.
そして、偽造Groupを通してホストに対するDoS攻撃を上演できた、-、-、ソース特有のQueries。 攻撃者は一般的な質問の特定のホストの会員資格を見つけることができます。 その後に、多くのGroupの、そして、ソース特有の質問を送るかもしれません、それぞれ大きいソース・リストと大きい値に用意ができているMaximum Response Timeと共に。 ホストは、遅延応答を送るにはかかる限り、それらの質問のすべてで指定されたソースを、保存して、維持しなければならないでしょう。 これは、ソース・リストが連続した質問に含まれている状態で記録されたソースを増大させるためにメモリとCPUサイクルの両方を費やすでしょう。
To protect against such a DoS attack, a host stack implementation could restrict the number of Group-and-Source-Specific Queries per group membership within this interval, and/or record only a limited number of sources.
そのようなDoS攻撃から守るために、ホストスタック実装は、この間隔中にグループ会員資格あたりのGroupの、そして、ソース特有のQueriesの数を制限する、そして/または、限られた数のソースだけを記録するかもしれません。
Forged Query messages from the local network can be easily traced. There are three measures necessary to defend against externally forged Queries:
容易に企業内情報通信網からの偽造Queryメッセージをたどることができます。 外部的に鍛造されたQueriesに対して防御するのに必要な3つの測定があります:
o Routers SHOULD NOT forward Queries. This is easier for a router to
accomplish if the Query carries the Router-Alert option.
o ルータSHOULD NOTはQueriesを進めます。 QueryがRouter-警戒オプションを運ぶなら、ルータには、これは達成するのが、より簡単です。
o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
option.
o ホストSHOULDはRouter-警戒オプションなしでv2かv3 Queriesを無視します。
o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
multicast address other than 224.0.0.1, the all-systems address.
o ホストSHOULDは司令官のQueriesがマルチキャストアドレスに発信したv1、v2またはv3を無視します。224.0 .0 .1、オールシステムアドレス。
9.2. Current-State Report messages
9.2. 現在の州のReportメッセージ
A forged Report message may cause multicast routers to think there are members of a group on a network when there are not. Forged Report messages from the local network are meaningless, since joining a group on a host is generally an unprivileged operation, so a local user may trivially gain the same result without forging any messages. Forged Report messages from external sources are more troublesome; there are two defenses against externally forged Reports:
偽造Reportメッセージはないとき、ネットワークに関するグループのメンバーがいると考えるルータをマルチキャストに引き起こすかもしれません。 企業内情報通信網からの偽造Reportメッセージは無意味です、地元のユーザがどんなメッセージも作り出さないで同じ結果を些細なことに獲得するかもしれなくてホストで仲間に入るのが、一般に「非-特権を与え」させられた操作であるので。 外部電源からの偽造Reportメッセージは、より厄介です。 2つのディフェンスが外部的に鍛造されたReportsに反対しています:
Cain, et. al. Standards Track [Page 44] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[44ページ]RFC3376IGMPv3 October 2002
o Ignore the Report if you cannot identify the source address of the
packet as belonging to a network assigned to the interface on which
the packet was received. This solution means that Reports sent by
mobile hosts without addresses on the local network will be
ignored. Report messages with a source address of 0.0.0.0 SHOULD
be accepted on any interface.
o パケットが受け取られたインタフェースに割り当てられたネットワークに属すとしてパケットのソースアドレスを特定できないなら、Reportを無視してください。 このソリューションは、企業内情報通信網でアドレスなしでモバイルホストによって送られたReportsが無視されることを意味します。 レポートが0.0のソースアドレスで.0を通信させる、.0SHOULD、あらゆるインタフェースで受け入れてください。
o Ignore Report messages without Router Alert options [RFC-2113], and
require that routers not forward Report messages. (The requirement
is not a requirement of generalized filtering in the forwarding
path, since the packets already have Router Alert options in them.)
This solution breaks backwards compatibility with implementations
of IGMPv1 or earlier versions of IGMPv2 which did not require
Router Alert.
o Router Alertオプション[RFC-2113]なしでReportメッセージを無視してください、そして、ルータがメッセージをReportに転送しないのを必要であってください。 (要件は推進経路の一般化されたフィルタリングの要件ではありません、パケットがそれらに既にRouter Alertオプションを持つので。) このソリューションは後方にRouter Alertを必要としなかったIGMPv1の実装かIGMPv2の以前のバージョンとの互換性を壊します。
A forged Version 1 Report Message may put a router into "version 1 members present" state for a particular group, meaning that the router will ignore Leave messages. This can cause traffic to flow to groups with no members for up to [Group Membership Interval]. This can be solved by providing routers with a configuration switch to ignore Version 1 messages completely. This breaks automatic compatibility with Version 1 hosts, so should only be used in situations where "fast leave" is critical.
バージョン1偽造Report Messageが特定のグループのために「バージョン1出席者」状態にルータを入れるかもしれません、ルータがLeaveメッセージを無視することを意味して。 これで、トラフィックは[グループMembership Interval]までメンバーなしでグループに注ぐことができます。 バージョン1メッセージを完全に無視するために設定スイッチをルータに提供することによって、これを解決できます。 1がホスティングするバージョンで自動互換性を壊すので、これは、「速い休暇」が重要である状況で使用されるだけであるべきです。
A forged Version 2 Report Message may put a router into "version 2 members present" state for a particular group, meaning that the router will ignore IGMPv3 source-specific state messages. This can cause traffic to flow from unwanted sources for up to [Group Membership Interval]. This can be solved by providing routers with a configuration switch to ignore Version 2 messages completely. This breaks automatic compatibility with Version 2 hosts, so should only be used in situations where source include and exclude is critical.
偽造バージョン2Report Messageは特定のグループのために「バージョン2出席者」状態にルータを入れるかもしれません、ルータがIGMPv3のソース特有の州のメッセージを無視することを意味して。 これで、トラフィックは[グループMembership Interval]まで求められていないソースから流れることができます。 バージョン2メッセージを完全に無視するために設定スイッチをルータに提供することによって、これを解決できます。 これが2がホスティングするバージョンとの自動互換性を壊して、そうによる状況で使用されて、どこがインクルードの出典を明示するかということだけであるべきである、除外、重要です。
9.3. State-Change Report Messages
9.3. 州変更報告書メッセージ
A forged State-Change Report message will cause the Querier to send out Group-Specific or Source-and-Group-Specific Queries for the group in question. This causes extra processing on each router and on each member of the group, but can not cause loss of desired traffic. There are two defenses against externally forged State-Change Report messages:
偽造州-変化Reportメッセージで、Querierは問題のグループのためにGroup特有の、または、Sourceの、そして、グループ特有のQueriesを出すでしょう。 これが、各ルータの上と、そして、グループの各メンバーの上で付加的な処理を引き起こしますが、必要なトラフィックの損失をもたらすことができません。 2つのディフェンスが外部的に鍛造された州-変化Reportメッセージに反対しています:
Cain, et. al. Standards Track [Page 45] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[45ページ]RFC3376IGMPv3 October 2002
o Ignore the State-Change Report message if you cannot identify the
source address of the packet as belonging to a subnet assigned to
the interface on which the packet was received. This solution
means that State-Change Report messages sent by mobile hosts
without addresses on the local subnet will be ignored. State-
Change Report messages with a source address of 0.0.0.0 SHOULD be
accepted on any interface.
o パケットが受け取られたインタフェースに割り当てられたサブネットに属すとしてパケットのソースアドレスを特定できないなら、州-変化Reportメッセージを無視してください。 このソリューションは、地方のサブネットでアドレスなしでモバイルホストによって送られた州-変化Reportメッセージが無視されることを意味します。 州の変化Reportが0.0のソースアドレスで.0を通信させる、.0SHOULD、あらゆるインタフェースで受け入れてください。
o Ignore State-Change Report messages without Router Alert options
[RFC-2113], and require that routers not forward State-Change
Report messages. (The requirement is not a requirement of
generalized filtering in the forwarding path, since the packets
already have Router Alert options in them.)
o Router Alertオプション[RFC-2113]なしで州-変化Reportメッセージを無視してください、そして、ルータが州-変化Reportメッセージを転送しないのを必要であってください。 (要件は推進経路の一般化されたフィルタリングの要件ではありません、パケットがそれらに既にRouter Alertオプションを持つので。)
9.4. IPSEC Usage
9.4. IPSEC用法
In addition to these measures, IPSEC in Authentication Header mode [AH] may be used to protect against remote attacks by ensuring that IGMPv3 messages came from a system on the LAN (or, more specifically, a system with the proper key). When using IPSEC, the messages sent to 224.0.0.1 and 224.0.0.22 should be authenticated using AH. When keying, there are two possibilities:
これらの測定に加えて、Authentication Headerモード[AH]によるIPSECは、IGMPv3メッセージがLAN(より明確に適切なキーがあるシステム)でシステムから来たのを確実にすることによってリモート攻撃から守るのに使用されるかもしれません。 そして、IPSECを使用するとき、メッセージが.0を224.0に送った、.1、224.0 .0 .22は、AHを使用することで認証されるべきです。 合わせるとき、2つの可能性があります:
1. Use a symmetric signature algorithm with a single key for the LAN
(or a key for each group). This allows validation that a packet
was sent by a system with the key. This has the limitation that
any system with the key can forge a message; it is not possible to
authenticate the individual sender precisely. It also requires
disabling IPSec's Replay Protection.
1. LAN(または、各グループのためのキー)に単一のキーがある左右対称の署名アルゴリズムを使用してください。 これはパケットがキーと共にシステムによって送られた合法化を許します。 これはキーがあるどんなシステムも持つことができる制限を持っています。メッセージを作り出してください。 正確に個々の送付者を認証するのは可能ではありません。 また、それは、IPSecのReplay Protectionを無効にするのを必要とします。
2. When appropriate key management standards have been developed, use
an asymmetric signature algorithm. All systems need to know the
public key of all routers, and all routers need to know the public
key of all systems. This requires a large amount of key
management but has the advantage that senders can be authenticated
individually so e.g., a host cannot forge a message that only
routers should be allowed to send.
2. 適切なかぎ管理規格を開発してあるときには、非対称の署名アルゴリズムを使用してください。 例えば、ホストがルータだけが許容されるべきであるというメッセージを作り出すことができないように個別に認証されて、すべてのルータがシステムこのすべての公開鍵が多量のかぎ管理を必要としますが、送付者がそうであることができる利点を持っているのを知るのにシステムが、すべてのルータの公開鍵を知る必要があって、送る必要があるすべて。
This solution only directly applies to Query and Leave messages in IGMPv1 and IGMPv2, since Reports are sent to the group being reported and it is not feasible to agree on a key for host-to-router communication for arbitrary multicast groups.
このソリューションは直接IGMPv1とIGMPv2のQueryとLeaveメッセージに適用されるだけです、報告されるグループにReportsを送って、任意のマルチキャストグループのためのホストからルータへのコミュニケーションのためにキーに同意するのが可能でないので。
Cain, et. al. Standards Track [Page 46] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[46ページ]RFC3376IGMPv3 October 2002
10. IANA Considerations
10. IANA問題
All IGMP types described in this document are already assigned in [IANA-REG].
本書では説明されたすべてのIGMPタイプが[IANA-REG]で既に選任されます。
11. Acknowledgments
11. 承認
We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert, Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for comments and suggestions on this document.
このドキュメントの上にコメントと提案についてRanアトキンソン、ルイス・コスタ、Toerlessエッケルト、ディーノ・ファリナッチ、セルジュFdida、Wilbert deグラーフ、Sumitグプタ、マーク・ハンドレー、ボブ・クイン、マイケル・シュペーア、デーヴThaler、およびロラン・ビーダに感謝申し上げます。
Portions of the text of this document were copied from [RFC-1112] and [RFC-2236].
このドキュメントの原本の部分は[RFC-1112]と[RFC-2236]からコピーされました。
12. Normative References
12. 引用規格
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[IANA-REG] http://www.iana.org/assignments/igmp-type-numbers
[IANA-レッジ] http://www.iana.org/assignments/igmp-type-numbers
[RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, August 1989.
[RFC-1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC-2113] Katz, D., "IP Router Alert Option," RFC 2113, February,
1997.
[RFC-2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
w.[RFC-2236]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[RFC-3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", BCP 57, RFC 3228, February
2002.
[RFC-3228] フェナー、B.、「IPv4インターネットグループ管理プロトコル(IGMP)のためのIANA問題」、BCP57、RFC3228、2002年2月。
13. Informative References
13. 有益な参照
[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[RFC-1071] ブレーデンとR.とボーマンとD.とC.Partridge、「インターネットチェックサムを計算します」、RFC1071、1988年9月。
[FILTER-API] Thaler, D., B. Fenner, and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", Work in
Progress.
[フィルタAPI] D.、B.フェナー、およびB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡大」というターレルは、進行中で動作します。
Cain, et. al. Standards Track [Page 47] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[47ページ]RFC3376IGMPv3 October 2002
[SSM] Bhattacharyya, S., et. al., "An Overview of Source-
Specific Multicast (SSM)", Work in Progress.
[SSM] et Bhattacharyya、S.、アル、「ソースの特定のマルチキャスト(SSM)の概要」、ProgressのWork。
[MLD] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[MLD] デアリングとS.とフェナーとW.とB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[MLDV2] Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I.
Kouvelas, and B. Haberman, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", Work in Progress.
[MLDV2] ビーダ、R.、L.コスタ、S.Fdida、S.デアリング、B.フェナー、I.Kouvelas、およびB.ハーバーマン、「IPv6"、進行中の仕事のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
Cain, et. al. Standards Track [Page 48] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[48ページ]RFC3376IGMPv3 October 2002
Appendix A. Design Rationale
付録A.デザイン原理
A.1 The Need for State-Change Messages
州変化メッセージのA.1必要性
IGMPv3 specifies two types of Membership Reports: Current-State and State Change. This section describes the rationale for the need for both these types of Reports.
IGMPv3はMembership Reportsの2つのタイプを指定します: 現状と状態は変化します。 このセクションはこれらのタイプのReportsの両方の必要性のために原理について説明します。
Routers need to distinguish Membership Reports that were sent in response to Queries from those that were sent as a result of a change in interface state. Membership reports that are sent in response to Membership Queries are used mainly to refresh the existing state at the router; they typically do not cause transitions in state at the router. Membership Reports that are sent in response to changes in interface state require the router to take some action in response to the received report (see Section 6.4).
ルータは、界面準位の変化の結果、送られたものとQueriesに対応して送られたMembership Reportsを区別する必要があります。 Membership Queriesに対応して送られる会員資格レポートは主にルータで現状をリフレッシュするのに使用されます。 彼らは状態でルータで変遷を通常引き起こしません。 界面準位の変化に対応して送られる会員資格Reportsは、受け取られていているレポートに対応して何らかの行動を取るためにルータを必要とします(セクション6.4を見てください)。
The inability to distinguish between the two types of reports would force a router to treat all Membership Reports as potential changes in state and could result in increased processing at the router as well as an increase in IGMP traffic on the network.
2つのタイプのレポートを見分けることができないことは、ルータに状態ですべてのMembership Reportsを潜在的変化として扱わせて、ネットワークでIGMPトラフィックの増加と同様にルータで増強された処理をもたらすかもしれません。
A.2 Host Suppression
A.2ホスト抑圧
In IGMPv1 and IGMPv2, a host would cancel sending a pending membership reports if a similar report was observed from another member on the network. In IGMPv3, this suppression of host membership reports has been removed. The following points explain the reasons behind this decision.
IGMPv1とIGMPv2では、ホストは、同様のレポートがネットワークで別のメンバーから観測されたなら未定の会員資格にレポートを送りながら、取り消すでしょう。 IGMPv3では、ホスト会員資格レポートのこの秘匿を取り除きました。 以下のポイントで、この決定の後ろで理由がわかります。
1. Routers may want to track per-host membership status on an
interface. This allows routers to implement fast leaves (e.g.,
for layered multicast congestion control schemes) as well as track
membership status for possible accounting purposes.
1. ルータはインタフェースで1ホストあたりの会員資格状態を追跡したがっているかもしれません。 これで、ルータは可能な会計目的のための道の会員資格状態と同様に速い葉(例えば、層にされたマルチキャスト輻輳制御体系のための)を実装することができます。
2. Membership Report suppression does not work well on bridged LANs.
Many bridges and Layer2/Layer3 switches that implement IGMP
snooping do not forward IGMP messages across LAN segments in order
to prevent membership report suppression. Removing membership
report suppression eases the job of these IGMP snooping devices.
2. 会員資格Report抑圧はブリッジしているLANでうまくいきません。 IGMP詮索を実装する多くのブリッジとLayer2/Layer3スイッチは、会員資格レポート抑圧を防ぐためにLANセグメントの向こう側にメッセージをIGMPに転送しません。 会員資格レポート抑圧を取り除くと、これらのIGMPがデバイスについて詮索する仕事は緩和されます。
3. By eliminating membership report suppression, hosts have fewer
messages to process; this leads to a simpler state machine
implementation.
3. 会員資格レポート抑圧を排除することによって、ホストには、処理するより少ないメッセージがあります。 これは、より簡単な州のマシン実装に通じます。
Cain, et. al. Standards Track [Page 49] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[49ページ]RFC3376IGMPv3 October 2002
4. In IGMPv3, a single membership report now bundles multiple
multicast group records to decrease the number of packets sent.
In comparison, the previous versions of IGMP required that each
multicast group be reported in a separate message.
4. IGMPv3では、ただ一つの会員資格レポートは、現在、送られたパケットの数を減少させるために複数のマルチキャストグループ・レコードを添付します。 相対的に、IGMPの旧バージョンは、それぞれのマルチキャストグループが別々のメッセージで報告されるのを必要としました。
A.3 Switching Router Filter Modes from EXCLUDE to INCLUDE
A.3切り換えルータがモードをフィルターにかける、インクルードへの除外
If there exist hosts in both EXCLUDE and INCLUDE modes for a single multicast group in a network, the router must be in EXCLUDE mode as well (see section 6.2.1). In EXCLUDE mode, a router forwards traffic from all sources unless that source exists in the exclusion source list. If all hosts in EXCLUDE mode cease to exist, it would be desirable for the router to switch back to INCLUDE mode seamlessly without interrupting the flow of traffic to existing receivers.
ホストが存在するなら、EXCLUDEとINCLUDEの両方では、ただ一つのマルチキャストのためのモードはネットワークで分類されて、ルータがまた、EXCLUDEモードであるに違いありません(セクション6.2.1を見てください)。 EXCLUDEモードで、そのソースが除外ソース・リストに存在していない場合、ルータはすべてのソースからトラフィックを進めます。 EXCLUDEモードによるすべてのホストが消滅するなら、ルータがシームレスに既存の受信機にトラフィックの流れを中断しないでINCLUDEモードに元に戻るのは、望ましいでしょう。
One of the ways to accomplish this is for routers to keep track of all sources desired by hosts that are in INCLUDE mode even though the router itself is in EXCLUDE mode. If the group timer now expires in EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode on the network (otherwise a membership report from that host would have refreshed the group timer). The router can then switch to INCLUDE mode seamlessly with the list of sources currently being forwarded in its source list.
これを達成する方法の1つはルータがルータ自体がEXCLUDEモードでありますが、INCLUDEモードでいるホストによって望まれていたすべてのソースの動向をおさえることです。 グループタイマが現在EXCLUDEモードで期限が切れるなら、それは、ネットワークのEXCLUDEモードにはホストが全くいないのを含意します(さもなければ、そのホストからの会員資格レポートはグループタイマをリフレッシュしたでしょう)。 そして、ルータはINCLUDEモードに現在ソース・リストでシームレスにソースのリストを転送している状態で切り替わることができます。
Appendix B. Summary of Changes from IGMPv2
IGMPv2からの変化の付録B.概要
While the main additional feature of IGMPv3 is the addition of source filtering, the following is a summary of other changes from RFC 2236.
IGMPv3の主な付加的な機能はソースフィルタリングの追加ですが、↓これはRFC2236からの他の変化の概要です。
o State is maintained as Group + List-of-Sources, not simply Group as
in IGMPv2.
o 状態はIGMPv2のようにソースのGroup+リスト、単にどんなGroupとしても維持されません。
o Interoperability with IGMPv1 and IGMPv2 systems is defined as
operations on the IGMPv3 state.
o IGMPv1とIGMPv2システムがある相互運用性はIGMPv3状態で操作と定義されます。
o The IP Service Interface has changed to allow specification of
source-lists.
o IP Service Interfaceは、ソース・リストの仕様を許容するために変化しました。
o The Querier includes its Robustness Variable and Query Interval in
Query packets to allow synchronization of these variables on non-
Queriers.
o Querierは、非Queriersにおけるこれらの変数の同期を許容するためにQueryパケットにそのRobustness VariableとQuery Intervalを含んでいます。
o The Max Response Time in Query messages has an exponential range,
changing the maximum from 25.5 seconds to about 53 minutes, for use
on links with huge numbers of systems.
o QueryメッセージのマックスResponse Timeには、指数の範囲があります、最大を25.5秒からおよそ53分に変えて、巨大な数のシステムとのリンクにおける使用のために。
o Hosts retransmit state-change messages for increased robustness.
o ホストは増強された丈夫さへの州変化メッセージを再送します。
Cain, et. al. Standards Track [Page 50] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[50ページ]RFC3376IGMPv3 October 2002
o Additional data sections are defined to allow later extensions.
o 追加資料課は、後の拡大を許すために定義されます。
o Report packets are sent to 224.0.0.22, to assist layer-2 switches
in "snooping".
o レポートパケットを224.0に送ります。.0 .22 層-2を補助するのは「詮索」で切り替わります。
o Report packets can contain multiple group records, to allow
reporting of full current state using fewer packets.
o レポートパケットは、完全な現状が、より少ないパケットを使用するのについて報告するのを許容するために複数のグループ・レコードを含むことができます。
o Hosts no longer perform suppression, to simplify implementations
and permit explicit membership tracking.
o ホストは、実装を簡素化して、明白な会員資格追跡を可能にするためにもう抑圧を実行しません。
o New Suppress Router-Side Processing (S) flag in Query messages
fixes robustness issues which were also present in IGMPv2.
o 新しいSuppress Router-サイドProcessing(S)は丈夫さが発行するまた、IGMPv2に存在しているQueryメッセージフィックスで弛みます。
Cain, et. al. Standards Track [Page 51] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[51ページ]RFC3376IGMPv3 October 2002
Authors' Addresses
作者のアドレス
Brad Cain Cereva Networks
ブラッドカインCerevaネットワーク
Steve Deering Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134-1706
タスマン・Driveサンノゼ、スティーブデアリングシスコシステムズInc.170カリフォルニア95134-1706
Phone: +1-408-527-8213 EMail: deering@cisco.com
以下に電話をしてください。 +1-408-527-8213 メールしてください: deering@cisco.com
Bill Fenner AT&T Labs - Research 75 Willow Rd. Menlo Park, CA 94025
ビルフェナーAT&T研究室--研究75Willow通り メンローパーク、カリフォルニア 94025
Phone: +1-650-330-7893 EMail: fenner@research.att.com
以下に電話をしてください。 +1-650-330-7893 メールしてください: fenner@research.att.com
Isidor Kouvelas Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134-1706
タスマン・Driveサンノゼ、Isidor KouvelasシスコシステムズInc.170カリフォルニア95134-1706
Phone: +1-408-525-0727 EMail: kouvelas@cisco.com
以下に電話をしてください。 +1-408-525-0727 メールしてください: kouvelas@cisco.com
Ajit Thyagarajan Ericsson IP Infrastructure
Ajit ThyagarajanエリクソンIPインフラストラクチャ
Cain, et. al. Standards Track [Page 52] RFC 3376 IGMPv3 October 2002
etカイン、アル。 標準化過程[52ページ]RFC3376IGMPv3 October 2002
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cain, et. al. Standards Track [Page 53]
etカイン、アル。 標準化過程[53ページ]
一覧
スポンサーリンク
