[要約] RFC 4607は、IPのためのソース特定マルチキャストに関する規格であり、ソース特定マルチキャストの目的は、特定の送信元からのマルチキャストトラフィックを効率的に配信することです。
Network Working Group H. Holbrook
Request for Comments: 4607 Arastra, Inc.
Category: Standards Track B. Cain
Acopia Networks
August 2006
Source-Specific Multicast for IP
IP用のソース固有のマルチキャスト
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.
232/8（232.0.0.0〜232.255.255.255）のIPバージョン4（IPv4）アドレスは、ソース固有のマルチキャスト（SSM）宛先アドレスとして指定され、ソース固有のアプリケーションとプロトコルで使用するために予約されています。IPバージョン6（IPv6）の場合、アドレスプレフィックスFF3X ::/32は、ソース固有のマルチキャスト使用のために予約されています。このドキュメントでは、SSMアドレスに送信されたデータグラムに適用されるインターネットネットワークサービスへの拡張機能を定義し、この拡張機能をサポートするホストとルーターの要件を定義します。
Table of Contents
目次
1. Introduction ....................................................3
2. Semantics of Source-Specific Multicast Addresses ................5
3. Terminology .....................................................6
4. Host Requirements ...............................................7
4.1. Extensions to the IP Module Interface ......................7
4.2. Requirements on the Host IP Module .........................8
4.3. Allocation of Source-Specific Multicast Addresses ..........9
5. Router Requirements ............................................10
5.1. Packet Forwarding .........................................10
5.2. Protocols .................................................10
6. Link-Layer Transmission of Datagrams ...........................11
7. Security Considerations ........................................12
7.1. IPsec and SSM .............................................12
7.2. SSM and RFC 2401 IPsec Caveats ............................12
7.3. Denial of Service .........................................13
7.4. Spoofed Source Addresses ..................................13
7.5. Administrative Scoping ....................................14
8. Transition Considerations ......................................14
9. IANA Considerations ............................................15
10. Acknowledgements ..............................................15
11. Normative References ..........................................16
12. Informative References ........................................17
The Internet Protocol (IP) multicast service model is defined in RFC 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP multicast address (224.0.0.0 through 239.255.255.255) G is delivered to each "upper-layer protocol module" that has requested reception of datagrams sent to address G. RFC 1112 calls the network service identified by a multicast destination address G a "host group". This model supports both one-to-many and many-to-many group communication. This document uses the term "Any-Source Multicast" (ASM) to refer to model of multicast defined in RFC 1112. RFC 3513 [RFC3513] specifies the form of IPv6 multicast addresses with ASM semantics.
インターネットプロトコル（IP）マルチキャストサービスモデルは、RFC 1112 [RFC1112]で定義されています。RFC 1112は、IPマルチキャストアドレスに送信されたデータグラム（224.0.0.0〜239.255.255.255）が各「上層層プロトコルモジュール」に配信されることを指定します。マルチキャストの宛先アドレスg「ホストグループ」によって識別されます。このモデルは、1対多で多数のグループコミュニケーションの両方をサポートします。このドキュメントでは、「Any-Source Multicast」（ASM）という用語を使用して、RFC 1112で定義されたマルチキャストのモデルを指します。RFC3513[RFC3513]は、ASMセマンティクスを使用したIPv6マルチキャストアドレスの形式を指定します。
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are currently designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOC].
232/8（232.0.0.0〜232.255.255.255）のIPv4アドレスは現在、ソース固有のマルチキャスト（SSM）宛先アドレスとして指定されており、ソース固有のアプリケーションとプロトコル[IANA-Alloc]で使用するために予約されています。
For IPv6, the address prefix FF3x::/32 is reserved for source-specific multicast use, where 'x' is any valid scope identifier, by [IPv6-UBM]. Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field of an SSM address also be set to zero, hence all SSM addresses fall in the FF3x::/96 range. Future documents may allow a non-zero network prefix field if, for instance, a new IP-address-to-MAC-address mapping is defined. Thus, address allocation should occur within the FF3x::/96 range, but a system should treat all of FF3x::/32 as SSM addresses, to allow for compatibility with possible future uses of the network prefix field.
IPv6の場合、アドレスプレフィックスFF3X ::/32は、[IPv6-UBM]によるソース固有のマルチキャスト使用のために予約されています。[IPv6-UBM]の用語を使用すると、すべてのSSMアドレスがp = 1、t = 1、およびplen = 0が必要です。[IPv6-Malloc]は、SSMアドレスのネットワークプレフィックスフィールドもゼロに設定されることを義務付けているため、すべてのSSMアドレスはFF3X ::/96範囲に分類されます。将来のドキュメントでは、たとえば新しいIP Address-to-MAC-Addressマッピングが定義されている場合、ゼロ以外のネットワークプレフィックスフィールドを許可する場合があります。したがって、アドレス割り当てはFF3X ::/96範囲内で発生する必要がありますが、システムはFF3X ::/32のすべてをSSMアドレスとして扱う必要があります。
Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic allocation by a host, as described in [IPv6-MALLOC]. Addresses in the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM addresses. ([IPv6-MALLOC] indicates that FF3x::0000:0001 to FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPv6-UBM] mandates that P=1 and T=1, hence their designation as invalid.) The treatment of a packet sent to such an invalid address is undefined -- a router or host MAY choose to drop such a packet.
範囲のアドレスFF3X :: 4000：0001からFF3X :: 7FFF：FFFFは、IANAによる割り当てのために[IPv6-Malloc]で予約されています。範囲内のアドレスFF3X :: 8000：0000からFF3X :: FFFF：FFFFは、[IPv6-Malloc]に記載されているように、ホストによる動的割り当てに許可されています。範囲のアドレスFF3X :: 0000：0000からFF3X :: 3FFF：FFFFは無効なIPv6 SSMアドレスです。（[IPv6-Malloc]は、ff3x :: 0000：0001からff3x :: 3fff：ffffがp = 0およびt = 0を設定する必要があることを示しますが、SSMの場合、[IPv6-UBM]はp = 1およびt = 1を義務付けています。したがって、そのような無効なアドレスに送られたパケットの処理は未定義です。ルーターまたはホストは、そのようなパケットをドロップすることを選択できます。
Source-specific multicast delivery semantics are provided for a datagram sent to an SSM address. That is, a datagram with source IP address S and SSM destination address G is delivered to each upper-layer "socket" that has specifically requested the reception of datagrams sent to address G by source S, and only to those sockets. The network service identified by (S,G), for SSM address G and source host address S, is referred to as a "channel". In contrast to the ASM model of RFC 1112, SSM provides network-layer support for one-to-many delivery only.
SSMアドレスに送信されたデータグラムに対して、ソース固有のマルチキャスト配信セマンティクスが提供されます。つまり、ソースIPアドレスsとSSM宛先アドレスGを備えたデータグラムは、ソースSがアドレスGに送信するために送信されたデータグラムの受信を特に要求し、それらのソケットにのみ要求した各上層層「ソケット」に配信されます。SSMアドレスGおよびソースホストアドレスsの（S、G）によって識別されるネットワークサービスは、「チャネル」と呼ばれます。RFC 1112のASMモデルとは対照的に、SSMは1対多くの配信のみをネットワーク層サポートを提供します。
The benefits of source-specific multicast include:
ソース固有のマルチキャストの利点は次のとおりです。
Elimination of cross-delivery of traffic when two sources simultaneously use the same source-specific destination address. The simultaneous use of an SSM destination address by multiple sources and different applications is explicitly supported.
2つのソースが同じソース固有の宛先アドレスを同時に使用する場合、トラフィックの相互配信の排除。複数のソースと異なるアプリケーションによるSSM宛先アドレスの同時使用が明示的にサポートされています。
Avoidance of the need for inter-host coordination when choosing source-specific addresses, as a consequence of the above.
上記の結果として、ソース固有のアドレスを選択する際のホスト間調整の必要性の回避。
Avoidance of many of the router protocols and algorithms that are needed to provide the ASM service model. For instance, the "shared trees" and Rendezvous Points of the PIM - Sparse Mode (PIM-SM) protocol [PIM-SM] are not necessary to support the source-specific model. The router mechanisms required to support SSM are in fact largely a subset of those that are used to support ASM. For example, the shortest-path tree mechanism of the PIM-SM protocol can be adapted to provide SSM semantics.
ASMサービスモデルを提供するために必要な多くのルータープロトコルとアルゴリズムの回避。たとえば、PIM-SPARSEモード（PIM-SM）プロトコル[PIM-SM]の「共有ツリー」とランデブーポイントは、ソース固有のモデルをサポートする必要はありません。SSMをサポートするために必要なルーターメカニズムは、実際には主にASMをサポートするために使用されるサブセットのサブセットです。たとえば、PIM-SMプロトコルの最短パスツリーメカニズムは、SSMセマンティクスを提供するように適合させることができます。
Like ASM, the set of receivers is unknown to an SSM sender. An SSM source is provided with neither the identity of receivers nor their number.
ASMと同様に、レシーバーのセットはSSM送信者には不明です。SSMソースには、受信機のアイデンティティもその番号も提供されていません。
SSM is particularly well-suited to dissemination-style applications with one or more senders whose identities are known before the application begins. For instance, a data dissemination application that desires to provide a secondary data source in case the primary source fails over might implement this by using one channel for each source and advertising both of them to receivers. SSM can be used to build multi-source applications where all participants' identities are not known in advance, but the multi-source "rendezvous" functionality does not occur in the network layer in this case. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library.
SSMは、アプリケーションが開始される前にアイデンティティが知られている1つ以上の送信者を備えた普及スタイルのアプリケーションに特に適しています。たとえば、プライマリソースが失敗した場合にセカンダリデータソースを提供したいデータ普及アプリケーションは、各ソースに1つのチャネルを使用し、両方のチャネルをレシーバーに宣伝することにより、これを実装できます。SSMは、すべての参加者のIDが事前に知られていないマルチソースアプリケーションを構築するために使用できますが、この場合、ネットワークレイヤーではマルチソースの「ランデブー」機能は発生しません。ユニキャストを基礎となるトランスポートとして使用するアプリケーションと同様に、この機能はアプリケーションまたはアプリケーション層ライブラリによって実装できます。
Multicast resource discovery of the form in which a client sends a multicast query directly to a "service location group" to which servers listen is not directly supported by SSM.
マルチキャストリソースは、クライアントがマルチキャストクエリを直接「サービスロケーショングループ」に直接送信し、サーバーがSSMによって直接サポートされていないフォームの発見です。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document defines the semantics of source-specific multicast addresses and specifies the policies governing their use. In particular, it defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines host extensions to support the network service. Hosts, routers, applications, and protocols that use these addresses MUST comply with the policies outlined in this document. Failure of a host to comply may prevent that host or other hosts on the same LAN from receiving traffic sent to an SSM channel. Failure of a router to comply may cause SSM traffic to be delivered to parts of the network where it is unwanted, unnecessarily burdening the network.
このドキュメントは、ソース固有のマルチキャストアドレスのセマンティクスを定義し、それらの使用を管理するポリシーを指定します。特に、SSMアドレスに送信されたデータグラムに適用されるインターネットネットワークサービスへの拡張機能を定義し、ネットワークサービスをサポートするホスト拡張機能を定義します。これらのアドレスを使用するホスト、ルーター、アプリケーション、およびプロトコルは、このドキュメントで概説されているポリシーに準拠する必要があります。ホストが遵守しなかった場合、同じLAN上のホストまたは他のホストがSSMチャネルに送信されるトラフィックを受信することを防ぐことができます。ルーターが遵守しなかった場合、SSMトラフィックがネットワークの一部に配信される可能性があり、そこで不要なネットワークの一部であり、ネットワークに不必要に負担をかけます。
The source-specific multicast service is defined as follows:
ソース固有のマルチキャストサービスは、次のように定義されています。
A datagram sent with source IP address S and destination IP address G in the SSM range is delivered to each host socket that has specifically requested delivery of datagrams sent by S to G, and only to those sockets.
SSM範囲のソースIPアドレスと宛先IPアドレスGで送信されたデータグラムは、Sから送信されたデータグラムの配信を特に要求した各ホストソケットに配信され、それらのソケットにのみ配信されます。
Where, using the terminology of [IGMPv3],
ここで、[Igmpv3]の用語を使用して、
"socket" is an implementation-specific parameter used to distinguish among different requesting entities (e.g., programs or processes or communication end-points within a program or process) within the requesting host; the socket parameter of BSD Unix system calls is a specific example.
「Socket」は、リクエストホスト内のさまざまな要求エンティティ（プログラムまたはプログラムまたはプロセス内のプログラムまたは通信エンドポイントなど）を区別するために使用される実装固有のパラメーターです。BSD UNIXシステム呼び出しのソケットパラメーターは、具体的な例です。
Any host may send a datagram to any SSM address, and delivery is provided according to the above semantics.
ホストは任意のSSMアドレスにデータグラムを送信する場合があり、上記のセマンティクスに従って配信が提供されます。
The IP module interface to upper-layer protocols is extended to allow a socket to "Subscribe" to or "Unsubscribe" from a particular channel identified by an SSM destination address and a source IP address. The extended interface is defined in Section 4.1. It is meaningless for an application or host to request reception of datagrams sent to an SSM destination address G, as is supported in the any-source multicast model, without also specifying a corresponding source address, and routers MUST ignore any such request.
上層層プロトコルへのIPモジュールインターフェイスは、SSM宛先アドレスとソースIPアドレスによって識別された特定のチャネルからソケットが「サブスクライブ」または「登録解除」できるように拡張されます。拡張インターフェイスは、セクション4.1で定義されています。アプリケーションまたはホストが、対応するソースアドレスも指定することなく、任意のソースマルチキャストモデルでサポートされているように、SSM宛先アドレスGに送信されたデータグラムの受信をリクエストすることは無意味であり、ルーターはそのような要求を無視する必要があります。
Multiple source applications on different hosts can use the same SSM destination address G without conflict because datagrams sent by each source host Si are delivered only to those sockets that requested delivery of datagrams sent to G specifically by Si.
さまざまなホストの複数のソースアプリケーションは、各ソースホストSIによって送信されたデータグラムがSIから送信されたデータグラムの配信を要求したソケットにのみ配信されるため、競合なしで同じSSM宛先アドレスGを使用できます。
The key distinguishing property of the model is that a channel is identified (addressed) by the combination of a unicast source address and a multicast destination address in the SSM range. So, for example, the channel
モデルの重要な際立ったプロパティは、ユニキャストソースアドレスとSSM範囲のマルチキャスト宛先アドレスの組み合わせによってチャネルが識別（アドレス指定）されることです。たとえば、チャンネル
S,G = (192.0.2.1, 232.7.8.9)
differs from
とは異なり
S,G = (192.0.2.2, 232.7.8.9),
even though they have the same destination address portion. Similarly, for IPv6,
同じ宛先アドレス部分を持っていても。同様に、IPv6の場合、
S,G = (2001:3618::1, FF33::1234)
and
と
S,G = (2001:3618::2, FF33::1234)
are different channels.
異なるチャネルです。
To reduce confusion when talking about the any-source and source-specific multicast models, we use different terminology when discussing them.
任意のソースとソース固有のマルチキャストモデルについて話すときに混乱を減らすために、それらについて議論する際に異なる用語を使用します。
We use the term "channel" to refer to the service associated with an SSM address. A channel is identified by the combination of an SSM destination address and a specific source, e.g., an (S,G) pair.
「チャネル」という用語を使用して、SSMアドレスに関連付けられたサービスを参照します。チャネルは、SSM宛先アドレスと特定のソース、例えば（s、g）ペアの組み合わせによって識別されます。
We use the term "host group" (used in RFC 1112) to refer to the service associated with "regular" ASM multicast addresses (excluding those in the SSM range). A host group is identified by a single multicast address.
「ホストグループ」（RFC 1112で使用）という用語を使用して、「通常の」ASMマルチキャストアドレス（SSM範囲の範囲を除く）に関連するサービスを参照します。ホストグループは、単一のマルチキャストアドレスによって識別されます。
Any host can send to a host group, and similarly, any host can send to an SSM destination address. A packet sent by a host S to an ASM destination address G is delivered to the host group identified by G. A packet sent by host S to an SSM destination address G is delivered to the channel identified by (S,G). The receiver operations allowed on a host group are called "join(G)" and "leave(G)" (as per RFC 1112). The receiver operations allowed on a channel are called "Subscribe(S,G)" and "Unsubscribe(S,G)".
ホストはホストグループに送信でき、同様に、ホストはSSM宛先アドレスに送信できます。ホストSからASM宛先アドレスGに送信されたパケットは、Gによって識別されたホストグループに配信されます。SSM宛先アドレスGにホストSから送信されたパケットは、（S、G）によって識別されたチャネルに配信されます。ホストグループで許可されている受信機操作は、「Join（g）」と「leave（g）」と呼ばれます（RFC 1112に従って）。チャネルで許可されるレシーバー操作は、「subscribe（s、g）」と「unsubscribe（s、g）」と呼ばれます。
The following table summarizes the terminology:
次の表は、用語をまとめたものです。
Service Model: any-source source-specific
Network Abstraction: group channel
Identifier: G S,G
Receiver Operations: Join, Leave Subscribe, Unsubscribe
We note that, although this document specifies a new service model available to applications, the protocols and techniques necessary to support the service model are largely a subset of those used to support ASM.
このドキュメントは、アプリケーションで利用可能な新しいサービスモデルを指定していますが、サービスモデルをサポートするために必要なプロトコルと手法は、主にASMをサポートするために使用されるサブセットのサブセットであることに注意してください。
This section describes requirements on hosts that support source-specific multicast, including:
このセクションでは、以下を含む、ソース固有のマルチキャストをサポートするホストの要件について説明します。
- Extensions to the IP Module Interface
- IPモジュールインターフェイスへの拡張
- Extensions to the IP Module
- IPモジュールへの拡張
- Allocation of SSM Addresses
- SSMアドレスの割り当て
The IP module interface to upper-layer protocols is extended to allow protocols to request reception of all datagrams sent to a particular channel.
上層層プロトコルへのIPモジュールインターフェイスは、プロトコルが特定のチャネルに送信されたすべてのデータグラムの受信を要求できるように拡張されています。
Subscribe ( socket, source-address, group-address, interface )
購読（ソケット、ソースアドレス、グループアドレス、インターフェイス）
Unsubscribe ( socket, source-address, group-address, interface )
登録解除（ソケット、ソースアドレス、グループアドレス、インターフェイス）
where
ただし
"socket" is as previously defined in Section 2,
「ソケット」は、セクション2で以前に定義されているとおりです。
and, paraphrasing [IGMPv3],
そして、言い換え[igmpv3]、
"interface" is a local identifier of the network interface on which reception of the channel identified by the (source-address,group-address) pair is to be enabled or disabled. A special value may be used to indicate a "default" interface. If reception of the same channel is desired on multiple interfaces, Subscribe is invoked once for each.
「インターフェイス」は、（ソースアドレス、グループアドレス）ペアによって識別されたチャネルの受信を有効または無効にするネットワークインターフェイスのローカル識別子です。特別な値を使用して、「デフォルト」インターフェイスを示すことができます。同じチャネルの受信が複数のインターフェイスで望まれる場合、サブスクライブはそれぞれに1回呼び出されます。
The above are strictly abstract functional interfaces -- the functionality can be provided in an implementation-specific way. On a host that supports the multicast source filtering application programming interface of [MSFAPI], for instance, the Subscribe and Unsubscribe interfaces may be supported via that API. When a host has been configured to know the SSM address range (whether the configuration mechanism is manual or through a protocol), the host's operating system SHOULD return an error to an application that makes a non-source-specific request to receive multicast sent to an SSM destination address.
上記は、厳密に抽象的な機能インターフェイスです。機能は、実装固有の方法で提供できます。たとえば、[MSFAPI]のマルチキャストソースフィルタリングアプリケーションプログラミングインターフェイスをサポートするホストでは、サブスクライブおよび登録解除インターフェイスがそのAPIを介してサポートされる場合があります。ホストがSSMアドレス範囲を知るように構成されている場合（構成メカニズムがマニュアルであるか、プロトコルを介して）、ホストのオペレーティングシステムは、に送信されるマルチキャストを受け取るための非ソース固有のリクエストを行うアプリケーションにエラーを返す必要がありますSSM宛先アドレス。
A host that does not support these IP module interfaces (e.g., ASM-only hosts) and their underlying protocols cannot expect to reliably receive traffic sent on an SSM channel. As specified below in Section 5.2, routers will not set up SSM forwarding state or forward datagrams in response to an ASM join request.
これらのIPモジュールインターフェイス（ASMのみのホストなど）をサポートしていないホストとその基礎となるプロトコルは、SSMチャネルで送信されたトラフィックを確実に受信することを期待できません。以下にセクション5.2で指定されているように、ルーターはASM参加要求に応じてSSM転送状態またはフォワードデータグラムを設定しません。
Widespread implementations of the IP packet reception interface (e.g., the recvfrom() system call in BSD Unix) do not allow a receiver to determine the destination address to which a datagram was sent. On a host with such an implementation, the destination address of a datagram cannot be inferred when the socket on which the datagram is received is Subscribed to multiple channels. Host operating systems SHOULD provide a way for a host to determine both the source and the destination address to which a datagram was sent. (As one example, the Linux operating system provides the destination of a packet as part of the response to the recvmsg() system call.) Until this capability is present, applications may be forced to use higher-layer mechanisms to identify the channel to which a datagram was sent.
IPパケット受信インターフェイスの広範な実装（たとえば、BSD UNIXでのRecvFROM（）システムコール）では、レシーバーがデータグラムの送信された宛先アドレスを決定することはできません。このような実装を持つホストでは、データグラムが受信されるソケットが複数のチャネルにサブスクライブされる場合、データグラムの宛先アドレスを推測することはできません。ホストオペレーティングシステムは、ホストがデータグラムが送信されたソースと宛先アドレスの両方を決定する方法を提供する必要があります。（1つの例として、Linuxオペレーティングシステムは、Recvmsg（）システムコールへの応答の一部としてパケットの宛先を提供します。）データグラムが送信されました。
An incoming datagram destined to an SSM address MUST be delivered by the IP module to all sockets that have indicated (via Subscribe) a desire to receive data that matches the datagram's source address, destination address, and arriving interface. It MUST NOT be delivered to other sockets.
SSMアドレスに運命づけられた着信データグラムは、IPモジュールによって（購読を介して）データグラムのソースアドレス、宛先アドレス、および到着インターフェイスに一致するデータを受信したいという要望を示したすべてのソケットに配信する必要があります。他のソケットに配信してはなりません。
When the first socket on host H subscribes to a channel (S,G) on interface I, the host IP module on H sends a request on interface I to indicate to neighboring routers that the host wishes to receive traffic sent by source S to source-specific multicast destination G. Similarly, when the last socket on a host unsubscribes from a channel on interface I, the host IP module sends an unsubscription request for that channel to interface I.
ホストHの最初のソケットがインターフェイスIでチャネル（s、g）にサブスクライブすると、HのホストIPモジュールはインターフェイスIにリクエストを送信して、ホストがソースSから送信したトラフィックをソースに送信したいという隣接ルーターに示すように送信します。 - 特異的なマルチキャスト宛先G。同様に、ホストの最後のソケットがインターフェイスIのチャネルからの登録解除の場合、ホストIPモジュールは、そのチャネルにunsubscriptionリクエストをインターフェイスIに送信します。
These requests will typically be Internet Group Management Protocol version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that supports the SSM service model MUST implement the host portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM].
これらの要求は、通常、IPv4のインターネットグループ管理プロトコルバージョン3（IGMPV3）メッセージ、またはIPv6 [IGMPV3、MLDV2]のマルチキャストリスナーディスカバリーバージョン2（MLDV2）メッセージです。SSMサービスモデルをサポートするホストは、IPv4の[Igmpv3]のホスト部分とIPv6に[MLDV2]のホスト部分を実装する必要があります。また、[GMP-SSM]で説明されているIGMPV3/MLDV2の挙動にも準拠する必要があります。
The SSM destination address 232.0.0.0 is reserved, and it must not be used as a destination address. Similarly, FF3x::4000:0000 is also reserved. The goal of reserving these two addresses is to preserve one invalid SSM destination for IPv4 and IPv6, which can be useful in an implementation as a null value. The address range 232.0.0.1 - 232.0.0.255 is currently reserved for allocation by IANA. SSM destination addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are similarly reserved for IANA allocation [IPv6-MALLOC]. The motivation to reserve these addresses is outlined below in Section 9, "IANA Considerations".
SSM宛先アドレス232.0.0.0は予約されており、宛先アドレスとして使用してはなりません。同様に、FF3X :: 4000：0000も予約されています。これらの2つのアドレスを予約するという目標は、IPv4とIPv6の1つの無効なSSM宛先を保持することです。これは、ヌル値として実装に役立つ可能性があります。アドレス範囲232.0.0.1-232.0.0.255は現在、IANAによる割り当てのために予約されています。SSM宛先アドレスは、FF3X :: 4000：0001からFF3X :: 7FFF：FFFFのIANA割り当て[IPv6-Malloc]のために同様に予約されています。これらの住所を予約する動機は、セクション9「IANAの考慮事項」で概説されています。
The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host.
残りのSSMアドレスをアプリケーションの送信に割り当てるためのポリシーは、送信ホストによって厳密に局所的に決定されます。
When allocating SSM addresses dynamically, a host or host operating system MUST NOT allocate sequentially starting at the first allowed address. It is RECOMMENDED to allocate SSM addresses to applications randomly, while ensuring that allocated addresses are not given simultaneously to multiple applications (and avoiding the reserved addresses). For IPv6, the randomization should apply to the lowest 31 bits of the address.
SSMアドレスを動的に割り当てる場合、ホストまたはホストのオペレーティングシステムは、最初の許可されたアドレスから順次開始を割り当ててはなりません。SSMアドレスをアプリケーションにランダムに割り当てることをお勧めしますが、割り当てられたアドレスが複数のアプリケーションに同時に与えられないことを確認することをお勧めします（予約アドレスを回避します）。IPv6の場合、ランダム化はアドレスの最低31ビットに適用する必要があります。
As described in Section 6, the mapping of an IP packet with SSM destination address onto a link-layer multicast address does not take into account the datagram's source IP address (on commonly-used link layers like Ethernet). If all hosts started at the first allowed address, then with high probability, many source-specific channels on shared-medium local area networks would use the same link-layer multicast address. As a result, traffic destined for one channel subscriber would be delivered to another's IP module, which would then have to discard the datagram.
セクション6で説明されているように、SSM宛先アドレスをリンク層マルチキャストアドレスに搭載したIPパケットのマッピングは、データグラムのソースIPアドレス（イーサネットのような一般的に使用されるリンクレイヤー）を考慮していません。すべてのホストが最初の許可されたアドレスで開始された場合、その後、高い確率で、共有メディウムローカルエリアネットワークの多くのソース固有のチャネルは、同じリンク層マルチキャストアドレスを使用します。その結果、1つのチャネルサブスクライバーに運命づけられたトラフィックが別のIPモジュールに配信され、データグラムを破棄する必要があります。
A host operating system SHOULD provide an interface to allow an application to request a unique allocation of a channel destination address in advance of a session's commencement, and this allocation database SHOULD persist across host reboots. By providing persistent allocations, a host application can advertise the session in advance of its start time on a web page or in another directory. (We note that this issue is not specific to SSM applications -- the same problem arises for ASM.)
ホストオペレーティングシステムは、セッションの開始前にアプリケーションがチャネル宛先アドレスの一意の割り当てをリクエストできるようにするためのインターフェイスを提供する必要があり、この割り当てデータベースはホストの再起動全体に持続する必要があります。永続的な割り当てを提供することにより、ホストアプリケーションは、Webページまたは別のディレクトリで開始時間の前にセッションを宣伝できます。（この問題はSSMアプリケーションに固有のものではないことに注意してください。ASMには同じ問題が発生します。）
This document neither defines the interfaces for requesting or returning addresses nor specifies the host algorithms for storing those allocations. One plausible abstract API is defined in RFC 2771 [RFC2771]. Note that RFC 2771 allows an application to request an address within a specific range of addresses. If this interface is used, the starting address of the range SHOULD be selected at random by the application.
このドキュメントは、アドレスを要求または返信するためのインターフェイスを定義したり、それらの割り当てを保存するホストアルゴリズムを指定したりしません。1つのもっともらしい抽象的なAPIは、RFC 2771 [RFC2771]で定義されています。RFC 2771では、アプリケーションが特定の範囲のアドレス内でアドレスを要求できることに注意してください。このインターフェイスを使用する場合、範囲の開始アドレスをアプリケーションによってランダムに選択する必要があります。
For IPv6, administratively scoped SSM channel addresses are created by choosing an appropriate scope identifier for the SSM destination address. Normal IPv6 multicast scope boundaries [SCOPINGv6] are applied to traffic sent to an SSM destination address, including any relevant boundaries applied to both the source and destination address.
IPv6の場合、SSM宛先アドレスに適切なスコープ識別子を選択することにより、管理上スコープSSMチャネルアドレスが作成されます。通常のIPv6マルチキャストスコープ境界[Scopingv6]は、ソースアドレスと宛先アドレスの両方に適用される関連境界を含む、SSM宛先アドレスに送信されるトラフィックに適用されます。
No globally agreed-upon administratively-scoped address range [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast. For IPv4, administrative scoping of SSM addresses can be implemented within an administrative domain by filtering outgoing SSM traffic sent to a scoped address at the domain's boundary routers.
現在、IPv4ソース固有のマルチキャストでは、世界的に合意された管理上スコープアドレス範囲[Admin-Scope]は現在定義されていません。IPv4の場合、SSMアドレスの管理スコーピングは、ドメインの境界ルーターのスコープアドレスに送信される発信SSMトラフィックをフィルタリングすることにより、管理ドメイン内に実装できます。
A router that receives an IP datagram with a source-specific destination address MUST silently drop it unless a neighboring host or router has communicated a desire to receive packets sent from the source and to the destination address of the received packet.
ソース固有の宛先アドレスを使用してIPデータグラムを受信するルーターは、隣接するホストまたはルーターが、ソースから送信されたパケットと受信パケットの宛先アドレスに送信されたパケットを受信したいという欲求を伝えない限り、静かにドロップする必要があります。
Certain IP multicast routing protocols already have the ability to communicate source-specific joins to neighboring routers (in particular, PIM-SM [PIM-SM]), and these protocols can, with slight modifications, be used to provide source-specific semantics. A router that supports the SSM service model MUST implement the PIM-SSM subset of the PIM-SM protocol from [PIM-SM] and MUST implement the router portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6. An SSM router MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM].
特定のIPマルチキャストルーティングプロトコルは、ソース固有の結合を隣接ルーター（特にPIM-SM [PIM-SM]）に通信する機能を既に備えており、これらのプロトコルは、わずかな変更でソース固有のセマンティクスを提供するために使用できます。SSMサービスモデルをサポートするルーターは、[PIM-SM]からPIM-SMプロトコルのPIM-SSMサブセットを実装し、IPv4および[MLDV2]の[Igmpv3]のルーター部分をIPv6に実装する必要があります。SSMルーターは、[GMP-SSM]で説明されているIGMPV3/MLDV2挙動にも準拠する必要があります。
With PIM-SSM, successful establishment of an (S,G) forwarding path from the source S to any receiver depends on hop-by-hop forwarding of the explicit join request from the receiver toward the source. The protocol(s) and algorithms that are used to select the forwarding path for this explicit join must provide a loop-free path. When using PIM-SSM, the PIM-SSM implementation MUST (at least) support the ability to use the unicast topology database for this purpose.
PIM-SSMを使用すると、ソースSからレシーバーへの（s、g）転送パスの確立を成功させることは、レシーバーからソースへの明示的な結合要求のホップバイホップ転送に依存します。この明示的な結合の転送パスを選択するために使用されるプロトコルとアルゴリズムは、ループフリーのパスを提供する必要があります。PIM-SSMを使用する場合、PIM-SSMの実装は、この目的のためにユニキャストトポロジデータベースを使用する機能を（少なくとも）サポートする必要があります。
A network can concurrently support SSM in the SSM address range and any-source multicast in the rest of the multicast address space, and it is expected that this will be commonplace. In such a network, a router may receive a non-source-specific, or "(*,G)" in conventional terminology, request for delivery of traffic in the SSM range from a neighbor that does not implement source-specific multicast in a manner compliant with this document. A router that receives such a non-source-specific request for data in the SSM range MUST NOT use the request to establish forwarding state and MUST NOT propagate the request to other neighboring routers. A router MAY log an error in such a case. This applies both to any request received from a host (e.g., an IGMPv1 or IGMPv2 [IGMPv2] host report) and to any request received from a routing protocol (e.g., a PIM-SM (*,G) join). The inter-router case is further discussed in Section 8, "Transition Considerations".
ネットワークは、SSMアドレスの範囲でSSMを同時にサポートでき、他のマルチキャストアドレス空間では任意のソースマルチキャストをサポートできます。これは当たり前になると予想されます。このようなネットワークでは、ルーターは従来の用語で非ソース固有の、または「（*、g）」を受け取る場合があります。このドキュメントに準拠した方法。SSM範囲のデータに対するこのような非ソース固有のリクエストを受信するルーターは、リクエストを使用して転送状態を確立する必要があり、他の隣接するルーターにリクエストを伝播してはなりません。ルーターは、そのような場合にエラーを記録する場合があります。これは、ホストから受け取った要求（例：IGMPV1またはIGMPV2 [IGMPV2]ホストレポート）と、ルーティングプロトコル（たとえば、PIM-SM（*、g）の結合）から受信したリクエストにも適用されます。ルーター間のケースについては、セクション8「遷移に関する考慮事項」でさらに説明します。
It is essential that all routers in the network give source-specific semantics to the same range of addresses in order to achieve the full benefit of SSM. To comply with this specification, a router MUST treat ALL IANA-allocated SSM addresses with source-specific semantics.
ネットワーク内のすべてのルーターが、SSMの完全な利益を達成するために、同じ範囲のアドレスにソース固有のセマンティクスを提供することが不可欠です。この仕様に準拠するために、ルーターはすべてのIANAに割り当てられたSSMアドレスをソース固有のセマンティクスで処理する必要があります。
Source-specific multicast packets are transmitted on link-layer networks as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. On most shared-medium link-layer networks that support multicast (e.g., Ethernet), the IP source address is not used in the selection of the link-layer destination address. Consequently, on such a network, all packets sent to destination address G will be delivered to any host that has subscribed to any channel (S,G), regardless of S. Therefore, the IP module MUST filter packets it receives from the link layer before delivering them to the socket layer.
ソース固有のマルチキャストパケットは、IPv4のRFC 1112およびIPv6の[Etherv6]のように、リンク層ネットワークで送信されます。マルチキャスト（イーサネットなど）をサポートするほとんどの共有中程度のリンク層ネットワークでは、IPソースアドレスは、リンク層宛先アドレスの選択には使用されません。その結果、このようなネットワークでは、宛先アドレスGに送信されるすべてのパケットが、Sに関係なくチャネル（s、g）にサブスクライブしたホストに配信されます。したがって、IPモジュールはリンクレイヤーから受信したパケットをフィルタリングする必要がありますソケットレイヤーに配信する前に。
This section outlines security issues pertaining to SSM. The following topics are addressed: IPsec, denial-of-service attacks, source spoofing, and security issues related to administrative scoping.
このセクションでは、SSMに関するセキュリティの問題の概要を説明します。以下のトピックについて説明します：IPSEC、サービス拒否攻撃、ソーススプーフィング、および管理スコーピングに関連するセキュリティの問題。
The IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) can be used to secure SSM traffic, if a multicast-capable implementation of IPsec (as required in [RFC4301]) is used by the receivers.
IPSEC認証ヘッダー（AH）およびカプセル化セキュリティペイロード（ESP）を使用して、IPSECのマルチキャスト対応実装（[RFC4301]で要求される）が受信者が使用する場合、SSMトラフィックを保護できます。
For existing implementations of RFC 2401 IPsec (now superseded by [RFC4301]), there are a few caveats related to SSM. They are listed here. In RFC 2401 IPsec, the source address is not used as part of the key in the SAD lookup. As a result, two senders that happen to use the same SSM destination address and the same Security Parameter Index (SPI) will "collide" in the SAD at any host that is receiving both channels. Because the channel addresses and SPIs are both allocated autonomously by the senders, there is no reasonable means to ensure that each sender uses a unique destination address or SPI.
RFC 2401 IPSECの既存の実装（現在は[RFC4301]に取って代わっている）の場合、SSMに関連するいくつかの注意事項があります。それらはここにリストされています。RFC 2401 IPSECでは、ソースアドレスはSADルックアップのキーの一部として使用されません。その結果、同じSSM宛先アドレスと同じセキュリティパラメーターインデックス（SPI）を使用する2人の送信者が、両方のチャネルを受信しているホストでSADで「衝突」します。チャネルアドレスとスピスはどちらも送信者によって自律的に割り当てられているため、各送信者が一意の宛先アドレスまたはSPIを使用することを保証する合理的な手段はありません。
A problem arises if a receiver subscribes simultaneously to two unrelated channels using IPsec whose sources happen to be using the same IP destination address (IPDA) and the same IPsec SPI. Because the channel destination addresses are allocated autonomously by the senders, any two hosts can simultaneously use the same destination address, and there is no reasonable means to ensure that this does not happen. The <IPDA,SPI> tuple, however, consists of 56 bits that are generally randomly chosen (24 bits of the IP destination and 32 bits of the SPI), and a conflict is unlikely to occur through random chance.
ソースがたまたま同じIP宛先アドレス（IPDA）と同じIPSEC SPIを使用しているIPSECを使用して、レシーバーが2つの無関係なチャネルに同時に購読する場合、問題が発生します。チャネル宛先アドレスは送信者によって自律的に割り当てられているため、2人のホストは同じ宛先アドレスを同時に使用でき、これが発生しないことを確認する合理的な手段はありません。ただし、<ipda、spi>タプルは、一般にランダムに選択された56ビット（IP宛先の24ビットとSPIの32ビット）で構成されており、競合がランダムなチャンスによって発生する可能性は低いです。
If such a collision occurs, a receiver will not be able to simultaneously receive IPsec-protected traffic from the two colliding sources. A receiver can detect this condition by noticing that it is receiving traffic from two different sources with the same SPI and the same SSM destination address.
そのような衝突が発生した場合、受信者は2つの衝突源からIPSECで保護されたトラフィックを同時に受信できません。レシーバーは、同じSPIと同じSSM宛先アドレスを持つ2つの異なるソースからトラフィックを受け取っていることに気付くことにより、この状態を検出できます。
A subscription request creates (S,G) state in a router to record the subscription, invokes processing on that router, and possibly causes processing at neighboring routers. A host can mount a denial-of-service attack by requesting a large number of subscriptions. Denial of service can result if:
サブスクリプション要求は、ルーターに（s、g）状態を作成してサブスクリプションを記録し、そのルーターで処理を呼び出し、隣接するルーターで処理を引き起こす可能性があります。ホストは、多数のサブスクリプションを要求することにより、サービス拒否攻撃を実施できます。サービスの拒否は、次の場合に生じる可能性があります。
- a large amount of traffic arrives when it was otherwise undesired, consuming network resources to deliver it and host resources to drop it;
- それ以外の場合は望ましくなく、ネットワークリソースを消費するためにそれを提供し、それをドロップするリソースをホストするためにネットワークリソースを消費するときに、大量のトラフィックが到着します。
- a large amount of source-specific multicast state is created in network routers, using router memory and CPU resources to store and process the state; or
- ルーターメモリとCPUリソースを使用して状態を保存および処理するために、大量のソース固有のマルチキャスト状態がネットワークルーターに作成されます。また
- a large amount of control traffic is generated to manage the source-specific state, using router CPU and network bandwidth.
- ルーターCPUとネットワーク帯域幅を使用して、ソース固有の状態を管理するために、大量の制御トラフィックが生成されます。
To reduce the damage from such an attack, a router MAY have configuration options to limit, for example, the following items:
このような攻撃による損傷を減らすために、ルーターには、次の項目を制限する構成オプションがある場合があります。
- The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks).
- 任意の1つのインターフェイスのすべてのホストがサブスクリプションを開始することが許可されている合計率（偽造されたソースアドレス攻撃による損傷を制限するため）。
- The total number of subscriptions that can be initiated from any single interface or host.
- 単一のインターフェイスまたはホストから開始できるサブスクリプションの総数。
Any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, however, as future applications may use large numbers of channels. Tight limits on the rate or number of channel subscriptions would inhibit the deployment of such applications.
ただし、将来のアプリケーションが多数のチャネルを使用する可能性があるため、実装者がサブスクリプションのレートまたは数を制限する決定は慎重に取得する必要があります。チャネルサブスクリプションのレートまたは数の厳しい制限は、そのようなアプリケーションの展開を阻害します。
A router SHOULD verify that the source of a subscription request is a valid address for the interface on which it was received. Failure to do so would exacerbate a spoofed-source address attack.
ルーターは、サブスクリプション要求のソースが受信したインターフェイスの有効なアドレスであることを確認する必要があります。そうしないと、スプーフィングされたソースアドレス攻撃が悪化します。
We note that these attacks are not unique to SSM -- they are also present for any-source multicast.
これらの攻撃はSSMに固有のものではないことに注意してください。また、任意のソースマルチキャストにも存在します。
By forging the source address in a datagram, an attacker can potentially violate the SSM service model by transmitting datagrams on a channel belonging to another host. Thus, an application requiring strong authentication should not assume that all packets that arrive on a channel were sent by the requested source without higher-layer authentication mechanisms. The IPSEC Authentication Header [RFC2401, RFC4301] may be used to authenticate the source of an SSM transmission, for instance.
データグラムにソースアドレスを偽造することにより、攻撃者は、別のホストに属するチャネルでデータグラムを送信することにより、SSMサービスモデルに違反する可能性があります。したがって、強力な認証を必要とするアプリケーションは、チャネルに到着したすべてのパケットが、より高い層認証メカニズムなしで要求されたソースによって送信されたと仮定するべきではありません。IPSEC認証ヘッダー[RFC2401、RFC4301]を使用して、たとえばSSM送信のソースを認証することができます。
Some degree of protection against spoofed source addresses in multicast is already fairly widespread, because the commonly deployed IP multicast routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path forwarding check" that validates that a multicast packet arrived on the expected interface for its source address. Routing protocols used for SSM SHOULD incorporate such a check.
マルチキャストのスプーフィングされたソースアドレスに対するある程度の保護は、一般的に展開されているIPマルチキャストルーティングプロトコル[PIM-DM、PIM-SM、DVMRP]には「リバースパス転送チェック」が組み込まれているため、マルチキャストパケットが到着したことを検証する「リバースパス転送チェック」が組み込まれているためソースアドレスの予想されるインターフェイス。SSMに使用されるルーティングプロトコルには、そのようなチェックが組み込まれる必要があります。
Source Routing [RFC791] (both Loose and Strict) in combination with source address spoofing may be used to allow an impostor of the true channel source to inject packets onto an SSM channel. An SSM router SHOULD by default disallow source routing to an SSM destination address. A router MAY have a configuration option to allow source routing. Anti-source spoofing mechanisms, such as source address filtering at the edges of the network, are also strongly encouraged.
ソースルーティング[RFC791]（ゆるいと厳格の両方）とソースアドレスのスプーフィングと組み合わせて、真のチャネルソースの詐欺師がSSMチャネルにパケットを注入できるようにすることができます。SSMルーターは、デフォルトでSSM宛先アドレスへのソースルーティングを許可する必要があります。ルーターには、ソースルーティングを許可する構成オプションがある場合があります。ネットワークのエッジでのソースアドレスフィルタリングなど、アンチソースのスプーフィングメカニズムも強く奨励されています。
Administrative scoping should not be relied upon as a security measure [ADMIN-SCOPE]; however, in some cases it is part of a security solution. It should be noted that no administrative scoping exists for IPv4 source-specific multicast. An alternative approach is to manually configure traffic filters to create such scoping if necessary.
管理スコーピングは、セキュリティ尺度[Admin-Scope]として依存するべきではありません。ただし、場合によっては、セキュリティソリューションの一部です。IPv4ソース固有のマルチキャストには、管理スコーピングが存在しないことに注意する必要があります。別のアプローチは、必要に応じてそのようなスコーピングを作成するためにトラフィックフィルターを手動で構成することです。
Furthermore, for IPv6, neither source nor destination address scoping should be used as a security measure. In some currently-deployed IPv6 routers (those that do not conform to [SCOPINGv6]), scope boundaries are not always applied to all source address (for instance, an implementation may filter link-local addresses but nothing else). Such a router may incorrectly forward an SSM channel (S,G) through a scope boundary for S.
さらに、IPv6の場合、ソースも宛先アドレスのスコーピングもセキュリティメジャーとして使用する必要はありません。現在展開されている一部のIPv6ルーター（[Scopingv6]に準拠していないもの）では、スコープ境界が常にすべてのソースアドレスに適用されるわけではありません（たとえば、実装はリンクローカルアドレスをフィルタリングする場合がありますが、他には何もありません）。このようなルーターは、Sのスコープ境界を介してSSMチャネル（S、G）を誤って転送する可能性があります。
A host that complies with this document will send ONLY source-specific host reports for addresses in the SSM range. As stated above, a router that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1 [RFC2710]) host report for a source-specific multicast destination address MUST ignore these reports. Failure to do so would violate the SSM service model promised to the sender: that a packet sent to (S,G) would only be delivered to hosts that specifically requested delivery of packets sent to G by S.
このドキュメントに準拠したホストは、SSM範囲のアドレスに対してソース固有のホストレポートのみを送信します。上記のように、ソース固有の非ソース固有のルーター（例：IGMPV1またはMLDV1 [RFC2710]）を受け取るルーターは、ソース固有のマルチキャスト宛先アドレスのホストレポートを無視する必要があります。そうしないと、送信者に約束されたSSMサービスモデルに違反します。
During a transition period, it would be possible to deliver SSM datagrams in a domain where the routers do not support SSM semantics by simply forwarding any packet destined to G to all hosts that have requested subscription of (S,G) for any S. However, this implementation risks unduly burdening the network infrastructure by delivering (S,G) datagrams to hosts that did not request them. Such an implementation for addresses in the SSM range is specifically not compliant with Section 5.2 of this document.
遷移期間中、ルーターがSSMセマンティクスをサポートしないドメインでSSMデータグラムを配信することが可能です。、この実装は、リクエストしなかったホストに（s、g）データグラムを配信することにより、ネットワークインフラストラクチャに過度に負担するリスクがあります。SSM範囲のアドレスのこのような実装は、このドキュメントのセクション5.2に特に準拠していません。
IANA allocates IPv4 addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to FF3x::7FFF:FFFF. These addresses are allocated according to IETF Consensus [IANA-CONSID]. These address ranges are reserved for services with wide applicability that either require that or would strongly benefit if all hosts use a well-known SSM destination address for that service. Any proposal for allocation must consider the fact that, on an Ethernet network, all datagrams sent to any SSM destination address will be transmitted with the same link-layer destination address, regardless of the source. Furthermore, the fact that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer addresses as the reserved IP multicast group range 224.0.0.0/24 must also be considered. Similar consideration should be given to the IPv6 reserved multicast addresses. 232.0.0.0 and FF3x::4000:0000 should not be allocated, as suggested above.
IANAは、範囲232.0.0.1から232.0.0.255のIPv4アドレスを割り当て、FF3X：4000：0001からFF3X :: 7FFF：FFFFの範囲でIPv6アドレスを割り当てます。これらのアドレスは、IETFコンセンサス[IANA-Consid]に従って割り当てられます。これらのアドレス範囲は、すべてのホストがそのサービスによく知られているSSM宛先アドレスを使用する場合、それを必要とするか、強く利益を得る幅広い適用性を備えたサービスのために予約されています。割り当ての提案は、イーサネットネットワークで、SSM宛先アドレスに送信されるすべてのデータグラムが、ソースに関係なく、同じリンク層宛先アドレスで送信されるという事実を考慮する必要があります。さらに、232.0.0.0/24および232.128.0.0/24のSSM宛先が、予約されたIPマルチキャストグループ範囲224.0.0.0/24と同じリンク層アドレスを使用しているという事実も考慮する必要があります。IPv6予約済みのマルチキャストアドレスについても同様の考慮事項を考慮する必要があります。232.0.0.0およびFF3X :: 4000：0000は、上記のように割り当てられないでください。
Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM destination address to a particular entity or application. To do so would compromise one of the important benefits of the source-specific model: the ability for a host to simply and autonomously allocate a source-specific multicast address from a large flat address space.
前述のアドレスを除き、IANAはSSM宛先アドレスを特定のエンティティまたはアプリケーションに割り当ててはなりません。そうすることは、ソース固有のモデルの重要な利点の1つを妥協します。ホストが大規模なフラットアドレススペースからソース固有のマルチキャストアドレスを簡単かつ自律的に割り当てる能力です。
The SSM service model draws on a variety of prior work on alternative approaches to IP multicast, including the EXPRESS multicast model of Holbrook and Cheriton [EXPRESS], Green's [SMRP], and the Simple Multicast proposal of Perlman, et al. [SIMPLE]. We would also like to thank Jon Postel and David Cheriton for their support in reassigning the 232/8 address range to SSM. Brian Haberman contributed to the IPv6 portion of this document. Thanks to Pekka Savola for a careful review.
SSMサービスモデルは、HolbrookとCheriton [Express]、Greenの[SMRP]、Perlman et al。[単純]。また、232/8のアドレス範囲をSSMに再割り当てすることをサポートしてくれたJon PostelとDavid Cheritonにも感謝します。ブライアンハーバーマンは、このドキュメントのIPv6部分に貢献しました。慎重にレビューしてくれたPekka Savolaに感謝します。
[ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Etherv6] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[GMP-SSM] Holbrook, H. and B. Cain, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[GMP-SSM] Holbrook、H。およびB. Cain、「インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリープロトコルバージョン2（MLDV2）を使用して、ソース固有のマルチキャストのためのRFC 4604、2006年8月。
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[Igmpv3] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[IPv6-UBM] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[IPv6-UBM] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。
[IPv6-MALLOC] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[IPv6-Malloc] Haberman、B。、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、2002年8月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDV2] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas。「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Admin-Scope] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[DVMRP] Waitzman、D.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source-Specific Multicast: EXPRESS support for Large-scale Single-source Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 1999.
[Express] Holbrook、H。、およびCheriton、D。ACM Sigcomm '99の議事録、マサチューセッツ州ケンブリッジ、1999年9月。
[IANA-ALLOC] Internet Assigned Numbers Authority, http://www.iana.org/assignments/multicast-addresses.
[IANA-Alloc]インターネットは、http://www.iana.org/assignments/multicast-addressesを割り当てました。
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-Consid] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Igmpv2] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[MSFAPI] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルターのソケットインターフェイス拡張機能」、RFC 3678、2004年1月。
[PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[PIM-DM] Adams、A.、Nicholas、J.、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM-DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[RFC2771] Finlayson、R。、「マルチキャストアドレス割り当ての抽象的なAPI」、RFC 2771、2000年2月。
[SCOPINGv6] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[Scopingv6] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6スコープアドレスアーキテクチャ」、RFC 4007、2005年3月。
[SIMPLE] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, and M. Green, "Simple Multicast: A Design for Simple, Low-Overhead Multicast", Work in Progress, October 1999.
[シンプル] R.パールマン、C-Y。Lee、A。Ballardie、J。Crowcroft、Z。Wang、T。Maufer、C。Diot、およびM. Green、「シンプルなマルチキャスト：シンプルでローオーバーヘッドマルチキャストのデザイン」、1999年10月の作業。
[SMRP] Green, M. "Method and System of Multicast Routing for Groups with a Single Transmitter." United States Patent Number 5,517,494.
[SMRP] Green、M。「単一の送信機を持つグループのマルチキャストルーティングの方法とシステム。」米国特許番号5,517,494。
Authors' Addresses
著者のアドレス
Brad Cain Acopia Networks
Brad Cain Acopia Networks
EMail: bcain99@gmail.com
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
Hugh Holbrook Arastra、Inc。P.O.Box 10905 Palo Alto、CA 94303
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。