RFC4604 日本語訳

Network Working Group                                        H. Holbrook
Request for Comments: 4604                                 Arastra, Inc.
Updates: 3376, 3810                                              B. Cain
Category: Standards Track                                Acopia Networks
                                                             B. Haberman
                                                                 JHU APL
                                                             August 2006

コメントを求めるワーキンググループH.ホルブルック要求をネットワークでつないでください: 4604のArastra Inc.アップデート: 3376、3810B.カインカテゴリ: 規格はB.ハーバーマンJHU APL2006年8月にAcopiaネットワークを追跡します。

      Using Internet Group Management Protocol Version 3 (IGMPv3)
      and Multicast Listener Discovery Protocol Version 2 (MLDv2)
                     for Source-Specific Multicast

ソース特有のマルチキャストにインターネット集団経営プロトコルバージョン3(IGMPv3)とマルチキャストリスナー発見プロトコルバージョン2(MLDv2)を使用します。

Status of This Memo

このメモの状態

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

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   The Internet Group Management Protocol Version 3 (IGMPv3) and the
   Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols
   that allow a host to inform its neighboring routers of its desire to
   receive IPv4 and IPv6 multicast transmissions, respectively.
   Source-specific multicast (SSM) is a form of multicast in which a
   receiver is required to specify both the network-layer address of the
   source and the multicast destination address in order to receive the
   multicast transmission.  This document defines the notion of an
   "SSM-aware" router and host, and clarifies and (in some cases)
   modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and
   hosts to accommodate source-specific multicast.  This document
   updates the IGMPv3 and MLDv2 specifications.

インターネットGroup Managementプロトコルバージョン3(IGMPv3)とMulticast Listenerディスカバリープロトコルバージョン2(MLDv2)はホストがそれぞれIPv4を受け取る願望とIPv6マルチキャスト送信の隣接しているルータを知らせることができるプロトコルです。 ソース特有のマルチキャスト(SSM)は受信機がマルチキャスト送信を受けるためにソースのネットワーク層アドレスとマルチキャスト送付先アドレスの両方を指定するのに必要であるマルチキャストのフォームです。 このドキュメントは、「SSM意識している」ルータとホストの概念を定義して、はっきりさせて、(いくつかの場合、)ソース特有のマルチキャストを収容するようにSSM意識しているルータとホストでIGMPv3とMLDv2の動きを変更します。 このドキュメントはIGMPv3とMLDv2仕様をアップデートします。

Holbrook, et al.            Standards Track                     [Page 1]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[1ページ]。

1.  Introduction

1. 序論

   The Internet Group Management Protocol (IGMP) [RFC1112, IGMPv2,
   IGMPv3] allows an IPv4 host to communicate IP multicast group
   membership information to its neighboring routers.  IGMP version 3
   (IGMPv3) [IGMPv3] provides the ability for a host to selectively
   request or filter traffic from individual sources within a multicast
   group.

インターネットGroup Managementプロトコル(IGMP)[RFC1112、IGMPv2、IGMPv3]で、IPv4ホストはIPマルチキャストグループ会員資格情報を隣接しているルータに伝えることができます。 IGMPバージョン3(IGMPv3)[IGMPv3]はマルチキャストグループの中で能力を個々のソースから選択的に要求するホストかフィルタ交通に提供します。

   The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2]
   offers similar functionality for IPv6 hosts.  MLD version 2 (MLDv2)
   provides the analogous "source filtering" functionality of IGMPv3 for
   IPv6.

Multicast Listenerディスカバリープロトコル(MLD)[RFC2710、MLDv2]はIPv6ホストのために同様の機能性を提供します。 MLDバージョン2(MLDv2)はIGMPv3の類似の「ソースフィルタリング」の機能性をIPv6に供給します。

   Due to the commonality of function, the term "Group Management
   Protocol", or "GMP", will be used to refer to both IGMP and MLD.  The
   term "Source Filtering GMP", or "SFGMP", will be used to refer
   jointly to the IGMPv3 and MLDv2 group management protocols.

機能の共通点のため、用語の「グループ管理プロトコル」、または"GMP"が、IGMPとMLDの両方について言及するのに使用されるでしょう。 用語の「ソースフィルタリングGMP」、または"SFGMP"が、共同でIGMPv3とMLDv2グループ管理プロトコルを示すのに使用されるでしょう。

   The use of source-specific multicast is facilitated by small changes
   to the SFGMP protocols on both hosts and routers.  [SSM] defines
   general requirements that must be followed by systems that implement
   the SSM service model; this document defines the concrete application
   of those requirements to systems that implement IGMPv3 and MLDv2.  In
   doing so, this document defines modifications to the host and router
   portions of IGMPv3 and MLDv2 for use with SSM, and presents a number
   of clarifications to their behavior when used with SSM addresses.
   This document updates the IGMPv3 and MLDv2 specifications.

