[要約] RFC 6157は、SIPにおけるIPv6移行に関するガイドラインです。その目的は、SIPベースの通信プロトコルがIPv6に移行する際の手順と課題を明確にすることです。
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)
セッション開始プロトコル（SIP）のIPv6トランジション
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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遷移の完全なソリューションは、シグナリング層とメディア層の両方を処理する必要があります。プロキシサーバーとそのドメイン名システム（DNS）エントリが適切に構成されている限り、Unextended SIPは信号層で異種の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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「「必要」、「しなければ」、「そうしない」、「そうすべきではない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈され、準拠の実装の要件レベルを示します。
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 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トラフィックを送信および受信します。このセクションでは、信号層でのそのような交通交換に関連する問題、つまり、セッションを確立するための参加者間の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エントリの両方が存在するはずです。これにより、ユーザーエージェントはDNSを照会し、使用に最も適したIPアドレスを取得できます（つまり、IPv4のみのユーザーエージェントがリソースレコード（RRS）に対してDNSを照会します。IPv6のみのユーザーエージェントはAAAA RRSをクエリします、およびデュアルスタックユーザーエージェントは、すべての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のみのインバウンドプロキシサーバーの両方を展開することをお勧めします。これにより、自律ドメインの外部のユーザーエージェントがDNSを照会し、使用に最も適したインバウンドプロキシのIPアドレスを受信できます（つまり、IPv4のみのユーザーエージェントはRRSを照会します。IPv6のみのユーザーエージェントはAAAA RRSのDNSクエリとデュアルスタックユーザーエージェントは、すべてのRRをDNSに照会し、特定のネットワークを選択します）。この戦略、つまりデュアルスタックプロキシを展開することにより、自律ドメイン内のIPv6のみのユーザーエージェントが同じ自律ドメインのIPv4のみのユーザーエージェントと通信することもできます。このようなプロキシがなければ、異なるネットワーク識別子を使用するユーザーエージェントは、互いに正常に信号を送ることができません。
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.
IPv6を使用してリクエストを受信し、IPv4を使用してユーザーエージェント（または別のダウンストリームプロキシ）にリレーする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つは、リレーを行うプロキシは、セッションの期間中、シグナリングパスにとどまる必要があります。それ以外の場合、上流のクライアントとダウンストリームサーバーは直接通信できません。第二に、シグナリングパスに留まるには、プロキシは1つまたは2つのレコードルートヘッダーを挿入する必要があります。プロキシがプロキシの完全に適格なドメイン名（FQDN）を含むURIを挿入している場合、その名前はIPv4とIPv6の両方を持っていますDNSのアドレスで、1つのレコードルートヘッダーを挿入すると十分です。ただし、プロキシがレコードルートヘッダーにIPアドレスを挿入している場合、そのようなヘッダーを2つ挿入する必要があります。最初のレコードルートヘッダーには、ダウンストリームサーバーのネットワークタイプと互換性のあるプロキシのIPアドレスが含まれており、2番目のレコードルートヘッダーには、アップストリームクライアントと互換性のあるプロキシの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.
この例は、この動作を説明するのに役立ちます。この例では、ディスカッションに関連するヘッダーのみを使用します。他のヘッダーは簡潔に省略されています。さらに、招待リクエストと最終応答（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 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.)
この例では、Domain Example.comを担当するProxy Pは、IPv4のみのアップストリームクライアントからリクエストを受け取ります。このリクエストをIPv6のみのダウンストリームサーバーに依頼します。プロキシPはデュアルスタックホストで実行されています。IPv4インターフェイスには192.0.2.1のアドレスがあり、IPv6インターフェイスでは2001年のアドレスで構成されています：DB8 :: 1（付録Aには、両方のIPv4が入力されたサンプルDNSゾーンファイルエントリが含まれています。およびIPv6アドレス。）
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を招待する：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>
...
F3: 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
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <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）が招待状を取得し、招待状を受け入れると、200 OK（F3）を送信し、ルートセットを形成します。ルートセットの最初のエントリは、プロキシのIPv6インターフェイスに対応しています。同様に、200 OKがユーザーエージェントクライアント（UAC）（F4）に到達すると、RFC 3261のガイドラインに従ってレコードルートヘッダーを逆にすることで設定されたルートを作成します。ルートセットの最初のエントリは、プロキシの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.
あるいは、プロキシはFQDNをレコードルートURIに挿入した可能性があり、結果は同じだったでしょう。これは、プロキシにDNSにIPv4アドレスとIPv6アドレスの両方があるためです。したがって、URI解像度はUACにIPv4アドレスとUASにIPv6アドレスをもたらしました。
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.
ユーザーエージェントのクライアントは、セクション4.2で指定された規範テキストに従って、ネットワークに関連するIPアドレスを収集する必要があります。それを行った後、クライアントはセクション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]を使用してメディアセッションを確立します。1つのエンドポイントであるオファーは、セッションの説明（オファー）をもう一方のエンドポイントであるAnswererに送信します。このオファーには、メディアをオファー担当者と交換するために必要なすべてのメディアパラメーターが含まれています。コーデック、輸送アドレス、メディアを転送するプロトコルなど。
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].
応答者がオファーを受け取ると、それは答えを詳しく説明し、それを提供者に送り返します。回答には、Answererがその特定のセッションに喜んで使用することを望んでいるメディアパラメーターが含まれています。オファーと回答は、セッション説明プロトコルを使用して書かれています。現在のセッションを説明する最も広範なプロトコルは、適切に、セッション説明プロトコル（SDP）[2]と呼ばれています。
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のみのユーザーエージェントは、1つ以上の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.
このIPバージョンの非互換性の問題は、IPv6を実装するホストもIPv4を実装し、IPv4とIPv6アドレスの両方で構成された場合、存在しません。そのような場合、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-のみのユーザーエージェントベースとは異なります。
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アドレスを使用してメディアを送信および受信することもできますが、できない場合は、NAT（STUN）リレー使用のセッショントラバーサルユーティリティをサポートする必要があります[8]。このようなリレーにより、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.
1. パブリックIPv4アドレスが不足しているネットワークで、IPv6でのみ大規模な展開を行うことが望ましいです。
2. Networks utilizing Layer-2's that do not support concurrent IPv4 and IPv6 usage on the same link.
2. 同じリンクで同時のIPv4とIPv6の使用をサポートしないレイヤー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., ::).
1. 場合によっては、特にサードパーティのコールコントロールを扱うもの（[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.
2. SDP回答の各メディアの説明は、オファー内の対応するメディアの説明と同じネットワークタイプを使用する必要があります。したがって、オファーの該当する「C =」行に値「IP4」を持つネットワークタイプが含まれている場合、回答の対応するメディア説明の該当する「C =」行は、「IP4」を含む必要があります。ネットワーク型。同様に、オファー内のメディアの説明の該当する「C =」行に値「IP6」を持つネットワークタイプが含まれている場合、回答の対応するメディア説明の該当する「C =」行は、「IP6」を含む必要があります。ネットワーク型。
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.
ローカルアドレスに加えて、氷の手順に従う場合、ユーザーエージェントはリレーからアドレスを取得する必要がある場合があります。たとえば、IPv6ユーザーエージェントは、リレーからIPv4アドレスを取得します。リレーは、このIPv4アドレスで受信したトラフィックをIPv6を使用してユーザーエージェントに転送します。このようなユーザーエージェントは、あらゆるメカニズムを使用してリレーでアドレスを取得する場合がありますが、ICEの推奨事項に従って、ユーザーエージェントはこの目的のためにStun Relayの使用[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-を展開することができるため、AはAに残されています。たとえば、ネットワークのみ。氷の使用は、そのような管理されたネットワーク内にとどまるメッセージを信号するために回避できます。
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で指定されたように接続性チェックを実行します。これらのチェックは、いくつかの種類の洪水攻撃を防ぎ、ユーザーエージェントが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は、URIを処理できるさまざまなサーバーのDNS SRVレコードのセットにSIPまたはSIPをマッピングします。アプリケーションの一意の文字列（URI）が与えられた予想出力は、「優先度」フィールドでソートされた1つ以上の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 [5]のセクション8で定義されています。
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.
リクエストを送信する特定のIPアドレスを見つけるために、クライアントは最終的にターゲットでAまたはAAAA DNSルックアップを実行します。RFC 3263で指定されているように、このターゲットはNAPTRおよびSRVルックアップを通じて取得されます。または、NAPTRとSRVルックアップがレコードを返さなかった場合、ターゲットは単にアプリケーションの一意の文字列のドメイン名になります。ターゲットを対応するIPアドレスのセットに変換するには、IPv6のみまたはデュアルスタッククライアントがGethostbyname（）[16]の代わりに、新しいgetAddrinfo（）name lookup関数を使用する必要があります。新しい関数は、RFC 3484 [9]で指定されたソースおよび宛先アドレスの選択アルゴリズムを実装します。これは、すべてのIPv6ホストによってサポートされると予想されます。
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.
開発者は、Roy et al。[19]解決解決の遅延と選択ルールに対処することに関して。たとえば、getaddrinfo（）の実装は、リストの上部にIPv6グローバルアドレスを含むアドレスリストを返すことができ、ホストがIPv6ローカルスコープ（例：link-local）でのみ構成されている場合でも、下部のIPv4アドレスを下に戻すことができます。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ユーザーエージェントと通信する方法について説明します（およびその逆も同様です）。これを行うには、追加のプロトコルを使用します（スタンリレー使用[6]、ICE [7]、SDP [2]）。そのような各プロトコルの脅威モデルは、それぞれのドキュメントに含まれています。このドキュメントで導入された手順では、新しいセキュリティの脅威の可能性は導入されていません。ただし、ホストは既存の脅威に対応しやすくなる可能性があります。たとえば、IPv4とIPv6アドレスをローカルに割り当て、これらをSDPに挿入するUACを検討してください。リクエストを傍受する可能性のある悪意のあるユーザーエージェントは、UACのさまざまなネットワークインターフェイスをターゲットにしたサービス拒否攻撃を実施できます。そのような場合、UACは、RFC3261 [3]のセクション26.2.2で説明されているSIPS URIスキームを使用するなど、メッセージの機密性と整合性を保護するメカニズムを使用する必要があります。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.
著者は、この文書の品質を向上させたワーキンググループリストに関する議論について、モハメド・ブーカデア、クリスティーン・フィッシャー、カレン・ジェニングス、アキ・ニーミ、ジョナサン・ローゼンバーグ、ロバート・スパークに感謝したいと思います。
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.
さらに、Francois Audet、Mary Barnes、Keith Drage、およびDale Worleyは、ワーキンググループの最後のコールレビュープロセスの一部として貴重なコメントを提供しました。Jari Arkko、Lars Eggert、Tobias Gondrom、Suresh Krishnan、およびTim Polkは、IESGおよびGen-Artのレビューの一部として、この作品の詳細なレビューを実施しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg、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] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATの周りのリレーを使用したトラバーサル：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] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：Network Address Translator（NAT）Traversal for Offer/Answer Protocolsのプロトコル」、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] Camarillo、G.、Novo、O。、およびS. Perreault、「IPv6のNAT（ターン）拡張の周りのリレーを使用したトラバーサル」、RFC 6156、2011年4月。
[9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[9] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、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. Volz、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPV6）オプション」、RFC 3319、2003年7月。
[11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[11] Schulzrinne、H。、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCP-For-IPV4）オプション」、RFC 3361、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] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス（SIP）」、BCP 85、RFC 3725、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.、Frederick、R。、およびV. Jacobson、「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] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、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.、Boulton、C。、およびR. Sparks、「セッション開始プロトコル（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] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「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. Gilligan、「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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] Roy、S.、Durand、A。、およびJ. Paugh、「IPv6 Neighbor Discovery On-Link Assuptionが有害と見なされる」、RFC 4943、2007年9月。
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
... _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 ...
AAAA 2001の192.0.2.1 SIP1のSIP1：DB8 :: 1 SIP2 IN 192.0.2.2 SIP2 In AAAA 2001：DB8 :: 2 ...
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Karim El Malki Athonet AREA Science Park Padriciano 99 Trieste (TS) 34149 Italy
Karim El Malki AthonetエリアサイエンスパークPadriciano 99 Trieste（TS）34149 Italy
EMail: karim@athonet.com
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Rm 9C-533 Naperville, IL 60563 USA
Vijay K. Gurbani Bell Laboratories、Alcatel-Lucent 1960 Lucent Lane RM 9C-533 Naperville、IL 60563 USA
Phone: +1 630 224 0216
EMail: vkg@bell-labs.com