RFC4607 日本語訳
4607 Source-Specific Multicast for IP. H. Holbrook, B. Cain. August 2006. (Format: TXT=42990 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Holbrook
Request for Comments: 4607 Arastra, Inc.
Category: Standards Track B. Cain
Acopia Networks
August 2006
コメントを求めるワーキンググループH.ホルブルック要求をネットワークでつないでください: 4607年のArastra Inc.カテゴリ: 規格は2006年8月にB.カインAcopiaネットワークを追跡します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
IPバージョン4(IPv4)が232/8で扱う、(232.0 .0 232.255.255.255)範囲への.0は、ソース特有のマルチキャスト(SSM)送付先アドレスとして指定されて、使用のためにソースの特定のアプリケーションとプロトコルによって予約されます。 IPバージョン6(IPv6)、アドレス接頭語FF3xのために:、:/32はソース特有のマルチキャスト使用のために予約されます。 このドキュメントは、SSMアドレスに送られたデータグラムに申請されるインターネットネットワーク・サービスと拡大を定義して、ホストとこの拡大をサポートするというルータ要件を定義します。
Holbrook & Cain Standards Track [Page 1] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[1ページ]RFC4607
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
1. 序論…3 2. ソース特有のマルチキャストアドレスの意味論…5 3. 用語…6 4. 要件を接待してください…7 4.1. IPモジュールへの拡大は連結します…7 4.2. ホストIPモジュールに関する要件…8 4.3. ソース特有のマルチキャストアドレスの配分…9 5. ルータ要件…10 5.1. パケット推進…10 5.2. プロトコル…10 6. データグラムのリンクレイヤ送信…11 7. セキュリティ問題…12 7.1. IPsecとSSM…12 7.2. SSMとRFC2401IPsec警告…12 7.3. サービス妨害…13 7.4. ソースアドレスであると偽造されます…13 7.5. 管理見ること…14 8. 変遷問題…14 9. IANA問題…15 10. 承認…15 11. 標準の参照…16 12. 有益な参照…17
Holbrook & Cain Standards Track [Page 2] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[2ページ]RFC4607
1. Introduction
1. 序論
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)マルチキャストサービスモデルはRFC1112[RFC1112]で定義されます。 RFC1112が、データグラムがIPマルチキャストアドレスに発信したと指定する、(224.0、.0、.0、通じて、239.255 .255 .255) Gはデータグラムのレセプションがネットワーク・サービスがマルチキャスト送付先アドレスGで特定したG. RFC1112呼び出しに「ホストグループ」を扱うために発信したよう要求した各「上側の層のプロトコルモジュール」に提供されます。 このモデルは多くへの1と多くへの多くグループコミュニケーションの両方をサポートします。 このドキュメントが用語を使用する、「いくらか、-、ソース、」 RFC1112で定義されたマルチキャストのモデルについて言及するマルチキャスト(ASM) 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].
IPv4が232/8で扱う、(232.0 .0 232.255.255.255)範囲への.0は、現在、ソース特有のマルチキャスト(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がなければなりません。 [IPv6-MALLOC]は、また、SSMアドレスのネットワーク接頭語分野がしたがって、ゼロ、FF3xのすべてのSSMアドレス秋に以下を設定することであることを強制します:/96は及びます。 例えば、新しいIPのアドレスからMACアドレス・マッピングが定義されるなら、将来のドキュメントは非ゼロネットワーク接頭語分野を許容するかもしれません。 したがって、アドレス配分は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は配分のために[IPv6-MALLOC]でIANAによって予約されます。 範囲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
ソース特有のマルチキャスト配送意味論をSSMアドレスに送られたデータグラムに提供します。 すなわち、ソースIPアドレスSとSSM送付先アドレスGがあるデータグラムはデータグラムのレセプションがソースSでGを扱うために発信したよう明確に要求したそれぞれの上側の層の「ソケット」と、そして、それらのソケットだけに提供されます。 (S、G)によってSSMアドレスGとソースに特定されたネットワーク・サービス
Holbrook & Cain Standards Track [Page 3] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[3ページ]RFC4607
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.
「チャンネル」と呼ばれた状態でアドレスSをホスティングしてください。 RFC1112の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の「共有された木」とRendezvous Points--まばらなMode(PIM-SM)プロトコル[PIM-SM]は、ソース特有のモデルをサポートするのに必要ではありません。 事実上、SSMをサポートしなければならなかったルータメカニズムは主にASMをサポートするのに使用されるものの部分集合です。 例えば、意味論をSSMに供給するためにPIM-SMプロトコルの最短パス木のメカニズムを適合させることができます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Holbrook & Cain Standards Track [Page 4] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[4ページ]RFC4607
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トラフィックがそれが求められていないネットワークの部分に提供されることを引き起こすかもしれません、不必要にネットワークを負って。
2. Semantics of Source-Specific Multicast Addresses
2. ソース特有のマルチキャストアドレスの意味論
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.
ソースIPアドレスSと送付先IPアドレスGと共にSSM範囲で送られたデータグラムはSからGでデータグラムの明確に要求された配送を送るそれぞれのホストソケットと、そして、それらのソケットだけに提供されます。
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を使用できます。
Holbrook & Cain Standards Track [Page 5] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[5ページ]RFC4607
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.
異なったチャンネルはそうですか?
3. Terminology
3. 用語
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.
私たちは、「通常」のASMマルチキャストアドレスに関連しているサービスについて言及するのに「ホストグループ」(RFC1112では、使用される)という用語を使用します(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.によって特定されたホストグループに提供されます。ホストSによってSSM送付先アドレスGに送られたAパケットは(S、G)によって特定されたチャンネルに提供されます。 ホストグループで許された受信機操作は、「(G)を接合してください」と呼ばれて、「(G)を残す」(RFC1112に従って)。 チャンネルの上に許された受信機操作は「(S、G)を申し込んでください、そして、(S、G)を外してください。」と呼ばれます。
Holbrook & Cain Standards Track [Page 6] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[6ページ]RFC4607
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
モデルにサービスを提供してください: いくらか、-、ソース、ソース特有のNetwork Abstraction: チャンネルIdentifierを分類してください: 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をサポートするのに使用されるものの部分集合であることに注意します。
4. Host Requirements
4. ホスト要件
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アドレスの配分
4.1. Extensions to the IP Module Interface
4.1. IPモジュールインタフェースへの拡大
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.
「インタフェース」は(ソースアドレス、グループアドレス)組によって特定されたチャンネルのレセプションが可能にされることになっているか、または無効にされることになっているネットワーク・インターフェースのローカルの識別子です。 特別な値は、「デフォルト」インタフェースを示すのに使用されるかもしれません。 同じチャンネルのレセプションが複数のインタフェースで望まれているなら登録。それぞれのために一度呼び出されます。
Holbrook & Cain Standards Track [Page 7] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[7ページ]RFC4607
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アドレスの範囲を知るために構成されたとき(手動である、またはプロトコルを通して構成メカニズムにかかわらず)、ホストのオペレーティングシステムSHOULDは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で以下で指定されるように、ルータが状態を進めながら、SSMをセットアップしないだろうか、またはASMに対応した前進のデータグラムは要求に参加します。
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()システムコール)の広範囲の実装で、受信機はデータグラムが送られた送付先アドレスを決定できません。 データグラムが受け取られているソケットが複数のチャンネルへのSubscribedであるときに、そのような実装をもっているホストの上では、データグラムの送付先アドレスを推論できません。 ホスト・オペレーティング・システムSHOULDはホストがデータグラムが送られたソースと送付先アドレスの両方を決定する方法を提供します。 (1つの例として、リナックス・オペレーティング・システムはrecvmsg()システムコールへの応答の一部としてパケットの目的地を提供します。) この能力が現在まで、アプリケーションは、データグラムが送られたチャンネルを特定するのにやむを得ずより高い層のメカニズムを使用するかもしれません。
4.2. Requirements on the Host IP Module
4.2. ホストIPモジュールに関する要件
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.
を通して示されて、IPモジュールでSSMアドレスに運命づけられた受信データグラムをそうしたすべてのソケットに提供しなければならない、(登録、)、データグラムのソースアドレスに合っているデータを受け取る願望、送付先アドレス、および到着は連結します。 他のソケットにそれを提供してはいけません。
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モジュールはホストIPモジュールがそのチャンネルがIを連結するという非購読要求を送るのをホストの上の最後のソケットがインタフェースIでチャンネルから外すときホストがソースSによってソース特有のマルチキャストの目的地G.Similarlyに送られたトラフィックを受けたがっている隣接しているルータに示すというインタフェースIに関する要求を送ります。
Holbrook & Cain Standards Track [Page 8] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[8ページ]RFC4607
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へのインターネットGroup Managementプロトコルバージョン3(IGMPv3)メッセージか、IPv6[IGMPv3、MLDv2]へのMulticast Listenerディスカバリーバージョン2(MLDv2)メッセージになるでしょう。 SSMサービスモデルをサポートするホストはIPv4のための[IGMPv3]とIPv6のための[MLDv2]のホスト部分を実装しなければなりません。 また、それは[GMP-SSM]で説明されたIGMPv3/MLDv2の振舞いに従わなければなりません。
4.3. Allocation of Source-Specific Multicast Addresses
4.3. ソース特有のマルチキャストアドレスの配分
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の目的地を保持することです。(IPv6はヌル値として実装で役に立つ場合があります)。 アドレス範囲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に割り当てるRECOMMENDEDです。 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番目で始められたすべてのホストがアドレスを許すなら、高い確率と共に、共有された媒体ローカル・エリア・ネットワークの多くのソース特有のチャンネルが同じリンクレイヤマルチキャストアドレスを使用するでしょうに。 その結果、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
SHOULDがアプリケーションがセッションの始めの前にチャンネル送付先アドレスのユニークな配分を要求するのを許容するためにインタフェースを提供して、この配分データベースSHOULDが固持するホスト・オペレーティング・システムはホストの向こう側にリブートされます。 永続的な配分を提供することによって、ホストアプリケーションはあらかじめ、セッションの広告を出すことができます。
Holbrook & Cain Standards Track [Page 9] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[9ページ]RFC4607
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.)
ウェブページの上、または、別のディレクトリの開始時刻について。 (私たちは、この問題が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がRFC2771[RFC2771]で定義されます。 RFC2771がアプリケーションに特定の範囲のアドレスの中でアドレスを要求させることに注意してください。 インタフェースはこれであるなら使用されていて、範囲の開始アドレスはSHOULDです。アプリケーションで無作為に選択されます。
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アドレスを管理見ることを実装することができます。
5. Router Requirements
5. ルータ要件
5.1. Packet Forwarding
5.1. パケット推進
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データグラムを受けるルータは静かにそれを下げなければなりません。
5.2. Protocols
5.2. プロトコル
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].
プロトコルがソース詳細を伝える能力をわずかな変更で隣接しているルータ(特にPIM-SM[PIM-SM])、およびこれらのプロトコル缶につないで、使用して、ソース特有の意味論を提供するように既に持っているあるIPマルチキャストルーティング。 SSMサービスモデルをサポートするルータは、[PIM-SM]からPIM-SMプロトコルのPIM-SSM部分集合を実装しなければならなくて、IPv4のための[IGMPv3]とIPv6のための[MLDv2]のルータ部分を実装しなければなりません。 また、SSMルータは[GMP-SSM]で説明されたIGMPv3/MLDv2の振舞いに従わなければなりません。
Holbrook & Cain Standards Track [Page 10] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[10ページ]RFC4607
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の完全給付を達成するためにソース特有の意味論を同じ範囲のアドレスに与えるのは、不可欠です。 この仕様に従うために、ルータはソース特有の意味論でALL IANAによって割り当てられたSSMアドレスを扱わなければなりません。
6. Link-Layer Transmission of Datagrams
6. データグラムのリンクレイヤ送信
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のためのRFC1112の指定されるとしてのリンクレイヤネットワーク、IPv6のための[ETHERv6]のように伝えられます。 マルチキャストが(例えば、イーサネット)であるとサポートするほとんどの共有された媒体リンクレイヤネットワークでは、IPソースアドレスはリンクレイヤ送付先アドレスの選択に使用されません。 その結果、そのようなネットワークでは、送付先アドレスGに送られたすべてのパケットがどんなチャンネル(S、G)にも加入したどんなホストにも提供されるでしょう、S.ThereforeにかかわらずIPモジュールはそれがそれらを提供する前のリンクレイヤからソケットレイヤーまで受けるパケットをフィルターにかけなければなりません。
Holbrook & Cain Standards Track [Page 11] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[11ページ]RFC4607
7. Security Considerations
7. セキュリティ問題
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、サービス不能攻撃、ソーススプーフィング、および安全保障問題は管理見ることに関連しました。
7.1. IPsec and SSM
7.1. IPsecとSSM
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.
SSMがトラフィックであると機密保護するのに、IPsec Authentication Header(AH)とEncapsulating Security有効搭載量(超能力)を使用できます、IPsecのマルチキャストのできる実装であるなら。(必要に応じて[RFC4301)で受信機によって使用されます。
7.2. SSM and RFC 2401 IPsec Caveats
7.2. SSMとRFC2401IPsec警告
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.
RFC2401IPsec(現在、[RFC4301]によって取って代わられる)の既存の実装のために、SSMに関連するいくつかの警告があります。 それらはここに記載されています。 RFC2401IPsecでは、ソースアドレスはキーの一部としてSADルックアップに使用されません。 その結果、たまたま、同じSSM送付先アドレスと同じSecurity Parameter Index(SPI)を使用する2人の送付者が両方のチャンネルを受け取っているどんなホストでもSADで「衝突するでしょう」。 チャンネル・アドレスとSPIsが送付者によってともに自主的に割り当てられるので、各送付者がユニークな送付先アドレスか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と同じIPsec SPIを使用することで2個の関係ないチャンネルに加入するなら、問題は起こります。 チャンネル送付先アドレスが送付者によって自主的に割り当てられるので、どんな2人のホストも同時に同じ送付先アドレスを使用できます、そして、これが起こらないのを保証するどんな合理的な手段もありません。 <IPDA、しかしながら、SPI>tupleは一般に、手当たりしだいに選ばれている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人のさまざまな原因からトラフィックを受けているのに気付くことによって、受信機はこの状態を検出できます。
Holbrook & Cain Standards Track [Page 12] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[12ページ]RFC4607
7.3. Denial of Service
7.3. サービス妨害
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.
ルータSHOULDは、購読要求の源がそれが受け取られたインタフェースへの有効なアドレスであることを確かめます。 そうしない場合、偽造しているソースアドレス攻撃を悪化させるでしょう。
We note that these attacks are not unique to SSM -- they are also present for any-source multicast.
私たちは、これらの攻撃がSSMにユニークでないことに注意します--また、それらも存在している、いくらか、-、ソース、マルチキャスト
7.4. Spoofed Source Addresses
7.4. ソースアドレスであると偽造されます。
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
データグラムでソースアドレスを偽造することによって、データグラムを送ることによって、攻撃者は別のホストに属しながら、チャンネルの上に潜在的にSSMサービスモデルに違反できます。 したがって、強い認証を必要とするアプリケーションは、それがすべて、パケットであると仮定するべきではありません。
Holbrook & Cain Standards Track [Page 13] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[13ページ]RFC4607
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.
チャンネルが、より高い層の認証機構なしで要求されたソースによって送られたaで到着してください。IPSEC Authentication Header[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 SHOULDに使用されるルーティング・プロトコルはそのようなチェックを取り入れます。
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](LooseとStrictの両方)は、正しいチャンネルソースの詐欺師がSSMチャンネルにパケットを注入するのを許容するのに使用されるかもしれません。 SSMルータSHOULDはデフォルトでSSM送付先アドレスにソースルーティングを禁じます。 ルータには、ソースにルーティングを許す設定オプションがあるかもしれません。 また、ネットワークの縁のソースアドレスフィルタリングなどの反ソーススプーフィングメカニズムは強く奨励されます。
7.5. Administrative Scoping
7.5. 管理見ること
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)を範囲境界を通して送るかもしれません。
8. Transition Considerations
8. 変遷問題
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に送られたパケットの配信を要求したホストに提供されるだけでしょう。
Holbrook & Cain Standards Track [Page 14] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[14ページ]RFC4607
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が意味論であると単にどんなS.Howeverのためにも(S、G)の購読を要求したすべてのホストにGに運命づけられたどんなパケットも送ることによってサポートしないところから、この実装が過度に危険にさらすドメインでデータグラムをSSMに提供するのは、(S、G)にデータグラムを提供することによって彼らを要求しなかったホストにネットワークインフラを負いながら、可能でしょう。 SSM範囲のアドレスのためのそのような実装はこのドキュメントのセクション5.2と共に明確に対応しません。
9. IANA Considerations
9. IANA問題
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が範囲にアドレスをIPv4に割り当てる、232.0、.0、.1、通じて、232.0 .0 範囲FF3xの.255とIPv6アドレス: 4000:0001 FF3xに:、:7FFF: FFFF。 IETF Consensus[IANA-CONSID]に応じて、これらのアドレスを割り当てます。 これらのアドレスの範囲はサービスのためにすべてのホストがそのサービスによく知られるSSM送付先アドレスを使用するなら、それを必要とするか、または強く利益を得る広い適用性で予約されます。 配分のためのどんな提案もどんなSSM送付先アドレスにも送られたすべてのデータグラムがイーサネットネットワークで同じリンクレイヤ送付先アドレスで送られるという事実を考えなければなりません、ソースにかかわらず。 その上、また、.0/24が同じように使用する232.0.0 24と.0/232.128.0における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 SHALL NOTはどんなSSM送付先アドレスも特定の実体かアプリケーションに割り当てます。 そうするのはソースの特定のモデルの重要な利益の1つに感染するでしょう: ホストが大きいフラットアドレス空間からソース特有のマルチキャストアドレスを簡単に自主的に割り当てる能力。
10. Acknowledgements
10. 承認
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サービスモデルはIPマルチキャストへの代替的アプローチに対するさまざまな先の仕事を利用します、ホルブルックのEXPRESSマルチキャストモデル、Cheriton[EXPRESS]、グリーンの[SMRP]、およびパールマンのSimple Multicast提案を含んでいて、他 [簡単な。] また、232/8アドレスを再選任することにおける彼らのサポートのためのCheritonがSSMに変化するのをジョン・ポステルとデヴィッドに感謝申し上げます。 ブライアン・ハーバーマンはこのドキュメントのIPv6部分に貢献しました。 慎重なレビューをペッカSavolaをありがとうございます。
Holbrook & Cain Standards Track [Page 15] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[15ページ]RFC4607
11. Normative References
11. 引用規格
[ETHERv6] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[ETHERv6] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、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)について議定書の中で述べてください」、RFC4604、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インチ、RFC3376、2002年10月。」
[IPv6-UBM] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[IPv6-UBM] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。
[IPv6-MALLOC] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[IPv6-MALLOC] ハーバーマン、B.、「IPv6マルチキャストアドレスのための配分ガイドライン」、RFC3307、2002年8月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[MLDv2]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[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):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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)アドレッシング体系」、RFC3513、2003年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Holbrook & Cain Standards Track [Page 16] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[16ページ]RFC4607
12. Informative References
12. 有益な参照
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[アドミン範囲] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, November
1988.
[DVMRP] WaitzmanとD.とヤマウズラ、C.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、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.
[急行]のホルブルック、H.、およびCheriton、D.、「明らかに要求されたソース特有のマルチキャスト:」 「EXPRESSは、LargeのためにスケールSingle-ソースがApplicationsであるとサポートします。」 1999'年9月のACM SIGCOMM'99、ケンブリッジ(MA)の議事。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[IGMPv2] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC 2236, November 1997.
w.[IGMPv2]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
[MSFAPI] ターレル、D.、フェナー、B.、およびB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡大」、RFC3678、2004年1月。
[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):、」 「プロトコル仕様(改訂される)」、RFC3973、2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
[RFC2771] フィンリースン、R.、「マルチキャストアドレス配分のための抽象的なAPI」、RFC2771、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.とJinmeiとT.とNordmark、E.とB.Zill、「IPv6はアドレス体系を見た」RFC4007、2005年3月。
Holbrook & Cain Standards Track [Page 17] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[17ページ]RFC4607
[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。 リー、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.
M. [SMRP]グリーンと、「単一の送信機があるグループのためのマルチキャストルート設定のメソッドとシステム。」 合衆国はNo.5,517,494の特許をとります。
Authors' Addresses
作者のアドレス
Brad Cain Acopia Networks
ブラッドカインAcopiaネットワーク
EMail: bcain99@gmail.com
メール: bcain99@gmail.com
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
パロアルト、ヒューホルブルックArastra Inc.P.O. Box10905カリフォルニア 94303
Phone: +1 650 331-1620 EMail: holbrook@arastra.com
以下に電話をしてください。 +1 650 331-1620 メールしてください: holbrook@arastra.com
Holbrook & Cain Standards Track [Page 18] RFC 4607 Source-Specific Multicast August 2006
マルチキャスト2006年8月にソース特有のホルブルックとカイン標準化過程[18ページ]RFC4607
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Holbrook & Cain Standards Track [Page 19]
ホルブルックとカイン標準化過程[19ページ]
一覧
スポンサーリンク