ソース特有のマルチキャストの使用はばら銭によってホストとルータの両方のSFGMPプロトコルに容易にされます。 [SSM]はSSMサービスモデルを実行するシステムが支えなければならない一般的な要件を定義します。 このドキュメントはそれらの要件の具体的なアプリケーションをIGMPv3とMLDv2を実行するシステムと定義します。 そうする際に、このドキュメントは、SSMとの使用のためにIGMPv3とMLDv2のホストとルータ一部への変更を定義して、SSMアドレスと共に使用されると、彼らの振舞いに多くの明確化を提示します。 このドキュメントはIGMPv3とMLDv2仕様をアップデートします。

1.1.  Terminology

1.1. 用語

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

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

   In order to emphasize the parts of this document that modify the
   existing protocol specifications ([RFC2710, MLDv2, IGMPv3]), as
   opposed to merely clarify them, any protocol modifications are marked
   with the tag "MODIFICATION".

と対照的に、存在を変更するこのドキュメントの部分を強調するために、仕様([RFC2710、MLDv2、IGMPv3])を議定書の中で述べてください、単にそれらをはっきりさせてください、そして、どんなプロトコル変更もタグ「変更」でマークされます。

2.  Host Requirements for Source-Specific Multicast

2. ソース特有のマルチキャストのためのホスト要件

   This section defines the notion of an "SSM-aware" host and then goes
   on to describe the API requirements and the SFGMP protocol
   requirements of an SSM-aware host.  It is important to note that SSM
   can be used by any host that supports source filtering APIs and whose
   operating system supports the appropriate SFGMP.  The SFGMP

このセクションは、「SSM意識している」ホストの概念を定義して、次に、SSM意識しているホストのAPI要件とSFGMPプロトコル要件について説明し続けます。 ソースフィルタリングAPIを支持して、オペレーティングシステムが適切なSFGMPを支持するどんなホストもSSMを使用できることに注意するのは重要です。 SFGMP

Holbrook, et al.            Standards Track                     [Page 2]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[2ページ]。

   modifications described in this section make SSM work better on an
   SSM-aware host, but they are not strict prerequisites for the use of
   SSM.

SSMはSSM意識しているホストの上でこのセクションで説明された変更でうまくいきますが、それらはSSMの使用のための厳しい前提条件ではありません。

   The 232/8 IPv4 address range is currently allocated for SSM by IANA
   [IANA-ALLOCATION].  In IPv6, the FF3x::/32 range (where 'x' is a
   valid IPv6 multicast scope value) is reserved for SSM semantics
   [RFC3306], although today SSM allocations are restricted to
   FF3x::/96.  ([SSM] has a more thorough discussion of this topic.)  A
   host that knows the SSM address range and is capable of applying SSM
   semantics to it is described as an "SSM-aware" host.

232/8IPv4アドレスの範囲は現在、SSMのためにIANA[IANA-ALLOCATION]によって割り当てられます。 IPv6、FF3xで:、:/32範囲('x'がa有効なIPv6マルチキャスト範囲価値であるところ)はSSM意味論[RFC3306]のために予約されます、SSM配分が今日、FF3xに制限されますが:、:/96. ([SSM]はこの話題の、より徹底的な議論をします。) SSMアドレスの範囲を知って、SSM意味論をそれに適用できるホストは、「SSM意識している」ホストとして記述されています。

   A host or router may be configured to apply SSM semantics to
   addresses other than those in the IANA-allocated range.  The GMP
   module on a host or router SHOULD have a configuration option to set
   the SSM address range(s).  If this configuration option exists, it
   MUST default to the IANA-allocated SSM range.  The mechanism for
   setting this configuration option MUST at least allow for manual
   configuration.  Protocol mechanisms to set this option may be defined
   in the future.

ホストかルータが、IANAによって割り当てられた範囲のそれら以外のアドレスにSSM意味論を適用するために構成されるかもしれません。 SHOULDが設定オプションを持っているホストかルータのGMPモジュールはSSMアドレスの範囲を設定しました。 この設定オプションが存在しているなら、それはIANAによって割り当てられたSSM範囲をデフォルトとしなければなりません。 オプションが手動の構成のために少なくとも許さなければならないこの構成を設定するためのメカニズム。 このオプションを設定するプロトコルメカニズムは将来、定義されるかもしれません。

2.1.  API Requirements

