Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8445

Proposed STD
Pages: 100
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ICE

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal

Part 1 of 6, p. 1 to 17
None       Next Section

Obsoletes:    5245


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        A. Keranen
Request for Comments: 8445                                   C. Holmberg
Obsoletes: 5245                                                 Ericsson
Category: Standards Track                                   J. Rosenberg
ISSN: 2070-1721                                              jdrosen.net
                                                               July 2018


             Interactive Connectivity Establishment (ICE):
       A Protocol for Network Address Translator (NAT) Traversal

Abstract

   This document describes a protocol for Network Address Translator
   (NAT) traversal for UDP-based communication.  This protocol is called
   Interactive Connectivity Establishment (ICE).  ICE makes use of the
   Session Traversal Utilities for NAT (STUN) protocol and its
   extension, Traversal Using Relay NAT (TURN).

   This document obsoletes RFC 5245.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8445.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Overview of ICE . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Gathering Candidates  . . . . . . . . . . . . . . . . . .   8
     2.2.  Connectivity Checks . . . . . . . . . . . . . . . . . . .  10
     2.3.  Nominating Candidate Pairs and Concluding ICE . . . . . .  12
     2.4.  ICE Restart . . . . . . . . . . . . . . . . . . . . . . .  13
     2.5.  Lite Implementations  . . . . . . . . . . . . . . . . . .  13
   3.  ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  ICE Candidate Gathering and Exchange  . . . . . . . . . . . .  17
     5.1.  Full Implementation . . . . . . . . . . . . . . . . . . .  17
       5.1.1.  Gathering Candidates  . . . . . . . . . . . . . . . .  18
         5.1.1.1.  Host Candidates . . . . . . . . . . . . . . . . .  18
         5.1.1.2.  Server-Reflexive and Relayed Candidates . . . . .  20
         5.1.1.3.  Computing Foundations . . . . . . . . . . . . . .  21
         5.1.1.4.  Keeping Candidates Alive  . . . . . . . . . . . .  21
       5.1.2.  Prioritizing Candidates . . . . . . . . . . . . . . .  22
         5.1.2.1.  Recommended Formula . . . . . . . . . . . . . . .  22
         5.1.2.2.  Guidelines for Choosing Type and Local
                   Preferences . . . . . . . . . . . . . . . . . . .  23
       5.1.3.  Eliminating Redundant Candidates  . . . . . . . . . .  23
     5.2.  Lite Implementation Procedures  . . . . . . . . . . . . .  23
     5.3.  Exchanging Candidate Information  . . . . . . . . . . . .  24
     5.4.  ICE Mismatch  . . . . . . . . . . . . . . . . . . . . . .  26
   6.  ICE Candidate Processing  . . . . . . . . . . . . . . . . . .  26
     6.1.  Procedures for Full Implementation  . . . . . . . . . . .  26
       6.1.1.  Determining Role  . . . . . . . . . . . . . . . . . .  26
       6.1.2.  Forming the Checklists  . . . . . . . . . . . . . . .  28
         6.1.2.1.  Checklist State . . . . . . . . . . . . . . . . .  28
         6.1.2.2.  Forming Candidate Pairs . . . . . . . . . . . . .  28
         6.1.2.3.  Computing Pair Priority and Ordering Pairs  . . .  31
         6.1.2.4.  Pruning the Pairs . . . . . . . . . . . . . . . .  31
         6.1.2.5.  Removing Lower-Priority Pairs . . . . . . . . . .  31
         6.1.2.6.  Computing Candidate Pair States . . . . . . . . .  32
       6.1.3.  ICE State . . . . . . . . . . . . . . . . . . . . . .  36
       6.1.4.  Scheduling Checks . . . . . . . . . . . . . . . . . .  36
         6.1.4.1.  Triggered-Check Queue . . . . . . . . . . . . . .  36
         6.1.4.2.  Performing Connectivity Checks  . . . . . . . . .  36
     6.2.  Lite Implementation Procedures  . . . . . . . . . . . . .  38
   7.  Performing Connectivity Checks  . . . . . . . . . . . . . . .  38
     7.1.  STUN Extensions . . . . . . . . . . . . . . . . . . . . .  38
       7.1.1.  PRIORITY  . . . . . . . . . . . . . . . . . . . . . .  38
       7.1.2.  USE-CANDIDATE . . . . . . . . . . . . . . . . . . . .  38
       7.1.3.  ICE-CONTROLLED and ICE-CONTROLLING  . . . . . . . . .  39
     7.2.  STUN Client Procedures  . . . . . . . . . . . . . . . . .  39
       7.2.1.  Creating Permissions for Relayed Candidates . . . . .  39

