idnits 2.17.1 draft-johansson-sip-dual-stack-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2014) is 3487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE O. Johansson 3 Internet-Draft Edvina AB 4 Intended status: Standards Track G. Salgueiro 5 Expires: April 9, 2015 Cisco Systems 6 October 6, 2014 8 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP 9 Network 10 draft-johansson-sip-dual-stack-03 12 Abstract 14 RFC 3263 defines how a Session Initiation Protocol (SIP) 15 implementation, given a SIP Uniform Resource Identifier (URI), should 16 locate the next hop SIP server using Domain Name System (DNS) 17 procedures. The specification repeatedly states that the 18 implementation should look up IPv4 or IPv6 addresses. This is not a 19 suitable solution and one that can cause severely degraded user 20 experience dual-stack clients, as detailed in the Happy Eyeballs 21 specification. This document specifies amended procedures for dual- 22 stack SIP implementations so that they look up both IPv4 and IPv6 23 addresses. This way, the SIP implementation can find the preferred 24 network path and protocol with an improved chance of successfully 25 reaching the desired service. This document also clarifies DNS SRV 26 usage for single-stack clients. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 9, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology and Conventions Used in This Document . . . . . . 3 64 3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 3 65 3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4 66 3.2. Indicating Address Family Preference in DNS SRV Records . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 7.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 The core SIP [RFC3261] RFCs were written with support for both IPv4 78 and IPv6 in mind, but they were not fully equipped to handle highly 79 hybridized environments during this transitional phase of migration 80 from IPv4 to IPv6 networks, where many server and client 81 implementations run on dual stack hosts. In such environments, a 82 dual-stack host will likely suffer greater connection delay, and by 83 extension an inferior user experience, than an IPv4-only host. The 84 need to remedy this diminished performance of dual-stack hosts led to 85 the development of the Happy Eyeballs [RFC6555] algorithm, that has 86 since been implemented in many applications. 88 RFC 6157[RFC6157] focuses on handling media in a dual-stack network 89 path between two SIP user agents (UAs). This doesn't solve the 90 signalling issues that can occur when trying to find the best network 91 path to the next hop SIP server. 93 This document updates RFC 3263[RFC3263] procedures so that a dual- 94 stack client SHOULD look up both A and AAAA records in DNS and then 95 select the best way to set up a network flow. The details of how the 96 latter is done is considered out of scope for this document. See the 97 Happy Eyeballs algorithm and implementation and design considerations 98 in RFC 6555[RFC6555] for more information about issues with setting 99 up dual-stack network flows. 101 2. Terminology and Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 RFC 3261 [RFC3261] defines additional terms used in this document 108 that are specific to the SIP domain such as "proxy"; "registrar"; 109 "redirect server"; "user agent server" or "UAS"; "user agent client" 110 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 111 "transaction"; "server transaction". 113 This document uses the term "SIP Server" that is defined to include 114 the following SIP entities: user agent server, registrar, redirect 115 server, a SIP proxy in the role of user agent server, and a B2BUA in 116 the role of a user agent server. 118 This document also uses the following terminology to make clear 119 distinction between SIP entities supporting only IPv4, only IPv6 or 120 supporting both IPv4 and IPv6. 122 IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling 123 and media only on the IPv4 network. It does not understand IPv6 124 addresses. 126 IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling 127 and media only on the IPv6 network. It does not understand IPv4 128 addresses. 130 IPv4/IPv6 UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and 131 media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known 132 (and will be referred to in this document) as a "dual-stack" 133 [RFC4213] UA/UAC/UAS. 135 3. DNS Procedures in a Dual-Stack Network 137 This specification introduces two normative DNS lookup procedures. 138 These are designed to improve the performace of dual-stack clients in 139 IPv4/IPv6 networks. 141 3.1. Dual-Stack SIP UA DNS Record Lookup Procedure 143 Once the transport protocol has been determined, the procedure for 144 discovering an ip address if the TARGET is not a numeric IP address 145 but the port is explicitly stated in the URI, is detailed in 146 Section 4.2 of RFC 3263[RFC3263]. The piece relevant to to this 147 discussion is: 149 "If the TARGET was not a numeric IP address, but a port is present 150 in the URI, the client performs an A or AAAA record lookup of the 151 domain name. The result will be a list of IP addresses, each of 152 which can be contacted at the specific port from the URI and 153 transport protocol determined previously." 155 Section 4.2 of RFC 3263 [RFC3263] also goes on to describe the 156 complete procedure for discovering an ip address if the TARGET is not 157 a numeric IP address, and no port is present in the URI. The piece 158 relevant to to this discussion is: 160 "If no SRV records were found, the client performs an A or AAAA 161 record lookup of the domain name. The result will be a list of IP 162 addresses, each of which can be contacted using the transport 163 protocol determined previously, at the default port for that 164 transport. Processing then proceeds as described above for an 165 explicit port once the A or AAAA records have been looked up." 167 Happy Eyeballs [RFC6555] has proven that looking up the "A or AAAA 168 record" is not an effective practice for dual-stack clients that can 169 add significant connection delay and greatly degrade user experience. 170 A dual-stack client SHOULD perform an A and AAAA record lookup of the 171 domain name and add the respective IPv4/IPv6 addresses to the list of 172 IP addresses to be contacted. This is a normative update to the 173 procedures described in Section 4.2 of RFC 3263 [RFC3263]. 175 3.2. Indicating Address Family Preference in DNS SRV Records 177 The Happy Eyeballs algorithm is particularly effective when dual- 178 stack client applications have have significant performance 179 differences in their IPv4 or IPv6 network paths. In this common 180 scenario it is often necessary for a dual-stack client to indicate a 181 preference for either IPv4 or IPv6. A service may use DNS SRV 182 records to indicate such a preference for an address family. This 183 way, a server with a high-latency and/or low-capacity IPv4 tunnel may 184 indicate a preference for being contacted using IPv6. A server that 185 wishes to do this can use the lowest SRV priority to publish 186 hostnames that only resolve in IPv6 and the next priority with host 187 names that resolve in both address families. 189 When indicating address family preference through SRV, a single 190 stack-clients should be prepared to handle SRV record sets that don't 191 resolve into an ip address in the address family used by the client. 192 In such a case, the client should simply proceed to the next priority 193 and try those hostnames. 195 4. Security Considerations 197 This document makes two normative changes to the existing DNS 198 procedures used to locate SIP servers in a dual-stack network. One 199 change updates the procedure described in RFC 3263 for dual-stack 200 clients and recommends both A and AAAA record lookups of the domain 201 name. The other update is simply the ability to indicate preference 202 for a particular address family in SRV records. While both of these 203 changes to current procedures are optimizations designed to improve 204 the performance of dual-stack clients, neither introduces any new 205 security considerations. The specific security vulnerabilities, 206 attacks and threat models of the various protocols discussed in this 207 document (SIP, DNS, SRV records, etc.) are well documented in their 208 respective specifications. 210 5. IANA Considerations 212 This document does not require any actions by IANA. 214 6. Acknowledgements 216 The author would like to acknowledge the support and contribution of 217 the SIP Forum IPv6 Working Group. This document is based on a lot of 218 tests and discussions at SIPit events, organized by the SIP Forum. 220 This document has benefited from the expertise and review feedback of 221 Dan Wing, Brett Tate, Rifaat Shekh-Yusef and Carl Klatsky. 223 7. References 225 7.1. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 231 Protocol (SIP): Locating SIP Servers", RFC 3263, June 232 2002. 234 7.2. Informative References 236 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 237 A., Peterson, J., Sparks, R., Handley, M., and E. 238 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 239 June 2002. 241 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 242 for IPv6 Hosts and Routers", RFC 4213, October 2005. 244 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 245 Transition in the Session Initiation Protocol (SIP)", RFC 246 6157, April 2011. 248 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 249 Dual-Stack Hosts", RFC 6555, April 2012. 251 Authors' Addresses 253 Olle E. Johansson 254 Edvina AB 255 Runbovaegen 10 256 Sollentuna SE-192 48 257 SE 259 Email: oej@edvina.net 261 Gonzalo Salgueiro 262 Cisco Systems 263 7200-12 Kit Creek Road 264 Research Triangle Park, NC 27709 265 US 267 Email: gsalguei@cisco.com