idnits 2.17.1 draft-reddy-mmusic-ice-happy-eyeballs-01.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 == Line 173 has weird spacing: '...ndidate pair...' -- The document date (July 11, 2013) is 3943 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) == Unused Reference: 'RFC3484' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 344, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6336 (Obsoleted by RFC 8839) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track D. Wing 5 Expires: January 12, 2014 Cisco 6 July 11, 2013 8 Happy Eyeballs Extension for ICE 9 draft-reddy-mmusic-ice-happy-eyeballs-01 11 Abstract 13 This document specifies requirements for algorithms that make ICE 14 connectivity checks more responsive by reducing delays in dual-stack 15 host ICE connectivity checks when there is a path failure for the 16 address family preferred by the application or by the operating 17 system. As IPv6 is usually preferred, the procedures in this 18 document helps avoid user-noticeable delays when the IPv6 path is 19 broken or excessively slow. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 12, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 57 3. Candidates Priority . . . . . . . . . . . . . . . . . . . . . 2 58 4. Algorithm overview . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Processing the Results . . . . . . . . . . . . . . . . . 5 60 5. Indicating Happy-Eyeballs . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 9.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 In situations where there are many IPv6 addresses, ICE [RFC5245] will 72 prefer IPv6 candidates [RFC6724] and will attempt connectivity checks 73 on all the IPv6 candidates before trying an IPv4 candidate. If the 74 IPv6 path is broken, this fallback to IPv4 can consume a lot of time, 75 harming user satisfaction of dual-stack devices. 77 This document describes an algorithm that makes ICE connectivity 78 checks more responsive to failures of an address family by reordering 79 the candidate pairs such that IPv6 and IPv4 candidates get a fair 80 chance during connectivity checks. This document specifies 81 requirements for any such algorithm, with the goals that the ICE 82 agent need not be inordinately harmed with a simple reordering of the 83 candidate pairs. 85 2. Notational Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 This note uses terminology defined in [RFC5245]. 93 3. Candidates Priority 95 A prioritization formula is used by ICE [RFC5245] so that most 96 preferred address pairs are tested first, and if a sufficiently good 97 pair is discovered, the tests can be stopped. With IPv6, addresses 98 obtained from local network interfaces, called host candidates, are 99 recommended as high-priority ones to be tested first since if they 100 work, they provide usually the best path between the two hosts. The 101 ICE specification recommends to use the rules defined in [RFC6724] as 102 part of the prioritization formula for IPv6 host candidates and 103 [I-D.keranen-mmusic-ice-address-selection] updates the ICE rules on 104 how IPv6 host candidates are selected. 106 For dual-stack hosts the preference for IPv6 host candidates is 107 higher than IPv4 host candidates based on precedence value of IP 108 addresses described in [RFC6724]. IPv6 server reflexive candidates 109 have higher precedence than IPv4 server reflexive candidate since 110 NPTv6 is stateless and transport-agnostic. 112 (highest) IPv6 Host Candidate 113 IPv4 Host Candidate 114 IPv6 Server Reflexive Candidate 115 IPv4 Server Reflexive Candidate 116 IPv6 Relayed Transport Candidate 117 (lowest) IPv4 Relayed Transport Candidate 119 Figure 1: Candidate Preferences in decreasing order 121 By using the technique described in Section 4, if there are both IPv6 122 and IPv4 addresses in the check list, and the first 'N' candidates 123 are of the same IP address family, then the highest-priority 124 candidate pair of the other address family is promoted to position N 125 in the check list thus making ICE connectivity checks more responsive 126 to failures of an address family. 128 Note: The algorithm works even if the administrator changes the 129 policy table to prefer IPv4 addresses over IPv6 addresses as defined 130 in [RFC6724] 132 4. Algorithm overview 134 The Happy Eyeballs Extension for ICE algorithm proposes the 135 following: 137 1. Indicate support for ICE Happy Eyeballs in the SDP offer if the 138 end-point is dual-stack. The end-point will also include the 139 position 'N' at which promotion is to occur. 141 2. After SDP offer/answer exchange if both end points support ICE 142 Happy Extension for ICE algorithm the following steps are 143 performed by the ICE agents after computing the candidate pair 144 priority, ordering and pruning the pairs (section 5.7.2, 5.7.3 of 145 [RFC5245]) 147 a. If the first 'N' candidate pairs in the check list are of the 148 same IP address family, then the highest-priority candidate 149 pair of the other address family is promoted to position 'N' 150 in the list. 152 b. Step b is repeated for candidate pairs that are next in the 153 check list. This is continued until all candidate pairs of 154 the preferred address family are exhausted. 156 The result of these steps is that after every consecutive 'N' 157 candidate pairs of the preferred family, a candidate pair of the 158 other family is inserted. 160 The following figure illustrates the result of the algorithm on 161 candidate pairs: 163 Before Happy Eyeballs Extension for ICE algorithm : 164 ---------------------------------------------------- 165 (highest) IPv6 Host Candidate-1 pair 166 IPv6 Host Candidate-2 pair 167 IPv6 Host Candidate-3 pair 168 IPv6 Host Candidate-4 pair 169 IPv6 Host Candidate-5 pair 170 IPv6 Host Candidate-6 pair 171 IPv6 Host Candidate-7 pair 172 IPv4 Host Candidate pair 173 IPv6 Server Reflexive Candidate pair 174 IPv4 Server Reflexive Candidate pair 175 IPv6 Relayed Transport Candidate pair 176 (lowest) IPv4 Relayed Transport Candidate pair 178 After Happy Eyeballs Extension for ICE algorithm : 179 -------------------------------------------------- 180 (highest) IPv6 Host Candidate-1 pair 181 IPv6 Host Candidate-2 pair 182 IPv6 Host Candidate-3 pair 183 IPv4 Host Candidate pair ---> Promoted pair 184 IPv6 Host Candidate-4 pair 185 IPv6 Host Candidate-5 pair 186 IPv6 Host Candidate-6 pair 187 IPv4 Server Reflexive Candidate pair ---> Promoted pair 188 IPv6 Host Candidate-7 pair 189 IPv6 Server Reflexive Candidate pair 190 IPv6 Relayed Transport Candidate pair 191 (lowest) IPv4 Relayed Transport Candidate pair 193 4.1. Processing the Results 195 If ICE connectivity checks using an IPv4 candidate is successful then 196 ICE Agent will performs as usual "Discovering Peer Reflexive 197 Candidates" (Section 7.1.3.2.1 of [RFC5245]), "Constructing a Valid 198 Pair" (Section 7.1.3.2.2 of [RFC5245]), "Updating Pair States" 199 (Section 7.1.3.2.3 of [RFC5245]), "Updating the Nominated Flag" 200 (Section 7.1.3.2.4 of [RFC5245]). 202 If ICE connectivity checks using an IPv4 candidate is successful for 203 each component of the media stream and connectivity checks using IPv6 204 candidates is not yet successful, the ICE endpoint will declare 205 victory, conclude ICE for the media stream and start sending media 206 using IPv4. However, it is also possible that ICE endpoint continues 207 to perform ICE connectivity checks with IPv6 candidate pairs and if 208 checks using higher-priority IPv6 candidate pair is successful then 209 media stream can be moved to the IPv6 candidate pair. Continuing to 210 perform connectivity checks can be useful for subsequent connections, 211 to optimize which connectivity checks are tried first. Such 212 optimization is out of scope of this document. 214 The following diagram shows the behaviour during the connectivity 215 check when Alice calls Bob and Agent Alice is the controlling agent 216 and uses the aggressive nomination algorithm. "USE-CAND" implies the 217 presence of the USE-CANDIDATE attribute. 219 Alice Bob 220 | | 221 | SDP Offer; a=happy-eyeballs:2 | 222 | SDP Answer; a=happy-eyeballs:2 | 223 | | 224 | Bind Req USE-CAND Bind Req | 225 | using IPv6 using IPv6 | 226 |------------------>X X<-----------------------| 227 | Bind Req USE-CAND Bind Req | 228 | using IPv6 after Ta using IPv6 | 229 |------------------>X X<-----------------------| 230 | | 231 [after connectivity checks for 2 IPv6 addresses, try IPv4] | 232 | | 233 | Bind Req USE-CAND | 234 | using IPv4 | 235 |------------------------------------------------------------>| 236 | Bind Resp | 237 | using IPv4 | 238 |<----------------------------------------------------------- | 239 | RTP | 240 |============================================================>| 241 | Bind Req | 242 | using IPv4 | 243 |<------------------------------------------------------------| 244 | Bind Response | 245 | using IPv4 | 246 |------------------------------------------------------------>| 247 | RTP | 248 |<===========================================================>| 250 Figure 2: Happy Eyeballs Extension for ICE 252 5. Indicating Happy-Eyeballs 254 To indicate that Happy Eyeballs Extension for ICE algorithm defined 255 in this document is used, the ICE offerer MUST include ice-options 256 attribute with "happy-eyeballs:N" option identifier in the Session 257 Description Protocol (SDP) [RFC4566] ICE offer, where N indicates the 258 position at which promotion is to occur. If the ICE offer does not 259 include this option tag, the answerer SHOULD NOT utilize the updated 260 ICE algorithm defined in this document. If the offer included the 261 option tag and the answerer supports this specification, the answerer 262 SHOULD add the same option tag to the response and use the Happy 263 Eyeballs Extension for ICE algorithm. If the ICE answer does not 264 contain the option tag, the offerer SHOULD NOT use the updated ICE 265 algorithm. Recommended value for 'N' is 3. As IPv6 becomes more 266 prevalent, the value of 'N' can be increased as desired. 268 6. IANA Considerations 270 IANA is requested to register "happy-eyeballs" option identifier 271 under the "ICE Options" [RFC6336] registry. 273 The required registration information is as follows: 275 Option identifier: happy-eyeballs 277 Contact: Tirumaleswar Reddy, tireddy@cisco.com 279 Change control: IETF 281 Description: Existence of this option identifier indicates that Happy 282 Eyeballs Extension for ICE algorithm is used. 284 Reference: RFCXXXX 286 [RFC editor: replace XXXX with the RFC number of this document] 288 7. Security Considerations 290 STUN connectivity check using MAC computed during key exchanged in 291 the signaling channel provides message integrity and data origin 292 authentication as described in section 2.5 of [RFC5245] apply to this 293 use. 295 8. Acknowledgements 297 The authors would like to thank Bernard Aboba for his inputs. 299 9. References 301 9.1. Normative References 303 [I-D.keranen-mmusic-ice-address-selection] 304 Keraenen, A. and J. Arkko, "Update on Candidate Address 305 Selection for Interactive Connectivity Establishment 306 (ICE)", draft-keranen-mmusic-ice-address-selection-01 307 (work in progress), July 2012. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC3484] Draves, R., "Default Address Selection for Internet 313 Protocol version 6 (IPv6)", RFC 3484, February 2003. 315 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 316 Description Protocol", RFC 4566, July 2006. 318 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 319 Description Protocol", RFC 4566, July 2006. 321 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 322 (ICE): A Protocol for Network Address Translator (NAT) 323 Traversal for Offer/Answer Protocols", RFC 5245, April 324 2010. 326 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 327 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 328 October 2008. 330 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 331 Relays around NAT (TURN): Relay Extensions to Session 332 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 334 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 335 Interactive Connectivity Establishment (ICE) Options", RFC 336 6336, July 2011. 338 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 339 "Default Address Selection for Internet Protocol Version 6 340 (IPv6)", RFC 6724, September 2012. 342 9.2. Informative References 344 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 345 Translator (NAT) Terminology and Considerations", RFC 346 2663, August 1999. 348 Authors' Addresses 350 Tirumaleswar Reddy 351 Cisco Systems, Inc. 352 Cessna Business Park, Varthur Hobli 353 Sarjapur Marathalli Outer Ring Road 354 Bangalore, Karnataka 560103 355 India 357 Email: tireddy@cisco.com 359 Prashanth Patil 360 Cisco Systems, Inc. 361 Cessna Business Park, Varthur Hobli 362 Sarjapur Marthalli Outer Ring Road 363 Bangalore, Karnataka 560103 364 India 366 Email: praspati@cisco.com 368 Dan Wing 369 Cisco Systems, Inc. 370 170 West Tasman Drive 371 San Jose, California 95134 372 USA 374 Email: dwing@cisco.com