Top      ToC       Page 4 
       7.2.2.  Forming Credentials . . . . . . . . . . . . . . . . .  39
       7.2.3.  Diffserv Treatment  . . . . . . . . . . . . . . . . .  40
       7.2.4.  Sending the Request . . . . . . . . . . . . . . . . .  40
       7.2.5.  Processing the Response . . . . . . . . . . . . . . .  40
         7.2.5.1.  Role Conflict . . . . . . . . . . . . . . . . . .  40
         7.2.5.2.  Failure . . . . . . . . . . . . . . . . . . . . .  41
           7.2.5.2.1.  Non-Symmetric Transport Addresses . . . . . .  41
           7.2.5.2.2.  ICMP Error  . . . . . . . . . . . . . . . . .  41
           7.2.5.2.3.  Timeout . . . . . . . . . . . . . . . . . . .  41
           7.2.5.2.4.  Unrecoverable STUN Response . . . . . . . . .  41
         7.2.5.3.  Success . . . . . . . . . . . . . . . . . . . . .  42
           7.2.5.3.1.  Discovering Peer-Reflexive Candidates . . . .  42
           7.2.5.3.2.  Constructing a Valid Pair . . . . . . . . . .  43
           7.2.5.3.3.  Updating Candidate Pair States  . . . . . . .  44
           7.2.5.3.4.  Updating the Nominated Flag . . . . . . . . .  44
         7.2.5.4.  Checklist State Updates . . . . . . . . . . . . .  44
     7.3.  STUN Server Procedures  . . . . . . . . . . . . . . . . .  45
       7.3.1.  Additional Procedures for Full Implementations  . . .  45
         7.3.1.1.  Detecting and Repairing Role Conflicts  . . . . .  46
         7.3.1.2.  Computing Mapped Addresses  . . . . . . . . . . .  47
         7.3.1.3.  Learning Peer-Reflexive Candidates  . . . . . . .  47
         7.3.1.4.  Triggered Checks  . . . . . . . . . . . . . . . .  47
         7.3.1.5.  Updating the Nominated Flag . . . . . . . . . . .  49
       7.3.2.  Additional Procedures for Lite Implementations  . . .  49
   8.  Concluding ICE Processing . . . . . . . . . . . . . . . . . .  50
     8.1.  Procedures for Full Implementations . . . . . . . . . . .  50
       8.1.1.  Nominating Pairs  . . . . . . . . . . . . . . . . . .  50
       8.1.2.  Updating Checklist and ICE States . . . . . . . . . .  51
     8.2.  Procedures for Lite Implementations . . . . . . . . . . .  52
     8.3.  Freeing Candidates  . . . . . . . . . . . . . . . . . . .  53
       8.3.1.  Full Implementation Procedures  . . . . . . . . . . .  53
       8.3.2.  Lite Implementation Procedures  . . . . . . . . . . .  53
   9.  ICE Restarts  . . . . . . . . . . . . . . . . . . . . . . . .  53
   10. ICE Option  . . . . . . . . . . . . . . . . . . . . . . . . .  54
   11. Keepalives  . . . . . . . . . . . . . . . . . . . . . . . . .  54
   12. Data Handling . . . . . . . . . . . . . . . . . . . . . . . .  55
     12.1.  Sending Data . . . . . . . . . . . . . . . . . . . . . .  55
       12.1.1.  Procedures for Lite Implementations  . . . . . . . .  56
     12.2.  Receiving Data . . . . . . . . . . . . . . . . . . . . .  56
   13. Extensibility Considerations  . . . . . . . . . . . . . . . .  57
   14. Setting Ta and RTO  . . . . . . . . . . . . . . . . . . . . .  57
     14.1.  General  . . . . . . . . . . . . . . . . . . . . . . . .  57
     14.2.  Ta . . . . . . . . . . . . . . . . . . . . . . . . . . .  58
     14.3.  RTO  . . . . . . . . . . . . . . . . . . . . . . . . . .  58
   15. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
     15.1.  Example with IPv4 Addresses  . . . . . . . . . . . . . .  60
     15.2.  Example with IPv6 Addresses  . . . . . . . . . . . . . .  65