2.1. API要件

   If the host IP module of an SSM-aware host receives a non-source-
   specific request to receive multicast traffic sent to an SSM
   destination address, it SHOULD return an error to the application, as
   specified in [MSFAPI] (MODIFICATION).  On a non-SSM-aware host, an
   application that uses the wrong API (e.g., "join(G)",
   "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or
   "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery
   of packets sent to an SSM address will not receive the requested
   service, because an SSM-aware router (following the rules of this
   document) will refuse to process the request, and the application
   will receive no indication other than a failure to receive the
   requested traffic.

-マルチキャスト交通を受けるというソース特有の要求はSSM送付先アドレスに発信しました、それ。SSM意識しているホストのホストIPモジュールがaを受ける、非、SHOULDは指定されるとして[MSFAPI](MODIFICATION)で誤りをアプリケーションに返します。 a、非SSM意識する、ホスト、パケットの配信がSSMアドレスに発信したよう要求するのに、間違ったAPI(例えば、「(G)を接合してください」、IGMPv3のための「IPMulticastListen(G、(S1)を除く)」、またはMLDv2のための「IPv6MulticastListen(G、(S2)を除く)」)を使用するアプリケーションは要求されたサービスを受けないでしょう、SSM意識しているルータ(このドキュメントの規則に従う)が、要求を処理するのを拒否して、アプリケーションが要求された交通を受けないこと以外の指示を全く受けないので。

2.2.  GMP Requirements

2.2. GMP要件

   This section defines the behavior of the SFGMP protocol module on an
   SSM-aware host, including two modifications to the protocols as
   described in [IGMPv3, MLDv2].  It also includes a number of
   clarifications of protocol operations.  In doing so, it documents the
   behavior of an SSM-aware host with respect to sending and receiving
   the following GMP message types:

このセクションはSSM意識しているホストにおけるSFGMPプロトコルモジュールの振舞いを定義します、[IGMPv3、MLDv2]で説明されるプロトコルへの2つの変更を含んでいて。 また、それはプロトコル操作の多くの明確化を含んでいます。 そうする際に、発信に関してSSM意識しているホストの振舞いを記録します、そして、以下のGMPメッセージを受け取るのはタイプされます:

      - IGMPv1/v2 and MLDv1 Reports (2.2.1)
      - IGMPv3 and MLDv2 Reports (2.2.2)
      - IGMPv1 Queries, IGMPv2 and MLDv1 General Queries (2.2.3)

- IGMPv1/v2とMLDv1レポート、(2.2、.1、)、--、IGMPv3とMLDv2が報告する(2.2、.2、)、--、IGMPv1質問、IGMPv2、およびMLDv1の一般質問(2.2.3)

Holbrook, et al.            Standards Track                     [Page 3]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[3ページ]。

      - IGMPv2 Leave and MLDv1 Done (2.2.4)
      - IGMPv2 and MLDv1 Group Specific Query (2.2.5)
      - IGMPv3 and MLDv2 Group Specific Query (2.2.6)
      - IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7)

- IGMPv2休暇と行われたMLDv1、(2.2、.4、)、--、IGMPv2とMLDv1が特定の質問を分類する(2.2、.5、)、--、IGMPv3とMLDv2が特定の質問を分類する(2.2、.6、)、--IGMPv3とMLDv2が特定の質問を分類して、出典を明示する(2.2.7)

2.2.1.  IGMPv1/v2 and MLDv1 Reports

2.2.1. IGMPv1/v2とMLDv1レポート

   An SSM-aware host operating according to [IGMPv3, MLDv2] could send
   an IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is
   operating in "older-version compatibility mode."  This is an
   exceptional (error) condition, indicating that the router(s) cannot
   provide the SFGMP support needed for SSM, and an error is logged when
   the host enters compatibility mode for an SSM address, as described
   below.  In this situation, it is likely that traffic sent to a
   channel (S,G) will not be delivered to a receiving host that has
   requested to receive channel (S,G).

それであるときに[IGMPv3、MLDv2]に従って作動するのがIGMPv1、IGMPv2を送るかもしれないか、またはMLDv1がSSMアドレスのために報告するSSM意識しているホストは「旧式のバージョン互換性モード」で働いています。 これが例外的な(誤り)状態である、ホストがSSMアドレスのために互換性モードを入れるとき、ルータがSSMに必要であるサポート、および誤りをSFGMPに供給できないのを示すのが登録されます、以下で説明されるように。 この状況で、チャンネル(S、G)に送られた交通はそれがチャンネル(S、G)を受け取るよう要求した受信ホストに提供されそうにないでしょう。

   [IGMPv3] and [MLDv2] specify that a host MAY allow an older-version
   report to suppress its own IGMPv3 or MLDv2 Membership Record.  An
   SSM-aware host, however, MUST NOT allow its report to be suppressed
   in this situation (MODIFICATION).  Suppressing reports in this
   scenario would provide an avenue for an attacker to deny SSM service
   to other hosts on the link.

