[要約] RFC 4570は、Session Description Protocol（SDP）のソースフィルタに関する仕様を定めたものです。このRFCの目的は、SDPを使用してセッションのソースフィルタを指定する方法を提供することです。
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
セッション説明プロトコル（SDP）ソースフィルター
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
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アドレス（ES）のいずれかをマルチキャストまたはユニキャストの宛先のいずれかの包括的または排他的なソースリストとして参照できる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.
通常、セッションの説明は、「接続アドレス」（宛先）のIPマルチキャストアドレスを参照しますが、ユニキャストアドレスまたは完全資格のドメイン名（FQDNS）も使用できます。このドキュメントで定義されている「ソースフィルター」属性は、正当なソース（送信者）のアドレス（または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]を使用してルーターと）と共有することもできます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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構文やセマンティクスを変更しませんが、追加セッションの説明情報の形式を定義します。具体的には、Source-Filterの構文は、1つ以上のユニキャストアドレスを、（またはすべての）SDPセッションの説明「接続アドレス」フィールド値の正当なソースまたは違法なソースとして処方できます。
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:
<filter-mode>は、「incluse」または「除外」のいずれかです（それぞれ包含または除外用）。<filter-spec>には4つのサブコンポーネントがあります。
<nettype> <address-types> <dest-address> <src-list>
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>.
「inl」の<filter-mode>は、そのソースアドレスが<src-list>で指定されたセットにある場合にのみ、着信パケットが受け入れられることを意味します。「除外」の<filter-mode>は、ソースアドレスが<src-list>で指定されたセットにある場合、着信パケットが拒否されることを意味します。
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.
SDPはプロトコルに依存しないため、最初のサブフィールド<NetType>はネットワークタイプを示します。このドキュメントは、インターネットプロトコルを指定する値「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-Address>は、宛先アドレスであり、セッションの「接続アドレス」フィールド値の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-Address>値は、セッションの説明の既存の<接続フィールド>値に対応する必要があります。これの唯一の例外は、「*」ワイルドカードを使用して、ソースフィルターがすべての<connection-field>値に適用されることを示す場合です。
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-Address>値がマルチキャストアドレスである場合、フィールド値には、<connection-address>値からサブフィールド<ttl>および<アドレスの数を含めてはなりません。<connection-Address>が複数のマルチキャストアドレス（<アドレスの数>フィールド）を指定している場合、そのようなアドレスごとにソースフィルターを明示的に記載する必要があります。「各アドレスのライン（「*」ワイルドカードが<Dest-Address>に使用されない限り）。例については、セクション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-address>はfqdnまたは "*"でなければなりません（つまり、IPv4またはIPv6アドレスであってはなりません）。例については、セクション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]で説明されている標準<connection-field>のように、「ソースフィルター」属性の位置は、セッション全体に適用されるか、特定のメディア（つまり、「セッションレベル」または「メディア」に適用されるかどうかを決定します。レベル"）。メディアレベルのソースフィルターは、常にセッションレベルのソースフィルターを完全にオーバーライドします。
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.
「ソースフィルター」は、対応する<接続フィールド>と同じ階層レベルに配置する必要はありません。したがって、メディアレベルの<source-filter>は、セッションレベルの<connection-field>値を参照でき、セッションレベルの「ソースフィルター」をすべての一致するメディアレベル<接続フィールド>値に適用できます。例については、セクション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-list>で許可されているエントリの数に指定された制限はありません。ただし、考慮すべき実用的な制限があります。たとえば、セッションの説明に使用するトランスポートに応じて、セッションの説明の合計サイズに制限がある場合があります（たとえば、単一のデータグラムの最大ペイロードによって決定されます）。また、ソースフィルターが制御プロトコルに適用されると、送信できるソースアドレスの数に制限がある場合があります。これらの制限はこのドキュメントの範囲外ですが、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
<media-description 1> =
m=audio 54320 RTP/AVP 0
<media-description 2> =
m=video 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]範囲のマルチキャストアドレスには、各マルチキャスト宛先の単一キャスト送信者アドレスが必要であるため、ソースフィルター仕様は自然に適合します。この例では、セッションメンバーは、192.0.2.10からマルチキャストセッションアドレス232.3.4.5に送信されたトラフィックのみを受け取る必要があります。
<session-description>
<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 = In IP4 232.3.4.5/127 a = source-filter：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 =」行は「RTP/AVP」を輸送プロトコルとして指定します）、「inl」仕様は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 ...
a = rtcp-unicast ...
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）パケットがUnicastを介して送信されることを指定します。
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."
通常、SDPセッション<Connection-Address>値はマルチキャストアドレスですが、ユニキャストアドレスまたはFQDNのいずれかを使用することもできます。この例は、セッションの説明が除外フィルターのユニキャストソースアドレス192.0.2.10を示すシナリオを示しています。実際には、このサンプルソースフィルターは、「目的地192.0.2.11は、 * 192.0.2.10を除く送信者 *からのトラフィックを受け入れる必要があります。」
<session-description>
<session-description>
c=IN IP4 192.0.2.11 a=source-filter: excl IN IP4 192.0.2.11 192.0.2.10
c = in ip4 192.0.2.11 a = source-filter：IP4で除外192.0.2.11 192.0.2.10
<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 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.
このソースフィルターの例では、<dest-Addr>のWildCard "*"値を使用して、<connection-address>値に対応します。したがって、232.2.2.2または232.4.4.4のマルチキャストアドレスのいずれかに送信されるトラフィックの唯一の正当なソースは192.0.2.10です。他のユニキャストソースアドレスから送信されたトラフィックは、受信機によって破棄される必要があります。
<session-description>
<session-description>
a=source-filter: incl IN IP4 * 192.0.2.10
<media-description 1>
<メディアデスクリプリ1>
c=IN IP4 232.2.2.2/127
C = IP4 232.2.2.2/127
<media-description 2>
<メディアデスクリプリ2>
c=IN IP4 232.4.4.4/63
C = IP4 232.4.4.4/63
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.
この例では、<connection-address>は、224.2.1.1、224.2.1.2、および224.2.1.3の3つのマルチキャストアドレスを指定します。これらのアドレスの最初と3番目には、ソースフィルターが与えられます。ただし、この例では、2番目のアドレス-224.2.1.2-はソースフィルターを与えられていません。
<session-description>
<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
<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マルチキャスト宛先とソースペアを参照する単一のセッションレベルのソースフィルターを定義しています。FFOE :: 11aに送信されたIPマルチキャストトラフィックは、Unicast Sourceアドレス2001：DB8：1：2：240：96FF：FE25：8EC9からのみ有効です。
<session-description>
<session-description>
c=IN IP6 FF0E::11A/127
a=source-filter incl IN IP6 FF0E::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).
この例は、<addrtype> "*"ワイルドカードの使用と、IPv6またはIPv4アドレス、あるいはその両方に解決するマルチキャストおよびソースFQDNSとともに示しています。通常、マルチキャストアドレスとソースアドレスの両方が同じ（IPv4または両方のIPv6のいずれか）になりますが、ソースフィルターのAddRTypeのワイルドカードを使用すると、2つのアドレス間の非対称性が可能になります（したがって、IPv4ソースアドレスはIPv6マルチキャストアドレスで使用できます。）。
<session-description>
<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
<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ソースアドレス（ES）が回答に含まれるかについての先験的な知識を持っていません。応答者には、回答に「ソースフィルター」属性を含めることができますが（たとえば、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モデルは、匿名の送信者とあらゆる種類のマルチキャストアプリケーション（多くの人から多くのマルチキャストアプリケーションをサポートしています。ソースフィルターの使用は、一部の（不明または望ましくない）送信者を除外します。
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アドレスを認証に使用することは弱いです。アドレスが動的に割り当てられていることが多く、送信者が送信するデータグラムでソースアドレス（つまり、独自のもの以外の1つを使用する）を「スプーフィング」する可能性があるためです。ただし、適切なルーター構成では、ネットワークに送信される「スプーフィングされた」ソースアドレスの可能性を減らすことができます。具体的には、ボーダールーターは、無効なソースアドレスを持つデータグラムが転送されないようにトラフィックをフィルタリングすることをお勧めします（たとえば、ソースアドレスが非ローカルである場合、ルーターはデータグラムをドロップします）[フィルタリング]。ただし、これは、IPソースアドレスがローカルエリアネットワーク（LAN）でスプーフィングされるのを妨げません。
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-Address>または<Src-List>値のいずれかにFQDNSを使用すると、優れた柔軟性を提供する間接の層が提供されます。ただし、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
連絡先：Ross Finlaysonメール：Finlayson（at）Live555.com電話：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-field"）：属性名：ソースフィルターロングフォーム：ソースフィルタータイプの名前：att-field属性のタイプ：セッションレベルまたはメディアレベルcharset：なし目的：このドキュメントリファレンスを参照：thisドキュメント値：このドキュメントと以下の登録を参照してください
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.
著者は、この文書の実質の多くを入力したDave ThalerとMark Handleyに感謝したいと思います。Magnus Westerlundは、編集中に貴重なフィードバックも提供しました。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D.、ed。および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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP] Handley、M.、Jacobson、V。、およびC. Perkins、「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.
[フィルタリング] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[IGMPv1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[Igmpv1] Deering、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルターのソケットインターフェイス拡張機能」、RFC 3678、2004年1月。
[OFFER] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[オファー] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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] Chesterfield、J.、E。Schooler、J。Ott、「ユニキャストフィードバックを備えたシングルソースマルチキャストセッション用のRTCP拡張」、2004年10月の作業。
[SSM] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[SSM] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
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.
この付録は、1つ以上の（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.
WildCard接続アドレス値「*」が指定されていない限り、各ソースフィルターフィールドの「Dest-Address」値は、既存の接続フィールド値と一致する必要があります。
source-filter = "source-filter" ":" SP filter-mode SP filter-spec
; SP is the ASCII 'space' character
; (0x20, defined in [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].
Filter-spec = netType SPアドレスタイプSP Dest-Address SP SRC-LIST;NetTypeは[SDP]で定義されています。
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].
dest-address = "*" / basic-multicast-address / unicast-address ; "*" applies to all connection-address values. ; unicast-address is as defined in [SDP].
Dest-Address = "*" / Basic-Multicast-Address / Unicast-Address;「*」は、すべての接続アドレス値に適用されます。;ユニキャストアドレスは[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].
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].
basic-IP4-multicast = m1 3( "." decimal-uchar ) ; m1 and decimal-uchar are as defined ; in [SDP].
BASIC-IP4-Multicast = M1 3（ "。" 10進み）;M1と10進みは定義されています。[SDP]で。
basic-IP6-multicast = hexpart ; hexpart is as defined in [SDP].
Basic-IP6-Multicast = Hexpart;Hexpartは[SDP]で定義されています。
Authors' Addresses
著者のアドレス
Bob Quinn BoxnArrow.com 31 Caldwell Road Waltham, MA 02453
Bob Quinn BoxNarrow.com 31 Caldwell Road Waltham、MA 02453
Phone: +1-781-577-1539
EMail: rcq@boxnarrow.com
Ross Finlayson Live Networks, Inc. 650 Castro St., suite 120-196 Mountain View, CA 94041
Ross Finlayson Live Networks、Inc。650 Castro St.、Suite 120-196 Mountain View、CA 94041
EMail: finlayson@live555.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。