Network Working Group B. Quinn
Request for Comments: 4570 BoxnArrow.com
Category: Standards Track R. Finlayson
Live Networks, Inc.
July 2006
Session Description Protocol (SDP) Source Filters
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
抽象
This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session.
この文書では、セッション記述プロトコル（SDP）は、1つ以上の宛先「接続」アドレスのソースフィルタのような1つ以上のソースアドレスを発現するように適応させる方法について説明します。これは、マルチキャストまたはユニキャストの宛先のいずれかのための包括的または排他的なソースリストのいずれかとしてのIPv4またはIPv6アドレスを参照することができるSDP「ソースフィルタ」属性の構文およびセマンティクスを定義します。具体的には、包含ソースフィルタは、ソース固有マルチキャスト（SSM）セッションを指定するために使用することができます。
The Session Description Protocol [SDP] provides a general purpose format for describing multimedia sessions in announcements or invitations. SDP uses an entirely textual data format (the US-ASCII subset of [UTF-8]) to maximize portability among transports. SDP does not define a protocol, but only the syntax to describe a multimedia session with sufficient information to discover and participate in that session. Session descriptions may be sent using any number of existing application protocols for transport (e.g., Session Announcement Protocol (SAP), SIP, Real Time Streaming Protocol (RTSP), email, and HTTP).
セッション記述プロトコル[SDP]はアナウンスまたは招待でマルチメディアセッションを記述するための汎用的なフォーマットを提供します。 SDPは、トランスポートの間で移植性を最大にするために（[UTF-8]のUS-ASCIIのサブセット）全体テキストデータ形式を使用します。 SDPは、発見し、そのセッションに参加するために十分な情報を持つマルチメディアセッションを記述するためのプロトコルが、唯一の構文を定義していません。セッション記述は輸送のため、既存のアプリケーションプロトコル（例えば、セッションアナウンスメントプロトコル（SAP）、SIP、リアルタイムストリーミングプロトコル（RTSP）、電子メール、およびHTTP）の任意の数を使用して送信することができます。
Typically, session descriptions reference an IP multicast address for the "connection-address" (destination), though unicast addresses or fully qualified domain names (FQDNs) MAY also be used. The "source- filter" attribute defined in this document qualifies the session traffic by identifying the address (or FQDN) of legitimate sources (senders). The intent is for receivers to use the source and destination address pair(s) to filter traffic, so that applications receive only legitimate session traffic.
ユニキャストアドレスまたは完全修飾ドメイン名（FQDN）を使用することもできるが、典型的には、セッション記述は、「接続アドレス」（宛先）のためのIPマルチキャストアドレスを参照します。この文書で定義された「ソース - フィルタ」属性が正当なソース（送信者）のアドレス（またはFQDN）を識別することによって、セッショントラフィックを修飾します。アプリケーションのみ正規セッショントラフィックを受け取ることができるように、受信機は、トラフィックをフィルタリングするために、ソースと宛先アドレスのペア（複数可）を使用する意図があります。
Receiver applications are expected to use the SDP source-filter information to identify traffic from legitimate senders, and discard traffic from illegitimate senders. Applications and hosts may also share the source-filter information with network elements (e.g., with routers using [IGMPv3]) so they can potentially perform the traffic filtering operation further "upstream," closer to the source(s).
受信機アプリケーションは、正当な送信者からのトラフィックを識別し、不正な送信者からのトラフィックを廃棄するSDPソースフィルタ情報を使用することが期待されます。アプリケーションおよびホストは、（[IGMPv3の]を使用してルータと、例えば）ネットワーク要素とソースフィルタ情報を共有することができるので、潜在的に（S）ソースにさらに「上流」近いトラフィックフィルタリング操作を行うことができます。
The "source-filter" attribute can appear at the session level and/or the media level.
「ソースフィルタ」属性はセッションレベルおよび/またはメディアレベルで表示されます。
The purpose of a source-filter is to help protect receivers from traffic sent from illegitimate source addresses. Filtering traffic can help to preserve content integrity and protect against Denial of Service (DoS) attacks.
ソース・フィルタの目的は、違法な送信元アドレスから送信されるトラフィックから受信機を保護するためです。トラフィックをフィルタリングすると、コンテンツの完全性を維持するために役立つとサービス拒否（DoS）攻撃を防御することができます。
For multicast destination addresses, receiver applications MAY apply source-filters using the Multicast Source Filter APIs [MSF-API]. Hosts are likely to implement these APIs using protocol mechanisms to convey the source filters to local multicast routers. Other "upstream" multicast routers MAY apply the filters and thereby provide more explicit multicast group management and efficient utilization of network resources. The protocol mechanisms to enable these operations are beyond the scope of this document, but their potential provided motivation for SDP source-filters.
マルチキャスト宛先アドレスの場合、受信側のアプリケーションは、マルチキャストソースフィルタAPIに[MSF-API]を使用してソース・フィルタを適用することができます。ホストはローカルマルチキャストルータにソースフィルタを伝えるためにプロトコルメカニズムを使用して、これらのAPIを実装する可能性があります。その他の「上流」マルチキャストルータは、フィルタを適用することにより、より明示的なマルチキャストグループ管理とネットワーク資源の効率的利用を提供することができます。これらの操作を可能にするプロトコルメカニズムは、この文書の範囲外であるが、その可能性は、SDPのソースフィルタのための動機を与えました。
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 [REQMNT].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [REQMNT]に記載されているように解釈されます。
The SDP source-filter attribute does not change any existing SDP syntax or semantics, but defines a format for additional session description information. Specifically, source-filter syntax can prescribe one or more unicast addresses as either legitimate or illegitimate sources for any (or all) SDP session description "connection-address" field values.
SDPソースフィルタ属性は、既存のSDP構文またはセマンティクスを変更するが、追加のセッション記述情報の形式を定義していません。具体的には、ソース・フィルタの構文は、任意の（またはすべての）SDPセッション記述「接続アドレス」フィールド値の正当または不正なソースのいずれかのような1つ以上のユニキャストアドレスを処方することができます。
Note that the unicast source addresses specified by this attribute are those that are seen by a receiver. Therefore, if source addresses undergo translation en route from the original sender to the receiver - e.g., due to Network Address Translation (NAT) or some tunneling mechanism - then the SDP "source-filter" attribute, as presented to the receiver, will not be accurate unless the source addresses therein are also translated accordingly.
この属性で指定されたユニキャスト送信元アドレスは、受信機によって見られるものであることに留意されたいです。そのため、送信元アドレスが受信機に元の送信者からの途中で翻訳を受ける場合 - 例えば、原因ネットワークアドレス変換（NAT）またはいくつかのトンネリングメカニズムに - その後、SDP「ソースフィルタ」属性、受信機に提示される、とは限りません送信元アドレスは、その中にもそれに応じて翻訳されていない限り、正確です。
The source-filter attribute has the following syntax:
ソース・フィルタ属性の構文は次のとおりです。
a=source-filter: <filter-mode> <filter-spec>
=ソース・フィルタ<フィルタモード> <フィルタ仕様>
The <filter-mode> is either "incl" or "excl" (for inclusion or exclusion, respectively). The <filter-spec> has four sub-components:
<フィルタモード>（それぞれ、包含または除外のため）「含」または「除く」のいずれかです。 <フィルタ仕様>は、4つのサブコンポーネントがあります。
<nettype> <address-types> <dest-address> <src-list>
<NETTYPE> <アドレスタイプ> <DEST-アドレス> <SRC-リスト>
A <filter-mode> of "incl" means that an incoming packet is accepted only if its source address is in the set specified by <src-list>. A <filter-mode> of "excl" means that an incoming packet is rejected if its source address is in the set specified by <src-list>.
<フィルタモード>「税込」の着信パケットは、その送信元アドレスは<SRC-リスト>で指定されたセット内にある場合にのみ受け入れられていることを意味しています。 「除く」の<フィルタモード>は、その送信元アドレスが<SRC-リスト>で指定されたセット内にある場合、着信パケットが拒否されたことを意味します。
The first sub-field, <nettype>, indicates the network type, since SDP is protocol independent. This document is most relevant to the value "IN", which designates the Internet Protocol.
最初のサブフィールド、<NETTYPE> SDPプロトコル独立しているので、ネットワークの種類を示します。この文書は、インターネットプロトコルを指定した値「IN」、に最も関連しています。
The second sub-field, <address-types>, identifies the address family, and for the purpose of this document may be either <addrtype> value "IP4" or "IP6". Alternately, when <dest-address> is an FQDN, the value MAY be "*" to apply to both address types, since either address type can be returned from a DNS lookup.
第2サブフィールド、<アドレスタイプ>、アドレスファミリーを識別し、この文書の目的のために<ADDRTYPE>値「IP4」または「IP6」のいずれであってもよいです。 <DEST-address>はFQDNであるとき、交互に、値がいずれかのアドレスタイプは、DNSルックアップから返される可能性があるため、両方のアドレスタイプに適用するために、「*」であってもよいです。
The third sub-field, <dest-address>, is the destination address, which MUST correspond to one or more of the session's "connection-address" field values. It may be either a unicast or multicast address, an FQDN, or the "*" wildcard to match any/all of the session's "connection-address" values.
第3サブフィールド、<DESTアドレス>、セッションの「接続アドレス」フィールドの値の1つ以上に対応している必要があり、宛先アドレス、です。これは、ユニキャストまたはマルチキャストアドレス、FQDN、またはセッションの「コネクション・アドレス」の値のいずれか/すべてを一致するように、「*」はワイルドカードのいずれであってもよいです。
The fourth sub-field, <src-list>, is the list of source hosts/interfaces in the source-filter, and consists of one or more unicast addresses or FQDNs, separated by space characters.
第4のサブフィールド、<SRC-list>は、ソースホスト/ソースフィルタのインターフェイスのリストであり、空白文字で区切られた1つ以上のユニキャストアドレスまたはFQDNが、から成ります。
The format and content of these semantic elements are derived from and compatible with those defined in [SDP]. For more detail, see Appendix A of this document.
これらのセマンティック要素の形式と内容は由来し、[SDP]で定義されたものと互換性があります。詳細については、このドキュメントの付録Aを参照してください。
There are a number of details to consider when parsing the SDP source-filter syntax.
SDPソースフィルタの構文を解析する際に考慮すべき内容がいくつかあります。
The <dest-address> value in a "source-filter" attribute MUST correspond to an existing <connection-field> value in the session description. The only exception to this is when a "*" wildcard is used to indicate that the source-filter applies to all <connection-field> values.
<DESTアドレス>値「ソース・フィルタ」の属性は、セッション記述における既存の<接続フィールド>の値に対応しなければなりません。これに対する唯一の例外は、「*」ワイルドカードは、ソース・フィルタは、すべての<接続フィールド>の値に適用されることを示すために使用されている場合です。
When the <dest-address> value is a multicast address, the field value MUST NOT include the sub-fields <ttl> and <number of addresses> from the <connection-address> value. If the <connection-address> specifies more than one multicast address (in the <number of addresses> field), then a source filter, if any, for each such address must be stated explicitly, using a separate "a=source-filter" line for each address (unless a "*" wildcard is used for <dest-address>). See section 3.2.4 for an example.
<DESTアドレス>値がマルチキャストアドレスである場合、フィールドの値が<接続アドレス>値からサブフィールド<TTL>と<アドレスの数>を含んではいけません。 <接続アドレス>が（<アドレスの数>フィールドに）複数のマルチキャストアドレスを指定した場合、その後、ソースフィルタは、もしあれば、そのような各アドレスに別々の「A =ソース・フィルタを使用して、明示的に指定しなければなりません"（*『ワイルドカード<DESTアドレス>に使用されていない限り）各アドレスのライン』。例えばセクション3.2.4を参照してください。
When the <addrtype> value is the "*" wildcard, the <dest-address> MUST be either an FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6 address). See section 3.2.6 for an example.
<ADDRTYPE>の値が「*」はワイルドカードである場合、<DEST-アドレス>（即ち、それはIPv4またはIPv6アドレスでないこと）FQDNまたは「*」でなければなりません。例えばセクション3.2.6を参照してください。
As has always been the case, the default behavior when a source-filter attribute is not provided in a session description is that all traffic sent to the specified <connection-address> value should be accepted (i.e., from any source address). The source-filter grammar does not include syntax to express either "exclude none" or "include all."
常にそうであったように、ソース・フィルタ属性はセッション記述には設けられていないデフォルトの動作は、指定された<接続アドレス>値に送信されたすべてのトラフィック（すなわち、任意のソースアドレスからの）受け入れなければならないということです。ソース・フィルタの文法は、いずれかの表現「何を除外しない」またはする構文が含まれていない「すべてが含まれています。」
Like the standard <connection-field> described in [SDP], the location of the "source-filter" attribute determines whether it applies to the entire session or only to a specific medium (i.e., "session-level" or "media-level"). A media-level source-filter will always completely override a session-level source-filter.
「ソースフィルタ」属性は、それが全体のセッションにのみ、特定の媒体に適用されるか否かを判断する（すなわち、「セッションレベル」または「する、メディアの位置、[SDP]に記載されている標準<接続フィールド>様レベル"）。メディアレベルのソース・フィルタは、常に完全にセッションレベルのソース・フィルタを無効にします。
A "source-filter" need not be located at the same hierarchy level as its corresponding <connection-field>. So, a media-level <source-filter> can reference a session-level <connection-field> value, and a session-level "source-filter" can be applied to all matching media-level <connection-field> values. See section 3.2.3 for an example.
「ソース・フィルタ」は、その対応する<接続場>と同じ階層レベルに配置される必要はありません。だから、メディアレベル<ソース・フィルタは>セッションレベル<接続フィールド>の値を参照することができ、そしてセッションレベル「ソース・フィルタ」は、一致するすべてのメディアレベル<接続フィールド>の値に適用することができます。例えばセクション3.2.3を参照してください。
An SDP description MUST NOT contain more than one session-level "source-filter" attribute that covers the same destination address, or more than one media-level "source-filter" attribute that covers the same destination address.
SDPの記述は、同じ宛先アドレスをカバーし、あるいは同じ宛先アドレスをカバーし、複数のメディアレベル「ソースフィルタ」属性に複数のセッションレベル「ソースフィルタ」属性を含んではなりません。
There is no specified limit to the number of entries allowed in the <src-list>; however, there are practical limits that should be considered. For example, depending on the transport to be used for the session description, there may be a limit to the total size of the session description (e.g., as determined by the maximum payload in a single datagram). Also, when the source-filter is applied to control protocols, there may be a limit to the number of source addresses that can be sent. These limits are outside the scope of this document, but should be considered when defining source-filter values for SDP.
<SRC-リスト>で許可されるエントリの数に指定された制限はありません。しかし、考慮すべき現実的な限界があります。例えば、セッション記述のために使用されるトランスポートに依存して、セッション記述（例えば、単一のデータグラムで最大ペイロードによって決定される）の合計サイズには限界があってもよいです。ソース・フィルタはプロトコルを制御するために適用される場合も、送信できる送信元アドレスの数に制限があってもよいです。これらの制限は、この文書の範囲外であるが、SDPのソース・フィルタ値を定義するときに考慮されるべきです。
Here are a number of examples that illustrate how to use the source-filter attribute in some common scenarios. We use the following session description components as the starting point for the examples to follow. For each example, we show the source filter with additional relevant information and provide a brief explanation.
ここではいくつかの一般的なシナリオでは、ソース・フィルタ属性を使用する方法を示すサンプル数があります。私たちは例が追従するための出発点として、以下のセッション記述コンポーネントを使用しています。各たとえば、我々は追加の関連情報をソースフィルタを表示し、簡単な説明を提供しています。
<session-description> = v=0 o=The King <Elvis@example.com> s=Elvis Impersonation i=All Elvis, all the time u=http://www.example.com/ElvisLive/ t=0 0 a=recvonly
<セッション記述> = V = 0 0 =キング<Elvis@example.com> S =エルビス偽装I =すべてのエルビス、すべての時間のu =のhttp：//www.example.com/ElvisLive/トン= 0 0 A =がrecvonly
<media-description 1> = m=audio 54320 RTP/AVP 0
<メディア記述1> = M =オーディオ54320 RTP / AVP 0
<media-description 2> = m=video 54322 RTP/AVP 34
<メディア記述2> = M =ビデオ54322 RTP / AVP 34
Multicast addresses in the Source-Specific Multicast [SSM] range require a single unicast sender address for each multicast destination, so the source-filter specification provides a natural fit. In this example, a session member should receive only traffic sent from 192.0.2.10 to the multicast session address 232.3.4.5.
ソースフィルタ仕様は、自然なフィットを提供するように、ソース固有マルチキャスト[SSM]におけるマルチキャストアドレスは、各マルチキャスト宛先のための単一のユニキャスト送信元アドレスを必要とする範囲です。この例では、セッションメンバーは、マルチキャストセッションアドレス232.3.4.5に192.0.2.10から送信されたトラフィックのみを受け取る必要があります。
<session-description>
<セッション記述>
c=IN IP4 232.3.4.5/127 a=source-filter: incl IN IP4 232.3.4.5 192.0.2.10
C = IP4 232.3.4.5/127 =ソースフィルタの場合：税込、IN IP4 232.3.4.5 192.0.2.10
<media-description 1>
<メディア記述1>
This source-filter example uses an inclusion list with a single multicast "connection-address" as the destination and single unicast address as the source. Note that the value of the connection-address matches the value specified in the connection-field.
このソース・フィルタの例は、宛先及びソースのような単一のユニキャストアドレスとして単一のマルチキャスト「接続アドレス」に包含リストを使用します。コネクションアドレスの値は、接続フィールドで指定された値と一致していることに注意してください。
Also note that since the connection-field is located in the session-description section, the source-filter applies to all media.
また、接続フィールドは、セッション記述部に位置しているので、ソース・フィルタは、すべてのメディアに適用されることに注意してください。
Furthermore, if the SDP description specifies an RTP session (e.g., its "m=" line(s) specify "RTP/AVP" as the transport protocol), then the "incl" specification will apply not only to RTP packets, but also to any RTCP packets that are sent to the specified multicast address. This means that, as a side effect of the "incl" specification, the only possible multicast RTCP packets will be "Sender Report" (SR) packets sent from the specified source address.
SDP記述がRTPセッションを指定している場合、さらに、（例えば、その「M =」行（S）トランスポートプロトコルとして「RTP / AVP」を指定する）、次いで、「含」仕様だけでなく、RTPパケットにだけでなく、適用されます指定されたマルチキャストアドレスに送信されたすべてのRTCPパケットに。これはことを意味し、「税込」仕様の副作用として、唯一の可能なマルチキャストRTCPパケットは、「送信者レポート」指定した送信元アドレスから送信された（SR）パケットとなります。
Because of this, an SDP description for a Source-Specific Multicast (SSM) RTP session SHOULD also include an
このため、ソース固有マルチキャスト（SSM）RTPセッションのSDP記述も含むべきです
a=rtcp-unicast ...
= RTCP-ユニ...
attribute, as described in [RTCP-SSM] (section 10.1). This specifies that RTCP "Reception Report" (RR) packets are to be sent back via unicast.
[RTCP-SSM（セクション10.1）に記載されているように、属性。これは、RTCP「受信レポート」（RR）パケットが戻って、ユニキャストを経由して送信されることを指定します。
Typically, an SDP session <connection-address> value is a multicast address, although it is also possible to use either a unicast address or FQDN. This example illustrates a scenario whereby a session description indicates the unicast source address 192.0.2.10 in an exclusion filter. In effect, this sample source-filter says, "destination 192.0.2.11 should accept traffic from any sender *except* 192.0.2.10."
ユニキャストアドレスまたはFQDNのいずれかを使用することも可能であるが、典型的には、SDPセッション<接続アドレス>値は、マルチキャストアドレスです。この例では、セッション記述は除外フィルタにユニキャスト送信元アドレス192.0.2.10を示すれるシナリオを示します。実際には、このサンプル・ソース・フィルタは言う、「先192.0.2.11は* 192.0.2.10以外の任意の送信者*からのトラフィックを受け入れる必要があります。」
<session-description>
<セッション記述>
c=IN IP4 192.0.2.11 a=source-filter: excl IN IP4 192.0.2.11 192.0.2.10
IP4 192.0.2.11 =ソースフィルタのC =：IP4 192.0.2.11 192.0.2.10 IN EXCL
<media-description 1>
<メディア記述1>
This source-filter example uses the wildcard "*" value for <dest-addr> to correspond to any/all <connection-address> values. Hence, the only legitimate source for traffic sent to either
このソース・フィルタの例は、任意の/すべての<接続アドレス>の値に対応する「*」<DEST-ADDR>の値をワイルドカードを使用します。そのため、トラフィックのための唯一の合法的なソースのいずれかに送信されました
232.2.2.2 or 232.4.4.4 multicast addresses is 192.0.2.10. Traffic sent from any other unicast source address should be discarded by the receiver.
232.2.2.2や232.4.4.4マルチキャストアドレス192.0.2.10です。他のユニキャスト送信元アドレスから送信されるトラフィックは、受信機によって廃棄されなければなりません。
<session-description>
<セッション記述>
a=source-filter: incl IN IP4 * 192.0.2.10
=ソースフィルタ：IP4、IN税込* 192.0.2.10
<media-description 1>
<メディア記述1>
c=IN IP4 232.2.2.2/127
IP4 232.2.2.2/127のC =
<media-description 2>
<メディア記述2>
c=IN IP4 232.4.4.4/63
IP4 232.4.4.4/63のC =
In this example, the <connection-address> specifies three multicast addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3. The first and third of these addresses are given source filters. However, in this example the second address - 224.2.1.2 - is *not* given a source filter.
224.2.1.1、224.2.1.2、および224.2.1.3：この例では、<接続アドレス>は3つのマルチキャストアドレスを指定します。第一及びこれらのアドレスの第三は、ソースフィルタを与えています。しかし、この例では第2のアドレス - 224.2.1.2は、 - ソースフィルタ所与*ありません。
<session-description>
<セッション記述>
c=IN IP4 224.2.1.1/127/3 a=source-filter: incl IN IP4 224.2.1.1 192.0.2.10 a=source-filter: incl IN IP4 224.2.1.3 192.0.2.42
C = IP4 224.2.1.1/127/3 =ソースフィルタの場合：税込、IN IP4 224.2.1.1 192.0.2.10 A =ソースフィルタ：税込、IN IP4 224.2.1.3 192.0.2.42
<media-description 1>
<メディア記述1>
This simple example defines a single session-level source-filter that references a single IPv6 multicast destination and source pair. The IP multicast traffic sent to FFOE::11A is valid only from the unicast source address 2001:DB8:1:2:240:96FF:FE25:8EC9.
この単純な例では、単一のIPv6マルチキャスト宛先及びソースペアを参照する単一のセッション・レベル・ソース・フィルタを定義します。 DB8：：FFOE :: 11Aに送信されたIPマルチキャストトラフィックは、ユニキャスト送信元アドレス2001から有効である1：2：240：96FF：FE25：8EC9。
<session-description>
<セッション記述>
c=IN IP6 FF0E::11A/127 a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9
IP6のFF0Eにおけるc = IN IP6 FF0E :: 11A / 127 =ソースフィルタ込み:: 11A 2001：DB8：1：2：240：96FF：FE25：8EC9
<media-description 1>
<メディア記述1>
This example illustrates use of the <addrtype> "*" wildcard, along with multicast and source FQDNs that may resolve to either an IPv6 or IPv4 address, or both. Although typically both the multicast and source addresses will be the same (either both IPv4 or both IPv6), using the wildcard for addrtype in the source filter allows asymmetry between the two addresses (so an IPv4 source address may be used with an IPv6 multicast address).
この例では、IPv6またはIPv4アドレス、またはその両方のいずれかに解決することができるマルチキャストおよびソースのFQDNと共に、<ADDRTYPE>「*」ワイルドカードの使用を示します。典型的には、両方のマルチキャストおよびソースアドレス（IPv4または両方IPv6の両方とも）同じになるが、ソースフィルタでADDRTYPEためにワイルドカードを使用するので、IPv4ソースアドレスはIPv6マルチキャストアドレスを使用することができる2つのアドレス（の間の非対称性を可能にします）。
<session-description>
<セッション記述>
c=IN IP4 channel-1.example.com/127 c=IN IP6 channel-1.example.com/127 a=source-filter: incl IN * channel-1.example.com src-1.example.com
C IN = IP4 channel-1.example.com/127 C IN = IP6 channel-1.example.com/127 A =ソースフィルタIN：税込* channel-1.example.com src-1.example.com
<media-description 1>
<メディア記述1>
The "source-filter" attribute is not intended to be used as an 'offer' in an SDP offer-answer exchange [OFFER], because sets of source addresses do not represent 'capabilities' or 'limitations' of the offerer, and because the offerer does not, in general, have a priori knowledge of which IP source address(es) will be included in an answer. While an answerer may include the "source-filter" attribute in his/her answer (e.g., to designate a SSM session), the answerer SHOULD ignore any "source-filter" attribute that was present in the original offer.
「ソース・フィルタ」属性は送信元アドレスのセットは、オファーの「能力」や「制限」を表すものではありませんので、SDPオファーアンサー交換[オファー]で「提供」として使用することを意図し、されていないので、オファー側は、一般的には、その送信元IPアドレス（複数可）の先験的知識が答えに含まれるていません。回答者は、彼/彼女の回答（例えば、SSMのセッションを指定する）の「ソースフィルタ」属性を含むことができるが、回答者は、元のオファーに存在したすべての「ソースフィルタ」属性を無視すべきです。
Defining a list of legitimate sources for a multicast destination address represents a departure from the Any-Source Multicast (ASM) model, as originally described in [IGMPv1]. The ASM model supports anonymous senders and all types of multicast applications (e.g., many-to-many). Use of a source-filter excludes some (unknown or undesirable) senders, which lends itself more to one-to-many or few-to-few type multicast applications.
元々【のIGMPv1]に記載されているように、マルチキャスト宛先アドレスの正当なソースのリストを定義すると、任意の-ソースマルチキャスト（ASM）モデルからの逸脱を表します。 ASMモデルは、匿名の送信者と（例えば、多対多）マルチキャストアプリケーションのすべての種類をサポートしています。ソースフィルタの使用はより1対多数または少数対少数のタイプのマルチキャストアプリケーションに適しているいくつかの（未知の、または望ましくない）送信者を除外する。
Although these two models have contrasting operational characteristics and requirements, they can coexist on the same network using the same protocols. Use of source-filters do not corrupt the ASM semantics but provide more control for receivers, at their discretion.
これら2つのモデルは動作特性および要件を対比しているが、それらは同じプロトコルを使用して、同じネットワーク上に共存することができます。ソースフィルタの使用は、ASMの意味壊れていないが、彼らの裁量で、受信機のためのより多くの制御を提供します。
See [SDP] for security considerations specific to the Session Description Protocol in general. The central issue relevant to using source address filters is the question of address authenticity.
一般的に、セッション記述プロトコルに固有のセキュリティ上の考慮事項については、[SDP]を参照してください。送信元アドレスフィルタを使用してに関連する中心的な問題は、アドレス真正性の問題です。
Using the source IP address for authentication is weak, since addresses are often dynamically assigned and it is possible for a sender to "spoof" its source address (i.e., use one other than its own) in datagrams that it sends. Proper router configuration, however, can reduce the likelihood of "spoofed" source addresses being sent to or from a network. Specifically, border routers are encouraged to filter traffic so that datagrams with invalid source addresses are not forwarded (e.g., routers drop datagrams if the source address is non-local) [FILTERING]. This, however, does not prevent IP source addresses from being spoofed on a Local Area Network (LAN).
認証のためのソースIPアドレスを使用すると、アドレスは、多くの場合、動的に割り当てられていることから、弱く、送信者が「なりすまし」の送信元アドレスは、送信するデータグラムで（すなわち、自社以外のものを使用）することが可能です。適切なルータ設定には、しかし、またはネットワークから送信されている「偽装された」送信元アドレスの可能性を減らすことができます。 [フィルタリング]具体的には、境界ルータが無効送信元アドレスを持つデータグラムが転送されないようにトラフィックをフィルタリングすることが奨励される（ソースアドレスが非ローカルである場合、例えば、ルータは、データグラムをドロップ）。しかし、これは、ローカルエリアネットワーク（LAN）上でスプーフィングされたIP送信元アドレスを防ぐことはできません。
Also, as noted in section 3 above, tunneling or NAT mechanisms may require corresponding translation of the addresses specified in the SDP "source-filter" attribute, and furthermore, may cause a set of original source addresses to be translated to a smaller set of source addresses as seen by the receiver.
上記のセクション3で述べたように、また、トンネリングまたはNATメカニズムはSDP「ソースフィルタ」属性で指定されたアドレスの対応する翻訳を必要とするかもしれない、さらに、元のソース・アドレスのセットは、の小さなセットに変換させてもよいです受信機から見たソースアドレス。
Use of FQDNs for either <dest-address> or <src-list> values provides a layer of indirection that provides great flexibility. However, it also exposes the source-filter to any security inadequacies that the DNS system may have. If unsecured, it is conceivable that the DNS server could return illegitimate addresses.
<DEST-アドレス>または<SRC-list>の値のいずれかのためのFQDNを使用すると、大きな柔軟性を提供して間接的なレイヤを提供します。しかし、それはまた、DNSシステムが持つかもしれないセキュリティの不備にソース・フィルタを公開します。無担保する場合は、DNSサーバーが違法なアドレスを返すことが考えられます。
In addition, if source-filtering is implemented by sharing the source-filter information with network elements, then the security of the protocol(s) that are used for this (e.g., [IGMPv3]) becomes important, to ensure that legitimate traffic (and only legitimate traffic) is received.
ソースフィルタリングは、ネットワーク要素とソースフィルタ情報を共有することによって実装されている場合に加えて、このために使用されるプロトコル（単数または複数）のセキュリティ（例えば、[IGMPv3のは]）（その正当なトラフィックを確実にするために、重要となりますそして唯一の正当なトラフィック）が受信されます。
For these reasons, receivers SHOULD NOT treat the SDP "source-filter" attribute as being its sole mechanism for protecting the integrity of received content.
これらの理由から、受信機は、受信したコンテンツの完全性を保護するための独自のメカニズムであるとしてSDP「ソースフィルタ」属性を扱うべきではありません。
As recommended by [SDP] (Appendix B), the new attribute name "source-filter" has been registered with IANA, as follows:
[SDP（付録B）によって推奨されるように、以下のように、新しい属性名「ソース・フィルタ」は、IANAに登録されています。
The following contact information shall be used for all registrations included here:
以下の連絡先情報はここに含まれるすべての登録に使用しなければなりません。
Contact: Ross Finlayson
email: finlayson (at) live555.com
phone: +1-650-254-1184
SDP Attribute ("att-field"): Attribute name: source-filter Long form: Source Filter Type of name: att-field Type of attribute: Session level or media level Subject to charset: No Purpose: See this document Reference: This document Values: See this document, and registrations below
SDP属性（「ATT-フィールド」）：属性名：ソース・フィルタロングフォーム：名前のソースフィルタタイプ：属性のATT-場の種類：文字セットに従うことを条件として、セッションレベルまたはメディアレベル：いいえ目的：このドキュメントのリファレンスを参照してください。この文書値：このドキュメントを参照してください、以下の登録
The authors would like to thank Dave Thaler and Mark Handley, whose input provided much of the substance of this document. Magnus Westerlund also provided valuable feedback during editing.
著者は、その入力が、この文書の物質の多くを提供デーブターラーとマーク・ハンドリーを、感謝したいと思います。マグヌスウェスターはまた、編集中の貴重なフィードバックを提供しました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[REQMNT] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQMNT]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[FILTERING] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[フィルタリング]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、BCP 38、RFC 2827、2000年5月。
[IGMPv1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[IGMPv1レポート]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年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月。
[MSF-API] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[MSF-API]ターラー、D.、フェナー、B.、およびB.クイン、 "マルチキャストソースフィルタのためのソケットインタフェース拡張"、RFC 3678、2004年1月。
[OFFER] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[オファー]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RTCP-SSM] Chesterfield, J., E. Schooler, J. Ott, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, October 2004.
[RTCP-SSM]チェスターフィールド、J.、E.学生、J.オット、 "ユニキャストフィードバック付きシングルソースのマルチキャストセッションのRTCP拡張機能"、進歩、2004年10月に作業。
[SSM] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[SSM]バッタチャリヤ、S.、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
Appendix A. Source-Filter Attribute Syntax
付録A.ソース・フィルターの属性の構文
This appendix provides an Augmented BNF [ABNF] grammar for expressing an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast source addresses. It is intended as an extension to the grammar for the Session Description Protocol, as defined in [SDP]. Specifically, it describes the syntax for the new "source-filter" attribute field, which MAY be either a session-level or media-level attribute.
この付録は、一つ以上の（IPv4またはIPv6）ユニキャスト送信元アドレスの除外または包含リストを表現するための増大しているBNF [ABNF]文法を提供します。 [SDP]で定義されるように、それは、セッション記述プロトコル用の文法の拡張として意図されています。具体的には、セッションレベルまたはメディアレベルの属性のいずれであってもよく、新しい「ソース・フィルタ」属性フィールド、構文について説明します。
The "dest-address" value in each source-filter field MUST match an existing connection-field value, unless the wildcard connection-address value "*" is specified.
ワイルドカード接続アドレス値「*」が指定されない限り、各ソース・フィルタ・フィールドにおける「DESTアドレス」の値は、既存の接続フィールド値と一致しなければなりません。
source-filter = "source-filter" ":" SP filter-mode SP filter-spec ; SP is the ASCII 'space' character ; (0x20, defined in [ABNF]).
ソース・フィルタ=「ソースフィルタ」「：」SPフィルタモードSPフィルタスペック。 SPはASCII「空白」文字です。 （0x20に、[ABNF]で定義されます）。
filter-mode = "excl" / "incl" ; either exclusion or inclusion mode.
フィルタモード=「除く」/「税込」;除外または包含モードのいずれか。
filter-spec = nettype SP address-types SP dest-address SP src-list ; nettype is as defined in [SDP].
フィルタスペック= NETTYPEのSPアドレス・タイプSP DESTアドレスSPのSRC-リスト。 [SDP]で定義されるようNETTYPEです。
address-types = "*" / addrtype ; "*" for all address types (both IP4 and IP6), ; but only when <dest-address> and <src-list> ; reference FQDNs. ; addrtype is as defined in [SDP].
アドレスタイプ=「*」/ ADDRTYPE。すべてのアドレスタイプ（IP4とIP6の両方）のための「*」、。しかし、ときにのみ、<DEST-アドレス>と<SRC-リスト>;参照のFQDN。 ; [SDP]で定義されるようADDRTYPEです。
dest-address = "*" / basic-multicast-address / unicast-address ; "*" applies to all connection-address values. ; unicast-address is as defined in [SDP].
DEST-アドレス= "*" /基本的なマルチキャスト・アドレス/ユニキャストアドレス。 「*」すべての接続アドレス値に適用されます。 ; [SDP]で定義されるようにユニキャストアドレスです。
src-list = *(unicast-address SP) unicast-address ; one or more unicast source addresses (in ; standard IPv4 or IPv6 ASCII-notation form) ; or FQDNs. ; unicast-address is as defined in [SDP].
SRC-リスト= *（ユニキャスト・アドレスSP）ユニキャストアドレス。 （;標準IPv4またはIPv6 ASCII表記の形で）は、1つ以上のユニキャストソースアドレス。またはFQDNが。 ; [SDP]で定義されるようにユニキャストアドレスです。
basic-multicast-address = basic-IP4-multicast / basic-IP6-multicast / FQDN / extn-addr ; i.e., the same as multicast-address ; defined in [SDP], except that the ; /<ttl> and /<number of addresses> ; fields are not included. ; FQDN and extn-addr are as defined ; in [SDP].
基本的なマルチキャストアドレス=基本IP4マルチキャスト/基本IP6マルチキャスト/ FQDN / EXTN-ADDR。すなわち、マルチキャストアドレスと同じ。ことを除いて、[SDP]で定義されます。 / <TTL>および/または<アドレスの数>。フィールドが含まれていません。 ;定義されたようFQDNとEXTN-addrがあります。 [SDP]です。
basic-IP4-multicast = m1 3( "." decimal-uchar ) ; m1 and decimal-uchar are as defined ; in [SDP].
基本IP4マルチキャスト= M1 3（小数UCHAR ""）;定義されたようM1と小数UCHARです。 [SDP]です。
basic-IP6-multicast = hexpart ; hexpart is as defined in [SDP].
基本的な-IP6-マルチキャスト= hexpart。 [SDP]で定義されるようhexpartです。
Authors' Addresses
著者のアドレス
Bob Quinn BoxnArrow.com 31 Caldwell Road Waltham, MA 02453
ボブ・クインBoxnArrow.com 31コールドウェル・ロードウォルサム、MA 02453
Phone: +1-781-577-1539 EMail: rcq@boxnarrow.com
電話：+ 1-781-577-1539 Eメール：rcq@boxnarrow.com
Ross Finlayson Live Networks, Inc. 650 Castro St., suite 120-196 Mountain View, CA 94041
ロス・フィンレイソンライブネットワークス株式会社650カストロ聖、スイート120から196マウンテンビュー、CA 94041
EMail: finlayson@live555.com
メールアドレス：finlayson@live555.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）によって提供されます。