Internet Engineering Task Force (IETF) O. Johansson
Request for Comments: 7984 Edvina AB
Updates: 3263 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 V. Gurbani
Bell Labs, Nokia Networks
D. Worley, Ed.
Ariadne
September 2016
Internet Engineering Task Force (IETF) O. Johansson
Request for Comments: 7984 Edvina AB
Updates: 3263 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 V. Gurbani
Bell Labs, Nokia Networks
D. Worley, Ed.
Ariadne
September 2016
Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network
在双栈IP网络中定位会话启动协议（SIP）服务器
Abstract
摘要
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual-stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.
RFC 3263定义了给定SIP统一资源标识符（URI）的会话发起协议（SIP）实现应如何使用域名系统（DNS）过程定位下一跳SIP服务器。随着SIP网络逐渐从IPv4向双栈过渡，双栈SIP实现必须确保高质量的用户体验。本文档更新了RFC 3263中描述的双栈SIP实现的DNS过程，以准备即将发布的规范，将“快乐眼球”原则应用于SIP。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7984.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7984.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 4
3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4
3.2. Indicating Address Family Preference in DNS SRV Records . 5
4. Clarification of Interaction with RFC 6724 . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 4
3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4
3.2. Indicating Address Family Preference in DNS SRV Records . 5
4. Clarification of Interaction with RFC 6724 . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The Session Initiation Protocol (SIP) [RFC3261] and the additional documents that extended it provide support for both IPv4 and IPv6. However, this support does not fully extend to the highly hybridized environments that are characteristic of the transitional migratory phase from IPv4 to IPv6 networks. During this phase, many server and client implementations run on dual-stack hosts. In such environments, a dual-stack host will likely suffer greater connection delay, and by extension an inferior user experience, than an IPv4-only host. The need to remedy this diminished performance of dual-stack hosts led to the development of the "Happy Eyeballs" [RFC6555] algorithm, which has since been implemented in many protocols and applications.
会话启动协议（SIP）[RFC3261]和扩展它的附加文档提供了对IPv4和IPv6的支持。但是，这种支持并没有完全扩展到高度混合的环境，这些环境是从IPv4到IPv6网络过渡迁移阶段的特征。在此阶段，许多服务器和客户端实现在双堆栈主机上运行。在这样的环境中，双栈主机可能会比只使用IPv4的主机遭受更大的连接延迟，进而导致较差的用户体验。为了弥补双栈主机性能下降的问题，开发了“快乐眼球”[RFC6555]算法，该算法已在许多协议和应用程序中实现。
This document updates the DNS lookup procedures of RFC 3263 [RFC3263] in preparation for the specification of the application of Happy Eyeballs to SIP. Happy Eyeballs will provide enhanced performance, and consequently enhanced user experience, in highly hybridized dual-stack SIP networks. The procedures described herein are such that a dual-stack client should look up both A and AAAA records in DNS and then select the best way to set up a network flow. The details of how the latter is done is considered out of scope for this document. See the Happy Eyeballs algorithm and implementation and design considerations in RFC 6555 [RFC6555] for more information about issues with setting up dual-stack network flows.
本文件更新了RFC 3263[RFC3263]的DNS查找程序，为SIP中快乐眼球的应用规范做准备。在高度混合的双栈SIP网络中，Happy Eyeballs将提供增强的性能，从而增强用户体验。本文描述的过程是这样的：双栈客户端应该在DNS中查找a和AAAA记录，然后选择设置网络流的最佳方式。后一种方法的细节被认为超出了本文件的范围。有关设置双堆栈网络流问题的更多信息，请参阅RFC 6555[RFC6555]中的Happy Eyeballs算法以及实现和设计注意事项。
Section 4 of this document clarifies the interaction of [RFC3263] with [RFC6157] and [RFC6724].
本文件第4节阐明了[RFC3263]与[RFC6157]和[RFC6724]之间的相互作用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
RFC 3261 [RFC3261] defines additional terms used in this document that are specific to the SIP domain such as "proxy", "registrar", "redirect server", "user agent server" or "UAS", "user agent client" or "UAC", "back-to-back user agent" or "B2BUA", "dialog", "transaction", and "server transaction".
RFC 3261[RFC3261]定义了本文档中使用的特定于SIP域的其他术语，如“代理”、“注册商”、“重定向服务器”、“用户代理服务器”或“UAS”、“用户代理客户端”或“UAC”、“背对背用户代理”或“B2BUA”、“对话框”、“事务”和“服务器事务”。
This document uses the term "SIP server" that is defined to include the following SIP entities: user agent server, registrar, redirect server, a SIP proxy in the role of user agent server, and a B2BUA in the role of a user agent server.
本文档使用术语“SIP服务器”，该术语定义为包括以下SIP实体：用户代理服务器、注册器、重定向服务器、扮演用户代理服务器角色的SIP代理以及扮演用户代理服务器角色的B2BUA。
While this document focuses on the dual-stack situation described in RFC 6555 and other documents, concerning the migration from an IPv4-only network to a network supporting both IPv4 and IPv6, the techniques described can be used in other situations. Possible situations include when a device has multiple interfaces with distinct addressing characteristics and when additional IP address families are created in the future. This document uses the general term "dual-stack" to include all situations where the client has access to multiple communication methods that have distinct addressing characteristics.
虽然本文档主要关注RFC 6555和其他文档中描述的双堆栈情况，但关于从仅IPv4网络迁移到同时支持IPv4和IPv6的网络，所描述的技术可用于其他情况。可能的情况包括设备具有多个具有不同寻址特征的接口，以及将来创建其他IP地址系列。本文档使用通用术语“双堆栈”来包括客户端可以访问具有不同寻址特征的多种通信方法的所有情况。
The term "address records" means the DNS records that translate a domain name into addresses within the address family or families that the entity supports (as A records provide IPv4 addresses and AAAA records provide IPv6 addresses), regardless of whether the address family was defined before or after this document was approved.
术语“地址记录”是指将域名转换为实体支持的一个或多个地址族中的地址的DNS记录（因为记录提供IPv4地址，AAAA记录提供IPv6地址），而不管该地址族是在本文档批准之前还是之后定义的。
This specification introduces two normative DNS lookup procedures. These are designed to improve the performance of dual-stack clients in IPv4/IPv6 networks.
本规范介绍了两种标准的DNS查找过程。它们旨在提高IPv4/IPv6网络中双栈客户端的性能。
Once the transport protocol has been determined, the procedure for discovering an IP address if the TARGET is not a numeric IP address but the port is explicitly stated in the URI, is detailed in Section 4.2 of RFC 3263 [RFC3263]. The piece relevant to this discussion is:
一旦确定了传输协议，如果目标不是数字IP地址，但URI中明确说明了端口，则查找IP地址的过程将在RFC 3263[RFC3263]的第4.2节中详细说明。与本次讨论相关的内容如下：
If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously.
如果目标不是数字IP地址，但URI中存在端口，则客户端将对域名执行a或AAAA记录查找。结果将是一个IP地址列表，每个IP地址都可以通过前面确定的URI和传输协议在特定端口进行联系。
Section 4.2 of RFC 3263 [RFC3263] also goes on to describe the procedure for discovering an IP address if the TARGET is not a numeric IP address, and no port is present in the URI. The piece relevant to this discussion is:
RFC 3263[RFC3263]第4.2节还描述了在目标不是数字IP地址且URI中不存在端口的情况下查找IP地址的过程。与本次讨论相关的内容如下：
If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport. Processing then proceeds as described above for an explicit port once the A or AAAA records have been looked up.
如果未找到SRV记录，客户端将对域名执行A或AAAA记录查找。结果将是一个IP地址列表，可以使用先前确定的传输协议在该传输的默认端口联系每个IP地址。然后，在查找A或AAAA记录后，按照上述方式对显式端口进行处理。
Happy Eyeballs [RFC6555] documents that looking up the "A or AAAA record" is not an effective practice for dual-stack clients and that it can add significant connection delay and greatly degrade user experience. Therefore, this document makes the following normative addendum to the DNS lookup procedures in Section 4.2 of RFC 3263 [RFC3263] for IPv4/IPv6 hybrid SIP networks and recommends it as a best practice for such dual-stack networks:
Happy Eyeballs[RFC6555]文件指出，查找“A或AAAA记录”对于双堆栈客户端来说不是一种有效的做法，它会增加显著的连接延迟，并大大降低用户体验。因此，本文件对RFC 3263[RFC3263]第4.2节中IPv4/IPv6混合SIP网络的DNS查找程序进行了以下规范性附录，并建议将其作为此类双栈网络的最佳实践：
The dual-stack client SHOULD look up address records for all address families that it supports for the domain name and add the resulting addresses to the list of IP addresses to be contacted. A client MUST be prepared for the existence of DNS resource records containing addresses in families that it does not support; if such records may be returned by the client's DNS queries, such records MUST be ignored as unusable and the supported addresses used as specified herein.
双栈客户端应查找其支持的所有域名地址族的地址记录，并将结果地址添加到要联系的IP地址列表中。客户机必须准备好存在DNS资源记录，其中包含其不支持的系列中的地址；如果客户的DNS查询可能返回此类记录，则必须将此类记录视为不可用而忽略，并按照此处的规定使用支持的地址。
The Happy Eyeballs algorithm [RFC6555] is particularly effective for dual-stack HTTP client applications that have significant performance differences between their IPv4 and IPv6 network paths. This is because the client can initiate two TCP connections to the server, one using IPv4 and one using IPv6, and then use the connection that completes first. This works properly because the client can test each route by initiating a TCP connection, but simply opening a TCP connection to an HTTP server does not change the server's state; the client will send the HTTP request on only one connection.
Happy Eyeballs算法[RFC6555]对于双栈HTTP客户端应用程序特别有效，因为它们的IPv4和IPv6网络路径之间存在显著的性能差异。这是因为客户端可以启动到服务器的两个TCP连接，一个使用IPv4，一个使用IPv6，然后使用首先完成的连接。这可以正常工作，因为客户机可以通过启动TCP连接来测试每个路由，但是仅仅打开到HTTP服务器的TCP连接并不会改变服务器的状态；客户端将只在一个连接上发送HTTP请求。
Unfortunately, in common SIP situations, it is not possible to "race" simultaneous request attempts using two address families. If the SIP requests are transmitted as single UDP packets, sending two copies of the request to two different addresses risks having two copies of the request propagating through the SIP network at the same time. The difference between SIP and HTTP is that in SIP, the sender cannot test a route in a non-state-changing way.
不幸的是，在常见的SIP情况下，不可能使用两个地址族“竞争”同时请求尝试。如果SIP请求作为单个UDP数据包传输，则将请求的两个副本发送到两个不同的地址可能会导致请求的两个副本同时通过SIP网络传播。SIP和HTTP之间的区别在于，在SIP中，发送方不能以非状态改变的方式测试路由。
(If two copies of the same request arrive at the destination client, the client SHOULD reject the second of them with a response code of 482 [RFC3261]. To convey information on why the request was rejected to the originator, the client can include a descriptive reason phrase, for example, "Merged Request". However, issuing the 482 response is not sufficient to prevent user-visible differences in behavior. A proxy that is upstream of the second request to arrive at the client may (almost immediately!) serially fork the second request to further destinations (e.g., the voicemail service for the destination client).)
（如果同一请求的两个副本到达目标客户机，客户机应拒绝第二个副本，响应代码为482[RFC3261]。为了向发起人传达拒绝请求的原因，客户机可以包括一个描述性的原因短语，例如，“合并请求”。但是，发出482响应不足以防止用户出现明显的行为差异。位于到达客户端的第二个请求上游的代理可能（几乎立即！）连续地将第二个请求分支到其他目标（例如，目标客户端的语音邮件服务）。）
In this common scenario, it is often necessary for a dual-stack client to indicate a preference for either IPv4 or IPv6. A service may use DNS SRV records to indicate such a preference for an address family. This way, a server with a high-latency and/or low-capacity IPv4 tunnel may indicate a preference for being contacted using IPv6. A server that wishes to do this can use the lowest SRV priority to publish host names that only resolve in IPv6 and the next priority with host names that resolve in both address families.
在这种常见场景中，双栈客户端通常需要指示IPv4或IPv6的首选项。服务可以使用DNS SRV记录来指示对地址族的这种偏好。这样，具有高延迟和/或低容量IPv4隧道的服务器可能表示使用IPv6进行联系的偏好。希望这样做的服务器可以使用最低SRV优先级发布仅在IPv6中解析的主机名，并使用在两个地址族中解析的主机名发布下一个优先级。
Note that host names that have addresses in only one address family are discouraged by [RFC6555]. Such special-purpose host names SHOULD be used only as described in this section, as targets of SRV records for an aggregate host name, where the aggregate host name ultimately resolves to addresses in all families supported by the client.
请注意，[RFC6555]不鼓励仅在一个地址系列中包含地址的主机名。此类专用主机名应仅按本节所述使用，作为聚合主机名的SRV记录的目标，其中聚合主机名最终解析为客户端支持的所有系列中的地址。
Section 5 of [RFC6157] specifies that the addresses from the address records for a single target DNS name for a server's DNS name must be contacted in the order specified by the source and destination address selection algorithms defined in [RFC6724]. The set of addresses provided to a single invocation of the destination address selection algorithm MUST be the address records for the target DNS name in a single SRV record (or, if there are no SRV records, the DNS name in the URI or derived via NAPTR) -- the destination address selection algorithm MUST NOT reorder addresses derived from different SRV records. Typically, destination address selection is done by using the (relatively new) getaddrinfo() function to translate the target DNS name into a list of IPv4 and/or IPv6 addresses in the order in which they are to be contacted, as that function implements [RFC6724].
[RFC6157]第5节规定，必须按照[RFC6724]中定义的源和目标地址选择算法指定的顺序联系服务器DNS名称的单个目标DNS名称的地址记录中的地址。为目标地址选择算法的单个调用提供的地址集必须是单个SRV记录中目标DNS名称的地址记录（或者，如果没有SRV记录，则是URI中的DNS名称或通过NAPTR派生的DNS名称）--目标地址选择算法不得对来自不同SRV记录的地址进行重新排序。通常，目标地址选择是通过使用（相对较新的）getaddrinfo（）函数来完成的，该函数实现[RFC6724]，将目标DNS名称按照联系的顺序转换为IPv4和/或IPv6地址列表。
Thus, if SRV lookup on the server's DNS name is successful, the major ordering of the complete list of destination addresses is determined by the priority and weight fields of the SRV records (as specified in [RFC2782]), and the (minor) ordering among the destinations derived from the "target" field of a single SRV record is determined by [RFC6724].
因此，如果服务器DNS名称上的SRV查找成功，则目标地址的完整列表的主要顺序由SRV记录的优先级和权重字段确定（如[RFC2782]中所规定），而从单个SRV记录的“目标”字段派生的目标之间的（次要）顺序由[RFC6724]确定.
For example, consider a server with DNS name example.com, with TCP transport specified. The relevant SRV records for example.com are:
例如，考虑一个带有DNS名称ExpLo.com的服务器，其中指定了TCP传输。example.com的相关SRV记录如下：
_sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com.
_sip._tcp.example.com。SRV 10 1 5060 sip-1.example.com中的300_sip._tcp.example.com。SRV 20 1 5060 sip-2.example.com中的300。
The processing of [RFC2782] results in this ordered list of target domain names:
[RFC2782]的处理结果是目标域名的有序列表：
sip-1.example.com sip-2.example.com
sip-1.example.com sip-2.example.com
The address records for sip-1.example.com, as ordered by [RFC6724], are:
[RFC6724]订购的sip-1.example.com地址记录如下：
sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face
sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe
sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce
sip-1.example.com. 300 IN A 192.0.2.45
sip-1.example.com. 300 IN A 203.0.113.109
sip-1.example.com. 300 IN A 198.51.100.24
sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face
sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe
sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce
sip-1.example.com. 300 IN A 192.0.2.45
sip-1.example.com. 300 IN A 203.0.113.109
sip-1.example.com. 300 IN A 198.51.100.24
And the address records for sip-2.example.com, as ordered by [RFC6724], are:
[RFC6724]订购的sip-2.example.com地址记录如下：
sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead
sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef
sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de
sip-2.example.com. 300 IN A 192.0.2.75
sip-2.example.com. 300 IN A 203.0.113.38
sip-2.example.com. 300 IN A 198.51.100.140
sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead
sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef
sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de
sip-2.example.com. 300 IN A 192.0.2.75
sip-2.example.com. 300 IN A 203.0.113.38
sip-2.example.com. 300 IN A 198.51.100.140
Thus, the complete list of destination addresses has this ordering:
因此，目的地地址的完整列表具有以下顺序：
2001:0db8:58:c02::face
2001:0db8:c:a06::2:cafe
2001:0db8:44:204::d1ce
192.0.2.45
203.0.113.109
198.51.100.24
2001:0db8:58:c02::dead
2001:0db8:c:a06::2:beef
2001:0db8:44:204::c0de
192.0.2.75
203.0.113.38
198.51.100.140
2001:0db8:58:c02::face
2001:0db8:c:a06::2:cafe
2001:0db8:44:204::d1ce
192.0.2.45
203.0.113.109
198.51.100.24
2001:0db8:58:c02::dead
2001:0db8:c:a06::2:beef
2001:0db8:44:204::c0de
192.0.2.75
203.0.113.38
198.51.100.140
In particular, the destination addresses derived from sip-1.example.com and those derived from sip-2.example.com are not interleaved; [RFC6724] does not operate on the complete list. This would be true even if the two SRV records had the same priority and were (randomly) ordered based on their weights, as the address records of two target DNS names are never interleaved.
特别地，从sip-1.example.com派生的目的地地址和从sip-2.example.com派生的目的地地址不交错；[RFC6724]不在完整列表上运行。即使两个SRV记录具有相同的优先级，并且根据它们的权重（随机）排序，这也是正确的，因为两个目标DNS名称的地址记录从不交错。
This document introduces two new normative procedures to the existing DNS procedures used to locate SIP servers. A client may contact additional target addresses for a URI beyond those prescribed in [RFC3263], and/or it may contact target addresses in a different order than prescribed in [RFC3263]. Neither of these changes introduce any new security considerations because it has always been assumed that a client desiring to send to a URI may contact any of its targets that are listed in DNS.
本文档介绍了用于定位SIP服务器的现有DNS过程的两个新的规范性过程。客户机可以联系超出[RFC3263]中规定的URI的其他目标地址，和/或可以按照与[RFC3263]中规定的顺序不同的顺序联系目标地址。这两个更改都没有引入任何新的安全注意事项，因为始终假定希望发送到URI的客户端可以联系DNS中列出的任何目标。
The specific security vulnerabilities, attacks, and threat models of the various protocols discussed in this document (SIP, DNS, SRV records, Happy Eyeballs requirements and algorithm, etc.) are well documented in their respective specifications.
本文档中讨论的各种协议（SIP、DNS、SRV记录、快乐眼球要求和算法等）的特定安全漏洞、攻击和威胁模型在各自的规范中都有详细的记录。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <http://www.rfc-editor.org/info/rfc3263>.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，DOI 10.17487/RFC3263，2002年6月<http://www.rfc-editor.org/info/rfc3263>.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, DOI 10.17487/RFC6157, April 2011, <http://www.rfc-editor.org/info/rfc6157>.
[RFC6157]Camarillo，G.，El Malki，K.，和V.Gurbani，“会话启动协议（SIP）中的IPv6转换”，RFC 6157，DOI 10.17487/RFC6157，2011年4月<http://www.rfc-editor.org/info/rfc6157>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
Acknowledgments
致谢
The authors would like to acknowledge the support and contribution of the SIP Forum IPv6 Working Group. This document is based on a lot of tests and discussions at SIPit events, organized by the SIP Forum.
作者要感谢SIP论坛IPv6工作组的支持和贡献。本文件基于SIP论坛组织的SIPit活动中的大量测试和讨论。
This document has benefited from the expertise and review feedback of many participants of the IETF DISPATCH and SIPCORE Working Group mailing lists as well as those on the SIP Forum IPv6 Task Group mailing list. The authors wish to specifically call out the efforts and express their gratitude for the detailed and thoughtful comments and corrections of Dan Wing, Brett Tate, Rifaat Shekh-Yusef, Carl Klatsky, Mary Barnes, Keith Drage, Cullen Jennings, Simon Perreault, Paul Kyzivat, Adam Roach, Richard Barnes, Ben Campbell, Stefan Winter, Spencer Dawkins, and Suresh Krishnan. Adam Roach devised the example in Section 4.
本文件得益于IETF调度和SIPCORE工作组邮件列表以及SIP论坛IPv6任务组邮件列表中许多参与者的专业知识和审查反馈。作者希望特别指出这些努力，并感谢Dan Wing、Brett Tate、Rifaat Shekh Yusef、Carl Klatsky、Mary Barnes、Keith Drage、Cullen Jennings、Simon Perreault、Paul Kyzivat、Adam Roach、Richard Barnes、Ben Campbell、Stefan Winter、Spencer Dawkins、，还有苏雷什·克里希南。亚当·罗奇在第4节设计了这个例子。
Authors' Addresses
作者地址
Olle E. Johansson Edvina AB Runbovaegen 10 Sollentuna SE-192 48 Sweden
Olle E.Johansson Edvina AB Runbovaegen 10 Sollentuna SE-192 48瑞典
Email: oej@edvina.net
Email: oej@edvina.net
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Gonzalo Salgueiro Cisco Systems 7200-12美国北卡罗来纳州Kit Creek Road研究三角公园27709
Email: gsalguei@cisco.com
Email: gsalguei@cisco.com
Vijay K. Gurbani Bell Labs, Nokia Networks 1960 Lucent Lane Rm 9C-533 Naperville, IL 60563 United States of America
Vijay K.Gurbani Bell实验室，诺基亚网络1960年，美国伊利诺伊州纳珀维尔朗讯巷9C-533室，邮编：60563
Email: vkg@bell-labs.com
Email: vkg@bell-labs.com
Dale R. Worley (editor) Ariadne Internet Services 738 Main St. Waltham, MA 02451 United States of America
Dale R.Worley（编辑）Ariadne互联网服务738 Main St.Waltham，马萨诸塞州02451美利坚合众国
Email: worley@ariadne.com
Email: worley@ariadne.com