<?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-penno-rtcweb-pcp-00" ipr="trust200902">
  <front>
    <title abbrev="PCP with WebRTC">PCP Considerations for WebRTC
    Usage</title>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

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

          <city>San Jose</city>

          <region></region>

          <code>95134</code>

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

        <phone></phone>

        <email>repenno@cisco.com</email>

        <uri></uri>
      </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="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="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date />

    <workgroup>RTCWEB</workgroup>

    <abstract>
      <t>This document describes the motivations for WebRTC applications to be
      PCP-aware and the benefits provided by PCP-capable NATs and
      Firewalls.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Port Control Protocol (PCP, <xref target="RFC6887"></xref>) provides
      a mechanism to describe a flow to the network. The primary driver for
      PCP has been creating port mappings on NAT and firewall devices. When
      doing this, PCP pushes flow information from the host into the network
      (specifically to the network's NAT or firewall device), and receives
      information back from the network (from the NAT or firewall device).</t>

      <t>The Web Real-Time communication (WebRTC) framework <xref
      target="I-D.ietf-rtcweb-overview"></xref> provides the protocol building
      blocks to support direct, interactive, real-time communication using
      audio, video, collaboration, games, etc., between peer web-browsers.
      WebRTC application use Interactive Connectivity Establishment (ICE)
      protocol <xref target="RFC5245"></xref> for gathering candidates,
      prioritizing them, choosing default ones, exchanging them with the
      remote party, pairing them and ordering them into check lists. Once all
      of the above steps have been completed the participating ICE agents can
      begin a phase of connectivity checks and eventually select a pair of
      candidates that will be used for real-time communication.</t>

      <t>This specification describes the reasons for WebRTC applications to
      be PCP-aware and use PCP along side with STUN and TURN. It also explains
      the benefits for a network that deploy PCP-controlled NATs and
      Firewalls.</t>

      <!--
      <t>Details related to the specific case where WebRTC is enabled in a
      controlled network environment are discussed in <xref
      target="no_checks"></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"></xref>.</t>

      <t>This document uses terms defined in <xref target="RFC5389"></xref>
      and <xref target="RFC5766"> </xref>.</t>

      <t>eNodeB: The eNodeB is a base station entity that supports the
      Long-Term Evolution (LTE) air interface <xref
      target="RFC6459"></xref>.</t>
    </section>

    <section anchor="PCP" title="Advantages of using PCP with WebRTC">
      <t>The below sections explain the problems with NAT and Firewall,
      current techniques used to solved them and the PCP solution in these
      scenarios.</t>

      <section anchor="FW" title="Firewalls Blocking UDP">
        <t>Enterprise networks may deploy firewalls with restrictive policies
        configured to block UDP traffic. These firewalls may be configured to
        permit TCP or HTTP(s) traffic only. One of the reasons for blocking
        UDP could be that there is no way for the firewall to determine when
        the endpoints have terminated the call, in which case the firewall has
        to close the dynamic mapping based on firewall UDP mapping timer
        value. <xref target="RFC4787"></xref> mandates that the UDP mapping
        timer for NAT must not expire in less than 2 minutes and recommends a
        default value of five minutes or more. Firewalls are likely to follow
        the same recommendation for their UDP mapping timer, which would be
        applicable to both IPv4 and IPv6 firewalls. The behavioural
        requirements for IPv6 firewalls is explained in section 3.2.3 of <xref
        target="RFC6092"></xref>. <xref
        target="I-D.hutton-rtcweb-nat-firewall-considerations"></xref> gives
        details of other organization e.g. a public service agency or
        university that deploy firewall which may have restrictive firewall
        policy to block UDP traffic.</t>

        <t>Modern firewalls may also have application-layer gateways (ALGs)
        perform policy enforcement to permit peer-to-peer UDP media session.
        Using the ALG, a firewall can determine when the call is terminated
        and close any dynamic mappings created for the media session. But the
        problem is the session signaling between the WebRTC application
        running in the browser and the web server could be using TLS, in which
        case the ALG no longer has access to the signaling. Moreover, WebRTC
        does not enforce a particular session signaling protocol to be used,
        so firewalls using ALGs would fail to inspect the signaling to
        identify the 5-tuple used for each media stream. Furthermore, the
        session signaling and the peer-to-peer media may traverse different
        Firewalls.</t>

        <t>Using TURN for all such communication to by-pass firewall causes
        the following problems:</t>

        <t><list style="symbols">
            <t>TURN server could increase media latency as explained in
            section 4.1.2.2 of <xref target="RFC5245"></xref>. Using a
            reliable and ordered protocol like TCP instead of UDP to transfer
            real-time media is problematic as delays would be directly
            noticeable and may be unacceptable to the user.</t>

            <t>High-end TURN server would be needed (For example when
            TLS-over-TCP transport is used between the client and the server)
            to cater to all such calls.</t>

            <t>TURN server could either be located in the DMZ of the
            enterprise network or located in the public Internet. If the TURN
            server is located in the public Internet it comes at a high cost
            to the provider of the TURN server, since the server typically
            needs a high-bandwidth connection to the Internet as explained in
            the Introduction of <xref target="RFC5766"></xref>. As a
            consequence, it is best to use a TURN server only when a direct
            communication path cannot be found. When the client and a peer use
            ICE to determine the communication path, ICE will use hole
            punching techniques to search for a direct path first and only use
            a TURN server when a direct path cannot be found.</t>

            <t>Some of the other limitations of TURN explained in section 2.6
            of <xref target="RFC5766"></xref> are, the value of the Diffserv
            field may not be preserved, the Explicit Congestion Notification
            (ECN) field may be reset etc.</t>
          </list></t>

        <t>PCP resolves the above problems by restricting firewall traversal
        to authorized PCP clients and communicating mapping lifetimes and call
        termination between the PCP client and the PCP-controlled firewall. A
        PCP Server can also enforce per-host quotas for mappings.</t>
      </section>

      <section title="Firewalls permit specific WebRTC servers">
        <t>When an enterprise uses a trusted WebRTC server deployed in a 3rd
        party network for communication, the enterprise firewall could have
        granular policies to permit peer-to-peer UDP media session only when
        the call is initiated using the selected WebRTC server (Dr. Good) it
        trusts and block others (Dr. Evil). Firewall policy has a white-list
        of permitted outside applications/sites and can blacklist HTTP(S)
        connections via various forms of detections (destination DNS lookup,
        HTTP URL Filtering, DPI proxy that at least performs HTTPS inspection
        of URL in certificate, Subject Name of TLS exchange and validates SSL
        records etc). Firewall in this configuration would also block TCP
        connection to arbitrary TURN servers in the Internet. 3GPP networks
        may also have a similar configuration where IMS services of certain
        other operators are permitted and others are blocked [<xref
        target="TR33.830"></xref>.</t>

        <t>With PCP, this problem is solved by associating the media session
        with the signaling session. This is done by sending a cryptographic
        token in the signaling which authorizes the firewall mapping for the
        media session.</t>
      </section>

      <section title="ICE Lite">
        <t>For scenarios where the client is connected to the public Internet
        and has public IP address at which it can receive packets from the
        remote peer and uses ICE LITE implementation explained in section 2.7
        of <xref target="RFC5245"></xref>, the ICE Lite endpoint will not
        generate its own ICE connectivity checks, by definition. Thus, if an
        ICE Lite endpoint is behind a firewall that blocks unsolicited
        incoming traffic then ICE Lite will fail.</t>

        <t>This workaround for solving the problem is by using full ICE or by
        changing the filtering policy on the firewall to permit unsolicited
        incoming UDP traffic which would effectively disable the purpose of
        firewall. Full ICE will take more time to be adapted especially with
        legacy VoIP equipment which will initially start with ICE-Lite
        implementation as discussed in section 6 of <xref
        target="I-D.cbran-rtcweb-nat"></xref>.</t>

        <t>With PCP, a firewall can filter incoming UDP traffic and PCP client
        can communicate exceptions to the firewall to permit specific mappings
        when a call is active. In this way, the ICE Lite endpoint and its
        network are protected from unsolicited incoming UDP traffic, and can
        still operate using ICE Lite (rather than full ICE).</t>
      </section>

      <section title="Reducing Call Set-Up Time">
        <t>There are initiatives to speedup ICE processing in order to reduce
        call setup time using techniques such as Trickle ICE <xref
        target="I-D.rescorla-mmusic-ice-trickle"></xref> and RTP multiplexing
        <xref target="I-D.ietf-rtcweb-rtp-usage">Section 4.4 of</xref>.
        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. RTP multiplexing suggests to bind
        interactive audio and interactive video to the same 5-tuple {dest
        addr, source addr, protocol, dest port, source port} to optimize NAT
        resource usage and shorten the call setup time.</t>

        <t>PCP can help reduce call set-up time by speeding up ICE and, if
        appropriate, at the same time allowing each media for flow over a
        different 5-tuple.</t>

        <section title="ICE Speedup">
          <t>ICE requires time to perform its setup operations. This time
          grows in proportion to the number of transport sessions which must
          be opened in order to support the call. If using a different IP
          addresses and/or ports for audio versus video streams, call setup
          time will increase. The precise amount of this increase depends on
          the type of NAT and other factors like packet loss. The use of RTP
          Multiplexing technique introduces some QoS challenges in many
          networks, e.g., In Mobile Networks the QoS considerations are
          explained in Section 4.1 of <xref
          target="I-D.reddy-rtcweb-mobile"></xref>.</t>

          <t>Fast call setup time and QoS can both be retained by using PCP.
          External IP addresses and ports can be learnt faster using PCP than
          other techniques because the PCP client is communicating only with
          PCP servers in the Home and Service Provider network. In contrast,
          STUN and TURN servers may be located halfway around the world from
          the endpoint adding delay to learn server-reflexive and relayed
          candidates. Trickle ICE can begin connectivity checks using the
          candidates learnt from PCP, while the endpoint is still gathering
          other candidate types and thus can considerably shorten the time
          necessary for ICE processing to complete.</t>
        </section>

        <section title="Pre-allocating ports to speed call setup time">
          <t>The external IP:port allocated through PCP belong to the client
          for duration of the lifetime of the mapping. This means that
          connectivity checks for a new call can begin immediately using the
          already allocated external IP:port and if necessary the client can
          extend the lifetime of the mapping. TURN allocations can also be
          extended using Refresh transaction to update the time-to-expiry of
          existing allocation and thus can be used for a new call immediately.
          Server Reflexive candidates learnt using STUN can also be maintained
          for a new call but requires the endpoint to send frequent keepalives
          to prevent the NAT and firewall mappings from expiring.</t>

          <t>The PCP client for fast call setup can also use PORT_SET option
          <xref target="I-D.ietf-pcp-port-set"></xref> requesting the PCP
          server to pre-allocate contiguous ports with port parity
          preservation.</t>
        </section>
      </section>

      <section title="NAT">
        <t>Direct peer-to-peer communication is not possible if both NATs are
        of a certain type that changes the outside port number when connecting
        to new hosts (NAT behaviour "address-dependent mapping" or "address
        and-port-dependent mapping" as described in <xref
        target="RFC4787"></xref>).</t>

        <t>When such NAT devices are encountered, communication can be
        established using a media relay (TURN) server. But using TURN servers
        is expensive as explained in section 4.1.1.2 of <xref
        target="RFC5245"></xref> and other challenges of using TURN are
        discussed in <xref target="FW"></xref> . Relayed candidates should
        only be used as last-resort when connectivity checks using other
        candidate types are not successful.</t>

        <t>PCP improves this situation by creating explicit bindings on
        PCP-controlled NATs and can adjust their mapping and filtering
        behavior so that connections can be successfully created. PCP can also
        recursively communicate with multiple layers of NATs using <xref
        target="I-D.ietf-pcp-proxy"></xref>. Usage of STUN and PCP for
        learning candidates, prioritization, encoding them in offer or answer
        is explained in <xref target="STUN"></xref>.</t>
      </section>

      <section title="Optimizing NAT and Firewall Keepalives">
        <t>Applications like WebRTC need to keep their Network Address
        Translator (NAT) and firewall mappings alive for long periods of time,
        even when they are otherwise not sending or receiving any traffic. The
        signaling protocol used for WebRTC would want to keep the
        client-server connection alive for as long as the application is
        running. When the WebRTC application has otherwise no traffic to send,
        specific keep-alive messages are sent periodically to ensure that the
        NAT/Firewall state in the middle does not expire. The endpoint would
        also have to send keepalives for the media session to keep
        NAT/Firewall bindings alive. As NAT/firewall mapping timers may be
        short and unknown to the endpoint, the keepalive messages are sent
        frequently.</t>

        <t>In cellular mobile networks, frequent keepalive messages make the
        radio transition between active and power-save states causing
        signaling congestion. The excessive time spent on the active state due
        to keepalives also greatly reduces the battery life of the cellular
        connected devices such as smartphones or tablets.</t>

        <t>PCP is useful to reduce NAT and firewall keepalive messages (e.g.,
        Section 3.4 of <xref
        target="I-D.reddy-pcp-optimize-keepalives"></xref>) for both signaling
        protocol and media session.</t>
      </section>

      <section title="Faster Flow Failure Detection">
        <t>If a NAT device has rebooted, lost its mappings or has its external
        IP address changed then it may take few minutes before the endpoint
        realizes that the connectivity is lost, that would result in
        disruption of signaling and media traffic. Application can find that
        the signaling session is broken by using TCP keepalive probes, the
        time taken to detect that the connection is broken depends on the
        frequency of keepalive probes. If the endpoint is using sendonly media
        streams, it may take few minutes based on RTCP reports to realize that
        the connectivity is lost. WebRTC client will then have to re-establish
        connection with the WebRTC server and initiate ICE restart.</t>

        <t>Using the Rapid Recovery procedure explained in Section 14 of <xref
        target="RFC6887"></xref>, the PCP client upon receiving a PCP ANNOUNCE
        from a PCP server, becomes aware that the PCP server has rebooted or
        lost its mapping state. The PCP client issues new PCP requests to
        recreate any lost mapping state and thus reconstructs lost mappings
        fast enough that existing media streams do not break and re-establish
        connectivity with its WebRTC server.</t>

        <t>If for some reason PCP server determines that some or all of its
        mappings have become unusable (e.g., when a home gateway is assigned a
        different external IPv4 address by the upstream DHCP server) then the
        PCP server automatically repairs its mappings and notifies its clients
        about the new External IP address and port as part of the Rapid
        Recovery techniques explained in Section 14.2 of <xref
        target="RFC6887"></xref>. The client based on this notification can
        use MICE <xref target="I-D.wing-mmusic-ice-mobility"></xref> or ICE
        Restart to achieve RTP Mobility.</t>
      </section>

      <section title="3GPP Selective IP Traffic Offload (SIPTO)">
        <t>Given the exponential growth in the mobile data traffic, Mobile
        Operators are looking for ways to offload some of the IP traffic flows
        at the nearest access edge that has an Internet peering point. This
        approach results in efficient usage of the mobile packet core and
        helps lower the transport cost. Since Release 10, 3GPP starts
        supporting of Selected IP Traffic Offload (SIPTO) function defined in
        <xref target="TS23.060"></xref><xref target="TS23.060"></xref><xref
        target="TS23.401">,</xref>. The SIPTO function allows an operator to
        offload certain types of traffic at a network node close to the UE's
        point of attachment to the access network. Limited Mobility support
        available with SIPTO is explained in section 2.3.3 of <xref
        target="I-D.zuniga-dmm-gap-analysis"></xref>.</t>

        <t>If SIPTO is carried out in a Traffic offload Function (TOF) entity
        in the path between the Radio stations and the Mobile Gateway (MGW) as
        explained in <xref target="I-D.reddy-rtcweb-mobile"></xref> and the
        Mobile Node (MN) roams from one eNodeB and changes its point of
        attachment to a new eNodeB NAT changes. In this case host candidates
        for the MN will not change but MN will be behind a new NAT after
        roaming. It may take few minutes before the MN realizes that the
        connectivity is lost, resulting in disruption of signalling and media
        traffic. Application can find that the signaling session is broken by
        using TCP keepalive probes, the time taken to detect that connection
        is broken depends on the frequency of the keepalive probes. If the
        endpoint is using sendonly media streams, it may take few minutes
        based on RTCP reports to realize that the connectivity is lost. WebRTC
        client will then have to re-establish connection with the WebRTC
        server and initiate ICE restart.</t>

        <t>The problem can be mitigated by the following mechanism using
        PCP:</t>

        <t>When TOF receives the SIPTO rules for the MN, the PCP-controlled
        NAT at TOF sends unicast PCP ANNOUNCE response to the MN informing it
        that the NAT has changed. WebRTC application using PCP can verify that
        external IP addresses and ports have changed for the media streams and
        proceed accordingly (e.g., MICE <xref
        target="I-D.wing-mmusic-ice-mobility"></xref> or ICE Restart to
        achieve RTP Mobility).</t>
      </section>

      <section title="Auditing">
        <t>On certain networks, it is necessary to audit communications across
        the network firewall and attribute those communications to certain
        users or users running certain applications. The use case for auditing
        is also explained in Section 4.2.5.1 of <xref
        target="I-D.ietf-rtcweb-use-cases-and-requirements"></xref>.</t>

        <t>Today, this is done by tracking IP address assignment on the
        network and auditing lots of mappings created by firewalls.</t>

        <t>PCP improves that auditing by PCP Authentication <xref
        target="I-D.ietf-pcp-authentication"></xref>. A PCP server can audit
        all traffic including media sessions from inside an enterprise
        premises to any external peer. An enterprise that uses an WebRTC based
        web application for communication and desires to audit all WebRTC
        based application sessions used from inside the company towards any
        external peer can deploy a PCP-controlled firewall and enforce a
        policy on the PCP-controlled firewall to mandate PCP client
        authentication. Only after successful authentication, PCP client will
        be permitted to create dynamic mappings on the firewalls and NATs.</t>
      </section>

      <section title="NAT64">
        <t>For the IPv6-only WebRTC client to establish media session with
        IPv4-only WebRTC client it must learn prefix64(s).</t>

        <t>The workaround for solving the problem is by using heuristics is
        explained in <xref
        target="I-D.ietf-behave-nat64-discovery-heuristic"></xref>. Various
        other solutions including STUN for discovery based on heuristics are
        discussed in <xref
        target="I-D.ietf-behave-nat64-learn-analysis"></xref>.</t>

        <t>PCP allows to learn PREFIX64 when a NAT64 is in the path <xref
        target="I-D.ietf-pcp-nat64-prefix64"></xref>. PCP client can directly
        communicate with PCP-controlled NAT64 device to learn the Prefix64(s).
        This feature is useful to help establishing successful media session
        between an IPv6-only WebRTC client and an IPv6-only WebRTC client. The
        other advantages of using PCP is that endpoint will be notified
        whenever the Network Specific Prefix (NSP) is changed and endpoint
        will also learn multiple NSPs configured in the network.</t>

        <t>Experimental results related to the use of this feature for
        SIP-based applications in general are provided in <xref
        target="I-D.boucadair-pcp-nat64-experiments">Section 4.2
        of</xref>.</t>
      </section>
    </section>

    <section anchor="usage" title="Usage of PCP with STUN and TURN">
      <t></t>

      <section anchor="STUN" title="STUN">
        <t>This section explains the procedure to use STUN and PCP with ICE
        <xref target="RFC5245"></xref>:</t>

        <t>The ICE agent learns external IP addresses and ports using the PCP
        MAP opcode. If server reflexive candidates and external IP addresses
        learnt using PCP are different than the candidates learnt through
        STUN, the PCP discovered candidates are encoded in the ICE offer and
        answer just like the server reflexive candidates learnt using STUN
        <xref target="RFC5389"></xref>. When using the recommended formula
        explained in Section 4.1.2.1 of <xref target="RFC5245"></xref> to
        compute priority for the candidate learnt through PCP, the ICE agent
        should use a preference value greater than the server reflexive
        candidate and hence they are tested before the server reflexive
        candidates.</t>

        <t>The recommended type preference value is 105 for candidates
        discovered using PCP and is explained in section 4.2 of <xref
        target="RFC6544"></xref>.</t>

        <t>During connectivity checks the ICE agent SHOULD check if the
        XOR-MAPPED-ADDRESS from the STUN Binding response matches the external
        address and port provided by PCP MAP response.</t>

        <t><list style="symbols">
            <t>If the match is successful, then it indicates that only
            PCP-aware NATs exist between the peers. PCP can further be used to
            keep the NAT bindings alive and close the mappings.</t>

            <t>If the match is not successful then it indicates PCP unaware
            NATs exist between the peers.</t>
          </list></t>
      </section>

      <section title="TURN">
        <t>TURN server may be used for the following reasons even if PCP
        capable Firewalls and NATs exist:</t>

        <t><list style="symbols">
            <t>Users of WebRTC based web application may choose to use TURN so
            as to not expose the host candidate addresses to the remote peer
            for privacy reasons.</t>

            <t>IPv6 support in TURN includes IPv4-to-IPv6 and IPv6-to-IPv4
            relaying <xref target="RFC6156"></xref>.</t>

            <t>ICE connectivity checks using the candidates provided by STUN
            and PCP could fail because the endpoint is behind PCP-unaware NAT
            that performs address-dependent mapping and thus only relayed
            candidate allocated from the TURN server gets selected for
            media.</t>

            <t>TURN server could also be used for RTP Mobility <xref
            target="I-D.wing-mmusic-ice-mobility"></xref>, etc.</t>
          </list></t>
      </section>
    </section>

    <!--
    <section anchor="no_checks"
             title="Sample Use Case: WebRTC in Controlled Environments">
      <t>This section focuses on the sample use case where WebRTC is deployed
      in a controlled environment such as within a mobile network or among
      sites belonging to the same enterprise network. Within this section, a
      controlled environment denotes any network which does not require
      connectivity checks. Such controlled environments may allow:<list
          style="numbers">
          <t>Communications between two WebRTC clients both connected to the
          same underlying managed infrastructure.</t>

          <t>Communications between a WebRTC client and a legacy SIP UA
          (through a WebRTC-IMS Gateway for instance).</t>

          <t>Communications from/to a WebRTC client to/from any destination
          located in PSTN or PLMN (through a PSTN Gateway for instance).</t>
        </list></t>

      <t>In such controlled networks, a WebRTC agent can be packaged with the
      required PCP tuning parameters (e.g., identity of PCP server(s),
      explicit activation of PCP service, etc.).</t>

      <t>The following procedure depicts the typical generic steps to be
      followed by a WebRTC agent:</t>

      <t><list style="symbols">
          <t>To detect whether PCP service is available, the WebRTC client
          proceeds to the following on its bootstrapping:<list style="symbols">
              <t>Check if PCP service is explicitly enabled. This can be made
              available by setting a dedicated configuration parameter or
              accessing to a dedicated environment variable.</t>

              <t>If the PCP Server is explicitly configured, the WebRTC will
              use that server to install PCP mappings whenever needed.</t>

              <t>If the PCP service is explicitly disabled, PCP must not be
              used to install mappings.</t>

              <t>If the PCP service is not explicitly disabled or it is
              explicitly enabled but no PCP server is provisioned, the WebRTC
              must initiate a procedure to discover its PCP server(s):<list
                  style="symbols">
                  <t>This can be achieved by sending a MAP request to discover
                  the external IP address (see Section 11.6 of <xref
                  target="RFC6887"></xref>). This request is first sent to the
                  default router and then to the PCP IP anycast address in
                  case of failure.</t>

                  <t>If no answer is received, the WebRTC agent concludes no
                  PCP server is available.</t>

                  <t>If an answer is received, the WebRTC stores the identity
                  of discovered PCP server(s).</t>
                </list></t>

              <t>If a PCP server is detected on a network, the WebRTC agent
              caches this information in a dedicated parameter called
              STALE_PCP_SERVER. On reboot of WebRTC agent, the content of this
              variable will be used by the WebRTC agent to contact its PCP
              server when connected to the same network. If this variable is
              not set, the discovery procedure detailed in the above bullet
              must be followed.</t>
            </list></t>

          <t>Upon detection of a PCP Server, the WebRTC agent uses PCP to
          install a mapping for the signaling message. It may also prereserve
          a pair of ports to be used for media sessions.</t>

          <t>If the WebRTC is dual-stack, ALTC attribute <xref
          target="I-D.boucadair-mmusic-altc"></xref> is used to signal one
          IPv4 address and one IPv6 address.</t>
        </list></t>

      <t>Implementing a proof of concept of this procedure is ongoing.
      Experiment results will be published once available.</t>
    </section>
-->

    <section anchor="security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6887"></xref>
      are to be taken into account. PCP authentication <xref
      target="I-D.ietf-pcp-authentication"></xref> MAY also be used.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section title="Acknowledgments">
      <t>The authors would like to thank Charles Eckel for review and
      comments.</t>
    </section>
  </middle>

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

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

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

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

      <?rfc include='reference.I-D.ietf-pcp-proxy'?>

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

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

      <?rfc include='reference.I-D.ietf-pcp-authentication'?>

      <?rfc include='reference.I-D.ietf-rtcweb-rtp-usage'?>

      <?rfc ?>
    </references>

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

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

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

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

      <?rfc include='reference.I-D.ietf-rtcweb-use-cases-and-requirements'?>

      <?rfc include='reference.I-D.ietf-pcp-port-set'?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>

      <?rfc include='reference.I-D.wing-mmusic-ice-mobility'
?>

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

      <?rfc include='reference.I-D.reddy-rtcweb-mobile'?>

      <?rfc include='reference.I-D.reddy-pcp-optimize-keepalives'?>

      <?rfc include='reference.I-D.boucadair-pcp-nat64-experiments'?>

      <?rfc include='reference.I-D.boucadair-mmusic-altc'?>

      <?rfc include='reference.I-D.ietf-pcp-nat64-prefix64'
?>

      <?rfc include='reference.I-D.zuniga-dmm-gap-analysis'
?>

      <?rfc include='reference.I-D.hutton-rtcweb-nat-firewall-considerations'
?>

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

      <?rfc include='reference.I-D.cbran-rtcweb-nat' ?>

      <?rfc include='reference.I-D.ietf-behave-nat64-discovery-heuristic'?>

      <?rfc include='reference.I-D.ietf-behave-nat64-learn-analysis'?>

      <reference anchor="TS23.060" target="">
        <front>
          <title>"General Packet Radio Service (GPRS); Service description;
          Stage 2", June 2012.</title>

          <author fullname="3GPP" surname="3GPP">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <reference anchor="TS23.401" target="">
        <front>
          <title>General Packet Radio Service (GPRS) enhancements for Evolved
          Universal Terrestrial Radio Access Network (E- UTRAN) access
          (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 06).</title>

          <author fullname="3GPP" surname="3GPP">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <reference anchor="TR33.830" target="">
        <front>
          <title>3rd Generation Partnership Project; Technical Specification
          Group Services and System Aspects; Feasibility study on IMS firewall
          traversal (Release 12).</title>

          <author fullname="3GPP" surname="3GPP">
            <organization></organization>
          </author>

          <date day="0" month="September" year="2012" />
        </front>
      </reference>

      <!---->
    </references>
  </back>
</rfc>