Top      ToC       Page 5 
   16. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . .  69
     16.1.  Attributes . . . . . . . . . . . . . . . . . . . . . . .  69
     16.2.  New Error-Response Codes . . . . . . . . . . . . . . . .  70
   17. Operational Considerations  . . . . . . . . . . . . . . . . .  70
     17.1.  NAT and Firewall Types . . . . . . . . . . . . . . . . .  70
     17.2.  Bandwidth Requirements . . . . . . . . . . . . . . . . .  70
       17.2.1.  STUN and TURN Server-Capacity Planning . . . . . . .  71
       17.2.2.  Gathering and Connectivity Checks  . . . . . . . . .  71
       17.2.3.  Keepalives . . . . . . . . . . . . . . . . . . . . .  72
     17.3.  ICE and ICE-Lite . . . . . . . . . . . . . . . . . . . .  72
     17.4.  Troubleshooting and Performance Management . . . . . . .  72
     17.5.  Endpoint Configuration . . . . . . . . . . . . . . . . .  73
   18. IAB Considerations  . . . . . . . . . . . . . . . . . . . . .  73
     18.1.  Problem Definition . . . . . . . . . . . . . . . . . . .  73
     18.2.  Exit Strategy  . . . . . . . . . . . . . . . . . . . . .  74
     18.3.  Brittleness Introduced by ICE  . . . . . . . . . . . . .  74
     18.4.  Requirements for a Long-Term Solution  . . . . . . . . .  75
     18.5.  Issues with Existing NAPT Boxes  . . . . . . . . . . . .  75
   19. Security Considerations . . . . . . . . . . . . . . . . . . .  76
     19.1.  IP Address Privacy . . . . . . . . . . . . . . . . . . .  76
     19.2.  Attacks on Connectivity Checks . . . . . . . . . . . . .  77
     19.3.  Attacks on Server-Reflexive Address Gathering  . . . . .  80
     19.4.  Attacks on Relayed Candidate Gathering . . . . . . . . .  80
     19.5.  Insider Attacks  . . . . . . . . . . . . . . . . . . . .  81
       19.5.1.  STUN Amplification Attack  . . . . . . . . . . . . .  81
   20. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  82
     20.1.  STUN Attributes  . . . . . . . . . . . . . . . . . . . .  82
     20.2.  STUN Error Responses . . . . . . . . . . . . . . . . . .  82
     20.3.  ICE Options  . . . . . . . . . . . . . . . . . . . . . .  82
   21. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . .  83
   22. References  . . . . . . . . . . . . . . . . . . . . . . . . .  84
     22.1.  Normative References . . . . . . . . . . . . . . . . . .  84
     22.2.  Informative References . . . . . . . . . . . . . . . . .  85
   Appendix A.  Lite and Full Implementations  . . . . . . . . . . .  89
   Appendix B.  Design Motivations . . . . . . . . . . . . . . . . .  90
     B.1.  Pacing of STUN Transactions . . . . . . . . . . . . . . .  90
     B.2.  Candidates with Multiple Bases  . . . . . . . . . . . . .  92
     B.3.  Purpose of the Related-Address and Related-Port
           Attributes  . . . . . . . . . . . . . . . . . . . . . . .  94
     B.4.  Importance of the STUN Username . . . . . . . . . . . . .  95
     B.5.  The Candidate Pair Priority Formula . . . . . . . . . . .  96
     B.6.  Why Are Keepalives Needed?  . . . . . . . . . . . . . . .  96
     B.7.  Why Prefer Peer-Reflexive Candidates? . . . . . . . . . .  97
     B.8.  Why Are Binding Indications Used for Keepalives?  . . . .  97
     B.9.  Selecting Candidate Type Preference . . . . . . . . . . .  97
   Appendix C.  Connectivity-Check Bandwidth . . . . . . . . . . . .  99
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 100
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 100

