idnits 2.17.1 draft-ietf-sipcore-dns-dual-stack-04.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3263, but the abstract doesn't seem to directly say this. It does mention RFC3263 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3263, updated by this document, for RFC5378 checks: 2000-10-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2016) is 2978 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 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 Updates: RFC 3263 (if approved) G. Salgueiro 5 Intended status: Standards Track Cisco Systems 6 Expires: August 26, 2016 V. Gurbani 7 Bell Labs, Alcatel-Lucent 8 D. Worley, Ed. 9 Ariadne 10 February 23, 2016 12 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP 13 Network 14 draft-ietf-sipcore-dns-dual-stack-04 16 Abstract 18 RFC 3263 defines how a Session Initiation Protocol (SIP) 19 implementation, given a SIP Uniform Resource Identifier (URI), should 20 locate the next hop SIP server using Domain Name System (DNS) 21 procedures. As SIP networks increasingly transition from IPv4-only 22 to dual-stack, a quality user experience must be ensured for dual- 23 stack SIP implementations. This document updates the DNS procedures 24 described in RFC 3263 for dual-stack SIP implementations in 25 preparation for forthcoming specifications for applying Happy 26 Eyeballs to SIP. 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 August 26, 2016. 45 Copyright Notice 47 Copyright (c) 2016 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. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 4 66 4.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 4 67 4.2. Indicating Address Family Preference in DNS SRV Records . 5 68 5. Clarification of RFC 6157 . . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 72 9. Revision History . . . . . . . . . . . . . . . . . . . . . . 6 73 9.1. Changes from draft-ietf-sipcore-dns-dual-stack-03 to 74 draft-ietf-sipcore-dns-dual-stack-04 . . . . . . . . . . 6 75 9.2. Changes from draft-ietf-sipcore-dns-dual-stack-02 to 76 draft-ietf-sipcore-dns-dual-stack-03 . . . . . . . . . . 6 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 10.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 The Session Initiation Protocol (SIP, [RFC3261]) and the additional 85 documents that extended it provide support for both IPv4 and IPv6. 86 However, this support does not fully extend to the highly hybridized 87 environments that are characteristic of the transitional migratory 88 phase from IPv4 to IPv6 networks. During this phase, many server and 89 client implementations run on dual-stack hosts. In such 90 environments, a dual-stack host will likely suffer greater connection 91 delay, and by extension an inferior user experience, than an 92 IPv4-only host. The need to remedy this diminished performance of 93 dual-stack hosts led to the development of the Happy Eyeballs 94 [RFC6555] algorithm, which has since been implemented in many 95 protocols and applications. 97 This document updates the DNS lookup procedures of RFC 3263[RFC3263] 98 in preparation for the specification of the application of Happy 99 Eyeballs to SIP to provide enhanced performance, and consequently 100 user experience, in highly hybridized dual-stack SIP networks. The 101 procedures described herein are such that a dual-stack client should 102 look up both A and AAAA records in DNS and then select the best way 103 to set up a network flow. The details of how the latter is done is 104 considered out of scope for this document. See the Happy Eyeballs 105 algorithm and implementation and design considerations in RFC 6555 106 [RFC6555] for more information about issues with setting up dual- 107 stack network flows. 109 This document clarifies the interaction of [RFC3263] with [RFC6157] 110 as described in Section 5. 112 2. Notational Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Terminology 120 RFC 3261 [RFC3261] defines additional terms used in this document 121 that are specific to the SIP domain such as "proxy"; "registrar"; 122 "redirect server"; "user agent server" or "UAS"; "user agent client" 123 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 124 "transaction"; "server transaction". 126 This document uses the term "SIP Server" that is defined to include 127 the following SIP entities: user agent server, registrar, redirect 128 server, a SIP proxy in the role of user agent server, and a B2BUA in 129 the role of a user agent server. 131 This document also uses the following terminology to make clear 132 distinction between SIP entities supporting only IPv4, only IPv6 or 133 supporting both IPv4 and IPv6. 135 IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling 136 and media only on the IPv4 network. It does not understand IPv6 137 addresses. 139 IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling 140 and media only on the IPv6 network. It does not understand IPv4 141 addresses. 143 IPv4/IPv6 UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and 144 media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known 145 (and will be referred to in this document) as a "dual-stack" 146 [RFC4213] UA/UAC/UAS. 148 address records: The DNS records which translate a domain name into 149 addresses within the address family(ies) that the UA supports, as 150 A RR's provide IPv4 addresses and AAAA RR's provide IPv6 151 addresses. 153 4. DNS Procedures in a Dual-Stack Network 155 This specification introduces two normative DNS lookup procedures. 156 These are designed to improve the performance of dual-stack clients 157 in IPv4/IPv6 networks. 159 4.1. Dual-Stack SIP UA DNS Record Lookup Procedure 161 Once the transport protocol has been determined, the procedure for 162 discovering an IP address if the TARGET is not a numeric IP address 163 but the port is explicitly stated in the URI, is detailed in 164 Section 4.2 of RFC 3263[RFC3263]. The piece relevant to to this 165 discussion is: 167 If the TARGET was not a numeric IP address, but a port is present 168 in the URI, the client performs an A or AAAA record lookup of the 169 domain name. The result will be a list of IP addresses, each of 170 which can be contacted at the specific port from the URI and 171 transport protocol determined previously. 173 Section 4.2 of RFC 3263 [RFC3263] also goes on to describe the 174 procedure for discovering an IP address if the TARGET is not a 175 numeric IP address, and no port is present in the URI. The piece 176 relevant to to this discussion is: 178 If no SRV records were found, the client performs an A or AAAA 179 record lookup of the domain name. The result will be a list of IP 180 addresses, each of which can be contacted using the transport 181 protocol determined previously, at the default port for that 182 transport. Processing then proceeds as described above for an 183 explicit port once the A or AAAA records have been looked up. 185 Happy Eyeballs [RFC6555] documents that looking up the "A or AAAA 186 record" is not an effective practice for dual-stack clients and that 187 it can add significant connection delay and greatly degrade user 188 experience. Therefore, this document makes the following normative 189 addendum to the DNS lookup procedures of Section 4.2 of RFC 3263 190 [RFC3263] for IPv4/IPv6 hybrid SIP networks and recommends it as a 191 best practice for such dual-stack networks: 193 The dual-stack client SHOULD look up all address records (i.e., 194 for all address family(ies) that it supports) for the domain name 195 and add the resulting addresses to the list of IP addresses to be 196 contacted. A client MUST be prepared for DNS lookups to return 197 addresses in families that it does not support; such addresses 198 MUST be ignored as unusable and the supported addresses used as 199 specified herein. 201 4.2. Indicating Address Family Preference in DNS SRV Records 203 The Happy Eyeballs algorithm [RFC6555] is particularly effective when 204 dual-stack client applications have significant performance 205 differences in their IPv4 or IPv6 network paths. In this common 206 scenario it is often necessary for a dual-stack client to indicate a 207 preference for either IPv4 or IPv6. A service may use DNS SRV 208 records to indicate such a preference for an address family. This 209 way, a server with a high-latency and/or low-capacity IPv4 tunnel may 210 indicate a preference for being contacted using IPv6. A server that 211 wishes to do this can use the lowest SRV priority to publish 212 hostnames that only resolve in IPv6 and the next priority with host 213 names that resolve in both address families. 215 5. Clarification of RFC 6157 217 [RFC6157] defers to the Source and Destination Address Selection 218 algorithms defined in [RFC6724] (the successor of [RFC3484]) when 219 allowing a client to choose a specific server (c.f. Section 5 in 220 [RFC6157]). 222 This document clarifies the process: If SRV lookup is successful, the 223 major ordering of the list of destination addresses is determined by 224 the priority and weight fields of the SRV records as specified in 225 [RFC2782]. The (minor) ordering among the destinations derived from 226 the "target" field of a single SRV record is determined by [RFC6724]. 228 6. Security Considerations 230 This document introduces two new normative procedures to the existing 231 DNS procedures used to locate SIP servers. While both of these 232 procedures are optimizations designed to improve the performance of 233 dual-stack clients, neither introduces any new security 234 considerations. 236 The specific security vulnerabilities, attacks and threat models of 237 the various protocols discussed in this document (SIP, DNS, SRV 238 records, Happy Eyeballs requirements and algorithm, etc.) are well 239 documented in their respective specifications. 241 7. IANA Considerations 243 This document does not require any actions by IANA. 245 8. Acknowledgments 247 The authors would like to acknowledge the support and contribution of 248 the SIP Forum IPv6 Working Group. This document is based on a lot of 249 tests and discussions at SIPit events, organized by the SIP Forum. 251 This document has benefited from the expertise and review feedback of 252 many participants of the IETF DISPATCH and SIPCORE WG mailing lists 253 as well as those on the SIP Forum IPv6 Task Group mailing list. The 254 authors wish to specifically call out the efforts and express their 255 gratitude for the detailed and thoughtful comments and corrections of 256 Dan Wing, Brett Tate, Rifaat Shekh-Yusef, Carl Klatsky, Mary Barnes, 257 Keith Drage, Cullen Jennings and Simon Perreault. 259 The authors also thank the SIPCORE WG chairs, Paul Kyzivat and Adam 260 Roach, and assigned Area Director, Richard Barnes, for their support 261 and thorough evaluation of this work. 263 9. Revision History 265 [Note to RFC Editor: Please remove this entire section upon 266 publication as an RFC.] 268 9.1. Changes from draft-ietf-sipcore-dns-dual-stack-03 to draft-ietf- 269 sipcore-dns-dual-stack-04 271 Changed the "updates" specification to add RFC 3263 and remove RFC 272 6157. 274 Added Simon Perreault to the acknowledgments. 276 Minor wording changes. 278 9.2. Changes from draft-ietf-sipcore-dns-dual-stack-02 to draft-ietf- 279 sipcore-dns-dual-stack-03 281 Described the relationship to RFC 3263 as "update", since the 282 existing wording in 3263 is not what we want. Arguably, the new 283 wording is what was intended in 3263, but the existing wording either 284 does not say that or says it in a way that is easily misunderstood. 286 Described the relationship to RFC 6157 as "clarification", since the 287 described interaction between 3263 and 6157 appears to be the only 288 reasonable interpretation. 290 Revised wording, punctuation, and capitalization in various places. 292 Clarified that this draft does not document Happy Eyeballs for SIP, 293 but is preparatory for it. 295 Attempted to use "update" for text that is definitively a change to 296 the preexisting text and "clarify" for text that is a more clear 297 statement of the (presumed) intention of the preexisting text. 299 Removed normative words from section 1, the introduction. 301 Copied definition of "address records" from RFC 2782 (SRV records) to 302 allow the specifications to expand automatically to include any new 303 address families. 305 Relocated the text requiring a client to ignore addresses that it 306 discovers in address families it does not support from section 4.2 307 (which describes why the situation arises) to section 4.1 (which 308 describes how clients look up RRs). 310 Clarified the interaction with RFC 6157 (source and destination 311 address selection in IPv6) to specify what must have been intended: 312 The major sort of the destinations is the ordering determined by 313 priority/weight in the SRV records; the addresses derived from a 314 single SRV record's target are minorly sorted based on RFC 6157. 316 Removed editor's name from the acknowledgments list. 318 10. References 320 10.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 328 specifying the location of services (DNS SRV)", RFC 2782, 329 DOI 10.17487/RFC2782, February 2000, 330 . 332 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 333 Protocol (SIP): Locating SIP Servers", RFC 3263, 334 DOI 10.17487/RFC3263, June 2002, 335 . 337 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 338 Transition in the Session Initiation Protocol (SIP)", 339 RFC 6157, DOI 10.17487/RFC6157, April 2011, 340 . 342 10.2. Informative References 344 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 345 A., Peterson, J., Sparks, R., Handley, M., and E. 346 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 347 DOI 10.17487/RFC3261, June 2002, 348 . 350 [RFC3484] Draves, R., "Default Address Selection for Internet 351 Protocol version 6 (IPv6)", RFC 3484, 352 DOI 10.17487/RFC3484, February 2003, 353 . 355 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 356 for IPv6 Hosts and Routers", RFC 4213, 357 DOI 10.17487/RFC4213, October 2005, 358 . 360 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 361 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 362 2012, . 364 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 365 "Default Address Selection for Internet Protocol Version 6 366 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 367 . 369 Authors' Addresses 371 Olle E. Johansson 372 Edvina AB 373 Runbovaegen 10 374 Sollentuna SE-192 48 375 SE 377 Email: oej@edvina.net 378 Gonzalo Salgueiro 379 Cisco Systems 380 7200-12 Kit Creek Road 381 Research Triangle Park, NC 27709 382 US 384 Email: gsalguei@cisco.com 386 Vijay Gurbani 387 Bell Labs, Alcatel-Lucent 388 1960 Lucent Lane 389 Rm 9C-533 390 Naperville, IL 60563 391 US 393 Email: vkg@bell-labs.com 395 Dale R. Worley (editor) 396 Ariadne Internet Services 397 738 Main St. 398 Waltham, MA 02451 399 US 401 Email: worley@ariadne.com