idnits 2.17.1 draft-thatcher-ice-renomination-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 (March 21, 2016) is 2957 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: 'RFC5245' is defined on line 132, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thatcher 3 Internet-Draft H. Zhang 4 Intended status: Standards Track T. Brandstetter 5 Expires: September 22, 2016 Google 6 March 21, 2016 8 ICE Renomination: Dynamically selecting ICE candidate pairs 9 draft-thatcher-ice-renomination-00 11 Abstract 13 This document describes an extension to the Interactive Connectivity 14 Establishment (ICE) that enables ICE agents to dynamically change the 15 selected candidate pair of the controlled side by allowing the 16 controlling side to nominate different candidate pairs over time as 17 network conditions change. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 22, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Renomination . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. "Nomination" attribute . . . . . . . . . . . . . . . . . . . 3 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 60 8. Normative References . . . . . . . . . . . . . . . . . . . . 3 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 63 1. Introduction 65 ICE agents are either controlling or controlled. The controlling ICE 66 agent can unilaterally select a given candidate pair at any time. 67 But it cannot control what candidate pair the controlled ICE agent 68 selects once the controlling ICE agent has nominated a candidate pair 69 (with passive nomination) or nominated many candidate pairs (with 70 aggressive nomination), with the exception that it may nominate a 71 higher priority candidate pair with aggressive nomination. This 72 greatly limits the controlling side's options. 74 For example, if an ICE agent selects and nominates a candidate pair 75 over a cellular network, and then later connects to a Wi-Fi network 76 and trickles ICE candidates for the Wi-Fi network, it may wish to 77 select and nominate a candidate pair using Wi-Fi. If soon thereafter 78 the Wi-Fi network disconnects and the ICE agent wishes to select and 79 nominate the cellular candidate pair again, it would be unable to do 80 with either passive or aggressive nomination. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Renomination 90 We define a new ICE option called "renomination". When renomination 91 is signaled, aggressive nomination is disabled, and the controlled 92 side follows a rule of "last nomination wins". This allows the 93 controlling side to send nominations for new candidate pairs at any 94 time. The controlling side SHOULD send the new nomination until the 95 STUN packet is acked to ensure that the renomination was received. 97 If one side signals "renomination" and the other does not understand 98 it, then according to the rules of ICE, aggressive nomination is 99 disabled and passive nomination is used, and the controlling side 100 MUST NOT send more than one nomination. 102 4. "Nomination" attribute 104 To deal with out-of-order delivery of nominations, we define a new 105 STUN attribute: "nomination" which includes a 24-bit integer in the 3 106 least significant bytes of the attribute. 108 The controlling side MAY include such an attribute when renominating. 109 The controlled side MUST select the nomination with the largest value 110 contained in the "nomination" attribute. Any value included takes 111 precedence over the lack of a value. 113 5. IANA Considerations 115 This specification requests no actions from IANA. 117 6. Security Considerations 119 TODO 121 7. Acknowledgements 123 TODO 125 8. Normative References 127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 128 Requirement Levels", BCP 14, RFC 2119, 129 DOI 10.17487/RFC2119, March 1997, 130 . 132 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 133 (ICE): A Protocol for Network Address Translator (NAT) 134 Traversal for Offer/Answer Protocols", RFC 5245, 135 DOI 10.17487/RFC5245, April 2010, 136 . 138 Authors' Addresses 139 Peter Thatcher 140 Google 141 747 6th St S 142 Kirkland, WA 98033 143 USA 145 Email: pthatcher@google.com 147 Honghai Zhang 148 Google 149 747 6th St S 150 Kirkland, WA 98033 151 USA 153 Email: honghaiz@google.com 155 Taylor Brandstetter 156 Google 157 747 6th St S 158 Kirkland, WA 98033 159 USA 161 Email: deadbeef@google.com