[IGMPv3]と[MLDv2]は、ホストが旧式のバージョンレポートにそれ自身のIGMPv3かMLDv2 Membership Recordを抑圧させるかもしれないと指定します。 しかしながら、SSM意識しているホストは、レポートがこの状況(MODIFICATION)で抑圧されるのを許してはいけません。 このシナリオでのレポートを抑圧すると、攻撃者がリンクの上に他のホストに対するサービスをSSMに対して否定するように、大通りは提供されるでしょう。

2.2.2.  IGMPv3 and MLDv2 Reports

2.2.2. IGMPv3とMLDv2レポート

   A host implementation may report more than one SSM channel in a
   single report either by including multiple sources within a group
   record or by including multiple group records.

ホスト導入は、グループ・レコードの中の複数のソースを含んでいるか、または複数のグループ・レコードを含んでいることによって、ただ一つのレポートの1個以上のSSMチャンネルを報告するかもしれません。

   A Group Record for a source-specific destination address may (under
   normal operation) be any of the following types:

ソース特有の送付先アドレスのためのGroup Recordは以下のタイプのいずれであるかもしれません(通常の操作で)も:

      - MODE_IS_INCLUDE as part of a Current-State Record

- MODE、__Current-状態の一部としてのINCLUDEはRecordです。

      - ALLOW_NEW_SOURCES as part of a State-Change Record

- aを離れさせるとき、ALLOW_NEW_SOURCESはRecordを州で変えます。

      - BLOCK_OLD_SOURCES as part of a State-Change Record

- aを離れさせるとき、BLOCK_OLD_SOURCESはRecordを州で変えます。

   A report may include both SSM destination addresses and non-source-
   specific, i.e., Any-Source Multicast (ASM) destination addresses, in
   the same message.

そして、レポートが両方のSSM送付先アドレスを含むかもしれない、非、-ソース特有です、すなわち、Any同じメッセージのMulticast(ASM)送付先アドレスの出典を明示してください。

   Additionally, a CHANGE_TO_INCLUDE_MODE record may be sent by a host
   in some cases, for instance, when the SSM address range is changed
   through configuration.  A router should process such a record
   according to the normal SFGMP rules.

例えば、さらに、構成を通してSSMアドレスの範囲を変えるとき、いくつかの場合、ホストはCHANGE_TO_INCLUDE_MODE記録を送るかもしれません。 正常なSFGMP規則に従って、ルータはそのような記録を処理するべきです。

Holbrook, et al.            Standards Track                     [Page 4]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[4ページ]。

   An SSM-aware host SHOULD NOT send any of the following record types
   for an SSM address.

SSM意識しているホストSHOULD NOTが以下のレコード種類のどれかをSSMに行かせるのをアドレス。

      - MODE_IS_EXCLUDE as part of a Current-State Record

- MODE、__Current-状態の一部としてのEXCLUDEはRecordです。

      - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record

- CHANGE_TO、_Filterモード変化Recordの一部としてのEXCLUDE_MODE

   This is a MODIFICATION to [IGMPv3, MLDv2], imposing a restriction on
   its use for SSM destination addresses.  The rationale is that EXCLUDE
   mode does not apply to SSM addresses, and an SSM-aware router will
   ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM
   range, as described below.

SSM送付先アドレスの使用に制限を課して、これは[IGMPv3、MLDv2]へのMODIFICATIONです。 原理はEXCLUDEモードがSSMアドレスに適用されないで、SSM意識しているルータがMODEを無視するのを_が_EXCLUDEであるということです、そして、SSMでのCHANGE_TO_EXCLUDE_MODE要求は及びます、以下で説明されるように。

2.2.3.  IGMPv1 Queries, IGMPv2 and MLDv1 General Queries

2.2.3. IGMPv1質問、IGMPv2、およびMLDv1の一般質問

   If an IGMPv1 Query, or an IGMPv2 or MLDv1 General Query is received,
   the SFGMP protocol specifications require the host to revert to the
   older (IGMPv1, IGMPv2, or MLDv1) mode of operation on that interface.
   If this occurs, the host will stop reporting source-specific
   subscriptions on that interface and will start using IGMPv1, IGMPv2,
   or MLDv1 to report interest in all SSM destination addresses,
   unqualified by a source address.  As a result, SSM semantics will no
   longer be applied to the multicast group address by the router.

IGMPv1 Query、IGMPv2またはMLDv1の司令官のQueryがそうなら、受け取られていて、SFGMPプロトコル仕様は、そのインタフェースでホストが、より古い(IGMPv1、IGMPv2、またはMLDv1)運転モードに先祖帰りをするのを必要とします。 これが起こると、ホストは、そのインタフェースに関してソース特有の購読を報告するのを止めて、すべてのSSM送付先アドレスへの関心を報告するのにIGMPv1、IGMPv2、またはMLDv1を使用し始めるでしょう、ソースアドレスで、資格がありません。 その結果、SSM意味論はもうルータによってマルチキャストグループアドレスに適用されないでしょう。

   A router compliant with this document would never generate an IGMPv1,
   IGMPv2, or MLDv1 query for an address in the SSM range; thus, this
   situation only occurs either if the router is not SSM-aware, or if
   the host and the router disagree about the SSM address range (for
   instance, if they have inconsistent manual configurations).

