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
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).
著作権（C）インターネット協会（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は、Gが、GのRFC 1112アドレスに送信されたデータグラムの受信を要求した各「上位層プロトコル・モジュール」に配信される（239.255.255.255スルー224.0.0.0）IPマルチキャストアドレスに送信されたデータグラムは、ネットワークサービスを呼び出すように指定しますマルチキャスト宛先アドレスG「ホストグループ」によって識別されます。このモデルは、両方の1対多および多対多のグループ通信をサポートしています。この文書は、RFC 1112 RFC 3513 [RFC3513]で定義されたマルチキャストのモデルを参照するために用語「どれ-ソースマルチキャスト」（ASM）を使用して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.255.255.255に232.0.0.0）で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「X」[たIPv6-UBM]により、任意の有効なスコープ識別子であるソース固有マルチキャストの使用のために予約されています。 [IPv6の-UBM]の用語を使用して、すべてのSSMアドレスは、P = 1、T = 1、及びPLEN = 0を有していなければなりません。 SSMアドレスのネットワークプレフィックスフィールドがゼロに設定され、[IPv6にMALLOC]義務、したがって、すべてのSSMアドレスが:: / 96の範囲FF3xに入ります。たとえば、新しいIPアドレスとMACアドレスのマッピングが定義されている、場合には、将来の文書が非ゼロのネットワークプレフィックスフィールドを可能にすることができます。これにより、アドレス割り当てが:: / 96の範囲FF3x内で発生したが、システムは、ネットワークプレフィックスフィールドの可能な将来の用途との互換性を可能にするために、SSMアドレスとしてFF3xの全て:: / 32を治療すべきです。
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 :: 7FFFスルー0001：範囲FF3x :: 4000のアドレスはIANAによって割り当てのため〔のIPv6-MALLOC]に予約されFFFF。 FF3x :: FFFFを介し0000：範囲FF3x :: 8000のアドレスは[IPv6にMALLOC]に記載されているように、ホストが動的割り当てのために許可されFFFF。 FF3x :: 3FFFを通じて0000：範囲FF3x :: 0000のアドレスは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をアドレスに送信されたデータグラムの受信を要求した各上層「ソケット」に送達されます。 （S、G）によって識別されるネットワーク・サービスは、SSMアドレスGとソースホストアドレスSは、「チャネル」と呼ばれます。 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.
トラフィックのクロス送達の除去二つのソースが同時に同じソース固有の宛先アドレスを使用します。複数のソースと異なるアプリケーションによって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のランデブーポイント - スパースモード（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は、すべての参加者の身元が事前に知られていないマルチソース・アプリケーションを構築するために使用することができますが、マルチソース 『ランデブー』機能は、この場合のネットワーク層では発生しません。ただ、基礎となるトランスポートとしてユニキャストを使用するアプリケーションのように、この機能は、アプリケーションまたはアプリケーション層のライブラリで実現することができます。
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アドレスに送信されたデータグラムに適用され、ネットワークサービスをサポートするために、ホストの拡張を定義するインターネットネットワークサービスへの拡張を定義します。ホスト、ルータ、アプリケーション、およびこれらのアドレスを使用するプロトコルは、このドキュメントで概説された方針を遵守しなければなりません。準拠するホストの障害がSSMチャネルに送信されたトラフィックを受信し、同じLAN上のホストまたは他のホストを防止することができます。遵守するためのルータの失敗は、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アドレスSと宛先IPアドレスGで送信されたデータグラムは、具体的にのみそれらのソケットに、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.
「ソケット」が要求しているホスト内（プログラムまたはプロセス内、例えば、プログラムまたはプロセスまたは通信エンドポイント）は、異なる要求エンティティを区別するために使用する実装固有のパラメータです。 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によって特異的Gに送信されたデータグラムの配信を要求し、それらのソケットにのみ配信されるため、異なるホスト上の複数のソースアプリケーションが競合することなく同じ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)
S、G =（192.0.2.1、232.7.8.9）
differs from
とは異なり
S,G = (192.0.2.2, 232.7.8.9),
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)
S、G =（2001：3618 :: 1、FF33 :: 1234）
and
そして
S,G = (2001:3618::2, FF33::1234)
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.
我々は（SSM範囲のものを除く。）「通常の」ASMマルチキャストアドレスに関連するサービスを参照するために（RFC 1112で使用される）用語「ホストグループ」を使用します。ホストグループは、単一のマルチキャストアドレスによって識別されます。
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宛先アドレスに送信することができます。 ASM宛先アドレスGにホストSによって送信されたパケットは、SSM宛先アドレスGにホストSによって送信されたパケットは（S、G）によって識別されたチャネルに配信さG.によって識別されるホストグループに配信されます。ホストグループ上許容受信操作が（RFC 1112による）「参加（G）」と「残す（G）」と呼ばれます。チャネル上で許可受信動作が「購読（Sを、G）」、および「脱退（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
サービスモデル：任意のソースのソース固有のネットワーク抽象化：グループチャンネル識別子：G S、Gレシーバー操作：購読まま、参加、脱退
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.
「インターフェース」とは、（送信元アドレス、グループ・アドレス）のペアによって識別されたチャネルの受信を有効または無効にされているネットワークインタフェースのローカル識別子です。特別な値は、「デフォルト」のインターフェイスを示すために使用することができます。同じチャンネルの受信が複数のインターフェイス上で望まれる場合、購読はごとに一度呼び出されます。
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（）システム・コール）は、受信機がデータグラムが送信された先のアドレスを決定することができません。データグラムが受信されたソケットが複数のチャネルにサブスクライブされたときに、そのような実装のホスト上で、データグラムの宛先アドレスは推測できません。送信元および宛先アドレスの両方がそのデータグラムが送信されたかを決定するホストのための方法を提供すべきであるオペレーティング・システムをホストします。 （一例として、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上の第1のソケットインターフェイスIのチャネル（S、G）に加入したとき、H上のホストIPモジュールは、私は、ホストがソースに、ソースSによって送信されたトラフィックを受信したい隣接ルータに指示するインターフェースに要求を送信しますインターフェイスIのチャネルからホスト登録解除の最後のソケットは、ホストIPモジュールが送信するときに特異的マルチキャスト宛先G.同様に、そのチャネルの脱退要求が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サービスモデルをサポートするホストは、IPv6のための【のMLDv2] IPv4の【のIGMPv3]のホスト部分を実装しなければなりません。また、[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によって割り当てのために予約されています。 FF3x :: 7FFFスルー0001：範囲FF3x :: 4000におけるSSM宛先アドレスは、同様IANA配分[IPv6にMALLOC]のために予約されていFFFF。これらのアドレスを予約する動機は、「IANAの考慮事項」、第9節で以下に概説します。
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.
この文書では、どちらのアドレスを要求する、または戻すためのインタフェースを定義することも、それらの割り当てを格納するためのホスト・アルゴリズムを指定します。一つの妥当な抽象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.
いいえグローバル合意管理スコープのアドレス範囲[ADMIN-SCOPE]は、現在のIPv4ソース固有マルチキャストのために定義されています。 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]）ソース固有の隣接ルータへ参加を通信する能力を有しており、これらのプロトコルは、わずかな変更を加えて、ソース固有のセマンティクスを提供するために使用することができます。 IPv6の【のMLDv2] [PIM-SM]からPIM-SMプロトコルのPIM-SSMのサブセットを実装しなければならないSSMサービスモデルをサポートし、IPv4の【のIGMPv3]のルータ部を実装しなければならないとルータ。 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範囲内のトラフィックの配信要求この文書に準拠した方法。 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のおよびIPv6の[ETHERv6]のようにRFC 1112で指定されたソース固有マルチキャストパケットは、リンク層ネットワーク上で送信されます。マルチキャストをサポートするほとんどの共有媒体リンク層ネットワーク上に（例えば、イーサネット（登録商標））、IPソースアドレスは、リンク層の宛先アドレスの選択に使用されていません。したがって、そのようなネットワーク上で、宛先アドレスGに送信されたすべてのパケットは、したがって、IPモジュールは、それがリンク層から受信するパケットをフィルタリングしなければならないにかかわらず、Sのいずれかのチャネル（S、G）に加入している任意のホストに配信されますソケット層に配信する前に。
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のマルチキャスト可能な実装は（[RFC4301]で必要に応じて）受信機で使用される場合のIPsec認証ヘッダ（AH）とカプセル化セキュリティペイロード（ESP）は、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.
（現在は[RFC4301]に取って代わら）RFC 2401のIPsecの既存の実装では、SSMに関連するいくつかの注意点があります。彼らはここにリストされています。 RFC 2401のIPsecでは、送信元アドレスは、SADのルックアップでキーの一部として使用されていません。結果として、同じSSM宛先アドレスと同じセキュリティパラメータインデックス（SPI）を使用する起こる2つの送信者は、両方のチャネルを受信しているすべてのホストにSADの「衝突」であろう。チャネル・アドレスとのSPIは、両方の送信者によって自律的に割り当てられるため、各送信者はユニークな宛先アドレスまたは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).
- いずれかのインターフェイス上のすべてのホストは、（偽造ソースアドレス攻撃によるダメージを制限する）サブスクリプションを開始するために許可される合計レート。
- 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またはIGMPv2のまたはのMLDv1 [RFC2710]）ホストレポートを受信するルータは、これらのレポートを無視しなければなりません。そうしないと、送信者に約束したSSMサービスモデルに違反する：（S、G）に送信されたパケットのみが特にSでGに送信されたパケットの配信を要求したホストに配信されること
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.
移行期間中は、どのS.のためのルータが単に（S、G）のサブスクリプションを要求したすべてのホストにG宛てのすべてのパケットを転送することにより、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.255までの範囲の232.0.0.1でIPv4アドレスを割り当て、IPv6は範囲FF3xに対処します。4000：FF3xに0001 :: 7FFF：FFFF。これらのアドレスは、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宛先アドレスを割り当てないものとします。簡単かつ自律的に大型フラットアドレス空間からソース固有のマルチキャストアドレスを割り当てるホストの能力：そうするためには、ソース固有のモデルの重要な利点の一つを危うくします。
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サービスモデルは、ホルブルックとCheriton [EXPRESS]、グリーン[SMRP]の明示マルチキャストモデル、およびパールマンのシンプルなマルチキャスト提案らを含むIPマルチキャストの代替的なアプローチ、上の前の仕事のさまざまな描画します。 [SIMPLE]。また、SSMに232/8のアドレス範囲を再割り当てで彼らのサポートのためにジョン・ポステルとデビッド・チェリトンに感謝したいと思います。ブライアンハーバーマンは、この文書のIPv6の部分に貢献しました。慎重に検討のためのペッカSavolaに感謝します。
[ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[ETHERv6]クロフォード、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]ホルブルック、H.、およびB.カイン、 "ソース固有マルチキャストのためにインターネットグループ管理プロトコルバージョン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の]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。
[IPv6-MALLOC] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[IPv6の-MALLOC]ハーバーマン、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]ヴィーダ、R.とL.コスタ、 "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]フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI. Kouvelas。 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[ADMIN-SCOPE]マイヤー、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.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、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]ホルブルック、H.、およびCheriton、D.は「：大規模なシングルソース・アプリケーションのための明示のサポートを明示的にソース固有のマルチキャストを要求しました。」 ACMのSIGCOMM '99の議事録、ケンブリッジ、MA、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の]フェナー、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]ターラー、D.、フェナー、B.、およびB.クイン、 "マルチキャストソースフィルタのためのソケットインタフェース拡張"、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]アダムス、A.、ニコラス、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[RFC2771]フィンレイソン、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]デアリング、S.、ハーバーマン、B.、神明、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.
[SIMPLE] R.パールマン、C-Y。リー、A. Ballardie、J.クロウクロフト、Z.王、T. Maufer、C. Diot、およびM.グリーン、 "シンプル・マルチキャスト：シンプル、低オーバーヘッドのマルチキャストのためのデザイン"、進歩、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】グリーン、M.米国特許番号5517494。
Authors' Addresses
著者のアドレス
Brad Cain Acopia Networks
ブラッドカインAcopia Networksの
EMail: bcain99@gmail.com
メールアドレス：bcain99@gmail.com
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
ヒュー・ホルブルックArastra、株式会社私書箱ボックス10905パロアルト、CA 94303
Phone: +1 650 331-1620 EMail: holbrook@arastra.com
電話：+1 650 331-1620 Eメール：holbrook@arastra.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。