RFC4091 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 4091                                      Ericsson
Category: Standards Track                                   J. Rosenberg
                                                           Cisco Systems
                                                               June 2005

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 4091年のエリクソンカテゴリ: 標準化過程J.ローゼンバーグシスコシステムズ2005年6月

         The Alternative Network Address Types (ANAT) Semantics
     for the Session Description Protocol (SDP) Grouping Framework

代替のネットワーク・アドレスはセッション記述プロトコル(SDP)組分けフレームワークのために(ANAT)意味論をタイプします。

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 (2005).

Copyright(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.

このドキュメントはSession記述プロトコル(SDP)組分けフレームワークのためにAlternative Network Address Types(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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 対話的な接続性設立との範囲と関係。 . . . . . . . . . . . . . . . . . . . . . 2 2. 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 ANAT意味論. . . . . . . . . . . . . . . . . . . . . . . . 3 4。 好み. . . . . . . . . . . . . . . . . . . . . . . . . . 3 5。 申し出/答えとANAT. . . . . . . . . . . . . . . . . . . . 3 6。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 4 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 5 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1。 引用規格. . . . . . . . . . . . . . . . . . 5 9.2。 情報の参照. . . . . . . . . . . . . . . . 5

Camarillo & Rosenberg       Standards Track                     [Page 1]

RFC 4091                     ANAT Semantics                    June 2005

キャマリロとローゼンバーグStandardsはANAT意味論2005年6月にRFC4091を追跡します[1ページ]。

1.  Introduction

1. 序論

   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.

Session記述プロトコル(SDP)[2]セッション記述は多くのメディアストリームを確立する際に使用されるべきメディアパラメタを含んでいます。特定のメディアストリームのために、SDPセッション記述は他のパラメタの中にメディアを移す際に使用されるべきネットワーク・アドレスとコーデックを含んでいます。 SDPは1セットのメディアストリームあたりのコーデック、しかし、1つのネットワーク・アドレスだけを考慮します。

   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だけホストの両方によって、メディアストリームを証明するために1セットのネットワーク・アドレスを提供する能力は環境で役に立ちます。

   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.

このドキュメントはフレームワーク[4]を分類するSDPのためにAlternative Network Address Types(ANAT)意味論を定義します。 ANAT意味論は特定のメディアストリームに関して代替のネットワーク・アドレスの式(例えば、異なったIPバージョン)を考慮します。

1.1.  Scope and Relation with Interactive Connectivity Establishment

1.1. 対話的な接続性設立との範囲と関係

   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(対話的なConnectivity特権階級)で定義された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が中で有効である最も傾向があるアドレスをコード化する、'系列、およびそれが'系列になった後に=系列としてのアドレスの残りはそうです。 'この道、単にICEをサポートしないシステムがa=系列を無視して、中でアドレスを使用するだけである、'立ち並んでください。 これは良い後方の互換性を獲得します。

   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.

'私たちがそうした、'分類するために選ばれているのが、異なったIPバージョンがある系列である、'レガシー(IPv4)NATs(ネットワークAddress Translators)に使用されるICEパラメタから自由にIPv6構文を保つためにaでレベル(ICE形式)と等しいというよりもむしろ(ANAT意味論)を平らにしてください。 IPv6アドレスが'それら自身ので定義されているのが、aへのパラメタで属しているよりむしろ系列であるということであるところでは、'これははるかに近くでバニラ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アドレス)を左遷するのを避けます。

Camarillo & Rosenberg       Standards Track                     [Page 2]

RFC 4091                     ANAT Semantics                    June 2005

キャマリロとローゼンバーグStandardsはANAT意味論2005年6月にRFC4091を追跡します[2ページ]。

   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が(例えば、マルチキャストサーバ)であるとサポートする必要はないシステムを助けます。

2.  Terminology

2. 用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。

3.  ANAT Semantics

3. ANAT意味論

   We define a new "semantics" attribute within the SDP grouping
   framework [4]: ANAT (Alternative Network Address Types).

私たちはフレームワーク[4]を分類するSDPの中で新しい「意味論」属性を定義します: 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グループと共にセッション記述を作成する実体は分類のどれかの上にメディアを受け取る準備ができているのが(発信してください)、'系列であるということであるに違いありません。 同じタイプにはネットワーク・アドレスがあるメディアストリームを分類するのにANAT意味論を使用してはいけません。

4.  Preference

4. 好み

   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がある系列には、より高い優先があるということである、'中間の=2がある系列です。

5.  Offer/Answer and ANAT

5. 申し出/答えとANAT

   An offerer using SIP [3] to send its offer SHOULD place the sdp-anat
   option-tag [5] in a Require header field.

Requireヘッダーフィールドにおけるsdp-anatオプションタグ[5]を申し出SHOULD場所に送るのにSIP[3]を使用している申出人。

   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.

'answererがSHOULDがそれが理解している最優先があるアドレスを使用して、残りのポートを設定するANAT意味論を使用するセッション記述を受ける、'ゼロへのグループの系列はそうです。

Camarillo & Rosenberg       Standards Track                     [Page 3]

RFC 4091                     ANAT Semantics                    June 2005

キャマリロとローゼンバーグStandardsはANAT意味論2005年6月にRFC4091を追跡します[3ページ]。

6.  Example

6. 例

   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に関するマッピングに対応する形式は、追加アドレスを提供するためには両方で使用されているのが、'系列であるということであるかもしれません。

      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

ボブの280744730 28977631IN v=0o=IP4 host.example.com s=tは=グループあたり0 0と等しいです: ANAT1 2mがオーディオの25000RTP/AVPと等しい、0、c、IN IP6 2001: =DB8:、:=<ICEによってコード化された追加IPv6あたり1が: 1mの=中間の=オーディオの22334RTP/AVPを>に扱う、(そして、ポート)0、c、=IN IP4、192.0、.2、.1、=<ICEによってコード化された追加IPv4はa=中間で>を扱います(そして、ポート):、2

7.  Security Considerations

7. セキュリティ問題

   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.

ANAT意味論を使用して、グループ系列を加えている攻撃者はエンドポイントにすべてのストリームを確立するリモートエンドの意志がことであったかもしれないリモート終わりまでに提供されたすべてのストリームから1つしかSDPセッション記述に使用させることができませんでした。

   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.

その結果、強く、保全保護をあるRECOMMENDEDは、申し込みました。それがそうである、SDPセッション記述。 SIP[3]で運ばれたセッション記述のために、S/MIMEは終わりから終わりへの保全そのような保護を提供する自然な選択です、RFC3261[3]で説明されるように。 他のアプリケーションは異なった形式の保全保護を使用するかもしれません。

Camarillo & Rosenberg       Standards Track                     [Page 4]

RFC 4091                     ANAT Semantics                    June 2005

キャマリロとローゼンバーグStandardsはANAT意味論2005年6月にRFC4091を追跡します[4ページ]。

8.  IANA Considerations

8. IANA問題

   The IANA has registered the following new 'semantics' attribute for
   the SDP grouping framework [4]:

IANAはフレームワーク[4]を分類するSDPのために以下の新しい'意味論'属性を示しました:

   Semantics                            Token      Reference
   ---------------------------------    -----      ---------
   Alternative Network Address Types    ANAT       [RFC4091]

意味論トークン参照--------------------------------- ----- --------- 代替のネットワーク・アドレスはANATをタイプします。[RFC4091]

   ANAT has been registered in the SDP parameters registry under
   Semantics for the "group" SDP Attribute.

ANATは「グループ」SDP AttributeのためにSemanticsの下のSDPパラメタ登録に登録されました。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

[2] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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)で立ち並んでいます」、RFC3388、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)意味論をタイプします」、RFC4092、2005年6月。

9.2.  Informative References

9.2. 有益な参照

   [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.、「対話的な接続性設立(氷):」 「マルチメディアセッション設立プロトコルのためのネットワークアドレス変換機構(NAT)縦断のための方法論」、処理中の作業、2005年2月。

Camarillo & Rosenberg       Standards Track                     [Page 5]

RFC 4091                     ANAT Semantics                    June 2005

キャマリロとローゼンバーグStandardsはANAT意味論2005年6月にRFC4091を追跡します[5ページ]。

Authors' Addresses

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)

   EMail: jdrosen@cisco.com

メール: jdrosen@cisco.com

Camarillo & Rosenberg       Standards Track                     [Page 6]

RFC 4091                     ANAT Semantics                    June 2005

キャマリロとローゼンバーグStandardsはANAT意味論2005年6月にRFC4091を追跡します[6ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントは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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Camarillo & Rosenberg       Standards Track                     [Page 7]

キャマリロとローゼンバーグ標準化過程[7ページ]