From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6157.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc6157.txt (limited to 'doc/rfc/rfc6157.txt') diff --git a/doc/rfc/rfc6157.txt b/doc/rfc/rfc6157.txt new file mode 100644 index 0000000..4f3c99e --- /dev/null +++ b/doc/rfc/rfc6157.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Camarillo +Request for Comments: 6157 Ericsson +Updates: 3264 K. El Malki +Category: Standards Track Athonet +ISSN: 2070-1721 V. Gurbani + Bell Labs, Alcatel-Lucent + April 2011 + + + IPv6 Transition in the Session Initiation Protocol (SIP) + +Abstract + + This document describes how the IPv4 Session Initiation Protocol + (SIP) user agents can communicate with IPv6 SIP user agents (and vice + versa) at the signaling layer as well as exchange media once the + session has been successfully set up. Both single- and dual-stack + (i.e., IPv4-only and IPv4/IPv6) user agents are considered. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + +Camarillo, et al. Standards Track [Page 1] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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. + +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 + + 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]. + + 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. + + + + +Camarillo, et al. Standards Track [Page 2] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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. + +2. Terminology + + 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. + + 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-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. + + 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-only node: A host that implements IPv6 and does not implement + IPv4. + + IPv4/IPv6 node: A host that implements both IPv4 and IPv6; such + hosts are also known as "dual-stack" hosts [17]. + + IPv4/IPv6 user agent: A user agent that supports SIP signaling and + media on both IPv4 and IPv6 networks. + + IPv4/IPv6 proxy: A proxy that supports SIP signaling on both IPv4 + and IPv6 networks. + +3. The Signaling Layer + + 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 + + + + + +Camarillo, et al. Standards Track [Page 3] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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. + +3.1. Proxy Behavior + + 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.) + + 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. + + 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. + + Proxies MUST follow the recommendations in Section 5 to determine the + order in which to contact the downstream servers when routing a + request. + + + + + + +Camarillo, et al. Standards Track [Page 4] + +RFC 6157 IPv6 Transition in SIP April 2011 + + +3.1.1. Relaying Requests across Different Networks + + 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. + + 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. + + 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. + + 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. + + 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. + + 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 + + + +Camarillo, et al. Standards Track [Page 5] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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.) + + UAC Proxy UAS + (IPv4) P (IPv6) + | (IPv4/IPv6) | + | | | + +---F1--------->| | + | +---F2-------->| + | | | + | |<--F3---------+ + |<--F4----------+ | + ... ... ... + | | | + V V V + + F1: INVITE sip:alice@example.com SIP/2.0 + ... + + F2: INVITE sip:alice@2001:db8::10 SIP/2.0 + Record-Route: + Record-Route: + ... + + F3: SIP/2.0 200 OK + Record-Route: + Record-Route: + ... + + F4: SIP/2.0 200 OK + Record-Route: + Record-Route: + ... + + Figure 1: Relaying requests across different networks + + 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. + + + + + +Camarillo, et al. Standards Track [Page 6] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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. + +3.2. User Agent Behavior + + 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. + + 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. + +4. The Media Layer + + 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. + + 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]. + + 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. + + 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 + + + + +Camarillo, et al. Standards Track [Page 7] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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. + + 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. + + 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. + + 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: + + 1. Networks where public IPv4 addresses are scarce and it is + preferable to make large deployments only on IPv6. + + 2. Networks utilizing Layer-2's that do not support concurrent IPv4 + and IPv6 usage on the same link. + +4.1. Updates to RFC 3264 + + This section provides a normative update to RFC 3264 [4] in the + following manner: + + 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., ::). + + + + +Camarillo, et al. Standards Track [Page 8] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + 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. + +4.2. Initial Offer + + 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. + + 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. + + 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.) + + 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. + + + + + + + +Camarillo, et al. Standards Track [Page 9] + +RFC 6157 IPv6 Transition in SIP April 2011 + + +4.3. Connectivity Checks + + 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. + +5. Contacting Servers: Interaction of RFC 3263 and RFC 3484 + + 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. + + 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]. + + 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. + + 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. + + 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. + + + +Camarillo, et al. Standards Track [Page 10] + +RFC 6157 IPv6 Transition in SIP April 2011 + + +6. Security Considerations + + 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. + +7. Acknowledgments + + 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. + +8. References + +8.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [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. + + + + + +Camarillo, et al. Standards Track [Page 11] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + the Session Description Protocol (SDP)", RFC 3264, June 2002. + + [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol + (SIP): Locating SIP Servers", RFC 3263, June 2002. + + [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. + + [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A + Protocol for Network Address Translator (NAT) Traversal for + Offer/Answer Protocols", RFC 5245, April 2010. + + [8] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using + Relays around NAT (TURN) Extension for IPv6", RFC 6156, April + 2011. + + [9] Draves, R., "Default Address Selection for Internet Protocol + version 6 (IPv6)", RFC 3484, February 2003. + +8.2. Informative References + + [10] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration + Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) + Servers", RFC 3319, July 2003. + + [11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- + for-IPv4) Option for Session Initiation Protocol (SIP) + Servers", RFC 3361, August 2002. + + [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. + + [13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + + [14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + + [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. + + + + + +Camarillo, et al. Standards Track [Page 12] + +RFC 6157 IPv6 Transition in SIP April 2011 + + + [16] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, + "Application Aspects of IPv6 Transition", RFC 4038, March 2005. + + [17] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for + IPv6 Hosts and Routers", RFC 4213, October 2005. + + [18] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session + Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. + + [19] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On- + Link Assumption Considered Harmful", RFC 4943, September 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 13] + +RFC 6157 IPv6 Transition in SIP April 2011 + + +Appendix A. Sample IPv4/IPv6 DNS File + + 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. + + + ... + _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 + ... + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 14] + +RFC 6157 IPv6 Transition in SIP April 2011 + + +Authors' Addresses + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + Karim El Malki + Athonet + AREA Science Park + 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 + + Phone: +1 630 224 0216 + EMail: vkg@bell-labs.com + + + + + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 15] + -- cgit v1.2.3