| Internet-Draft | ICE Renomination | April 2026 |
| Thatcher, et al. | Expires 8 October 2026 | [Page] |
This document describes an extension to the Interactive Connectivity Establishment (ICE) that enables the controlling ICE agent to dynamically change its selected candidate pair over time as network conditions change, and notify the controlled side accordingly.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-thatcher-tsvwg-renomination/.¶
Discussion of this document takes place on the tsvwg Working Group mailing list (mailto:tsvwg@ietf.org), which is archived at https://datatracker.ietf.org/wg/tsvwg/. Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
ICE [RFC8445] agents take either the controlling or controlled role. During the ICE establishment process, the controlling and controlled agents communicate, using either regular or aggressive nomination, to agree upon which candidate pair they will use to exchange traffic. However, once ICE is established, there is no defined procedure for changing the selected pair without using an ICE restart.¶
While the controlling ICE agent could unilaterally select a given candidate pair at any time, it has no straightforward way of authoritatively telling the controlled side what pair it has selected. This greatly limits the controlling side's options.¶
For example, if an ICE agent selects and nominates a candidate pair over a cellular network, and then later connects to a Wi-Fi network and trickles ICE candidates for the Wi-Fi network, it may wish to select and nominate a Wi-Fi candidate pair. If soon thereafter the Wi-Fi network disconnects, the ICE agent may wish to select and nominate the cellular candidate pair again. These sorts of mid-session changes to the selected pair are not possible under the current ICE procedures without an ICE restart.¶
This document continues the work from the earlier individual Internet-Draft [I-D.thatcher-ice-renomination].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines an extension to the ICE mechanism called renomination. When active, renomination allows the controlling side to dynamically change the selected pair at any time, and notify the controlled side which pair it should use.¶
This allows switching between known pairs, or, as in the scenario outlined above, if a new interface becomes available, the controlling side can switch to a pair where the local candidate is on the new interface.¶
While this sort of dynamic change could be achieved with an ICE restart, a restart is a somewhat heavy operation that involves signaling new ICE credentials, gathering new candidates on both sides, and running the connectivity check mechanism for a whole new set of candidate pairs. In particular, the signaling requirement can be especially problematic if the device is in the process of switching between networks.¶
In contrast, the renomination mechanism only requires the exchange of a single ICE connectivity check.¶
As with regular nomination, this specification does not prescribe a specific algorithm for the controlling agent to select a candidate pair.¶
When renomination is active, the controlled side follows a process similar to regular nomination, except that more than one nomination request carrying USE-CANDIDATE can be sent during the lifetime of the ICE session, and the last valid nomination wins. To avoid ambiguity if requests are received out of order, a new NOMINATION attribute (Section 3.3) MUST be included in every connectivity check that contains USE-CANDIDATE. The value of the NOMINATION attribute is a monotonically increasing sequence number chosen by the controlling agent. A nomination request whose NOMINATION value is less than or equal to the highest previously accepted NOMINATION value for the same ICE generation and component MUST be ignored.¶
In order to ensure that candidate pairs other than the selected pair remain usable, both sides need to keep their candidates alive (e.g., by refreshing an associated TURN allocation). In addition, the controlling side MUST periodically send ICE consent checks on any candidate pair it wants to keep available for future nomination, using the consent freshness mechanism defined in [RFC7675]. The controlled side MUST issue a success response to these checks for all candidate pairs it intends to keep available for future nomination. However, either agent MAY limit the number and type of retained candidate pairs according to local policy.¶
This allows the controlling side to maintain a set of valid candidate pairs, any one of which it can nominate at any time.¶
Naturally, this mechanism requires opt-in from both ICE agents. To accomplish this, we define a new ICE option called "renomination2", where the "2" is added to avoid ambiguities with earlier versions of this draft.¶
If one side signals "renomination2" and the other does not, renomination is not in use for that ICE session. In that case, the controlling side MUST use standard ICE nomination procedures and MUST NOT send more than one effective nomination for a given component.¶
Note that the offering side (typically, the controlling side, but not always, e.g., if the offerer is ICE Lite) MAY receive ICE checks prior to receiving the SDP answer that definitively indicates support for renomination. In this case, the ICE checks might or might not include the NOMINATION attribute defined below. Accordingly, when offering "renomination2" and operating in the controlled role, the offerer MUST be prepared to work with an answerer that is using either renomination or regular nomination.¶
To deal with out-of-order delivery of nominations, this document defines a new STUN attribute [RFC8489], NOMINATION, which carries a 32-bit unsigned integer in network byte order. This attribute is comprehension-required, as it is only used when both sides have explicitly negotiated support via the "renomination2" ICE option.¶
When the "renomination2" ICE option has been negotiated, the controlling side MUST include a NOMINATION attribute in every connectivity check that includes USE-CANDIDATE. The first such request for an ICE generation (i.e., for a given set of ICE credentials) and component MAY use any value. Subsequent nomination requests for that same ICE generation and component MUST use a strictly greater value than any prior nomination request sent for that component. NOMINATION values for different components are not compared.¶
The controlled side MUST compare the received NOMINATION value against the highest previously accepted NOMINATION value for the current ICE generation and component. If the received value is greater, the nomination is accepted and the nominated pair is updated for that component. If the received value is less than or equal to the stored value, the request MUST be ignored for the purpose of updating the nominated pair. If the NOMINATION attribute is absent, the request MUST be similarly ignored, unless the scenario noted in Section 3.2 applies, where the SDP answer has not yet arrived and it is currently unclear to the offerer whether regular nomination or renomination is in use. In this situation, a connectivity check with USE-CANDIDATE but no NOMINATION attribute MUST be processed as a regular nomination.¶
If the ICE credentials are changed, i.e., by an ICE restart, this constitutes a new ICE generation, and the first-request rules above apply for each component.¶
Renomination is compatible with both full ICE and ICE Lite. When using ICE Lite, the guidance in [RFC8445] for the controlling side to select the candidate pair with the highest priority is superseded by the mechanism described above.¶
This document requests that IANA make the following registrations:¶
IANA is requested to add the following value to the "Interactive Connectivity Establishment (ICE) Options" registry:¶
ICE Option name: renomination2
Description: The ICE option indicates that the ICE agent supports renomination.
Reference: RFC XXXX¶
IANA is requested to add the following value to the "STUN Attributes" registry:¶
Attribute Name: NOMINATION
Value: 0x0030
Reference: RFC XXXX¶
Note: Some implementations have already used 0x0030 for this attribute, and
IANA has confirmed that this codepoint is available for registration by this
specification.¶
This mechanism extends the period during which ICE nomination can occur. Although it does not introduce any significant new protocol surface, it will result in continued connectivity checks on non-selected candidate pairs.¶
The existing consent freshness mechanism defined in [RFC7675] is used to ensure that the controlling side has permission to continue sending checks to these non-selected candidate pairs.¶
However, keeping certain candidates alive may incur higher power and network usage (e.g., cellular or TURN candidates). To control this, either side MAY discard candidates that it considers non-essential.¶
This extension does not change the existing requirements for authenticating STUN checks or protecting application or media traffic sent over candidate pairs.¶
This document overlaps with similar ideas in [I-D.uberti-mmusic-nombis] and [I-D.oreland-dispatch-ice-nicer].¶