Network Working Group G. Camarillo
Request for Comments: 4091 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
The Alternative Network Address Types (ANAT) Semantics
for the Session Description Protocol (SDP) Grouping Framework
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream.
この文書では、フレームワークをグループ化するセッション記述プロトコル（SDP）のための代替ネットワークアドレスタイプ（ANAT）セマンティクスを定義します。 ANATセマンティクスは、ネットワークアドレスの代わりの種類は特定のメディアストリームを確立することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope and Relation with Interactive Connectivity
Establishment. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Offer/Answer and ANAT . . . . . . . . . . . . . . . . . . . . 3
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informational References . . . . . . . . . . . . . . . . 5
A Session Description Protocol (SDP) [2] session description contains the media parameters to be used in establishing a number of media streams. For a particular media stream, an SDP session description contains, among other parameters, the network addresses and the codec to be used in transferring media. SDP allows for a set of codecs per media stream, but only one network address.
セッション記述プロトコル（SDP）[2]セッション記述は、メディアストリームの数を確立する際に使用するメディアパラメータを含んでいます。特定のメディア・ストリームのために、SDPセッション記述は、他のパラメータのうち、ネットワークアドレスおよびコーデックは、メディアの転送に使用されるように、含まれています。 SDPは、メディアストリームあたりのコーデックのセットすることができますが、唯一つのネットワークアドレス。
The ability to offer a set of network addresses to establish a media stream is useful in environments with both IPv4-only hosts and IPv6-only hosts, for instance.
メディアストリームを確立するためにネットワーク・アドレスのセットを提供する能力は、例えば、IPv4専用ホストとIPv6専用ホストの両方の環境において有用です。
This document defines the Alternative Network Address Types (ANAT) semantics for the SDP grouping framework [4]. The ANAT semantics allow for the expression of alternative network addresses (e.g., different IP versions) for a particular media stream.
この文書では、SDPグルーピングフレームワークのための代替ネットワークアドレスタイプ（ANAT）セマンティクスを定義する[4]。 ANATセマンティクスは、特定のメディアストリームのための代替ネットワークアドレス（例えば、異なるIPバージョン）の発現を可能にします。
The ANAT semantics are intended to address scenarios that involve different network address types (e.g., different IP versions). They are not intended to provide alternative transport addresses with the same network type. Systems that need to provide different transport addresses with the same network type should use the SDP format defined in ICE (Interactive Connectivity Establishment) [6] instead.
ANATセマンティクスは異なるネットワーク・アドレス・タイプ（例えば、異なるIPバージョン）を含むシナリオに対処することを意図しています。彼らは、同じネットワークタイプで代替輸送アドレスを提供することを意図していません。同じネットワークタイプの異なるトランスポートアドレスを提供する必要があるシステムでは、代わりに[6] ICE（インタラクティブ接続確立）で定義されたSDPフォーマットを使用しなければなりません。
ICE is used by systems that cannot determine their own transport address as seen from the remote end, but that can provide several possible alternatives. ICE encodes the address that is most likely to be valid in an 'm' line, and the rest of addresses as a= lines after that 'm' line. This way, systems that do not support ICE simply ignore the a= lines and only use the address in the 'm' line. This achieves good backward compatibility.
ICEは、リモート側から見て、独自のトランスポート・アドレスを決定することができないシステムで使用されているが、それはいくつかの可能な選択肢を提供することができます。 ICEは、「M」行の後に=行として「M」行に有効である可能性が最も高いアドレス、およびアドレスの残りの部分をコードしています。この方法では、ICEをサポートしていないシステムでは、単純に、A =行を無視し、唯一の「m」行のアドレスを使用しています。これは良い、下位互換性を実現しています。
We have chosen to group 'm' lines with different IP versions at the 'm' level (ANAT semantics) rather than at the a= level (ICE format) in order to keep the IPv6 syntax free from ICE parameters used for legacy (IPv4) NATs (Network Address Translators). This yields a syntax much closer to vanilla SDP, where IPv6 addresses are defined in their own 'm' line, rather than in parameters belonging to a different 'm' line.
我々は、（従来のために使用さICEパラメータからフリーのIPv6構文を維持するために、「M」レベル（ANATの意味）ではなく、A =レベル（ICE形式）で異なるIPバージョンのグループ「M」線にはIPv4を選択しました）NATの（ネットワークアドレス変換）。これは、IPv6アドレスは、独自の「m」の行ではなく、異なる「m」の行に属するパラメータで定義されているバニラSDP、に非常に近い構文を生成します。
Additionally, ICE only allows us to provide a single primary address when the peer does not support ICE. The ANAT semantics avoid relegating certain types of addresses (e.g., IPv6 addresses) to only be a secondary alternate to another address type (e.g., IPv4 addresses).
また、ICEはピアがICEをサポートしていない、単一のプライマリアドレスを提供することができます。 ANATセマンティクスは、別のアドレスの種類（例えば、IPv4アドレス）に二次的代替であるとアドレスの特定のタイプ（例えば、IPv6アドレス）を格下げ避けます。
Furthermore, the separation between ANAT and ICE helps systems that support IPv4 and IPv6 but that do not need to support ICE (e.g., a multicast server).
さらに、ANATとICE間の分離は、IPv4とIPv6をサポートしているシステムに役立ちますが、それはICE（例えば、マルチキャスト・サーバ）をサポートする必要はありません。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
We define a new "semantics" attribute within the SDP grouping framework [4]: ANAT (Alternative Network Address Types).
私たちは、SDPのグループ化の枠組みの中で、新たな「意味論」の属性を定義する[4]：ANAT（代替ネットワークアドレスタイプ）。
Media lines grouped using ANAT semantics provide alternative network addresses of different types for a single logical media stream. The entity creating a session description with an ANAT group MUST be ready to receive (or send) media over any of the grouped 'm' lines. The ANAT semantics MUST NOT be used to group media streams whose network addresses are of the same type.
ANATセマンティクスを使用してグループ化されたメディア・ラインは、単一の論理的なメディアストリームのために、異なるタイプの代替ネットワークアドレスを提供します。 ANAT基でセッション記述を作成エンティティは、受信（または送信）する準備ができていなければなりませんメディアグルーピング「M」線のいずれかを超えます。 ANATセマンティクスは、そのネットワークアドレスが同じタイプであるグループのメディアストリームに使用してはいけません。
The entity generating a session description may have an order of preference for the alternative network address types offered. The identifiers of the media streams MUST be listed in order of preference in the group line. For example, in the session description in Section 6, the 'm' line with mid=1 has a higher preference than the 'm' line with mid=2.
セッション記述を生成するエンティティは、提供代替ネットワークアドレスタイプのための優先順位を有することができます。メディアストリームの識別子は、グループ行の優先順にリストされなければなりません。例えば、第6のセッション記述において、ミッド= 1「M」線は、中間= 2「M」線よりも高い優先度を有しています。
An offerer using SIP [3] to send its offer SHOULD place the sdp-anat option-tag [5] in a Require header field.
SIPを使用して提供者[3]そのオファーを送信するためには、Requireヘッダーフィールドに[5] SDP-アナトオプションタグを配置する必要があります。
An answerer receiving a session description that uses the ANAT semantics SHOULD use the address with the highest priority it understands and set the ports of the rest of the 'm' lines of the group to zero.
理解の最も優先度の高いアドレスを使用して、ゼロにグループの「M」行の残りのポートを設定すべきであるANATセマンティクスを使用するセッション記述を受信した回答。
The session description below contains an IPv4 address and an IPv6 address grouped using ANAT. The format corresponding to the mapping of ICE into SDP [6] can be used in both 'm' lines to provide additional addresses.
セッション記述は、以下のIPv4アドレスとANATを使用してグループ化されたIPv6アドレスを含んでいます。 SDP [6]にICEのマッピングに対応するフォーマットは、追加のアドレスを提供するために、両方の「M」ラインで使用することができます。
v=0 o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 a=group:ANAT 1 2 m=audio 25000 RTP/AVP 0 c=IN IP6 2001:DB8::1 a= <ICE-encoded additional IPv6 addresses (and ports)> a=mid:1 m=audio 22334 RTP/AVP 0 c=IN IP4 192.0.2.1 a= <ICE-encoded additional IPv4 addresses (and ports)> a=mid:2
V = 0 0 =ボブ280744730 28977631 IN IP4 host.example.com S = T = 0、A =基：ANAT 1 2 M = IP6 2001年オーディオ25000 RTP / AVP 0のC =：DB8 :: 1 A = <ICEエンコードさ追加のIPv6アドレス（およびポート）> A =ミッド：IP4の192.0.2.1のA = <ICE符号化され、追加のIPv4アドレス（およびポート）> A =ミッド中1M =オーディオ22334 RTP / AVP 0のC = 2
An attacker adding group lines, using the ANAT semantics, to an SDP session description could make an end-point use only one out of all the streams offered by the remote end, when the intention of the remote-end might have been to establish all the streams.
リモートエンドの意図はすべてを確立することであったかもしれないときSDPセッション記述に、グループの行を追加ANATセマンティクスを使用して、攻撃者は、リモートエンドが提供するすべてのストリームのうち一つだけのエンドポイントの利用を作ることができますストリーム。
An attacker removing group lines using ANAT semantics could make an end-point establish a higher number of media streams. If the end-point sends media over all of them, the session bandwidth may increase dramatically.
攻撃者は、エンドポイントは、メディアストリームの高い数を確立させることができANATセマンティクスを使用して、グループ行を削除します。エンドポイントは、それらのすべてを介してメディアを送信した場合、セッションの帯域幅が大幅に増加する可能性があります。
It is thus strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [3], S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [3]. Other applications MAY use a different form of integrity protection.
したがって、強く完全性保護がSDPセッション記述に適用されることが推奨されます。 SIPで運ばれるセッション記述は、RFC 3261に記載されているように[3]、S / MIMEは、そのようなエンドツーエンドの完全性保護を提供するために、自然な選択である[3]。他のアプリケーションは、完全性保護の異なる形式を使用するかもしれません。
The IANA has registered the following new 'semantics' attribute for the SDP grouping framework [4]:
IANAはSDPのグループ化の枠組みについて、次の新しい「意味論」属性を登録している[4]：
Semantics Token Reference
--------------------------------- ----- ---------
Alternative Network Address Types ANAT [RFC4091]
ANAT has been registered in the SDP parameters registry under Semantics for the "group" SDP Attribute.
ANATは、「グループ」SDP属性のセマンティクスの下でSDPパラメータレジストリに登録されています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[4]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、RFC 3388、2002年12月。
[5] Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, June 2005.
[5]キャマリロ、G.およびJ.ローゼンバーグ、 "セッション開始プロトコルのセッション記述プロトコルの使用（SDP）の代替ネットワークアドレスタイプ（ANAT）セマンティクス（SIP）"、RFC 4092、2005年6月。
[6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", Work in Progress, February 2005.
[6]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：マルチメディアセッション確立プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための方法論」、進歩、2005年2月に作業。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
EMail: jdrosen@cisco.com
メールアドレス：jdrosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。