idnits 2.17.1 draft-reddy-mmusic-ice-happy-eyeballs-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 abstract seems to contain references ([RFC5245]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 09, 2013) is 3788 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 normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 2 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 P. Martinsen 5 Expires: June 12, 2014 Cisco 6 December 09, 2013 8 Happy Eyeballs Extension for ICE 9 draft-reddy-mmusic-ice-happy-eyeballs-04 11 Abstract 13 This document provides guidelines on how to make ICE [RFC5245] 14 conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths 15 exists. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 12, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 53 2. Improving ICE Dual-stack Fairness . . . . . . . . . . . . . . 2 54 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 58 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 There is a need to introduce more fairness in the handling of 64 connectivity checks in dual-stack IPv4/IPv6 ICE scenarios. 65 Section 4.1.2.1 of ICE [RFC5245] points to [RFC3484] for prioritizing 66 among the different IP families. [RFC3484] is obsoleted by [RFC6724] 67 but following the recommendations from the updated RFC will still 68 lead to prioritization of IPv6 over IPv4 with the same candidate 69 type. There can be a lot of ICE candidates belonging to one address 70 family which results in user-noticable setup delays if the path for 71 that address family is broken. 73 To avoid such user-noticable delays when the IPv6 path or IPv4 path 74 is broken, this specification encourages earlier checking of the 75 other address family. Greater IP address family fairness into ICE 76 connectivity checks will lead to more sustained IPv6 deployment (so 77 users will no longer have an incentive to disable IPv6), which incurs 78 only a small penalty for the IPv4 connectivity checks. 80 1.1. Notational Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 This document uses terminology defined in [RFC5245]. 88 2. Improving ICE Dual-stack Fairness 90 Candidates SHOULD be prioritized such that a long sequence of 91 candidates belonging to the same address family be interleaved with 92 candidates from the alternate IP family. For example, promoting IPv4 93 candidates in the presence of many IPv6 addresses such that an IPv4 94 address candidate is always present after a small sequence of IPv6 95 addresses. This makes ICE connectivity checks more responsive to 96 failures of an address family by reordering the candidates such that 97 IPv6 and IPv4 candidates get a fair chance during connectivity 98 checks. 100 An ICE agent can choose an algorithm or a technique of its choice to 101 promote IPv4 candidates. 103 3. Compatibility 105 ICE [RFC5245] section 4.1.2 states that the formula in section 106 4.1.2.1 SHOULD be used. Failing to do so may lead to ICE taking 107 longer to converge as the checklist no longer will be coordinated. 108 Therefore responsiveness of ICE candidate checks are improved when 109 both sides support Happy-Eyeballs, both sides have the same number of 110 candidate pairs, and both sides use the same Happy Eyeballs promotion 111 algorithm. 113 If each ICE agent uses a different algorithm to promote IPv4 114 candidates, ICE connectivity checks will be as responsive as the 115 least aggressive algorithm. This is because the MAX/MIN candiate- 116 pair logic ensures that for a particular agent, a lower-priority 117 candidate is never used (for media) until all higher-priority 118 candidates have been tried. 120 If only one ICE agent supports Happy-Eyeballs, there is potentially 121 no change in pacing of ICE connectivity checks and the situation is 122 no worse than what exists today 124 4. IANA Considerations 126 None. 128 5. Security Considerations 130 STUN connectivity check using MAC computed during key exchanged in 131 the signaling channel provides message integrity and data origin 132 authentication as described in section 2.5 of [RFC5245] apply to this 133 use. 135 6. Acknowledgements 137 Authors would like to thank Dan Wing, Ari Keranen, Bernard Aboba, 138 Martin Thomson and Jonathan Lennox for their comments and review. 140 7. Normative References 142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 143 Requirement Levels", BCP 14, RFC 2119, March 1997. 145 [RFC3484] Draves, R., "Default Address Selection for Internet 146 Protocol version 6 (IPv6)", RFC 3484, February 2003. 148 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 149 (ICE): A Protocol for Network Address Translator (NAT) 150 Traversal for Offer/Answer Protocols", RFC 5245, April 151 2010. 153 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 154 "Default Address Selection for Internet Protocol Version 6 155 (IPv6)", RFC 6724, September 2012. 157 Authors' Addresses 159 Tirumaleswar Reddy 160 Cisco Systems, Inc. 161 Cessna Business Park, Varthur Hobli 162 Sarjapur Marathalli Outer Ring Road 163 Bangalore, Karnataka 560103 164 India 166 Email: tireddy@cisco.com 168 Prashanth Patil 169 Cisco Systems, Inc. 170 Cessna Business Park, Varthur Hobli 171 Sarjapur Marathalli Outer Ring Road 172 Bangalore 173 India 175 Email: praspati@cisco.com 177 Paal-Erik Martinsen 178 Cisco Systems, Inc. 179 Philip Pedersens vei 22 180 Lysaker, Akershus 1325 181 Norway 183 Email: palmarti@cisco.com