idnits 2.17.1 draft-reddy-mmusic-ice-happy-eyeballs-05.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 (January 28, 2014) is 3735 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: August 1, 2014 Cisco 6 January 28, 2014 8 Happy Eyeballs Extension for ICE 9 draft-reddy-mmusic-ice-happy-eyeballs-05 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 exist. This will lead to more sustained IPv6 deployment as users 16 will no longer have an incentive to disable IPv6. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 1, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 54 3. Improving ICE Dual-stack Fairness . . . . . . . . . . . . . . 2 55 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 There is a need to introduce more fairness in the handling of 65 connectivity checks for different IP address families in dual-stack 66 IPv4/IPv6 ICE scenarios. Section 4.1.2.1 of ICE [RFC5245] points to 67 [RFC3484] for prioritizing among the different IP families. 68 [RFC3484] is obsoleted by [RFC6724] but following the recommendations 69 from the updated RFC will lead to prioritization of IPv6 over IPv4 70 for the same candidate type. Due to this, connectivity checks for 71 candidates of the same type (HOST, RFLX, RELAY) are sent such that an 72 IP address family is completely depleted before checks on the other 73 address family are started. This results in user noticeable setup 74 delays if the path for the prioritized address family is broken. 76 To avoid such user noticeable delays when either IPv6 or IPv4 path is 77 broken, this specification encourages intermingling the different 78 address families when connectivity checks are conducted. Introducing 79 IP address family fairness into ICE connectivity checks will lead to 80 more sustained dual-stack IPv4/IPv6 deployment as users will no 81 longer have an incentive to disable IPv6. The cost is a small 82 penalty to the address type that otherwise would have been 83 prioritized. 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 document uses terminology defined in [RFC5245]. 93 3. Improving ICE Dual-stack Fairness 95 Candidates SHOULD be prioritized such that a long sequence of 96 candidates belonging to the same address family will be intermingled 97 with candidates from an alternate IP family. For example, promoting 98 IPv4 candidates in the presence of many IPv6 candidates such that an 99 IPv4 address candidate is always present after a small sequence of 100 IPv6 candidates, i.e., reordering candidates such that both IPv6 and 101 IPv4 candidates get a fair chance during the connectivity check 102 phase. This makes ICE connectivity checks more responsive to broken 103 path failures of an address family. 105 An ICE agent can choose an algorithm or a technique of its choice to 106 ensure that the resulting check lists have a fair intermingled mix of 107 IPv4 and IPv6 address families. Modifying the check list directly 108 can lead to uncoordinated local and remote check lists that result in 109 ICE taking longer to complete. The best approach is to modify the 110 formula for calculating the candidate priority value described in ICE 111 [RFC5245] section 4.1.2.1. 113 4. Compatibility 115 ICE [RFC5245] section 4.1.2 states that the formula in section 116 4.1.2.1 SHOULD be used to calculate the candidate priority. The 117 formula is as follows: 119 priority = (2^24)*(type preference) + 120 (2^8)*(local preference) + 121 (2^0)*(256 - component ID) 123 ICE [RFC5245] section 4.1.2.2 has guidelines for how the type 124 preference value should be chosen. Instead of having a static value 125 for IPv4 and a static value for IPv6 type of addresses, it is 126 possible to choose this value dynamically in such a way that IPv4 and 127 IPv6 address candidate priorities ends up intermingled. 129 The local and remote agent can have different algorithms for choosing 130 the type preference value without any impact on coordination between 131 the local and remote check list. 133 The check list is made up by candidate pairs. A candidate pair is 134 two candidates paired up and given a candidate pair priority as 135 described in [RFC5245] section 5.7.2. Using the pair priority 136 formula: 138 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 140 Where G is the candidate provided by the controlling agent and D the 141 priority provided by the controlled agent. This ensures that the 142 local and remote check lists are coordinated. 144 Even if the two agents have different algorithms for choosing the 145 candidate priority value to get an intermingled set of IPv4 and IPv6 146 candidates, the resulting checklist, that is a list sorted by the 147 pair priority value, will be identical on the two agents. 149 The agent that has promoted IPv4 cautiously i.e. lower IPv4 candidate 150 priority values compared to the other agent, will influence the check 151 list the most due to (2^32*MIN(G,D)) in the formula. 153 These recommendations are backward compatible with a standard ICE 154 implementation. If the other agent have IPv4 candidates with higher 155 priorities due to intermingling, the effect is canceled when the 156 checklist is formed and the pair priority formula is used to 157 calculate the pair priority. 159 5. IANA Considerations 161 None. 163 6. Security Considerations 165 STUN connectivity check using MAC computed during key exchanged in 166 the signaling channel provides message integrity and data origin 167 authentication as described in section 2.5 of [RFC5245] apply to this 168 use. 170 7. Acknowledgements 172 Authors would like to thank Dan Wing, Ari Keranen, Bernard Aboba, 173 Martin Thomson and Jonathan Lennox for their comments and review. 175 8. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC3484] Draves, R., "Default Address Selection for Internet 181 Protocol version 6 (IPv6)", RFC 3484, February 2003. 183 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 184 (ICE): A Protocol for Network Address Translator (NAT) 185 Traversal for Offer/Answer Protocols", RFC 5245, April 186 2010. 188 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 189 "Default Address Selection for Internet Protocol Version 6 190 (IPv6)", RFC 6724, September 2012. 192 Authors' Addresses 194 Tirumaleswar Reddy 195 Cisco Systems, Inc. 196 Cessna Business Park, Varthur Hobli 197 Sarjapur Marathalli Outer Ring Road 198 Bangalore, Karnataka 560103 199 India 201 Email: tireddy@cisco.com 203 Prashanth Patil 204 Cisco Systems, Inc. 205 Bangalore 206 India 208 Email: praspati@cisco.com 210 Paal-Erik Martinsen 211 Cisco Systems, Inc. 212 Philip Pedersens Vei 22 213 Lysaker, Akershus 1325 214 Norway 216 Email: palmarti@cisco.com