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
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）用户代理如何在会话成功设置后在信令层以及exchange介质上与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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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可以在信令层处理异构IPv6/IPv4网络，只要代理服务器及其域名系统（DNS）条目配置正确，但使用不同网络和地址空间的用户代理必须实现扩展，以便在它们之间交换媒体。
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.
本文档解决了系统级问题，以使SIP在IPv4和IPv6之间成功工作。第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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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流量，以及向其他自治域发送和从其他自治域接收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条目。这允许用户代理查询DNS并获得最适合其使用的IP地址（即，仅IPv4的用户代理将查询DNS中的资源记录（RRs），仅IPv6的用户代理将查询DNS中的AAAA RRs，双堆栈用户代理将查询DNS中的所有RRs并选择特定网络。）
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的用户代理将查询DNS以查找RRs，仅IPv6的用户代理将查询DNS以查找AAAA RRs，双堆栈用户代理将查询DNS以查找所有RRs并选择特定网络）。此策略（即部署双堆栈代理）还允许自治域中的仅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.
以这种方式在不同网络间中继请求还有其他影响。首先，在会话期间，进行中继的代理必须保持在信令路径中；否则，上游客户端和下游服务器将无法直接通信。其次，要保留在信令路径中，代理必须插入一个或两个记录路由头：如果代理插入的URI包含代理的完全限定域名（FQDN），并且该名称在DNS中同时具有IPv4和IPv6地址，则插入一个记录路由头就足够了。但如果代理在记录路由头中插入IP地址，则必须插入两个这样的头；第一个记录路由标头包含与下游服务器的网络类型兼容的代理IP地址，第二个记录路由标头包含与上游客户端兼容的代理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请求和最终响应（200OK）；本示例的目的不是提供包含临时响应和其他请求的完整调用流。
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
在本例中，负责域example.com的代理P从仅IPv4的上游客户端接收请求。它将此请求代理到仅限IPv6的下游服务器。Proxy 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
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.comSIP/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：邀请sip：alice@2001：db8:：10sip/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）收到邀请并接受邀请时，它会发送一个200 OK（F3）并形成一个路由集。其路由集中的第一个条目对应于代理的IPv6接口。类似地，当200ok到达用户代理客户端（UAC）（F4）时，它通过遵循rfc3261的准则并反转记录路由头来创建路由集。其路由集中的第一个条目对应于代理的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的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]。一个端点（报价人）向另一个端点（应答人）发送会话描述（报价）。报价包含与报价人交换媒体所需的所有媒体参数：编解码器、传输地址、传输媒体的协议等。
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].
当回答者收到报价时，它会详细说明答案并将其发送回报价者。答案包含回答者愿意在特定会话中使用的媒体参数。提供和回答使用会话描述协议编写。目前用于描述会话的最广泛的协议被称为会话描述协议（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的用户代理希望在一个或多个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
如果实现IPv6的主机也实现了IPv4，并且配置了IPv4和IPv6地址，则不存在此IP版本不兼容问题。在这种情况下，UA将能够
to pick a compatible media transport address type to enable the hosts to communicate with each other.
选择兼容的媒体传输地址类型，使主机能够相互通信。
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用户代理预计是双堆叠的，因此也支持IPv4，这与不支持或不能支持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的运营商提供额外的服务器，以允许IPv6用户代理获取IPv4地址。对于部署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. 使用第2层的网络不支持在同一链路上同时使用IPv4和IPv6。
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实现必须使用.invalid DNS顶级域中的域名，而不是使用IPv6未指定的地址（即：：）。
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是一种协议，允许两个通信用户代理在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应答者都将能够生成一个双方都能接受的答案，以建立会话（使用ICE在报价中收集IPv4和IPv6地址可以缩短会话建立时间，因为所有应答者都会发现报价有效。）
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的网络。可以避免使用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或SIPS URI映射到可处理URI的各种服务器的一组DNS SRV记录。给定应用程序唯一字符串（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].
RFC 3263[5]第8节定义了在SIP上下文中解释的术语“预期输出”和“应用程序唯一字符串”。
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或双堆栈客户端必须使用更新的getaddrinfo（）名称查找函数，而不是gethostbyname（）[16]。新函数实现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.
开发人员应该仔细考虑罗伊等人关于地址解析延迟和地址选择规则所描述的问题。例如，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[3]第26.2.2节中所述的SIPS URI方案，或RFC3261[3]第23节中所述的安全MIME。如果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.
作者要感谢Mohamed Boucadair、Christine Fischer、Cullen Jennings、Aki Niemi、Jonathan Rosenberg和Robert Sparks就工作组名单进行的讨论，这些讨论提高了本文件的质量。
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艺术评论的一部分。
[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：会话描述协议”，RFC4566，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：会话启动协议”，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服务器”，RFC3263，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周围的中继进行遍历（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] Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年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（TURN）扩展使用中继进行遍历”，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）的最佳当前实践”，BCP 85，RFC 37252004年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 35502003年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：会话启动协议”，RFC 25431999年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，“互联网协议版本6（IPv6）的会话启动协议（SIP）酷刑测试消息”，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邻居发现被认为是有害的”，RFC 49432007年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._TCPSRV 20 0 5060 sip1.example.com SRV 0 0 5060 sip2.example.com_sip._UDPSRV 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 AAAA 2001中192.0.2.2 sip2中的sip2:db8:：2。。。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Karim El Malki Athonet AREA Science Park Padriciano 99 Trieste (TS) 34149 Italy
意大利的里雅斯特（TS）帕德里西亚诺99号卡里姆马尔基阿索内特地区科技园34149
EMail: karim@athonet.com
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实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编：60563
Phone: +1 630 224 0216
EMail: vkg@bell-labs.com
Phone: +1 630 224 0216
EMail: vkg@bell-labs.com