このドキュメントによる対応することのルータはSSM範囲でアドレスのためのIGMPv1、IGMPv2、またはMLDv1質問を決して発生させません。 したがって、ルータがSSM意識していないか、またはホストとルータがSSMアドレスの範囲について異なる意見をもつ場合にだけ、この状況は起こります(例えば、それらであるなら、矛盾した手動の構成を持ってください)。

   A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1
   query for an SSM address (MODIFICATION).

SSMアドレス(MODIFICATION)のためにIGMPv1、IGMPv2、またはMLDv1質問を受けるなら、ホストSHOULDは誤りを登録します。

   In order to mitigate this problem, it must be administratively
   assured that all routers on a given shared-medium network are
   compliant with this document and are in agreement about the SSM
   address range.

この問題を緩和するために、与えられた共有された媒体ネットワークのすべてのルータがこのドキュメントで言いなりになって、SSMアドレスの範囲に関して合意していることを行政上保証しなければなりません。

2.2.4.  IGMPv2 Leave and MLDv1 Done

2.2.4. IGMPv2休暇と行われたMLDv1

   IGMP Leave and MLD Done messages are not processed by hosts.  IGMPv2
   Leave and MLDv1 Done messages should not be sent for an SSM address,
   unless the sending host has reverted to older-version compatibility
   mode, with all the caveats described above.

IGMP LeaveとMLD Doneメッセージはホストによって処理されません。 SSMアドレスのためにIGMPv2 LeaveとMLDv1 Doneメッセージを送るべきではありません、送付ホストが旧式のバージョン互換性モードに先祖帰りをしていない場合、すべての警告が上で説明されている状態で。

Holbrook, et al.            Standards Track                     [Page 5]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[5ページ]。

2.2.5.  IGMPv2 and MLDv1 Group Specific Query

2.2.5. IGMPv2とMLDv1のグループの特定の質問

   If a host receives an IGMPv2 or MLDv1 Group Specific Query for an
   address in any configured source-specific range, it should process
   the query normally, as per [IGMPv3, MLDv2], even if the group queried
   is a source-specific destination address.  The transmission of such a
   query likely indicates either that the sending router is not
   compliant with this document or that it is not configured with the
   same SSM address range(s) as the receiving host.  A host SHOULD log
   an error in this case (MODIFICATION).

ホストがどんな構成されたソース特有の範囲のアドレスのためにもIGMPv2かMLDv1 Group Specific Queryを受け取るなら、通常、質問を処理するはずです、[IGMPv3、MLDv2]に従って、質問されたグループがソース特有の送付先アドレスであっても。 そのような質問の送信は、送付ルータがこのドキュメントで対応でない、またはそれが受信ホストと同じSSMアドレスの範囲によって構成されないのをおそらく示します。 ホストSHOULDはこの場合、誤り(MODIFICATION)を登録します。

2.2.6.  IGMPv3 and MLDv2 Group-Specific Query

2.2.6. IGMPv3とMLDv2のグループ特有の質問

   If an SSM-aware host receives an SFGMP Group-Specific Query for an
   SSM address, it must respond with a report if the group matches the
   source-specific destination address of any of its subscribed source-
   specific channels, as specified in [IGMPv3, MLDv2].

SSM意識しているホストがSSMアドレスのためにSFGMP Group特有のQueryを受け取るなら、グループが申し込まれたソース特定のチャンネルのどれかのソース特有の送付先アドレスに合っているなら、レポートで応じなければなりません、[IGMPv3、MLDv2]で指定されるように。

   The rationale for this is that, although in the current SFGMP
   protocol specifications a router would have no reason to send one,
   the semantics of such a query are well-defined in this range and
   future implementations may have reason to send such a query.  Be
   liberal in what you accept.

これのための原理はルータが現在のSFGMPプロトコル仕様に1つを送る理由を全く持たないでしょうが、そのような質問の意味論がこの範囲で明確であり、今後の実現にはそのような質問を送る理由があるかもしれないということです。 あなたが受け入れるものでは、寛容であってください。

2.2.7.  IGMPv3 and MLDv2 Group-and-Source-Specific Query

2.2.7. IGMPv3とMLDv2のグループの、そして、ソース特有の質問

   An SFGMP router typically uses a Group-and-Source-Specific Query to
   query an SSM channel that a host has requested to leave via a
   BLOCK_OLD_SOURCES record.  A host must respond to a Group-and-
   Source-Specific Query for which the group and source in the query
   match any channel for which the host has a subscription, as required
   by [IGMPv3, MLDv2].  The use of an SSM address does not change this
   behavior.