Top      ToC       Page 6 
1.  Introduction

   Protocols establishing communication sessions between peers typically
   involve exchanging IP addresses and ports for the data sources and
   sinks.  However, this poses challenges when operated through Network
   Address Translators (NATs) [RFC3235].  These protocols also seek to
   create a data flow directly between participants, so that there is no
   application-layer intermediary between them.  This is done to reduce
   data latency, decrease packet loss, and reduce the operational costs
   of deploying the application.  However, this is difficult to
   accomplish through NATs.  A full treatment of the reasons for this is
   beyond the scope of this specification.

   Numerous solutions have been defined for allowing these protocols to
   operate through NATs.  These include Application Layer Gateways
   (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple
   Traversal of UDP Through NAT (STUN) specification [RFC3489] (note
   that RFC 3489 has been obsoleted by RFC 5389), and Realm Specific IP
   [RFC3102] [RFC3103] along with session description extensions needed
   to make them work, such as the Session Description Protocol (SDP)
   attribute [RFC4566] for the Real-Time Control Protocol (RTCP)
   [RFC3605].  Unfortunately, these techniques all have pros and cons
   that make each one optimal in some network topologies, but a poor
   choice in others.  The result is that administrators and implementers
   are making assumptions about the topologies of the networks in which
   their solutions will be deployed.  This introduces complexity and
   brittleness into the system.

   This specification defines Interactive Connectivity Establishment
   (ICE) as a technique for NAT traversal for UDP-based data streams
   (though ICE has been extended to handle other transport protocols,
   such as TCP [RFC6544]).  ICE works by exchanging a multiplicity of IP
   addresses and ports, which are then tested for connectivity by
   peer-to-peer connectivity checks.  The IP addresses and ports are
   exchanged using ICE-usage-specific mechanisms (e.g., in an Offer/
   Answer exchange), and the connectivity checks are performed using
   STUN [RFC5389].  ICE also makes use of Traversal Using Relay around
   NAT (TURN) [RFC5766], an extension to STUN.  Because ICE exchanges a
   multiplicity of IP addresses and ports for each media stream, it also
   allows for address selection for multihomed and dual-stack hosts.
   For this reason, RFC 5245 [RFC5245] deprecated the solutions
   previously defined in RFC 4091 [RFC4091] and RFC 4092 [RFC4092].

   Appendix B provides background information and motivations regarding
   the design decisions that were made when designing ICE.

Top      ToC       Page 7 
2.  Overview of ICE

   In a typical ICE deployment, there are two endpoints (ICE agents)
   that want to communicate.  Note that ICE is not intended for NAT
   traversal for the signaling protocol, which is assumed to be provided
   via another mechanism.  ICE assumes that the agents are able to
   establish a signaling connection between each other.

   Initially, the agents are ignorant of their own topologies.  In
   particular, the agents may or may not be behind NATs (or multiple
   tiers of NATs).  ICE allows the agents to discover enough information
   about their topologies to potentially find one or more paths by which
   they can establish a data session.

   Figure 1 shows a typical ICE deployment.  The agents are labeled L
   and R.  Both L and R are behind their own respective NATs, though
   they may not be aware of it.  The type of NAT and its properties are
   also unknown.  L and R are capable of engaging in a candidate
   exchange process, whose purpose is to set up a data session between L
   and R.  Typically, this exchange will occur through a signaling
   server (e.g., a SIP proxy).

   In addition to the agents, a signaling server, and NATs, ICE is
   typically used in concert with STUN or TURN servers in the network.
   Each agent can have its own STUN or TURN server, or they can be the
   same.

                               +---------+
             +--------+        |Signaling|         +--------+
             | STUN   |        |Server   |         | STUN   |
             | Server |        +---------+         | Server |
             +--------+       /           \        +--------+
                             /             \
                            /               \
                           / <- Signaling -> \
                          /                   \
                   +--------+               +--------+
                   |  NAT   |               |  NAT   |
                   +--------+               +--------+
                      /                             \
                     /                               \
                 +-------+                       +-------+
                 | Agent |                       | Agent |
                 |   L   |                       |   R   |
                 +-------+                       +-------+

                     Figure 1: ICE Deployment Scenario

Top      ToC       Page 8 
   The basic idea behind ICE is as follows: each agent has a variety of
   candidate transport addresses (combination of IP address and port for
   a particular transport protocol, which is always UDP in this
   specification) it could use to communicate with the other agent.
   These might include:

   o  A transport address on a directly attached network interface

   o  A translated transport address on the public side of a NAT (a
      "server-reflexive" address)

   o  A transport address allocated from a TURN server (a "relayed
      address")

   Potentially, any of L's candidate transport addresses can be used to
   communicate with any of R's candidate transport addresses.  In
   practice, however, many combinations will not work.  For instance, if
   L and R are both behind NATs, their directly attached interface
   addresses are unlikely to be able to communicate directly (this is
   why ICE is needed, after all!).  The purpose of ICE is to discover
   which pairs of addresses will work.  The way that ICE does this is to
   systematically try all possible pairs (in a carefully sorted order)
   until it finds one or more that work.

2.1.  Gathering Candidates

   In order to execute ICE, an ICE agent identifies and gathers one or
   more address candidates.  A candidate has a transport address -- a
   combination of IP address and port for a particular transport
   protocol (with only UDP specified here).  There are different types
   of candidates; some are derived from physical or logical network
   interfaces, and others are discoverable via STUN and TURN.

   The first category of candidates are those with a transport address
   obtained directly from a local interface.  Such a candidate is called
   a "host candidate".  The local interface could be Ethernet or Wi-Fi,
   or it could be one that is obtained through a tunnel mechanism, such
   as a Virtual Private Network (VPN) or Mobile IP (MIP).  In all cases,
   such a network interface appears to the agent as a local interface
   from which ports (and thus candidates) can be allocated.

   Next, the agent uses STUN or TURN to obtain additional candidates.
   These come in two flavors: translated addresses on the public side of
   a NAT (server-reflexive candidates) and addresses on TURN servers
   (relayed candidates).  When TURN servers are utilized, both types of
   candidates are obtained from the TURN server.  If only STUN servers
   are utilized, only server-reflexive candidates are obtained from
   them.  The relationship of these candidates to the host candidate is

Top      ToC       Page 9 
   shown in Figure 2.  In this figure, both types of candidates are
   discovered using TURN.  In the figure, the notation X:x means IP
   address X and UDP port x.

                      To Internet

                          |
                          |
                          |  /------------  Relayed
                      Y:y | /               Address
                      +--------+
                      |        |
                      |  TURN  |
                      | Server |
                      |        |
                      +--------+
                          |
                          |
                          | /------------  Server
                   X1':x1'|/               Reflexive
                    +------------+         Address
                    |    NAT     |
                    +------------+
                          |
                          | /------------  Local
                      X:x |/               Address
                      +--------+
                      |        |
                      | Agent  |
                      |        |
                      +--------+


                     Figure 2: Candidate Relationships

   When the agent sends a TURN Allocate request from IP address and port
   X:x, the NAT (assuming there is one) will create a binding X1':x1',
   mapping this server-reflexive candidate to the host candidate X:x.
   Outgoing packets sent from the host candidate will be translated by
   the NAT to the server-reflexive candidate.  Incoming packets sent to
   the server-reflexive candidate will be translated by the NAT to the
   host candidate and forwarded to the agent.  The host candidate
   associated with a given server-reflexive candidate is the "base".

      Note: "Base" refers to the address an agent sends from for a
      particular candidate.  Thus, as a degenerate case, host candidates
      also have a base, but it's the same as the host candidate.

Top      ToC       Page 10 
   When there are multiple NATs between the agent and the TURN server,
   the TURN request will create a binding on each NAT, but only the
   outermost server-reflexive candidate (the one nearest the TURN
   server) will be discovered by the agent.  If the agent is not behind
   a NAT, then the base candidate will be the same as the server-
   reflexive candidate, and the server-reflexive candidate is redundant
   and will be eliminated.

   The Allocate request then arrives at the TURN server.  The TURN
   server allocates a port y from its local IP address Y, and generates
   an Allocate response, informing the agent of this relayed candidate.
   The TURN server also informs the agent of the server-reflexive
   candidate, X1':x1', by copying the source transport address of the
   Allocate request into the Allocate response.  The TURN server acts as
   a packet relay, forwarding traffic between L and R.  In order to send
   traffic to L, R sends traffic to the TURN server at Y:y, and the TURN
   server forwards that to X1':x1', which passes through the NAT where
   it is mapped to X:x and delivered to L.

   When only STUN servers are utilized, the agent sends a STUN Binding
   request [RFC5389] to its STUN server.  The STUN server will inform
   the agent of the server-reflexive candidate X1':x1' by copying the
   source transport address of the Binding request into the Binding
   response.

2.2.  Connectivity Checks

   Once L has gathered all of its candidates, it orders them by highest-
   to-lowest priority and sends them to R over the signaling channel.
   When R receives the candidates from L, it performs the same gathering
   process and responds with its own list of candidates.  At the end of
   this process, each ICE agent has a complete list of both its
   candidates and its peer's candidates.  It pairs them up, resulting in
   candidate pairs.  To see which pairs work, each agent schedules a
   series of connectivity checks.  Each check is a STUN request/response
   transaction that the client will perform on a particular candidate
   pair by sending a STUN request from the local candidate to the remote
   candidate.

   The basic principle of the connectivity checks is simple:

   1.  Sort the candidate pairs in priority order.

   2.  Send checks on each candidate pair in priority order.

   3.  Acknowledge checks received from the other agent.

Top      ToC       Page 11 
   With both agents performing a check on a candidate pair, the result
   is a 4-way handshake:

                  L                        R
                  -                        -
                  STUN request ->             \  L's
                            <- STUN response  /  check

                             <- STUN request  \  R's
                  STUN response ->            /  check

                    Figure 3: Basic Connectivity Check

   It is important to note that STUN requests are sent to and from the
   exact same IP addresses and ports that will be used for data (e.g.,
   RTP, RTCP, or other protocols).  Consequently, agents demultiplex
   STUN and data using the contents of the packets rather than the port
   on which they are received.

   Because a STUN Binding request is used for the connectivity check,
   the STUN Binding response will contain the agent's translated
   transport address on the public side of any NATs between the agent
   and its peer.  If this transport address is different from that of
   other candidates the agent already learned, it represents a new
   candidate (peer-reflexive candidate), which then gets tested by ICE
   just the same as any other candidate.

   Because the algorithm above searches all candidate pairs, if a
   working pair exists, the algorithm will eventually find it no matter
   what order the candidates are tried in.  In order to produce faster
   (and better) results, the candidates are sorted in a specified order.
   The resulting list of sorted candidate pairs is called the
   "checklist".

   The agent works through the checklist by sending a STUN request for
   the next candidate pair on the list periodically.  These are called
   "ordinary checks".  When a STUN transaction succeeds, one or more
   candidate pairs will become so-called "valid pairs" and will be added
   to a candidate-pair list called the "valid list".

   As an optimization, as soon as R gets L's check message, R schedules
   a connectivity-check message to be sent to L on the same candidate
   pair.  This is called a "triggered check", and it accelerates the
   process of finding valid pairs.

   At the end of this handshake, both L and R know that they can send
   (and receive) messages end to end in both directions.

Top      ToC       Page 12 
   In general, the priority algorithm is designed so that candidates of
   a similar type get similar priorities so that more direct routes
   (that is, routes without data relays or NATs) are preferred over
   indirect routes (routes with data relays or NATs).  Within those
   guidelines, however, agents have a fair amount of discretion about
   how to tune their algorithms.

   A data stream might consist of multiple components (pieces of a data
   stream that require their own set of candidates, e.g., RTP and RTCP).

2.3.  Nominating Candidate Pairs and Concluding ICE

   ICE assigns one of the ICE agents in the role of the controlling
   agent, and the other in the role of the controlled agent.  For each
   component of a data stream, the controlling agent nominates a valid
   pair (from the valid list) to be used for data.  The exact timing of
   the nomination is based on local policy.

   When nominating, the controlling agent lets the checks continue until
   at least one valid pair for each component of a data stream is found,
   and then it picks a valid pair and sends a STUN request on that pair,
   using an attribute to indicate to the controlled peer that it has
   been nominated.  This is shown in Figure 4.

             L                        R
             -                        -
             STUN request ->             \  L's
                       <- STUN response  /  check

                        <- STUN request  \  R's
             STUN response ->            /  check

             STUN request + attribute -> \  L's
                       <- STUN response  /  check

                           Figure 4: Nomination

   Once the controlled agent receives the STUN request with the
   attribute, it will check (unless the check has already been done) the
   same pair.  If the transactions above succeed, the agents will set
   the nominated flag for the pairs and will cancel any future checks
   for that component of the data stream.  Once an agent has set the
   nominated flag for each component of a data stream, the pairs become
   the selected pairs.  After that, only the selected pairs will be used
   for sending and receiving data associated with that data stream.

Top      ToC       Page 13 
2.4.  ICE Restart

   Once ICE is concluded, it can be restarted at any time for one or all
   of the data streams by either ICE agent.  This is done by sending
   updated candidate information indicating a restart.

2.5.  Lite Implementations

   Certain ICE agents will always be connected to the public Internet
   and have a public IP address at which it can receive packets from any
   correspondent.  To make it easier for these devices to support ICE,
   ICE defines a special type of implementation called "lite" (in
   contrast to the normal full implementation).  Lite agents only use
   host candidates and do not generate connectivity checks or run state
   machines, though they need to be able to respond to connectivity
   checks.

3.  ICE Usage

   This document specifies generic use of ICE with protocols that
   provide means to exchange candidate information between ICE agents.
   The specific details (i.e., how to encode candidate information and
   the actual candidate exchange process) for different protocols using
   ICE (referred to as "using protocol") are described in separate usage
   documents.

   One mechanism that allows agents to exchange candidate information is
   the utilization of Offer/Answer semantics (which are based on
   [RFC3264]) as part of the SIP protocol [RFC3261] [ICE-SIP-SDP].

   [RFC7825] defines an ICE usage for the Real-Time Streaming Protocol
   (RTSP).  Note, however, that the ICE usage is based on RFC 5245.

4.  Terminology

   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.

   Readers need to be familiar with the terminology defined in [RFC5389]
   and NAT Behavioral requirements for UDP [RFC4787].

Top      ToC       Page 14 
   This specification makes use of the following additional terminology:

   ICE Session:  An ICE session consists of all ICE-related actions
      starting with the candidate gathering, followed by the
      interactions (candidate exchange, connectivity checks,
      nominations, and keepalives) between the ICE agents until all the
      candidates are released or an ICE restart is triggered.

   ICE Agent, Agent:  An ICE agent (sometimes simply referred to as an
      "agent") is the protocol implementation involved in the ICE
      candidate exchange.  There are two agents involved in a typical
      candidate exchange.

   Initiating Peer, Initiating Agent, Initiator:  An initiating agent is
      an ICE agent that initiates the ICE candidate exchange process.

   Responding Peer, Responding Agent, Responder:  A responding agent is
      an ICE agent that receives and responds to the candidate exchange
      process initiated by the initiating agent.

   ICE Candidate Exchange, Candidate Exchange:  The process where ICE
      agents exchange information (e.g., candidates and passwords) that
      is needed to perform ICE.  Offer/Answer with SDP encoding
      [RFC3264] is one example of a protocol that can be used for
      exchanging the candidate information.

   Peer:  From the perspective of one of the ICE agents in a session,
      its peer is the other agent.  Specifically, from the perspective
      of the initiating agent, the peer is the responding agent.  From
      the perspective of the responding agent, the peer is the
      initiating agent.

   Transport Address:  The combination of an IP address and the
      transport protocol (such as UDP or TCP) port.

   Data, Data Stream, Data Session:  When ICE is used to set up data
      sessions, the data is transported using some protocol.  Media is
      usually transported over RTP, composed of a stream of RTP packets.
      Data session refers to data packets that are exchanged between the
      peer on the path created and tested with ICE.

   Candidate, Candidate Information:  A transport address that is a
      potential point of contact for receipt of data.  Candidates also
      have properties -- their type (server reflexive, relayed, or
      host), priority, foundation, and base.

Top      ToC       Page 15 
   Component:  A component is a piece of a data stream.  A data stream
      may require multiple components, each of which has to work in
      order for the data stream as a whole to work.  For RTP/RTCP data
      streams, unless RTP and RTCP are multiplexed in the same port,
      there are two components per data stream -- one for RTP, and one
      for RTCP.  A component has a candidate pair, which cannot be used
      by other components.

   Host Candidate:  A candidate obtained by binding to a specific port
      from an IP address on the host.  This includes IP addresses on
      physical interfaces and logical ones, such as ones obtained
      through VPNs.

   Server-Reflexive Candidate:  A candidate whose IP address and port
      are a binding allocated by a NAT for an ICE agent after it sends a
      packet through the NAT to a server, such as a STUN server.

   Peer-Reflexive Candidate:  A candidate whose IP address and port are
      a binding allocated by a NAT for an ICE agent after it sends a
      packet through the NAT to its peer.

   Relayed Candidate:  A candidate obtained from a relay server, such as
      a TURN server.

   Base:  The transport address that an ICE agent sends from for a
      particular candidate.  For host, server-reflexive, and peer-
      reflexive candidates, the base is the same as the host candidate.
      For relayed candidates, the base is the same as the relayed
      candidate (i.e., the transport address used by the TURN server to
      send from).

   Related Address and Port:  A transport address related to a
      candidate, which is useful for diagnostics and other purposes.  If
      a candidate is server or peer reflexive, the related address and
      port is equal to the base for that server or peer-reflexive
      candidate.  If the candidate is relayed, the related address and
      port are equal to the mapped address in the Allocate response that
      provided the client with that relayed candidate.  If the candidate
      is a host candidate, the related address and port is identical to
      the host candidate.

   Foundation:  An arbitrary string used in the freezing algorithm to
      group similar candidates.  It is the same for two candidates that
      have the same type, base IP address, protocol (UDP, TCP, etc.),
      and STUN or TURN server.  If any of these are different, then the
      foundation will be different.

Top      ToC       Page 16 
   Local Candidate:  A candidate that an ICE agent has obtained and may
      send to its peer.

   Remote Candidate:  A candidate that an ICE agent received from its
      peer.

   Default Destination/Candidate:  The default destination for a
      component of a data stream is the transport address that would be
      used by an ICE agent that is not ICE aware.  A default candidate
      for a component is one whose transport address matches the default
      destination for that component.

   Candidate Pair:  A pair containing a local candidate and a remote
      candidate.

   Check, Connectivity Check, STUN Check:  A STUN Binding request for
      the purpose of verifying connectivity.  A check is sent from the
      base of the local candidate to the remote candidate of a candidate
      pair.

   Checklist:  An ordered set of candidate pairs that an ICE agent will
      use to generate checks.

   Ordinary Check:  A connectivity check generated by an ICE agent as a
      consequence of a timer that fires periodically, instructing it to
      send a check.

   Triggered Check:  A connectivity check generated as a consequence of
      the receipt of a connectivity check from the peer.

   Valid Pair:  A candidate pair whose local candidate equals the mapped
      address of a successful connectivity-check response and whose
      remote candidate equals the destination address to which the
      connectivity-check request was sent.

   Valid List:  An ordered set of candidate pairs for a data stream that
      have been validated by a successful STUN transaction.

   Checklist Set:  The ordered list of all checklists.  The order is
      determined by each ICE usage.

   Full Implementation:  An ICE implementation that performs the
      complete set of functionality defined by this specification.

Top      ToC       Page 17 
   Lite Implementation:  An ICE implementation that omits certain
      functions, implementing only as much as is necessary for a peer
      that is not a lite implementation to gain the benefits of ICE.
      Lite implementations do not maintain any of the state machines and
      do not generate connectivity checks.

   Controlling Agent:  The ICE agent that nominates a candidate pair.
      In any session, there is always one controlling agent and one
      controlled agent.

   Controlled Agent:  The ICE agent that waits for the controlling agent
      to nominate a candidate pair.

   Nomination:  The process of the controlling agent indicating to the
      controlled agent which candidate pair the ICE agents will use for
      sending and receiving data.  The nomination process defined in
      this specification was referred to as "regular nomination" in RFC
      5245.  The nomination process that was referred to as "aggressive
      nomination" in RFC 5245 has been deprecated in this specification.

   Nominated, Nominated Flag:  Once the nomination of a candidate pair
      has succeeded, the candidate pair has become nominated, and the
      value of its nominated flag is set to true.

   Selected Pair, Selected Candidate Pair:  The candidate pair used for
      sending and receiving data for a component of a data stream is
      referred to as the "selected pair".  Before selected pairs have
      been produced for a data stream, any valid pair associated with a
      component of a data stream can be used for sending and receiving
      data for the component.  Once there are nominated pairs for each
      component of a data stream, the nominated pairs become the
      selected pairs for the data stream.  The candidates associated
      with the selected pairs are referred to as "selected candidates".

   Using Protocol, ICE Usage:  The protocol that uses ICE for NAT
      traversal.  A usage specification defines the protocol-specific
      details on how the procedures defined here are applied to that
      protocol.

   Timer Ta:  The timer for generating new STUN or TURN transactions.

   Timer RTO (Retransmission Timeout):  The retransmission timer for a
      given STUN or TURN transaction.


Next Section