<?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="info" docName="draft-boucadair-pcp-failure-06"
     ipr="trust200902">
  <front>
    <title abbrev="PCP Failure Scenarios">Analysis of Port Control Protocol
    (PCP) Failure Scenarios</title>

    <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>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization>Cisco</organization>

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

          <code></code>

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

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

    <date day="16" month="May" year="2013" />

    <workgroup>PCP Working Group</workgroup>

    <keyword>reliability, failure, state synchronization, state recovery,
    stale mapping</keyword>

    <abstract>
      <t>This document identifies and analyzes several PCP failure scenarios.
      Identifying these failure scenarios is useful to assess the efficiency
      of the protocol and also to decide whether new PCP extensions are
      needed.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document discusses several failure scenarios that may occur when
      deploying PCP <xref target="RFC6887"></xref>.</t>
    </section>

    <section title="PCP Client Failure Scenarios">
      <t></t>

      <section title="Change of the IP Address of The PCP Server">
        <t>When a new IP address is used to reach its PCP Server, the PCP
        Client must re-create all of its explicit dynamic mappings using the
        newly discovered IP address.</t>

        <t>The PCP Client must undertake the same process as per refreshing an
        existing explicit dynamic mapping (see <xref
        target="RFC6887"></xref>); the only difference is the PCP requests are
        sent to a distinct IP address. No specific behavior is required from
        the PCP Server for handling these requests.</t>

        <t><list style="empty">
            <t>Proposed Action: No particular extension is required to be
            added to the base specification to mitigate this failure
            scenario.</t>
          </list></t>
      </section>

      <section title="Application Crash">
        <t>When a fatal error is encountered by an application relying on PCP
        to open explicit dynamic mappings on an upstream device, and upon the
        restart of that application, the PCP Client should issue appropriate
        requests to refresh the explicit dynamic mappings of that application
        (e.g., clear old mappings and install new ones using the new port
        number used by the application).</t>

        <t>If the same port number is used but a distinct Mapping Nonce is
        generated, the request will be rejected with a NOT_AUTHORIZED error
        with the Lifetime of the error indicating duration of that existing
        mapping (see Section 2.7 of <xref
        target="I-D.boucadair-pcp-flow-examples"></xref>).</t>

        <t><list style="empty">
            <t>Proposed Action: A solution to recover the Mapping Nonce used
            when instantiating the mapping may be envisaged; this solution may
            not be viable if PCP authentication is not in use. Mapping Nonce
            recovery in the simple PCP threat model (especially when Mapping
            Check validation is enabled) induces the same security threated as
            those discussed in <xref target="RFC6887"></xref>.</t>
          </list>If a distinct port number is used by the application to bound
        its service (i.e., a new internal port number is to be signaled in
        PCP), the PCP Server may honor the refresh requests if the
        per-subscriber quota is not exceeded. A distinct external port number
        would be assigned by the PCP Server due to the presence of "stale"
        explicit dynamic mapping(s) associated with the "old" port number.</t>

        <t><list style="empty">
            <t>Proposed Action: To avoid this inconvenience induced by stale
            explicit dynamic mappings, the PCP Client may clear the "old"
            mappings before issuing the refresh requests; but this would
            require the PCP Client to store the information about the "old"
            port number. This can be easy to solve if the PCP Client is
            embedded in the application. In some scenarios, this is not so
            easy because the PCP Client may handle PCP requests on behalf of
            several applications and no means to identify the requesting
            application may be supported. Means to identify the application
            may be envisaged.</t>

            <t><xref target="RFC6887"></xref> does not allow a PCP Client to
            issue a request to delete all the explicit dynamic mappings
            associated with an internal IP address. If a PCP Client is allowed
            to clear all mappings bound to the same IP address, this would
            have negative impact on other applications and PCP Client(s) which
            may use the same internal IP address to instruct their explicit
            dynamic mappings in the PCP Server.</t>
          </list></t>
      </section>

      <section title="PCP Client Crash">
        <t>The PCP Client may encounter a fatal error leading to its restart.
        In such case, the internal IP address and port numbers used by
        requesting applications are not impacted. Therefore, the explicit
        dynamic mappings as maintained by the PCP Server are accurate and
        there is no need to refresh them.</t>

        <t>On the PCP Client side, a new UDP port should be assigned to issue
        PCP requests. As a consequence, if outstanding requests have been sent
        to the PCP Server, the responses are likely to be lost.</t>

        <t>If the PCP Client stores its explicit dynamic mappings in a
        persistent memory, there is no need to retrieve the list of active
        mappings from the PCP Server.</t>

        <t><list style="empty">
            <t>Proposed Action: If several PCP Clients are co-located on the
            same host, related PCP mapping tables should be uniquely
            distinguished (e.g., a PCP Client does not delete explicit dynamic
            mappings instructed by another PCP Client).</t>
          </list>If the PCP Client does not store the explicit dynamic
        mappings and new Mapping Nonces are assigned, the PCP Server will
        reject to refresh these mappings.<list style="empty">
            <t>Proposed Action: This issue can be solved if the PCP Client
            uses GET OpCode (<xref target="get"></xref>) to recover the
            mapping nonces used when instantiating the mappings if PCP
            authentication is used or Mapping Nonce validation check is
            disabled.</t>
          </list></t>

        <t></t>
      </section>

      <section anchor="change_internal_ip_address"
               title="Change of the Internal IP Address">
        <t>When a new IP address is assigned to a host embedding a PCP Client,
        the PCP Client must install on the PCP Server all the explicit dynamic
        mappings it manages, using the new assigned IP address as the internal
        IP address. The hinted external port number won't be assigned by the
        PCP Server since a "stale" mapping is already instantiated by the PCP
        Server (but it is associated with a distinct internal IP address).</t>

        <t>For a host configured with several addresses, the PCP Client must
        maintain a record about the target IP address it used when issuing its
        PCP requests. If no record is maintained and upon a change of the IP
        address or de-activation of an interface, the PCP-instructed explicit
        dynamic mappings are broken and inbound communications will fail to be
        delivered.</t>

        <t>Depending on the configured policies, the PCP Server may honor all
        or part of the requests received from the PCP Client. Upon receipt of
        the response from the PCP Server, the PCP Client must update its local
        PCP state with the new assigned port numbers and external IP
        address.</t>

        <t><list style="empty">
            <t>Proposed Action: Because of the possible negative impact if the
            quota is exceed due to the presence of stale mappings (see the
            example in Section 2.14 of <xref
            target="I-D.boucadair-pcp-flow-examples"></xref>), a procedure to
            clear stale mappings may have some benefits.</t>
          </list>A PCP Client may be used to manage explicit dynamic mappings
        on behalf of a third party (i.e., the PCP Client and the third party
        are not co-located on the same host). If a new internal IP address is
        assigned to that third party (e.g., webcam), the PCP Client should be
        instructed to delete the old mapping(s) and create new one(s) using
        the new assigned internal IP address. When the PCP Client is
        co-located with the DHCP server (e.g., PCP Proxy <xref
        target="I-D.ietf-pcp-proxy"></xref>, IWF in the CP router <xref
        target="I-D.ietf-pcp-upnp-igd-interworking"></xref>), the state can be
        updated using the state of the local DHCP server. Otherwise, it is
        safe to recommend the use of static internal IP addresses if PCP is
        used to configure third-party explicit dynamic mappings.<list
            style="empty">
            <t>Proposed Action: No particular extension is required to be
            added to the base specification to mitigate this failure
            scenario.</t>
          </list></t>

        <t></t>
      </section>

      <section title="Change of the CPE WAN IP Address">
        <t>The change of the IP address of the WAN interface of the CPE would
        have an impact on the accuracy of the explicit dynamic mappings
        instantiated in the PCP Server:</t>

        <t><list style="symbols">
            <t>For the DS-Lite case <xref target="RFC6333"></xref>: if a new
            IPv6 address is used by the B4 element when encapsulating IPv4
            packets in IPv6 ones, the explicit dynamic mappings should be
            refreshed: If the PCP Client is embedded in the B4, the refresh
            operation is triggered by the change of the B4 IPv6 address. This
            would be more complicated when the PCP Client is located in a
            device behind the B4. If a PCP Proxy is embedded in the CPE, the
            proxy can use ANNOUNCE OpCode towards internal IPv4 hosts behind
            the DS-Lite CPE.</t>

            <t>For the NAT64 case <xref target="RFC6146"></xref>, any change
            of the assigned IPv6 prefix delegated to the CPE will be detected
            by the PCP Client (because this leads to the allocation of a new
            IPv6 address). The PCP Client has to undertake the operation
            described in <xref
            target="change_internal_ip_address"></xref>.</t>

            <t>For the NAT444 case, similar problems are encountered because
            the PCP Client has no reasonable way to detect the CPE's WAN
            address changed.</t>
          </list></t>

        <t><list style="empty">
            <t>Proposed Action: Means to help detecting the CPE's WAN address
            change would help in mitigating this failure scenario.</t>
          </list></t>
      </section>

      <section title="UPnP IGD/PCP IWF">
        <t>In the event an UPnP IGD/PCP IWF <xref
        target="I-D.ietf-pcp-upnp-igd-interworking"></xref> fails to renew a
        mapping, there is no mechanism to inform the UPnP Control Point about
        this failure.</t>

        <t><list style="empty">
            <t>Proposed Action: This issue can not be solved.</t>
          </list></t>

        <t>On the reboot of the IWF, if no mapping table is maintained in a
        permanent storage, "stale" mappings will be maintained by the PCP
        Server and per-user quota will be consumed. This is even exacerbated
        if new mapping nonces are assigned by the IWF. <list style="empty">
            <t>Proposed Action: This issue can be soften by synchronizing the
            mapping table owing to the invocation of the GET OpCode defined in
            <xref target="get"></xref>. This procedure is supported only if
            Mapping Nonce validation checks are disabled.</t>
          </list></t>

        <t></t>
      </section>
    </section>

    <section title="Restart or Failure of the PCP Server">
      <t>This section covers failure scenarios encountered by the PCP
      Server.</t>

      <section title="Basic Rule">
        <t>In any situation the PCP Server loses all or part of its PCP state,
        the Epoch value must be reset when replying to received requests.
        Doing so would allow PCP Client to audit its explicit dynamic mapping
        table.</t>

        <t>If the state is not lost, the PCP Server must not reset the Epoch
        value returned to requesting PCP Clients.</t>

        <t><list style="empty">
            <t>Proposed Action: No action is required to update the base PCP
            specification for this failure scenario.</t>
          </list></t>
      </section>

      <section title="Clear PCP Mappings">
        <t>When a command line or a configuration change is enforced to clear
        all or a subset of PCP explicit dynamic mappings maintained by the PCP
        Server, the PCP Server must reset its Epoch to zero value.</t>

        <t>In order to avoid all PCP Clients to update their explicit dynamic
        mappings, the PCP Server should reset the Epoch to zero value only for
        impacted users.</t>

        <t><list style="empty">
            <t>Proposed Action: No action is required to update the base PCP
            specification for this failure scenario.</t>
          </list></t>
      </section>

      <section title="State Redundancy is Enabled">
        <t>When state redundancy is enabled, the state is not lost during
        failure events. Failures are therefore transparent to requesting PCP
        Clients. When a backup device takes over, Epoch must not be reset to
        zero.</t>

        <t><list style="empty">
            <t>Proposed Action: No action is required to update the base PCP
            specification for this failure scenario.</t>
          </list></t>
      </section>

      <section title="Cold-Standby without State Redundancy">
        <t>In this section we assume that a redundancy mechanisms is
        configured between a primary PCP-controlled device and a backup one
        but without activating any state synchronization for the
        PCP-instructed explicit dynamic mappings between the backup and the
        primary devices.</t>

        <t>If the primary PCP-controlled device fails and the backup one takes
        over, the PCP Server must reset the Epoch to zero value. Doing so
        would allow PCP Clients to detect the loss of states in the PCP Server
        and proceed to state synchronization.</t>

        <t><list style="empty">
            <t>Proposed Action: No action is required to update the base PCP
            specification for this failure scenario.</t>
          </list></t>
      </section>

      <section title="Anycast Redundancy Mode">
        <t>When an anycast-based mode is deployed (i.e., the same IP address
        is used to reach several PCP Servers) for redundancy reasons, the
        change of the PCP Server which handles the requests of a given PCP
        Client won't be detected by that PCP Client.</t>

        <t>Tweaking the Epoch (Section 8.5 of <xref target="RFC6887"></xref>)
        may help to detect the loss of state and therefore to re-create
        missing explicit dynamic mappings.</t>

        <t><list style="empty">
            <t>Proposed Action: No action is required to update the base PCP
            specification for this failure scenario.</t>
          </list></t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>PCP-related security consideratiosn are discussed in <xref
      target="RFC6887"></xref>.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>No action is required from IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Francis Dupont contributed text to this document. Many thanks to
      him.</t>
    </section>
  </middle>

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

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

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

      <?rfc include='reference.I-D.ietf-pcp-upnp-igd-interworking'?>
    </references>

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

      <?rfc include='reference.I-D.boucadair-pcp-flow-examples'?>

      <?rfc include='reference.RFC.6146'?>
    </references>

    <section title="PCP State Synchronization: Overview">
      <t>The following sketches the state synchronization logic:</t>

      <t><list style="symbols">
          <t>One element (i.e., PCP Client/host/application, PCP Server, PCP
          Proxy, PCP IWF) of the chain is REQUIRED to use stable storage</t>

          <t>If the PCP Client (resp., the PCP Server) crashes and restarts it
          just have to synchronize with the PCP Server (resp., the PCP
          Client);</t>

          <t>If both crash then one has to use stable storage and we fall back
          in the previous case as soon as we know which one (the Epoch value
          gives this information);</t>

          <t>PCP Server -&gt; PCP Client not-disruptive synchronization
          requires a GET/NEXT mechanism to retrieve the state from the PCP
          Server; without this mechanism the only way to put the PCP Server in
          a known state is for the PCP Client to send a delete all request, a
          clearly disruptive operation.</t>

          <t>PCP Client -&gt; PCP Server synchronization is done by a
          re-create or refresh of the state. The PCP Client MAY retrieve the
          PCP Server state in order to prevent stale explicit dynamic
          mappings.</t>
        </list></t>
    </section>

    <section anchor="get" title="GET/NEXT Operation">
      <t>This section defines a new PCP OpCode called GET and its associated
      Option NEXT.</t>

      <t>These PCP Opcode and Option are used by the PCP Client to retrieve an
      explicit mapping or to walk through the explicit dynamic mapping table
      maintained by the PCP Server for this subscriber and retrieves a list of
      explicit dynamic mapping entries it instantiated.</t>

      <t>GET can also be used by a NoC to retrieve the list of mappings for a
      given subscriber.</t>

      <section title="OpCode Format">
        <t>The GET OpCode payload contains a Filter used for explicit dynamic
        mapping matching: only the explicit dynamic mappings of the subscriber
        which match the Filter in a request are considered so could be
        returned in response.<list style="empty">
            <t>Implementation Note: Some existing implementations use 98
            (0x62) codepoint for GET OpCode, 131 for AMBIGUOUS error code, and
            131 (0x83) for NEXT Option.</t>
          </list></t>

        <t>The layout of GET OpCode is shown in <xref
        target="GET"></xref>.</t>

        <t><figure anchor="GET" title="GET: OpCode format">
            <artwork><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Protocol    |                Reserved                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    :   Filter internal IP address (always 128 bits)                :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    :   Filter external IP address (always 128 bits)                :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Filter internal port        |   Filter external port        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure></t>

        <t>For all fields, the value 0 in a request means wildcard filter/any
        value matches. Of course this has to be sound: no defined port with
        protocol set to any.</t>

        <t>These fields are described below: <list style="hanging">
            <t hangText="Protocol:">Same than for MAP <xref
            target="RFC6887"></xref>.</t>

            <t hangText="Reserved:">MUST be sent as 0 and MUST be ignored when
            received.</t>

            <t hangText="Filter internal IP address:">Conveys the internal IP
            address (including an unspecified IPv4IPv6 address). The encoding
            of this field follows Section 5 of <xref
            target="RFC6887"></xref>.</t>

            <t hangText="Filter external IP address:">Conveys the external IP
            address (including an unspecified IPv4IPv6 address). The encoding
            of this field follows Section 5 of <xref
            target="RFC6887"></xref>.</t>

            <t hangText="Filter internal port:">The internal port (including
            0).</t>

            <t hangText="Filter external port:">The external port (including
            0).</t>
          </list></t>

        <t>Responses include a bit-to-bit copy of the OpCode found in the
        request.</t>
      </section>

      <section title="OpCode-Specific Result Code">
        <t>This OpCode defines two new specific Result Code <list
            style="hanging">
            <t hangText="TBD:">NONEXIST_MAP, e.g., no explicit dynamic mapping
            matching the Filter was found.</t>

            <t hangText="TBD:">AMBIGUOUS. This code is returned when the PCP
            Server is not able to decide which mapping to return. Existing
            implementations use 131 as codepoint.</t>
          </list></t>
      </section>

      <section anchor="order" title="Ordering and Equality">
        <t>The PCP server is required to implement an order between matching
        explicit dynamic mappings. The only property of this order is to be
        stable: it doesn't change (*) between two GET requests with the same
        Filter.</t>

        <t>(*) "change" means two mappings are not gratuitously swapped:
        expiration, renewal or creation are authorized to change the order but
        they are at least expected by the PCP client. <list style="empty">
            <t>[Ed. Note: We have two proposals for the order: lexicographical
            order and lifetime order. Both work, this should be left to the
            implementor.]</t>
          </list></t>

        <?rfc subcompact="yes"?>

        <t>Equality is defined by: <list style="symbols">
            <t>same protocol and;</t>

            <t>same internal address and;</t>

            <t>same external address and;</t>

            <t>same internal port and;</t>

            <t>same external port.</t>
          </list></t>

        <?rfc subcompact="no"?>
      </section>

      <section title="NEXT Option">
        <t>Formal definition: <list style="hanging">
            <t hangText="Name:">NEXT</t>

            <t hangText="Number:">at most one in requests, any in
            responses.</t>

            <t hangText="Purpose:">carries a Locator in requests, matching
            explicit dynamic mappings greater than the Locator in
            responses.</t>

            <t hangText="Is valid for OpCodes:">GET OpCode.</t>

            <t hangText="Length:">variable, the minimum is 11.</t>

            <t hangText="May appear in:">both requests and responses.</t>

            <t hangText="Maximum occurrences:">one for requests, bounded by
            maximum message size for PCP responses <xref
            target="RFC6887"></xref>.</t>
          </list></t>

        <t>The layout of the NEXT Option is shown in <xref
        target="NEXT"></xref>.</t>

        <t><figure anchor="NEXT" title="NEXT: Option format">
            <artwork><![CDATA[Version=1
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Protocol    |          Reserved             |  MORE/END     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    :   Mapping internal IP address (always 128 bits)               :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    :   Mapping external IP address (always 128 bits)               :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Mapping remaining lifetime                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Mapping internal port       |   Mapping external port       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       Mapping Options                         :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version=2

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                 Mapping Nonce (96 bits)                       :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Protocol    |          Reserved             |  MORE/END     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :   Mapping internal IP address (always 128 bits)               :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :   Mapping external IP address (always 128 bits)               :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Mapping remaining lifetime                                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Mapping internal port       |   Mapping external port       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Mapping Options                         :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
          </figure></t>

        <t>In requests the NEXT Option carries a Locator: a position in the
        list of explicit dynamic mappings which match the Filter. The
        following two useful forms of Locators are considered: <list
            style="symbols">
            <t>the "Undefined" form where the Protocol, Addresses, Ports
            fields are set to zero.</t>

            <t>the "Defined" form where none of the Protocol, Addresses and
            Ports is set to zero.</t>
          </list></t>

        <t>The new fields in a Locator (a.k.a., the NEXT Option in a GET
        request) are described below: <list style="hanging">
            <t hangText="MORE/END:">The value 0 denotes "MORE" and means the
            response MAY include multiple NEXT Options; a value other than 0
            (1 is RECOMMENDED) denotes "END" and means the response SHALL
            include at most one NEXT Option.</t>

            <t hangText="Mapping remaining lifetime:">MUST be sent as 0 and
            MUST be ignored when received.</t>

            <t hangText="Mapping Options:">The Option Codes of the PCP Client
            wants to get in the response (e.g., THIRD_PARTY). The format is
            the same than for the UNPROCESSED Option (see rev 17 of<xref
            target="RFC6887"></xref>).</t>
          </list></t>

        <t>In responses the NEXT Options carry the returned explicit dynamic
        mappings, one per NEXT Option. The fields are described below: <list
            style="hanging">
            <t hangText="Protocol:">The protocol of the returned mapping.</t>

            <t hangText="MORE/END:">The value 0 when there are explicit
            dynamic mapping matching the Filter and greater than this returned
            mapping; a value other than 0 (1 is RECOMMENDED) when the return
            mapping is the greatest explicit dynamic mapping matching the
            Filter.</t>

            <t hangText="Mapping internal IP address:">the internal address of
            the returned mapping. The encoding of this field follows Section 5
            of <xref target="RFC6887"></xref>.</t>

            <t hangText="Mapping external IP address:">the external address of
            the returned mapping. The encoding of this field follows Section 5
            of <xref target="RFC6887"></xref>.</t>

            <t hangText="Mapping remaining lifetime:">The remaining lifetime
            in seconds of the returned mapping.</t>

            <t hangText="Mapping internal port:">the internal port of the
            returned mapping.</t>

            <t hangText="Mapping external port:">the external port of the
            returned mapping.</t>

            <t hangText="Mapping Options:">An embedded list of option values.
            Each corresponding Option Code MUST be present in the request NEXT
            Option, each option MUST be related to the returned mapping or not
            related to any mapping.</t>
          </list></t>
      </section>

      <section title="GET/NEXT PCP Client Theory of Operation">
        <t>GET requests without a NEXT Option have low usage but with a full
        wildcard Filter they ask the PCP Server to know if it has at least one
        explicit dynamic mapping for this subscriber.</t>

        <t>GET requests with an END NEXT Option are "pure" GET: they asks for
        the status and/or the remaining lifetime or options of a specific
        explicit dynamic mapping. It is recommended to use an Undefined
        Locator and to use the Filter to identify the mapping.</t>

        <t>GET requests with a MORE NEXT Option are for the whole explicit
        dynamic mapping table retrieval from the PCP Server. The initial
        request contains an Undefined Locator, other requests a Defined
        Locator filled by a copy of the last returned mapping with the
        Lifetime and Option fields reseted to the original values. An END NEXT
        Option marks the end of the retrieval.</t>
      </section>

      <section title="GET/NEXT PCP Server Theory of Operation">
        <t>The PCP Server behavior is described below: <list style="symbols">
            <t>on the reception of a valid GET request the ordered list of
            explicit dynamic mapping of the subscriber matching the given
            Filter is (conceptually) built.</t>

            <t>if the list is empty a NONEXIST_MAP error response is returned.
            It includes no NEXT Option.</t>

            <t>the list is scanned to find the Locator using the Equality
            defined in <xref target="order"></xref>. If it is found the
            mappings less than the Locator are removed from the list, so the
            result is a list which begins by the mapping equals to the Locator
            followed by greater mappings.</t>

            <t>if the NEXT Option in the request is an END one, the first
            mapping of the list is returned in an only NEXT option, marked END
            if the list contains only this mapping, marked MORE otherwise.</t>

            <t>if the NEXT option in the request is a MORE one, as many as can
            fit mappings are returned in order in the response, marked as MORE
            but if the whole list can be returned the last is marked END.</t>
          </list>"Returned" means to include required options when they are
        defined for a mapping: if the mapping M has 3 REMOTE_PEER_FILTERs and
        the REMOTE_PEER_FILTER code was in the request NEXT, the NEXT carrying
        M will get the 3 REMOTE_PEER_FILTER options embedded.</t>
      </section>

      <section title="Flow Examples">
        <t>As an illustration example, let's consider the following explicit
        dynamic mapping table is maintained by the PCP Server:</t>

        <texttable align="center" anchor="mapping_table" style="full"
                   title="Excerpt of a mapping table">
          <ttcol align="center">Pro</ttcol>

          <ttcol align="center">Internal IP Address</ttcol>

          <ttcol align="center">Internal Port</ttcol>

          <ttcol align="center">External IP Address</ttcol>

          <ttcol align="center">External Port</ttcol>

          <ttcol align="center">Remaining Lifetime</ttcol>

          <c>UDP</c>

          <c>198.51.100.1</c>

          <c>25655</c>

          <c>192.0.2.1</c>

          <c>15659</c>

          <c>1659</c>

          <c>TCP</c>

          <c>198.51.100.2</c>

          <c>12354</c>

          <c>192.0.2.1</c>

          <c>32654</c>

          <c>3600</c>

          <c>TCP</c>

          <c>198.51.100.2</c>

          <c>8596</c>

          <c>192.0.2.1</c>

          <c>25659</c>

          <c>6000</c>

          <c>UDP</c>

          <c>198.51.100.1</c>

          <c>19856</c>

          <c>192.0.2.1</c>

          <c>42654</c>

          <c>7200</c>

          <c>TCP</c>

          <c>198.51.100.1</c>

          <c>15775</c>

          <c>192.0.2.1</c>

          <c>32652</c>

          <c>9000</c>
        </texttable>

        <t></t>

        <t>As shown in <xref target="mapping_table"></xref>, the PCP Server
        sorts the explicit dynamic mapping table using the internal IP address
        and the remaining lifetime.</t>

        <t><xref target="single_mapping_failed"></xref> illustrates the
        exchange that occurs when a PCP Client tries to retrieve the
        information related to a non-existing explicit dynamic mapping.</t>

        <t><figure align="center" anchor="single_mapping_failed"
            title="Example of a failed GET operation">
            <artwork><![CDATA[
        +------+                           +------+
        | PCP  |                           | PCP  |
        |Client|                           |Server|
        +------+                           +------+
           |       (1) PCP GET Request         |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 59864       |
           |         Undefined Locator         |
           |---------------------------------->|
           |                                   |
           |        (2) PCP GET Response       |
           |       error= NONEXIST_MAP         |
           |<----------------------------------|
           |                                   |

]]></artwork>
          </figure></t>

        <t><xref target="single_mapping_success"></xref> shows an example of a
        PCP Client which retrieves successfully an existing mapping from the
        PCP Server.</t>

        <t><figure align="center" anchor="single_mapping_success"
            title="Example of a successful GET operation">
            <artwork><![CDATA[
        +------+                           +------+
        | PCP  |                           | PCP  |
        |Client|                           |Server|
        +------+                           +------+
           |       (1) PCP GET Request         |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 25655       |
           |         Undefined Locator         |
           |---------------------------------->|
           |                                   |
           |      (2) PCP GET Response         |
           |             END                   |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 25655       |
           |   external-ip-address= 192.0.2.1  |
           |        external-port= 15659       |
           |       remaining-lifetime= 1659    |
           |<----------------------------------|
           |                                   |
           |      (3) PCP MAP4 Request         |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 25655       |
           |   external-ip-address= 192.0.2.1  |
           |        external-port= 15659       |
           |       requested-lifetime= 0       |
           |---------------------------------->| 
           |                                   |
]]></artwork>
          </figure></t>

        <t>In reference to <xref target="example"></xref>, the PCP Server
        returns the explicit dynamic mappings having the internal address
        equal to 192.0.2.1 ordered by increasing remaining lifetime.</t>

        <t><figure align="center" anchor="example"
            title="Flow example of GET/NEXT">
            <artwork><![CDATA[
        +------+                           +------+
        | PCP  |                           | PCP  |
        |Client|                           |Server|
        +------+                           +------+
           |       (1) PCP GET Request         |
           | internal-ip-address= 198.51.100.2 |
           |         Undefined Locator         |
           |---------------------------------->|
           |                                   |
           |       (2) PCP GET Response        |
           |               MORE                |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.2 |
           |        internal-port= 12354       |
           |   external-ip-address= 192.0.2.1  |
           |        external-port= 32654       |
           |       remaining-lifetime= 3600    |
           |               END                 |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.2 |
           |        internal-port= 8596        |
           |   external-ip-address= 192.0.2.1  |
           |        external-port= 25659       |
           |       remaining-lifetime= 6000    |
           |<----------------------------------|
           |                                   |
]]></artwork>
          </figure></t>

        <t>In reference to <xref target="example_2"></xref>, the PCP Server
        returns the explicit dynamic mappings having the internal address
        equal to 192.0.2.2 ordered by increasing remaining lifetime. In this
        example, the same internal port is used for TCP and UDP.</t>

        <t><figure align="center" anchor="example_2"
            title="Flow example of GET/NEXT: same internal port number">
            <artwork><![CDATA[
        +------+                           +------+
        | PCP  |                           | PCP  |
        |Client|                           |Server|
        +------+                           +------+
           |       (1) PCP GET Request         |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 25655       |
           |         Undefined Locator         |
           |---------------------------------->|
           |                                   |
           |       (2) PCP GET Response        |
           |               MORE                |
           |           protocol= UDP           |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 25655       |
           |   external-ip-address= 192.0.2.1  |
           |        external-port= 15659       |
           |       remaining-lifetime= 1659    |
           |                END                |
           |           protocol= TCP           |
           | internal-ip-address= 198.51.100.1 |
           |        internal-port= 25655       |
           |   external-ip-address= 192.0.2.1  |
           |        external-port= 32652       |
           |       remaining-lifetime= 9000    |
           |<----------------------------------|
           |                                   |
]]></artwork>
          </figure></t>
      </section>
    </section>
  </back>
</rfc>
