idnits 2.17.1 draft-ietf-sipcore-dns-dual-stack-00.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 (April 25, 2014) is 3653 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: October 27, 2014 Cisco Systems 6 April 25, 2014 8 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP 9 Network 10 draft-ietf-sipcore-dns-dual-stack-00 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. As SIP networks increasingly transition from IPv4-only 18 to dual-stack, a quality user experience must be ensured for dual- 19 stack SIP implementations. This document supplements the DNS 20 procedures described in RFC 3263 for dual-stack SIP implementations 21 and ensures that they properly align to the optimizations detailed by 22 Happy Eyeballs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 27, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 4 62 4.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4 63 4.2. Indicating Address Family Preference in DNS SRV Records . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The core SIP [RFC3261] RFCs were written with support for both IPv4 75 and IPv6 in mind, but they were not fully equipped to handle highly 76 hybridized environments during this transitional phase of migration 77 from IPv4 to IPv6 networks, where many server and client 78 implementations run on dual-stack hosts. In such environments, a 79 dual-stack host will likely suffer greater connection delay, and by 80 extension an inferior user experience, than an IPv4-only host. The 81 need to remedy this diminished performance of dual-stack hosts led to 82 the development of the Happy Eyeballs [RFC6555] algorithm, which has 83 since been implemented in many applications. 85 RFC 6157[RFC6157] focuses on handling media in a dual-stack network 86 path between two SIP user agents (UAs). This doesn't solve the 87 signalling issues that can occur when trying to find the best network 88 path to the next hop SIP server. 90 [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC 6157, 91 especially relative to the additional requirement that DNS be 92 populated such that a certain address family is preferred.]] 94 This document aims to provide a more holistic design solution by 95 clarifying the DNS lookup procedures of RFC 3263[RFC3263] to ensure 96 enhanced performance, and consequently user experience, in highly 97 hybridized dual-stack SIP networks. The procedures described herein 98 are such that a dual-stack client SHOULD look up both A and AAAA 99 records in DNS and then select the best way to set up a network flow. 100 The details of how the latter is done is considered out of scope for 101 this document. See the Happy Eyeballs algorithm and implementation 102 and design considerations in RFC 6555 [RFC6555] for more information 103 about issues with setting up dual-stack network flows. 105 2. Notational Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. Terminology 113 RFC 3261 [RFC3261] defines additional terms used in this document 114 that are specific to the SIP domain such as "proxy"; "registrar"; 115 "redirect server"; "user agent server" or "UAS"; "user agent client" 116 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 117 "transaction"; "server transaction". 119 This document uses the term "SIP Server" that is defined to include 120 the following SIP entities: user agent server, registrar, redirect 121 server, a SIP proxy in the role of user agent server, and a B2BUA in 122 the role of a user agent server. 124 This document also uses the following terminology to make clear 125 distinction between SIP entities supporting only IPv4, only IPv6 or 126 supporting both IPv4 and IPv6. 128 IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling 129 and media only on the IPv4 network. It does not understand IPv6 130 addresses. 132 IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling 133 and media only on the IPv6 network. It does not understand IPv4 134 addresses. 136 IPv4/IPv6 UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and 137 media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known 138 (and will be referred to in this document) as a "dual-stack" 139 [RFC4213] UA/UAC/UAS. 141 4. DNS Procedures in a Dual-Stack Network 143 This specification introduces two normative DNS lookup procedures. 144 These are designed to improve the performace of dual-stack clients in 145 IPv4/IPv6 networks. 147 4.1. Dual-Stack SIP UA DNS Record Lookup Procedure 149 Once the transport protocol has been determined, the procedure for 150 discovering an ip address if the TARGET is not a numeric IP address 151 but the port is explicitly stated in the URI, is detailed in 152 Section 4.2 of RFC 3263[RFC3263]. The piece relevant to to this 153 discussion is: 155 "If the TARGET was not a numeric IP address, but a port is present 156 in the URI, the client performs an A or AAAA record lookup of the 157 domain name. The result will be a list of IP addresses, each of 158 which can be contacted at the specific port from the URI and 159 transport protocol determined previously." 161 Section 4.2 of RFC 3263 [RFC3263] also goes on to describe the 162 complete procedure for discovering an ip address if the TARGET is not 163 a numeric IP address, and no port is present in the URI. The piece 164 relevant to to this discussion is: 166 "If no SRV records were found, the client performs an A or AAAA 167 record lookup of the domain name. The result will be a list of IP 168 addresses, each of which can be contacted using the transport 169 protocol determined previously, at the default port for that 170 transport. Processing then proceeds as described above for an 171 explicit port once the A or AAAA records have been looked up." 173 Happy Eyeballs [RFC6555] has proven that looking up the "A or AAAA 174 record" is not an effective practice for dual-stack clients and that 175 it can add significant connection delay and greatly degrade user 176 experience. Therefore, this document makes the following normative 177 addendum to the DNS lookup procedures of Section 4.2 of RFC 3263 178 [RFC3263] for IPv4/IPv6 hybrid SIP networks and recommends it as a 179 best practice for such dual-stack networks: 181 The dual-stack client SHOULD perform an A and AAAA record lookup 182 of the domain name and add the respective IPv4/IPv6 addresses to 183 the list of IP addresses to be contacted. 185 4.2. Indicating Address Family Preference in DNS SRV Records 187 The Happy Eyeballs algorithm [RFC6555] is particularly effective when 188 dual-stack client applications have significant performance 189 differences in their IPv4 or IPv6 network paths. In this common 190 scenario it is often necessary for a dual-stack client to indicate a 191 preference for either IPv4 or IPv6. A service may use DNS SRV 192 records to indicate such a preference for an address family. This 193 way, a server with a high-latency and/or low-capacity IPv4 tunnel may 194 indicate a preference for being contacted using IPv6. A server that 195 wishes to do this can use the lowest SRV priority to publish 196 hostnames that only resolve in IPv6 and the next priority with host 197 names that resolve in both address families. 199 When indicating address family preference through SRV, IPv4-only and/ 200 or IPv6-only clients should be prepared to handle SRV record sets 201 that don't resolve into an ip address in the address family used by 202 that client. In such a case, the client should simply proceed to the 203 next priority and try the hostnames in the alternate address family. 205 5. Security Considerations 207 This document introduces two new normative procedures to the existing 208 DNS procedures used to locate SIP servers. While both of these 209 procedures are optimizations designed to improve the performance of 210 dual-stack clients, neither introduces any new security 211 considerations. 213 The specific security vulnerabilities, attacks and threat models of 214 the various protocols discussed in this document (SIP, DNS, SRV 215 records, Happy Eyeballs requirements and algorithm, etc.) are well 216 documented in their respective specifications. 218 6. IANA Considerations 220 This document does not require any actions by IANA. 222 7. Acknowledgments 224 The author would like to acknowledge the support and contribution of 225 the SIP Forum IPv6 Working Group. This document is based on a lot of 226 tests and discussions at SIPit events, organized by the SIP Forum. 228 This document has benefited from the expertise and review feedback of 229 many participants of the IETF DISPATCH and SIPCORE WG mailing lists 230 as well as those on the SIP Forum IPv6 Task Group mailing list. The 231 authors wish to specifically call out the efforts and express their 232 gratitude for the detailed and thoughtful comments and corrections of 233 Dan Wing, Brett Tate, Rifaat Shekh-Yusef, Carl Klatsky, Dale Worley, 234 Mary Barnes, Keith Drage, Vijay Gurbani and Cullen Jennings. 236 The authors also thank the SIPCORE WG chairs, Paul Kyzivat and Adam 237 Roach, and assigned Area Director, Richard Barnes, for their support 238 and thorough evaluation of this work. 240 8. References 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 248 Protocol (SIP): Locating SIP Servers", RFC 3263, June 249 2002. 251 8.2. Informative References 253 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 254 A., Peterson, J., Sparks, R., Handley, M., and E. 255 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 256 June 2002. 258 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 259 for IPv6 Hosts and Routers", RFC 4213, October 2005. 261 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 262 Transition in the Session Initiation Protocol (SIP)", RFC 263 6157, April 2011. 265 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 266 Dual-Stack Hosts", RFC 6555, April 2012. 268 Authors' Addresses 270 Olle E. Johansson 271 Edvina AB 272 Runbovaegen 10 273 Sollentuna SE-192 48 274 SE 276 Email: oej@edvina.net 277 Gonzalo Salgueiro 278 Cisco Systems 279 7200-12 Kit Creek Road 280 Research Triangle Park, NC 27709 281 US 283 Email: gsalguei@cisco.com