Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6157 Ericsson
Updates: 3264 K. El Malki
Category: Standards Track Athonet
ISSN: 2070-1721 V. Gurbani
Bell Labs, Alcatel-Lucent
April 2011
IPv6 Transition in the Session Initiation Protocol (SIP)
Abstract
抽象
This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered.
この文書は、セッションが正常に設定された後のIPv4セッション開始プロトコル（SIP）ユーザエージェントは、シグナリング層並びに交換媒体でのIPv6 SIPユーザエージェント（およびその逆）と通信することができる方法について説明します。両方のシングルおよびデュアルスタック（すなわち、IPv4のみとIPv4 / IPv6）のユーザエージェントが考慮されます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6157.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6157で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Signaling Layer . . . . . . . . . . . . . . . . . . . . . 4
3.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Relaying Requests across Different Networks . . . . . 5
3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7
4. The Media Layer . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Updates to RFC 3264 . . . . . . . . . . . . . . . . . . . 9
4.2. Initial Offer . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10
5. Contacting Servers: Interaction of RFC 3263 and RFC 3484 . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Sample IPv4/IPv6 DNS File . . . . . . . . . . . . . . 14
SIP [3] is a protocol to establish and manage multimedia sessions. After the exchange of signaling messages, SIP endpoints generally exchange session or media traffic, which is not transported using SIP but a different protocol. For example, audio streams are typically carried using the Real-Time Transport Protocol (RTP) [13].
SIP [3]マルチメディアセッションを確立し、管理するためのプロトコルです。シグナリングメッセージの交換後、SIPエンドポイントは、一般に、SIPが、異なるプロトコルを使用して搬送されていないセッション又はメディアトラフィックを交換します。例えば、オーディオストリームは、典型的には、リアルタイムトランスポートプロトコル（RTP）[13]を使用して実施されます。
Consequently, a complete solution for IPv6 transition needs to handle both the signaling layer and the media layer. While unextended SIP can handle heterogeneous IPv6/IPv4 networks at the signaling layer as long as proxy servers and their Domain Name System (DNS) entries are properly configured, user agents using different networks and address spaces must implement extensions in order to exchange media between them.
これにより、IPv6への移行のための完全なソリューションは、シグナリング層と媒体層の両方を処理する必要があります。未伸長SIPは限りプロキシサーバとそのドメインネームシステム（DNS）のエントリが正しく設定されているとして、シグナリング層で異種のIPv6 / IPv4ネットワークを扱うことができますが、異なるネットワークとアドレス空間を使用して、ユーザーエージェントは、それらの間でメディアを交換するために拡張機能を実装する必要があります。
This document addresses the system-level issues in order to make SIP work successfully between IPv4 and IPv6. Sections 3 and 4 provide discussions on the topics that are pertinent to the signaling layer and media layer, respectively, to establish a successful session between heterogeneous IPv4/IPv6 networks.
この文書では、成功したIPv4とIPv6の間でSIPを動作させるために、システムレベルの問題に対処します。セクション3と4は、異種のIPv4 / IPv6ネットワークの間の成功したセッションを確立するために、それぞれ、シグナリング層と媒体層に関連しているトピックに関する議論を提供します。
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に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
IPv4-only user agent: An IPv4-only user agent supports SIP signaling and media only on the IPv4 network. It does not understand IPv6 addresses.
IPv4のみのユーザーエージェント：IPv4のみのユーザエージェントは、IPv4ネットワーク上のSIPシグナリングおよびメディアをサポートしています。これは、IPv6アドレスを理解していません。
IPv4-only node: A host that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts existing before the transition begins are IPv4-only nodes.
IPv4のみのノード：IPv4のみを実装したホスト。 IPv4のみのノードがIPv6を理解していません。移行を開始する前に既存のIPv4ホストのインストールベースはIPv4専用ノードです。
IPv6-only user agent: An IPv6-only user agent supports SIP signaling and media only on the IPv6 network. It does not understand IPv4 addresses.
IPv6のみのユーザーエージェント：IPv6のみのユーザエージェントはIPv6ネットワーク上のSIPシグナリングおよびメディアをサポートしています。これは、IPv4アドレスを理解していません。
IPv6-only node: A host that implements IPv6 and does not implement IPv4.
IPv6のみのノード：IPv6を実装し、IPv4を実装していないホスト。
IPv4/IPv6 node: A host that implements both IPv4 and IPv6; such hosts are also known as "dual-stack" hosts [17].
IPv4 / IPv6ノード：IPv4とIPv6の両方を実装するホスト。そのようなホストは、「デュアルスタック」ホスト[17]として知られています。
IPv4/IPv6 user agent: A user agent that supports SIP signaling and media on both IPv4 and IPv6 networks.
IPv4 / IPv6のユーザエージェント：IPv4とIPv6ネットワークの両方でSIPシグナリングとメディアをサポートするユーザエージェント。
IPv4/IPv6 proxy: A proxy that supports SIP signaling on both IPv4 and IPv6 networks.
IPv4 / IPv6のプロキシ：IPv4とIPv6の両方のネットワーク上のSIPシグナリングをサポートするプロキシ。
An autonomous domain sends and receives SIP traffic to and from its user agents as well as to and from other autonomous domains. This section describes the issues related to such traffic exchanges at the signaling layer, i.e., the flow of SIP messages between participants in order to establish the session. We assume that the network administrators appropriately configure their networks such that the
自律ドメインは、にしてから、そのユーザーエージェントだけでなく、他の自律ドメインにしてからSIPトラフィックを送受信します。このセクションでは、セッションを確立するために、シグナリング層、すなわち、参加者間のSIPメッセージの流れにおけるこのようなトラフィックエクスチェンジに関連する問題を記載しています。私たちは、ネットワーク管理者が適切に自社のネットワークを構成することを前提とし、その結果
SIP servers within an autonomous domain can communicate between themselves. This section contains system-level issues; a companion document [15] addresses IPv6 parser torture tests in SIP.
自律ドメイン内のSIPサーバは、自分たちの間で通信を行うことができます。このセクションでは、システムレベルの問題が含まれています。仲間ドキュメント[15]はSIPでのIPv6パーサー拷問テストに対応しています。
User agents typically send SIP traffic to an outbound proxy, which takes care of routing it forward. In order to support both IPv4-only and IPv6-only user agents, it is RECOMMENDED that domains deploy dual-stack outbound proxy servers or, alternatively, deploy both IPv4-only and IPv6-only outbound proxies. Furthermore, there SHOULD exist both IPv6 and IPv4 DNS entries for outbound proxy servers. This allows the user agent to query DNS and obtain an IP address most appropriate for its use (i.e., an IPv4-only user agent will query DNS for A resource records (RRs), an IPv6-only user agent will query DNS for AAAA RRs, and a dual-stack user agent will query DNS for all RRs and choose a specific network.)
ユーザーエージェントは、一般的にそれを前方にルーティングするの面倒をアウトバウンドプロキシにSIPトラフィックを送信します。両方のIPv4のみとIPv6専用のユーザエージェントをサポートするためには、ドメインがデュアルスタックアウトバウンドプロキシサーバを展開する、あるいは、両方のIPv4専用とIPv6専用アウトバウンドプロキシを展開することが推奨されます。さらに、アウトバウンドプロキシサーバのIPv6とIPv4 DNSの両方のエントリが存在している必要があります。これは（すなわち、IPv4のみのユーザエージェントがリソースレコードをDNSに照会します（RRS）、IPv6のみのユーザエージェントは、AAAA RRのためにDNSを照会しますユーザエージェントがDNSを照会し、その使用のために最も適切なIPアドレスを取得することができます、およびデュアルスタックユーザエージェントはすべてのRRのためにDNSを照会し、特定のネットワークを選択します。）
Some domains provide automatic means for user agents to discover their proxy servers. It is RECOMMENDED that domains implement appropriate discovery mechanisms to provide user agents with the IPv4 and IPv6 addresses of their outbound proxy servers. For example, a domain may support both the DHCPv4 [11] and the DHCPv6 [10] options for SIP servers.
いくつかのドメインは、そのプロキシサーバを発見するユーザエージェントの自動手段を提供します。ドメインがそのアウトバウンドプロキシサーバのIPv4アドレスとIPv6アドレスとユーザーエージェントを提供するために、適切な検出メカニズムを実装することをお勧めします。例えば、ドメインは、SIPサーバのためのDHCPv4 [11]とDHCPv6 [10]オプションの両方をサポートすることができます。
On the receiving side, user agents inside an autonomous domain receive SIP traffic from sources external to their domain through an inbound proxy, which is sometimes co-located with the registrar of the domain. As was the case previously, it is RECOMMENDED that domains deploy dual-stack inbound proxies or, alternatively, deploy both IPv4-only and IPv6-only inbound proxy servers. This allows a user agent external to the autonomous domain to query DNS and receive an IP address of the inbound proxy most appropriate for its use (i.e., an IPv4-only user agent will query DNS for A RRs, an IPv6-only user agent will query DNS for AAAA RRs, and a dual-stack user agent will query DNS for all RRs and choose a specific network). This strategy, i.e., deploying dual-stack proxies, also allows for an IPv6-only user agent in the autonomous domain to communicate with an IPv4-only user agent in the same autonomous domain. Without such a proxy, user agents using different networks identifiers will not be able to successfully signal each other.
受信側では、自律ドメイン内のユーザエージェントは、時にはドメインのレジストラと同じ場所に配置されるインバウンドプロキシを通じてドメインの外部ソースからのSIPトラフィックを受信します。以前にそうであったように、ドメインは、代替的に、両方のIPv4専用展開とIPv6専用インバウンドプロキシサーバ、デュアルスタックインバウンドプロキシを展開したりすることを推奨されます。これは、IPv6のみのユーザエージェント、（すなわち、IPv4のみのユーザエージェントは、RRのためのDNSを照会しますDNSを照会し、その使用のために最も適切なインバウンドプロキシのIPアドレスを受信するように自律ドメインへのユーザーエージェントは、外部のだろうことができますAAAA RRのためのクエリのDNS、およびデュアルスタックユーザエージェント）は、すべてのRRのためにDNSを照会し、特定のネットワークを選択します。この戦略は、すなわち、デュアルスタックプロキシを展開、また、同じ自律ドメイン内のIPv4専用ユーザエージェントと通信する自律ドメイン内のIPv6専用ユーザエージェントを可能にします。そのようなプロキシなしで、異なるネットワーク識別子を使用して、ユーザエージェントが正常にお互いをシグナリングすることができません。
Proxies MUST follow the recommendations in Section 5 to determine the order in which to contact the downstream servers when routing a request.
プロキシは、要求をルーティングするとき下流サーバーに接続する順序を決定する第5の推奨に従わなければなりません。
A SIP proxy server that receives a request using IPv6 and relays it to a user agent (or another downstream proxy) using IPv4, and vice versa, needs to remain in the path traversed by subsequent requests. Therefore, such a SIP proxy server MUST be configured to Record-Route in that situation.
IPv4を使用してIPv6を使用して要求を受信し、ユーザエージェント（または他の下流のプロキシ）にそれを中継するSIPプロキシサーバ、およびその逆は、後続の要求が横断する経路に留まる必要があります。したがって、そのようなSIPプロキシサーバは、その状況にレコードルートに設定する必要があります。
Note that while this is the recommended practice, some problems may still arise if an RFC 2543 [14] endpoint is involved in signaling. Since the ABNF in RFC 2543 did not include production rules to parse IPv6 network identifiers, there is a good chance that an RFC 2543-only compliant endpoint is not able to parse or regenerate IPv6 network identifiers in headers. Thus, despite a dual-stack proxy inserting itself into the session establishment, the endpoint itself may not succeed in the signaling establishment phase.
これはお勧めであるRFC 2543 [14]エンドポイントがシグナル伝達に関与している場合、いくつかの問題が依然として生じ得ることに留意されたいです。 RFC 2543でのABNFは、IPv6ネットワーク識別子を解析するために、生産ルールが含まれていなかったので、RFC 2543のみの対応エンドポイントが解析またはヘッダーでIPv6ネットワーク識別子を再生成することができないことを良いチャンスがあります。従って、セッション確立に自身を挿入デュアルスタックプロキシにもかかわらず、エンドポイント自体は、シグナリング確立フェーズに成功しないかもしれません。
This is generally not a problem with RFC 3261 endpoints; even if such an endpoint runs on an IPv4-only node, it still is able to parse and regenerate IPv6 network identifiers.
これは、一般的にRFC 3261のエンドポイントの問題ではありません。そのようなエンドポイントがIPv4のみのノードで実行されている場合でも、まだIPv6ネットワーク識別子を解析し、再生することが可能です。
Relaying a request across different networks in this manner has other ramifications. For one, the proxy doing the relaying must remain in the signaling path for the duration of the session; otherwise, the upstream client and the downstream server would not be able to communicate directly. Second, to remain in the signaling path, the proxy MUST insert one or two Record-Route headers: if the proxy is inserting a URI that contains a Fully Qualified Domain Name (FQDN) of the proxy, and that name has both IPv4 and IPv6 addresses in DNS, then inserting one Record-Route header suffices. But if the proxy is inserting an IP address in the Record-Route header, then it must insert two such headers; the first Record-Route header contains the proxy's IP address that is compatible with the network type of the downstream server, and the second Record-Route header contains the proxy's IP address that is compatible with the upstream client.
このように、異なるネットワーク間で要求を中継することは、他の波及効果を持っています。一つは、中継を行うプロキシは、セッションの間シグナリングパスに残っている必要があります。そうでない場合は、上流側クライアントと下流サーバは直接通信することができないだろう。第二、シグナリングパスに留まる、プロキシは、1つまたは2つのRecord-Routeヘッダを挿入しなければならない：プロキシは、プロキシの完全修飾ドメイン名（FQDN）が含まれているURIを挿入し、その名前は、IPv4とIPv6の両方を有する場合DNSのアドレスは、その後、一つのレコードルートヘッダが十分で挿入します。プロキシがRecord-Routeヘッダ内のIPアドレスを挿入している場合は、それは二つのそのようなヘッダを挿入する必要があります。最初のRecord-Routeヘッダには、下流サーバのネットワークタイプと互換性があるプロキシのIPアドレスを含み、第二Record-Routeヘッダは、上流側のクライアントに対応しているプロキシのIPアドレスを含みます。
An example helps illustrate this behavior. In the example, we use only those headers pertinent to the discussion. Other headers have been omitted for brevity. In addition, only the INVITE request and final response (200 OK) are shown; it is not the intent of the example to provide a complete call flow that includes provisional responses and other requests.
例では、この動作を説明するのに役立ちます。例では、我々は議論に関連するものだけヘッダーを使用します。他のヘッダは簡潔にするために省略されています。加えて、唯一のINVITE要求と最終応答（200 OK）が示されています。暫定応答および他の要求を含む完全なコールフローを提供するために、例の意図ではありません。
In this example, proxy P, responsible for the domain example.com, receives a request from an IPv4-only upstream client. It proxies this request to an IPv6-only downstream server. Proxy P is running on a dual-stack host; on the IPv4 interface, it has an address of
この例では、プロキシPは、ドメインexample.comの責任、IPv4専用上流クライアントからの要求を受信します。これは、IPv6のみの下流のサーバにこの要求をプロキシ。プロキシPは、デュアルスタックホスト上で実行されています。 IPv4インタフェース上で、それはのアドレスを持っています
192.0.2.1, and on the IPv6 interface, it is configured with an address of 2001:db8::1 (Appendix A contains a sample DNS zone file entry that has been populated with both IPv4 and IPv6 addresses.)
192.0.2.1、およびIPv6インタフェース上で、それは2001アドレスが設定されている：DB8 :: 1（付録Aは、IPv4およびIPv6アドレスの両方が移入されたサンプルDNSゾーンファイルのエントリを含みます。）
UAC Proxy UAS
(IPv4) P (IPv6)
| (IPv4/IPv6) |
| | |
+---F1--------->| |
| +---F2-------->|
| | |
| |<--F3---------+
|<--F4----------+ |
... ... ...
| | |
V V V
F1: INVITE sip:alice@example.com SIP/2.0 ...
F1：SIP INVITE：alice@example.com SIP / 2.0を...
F2: INVITE sip:alice@2001:db8::10 SIP/2.0 Record-Route: <sip:2001:db8::1;lr> Record-Route: <sip:192.0.2.1;lr> ...
F2：2001 @アリス：SIPのINVITE DB8 :: 10 SIP / 2.0レコードルート<SIP：2001：DB8 :: 1; LR>レコードルート<SIP：192.0.2.1; LR> ...
F3: SIP/2.0 200 OK Record-Route: <sip:2001:db8::1;lr> Record-Route: <sip:192.0.2.1;lr> ...
F3：SIP / 2.0 200 OK録音-ルート：<SIP：2001：DB8 :: 1; LR>レコード・ルート：<SIP：192.0.2.1; LR> ...
F4: SIP/2.0 200 OK Record-Route: <sip:2001:db8::1;lr> Record-Route: <sip:192.0.2.1;lr> ...
F4：SIP / 2.0 200 OK録音-ルート：<SIP：2001：DB8 :: 1; LR>レコード・ルート：<SIP：192.0.2.1; LR> ...
Figure 1: Relaying requests across different networks
図1：異なるネットワーク間の中継を要求
When the User Agent Server (UAS) gets an INVITE and it accepts the invitation, it sends a 200 OK (F3) and forms a route set. The first entry in its route set corresponds to the proxy's IPv6 interface. Similarly, when the 200 OK reaches the User Agent Client (UAC) (F4), it creates a route set by following the guidelines of RFC 3261 and reversing the Record-Route headers. The first entry in its route set corresponds to the proxy's IPv4 interface. In this manner, both the UAC and the UAS will have the correct address of the proxy to which they can target subsequent requests.
ユーザエージェントサーバ（UAS）がINVITEを取得し、それが招待を受け入れると、それは200 OK（F3）を送信し、ルートセットを形成しています。そのルートセットの最初のエントリは、プロキシのIPv6インタフェースに対応しています。 200 OKは、ユーザエージェントクライアント（UAC）（F4）に達すると同様に、それはRFC 3261のガイドラインに従うとRecord-Routeヘッダを逆にすることによって設定された経路を作成します。そのルートセット内の最初のエントリは、プロキシのIPv4インタフェースに対応します。このように、UACとUASの両方は、彼らが後続の要求をターゲットにすることができますするプロキシの正しいアドレスを持つことになります。
Alternatively, the proxy could have inserted its FQDN in the Record-Route URI and the result would have been the same. This is because the proxy has both IPv4 and IPv6 addresses in the DNS; thus, the URI resolution would have yielded an IPv4 address to the UAC and an IPv6 address to the UAS.
また、プロキシはレコード・ルートURIでそのFQDNが挿入されている可能性があり、結果は同じだっただろう。プロキシがDNSでのIPv4アドレスとIPv6アドレスの両方を持っているためです。従って、URI分解能はUACとUASにIPv6アドレスにIPv4アドレスをもたらしたであろう。
User agent clients MUST follow the normative text specified in Section 4.2 to gather IP addresses pertinent to the network. Having done that, clients MUST follow the recommendations in Section 5 to determine the order of the downstream servers to contact when routing a request.
ユーザー・エージェント・クライアントは、ネットワークに関連するIPアドレスを収集するために、4.2節で指定された規範的なテキストに従わなければなりません。それをやった、クライアントが要求をルーティングするときに連絡するダウンストリームサーバーの順序を決定するために第5節の推奨事項に従わなければなりません。
Autonomous domains SHOULD deploy dual-stack user agent servers, or alternatively, deploy both IPv4-only and IPv6-only servers. In either case, the RR in DNS for reaching the server should be specified appropriately.
自律ドメインは、デュアルスタックユーザエージェントサーバを配備するか、あるいは、両方のIPv4のみとIPv6専用のサーバーを展開する必要があります。いずれの場合においても、サーバに到達するためのDNSにRRを適切に指定されなければなりません。
SIP establishes media sessions using the offer/answer model [4]. One endpoint, the offerer, sends a session description (the offer) to the other endpoint, the answerer. The offer contains all the media parameters needed to exchange media with the offerer: codecs, transport addresses, protocols to transfer media, etc.
SIPは、オファー/アンサーモデルを使用してメディアセッションを確立します[4]。一方のエンドポイント、オファー側は、他のエンドポイント、回答にセッション記述（提供）を送信します。コーデック、トランスポート・アドレス、メディアなどを転送するためのプロトコル：オファーはすべてのメディア提供者でメディアを交換するために必要なパラメータが含まれています
When the answerer receives an offer, it elaborates an answer and sends it back to the offerer. The answer contains the media parameters that the answerer is willing to use for that particular session. Offer and answer are written using a session description protocol. The most widespread protocol to describe sessions at present is called, aptly enough, the Session Description Protocol (SDP) [2].
回答を提示申し出を受けたとき、それは答えを詳しく説明し、オファー側に送り返します。答えは、回答がその特定のセッションで使用して喜んでメディアパラメータが含まれています。オファーとの回答は、セッション記述プロトコルを使用して書かれています。現在のセッションを記述するための最も普及したプロトコルは、[2]、適切に十分に、セッション記述プロトコル（SDP）と呼ばれます。
A direct offer/answer exchange between an IPv4-only user agent and an IPv6-only user agent does not result in the establishment of a session. The IPv6-only user agent wishes to receive media on one or more IPv6 addresses, but the IPv4-only user agent cannot send media to these addresses, and generally does not even understand their format. Consequently, user agents need a means to obtain both IPv4 and IPv6 addresses to receive media and to place them in offers and answers.
IPv4のみのユーザエージェントとIPv6のみのユーザエージェントとの間の直接のオファー/アンサー交換は、セッションの確立にはなりません。 IPv6のみのユーザエージェントは、一の以上のIPv6アドレスにメディアを受信したいが、IPv4のみのユーザエージェントは、これらのアドレスにメディアを送信することはできません、と一般的にも、その形式を理解していません。その結果、ユーザエージェントは、IPv4とIPv6の両方がメディアを受信し、オファーとアンサーにそれらを配置するアドレスを取得するための手段を必要としています。
This IP version incompatibility problem would not exist if hosts implementing IPv6 also implemented IPv4, and were configured with both IPv4 and IPv6 addresses. In such a case, a UA would be able to pick a compatible media transport address type to enable the hosts to communicate with each other.
ホストはまた、IPv4の実装IPv6を実装し、IPv4とIPv6アドレスの両方で構成されている場合、このIPバージョン非互換性の問題は存在しません。このような場合、UAは、互いに通信するホストを可能にするために、互換性のあるメディアトランスポート・アドレス・タイプを選択することができるであろう。
Pragmatism dictates that IPv6 user agents undertake the greater burden in the transition period. Since IPv6 user agents are not widely deployed yet, it seems appropriate that IPv6 user agents obtain IPv4 addresses instead of mandating an upgrade on the installed IPv4 base. Furthermore, IPv6 user agents are expected to be dual-stacked and thus also support IPv4, unlike the larger IPv4- only user agent base that does not or cannot support IPv6.
プラグマティズムは、IPv6ユーザエージェントは、移行期間中に大きな負担を引き受けることを決定します。 IPv6ユーザエージェントは広くまだ展開されていないので、IPv6ユーザエージェントは、IPv4が代わりにインストールされたIPv4ベースのアップグレードを義務付けるのアドレスが得られることが適切と思われます。また、IPv6のユーザエージェントは、デュアルスタックさ、ひいてはないか、IPv6をサポートできない大きいIPv4-のみユーザエージェントベースとは異なり、のIPv4をサポートすることが期待されます。
An IPv6 node SHOULD also be able to send and receive media using IPv4 addresses, but if it cannot, it SHOULD support Session Traversal Utilities for NAT (STUN) relay usage [8]. Such a relay allows the IPv6 node to indirectly send and receive media using IPv4.
IPv6ノードはまた、IPv4アドレスを使用してメディアを送信および受信することができるはずですが、それができない場合は、[8]を使用リレーNATため（STUN）のセッショントラバーサルユーティリティをサポートしなければなりません。そのようなリレーは、IPv6ノードが間接的にIPv4を使用してメディアを送受信することを可能にします。
The advantage of this strategy is that the installed base of IPv4 user agents continues to function unchanged, but it requires an operator that introduces IPv6 to provide additional servers for allowing IPv6 user agents to obtain IPv4 addresses. This strategy may come at an additional cost to SIP operators deploying IPv6. However, since IPv4-only SIP operators are also likely to deploy STUN relays for NAT (Network Address Translator) traversal, the additional effort to deploy IPv6 in an IPv4 SIP network should be limited in this aspect.
この戦略の利点は、IPv4ユーザエージェントのインストールベースが変化しない機能し続けることであるが、それは、IPv6ユーザエージェントは、IPv4アドレスを取得することを可能にするための追加のサーバーを提供するために、IPv6を導入するオペレータを必要とします。この戦略は、IPv6を導入する事業者をSIPへの追加コストで来るかもしれません。 IPv4専用のSIPオペレータはまた、NAT（ネットワークアドレス翻訳）トラバーサルのためのSTUNリレーを展開する可能性があるので、IPv4のSIPネットワークでIPv6を展開するための追加の努力は、この点に限定されるべきです。
However, there will be deployments where an IPv4/IPv6 node is unable to use both interfaces natively at the same time, and instead, runs as an IPv6-only node. Examples of such deployments include:
ただし、のIPv4 / IPv6ノードが同時にネイティブ両方のインターフェイスを使用することができず、その代わりに、IPv6専用ノードとして動作します。展開が存在するであろうそのような展開の例としては、
1. Networks where public IPv4 addresses are scarce and it is preferable to make large deployments only on IPv6.
パブリックIPv4アドレスが不足していると、IPv6のみの大規模な導入を行うことが望ましい1.ネットワーク。
2. Networks utilizing Layer-2's that do not support concurrent IPv4 and IPv6 usage on the same link.
同じリンク上でIPv4とIPv6の並行使用をサポートしていないレイヤ2の者を利用2.ネットワーク。
This section provides a normative update to RFC 3264 [4] in the following manner:
このセクションは、以下のようにRFC 3264 [4]に規定更新を提供します。
1. In some cases, especially those dealing with third party call control (see Section 4.2 of [12]), there arises a need to specify the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in the SDP offer. For this, IPv6 implementations MUST use a domain name within the .invalid DNS top-level domain instead of using the IPv6 unspecified address (i.e., ::).
いくつかの場合において、第三者呼制御を扱う特に（[12]のセクション4.2を参照）、SDPオファーにIPv4の未指定アドレス（0.0.0.0）のIPv6の当量を指定する必要が生じます。 :)このため、IPv6実装は、IPv6未指定アドレス（すなわちを使用して代わりの.invalid DNSトップレベル・ドメイン内のドメイン名を使用しなければなりません。
2. Each media description in the SDP answer MUST use the same network type as the corresponding media description in the offer. Thus, if the applicable "c=" line for a media description in the offer contained a network type with the value "IP4", the applicable "c=" line for the corresponding media description in the answer MUST contain "IP4" as the network type. Similarly, if the applicable "c=" line for a media description in the offer contained a network type with the value "IP6", the applicable "c=" line for the corresponding media description in the answer MUST contain "IP6" as the network type.
SDPアンサー内2.各メディア記述は、オファー内の対応するメディア記述と同じネットワークタイプを使用しなければなりません。従って、オファー内のメディア記述に適用可能な「C =」行はれる「IP4」を含まなければならない値「IP4」とのネットワークタイプ、回答に対応するメディア記述に適用可能な「C =」行が含まれている場合ネットワーク型。同様に、オファー内のメディア記述に適用可能な「C =」行はれる「IP6」を含まなければならない値「IP6」とのネットワークタイプ、回答に対応するメディア記述に適用可能な「C =」行が含まれている場合ネットワーク型。
We now describe how user agents can gather addresses by following the Interactive Connectivity Establishment (ICE) [7] procedures. ICE is protocol that allows two communicating user agents to arrive at a pair of mutually reachable transport addresses for media communications in the presence of NATs. It uses the STUN [18] protocol, applying its binding discovery and relay usages.
私たちは今、ユーザエージェントがインタラクティブ接続確立（ICE）[7]の手順に従って、アドレスを収集する方法について説明します。 ICEは、2つの通信ユーザエージェントはNATの存在下でのメディア通信のために相互に到達可能なトランスポート・アドレスのペアに到達することを可能にするプロトコルです。これは、その結合発見及びリレー用途を適用して、STUN [18]プロトコルを使用します。
When following the ICE procedures, in addition to local addresses, user agents may need to obtain addresses from relays; for example, an IPv6 user agent would obtain an IPv4 address from a relay. The relay would forward the traffic received on this IPv4 address to the user agent using IPv6. Such user agents MAY use any mechanism to obtain addresses in relays, but, following the recommendations in ICE, it is RECOMMENDED that user agents support STUN relay usage [6] [8] for this purpose.
ICEの手順を以下の場合は、ローカルアドレスに加えて、ユーザエージェントはリレーからアドレスを取得する必要があるかもしれません。例えば、IPv6のユーザエージェントは、リレーからIPv4アドレスを取得することになります。リレーは、IPv6を使用してユーザーエージェントに、このIPv4アドレスで受信したトラフィックを転送します。そのようなユーザエージェントがICEの推奨事項を以下、リレーのアドレスを得るための任意の機構を使用してもよいが、それはユーザエージェントがSTUNリレーの使用をサポートすることが推奨されている[6] [8]この目的のために。
IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses using the ICE procedures to generate all their offers. This way, both IPv4-only and IPv6-only answerers will be able to generate a mutually acceptable answer that establishes a session (having used ICE to gather both IPv4 and IPv6 addresses in the offer reduces the session establishment time because all answerers will find the offer valid.)
IPv4 / IPv6のユーザエージェントは、すべてのオファーを生成するために、ICEの手順を使用してIPv4とIPv6の両方のアドレスを収集する必要があります。すべての回答がありますので、この方法では、両方のIPv4のみとIPv6のみの回答者は、セッション確立時間を短縮（提供にIPv4とIPv6の両方のアドレスを収集するためにICEを使用したセッションを確立し、相互に許容可能な答えを生成することができます有効な提供します。）
Implementations are encouraged to use ICE; however, the normative strength of the text above is left at a SHOULD since in some managed networks (such as a closed enterprise network) it is possible for the administrator to have control over the IP version utilized in all nodes and thus deploy an IPv6-only network, for example. The use of ICE can be avoided for signaling messages that stay within such managed networks.
実装は、ICEを使用することをお勧めします。管理者は、すべてのノードで利用IPバージョンの制御を有し、したがってIPv6-を展開するために（例えば、閉じた企業ネットワークのような）いくつかの管理対象ネットワークでそれが可能であるので、上記のテキストの規範的強度をSHOULDに残され例えば唯一のネットワーク、。 ICEの使用は、管理ネットワーク内にとどまるシグナリングメッセージのために回避することができます。
Once the answerer has generated an answer following the ICE procedures, both user agents perform the connectivity checks as specified by ICE. These checks help prevent some types of flooding attacks and allow user agents to discover new addresses that can be useful in the presence of NATs.
回答は、ICEの手順に従って回答を生成した後ICEによって指定されるように、両方のユーザエージェントは、接続性チェックを実行します。これらのチェックは、フラッド攻撃のいくつかのタイプを防ぎ、ユーザーエージェントはNATの存在下で有用であることができる新しいアドレスを検出することを可能に役立ちます。
RFC 3263 maps a SIP or SIPS URI to a set of DNS SRV records for the various servers that can handle the URI. The Expected Output, given an Application Unique String (the URI) is one or more SRV records, sorted by the "priority" field, and further ordered by the "weight" field in each priority class.
RFC 3263は、SIPをマップするか、URIを処理できる各種サーバーのDNS SRVレコードのセットにURIをSIPS。アプリケーション固有文字列（URI）与えられた予想される出力は、「優先順位」フィールドでソートされた一つ以上のSRVレコードであり、さらに各優先度クラスに「重み」フィールドで注文しました。
The terms "Expected Output" and "Application Unique String", as they are to be interpreted in the context of SIP, are defined in Section 8 of RFC 3263 [5].
用語「予想出力」と「アプリケーション固有の文字列」、彼らはSIPのコンテキストで解釈されるべきであるように、RFC 3263のセクション8で定義されている[5]。
To find a particular IP address to send the request to, the client will eventually perform an A or AAAA DNS lookup on a target. As specified in RFC 3263, this target will have been obtained through NAPTR and SRV lookups, or if NAPTR and SRV lookup did not return any records, the target will simply be the domain name of the Application Unique String. In order to translate the target to the corresponding set of IP addresses, IPv6-only or dual-stack clients MUST use the newer getaddrinfo() name lookup function, instead of gethostbyname() [16]. The new function implements the Source and Destination Address Selection algorithms specified in RFC 3484 [9], which is expected to be supported by all IPv6 hosts.
、クライアントは最終的にターゲットにAまたはAAAA DNSルックアップを実行します要求を送信するために、特定のIPアドレスを確認するには。 RFC 3263で規定されているように、このターゲットはNAPTRとSRVルックアップを介して取得されています、またはNAPTRとSRVルックアップがレコードを返さなかった場合、ターゲットは、単にアプリケーション固有文字列のドメイン名になります。 IPアドレスの対応するセットにターゲットを変換するためには、IPv6のみまたはデュアルスタッククライアントは、[16]）（代わりにgethostbynameで、新しいのgetaddrinfo（）名前検索機能を使用しなければなりません。新機能は、すべてのIPv6ホストでサポートされていることが予想され、[9] RFC 3484で指定された送信元および宛先アドレス選択アルゴリズムを実装しています。
The advantage of the additional complexity is that this technique will output an ordered list of IPv6/IPv4 destination addresses based on the relative merits of the corresponding source/destination pairs. This will guarantee optimal routing. However, the Source and Destination Selection algorithms of RFC3484 are dependent on broad operating system support and uniform implementation of the application programming interfaces that implement this behavior.
付加的な複雑さの利点は、この手法が出力対応するソース/宛先ペアの優劣に基づいたIPv6 / IPv4宛先アドレスの順序付きリスト。これは、最適なルーティングを保証します。しかし、RFC3484のソースとデスティネーションの選択アルゴリズムは、幅広いオペレーティングシステムのサポートと、この動作を実装するアプリケーション・プログラミング・インターフェースの均一な実装に依存しています。
Developers should carefully consider the issues described by Roy et al. [19] with respect to address resolution delays and address selection rules. For example, implementations of getaddrinfo() may return address lists containing IPv6 global addresses at the top of the list and IPv4 addresses at the bottom, even when the host is only configured with an IPv6 local scope (e.g., link-local) and an IPv4 address. This will, of course, introduce a delay in completing the connection.
開発者は慎重ロイらによって記載されている問題を考慮する必要があります。 [19]アドレス解決遅延およびアドレス選択ルールに関して。例えば、のgetaddrinfo（）の実装では、リストの一番上にIPv6グローバルアドレスを含むアドレスリストを返すことができるとIPv4（例えば、リンクローカル）とホストがIPv6のみローカルスコープで構成されている場合でも、下部にアドレスIPv4アドレス。これは、当然のことながら、接続を完了するの遅延を紹介します。
This document describes how IPv4 SIP user agents can communicate with IPv6 user agents (and vice versa). To do this, it uses additional protocols (STUN relay usage [6], ICE [7], SDP [2]); the threat model of each such protocol is included in its respective document. The procedures introduced in this document do not introduce the possibility of any new security threats; however, they may make hosts more amenable to existing threats. Consider, for instance, a UAC that allocates an IPv4 and an IPv6 address locally and inserts these into the SDP. Malicious user agents that may intercept the request can mount a denial-of-service attack targeted to the different network interfaces of the UAC. In such a case, the UAC should use mechanisms that protect confidentiality and integrity of the messages, such as using the SIPS URI scheme as described in Section 26.2.2 of RFC3261 [3], or secure MIME as described in Section 23 of RFC3261 [3]. If HTTP Digest is used as an authentication mechanism in SIP, then the UAC should ensure that the quality of protection also includes the SDP payload.
この文書は、IPv4 SIPユーザエージェントは、IPv6ユーザエージェント（およびその逆）と通信することができる方法について説明します。これを行うには、それが使用する追加のプロトコル（STUNリレー使用[6]、ICE [7]、SDP [2]）。各そのようなプロトコルの脅威モデルは、そのそれぞれの文書に含まれています。本書で紹介した手順は、新しいセキュリティの脅威の可能性を導入しません。しかし、彼らは既存の脅威へのホストがより容易にすることがあります。 、例えば、局所的にIPv4およびIPv6アドレスを割り当て、SDPにこれらを挿入するUACを考えます。要求を傍受できる悪意のあるユーザエージェントは、UACの異なるネットワークインタフェースを標的とするサービス拒否攻撃を仕掛けることができます。このような場合には、UACは、[RFC3261のセクション26.2.2に記載されているように[3]のようなSIPS URIスキームを使用するなど、メッセージの機密性と完全性を保護するメカニズムを使用するか、RFC3261のセクション23に記載されるようにMIMEを確保しなければなりません3]。 HTTPダイジェストは、SIPにおける認証メカニズムとして使用される場合、UACは、保護の品質もSDPペイロードが含まれていることを確認すべきです。
The authors would like to thank Mohamed Boucadair, Christine Fischer, Cullen Jennings, Aki Niemi, Jonathan Rosenberg, and Robert Sparks for discussions on the working group list that improved the quality of this document.
作者はこのドキュメントの品質を改善ワーキンググループリストの議論のためにモハメドBoucadair、クリスティン・フィッシャー、カレン・ジェニングス、アキニエミ、ジョナサン・ローゼンバーグ、ロバート・スパークスに感謝したいと思います。
Additionally, Francois Audet, Mary Barnes, Keith Drage, and Dale Worley provided invaluable comments as part of the working group Last Call review process. Jari Arkko, Lars Eggert, Tobias Gondrom, Suresh Krishnan, and Tim Polk conducted an in-depth review of the work as part of the IESG and Gen-ART reviews.
また、フランソワAudet、メアリー・バーンズ、キース糖剤、及びデールウォーリーは、ワーキンググループラストコールレビュープロセスの一環として、非常に貴重なコメントを提供しました。ヤリArkko、ラースEggertの、トビアスGondrom、スレシュクリシュナン、およびティムポークはIESGとのGen-ARTレビューの一環として、仕事の徹底的な見直しを行いました。
[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., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[6] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[6]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルがNATの周りにリレーを使用（TURN）：NAT（STUN）のセッショントラバーサルユーティリティへの中継の拡張"、RFC 5766、2010年4月。
[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[7]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[8] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011.
[8]キャマリロ、G.、ノボ、O.、およびS.ペロー、 "IPv6のためのNATの周りにリレーを使用トラバーサル（TURN）拡張子"、RFC 6156年4月2011。
[9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[9] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[10] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[10] Schulzrinneと、H.、およびB.フォルツ、RFC 3319、2003年7月 "セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション"。
[11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[11] Schulzrinneと、H.、RFC 3361 "セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCP-用-IPv4）のオプション"、2002年8月。
[12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[12]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[13] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[14]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[15] Gurbani, V., Boulton, C., and R. Sparks, "Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)", RFC 5118, February 2008.
[15] Gurbani、V.、ボールトン、C.、およびR.スパークス、 "セッション開始プロトコル（SIP）は、インターネットプロトコルバージョン6（IPv6）のための拷問テストメッセージ"、RFC 5118、2008年2月。
[16] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[16]シン、M-K。、香港、Y-G。、萩野、J.、Savola、P.、およびE.カストロ、 "IPv6移行のアプリケーション側面"、RFC 4038、2005年3月。
[17] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[17] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[18] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[18]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[19] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007.
[19]ロイ、S.、デュラン、A.、およびJ. Paugh 2007年9月、RFC 4943、 "IPv6の近隣探索オンリンク仮定は有害であると考えられました"。
Appendix A. Sample IPv4/IPv6 DNS File
付録A.サンプルのIPv4 / IPv6のDNSのファイル
A portion of a sample DNS zone file entry is reproduced below that has both IPv4 and IPv6 addresses. This entry corresponds to a proxy server for the domain "example.com". The proxy server supports the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) transport for both IPv4 and IPv6 networks.
サンプルDNSゾーンファイルのエントリの一部は、そのIPv4およびIPv6アドレスの両方を有して以下に再現されます。このエントリは、ドメイン「example.com」のプロキシサーバに対応します。プロキシサーバは、IPv4とIPv6ネットワークの両方のための伝送制御プロトコル（TCP）とユーザーデータグラムプロトコル（UDP）トランスポートをサポートしています。
...
_sip._tcp SRV 20 0 5060 sip1.example.com
SRV 0 0 5060 sip2.example.com
_sip._udp SRV 20 0 5060 sip1.example.com
SRV 0 0 5060 sip2.example.com
sip1 IN A 192.0.2.1 sip1 IN AAAA 2001:db8::1 sip2 IN A 192.0.2.2 sip2 IN AAAA 2001:db8::2 ...
SIP1のA 192.0.2.1 SIP1、IN AAAA 2001：AAAA 2001年に192.0.2.2のSIP2、IN DB8 :: 1 SIP2：DB8 :: 2 ...
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Karim El Malki Athonet AREA Science Park Padriciano 99 Trieste (TS) 34149 Italy
カリム・エルMalki Athonet AREAサイエンスパークPadriciano 99トリエステ（TS）34149イタリア
EMail: karim@athonet.com
メールアドレス：karim@athonet.com
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville, IL 60563 USA
ビジェイK. Gurbaniベル研究所、アルカテル・ルーセント1960ルーセントレーンRmの9C-533ネーパーヴィル、IL 60563 USA
Phone: +1 630 224 0216 EMail: vkg@bell-labs.com
電話：+1 630 224 0216 Eメール：vkg@bell-labs.com