SFGMPルータは、ホストがBLOCK_OLD_SOURCES記録でいなくなるよう要求したSSMチャンネルについて質問するのにGroupの、そして、ソース特有のQueryを通常使用します。 そして、ホストがGroupに応じなければならない、-、-、ソース特有のQuery、どれ、いずれもチャネルを開設する質問マッチのホストが必要に応じて[IGMPv3、MLDv2]で購読を持っているグループとソース。 SSMアドレスの使用はこの振舞いを変えません。

   A host must be able to process a query with multiple sources listed
   per group, again as required by [IGMPv3, MLDv2].  The use of an SSM
   address does not modify the behavior of the SFGMPs in this regard.

複数のソースがグループ単位で記載されている状態で、ホストは再び必要に応じて[IGMPv3、MLDv2]で質問を処理できなければなりません。 SSMアドレスの使用はこの点でSFGMPsの動きを変更しません。

3.  Router Requirements for Source-Specific Multicast

3. ソース特有のマルチキャストのためのルータ要件

   Routers must be aware of the SSM address range in order to provide
   the SSM service model.  A router that knows the SSM address range and
   is capable of applying SSM semantics to it as described in this
   section is described as an "SSM-aware" router.  An SSM-aware router
   MAY have a configuration option to apply SSM semantics to addresses
   other than the IANA-allocated range, but if such an option exists, it
   MUST default to the IANA-allocated range.

ルータは、SSMサービスモデルを提供するためにSSMアドレスの範囲を意識していなければなりません。 このセクションで説明されるようにSSMアドレスの範囲を知って、SSM意味論をそれに適用できるルータは、「SSM意識している」ルータとして記述されています。 SSM意識しているルータには、IANAによって割り当てられた範囲以外のアドレスにSSM意味論を適用する設定オプションがあるかもしれませんが、そのようなオプションが存在しているなら、それはIANAによって割り当てられた範囲をデフォルトとしなければなりません。

Holbrook, et al.            Standards Track                     [Page 6]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[6ページ]。

   This section documents the behavior of routers with respect to the
   following types of SFGMP messages for source-specific destination
   addresses:

このセクションはソース特有の送付先アドレスへの以下のタイプのSFGMPメッセージに関してルータの振舞いを記録します:

      - IGMPv3 and MLDv2 Reports (3.1)
      - IGMPv3 and MLDv2 General Query (3.2)
      - IGMPv3 and MLDv2 Group-Specific Query (3.3)
      - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4)
      - IGMPv1/v2 and MLDv1 Reports (3.5)
      - IGMPv1/v2 and MLDv1 Queries (3.6)
      - IGMPv2 Leave and MLDv1 Done (3.7)

- 行われたIGMPv3、MLDv2レポート(3.1)--IGMPv3とMLDv2の一般質問(3.2)--IGMPv3、MLDv2のグループ特有の質問(3.3)--IGMPv3とMLDv2のグループとソースの特定の質問(3.4)--IGMPv1/v2、IGMPv2が残すMLDv1レポート(3.5)(IGMPv1/v2とMLDv1質問(3.6))、およびMLDv1(3.7)

3.1.  IGMPv3 and MLDv2 Reports

3.1. IGMPv3とMLDv2レポート

   SFGMP Reports are used to report source-specific subscriptions in the
   SSM address range.  A router SHOULD ignore a group record of either
   of the following types if it refers to an SSM destination address:

SFGMP Reportsは、SSMアドレスの範囲でソース特有の購読を報告するのに使用されます。 SHOULDがグループ・レコードを無視する以下のタイプのルータはそれであるならSSM送付先アドレスを参照します:

         - MODE_IS_EXCLUDE Current-State Record

- モード_は_が現状記録を除くということです。

         - CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record

- _への変化_は_モード・フィルタモード変更記録を除きます。

   A router MAY choose to log an error in either case.  It MUST process
   any other group records within the same report.  These behaviors are
   MODIFICATIONS to [IGMPv3, MLDv2] to prevent non-source-specific
   semantics from being applied to SSM addresses, and to avoid reverting
   to older-version compatibility mode.

ルータは、どちらかの場合における誤りを登録するのを選ぶかもしれません。 それは同じレポートの中でいかなる他のグループ・レコードも処理しなければなりません。 これらの振舞いは非ソースの詳細意味論がSSMアドレスに適用されるのを防いで、旧式のバージョン互換性モードに戻るのを避ける[IGMPv3、MLDv2]へのMODIFICATIONSです。

   A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per
   the normal SFGMP rules; Section 2.2.2 describes a legitimate scenario
   when this could occur.

