<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wing-mmusic-ice-mobility-07"
     ipr="trust200902">
  <front>
    <title abbrev="MICE">Mobility with ICE (MICE)</title>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marthalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Paal-Erik Martinsen" initials="P.E" surname="Martinsen">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Philip Pedersens vei 22</street>

          <city>Lysaker</city>

          <region>Akershus</region>

          <code>1325</code>

          <country>Norway</country>
        </postal>

        <email>palmarti@cisco.com</email>
      </address>
    </author>

    <date/>

    <workgroup>MMUSIC</workgroup>

    <abstract>
      <t>This specification describes how endpoint mobility can be achieved
      using ICE.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>When moving between networks, an endpoint has to change its IP
      address. This change breaks upper layer protocols such as TCP and RTP.
      Various techniques exist to prevent this breakage, all tied to making
      the endpoint's IP address static (e.g., Mobile IP, Proxy Mobile IP,
      LISP). Other techniques exist, which make the upper layer protocol
      ambivalent to IP address changes (e.g., SCTP). The mechanisms described
      in this document are in that last category.</t>

      <t>ICE <xref target="RFC5245"/> ensures two endpoints have a working
      media path between them, and is typically used by Internet-connected
      interactive media systems (e.g., SIP endpoints). ICE does not expect
      either the local host or the remote host to change their IP addresses.
      Although ICE does allow an "ICE restart", this is done by sending a
      re-INVITE which goes over the SIP signaling path. The SIP signaling path
      is often slower than the media path (which needs to be recovered as
      quickly as possible), consumes an extra half round trip, and incurs an
      additional delay if the mobility event forces the endpoint to re-connect
      with its SIP proxy. When a device changes its IP address, it is
      necessary for it to re-establish connectivity with its SIP proxy, which
      can be performed in parallel with the steps described in this document.
      This document describes how mobility is performed entirely in the media
      path, without the additional delay of re-establishing SIP connectivity,
      issuing a new offer/answer, or the complications of multiple SIP offers.
      This document considers re-establishing bi-directional media the most
      critical aspect of a successful mobility event, and its efforts are
      towards meeting that goal.</t>

      <t>This document proposes a mechanism to achieve RTP mobility when both
      endpoints support MICE. When both endpoints support MICE, ICE itself can
      be used to provide mobility. When only one endpoint supports MICE, a
      TURN server provides mobility as described in <xref
      target="I-D.wing-tram-turn-mobility"/>. Both mobility techniques work
      across and between network types (e.g., between 3G and wired Internet
      access), so long as the client can still access the remote ICE peer or
      TURN server.</t>

      <t>Readers are assumed to be familiar with <xref
      target="RFC5245">ICE</xref>.</t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"/>.</t>

      <t>This note uses terminology defined in <xref target="RFC5245"/>, and
      the following additional terminology: <list style="hanging">
          <t hangText="Break Before Make:">The initially selected interface
          for communication may become unavailable (e.g due to loss of
          coverage when moving out of a WiFi hotspot) and new interfaces may
          become available due to administrative action (e.g manual activation
          of a specific connectivity technology) or due to dynamic conditions
          (e.g. Entering coverage area of a wireless network).</t>

          <t hangText="Make Before Break:">The initially selected interface
          for communication may become deprioritized (e.g new interface
          becoming available and it's per bit cost is cheaper and the
          connection speed is faster than existing interface used for
          communication).</t>

          <t hangText="Simultaneous Mobility:">If both the endpoints are
          mobile and roam at the same time between networks.</t>
        </list></t>
    </section>

    <section anchor="IntfGain" title="Break Before Make">
      <t>When both endpoints support ICE, ICE itself can provide mobility
      functions. One of the primary aspects of ICE is its address gathering,
      wherein ICE has each endpoint determine all of the IP addresses and
      ports that might be usable for that endpoint and communicate that list
      of addresses and ports to its peer, usually over SDP. That enables the
      next primary aspect of ICE, which is its connectivity checks: each ICE
      endpoint sends a connectivity check from a checklist created by the
      local and remote candidates exchanged in the initial offer/answer
      exchange. When the ICE endpoint checks the mapped address from the STUN
      response during ICE connectivity checks and finds that the transport
      address does not match any of the local candidates that the ICE agent
      knows about, the mapped address represents a new candidate -- a peer
      reflexive candidate. This will cause the endpoint to construct a new
      pair and insert it into the local checklist (Section 7.2.1.3 of <xref
      target="RFC5245"/>). ICE Mobility (MICE) takes advantage of that
      existing ICE functionality to provide faster mobility.</t>

      <t>Endpoints that support ICE Mobility perform ICE normally, and MUST
      also include the MOBILITY-SUPPORT attribute in all of their STUN
      requests and their STUN responses. The inclusion of this attribute
      allows the ICE peer to determine if it can achieve mobility using ICE or
      needs to use TURN. To force the use of TURN to achieve ICE mobility, the
      ICE endpoint SHOULD NOT respond to ICE connectivity checks that have an
      IP address and port different from the TURN server, unless those
      connectivity checks contain the MOBILITY-SUPPORT attribute. In this way,
      the remote peer will think those other candidates are invalid (because
      its connectivity checks did not succeed).</t>

      <t>After concluding ICE and moving to the ICE completed state (see
      Section 8 of <xref target="RFC5245"/>) either endpoint or both endpoints
      can initiate ICE Mobility, no matter if it was the Controlling Agent or
      the Controlled Agent during normal ICE processing.</t>

      <section anchor="Mob" title="Absence of other interfaces in Valid list">
        <t>When the interface currently being used for communication becomes
        unavailable then ICE agent acquires a list of interfaces that are
        available and based on the locally configured host policy preferences,
        the ICE endpoint performs ICE Mobility using one of the available
        interfaces. In this case local candidates from the selected interface
        are not present in the valid list. ICE Mobility is performed by:</t>

        <t><list style="numbers">
            <t>The ICE agent remembers the remote host/server reflexive/peer
            reflexive candidates for each component of the media streams
            previously used from the valid list before clearing its ICE check
            list and ICE Valid List.</t>

            <t>The ICE endpoint gathers host candidates of the same address
            family as the remote peer on the new interface, forms a check list
            by creating candidate pairs with local host candidates and remote
            host/server-reflexive candidates collected in step 1, performs
            "Computing Pair Priority and Ordering Pairs" (Section 5.7.2 of
            <xref target="RFC5245"/>), "Pruning the Pairs" (Section 5.7.3 of
            <xref target="RFC5245"/>, "Computing states" (Section 5.7.4 of
            <xref target="RFC5245"/>).</t>

            <t>The ICE endpoint initiates ICE connectivity checks on those
            candidates from the check list in the previous step, and includes
            the MOBILITY-EVENT attribute in those connectivity checks.</t>

            <t>The ICE endpoint acts as controlling agent and the ICE
            connectivity check from the previous step SHOULD also include the
            USE-CANDIDATE attribute to signal an aggressive nomination (see
            Section 2.6 of <xref target="RFC5245"/>).</t>

            <t>The ICE endpoint performs "Discovering Peer Reflexive
            Candidates" (Section 7.1.3.2.1 of <xref target="RFC5245"/>),
            "Constructing a Valid Pair" (Section 7.1.3.2.2 of <xref
            target="RFC5245"/>), "Updating Pair States" (Section 7.1.3.2.3 of
            <xref target="RFC5245"/>), and "Updating the Nominated Flag"
            (Section 7.1.3.2.4 of <xref target="RFC5245"/>). When the valid
            list contains a candidate pair for each component then ICE
            processing is considered complete for the media stream and ICE
            agent can start sending media using the nominated candidate
            pair.</t>

            <t>Once ICE connectivity checks for all of the media streams are
            completed, the controlling ICE endpoint follows the procedures in
            Section 11.1 of <xref target="RFC5245"/>, specifically to send
            updated offer if the candidates in the m and c lines for the media
            stream (called the DEFAULT CANDIDATES) do not match ICE's SELECTED
            CANDIDATES (also see Appendix B.9 of <xref
            target="RFC5245"/>).</t>
          </list></t>

        <t>The ICE endpoint even after Mobility using ICE is successful can
        issue an updated offer indicating ICE restart if connectivity checks
        using higher priority candidate pairs are not successful.</t>

        <t>Mobility using ICE could fail in case of Simultaneous Mobility or
        if the ICE peer is behind NAT that performs Address-Dependent
        Filtering (see Section 5 of <xref target="RFC5245"/>). Hence the ICE
        endpoint in parallel will re-establish connection with the SIP proxy.
        It will then determine whether to initiate ICE restart under the
        following conditions:</t>

        <t><list style="letters">
            <t>After re-establishing connection with the SIP proxy and before
            sending new offer to initiate ICE restart if Mobility using ICE is
            successful then stop sending the new offer.</t>

            <t>After successful negotiation of updated offer/answer to
            initiate ICE restart, proceed with ICE restart and stop Mobility
            using ICE if ICE checks are in the Running/Failed states or ICE is
            partially successful and not yet reached ICE complete state. It's
            not implementation friendly to have to two checks running in
            parallel. ICE restart can re-use partial successful ICE
            connectivity check results from Mobility using ICE if required as
            optimization.</t>
          </list></t>

        <section anchor="recvMob" title="Receiving ICE Mobility event">
          <t>A STUN Binding Request containing the MOBILITY-EVENT attribute
          MAY be received by an ICE endpoint. The agent MUST use short-term
          credential to authenticate the STUN request containing the
          MOBILITY-EVENT attribute and perform a message integrity check. The
          ICE endpoint will generate STUN Binding Response containing the
          MOBILE-SUPPORT attribute and the ICE agent takes role of controlled
          agent. If STUN Request containing the MOBILITY-EVENT attribute is
          received before the endpoint is in the ICE Completed state, it
          should be silently discarded.</t>

          <t>The agent remembers the highest-priority nominated pairs in the
          Valid list for each component of the media stream, called the
          previous selected pairs before removing all the selected candidate
          pairs from the Valid List . It continues sending media to that
          address until it finishes with the steps described below. Because
          those packets might not be received due to the mobility event, it
          MAY cache a copy of those packets.</t>

          <t><list style="numbers">
              <t>The ICE endpoint constructs a pair whose local candidate is
              equal to the transport address on which the STUN request was
              received with MOBILITY-EVENT, USE-CANDIDATE attributes and a
              remote candidate equal to the source transport address where the
              STUN request came from.</t>

              <t>The ICE endpoint will add this pair to the valid list if not
              already present.</t>

              <t>The agent sets the nominated flag for that pair in the valid
              pair to true. ICE processing is considered complete for a media
              stream if the valid list contains a selected candidate pair for
              each component and ICE agent can start sending media.</t>
            </list></t>

          <t>The ICE endpoint will follow Steps 1 to 3 when subsequent STUN
          Binding Requests are received with MOBILITY-EVENT and USE-CANDIDATE
          attributes.</t>
        </section>
      </section>

      <section title="Keeping unused relayed candidates active">
        <t>The ICE endpoints can maintain the relayed candidates active even
        when not actively used, so that relayed candidates can be tried if ICE
        connectivity checks using other candidate types fails. The ICE agent
        will have to create permissions in the TURN server for the remote
        relayed candidate IP addresses and perform the following steps:</t>

        <t><list style="numbers">
            <t>The ICE agent will keep the relayed candidates alive using
            Refresh transaction, as described in <xref target="RFC5766"/>.</t>

            <t>When the endpoint IP address changes due to mobility, the ICE
            agent will refresh it's allocation with TURN server using <xref
            target="I-D.wing-tram-turn-mobility"/>.</t>

            <t>The ICE agent will pair local and remote relayed candidates for
            connectivity checks when performing the steps in <xref
            target="Mob"/>.</t>

            <t>If the ICE connectivity check succeeds only with local and
            remote relayed candidates, it suggests that either other peer is
            roaming at the same time or is behind Address-Dependent Filtering
            NAT. The ICE agent adds the relayed candidate pair to the valid
            list and marks it as selected. The ICE agent can now send media
            using the newly selected relayed candidate pair. The Mobile device
            must re-establish connection with SIP proxy, issue an updated
            offer indicating ICE restart so that media can switched to
            higher-priority candidate pairs.</t>
          </list></t>

        <t>This approach assists Mobility using ICE to succeed but brings in
        additional overhead of maintaining relayed candidates.In case of
        Simultaneous Mobility, host candidates can change for both the
        endpoints by maintaining relayed candidates and using <xref
        target="I-D.wing-tram-turn-mobility"/>, media session can be
        established using the relayed candidate pair.</t>
      </section>

      <section title="New STUN Attributes">
        <t>Three new attributes are defined by this section: MOBILITY-EVENT,
        MOBILITY-SUPPORT.</t>

        <t>The MOBILITY-EVENT attribute indicate the sender experienced a
        mobility event. This attribute has no value, thus the attribute length
        field MUST always be 0. Rules for sending and interpretation of
        receiving are described above.</t>

        <t>The MOBILITY-SUPPORT attribute indicates the sender supports ICE
        Mobility, as defined in this document. This attribute has no value,
        thus the attribute length field MUST always be 0. Rules for sending
        and interpretation of receiving are described above.</t>
      </section>
    </section>

    <section title="Make Before Break">
      <t>When a new interface comes up and initially selected interface
      becomes deprioritized (e.g due to a low cost interface becoming
      available). The ICE endpoint re-connects to the SIP proxy using the new
      interface, gather candidates, exchange updated offer/exchange to restart
      ICE. Once ICE processing has reached the Completed state then the ICE
      endpoint can successfully switch the media over to the new interface.
      The interface initially used for communication can now be turned off
      without disrupting communications.</t>
    </section>

    <section anchor="compare"
             title="Comparison to ICE Restart and Trickle ICE">
      <t>There has been some concern that ICE Mobility is unnecessary, and
      that an ICE restart (section 9.1.1.1 of <xref target="RFC5245"/>) would
      provide exactly the same functionality as ICE Mobility. These sections
      examine how ICE restart and Trickle ICE <xref
      target="I-D.rescorla-mmusic-ice-trickle"/> compare with ICE
      Mobility.</t>

      <section anchor="diff" title="Break Before Make - ICE Restart">
        <t><list style="symbols">
            <t hangText="Break Before Make:">If ICE Restart is used for RTP
            Mobility then in case of Break before Make,<list style="numbers">
                <t>Before the endpoint can send an ICE restart message, it has
                to first re-establish communication with its SIP proxy. This
                consumes one round-trip for both TCP and UDP. If the
                connection is protected with TLS (TCP) or DTLS (UDP), we can
                assume TLS session resumption <xref target="RFC5077"/> will be
                used to reduce the number of TLS messages. With TLS session
                resumption, this consumes 1 round trip. If TLS session
                resumption is not available, a full TLS handshake consumes 2
                round trips. This is a total of 2 round trips (with session
                resumption) to 3 round trips (without session resumption),
                which is multiplied by the round trip time to the SIP proxy.
                The round trip time is dependent on a particular network or
                deployment, for example in second (2.5G), third (3G)
                generation wireless networks and satellite communication round
                trip time could be higher than 250ms. These calculations are
                only considering the network round-trip time and do not
                consider the wall-clock time to validate the TLS certificates
                or generate the TLS keys on the TLS client or the TLS server,
                which would make this longer.</t>

                <t>While performing the above steps to re-establish SIP
                connectivity with its SIP proxy, the endpoint will gather host
                candidates which incur no network traffic, server-reflexive
                candidates which incur a round-trip to a STUN server, and
                relayed candidates which incurs three round trips (two for
                re-authentication and one for creating the TURN permission).
                The STUN and TURN communications can be performed in parallel
                with the SIP connectivity check from step (1), above.</t>

                <t>The endpoints through the SIP server will exchange
                offer/answer. The SIP server could also be located halfway
                around the world from the endpoints and the delay could be
                significant. For SIP over UDP the endpoint will have send a
                SIP request and wait for the response to arrive.</t>

                <t>ICE restart requires sending a new INVITE. A new INVITE
                cannot be sent if there is an open SIP dialog, such as a
                previous INVITE. This means rapid mobility events will not
                work well, and there is also an increased likelihood for glare
                (both endpoints sending INVITEs at the same time).</t>
              </list></t>
          </list></t>
      </section>

      <section title="Break Before Make - Trickle ICE">
        <t><list style="symbols">
            <t hangText="Break Before Make:">If Trickle ICE <xref
            target="I-D.rescorla-mmusic-ice-trickle"/> is used for RTP
            Mobility then in case of Break before Make,<list style="numbers">
                <t>Trickle ICE can begin connectivity checks while the
                endpoint is still gathering candidates and can considerably
                shorten the time necessary for ICE processing to complete. It
                still involves the overhead of step 1 explained in section
                <xref target="diff"/>.</t>

                <t>The endpoint would learn host candidates and inform them to
                the remote peer in offer, the remote peer will provide its
                candidates in answer. The host, server reflexive, peer
                reflexive and relayed candidates of the remote peer may not
                change and the remote peer does not have to gather the
                candidates again. Trickle ICE will test local host candidates
                with all types of remote candidates provided by the remote
                peer in the answer. <list style="letters">
                    <t>If the endpoint is not behind NAT and the ICE peer is
                    behind NAT performing endpoint dependent filtering (or
                    firewall blocking unsolicited incoming traffic) then ICE
                    connectivity checks initiated by the endpoint to the
                    remote peer will succeed as a consequence of suicide ICE
                    connectivitivy check packets.</t>

                    <t>If the endpoint is behind NAT and ICE peer is behind
                    endpoint-dependent filtering NAT then ICE connectivity
                    checks using the first offer/answer will fail but will
                    later succeed in subsequent offer/answer where the
                    endpoint provides server-reflexive candidates.</t>
                  </list></t>

                <t>Trickle ICE must be supported by both endpoints for it be
                used.</t>
              </list></t>

            <t hangText="Break Before Make:">If both endpoints support TRICKLE
            ICE then it is RECOMMENDED that TRICKLE ICE be tried instead of
            ICE restart in steps (a) and (b) of <xref target="Mob"/>.</t>
          </list></t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>IANA is requested to add the following attributes to the <xref
      target="iana-stun">STUN attribute registry</xref>, <list style="symbols">
          <t>MOBILITY-EVENT (0x802, in the comprehension-required range)</t>

          <t>MOBILITY-SUPPORT (0x8000, in the comprehension-optional
          range)</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>A mobility event only occurs after both ICE endpoints have exchanged
      their ICE information. Thus, both username fragments are already known
      to both endpoints. Each endpoint contributes at least 24 bits of
      randomness to the ice-ufrag (Section 15.4 of <xref target="RFC5245"/>),
      which provides 48 bits of randomness. An off-path attacker would have to
      guess those 48 bits to cause the endpoints to perform HMAC-SHA1
      validation of the MESSAGE-INTEGRITY attribute.</t>

      <t>An attacker on the path between the ICE endpoints will see both
      ice-ufrags, and can cause the endpoints to perform HMAC-SHA1 validation
      by sending messages from any IP address.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson,
      Emil Ivov for review and comments.</t>
    </section>

    <section title="Change History">
      <t>[Note to RFC Editor: Please remove this section prior to
      publication.]</t>

      <section title="Changes from draft-wing-mmusic-ice-mobility-00 to -01">
        <t><list style="symbols">
            <t>Updated section 3</t>
          </list></t>
      </section>

      <section title="Changes from draft-wing-mmusic-ice-mobility-01 to -02">
        <t><list style="symbols">
            <t>Updated Introduction, Notational Conventions, sections 3.1,
            3.2.</t>

            <t>Updated section 3.5</t>
          </list></t>
      </section>

      <section title="Changes from draft-wing-mmusic-ice-mobility-02 to -03">
        <t><list style="symbols">
            <t>Moved sections Presence of other interfaces in Valid list,
            Losing an Interface to Appendix.</t>
          </list></t>
      </section>

      <section title="Changes from draft-wing-mmusic-ice-mobility-03 to -04">
        <t><list style="symbols">
            <t>Added Section 6.</t>
          </list></t>
      </section>

      <section title="Changes from draft-wing-mmusic-ice-mobility-04 to -05">
        <t><list style="symbols">
            <t>Updated Section 6.</t>
          </list></t>
      </section>

      <section title="Changes from draft-wing-mmusic-ice-mobility-05 to -06">
        <t><list style="symbols">
            <t>Updated Section 5.</t>

            <t>Added Implementation Status section.</t>
          </list></t>
      </section>

      <section title="Changes from draft-wing-mmusic-ice-mobility-06 to -07">
        <t><list style="symbols">
            <t>Removed Turn Mobility</t>
          </list></t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.5245"?>

      <?rfc include='reference.RFC.5766'?>

      <?rfc include='reference.RFC.5389'?>

      <?rfc include='reference.I-D.wing-tram-turn-mobility' ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.6263' ?>

      <?rfc include='reference.RFC.5780' ?>

      <?rfc include='reference.RFC.5077' 
?>

      <?rfc include='reference.RFC.5763' ?>

      <?rfc include='reference.RFC.6982' ?>

      <?rfc include='reference.I-D.rescorla-mmusic-ice-trickle'?>

      <reference anchor="iana-stun"
                 target="http://www.iana.org/assignments/stun-parameters/stun-pa rameters.xml">
        <front>
          <title>IANA: STUN Attributes</title>

          <author fullname="IANA" surname="IANA">
            <organization/>
          </author>

          <date month="April" year="2011"/>
        </front>
      </reference>
    </references>

    <section title="">
      <t/>

      <section anchor="reuse"
               title="Presence of other interfaces in Valid list">
        <t>This technique is optional and only relevant if there is a host
        policy to maintain unused candidates on other interfaces using the
        steps in <xref target="keep"/>. ICE Agent can maintain unused
        candidates on other interfaces if it detects that it is behind
        Address-Dependent Filtering NAT or Firewall. ICE Agent can detect NAT,
        Firewall behaviour using the procedure explained in <xref
        target="RFC5780"/>. When the interface currently being used for media
        communication becomes unavailable. If other interfaces are available
        and local candidates from these interfaces are already present in the
        valid list then ICE endpoint will perform the following steps:</t>

        <t><list style="numbers">
            <t>The ICE endpoint based on the locally configured host policy
            preferences, will select a interface whose candidates are already
            present in the valid list.</t>

            <t>The ICE endpoint clears all the pairs in the valid list
            containing the IP addresses from the interface that become
            unavailable.</t>

            <t>The ICE endpoint initiates ICE connectivity checks on the
            selected interface. The ICE endpoint acts as controlling agent and
            MUST include MOBILITY-EVENT attribute to signal mobility event and
            SHOULD also include the USE-CANDIDATE attribute to signal an
            aggressive nomination (see Section 2.6 of <xref
            target="RFC5245"/>). When all components have a nominated pair in
            the valid list, media can begin to flow using the highest priority
            nominated pair.</t>

            <t>The ICE endpoint will re-establish connection with the SIP
            proxy. Once ICE connectivity checks for all of the media streams
            are completed, the controlling ICE endpoint follows the procedures
            in Section 11.1 of <xref target="RFC5245"/>, specifically to send
            updated offer if the candidates in the m and c lines for the media
            stream (called the DEFAULT CANDIDATES) do not match ICE's SELECTED
            CANDIDATES (also see Appendix B.9 of <xref
            target="RFC5245"/>).</t>
          </list></t>

        <t>The ICE endpoint after Mobility using ICE is successful can issue
        an updated offer indicating ICE restart if higher priority interface
        becomes available.</t>

        <section anchor="recvMob1" title="Receiving ICE Mobility event">
          <t>The ICE endpoint that receives ICE Mobility Event will perform
          the steps in <xref target="recvMob"/>.</t>
        </section>
      </section>

      <section title="Losing an Interface">
        <t>When an interface is lost, the SDP MAY be updated, so that the
        remote ICE host does not waste its efforts with connectivity checks to
        that address, as those checks will fail. Because it can be argued that
        this is merely an optimization, and that the interface loss might be
        temporary (and soon regained), and that ICE has reasonable
        accommodation for candidates where connectivity checks timeout, this
        specification does not strongly encourage updating the SDP to remove a
        lost interface.</t>

        <t>Likewise, this specification recommends that ICE candidate
        addresses in valid list be maintained actively, subject to the host's
        policy. For example, battery operated hosts have a strong incentive to
        not maintain NAT binding for server reflexive candidates learnt
        through STUN Binding Request, as the maintenance requires sending
        periodic STUN Binding Indication. As another example, a host that is
        receiving media over IPv6 may not want to persist with keeping a
        NATted IPv4 mapping alive (because that consumes a NAT mapping that
        could be more useful to a host actively utilizing the mapping for real
        traffic).</t>

        <t>Note: this differs from Section 8.3 of <xref target="RFC5245"/>,
        which encourages abandoning unused candidates.</t>

        <section anchor="keep"
                 title="Keeping unused candidates in the valid list active">
          <t>ICE endpoint subject to host policy can continue performing ICE
          connectivity checks using candidates from other interfaces on the
          host even after ICE is complete. If valid list contains unused
          candidate pairs from other interfaces and one of these interfaces
          can be selected to send to media in case the existing interface used
          for media is unavailable then ICE endpoint can keep the unused
          candidate pairs from other interface{s} alive by sending keepalives
          every NN seconds. It is recommended to only keep
          host/server-reflexive candidates active in the valid list and not
          the relayed candidates.</t>

          <section title="Sending keep alive requests">
            <t>Application Mechanism for Keeping Alive the NAT Mappings
            Associated with RTP / RTP Control Protocol (RTCP) Flows <xref
            target="RFC6263"/> describes various reasons for doing keepalives
            on inactive streams and how to keep NAT mapping alive. However
            this specification requires some additional functionality
            associated with the keepalives.</t>

            <t>STUN binding requests MUST be used as the keepalive message
            instead of the STUN Binding indication as specified in <xref
            target="RFC5245"/>. This is to ensure positive peer consent from
            the remote side that the candidate pair is still active and in
            future mobility can be achieved using the steps in <xref
            target="reuse"/> . The request must include the MOBILITY-SUPPORT
            attribute. If the STUN binding response matches a pair in the
            checklist then that candidate pair should be kept in the list. If
            the STUN transaction fails then the candidate pair will be removed
            from valid list.</t>
          </section>

          <section title="Receiving keep alive requests">
            <t>Upon receiving a STUN binding request containing a
            MOBILITY-SUPPORT attribute even when ICE processing is in the
            Completed state, the ICE endpoint will add this pair to the valid
            list if not already present and generate STUN Binding Response
            containing the MOBILE-SUPPORT attribute.</t>
          </section>
        </section>
      </section>
    </section>
  </back>
</rfc>