CHANGE_TO_INCLUDE_MODE Filter-モード変化Recordは正常なSFGMP規則単位で処理されます。 セクション2.2 .2 これが起こることができたなら、正統のシナリオについて説明します。

3.2.  IGMPv3 and MLDv2 General Queries

3.2. IGMPv3とMLDv2の一般質問

   An SSM router sends periodic SFGMP General Queries as per the IGMPv3
   and MLDv2 specifications.  No change in behavior is required for SSM.

SSMルータはIGMPv3とMLDv2仕様に従って周期的なSFGMP司令官Queriesを送ります。 振舞いにおける変化は全くSSMに必要ではありません。

3.3.  IGMPv3 and MLDv2 Group-Specific Queries

3.3. IGMPv3とMLDv2のグループ特有の質問

   SFGMP routers that support source-specific multicast may send group-
   specific queries for addresses in the source-specific range.  This
   specification does not explicitly prohibit such a message, although,
   at the time of this writing, a router conformant to [IGMPv3, MLDv2]
   would not send one.

ソース特有のマルチキャストを支持するSFGMPルータはソース特有の範囲のアドレスのためのグループの特定の質問を送るかもしれません。 この仕様は明らかにそのようなメッセージを禁止しないで、この書くこと時点の[IGMPv3、MLDv2]へのルータconformantは送らないでしょうが、1つを送ってください。

Holbrook, et al.            Standards Track                     [Page 7]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[7ページ]。

3.4.  IGMPv3 and MLDv2 Group-and-Source-Specific Queries

3.4. IGMPv3とMLDv2のグループの、そして、ソース特有の質問

   SFGMP Group-and-Source-Specific Queries are used when a receiver has
   indicated that it is no longer interested in receiving traffic from a
   particular (S,G) pair to determine if there are any remaining
   directly-attached hosts with interest in that (S,G) pair.  Group-
   and-Source-Specific Queries are used within the source-specific
   address range when a router receives a BLOCK_OLD_SOURCES Record for
   one or more source-specific groups.  These queries are sent normally,
   as per [IGMPv3, MLDv2].

受信機が、(S、G)が対にされるので何か関心をもっている残っている直接付属しているホストがいるかどうか決定するためにもう特定(S、G)の組からの交通を受けたがっていないのを示したとき、SFGMP Groupの、そして、ソース特有のQueriesは使用されています。 グループ、ソース特有である、ルータが1つ以上のソース特有のグループのためにBLOCK_OLD_SOURCES Recordを受けるとき、Queriesはソース特有のアドレスの範囲の中で使用されます。 通常、[IGMPv3、MLDv2]に従ってこれらの質問を送ります。

3.5.  IGMPv1/v2 and MLDv1 Reports

3.5. IGMPv1/v2とMLDv1レポート

   An IGMPv1/v2 or MLDv1 report for an address in the source-specific
   range could be sent by a non-SSM-aware host.  A router SHOULD ignore
   all such reports and specifically SHOULD NOT use them to establish IP
   forwarding state.  This is a MODIFICATION to [IGMPv3, MLDv2].  A
   router MAY log an error if it receives such a report (also a
   MODIFICATION).

aでソース特有の範囲のアドレスのためのIGMPv1/v2かMLDv1レポートを送ることができた、非SSM意識する、ホスト。 ルータSHOULDはそのようなすべてのレポートを無視します、そして、明確にSHOULD NOTはIPを証明するのに状態を進めながら、それらを使用します。 これは[IGMPv3、MLDv2]へのMODIFICATIONです。 そのようなレポート(MODIFICATIONも)を受け取るなら、ルータは誤りを登録するかもしれません。

3.6.  IGMPv1/v2 and MLDv1 Queries

3.6. IGMPv1/v2とMLDv1質問

   An SFGMP router that loses the querier election to a lower version
   router must log an error, as specified by [IGMPv3, MLDv2].

下側のバージョンルータにquerier選挙に負けるSFGMPルータは誤りを登録しなければなりません、[IGMPv3、MLDv2]によって指定されるように。

3.7.  IGMPv2 Leave and MLDv1 Done

3.7. IGMPv2休暇と行われたMLDv1

   An IGMPv2 Leave or MLDv1 Done message may be sent by a non-SSM-aware
   host.  A router SHOULD ignore all such messages in the source-
   specific address range and MAY log an error (MODIFICATION).

aでIGMPv2 LeaveかMLDv1 Doneメッセージを送るかもしれない、非SSM意識する、ホスト。 ルータSHOULDはソースの特定のアドレスの範囲でそのようなすべてのメッセージを無視して、誤り(MODIFICATION)を登録するかもしれません。

4.  Security Considerations

4. セキュリティ問題

   The specific protocol modifications described in this document are
   not known to create any security concerns that are not already
   present when IGMPv3 or MLDv2 is used with ASM-style multicast.  The
   reader is referred to [SSM] for an analysis of SSM-specific security
   issues.

本書では説明された特定のプロトコル変更がどんなIGMPv3かMLDv2がASM-スタイルマルチキャストと共に使用されるとき既に存在していない安全上の配慮も作成するのが知られません。 読者はSSM特有の安全保障問題の分析について言及されます[SSM]。

   It is important that a router not accept non-source-specific
   reception requests for an SSM destination address.  The rules of
   [IGMPv3] and [MLDv2] require a router, upon receiving such a
   membership report, to revert to earlier version compatibility mode
   for the group in question.  If the router were to revert in this
   situation, it would prevent an IGMPv3-capable host from receiving SSM
   service for that destination address, thus creating a potential for
   an attacker to deny SSM service to other hosts on the same link.

ルータがSSM送付先アドレスを求める非ソースの詳細レセプション要求を受け入れないのは、重要です。 [IGMPv3]と[MLDv2]の規則はルータを必要とします、問題のグループのために以前のバージョン互換性モードに戻るためにそのような会員資格レポートを受け取ることに関して。 ルータがこの状況で戻ることであるなら、IGMPv3有能なホストがその送付先アドレスのためのSSMサービスを受けるのを防ぎます、その結果、攻撃者が同じリンクの上に他のホストに対するサービスをSSMに対して否定する可能性を作成します。

Holbrook, et al.            Standards Track                     [Page 8]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[8ページ]。

5.  Acknowledgements

5. 承認

   The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve
   Deering, Toerless Eckert, and Pekka Savola for their input and
   careful review.

作者は彼らの入力と慎重なレビューについてビンスLaviano、Nidhi Bhaskar、スティーブ・デアリング、Toerlessエッケルト、およびペッカSavolaに感謝したがっています。

6.  Normative References

6. 引用規格

   [IGMPv2]     Fenner, W., "Internet Group Management Protocol, Version
                2", RFC 2236, November 1997.

w.[IGMPv2]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。

   [IGMPv3]     Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
                Thyagarajan, "Internet Group Management Protocol,
                Version 3", RFC 3376, October 2002.

[IGMPv3] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」

   [MSFAPI]     Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
                Extensions for Multicast Source Filters", RFC 3678,
                January 2004.

[MSFAPI] ターレル、D.、フェナー、B.、およびB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡大」、RFC3678、2004年1月。

   [RFC1112]    Deering, S., "Host extensions for IP multicasting", STD
                5, RFC 1112, August 1989.

[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [SSM]        Holbrook, H. and B. Cain, "Source-Specific Multicast for
                IP", RFC 4607, August 2006.

[SSM] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、2006年8月。

   [MLDv2]      Vida, R. and L. Costa, "Multicast Listener Discovery
                Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

そして、[MLDv2]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」

   [RFC2710]    Deering, S., Fenner, W., and B. Haberman, "Multicast
                Listener Discovery (MLD) for IPv6", RFC 2710, October
                1999.

[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」

8.  Informative References

8. 有益な参照

   [IANA-ALLOC] Internet Assigned Numbers Authority,
                http://www.iana.org/assignments/multicast-addresses.

[IANA-ALLOC]インターネットは数の権威、 http://www.iana.org/assignments/multicast-addresses を割り当てました。

   [RFC3306]    Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
                Multicast Addresses", RFC 3306, August 2002.

[RFC3306] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。

Holbrook, et al.            Standards Track                     [Page 9]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[9ページ]。

Authors' Addresses

作者のアドレス

   Hugh Holbrook
   Arastra, Inc.
   P.O. Box 10905
   Palo Alto, CA 94303

パロアルト、ヒューホルブルックArastra Inc.P.O. Box10905カリフォルニア 94303

   Phone: +1 650 331-1620
   EMail: holbrook@arastra.com

以下に電話をしてください。 +1 650 331-1620 メールしてください: holbrook@arastra.com

   Brad Cain
   Acopia Networks

ブラッドカインAcopiaネットワーク

   EMail: bcain99@gmail.com

メール: bcain99@gmail.com

   Brian Haberman
   Johns Hopkins University Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, MD  20723-6099

ブライアンハーバーマンジョーンズ・ホプキンス大学応用物理学研究室11100のジョーンズ・ホプキン・Roadローレル、MD20723-6099

   EMail: brian@innovationslab.net

メール: brian@innovationslab.net

Holbrook, et al.            Standards Track                    [Page 10]

RFC 4604                IGMPv3/MLDv2 for SSM                 August 2006

ホルブルック、他 規格は2006年8月にSSMのためにRFC4604IGMPv3/MLDv2を追跡します[10ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Holbrook, et al.            Standards Track                    [Page 11]

ホルブルック、他 標準化過程[11ページ]