<?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-ietf-pcp-base-29" ipr="trust200902">
  <front>
    <title abbrev="Port Control Protocol (PCP)">Port Control Protocol
    (PCP)</title>

    <author fullname="Dan Wing" initials="D." role="editor" 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="Stuart Cheshire" initials="S." surname="Cheshire">
      <organization abbrev="Apple">Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino</city>
          <region>California</region>
          <code>95014</code>
          <country>USA</country>
        </postal>
        <phone>+1 408 974 3207</phone>
        <email>cheshire@apple.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>

    <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>California</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <email>repenno@cisco.com</email>
      </address>
    </author>

    <author fullname="Paul Selkirk" initials="P." surname="Selkirk">
      <organization abbrev="ISC">Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>California</region>
          <code>94063</code>
          <country>USA</country>
        </postal>
        <email>pselkirk@isc.org</email>
      </address>
    </author>

    <date />

    <workgroup>PCP working group</workgroup>

    <abstract>
      <t>The Port Control Protocol allows an IPv6 or IPv4 host to control how
      incoming IPv6 or IPv4 packets are translated and forwarded by a network
      address translator (NAT) or simple firewall, and also allows a host to
      optimize its outgoing NAT keepalive messages.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The Port Control Protocol (PCP) provides a mechanism to
      control how incoming packets are forwarded by upstream devices
      such as Network Address Translator IPv6/IPv4 (NAT64), Network
      Address Translator IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall
      devices, and a mechanism to reduce application keepalive
      traffic. PCP is designed to be implemented in the context of
      Carrier-Grade NATs (CGNs), small NATs (e.g., residential NATs),
      as well as with dual-stack and IPv6-only Customer Premises
      Equipment (CPE) routers, and all of the currently-known
      transition scenarios towards IPv6-only CPE routers.  PCP allows
      hosts to operate servers for a long time
      (e.g., a network-attached home security camera) or a
      short time (e.g., while playing a game or on a phone call) when
      behind a NAT device, including when behind a CGN operated by
      their Internet service provider or an IPv6 firewall integrated
      in their CPE router.</t>

      <t>PCP allows applications to create mappings from an external
      IP address, protocol, and port to an internal IP address,
      protocol, and port. These mappings are required for successful
      inbound communications destined to machines located behind a NAT
      or a firewall.</t>

      <t>After creating a mapping for incoming connections, it is necessary to
      inform remote computers about the IP address, protocol, and port for the incoming
      connection. This is usually done in an application-specific manner. For
      example, a computer game might use a rendezvous server specific to that
      game (or specific to that game developer), a SIP phone would use a SIP
      proxy, and a client using DNS-Based Service Discovery
      <xref target="I-D.cheshire-dnsext-dns-sd"></xref> would use DNS Update
      <xref target="RFC2136"></xref> <xref target="RFC3007"></xref>. PCP does not
      provide this rendezvous function. The rendezvous function may support
      IPv4, IPv6, or both. Depending on that support and the application's
      support of IPv4 or IPv6, the PCP client may need an IPv4 mapping, an
      IPv6 mapping, or both.</t>

      <t>Many NAT-friendly applications send frequent application-level
      messages to ensure their session will not be timed out by a NAT. These
      are commonly called "NAT keepalive" messages, even though they are not
      sent to the NAT itself (rather, they are sent 'through' the NAT). These
      applications can reduce the frequency of such NAT keepalive messages by
      using PCP to learn (and influence) the NAT mapping lifetime. This helps
      reduce bandwidth on the subscriber's access network, traffic to the
      server, and battery consumption on mobile devices.</t>

      <t>Many NATs and firewalls include Application Layer Gateways
      (ALGs) to create mappings for applications that establish additional
      streams or accept incoming connections. ALGs incorporated into NATs may
      also modify the application payload. Industry experience has shown that
      these ALGs are detrimental to protocol evolution. PCP allows an
      application to create its own mappings in NATs and firewalls, reducing
      the incentive to deploy ALGs in NATs and firewalls.</t>
    </section>

    <section title="Scope">
      <section title="Deployment Scenarios">
        <t>PCP can be used in various deployment scenarios, including:<list
            style="symbols">
            <t><xref target="RFC3022">Basic NAT</xref></t>

            <t><xref target="RFC3022">Network Address and Port
            Translation</xref>, such as commonly deployed in residential NAT
            devices</t>

            <t><xref target="I-D.ietf-behave-lsn-requirements">Carrier-Grade
            NAT</xref></t>

            <t><xref target="RFC6333">Dual-Stack Lite (DS-Lite)</xref></t>

            <t><xref target="I-D.miles-behave-l2nat">Layer-2 Aware
            NAT</xref></t>

            <t><xref target="RFC6619">Dual-Stack Extra
            Lite</xref></t>

            <t>NAT64, both <xref target="RFC6145">Stateless</xref> and
            <xref target="RFC6146">Stateful</xref></t>

            <t>IPv4 and <xref target="RFC6092">IPv6 simple firewall
            control</xref></t>

            <t><xref target="RFC6296">IPv6-to-IPv6 Network Prefix Translation (NPTv6)</xref></t>

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

      <section title="Supported Protocols">
        <t>The PCP Opcodes defined in this document are designed to
        support transport-layer protocols that use a 16-bit port
        number (e.g., TCP, UDP, <xref target="RFC4960">SCTP</xref>, 
          <xref target="RFC4340">DCCP</xref>). Protocols that do not use
        a port number (e.g., RSVP, <xref target="RFC4303">IPsec ESP</xref>, ICMP, ICMPv6) are
        supported for IPv4 firewall, IPv6 firewall, and NPTv6
        functions, but are out of scope for any NAT functions.</t>
      </section>

      <section anchor="single_homed" title="Single-homed Customer Premises Network">
        <t>PCP assumes a single-homed IP address model. That is, for a given
        IP address of a host, only one default route exists to reach
        other hosts on the Internet from that source IP address.
        This is important because after a PCP mapping is created and
        an inbound packet (e.g., TCP SYN) is rewritten and delivered to a host,
        the outbound response (e.g., TCP SYNACK) has to go through the same
        (reverse) path so it passes through the same NAT to have the necessary
        inverse rewrite performed. This restriction exists
        because otherwise there would need to be a PCP-enabled NAT for every
        egress (because the host could not reliably determine which egress
        path packets would take) and the client would need to be able to
        reliably make the same internal/external mapping in every NAT gateway,
        which in general is not possible (because the other NATs might already have
        the necessary External Port mapped to another host).</t>
      </section>
    </section>

    <section anchor="terminology" title="Terminology">
      <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">"Key words for use in RFCs to Indicate Requirement
      Levels"</xref>.</t>

      <t><list style="hanging">
          <t hangText="Internal Host:"><vspace blankLines="0" />A host served
          by a NAT gateway, or protected by a firewall. This is the host 
          that will receive incoming traffic resulting from a PCP mapping request, or
          the host that initiated an implicit dynamic outbound mapping (e.g., by
          sending a TCP SYN) across a firewall or a NAT.</t>

          <t hangText="Remote Peer Host:"><vspace blankLines="0" />A
          host with which an Internal Host is communicating. This can
          include another Internal Host (or even the same Internal
          Host); if a NAT is involved, the NAT would need to hairpin
          the traffic <xref target="RFC4787"></xref>.</t>

          <t hangText="Internal Address:"><vspace blankLines="0" />The address
          of an Internal Host served by a NAT gateway or protected by a
          firewall.</t>

          <t hangText="External Address:"><vspace blankLines="0" />The address
          of an Internal Host as seen by other Remote Peers on the Internet
          with which the Internal Host is communicating, after translation by
          any NAT gateways on the path. An External Address is generally a
          public routable (i.e., non-private) address. In the case of an
          Internal Host protected by a pure firewall, with no address
          translation on the path, its External Address is the same as its
          Internal Address.</t>

          <t hangText="Endpoint-Dependent Mapping (EDM):">A term
          applied to NAT operation where an implicit mapping created
          by outgoing traffic (e.g., TCP SYN) from a single Internal
          Address, Protocol, and Port to different Remote Peers and Ports may be
          assigned different External Ports, and a subsequent PCP mapping
          request for that Internal Address, Protocol, and Port may be assigned
          yet another different External Port.  This term encompasses
          both Address-Dependent Mapping and Address and
          Port-Dependent Mapping <xref target="RFC4787"></xref>.</t>

          <t hangText="Endpoint-Independent Mapping (EIM):">A term applied to
          NAT operation where all mappings from a single Internal Address,
          Protocol, and Port to different Remote Peers and Ports are all
          assigned the same External Address and Port.</t>

          <t hangText="Remote Peer Address:"><vspace blankLines="0" />The
          address of a Remote Peer, as seen by the Internal Host. A Remote
          Address is generally a publicly routable address. In the case of a
          Remote Peer that is itself served by a NAT gateway, the Remote
          Address may in fact be the Remote Peer's External Address, but since
          this remote translation is generally invisible to software running
          on the Internal Host, the distinction can safely be ignored for the
          purposes of this document.</t>

          <t hangText="Third Party:"><vspace blankLines="0" />In the common
          case, an Internal Host manages its own Mappings using PCP requests,
          and the Internal Address of those Mappings is the same as the source
          IP address of the PCP request packet. <vspace blankLines="1" /> In
          the case where one device is managing Mappings on behalf of some
          other device that does not implement PCP, the presence of the
          THIRD_PARTY Option in the MAP request signifies that the specified
          address, rather than the source IP address of the PCP request packet, should
          be used as the Internal Address for the Mapping.</t>

          <t hangText="Mapping, Port Mapping, Port
          Forwarding:"><vspace blankLines="0" />A NAT mapping creates
          a relationship between an internal IP address, protocol, and
          port, and an external IP address, protocol, and port. More
          specifically, it creates a translation rule where packets
          destined to the external IP and port are translated to the
          internal IP address, protocol, and port, and vice versa. In
          the case of a pure firewall, the "Mapping" is the identity
          function, translating an internal IP address, protocol, and
          port number to the same external IP address, protocol, and port
          number. Firewall filtering, applied in addition to that
          identity mapping function, is separate from the mapping
          itself.</t>

          <t hangText="Mapping Types:"><vspace blankLines="0" />
          There are three dimensions to classifying mapping types: how they are
          created (implicitly/explicitly), their primary purpose
          (outbound/inbound), and how they are deleted (dynamic/static).
          Implicit mappings are created as a side-effect of some other
          operation; explicit mappings are created by a mechanism explicitly
          dealing with mappings. Outbound mappings exist primarily to facilitate
          outbound communication; inbound mappings exist primarily to facilitate
          inbound communication. Dynamic mappings are deleted when their lifetime
          expires, or though other protocol action; static mappings are permanent
          until the user chooses to delete them.
          <list style="symbols">
            <t>Implicit dynamic mappings are created implicitly as a
            side-effect of traffic such as an outgoing TCP SYN or
            outgoing UDP packet. Such packets were not originally
            designed explicitly for creating NAT (or firewall) state, but they can
            have that effect when they pass through a NAT (or firewall) device.
            Implicit dynamic mappings usually have a finite lifetime, though
            this lifetime is generally not known to the client using them.</t>
            <t>Explicit dynamic mappings are created as a result of
            explicit PCP MAP and PEER requests.
            Like a DHCP address lease, explicit dynamic mappings have
            finite lifetime, and this lifetime is communicated to the client.
            As with a DHCP address lease, if the
            client wants a mapping to persist the client must prove that
            it is still present by periodically renewing the mapping to
            prevent it from expiring. If a PCP client goes away, then
            any mappings it created will be automatically cleaned up
            when they expire.</t>
            <t>Explicit static mappings are created by manual configuration
            (e.g., via command-line interface or other user
            interface) and persist until the user changes that manual
            configuration.</t>
          </list></t>

          <t>Both implicit and explicit dynamic mappings are dynamic in the
          sense that they are created on demand, as requested
          (implicitly or explicitly) by the Internal Host, and have a
          lifetime. After the lifetime, the mapping is deleted unless
          the lifetime is extended by action by the Internal Host (e.g.,
          sending more traffic or sending another PCP request).</t>

          <t>Static mappings are by their nature always explicit.
          Static mappings differ from explicit dynamic mappings in that
          their lifetime is effectively infinite (they exist until manually removed)
          but otherwise they behave exactly the same as explicit MAP mappings.</t>

          <t>While all mappings are by necessity bidirectional (most Internet communication
          requires information to flow in both directions for successful operation)
          when talking about mappings it can be helpful to identify them loosely according
          to their 'primary' purpose.
          <list style="symbols">
            <t>Outbound mappings exist primarily to enable outbound communication.
            For example, when a host calls connect() to make an outbound connection, a
            NAT gateway will create an implicit dynamic outbound mapping to facilitate that
            outbound communication.</t>
            <t>Inbound mappings exist primarily to enable listening servers to receive inbound
            connections. Generally, when a client calls listen() to listen for inbound
            connections, a NAT gateway will not implicitly create any mapping to facilitate
            that inbound communication. A PCP MAP request can be used explicitly to create
            a dynamic inbound mapping to enable the desired inbound communication.</t>
          </list>

          Explicit static (manual) mappings and explicit dynamic (MAP) mappings
          both allow Internal Hosts to receive inbound traffic that is not in direct
          response to any immediately preceding outbound communication (i.e., to
          allow Internal Hosts to operate a "server" that is accessible to other
          hosts on the Internet).</t>

          <t hangText="PCP Client:"><vspace blankLines="0" />A PCP software
          instance responsible for issuing PCP requests to a PCP server.
          Several independent PCP Clients can exist on the same host.
          Several PCP Clients can be located in the same local network. A PCP
          Client can issue PCP requests on behalf of a third party device for
          which it is authorized to do so. An interworking function from
          Universal Plug and Play Internet Gateway Device (UPnP IGDv1
          <xref target="IGDv1"></xref>) to PCP is another example of a PCP Client. A
          PCP server in a NAT gateway that is itself a client of another NAT
          gateway (nested NAT) may itself act as a PCP client to the upstream
          NAT.</t>

          <t hangText="PCP-Controlled Device:"><vspace blankLines="0" />A
          NAT or firewall that controls or rewrites packet flows between
          internal hosts and remote peer hosts.  PCP manages the Mappings
          on this device.</t>

          <t hangText="PCP Server:"><vspace blankLines="0" />A PCP software
          instance that resides on the NAT or firewall that receives PCP
          requests from the PCP client and creates appropriate state in
          response to that request.</t>

<!--
          <t hangText="Interworking Function:"><vspace blankLines="0" />A
          functional element responsible for translating or proxying another
          protocol to PCP. For example interworking
          <xref target="IGDv1">UPnP IGDv1</xref> with PCP.</t>
-->

          <t hangText="Subscriber:"><vspace blankLines="0" /> The unit of
          billing for a commercial ISP. A subscriber may have a single IP
          address from the commercial ISP (which can be shared among multiple
          hosts using a NAT gateway, thereby making them appear to be a single
          host to the ISP) or may have multiple IP addresses provided by the
          commercial ISP. In either case, the IP address or addresses provided
          by the ISP may themselves be further translated by a Carrier-Grade NAT (CGN)
          operated by the ISP.</t>

<!--
          <t hangText="5-tuple"><vspace blankLines="0" />The 5 pieces
          of information that uniquely identify a flow at a given
          place and time: transport protocol, source IP address and
          port, destination IP address and port. When NAT is being
          used, addresses and ports for a given flow are rewritten as
          packets pass through the NAT, so for the same flow Internal
          Hosts see Internal Addresses, and Remote Peers see External
          Addresses. Most NATs configure their Internal Hosts via DHCP
          to have different Internal Addresses.  Some deployment
          scenarios (e.g., Dual-Stack Lite, Layer 2-Aware NAT) allow multiple hosts to
          use the same Internal Address at the same time and use
          additional information (such as IPv6 tunnel identifier or
          VLAN identifier) to distinguish 5-tuples.</t>
-->
        </list></t>
    </section>

    <?rfc needLines="15" ?>
    <section anchor="relationship" title="Relationship between PCP Server and its NAT/firewall">
      <t>The PCP server receives and responds to PCP requests. The PCP server
      functionality is typically a capability of a NAT or firewall device, as
      shown in <xref target="diagram_pcp_server"></xref>. It is also possible
      for the PCP functionality to be provided by some other device, which
      communicates with the actual NAT(s) or firewall(s) via some other proprietary
      mechanism, as long as from the PCP client's perspective such split
      operation is indistinguishable from the integrated case.</t>

      <figure align="left" anchor="diagram_pcp_server" title="PCP-Enabled NAT or Firewall">
        <artwork align="center"><![CDATA[
                         +-----------------+
+------------+           | NAT or firewall |
| PCP client |-<network>-+      with       +---<Internet>
+------------+           |    PCP server   |
                         +-----------------+]]></artwork>
      </figure>

<t>A NAT or firewall device, between the PCP client and the Internet,
might implement simple or advanced firewall functionality.  This may
be a side-effect of the technology implemented by the device (e.g., a
network address and port translator, by virtue of its port rewriting,
normally requires connections to be initiated from an inside host
towards the Internet), or this might be an explicit firewall policy to
deny unsolicited traffic from the Internet.  Some firewall devices deny
certain unsolicited traffic from the Internet (e.g., TCP, UDP to
most ports) but allow certain other unsolicited traffic from the
Internet (e.g., UDP port 500 and IPsec ESP)
<xref target="RFC6092"></xref>.  Such default filtering (or lack
thereof) is out of scope of PCP itself.  If a client device
wants to receive traffic and supports PCP, and does not possess prior knowledge of such
default filtering policy, it SHOULD use PCP to request the necessary mappings to receive
the desired traffic.</t>
    </section>

    <section anchor="fixed-size-addr" title="Note on Fixed-Size Addresses">
      <t>For simplicity in building and parsing request and response
      packets, PCP always uses fixed-size 128-bit IP address fields
      for both IPv6 addresses and IPv4 addresses.</t>

      <t>When the address field holds an IPv6 address, the fixed-size
      128-bit IP address field holds the IPv6 address stored as-is.</t>

      <t>When the address field holds an IPv4
      address, <xref target="RFC4291">IPv4-mapped IPv6
      addresses</xref> are used (::ffff:0:0/96).  This has the first
      80 bits set to zero and the next 16 set to one, while its
      last 32 bits are filled with the IPv4 address.  This is
      unambiguously distinguishable from a native IPv6 address,
      because an <xref target="RFC4291">IPv4-mapped IPv6
      address</xref> would not be valid for a mapping.</t>

      <t>When checking for an IPv4-mapped IPv6 address, all of the
      first 96 bits MUST be checked for the pattern -- it is not
      sufficient to check for ones in bits 81-96.</t>

      <t>The all-zeroes IPv6 address MUST be expressed by filling the
      fixed-size 128-bit IP address field with all zeroes (::).</t>

      <t>The all-zeroes IPv4 address MUST be expressed by 80 bits of
      zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0).</t>
    </section>

    <section title="Protocol Design Note" anchor="protocol_design_note">
      <t>PCP can be viewed as a request/response protocol, much like many other
      UDP-based request/response protocols, and can be implemented perfectly well as such.
      It can also be viewed as what might be called a hint/notification protocol,
      and this observation can help simplify implementations.</t>

      <t>Rather than viewing the message streams between PCP client and PCP server
      as following a strict request/response pattern, where every response is associated
      with exactly one request, the message flows can be viewed as two somewhat independent
      streams carrying information in opposite directions:
        <list style="symbols">
          <t>A stream of hints flowing from PCP client to PCP server, where the client
          indicates to the server what it would like the state of its mappings to be, and</t>
          <t>A stream of notifications flowing from PCP server to PCP client, where the server
          informs the clients what the state of its mappings actually is.</t>
        </list>
      To an extent, some of this approach is required anyway in a UDP-based request/response
      protocol, since UDP packets can be lost, duplicated, or reordered.</t>

      <t>In this view of the protocol, the client transmits hints to the
      server at various intervals signaling its desires, and the server
      transmits notifications to the client signaling the actual state of its
      mappings. These two message flows are loosely correlated in that
      a client request (hint) usually elicits a server response (notification),
      but only loosely, in that a client request may result in no server response
      (in the case of packet loss) and a server response may be generated gratuitously
      without an immediately preceding client request (in the case where server
      configuration change, e.g. change of external IP address on a NAT gateway,
      results in a change of mapping state).</t>

      <t>The exact times that client requests are sent are influenced by a
      client timing state machine taking into account whether
      (i) the client has not yet received a response from the server for
      a prior request (retransmission), or
      (ii) the client has previously received a response from the server
      saying how long the indicated mapping would remain active (renewal).
      This design philosophy is the reason why PCP's retransmissions and renewals are
      exactly the same packet on the wire. Typically, retransmissions are sent with
      exponentially increasing intervals as the client waits for the server to respond,
      whereas renewals are sent with exponentially decreasing intervals as the
      expiry time approaches, but from the server's point of view both packets
      are identical, and both signal the client's desire that the stated
      mapping exist or continue to exist.</t>

      <t>A PCP server usually sends responses as a direct result of client requests,
      but not always. For example, if a server is too overloaded to respond, it is allowed
      to silently ignore a request message and let the client retransmit. Also, if
      external factors cause a NAT gateway or firewall's configuration to change,
      then the PCP server can send unsolicited responses to clients informing them
      of the new state of their mappings. Such reconfigurations are expected to be rare,
      because of the disruption they can cause to clients, but should they happen,
      PCP provides a way for servers to communicate the new state
      to clients promptly, without having to wait for the next periodic renewal request.
      </t>

      <t>This design goal helps explain why PCP request and response messages
      have no transaction ID, because such a transaction ID is unnecessary,
      and would unnecessarily limit the protocol and unnecessarily complicate
      implementations. A PCP server response (i.e. notification) is self-describing
      and complete. It communicates the internal and external addresses, protocol, and ports
      for a mapping, and its remaining lifetime. If the client does in fact
      currently want such a mapping to exist then it can identify the mapping in question
      from the internal address, protocol, and port, and update its state to reflect the
      current external address and port, and remaining lifetime. If a client does not
      currently want such a mapping to exist then it can safely ignore the message.
      No client action is required for unexpected mapping notifications. In today's
      world a NAT gateway can have a static mapping, and the client device has
      no explicit knowledge of this, and no way to change the fact. Also, in today's
      world a client device can be connected directly to the public Internet, with
      a globally-routable IP address, and in this case it effectively has "mappings"
      for all of its listening ports. Such a device has to be responsible for its own
      security, and cannot rely on assuming that some other network
      device will be blocking all incoming packets.</t>

    </section>

    <section title="Common Request and Response Header Format">
      <t>All PCP messages are sent over UDP, with a maximum UDP payload length of
      1100 octets.  The PCP messages contain a request or response
      header containing an Opcode, any relevant Opcode-specific
      information, and zero or more Options. All numeric quantities
      larger than a single octet (e.g. Result codes, Lifetimes, Epoch times, etc.)
      are represented in conventional IETF network order, i.e. most significant octet first.
      Non-numeric quantities are represented as-is on all platforms,
      with no byte swapping (e.g. IP addresses and ports are placed in PCP messages
      using the same representation as when placed in IP or TCP headers).</t>

      <t>The packet layout for
      the common header, and operation of the PCP client and PCP
      server, are described in the following sections. The information
      in this section applies to all Opcodes. Behavior of the Opcodes
      defined in this document is described in
      <xref target="map_opcodes"></xref> and
      <xref target="peer_opcodes"></xref>.</t>

      <section title="Request Header">
        <figure align="left" anchor="common_request" title="Common Request Packet Format">
          <preamble>All requests have the following format:</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version = 2  |R|   Opcode    |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Requested Lifetime (32 bits)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            PCP Client's IP Address (128 bits)                 |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:             (optional) Opcode-specific information            :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:             (optional) PCP Options                            :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>These fields are described below:<list style="hanging">
            <t hangText="Version:">This document specifies protocol
            version 2.  PCP clients and servers compliant with this
            document use the value 2.  This field is used for version
            negotiation as described in
            <xref target="version"></xref>.</t>

            <t hangText="R:">Indicates Request (0) or Response (1).</t>

            <t hangText="Opcode:">A seven-bit value specifying the operation
            to be performed. Opcodes are defined in
            <xref target="map_opcodes"></xref> and
            <xref target="peer_opcodes"></xref>.</t>

<!--
            <t hangText="PCP Client's Port:">The source port in the UDP header
            used by the PCP client when sending this PCP request.</t>
-->
<t hangText="Reserved:">16 reserved bits.  MUST be zero on transmission and
MUST be ignored on reception.</t>

            <t hangText="Requested Lifetime:">An unsigned 32-bit
            integer, in seconds, ranging from 0 to 2^32-1
            seconds. This is used by the MAP and PEER Opcodes defined
            in this document for their requested lifetime.</t>

            <t hangText="PCP Client's IP Address:">The source IPv4 or IPv6
            address in the IP header used by the PCP client when sending this
            PCP request.  IPv4 is represented using an IPv4-mapped IPv6 address.
            This is used to detect an unexpected NAT on the path between
            the PCP client and the PCP-controlled NAT or firewall device.
            See <xref target="general_generate_request"></xref></t>

            <t hangText="Opcode-specific information:">Payload data for this Opcode.
            The length of this data is determined by the Opcode definition.</t>

            <t hangText="PCP Options:">Zero, one, or more Options that
are legal for both a PCP request and for this Opcode.  See 
<xref target="options"></xref>.</t>

          </list></t>

     </section>

      <section title="Response Header">
        <figure align="left" anchor="common_response" title="Common Response Packet Format">
          <preamble>All responses have the following format:</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version = 2  |R|   Opcode    |   Reserved    |  Result Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Lifetime (32 bits)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Epoch Time (32 bits)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      Reserved (96 bits)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:             (optional) Opcode-specific response data          :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:             (optional) Options                                :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>These fields are described below:<list style="hanging">
            <t hangText="Version:">Responses from servers compliant with this specification MUST use version 2. This is set by the server.</t>

            <t hangText="R:">Indicates Request (0) or Response (1). All
            Responses MUST use 1. This is set by the server.</t>

            <t hangText="Opcode:">The 7-bit Opcode value. The server copies this value from the
            request.</t>

            <t hangText="Reserved:">8 reserved bits, MUST be sent as 0, MUST
            be ignored when received. This is set by the server.</t>

            <t hangText="Result Code:">The result code for this response. See
            <xref target="result_codes"></xref> for values. This is set by the
            server.</t>

            <t hangText="Lifetime:">An unsigned 32-bit integer, in
            seconds, ranging from 0 to 2^32-1 seconds. On an
            error response, this indicates how long clients should
            assume they'll get the same error response from that PCP
            server if they repeat the same request. On a success
            response for the PCP Opcodes that create a mapping (MAP
            and PEER), the Lifetime field indicates the lifetime for
            this mapping.  This is set by the server.</t>

            <t hangText="Epoch Time:">The server's Epoch time value. See
            <xref target="epoch"></xref> for discussion. This value is set by the server, in both success and error responses.</t>

            <t hangText="Reserved:">96 reserved bits.  For requests
            that were successfully parsed, this MUST be sent as 0,
            MUST be ignored when received. This is set by the server.
            For requests that were not successfully parsed, the server
            copies the last 96 bits of the PCP Client's IP Address
            field from the request message into this corresponding 96
            bit field of the response.</t>

            <t hangText="Opcode-specific information:">Payload data for
this Opcode.  The length of this data is determined by the Opcode
definition.</t>

            <t hangText="PCP Options:">Zero, one, or more Options that
are legal for both a PCP response and for this Opcode.  See 
<xref target="options"></xref>.</t>


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

      <section anchor="options" title="Options">
        <t>A PCP Opcode can be extended with one or more Options. Options can
        be used in requests and responses. The design decisions in this
        specification about whether to
        include a given piece of information in the base Opcode format or in
        an Option were an engineering trade-off between packet size and code
        complexity. For information that is usually (or always) required,
        placing it in the fixed Opcode data results in simpler code to
        generate and parse the packet, because the information is a fixed
        location in the Opcode data, but wastes space in the packet in the
        event that field is all-zeroes because the information is not needed
        or not relevant. For information that is required less often, placing
        it in an Option results in slightly more complicated code to generate
        and parse packets containing that Option, but saves space in the
        packet when that information is not needed. Placing information in an
        Option also means that an implementation that never uses that
        information doesn't even need to implement code to generate and parse
        it. For example, a client that never requests mappings on behalf of
        some other device doesn't need to implement code to generate the
        THIRD_PARTY Option, and a PCP server that doesn't implement the
        necessary security measures to create third-party mappings safely
        doesn't need to implement code to parse the THIRD_PARTY Option.</t>
<!--
        (However, note that in the case of THIRD_PARTY, for requests
        containing the THIRD_PARTY Option a PCP server that doesn't
        implement the THIRD_PARTY Option still needs to return a
        NOT_AUTHORIZED error rather than UNSUPP_OPCODE. This is to avoid
        leaking the capabilities of the PCP server to unauthorized clients.)</t>
-->

        <figure align="left" anchor="options-layout" title="Options Header">
          <preamble>Options use the following Type-Length-Value
          format:</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       (optional) data                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>The description of the fields is as follows:<list style="hanging">
            <t hangText="Option Code:">8 bits.  Its most significant bit
            indicates if this Option is mandatory (0) or optional (1) to
            process.</t>

            <t hangText="Reserved:">8 bits. MUST be set to 0 on transmission
            and MUST be ignored on reception.</t>

            <t hangText="Option Length:">16 bits. Indicates the length of the
            enclosed data, in octets. Options with length of 0 are allowed.
            Options that are not a multiple of four octets long are followed
            by one, two, or three zero octets to pad their effective length
            in the packet to be a multiple of four octets. The Option Length
            reflects the semantic length of the option, not including any
            padding octets.</t>

            <t hangText="data:">Option data.</t>
          </list></t>

        <t>If several Options are
        included in a PCP request, they MAY be encoded in any order by
        the PCP client, but MUST be processed by the PCP server in the
        order in which they appear.  It is the responsibility of the
        PCP client to ensure the server has sufficient room to reply
        without exceeding the 1100 octet size limit; if its reply would
        exceed that size, the server generates an error.</t>

        <t>If, while processing a PCP request, including its options,
        an error is encountered that causes
        a PCP error response to be generated, the PCP request MUST cause no
        state change in the PCP server or the PCP-controlled device (i.e., it
        rolls back any changes it might have made while processing the
        request). Such an error response MUST consist of a complete copy of the request
        packet with the error code and other appropriate fields set in the header.</t>

        <t>An Option MAY appear more than once in a request or in a
        response, if permitted by the definition of the Option. If the
        Option's definition allows the Option to appear only once but it
        appears more than once in a request, and the Option is understood
        by the PCP server, the PCP server MUST respond with
        the MALFORMED_OPTION result code.
        If the PCP server encounters an invalid option
        (e.g., PCP option length is longer than the UDP packet length)
        the error MALFORMED_OPTION SHOULD
        be returned (rather than MALFORMED_REQUEST), as that helps the
        client better understand how the packet was malformed.
        If a PCP response would have
        exceeded the maximum PCP message size, the PCP server SHOULD
        respond with MALFORMED_REQUEST.</t>

        <t>If the overall Option structure of a request cannot successfully be
        parsed (e.g. a nonsensical option length) the PCP server MUST generate an
        error response with code MALFORMED_OPTION.</t>

        <t>If the overall Option structure of a request is valid then how each
        individual Option is handled is determined by the most significant bit
        in the Option Code. If the most significant bit is set, handling this
        Option is optional, and a PCP server MAY process or ignore this Option,
        entirely at its discretion. If the most significant bit is clear,
        handling this Option is mandatory, and a PCP server MUST return the
        error MALFORMED_OPTION if the option contents are malformed, or
        UNSUPP_OPTION if the Option is unrecognized, unimplemented, or
        disabled, or if the client is not authorized to use the Option.
        In error responses all options are returned. In success responses all
        processed options are included and unprocessed options are not included.</t>

        <t>PCP clients are free to ignore any or all Options included in
        responses, although naturally if a client explicitly requests an
        Option where correct execution of that Option requires processing the
        Option data in the response, that client is expected to implement code
        to do that.</t>

        <?rfc needLines="9" ?>
        <t>Different options are valid for different Opcodes. For example:
          <list style="symbols">
            <t>The THIRD_PARTY Option is valid for both MAP and PEER Opcodes.</t>
            <t>The FILTER Option is valid only for the MAP Opcode
            (for the PEER Opcode it would have no meaning).</t>
            <t>The PREFER_FAILURE Option is valid only for the MAP Opcode
            (for the PEER Opcode, similar semantics are automatically implied).</t>
          </list>
        </t>

      </section>

      <?rfc needLines="15" ?>
      <section anchor="result_codes" title="Result Codes">
        <t>The following result codes may be returned as a result of any
        Opcode received by the PCP server. The only success result code is 0;
        other values indicate an error. If a PCP server encounters multiple
        errors during processing of a request, it SHOULD use the most specific
        error message. Each error code below is classified as either a 'long
        lifetime' error or a 'short lifetime' error, which provides guidance
        to PCP server developers for the value of the Lifetime field for these
        errors. It is RECOMMENDED that short lifetime errors use a 30 second
        lifetime and long lifetime errors use a 30 minute lifetime.

          <list style="hanging">
            <t hangText="0">SUCCESS: Success.</t>

            <t hangText="1">UNSUPP_VERSION: The version number at the start
            of the PCP Request header is not recognized by this PCP server.
            This is a long lifetime error. This document describes PCP version 2.</t>

            <t hangText="2">NOT_AUTHORIZED: The requested operation is
            disabled for this PCP client, or the PCP client requested an
            operation that cannot be fulfilled by the PCP server's security
            policy. This is a long lifetime error.</t>
<!--
NOT_AUTHORIZED MUST be
            returned if the client uses the THIRD_PARTY Option and the PCP
            Server (a) does not support THIRD_PARTY requests, or (b) supports
            THIRD_PARTY requests but has be configured to disallow them, or
            (c) supports THIRD_PARTY requests and has be configured to allow
            them for some clients but this client did not pass the PCP
            Server's authorization check.</t>
-->

            <t hangText="3">MALFORMED_REQUEST: The request could
            not be successfully parsed.  This is a long lifetime error.</t>

            <t hangText="4">UNSUPP_OPCODE: Unsupported Opcode.  This is a long lifetime error.</t>

            <t hangText="5">UNSUPP_OPTION: Unsupported Option. This error only
            occurs if the Option is in the mandatory-to-process range.  This is a long lifetime error.</t>

            <t hangText="6">MALFORMED_OPTION: Malformed Option (e.g., appears
            too many times, invalid length).  This is a long lifetime error.</t>

            <t hangText="7">NETWORK_FAILURE: The PCP server or the device it
            controls are experiencing a network failure of some sort (e.g.,
            has not obtained an External IP address). This is a short lifetime
            error.</t>

            <t hangText="8">NO_RESOURCES: Request is well-formed and
            valid, but the server has insufficient resources to
            complete the requested operation at this time.  For
            example, the NAT device cannot create more mappings at
            this time, is short of CPU cycles or memory, or
            is unable to handle the request due to
            some other temporary condition.  The same request may
            succeed in the future.  This is a system-wide error,
            different from USER_EX_QUOTA.
            This can be used as a catch-all error, should no
            other error message be suitable.  This is a short lifetime error.</t>

            <t hangText="9">UNSUPP_PROTOCOL: Unsupported transport protocol,
            e.g. SCTP in a NAT that handles only UDP and TCP.
            This is a long lifetime error.</t>

            <t hangText="10">USER_EX_QUOTA: This attempt to create a
            new mapping would exceed this subscriber's port quota. This
            is a short lifetime error.</t>

            <t hangText="11">CANNOT_PROVIDE_EXTERNAL: The suggested
            external port and/or external address cannot be provided.
            This error MUST only be returned for:
            <?rfc subcompact="yes"?>
            <list style="symbols">
            <t>MAP requests that included the PREFER_FAILURE Option<vspace blankLines="0" />
            (normal MAP requests will return an available external port)</t>
            <t>MAP requests for the SCTP protocol (PREFER_FAILURE is implied)</t>
            <t>PEER requests</t>
            <?rfc subcompact="no"?>
            </list>
            See <xref target="prefer_failure"></xref> for processing
            details. The error lifetime depends on the reason for the
            failure.</t>

            <t hangText="12">ADDRESS_MISMATCH: The source IP address of
            the request packet does not match the contents of the PCP
            Client's IP Address field, due to an unexpected NAT on the path
            between the PCP client and the PCP-controlled NAT or firewall.
            This is a long lifetime error.</t>

            <t hangText="13">EXCESSIVE_REMOTE_PEERS: The PCP server
            was not able to create the filters in this request. This result
            code MUST only be returned if the MAP request contained the FILTER
            Option. See <xref target="filter"></xref> for processing
            information. This is a long lifetime error.</t>

          </list></t>

      </section>
    </section>

    <section anchor="general" title="General PCP Operation">
      <t>PCP messages MUST be sent
      over <xref target="RFC0768">UDP</xref>.
      Every PCP request generates at least one response, so PCP does
      not need to run over a reliable transport protocol.</t>

<t>When receiving multiple identical requests, the PCP server will 
  generate identical responses, provided the PCP server's state
  did not change between those requests due to other activity.
      For example, if a request is received while the PCP-controlled
      device has no mappings available, it will generate an error
      response.  If mappings become available and then a (duplicated
      or re-transmitted) request is seen by the server, it will
      generate a non-error response.  A PCP client MUST
      handle such updated responses for any request it sends,
      most notably to support Rapid Recovery
      (<xref target="Rapid_Recovery"></xref>).  Also
      see <xref target="protocol_design_note">the Protocol Design Note</xref>.</t>

      <section title="General PCP Client: Generating a Request" anchor="general_generate_request">
        <t>This section details operation specific to a PCP client, for any
        Opcode. Procedures specific to the MAP Opcode are described in
        <xref target="map_opcodes"></xref>, and procedures specific to the PEER
        Opcode are described in <xref target="peer_opcodes"></xref>.</t>

        <t>Prior to sending its first PCP message, the PCP client determines
        which server to use. The PCP client performs the following steps to
        determine its PCP server: <list style="numbers">
            <t>if a PCP server is configured (e.g., in a configuration file or
            via DHCP), that single configuration source is used as the list
            of PCP Server(s), else;</t>

            <t>the default router list (for IPv4 and IPv6) is used as
            the list of PCP Server(s).  Thus, if a PCP client has both
            an IPv4 and IPv6 address, it will have an IPv4 PCP server
            (its IPv4 default router) for its IPv4 mappings, and an
            IPv6 PCP server (its IPv6 default router) for its IPv6
            mappings.</t>
          </list></t>

        <t>For the purposes of this document, only a single PCP server address
        is supported. Should future specifications define configuration
        methods that provide a longer list of PCP server addresses, those
        specifications will define how clients select one or more addresses
        from that list.</t>

        <t>With that PCP server address, the PCP client formulates its PCP
        request. The PCP request contains a PCP common header, PCP Opcode and
        payload, and (possibly) Options. As with all UDP client
        software on any operating system, when several independent PCP clients
        exist on the same host, each uses a distinct source port number to
        disambiguate their requests and replies. The PCP client's source port
        SHOULD be randomly generated <xref target="RFC6056"></xref>.</t>

        <t>The PCP client MUST include the source IP address of the PCP
        message in the PCP request. This is typically its own IP address;
        see <xref target="implement_source_address"></xref> for how this can be
        coded. This is used to detect an unexpected NAT on the path between the
        PCP client and the PCP-controlled NAT or firewall device, to avoid wasting
        state on the PCP-controlled NAT creating pointless non-functional mappings.
        When such an intervening non-PCP-aware inner NAT is detected, mappings
        must first be created by some other means in the inner NAT, before
        mappings can be usefully created in the outer PCP-controlled NAT. Having
        created mappings in the inner NAT by some other means, the PCP client
        should then use the inner NAT's External Address as the Client IP Address,
        to signal to the outer PCP-controlled NAT that the client is aware of the
        inner NAT, and has taken steps to create mappings in it by some other
        means, so that mappings created in the outer NAT will not be a pointless
        waste of state.</t>

<!--
        <t>When attempting to contact a PCP server, the PCP client
        sends a PCP message to the first server in its list of PCP
        servers, and SHOULD initialize a timer to a random value
        between 2 and 3 seconds.</t>
-->

<section anchor="retransmission" title="PCP Client Retransmission">

   <t>PCP clients are responsible for reliable delivery of PCP request
   messages.  If a PCP client fails to receive an expected response
   from a server, the client must retransmit its message.
   The retransmissions MUST use the same Mapping Nonce value
   (see <xref target="MAPPacket"/> and <xref target="PEERPacket"/>).
   The client begins the message exchange by transmitting a message to the server.
   The message exchange continues for as long as the client wishes to maintain
   the mapping, and terminates when the PCP client is no longer interested
   in the PCP transaction (e.g., the application that requested the mapping is no
   longer interested in the mapping) or (optionally) when the message exchange
   is considered to have failed according to the retransmission mechanism
   described below.</t>

   <t>The client retransmission behavior is controlled and described by the
   following variables:
<list style="hanging" hangIndent="8">

<t hangText="  RT:">Retransmission timeout, calculated as described below</t>

<t hangText=" IRT:">Initial retransmission time, SHOULD be 3 seconds</t>

<t hangText=" MRC:">Maximum retransmission count, SHOULD be 0 (0 indicates no maximum)</t>

<t hangText=" MRT:">Maximum retransmission time, SHOULD be 1024 seconds</t>

<t hangText=" MRD:">Maximum retransmission duration, SHOULD be 0 (0 indicates no maximum)</t>

<t hangText="RAND:">Randomization factor, calculated as described below</t>
</list></t>

<t>With each message transmission or retransmission, the client sets RT
   according to the rules given below.  If RT expires before a response
   is received, the client recomputes RT and retransmits the
   request.</t>

<t>Each of the computations of a new RT include a new randomization factor
   (RAND), which is a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor is included to
   minimize synchronization of messages transmitted by PCP clients.
   The algorithm for choosing a random number does not need to be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation of the PCP
   client.</t>

   <t>The RT value is initialized based on IRT:
<list style="empty"><t>RT = (1 + RAND) * IRT</t></list></t>

   <t>RT for each subsequent message transmission is based on the previous
   value of RT, subject to the upper bound on the value of RT specified by MRT.
   If MRT has a value of 0, there is no upper limit on the value of RT, and MRT
   is treated as "infinity":
<list style="empty"><t>RT = (1 + RAND) * MIN (2 * RTprev, MRT)</t></list></t>

<t>MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.</t>

<t>MRD specifies an upper bound on the length of time a client may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.</t>

<t>If both MRC and MRD are non-zero, the message exchange fails
   whenever either of the conditions specified in the previous two
   paragraphs are met.  If both MRC and MRD are zero, the client
   continues to transmit the message until it receives a response,
   or the client no longer wants a mapping.</t>




<!--
        <t>For as long as the client still desires the indicated
        mapping, if no response is received before the timer expires
        then the request is re-transmitted.  These re-transmissions
        are sent at a random value between 1.5 and 2.5 times the previous
        transmission interval.  The randomization helps avoid client
        synchronization.  This repeats until a maximum retransmission
        interval between 512 and 1024 seconds, at which point the
        retransmission continue at that interval, until a successful
        response is received or the client no longer desires the
        indicated mapping.</t>
-->

        <t>Once a PCP client has successfully received a response from a PCP
        server on that interface, it resets RT to a value randomly selected
        in the range 1/2 to 5/8 of the mapping lifetime, as described in
        <xref target="renewal"></xref>, and
        sends subsequent PCP requests for that mapping to that same server.</t>



        <!--
        <t>If, during its transmissions to a PCP server, the PCP client
        receives a hard or soft ICMP error (<xref target="RFC5461"></xref>),
        the ICMP error SHOULD be ignored.</t>

        <t>Upon receiving a response (success or error), the PCP client does
        not change to a different PCP server. That is, it does not "shop
        around" trying to find a PCP server to service its (same) request.</t>
-->

<t><list style="empty">
<t>Note: If the server's state changes between retranmissions and the
server's response is delayed or lost, the state in the PCP client and
server may not be synchronized.  This is not unique to PCP, but also
occurs with other network protocols (e.g., TCP).  In the unlikely
event that such de-synchronization occurs, PCP heals itself after
Lifetime seconds.</t>
</list></t>
</section>
      </section>

      <section title="General PCP Server: Processing a Request">
        <t>This section details operation specific to a PCP server. Processing
        SHOULD be performed in the order of the following paragraphs.</t>

        <t>A PCP server MUST only accept normal (non-THIRD_PARTY) PCP
        requests from a client on the same interface it would normally
        receive packets from that client, and MUST silently ignore PCP
        requests arriving on any other interface. For example, a
        residential NAT gateway accepts PCP requests only when they arrive on
        its (LAN) interface connecting to the internal network, and
        silently ignores any PCP requests arriving on its external (WAN)
        interface. A PCP server which supports THIRD_PARTY requests
        MAY be configured to accept THIRD_PARTY requests on other
        configured interfaces (see <xref target="third_party"></xref>).</t>

        <t>Upon receiving a request, the PCP server parses and validates it.
        A valid request contains a valid PCP common header, one valid PCP
        Opcode, and zero or more Options (which the server might or might not
        comprehend). If an error is encountered during processing, the server
        generates an error response which is sent back to the PCP client.
        Processing an Opcode and the Options are specific to each Opcode.</t>

        <t>Error responses have the same packet layout as success
        responses, with certain fields from the request copied into the
        response, and other fields assigned by the PCP server set as
        indicated in <xref target="common_response"></xref>.</t>

        <t>Copying request fields into the response is important because this is what
        enables a client to identify to which request a given
        response pertains.  For Opcodes that are understood by the PCP
        server, it follows the requirements of that Opcode to copy the
        appropriate fields.  For Opcodes that are not understood by the
        PCP server, it simply generates the UNSUPP_OPCODE response and
        copies fields from the PCP header and copies the rest of the
        PCP payload as-is (without attempting to interpret it).</t>

        <t>All responses (both error and success) contain the same Opcode
        as the request, but with the "R" bit set.</t>

        <?rfc needLines="11" ?>
        <t>Any error response has a nonzero Result Code, and is created by:
          <?rfc subcompact="yes"?>
          <list style="symbols">
          <t>Copying the entire UDP payload, or 1100 octets,
          whichever is less, and zero-padding the response to a multiple
          of 4 octets if necessary</t>
          <t>Setting the R bit</t>
          <t>Setting the Result Code</t>
          <t>Setting the Lifetime, Epoch Time and Reserved fields</t>
          <t>Updating other fields in the response, as indicated by 'set
          by the server' in the PCP response field description.</t>
          <?rfc subcompact="no"?>
          </list>
        </t>

        <?rfc needLines="11" ?>
        <t>A success response has a zero Result Code, and is created by:
          <?rfc subcompact="yes"?>
          <list style="symbols">
          <t>Copying the first four octets of request packet header</t>
          <t>Setting the R bit</t>
          <t>Setting the Result Code to zero</t>
          <t>Setting the Lifetime, Epoch Time and Reserved fields</t>
          <t>Possibly setting opcode-specific response data if appropriate</t>
          <t>Adding any processed options to the response message</t>
          <?rfc subcompact="no"?>
          </list>
        </t>

        <t>If the received PCP request message is less than two octets long it is silently dropped.</t>

        <t>If the R bit is set the message is silently dropped.</t>

        <t>If the first octet (version) is a version that is not supported,
        a response is generated with the UNSUPP_VERSION result code, and the
        other steps detailed in <xref target="version"/> are followed.</t>

        <t>Otherwise, if the version is supported but the received
        message is shorter than 24 octets, the message is silently dropped.</t>

        <t>If the server is overloaded by requests (from a particular client
        or from all clients), it MAY simply silently discard requests, as the requests
        will be retried by PCP clients, or it MAY generate the
        NO_RESOURCES error response.</t>

        <t>If the length of the message exceeds 1100 octets, is not a
        multiple of 4 octets, or is too short for the opcode in
        question, it is invalid and a MALFORMED_REQUEST response is
        generated, and the response message is truncated to 1100 octets.</t>

        <t>The PCP server compares the source IP address (from the
        received IP header) with the field PCP Client IP Address.  If
        they do not match, the error ADDRESS_MISMATCH MUST be returned.
        This is done to detect and prevent accidental use of PCP where a
        non-PCP-aware NAT exists between the PCP client and PCP server.
        If the PCP client wants such a mapping it needs to ensure the
        PCP field matches its apparent IP address from the perspective
        of the PCP server.</t>
      </section>

      <section title="General PCP Client: Processing a Response" anchor="pcp_processing_response">
        <t>The PCP client receives the response and verifies that the source
        IP address and port belong to the PCP server of a previously-sent PCP
        request. If not, the response is silently dropped.</t>

        <t>If the received PCP response message is less than four octets
        long it is silently dropped.</t>

        <t>If the R bit is clear the message is silently dropped.</t>

        <t>If the error code is UNSUPP_VERSION processing continues as
        described in <xref target="version"></xref>.</t>

        <t>The PCP client then validates that the Opcode matches a
        previous PCP request.  Responses shorter than 24 octets,
        longer than 1100 octets, or not a multiple of 4 octets are
        invalid and ignored, likely causing the request to be
        re-transmitted. The response is further matched by comparing
        fields in the response Opcode-specific data to fields in the
        request Opcode-specific data, as described by the processing
        for that Opcode.</t>

        <t>After these matches are successful, the PCP client checks the
        Epoch Time field to determine if it needs to restore its state
        to the PCP server (see <xref target="epoch"></xref>).  A PCP
        client SHOULD be prepared to receive multiple responses from
        the PCP Server at any time after a single request is sent.
        This allows the PCP server to inform the client of mapping
        changes such as an update or deletion.  For example, a PCP
        Server might send a SUCCESS response and, after a
        configuration change on the PCP Server, later send a
        NOT_AUTHORIZED response.  A PCP client MUST be prepared to
        receive responses for requests it never sent (which could have
        been sent by a previous PCP instance on this same host, or by
        a previous host that used the same client IP address, or by a
        malicious attacker) by simply ignoring those unexpected
        messages.</t>

        <t>If the error ADDRESS_MISMATCH is received, it indicates the
        presence of a NAT between the PCP client and PCP server.
        Procedures to resolve this problem are beyond the scope of
        this document.</t>

        <t>For both success and error responses a Lifetime value is
        returned.  The Lifetime indicates how long this request is
        considered valid by the server.  The PCP client SHOULD impose
        an upper limit on this returned value (to protect against
        absurdly large values, e.g., 5 years), detailed
        in <xref target="lifetime"></xref>.</t>
       
        <t>If the result code is 0 (SUCCESS), the request succeeded.</t>

        <t>If the result code is not 0, the request failed, and the PCP
        client SHOULD NOT resend the same request for the indicated
        Lifetime of the error (as limited by the sanity checking detailed in
        <xref target="lifetime"></xref>).</t>
        
        <t>If the PCP client has discovered a new PCP server (e.g., connected
        to a new network), the PCP client MAY immediately begin communicating
        with this PCP server, without regard to hold times from communicating
        with a previous PCP server.</t>
      </section>

      <section anchor="mif" title="Multi-Interface Issues">
        <t>Hosts that desire a PCP mapping might be multi-interfaced (i.e.,
        own several logical/physical interfaces). Indeed, a host can be
        configured with several IPv4 addresses (e.g., Wi-Fi and Ethernet) or
        dual-stacked. These IP addresses may have distinct reachability scopes
        (e.g., if IPv6 they might have global reachability scope as for Global
        Unicast Address (GUA, <xref target="RFC3587"></xref>) or limited scope
        as for <xref target="RFC4193">Unique Local Address (ULA)</xref>).</t>

        <t>IPv6 addresses with global reachability (e.g., GUA) SHOULD
        be used as the source address when generating a PCP
        request. IPv6 addresses without global reachability
        (e.g., <xref target="RFC4193">ULA</xref>), SHOULD NOT be used
        as the source interface when generating a PCP
        request. If <xref target="RFC4941">IPv6 privacy
        addresses</xref> are used for PCP mappings, a new PCP request
        will need to be issued whenever the IPv6 privacy address is
        changed. This PCP request SHOULD be sent from the IPv6 privacy
        address itself. It is RECOMMENDED that the client delete its
        mappings to the previous privacy address after it no longer needs
        those old mappings.</t>

        <t>Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope
        (e.g., <xref target="RFC1918">private addresses</xref>) MAY be used as
        the source interface when generating a PCP request.</t>

<!--
        <t>As mentioned in <xref target="single_homed"></xref>, only
        single-homed CP routers are in scope. Therefore, there is no viable
        scenario where a host located behind a CP router is assigned two
        Global Unicast Addresses belonging to different global IPv6
        prefixes.</t>
-->

        <!--
Section 2.4, "Change of the Internal IP Address"

   When a new IP address is assigned to a host implementing a PCP Client,
   the PCP Client MUST install on the PCP server all the mappings it
   manages, using the new assigned IP address as the internal IP
   address.

This needs some additional discussion.  Let's take an example where
I have a computer with both Wi-Fi and wired Ethernet connections
and I plug and unplug the Ethernet connection, or go in and out
of range of Wi-Fi.  When do we want PCP to do something about
that change of connectivity?   Does the answer depend on IPv4,
IPv6, or dual stack running on that interface if we're doing PIN44,
PIN64, PIN46, PIN66?

Med: Good point. IMHO, the address selection should be done according to the-be-completed
section: http://tools.ietf.org/html/draft-ietf-pcp-base-02#section-6.1.3. Based on the
output of that process, the PCP Client can be triggered accordingly.


Or ... just recommend the internal IP address not be changed!
-->
      </section>

      <section anchor="epoch" title="Epoch">
        <t>Every PCP response sent by the PCP server includes an Epoch
        time field.  This time field increments by one every second.
        Anomalies in the received Epoch time value provide a hint to PCP
        clients that a PCP server state loss may have occurred. Clients
        respond to such state loss hints by promptly renewing their mappings,
        so as to quickly restore any lost state at the PCP server.</t>

        <t>If the PCP server resets or loses the state of its
        explicit dynamic Mappings (that is, those mappings created by
        PCP requests), due to reboot, power failure, or any other
        reason, it MUST reset its Epoch time to its initial starting
        value (usually zero) to provide this hint to PCP clients.
        After resetting its Epoch time, the PCP server resumes incrementing the
        Epoch time value by one every second.  Similarly, if the External IP
        Address(es) of the NAT (controlled by the PCP server) changes,
        the Epoch time MUST be reset.  A PCP server MAY maintain one Epoch time
        value for all PCP clients, or MAY maintain distinct Epoch time
        values (per PCP client, per interface, or based on other
        criteria); this choice is implementation-dependent.</t>

        <t>Whenever a client receives a PCP response, the client
        validates the received Epoch time value according to the
        procedure below, using integer arithmetic:

        <list style="symbols">

        <t>If this is the first PCP response the client has received from
        this PCP server, the Epoch time value is treated as necessarily valid, otherwise

        <list style="symbols">

        <t>If the current PCP server Epoch time (curr_server_time)
        is less than the previously received PCP server Epoch time
        (prev_server_time) by more than one second, then the client treats
        the Epoch time as obviously invalid (time should not go backwards).
        The server Epoch time apparently going backwards by *up to* one
        second is not deemed invalid, so that minor packet re-ordering
        on the path from PCP Server to PCP Client does not trigger a
        cascade of unnecessary mapping renewals. If the server Epoch time
        passes this check, then further validation checks are performed:

        <list style="symbols">

        <t>The client computes the difference between its
        <vspace />
        current local time (curr_client_time) and the
        <vspace />
        time the previous PCP response was received from this PCP
        server (prev_client_time):
        <vspace />
        client_delta = curr_client_time - prev_client_time;</t>

        <t>The client computes the difference between the
        <vspace />
        current PCP server Epoch time (curr_server_time) and the
        <vspace />
        previously received Epoch time (prev_server_time):
        <vspace />
        server_delta = curr_server_time - prev_server_time;</t>

        <t>If client_delta+2 &lt; server_delta - server_delta/16
        <vspace />
        or server_delta+2 &lt; client_delta - client_delta/16
        <vspace />
        then the client treats the Epoch time value as invalid,
        <vspace />
        else the client treats the Epoch time value as valid</t>

        </list></t>

        </list></t>

        <t>The client records the current time values for use in its next comparison:
        <vspace />
        prev_client_time = curr_client_time
        <vspace />
        prev_server_time = curr_server_time</t>

        </list></t>

        <t>If the PCP client determined that the Epoch time value it
        received was invalid then it concludes that the PCP server may
        have lost state, and promptly renews all its active port mapping
        leases as described in <xref target="reboot"></xref>.</t>

        <?rfc needLines="8" ?>
        <t>Notes:<list style="symbols">

          <t>The client clock MUST never go backwards. If curr_client_time is found
          to be less than prev_client_time then this is a client bug, and how
          the client deals with this client bug is implementation specific.</t>

          <t>The calculations above are constructed to allow
          client_delta and server_delta to be computed as unsigned
          integer values.</t>

          <t>The "+2" in the calculations above is to accommodate
        quantization errors in client and server clocks (up to one
          second quantization error each in server and client time intervals).</t>

          <t>The "/16" in the calculations above is to accommodate inaccurate clocks in
          low-cost devices. This allows for a total discrepancy of up to 1/16 (6.25%)
          to be considered benign, e.g., if one clock were to run too fast by 3% while the
          other clock ran too slow by 3% then the client would not consider this
          difference to be anomalous or indicative of a restart having occurred.
          This tolerance is strict enough to be effective at detecting reboots,
          while not being so strict as to generate false alarms.</t>

        </list></t>

      </section>


  </section>

      <?rfc needLines="7" ?>
      <section anchor="version" title="Version Negotiation">

        <t>A PCP client sends its requests using PCP version number 2. Should
        later updates to this document specify different message formats with
        a version number greater than 2 it is expected that PCP servers will
        still support version 2 in addition to the newer version(s). However,
        in the event that a server returns a response with result code
        UNSUPP_VERSION, the client MAY log an error message to inform the user
        that it is too old to work with this server.</t>

        <t>Should later updates to this document specify different
        message formats with a version number greater than 2, and
        backwards compatibility is desired, this first octet
        can be used for forward and backward compatibility.</t>

        <t>If future PCP versions greater than 2 are specified, version
        negotiation proceeds as follows: <list style="numbers">

<!--
            <t>If a client or server supports more than one version it SHOULD
            support a contiguous range of versions  i.e., a lowest version
            and a highest version and all versions in between.</t>
-->

            <t>The client sends its first request using the highest (i.e., presumably
            'best') version number it supports.</t>

            <t>If the server supports that version it responds normally.</t>

            <t>If the server does not support that version it replies giving a
            result containing the result code UNSUPP_VERSION, and the closest
            version number it does support (if the server supports a range of
            versions higher than the client's requested version, the server
            returns the lowest of that supported range; if the server supports
            a range of versions lower than the client's requested version, the
            server returns the highest of that supported range).</t>

            <t>If the client receives an UNSUPP_VERSION result containing a
            version it does support, it records this fact and proceeds to use
            this message version for subsequent communication with this PCP
            server (until a possible future UNSUPP_VERSION response if the
            server is later updated, at which point the version negotiation
            process repeats).</t>

<!--
            <t>If the client receives an UNSUPP_VERSION result containing a
            version it does not support then the client MAY log an error
            message to inform the user that it is too old to work with this
            server, and the client SHOULD set a timer to retry its request in
            30 minutes or the returned Lifetime value, whichever is
            smaller.  By automatically retrying in 30 minutes, the protocol
            accommodates an upgrade of the PCP server.</t>
-->

            <t>If the client receives an UNSUPP_VERSION result
            containing a version it does not support then the client
            SHOULD try the next-lower version supported by the client.
            The attempt to use the next-lower version repeats until
            the client has tried version 2.  If using version 2 fails,
            the client MAY log an error message to inform the user
            that it is too old to work with this server, and the
            client SHOULD set a timer to retry its request in 30
            minutes or the returned Lifetime value, whichever is
            smaller.  By automatically retrying in 30 minutes, the
            protocol accommodates an upgrade of the PCP server.</t>
          </list></t>

    </section>

    <?rfc needLines="8" ?>
    <section anchor="opcode_introduction" title="Introduction to MAP and PEER Opcodes">
      <t>There are four uses for the MAP and PEER Opcodes defined in this
      document:<list style="symbols">
          <t>a host operating a server and wanting an incoming connection
            (<xref target="operating_a_server"></xref>);</t>
          <t>a host operating a client and server on the same port
            (<xref target="pcp_symmetric"></xref>);</t>
          <t>a host operating a client and wanting to optimize the application
            keepalive traffic (<xref target="keepalives"></xref>);</t>
          <t>and a host operating a client and wanting to restore lost state
            in its NAT (<xref target="restoring"></xref>).</t>
          </list></t>
      <t>These are discussed in the following sections, and a
      (non-normative) state diagram is provided
      in <xref target="state_section"></xref>.</t>

      <t>When operating a server
      (<xref target="operating_a_server"></xref>
      and <xref target="pcp_symmetric"></xref>) the PCP client knows
      if it wants an IPv4 listener, IPv6 listener, or both on the
      Internet. The PCP client also knows if it has an IPv4 address or
      IPv6 address configured on one of its interfaces.  It takes the
      union of this knowledge to decide to which of its PCP servers to
      send the request (e.g., an IPv4 address or an IPv6 address), and 
      if to send one or two MAP requests for
      each of its interfaces (e.g., if the PCP client has only an IPv4
      address but wants both IPv6 and IPv4 listeners, it sends a MAP
      request containing the all-zeros IPv6 address in the Suggested
      External Address field, and sends a second MAP request containing
      the all-zeros IPv4 address in the Suggested External Address field.
      If the PCP
      client has both an IPv4 and IPv6 address, and only wants an IPv4
      listener, it sends one MAP request from its IPv4 address (if
      the PCP server supports NAT44 or IPv4 firewall) or one MAP
      request from its IPv6 address (if the PCP server supports
      NAT64). The PCP client can simply request the desired mapping
      to determine if the PCP server supports the desired
      mapping. Applications that embed IP addresses in payloads (e.g.,
      FTP, SIP) will find it beneficial to avoid address family
      translation, if possible.</t>

      <t>The MAP and PEER requests include a Suggested External IP
      Address field.  Some PCP-controlled devices, especially CGN but
      also multi-homed NPTv6 networks, have a pool of public-facing IP
      addresses.  PCP allows the client to indicate if it wants a
      mapping assigned on a specific address of that pool or any
      address of that pool.  Some applications will break if mappings
      are created on different IP addresses (e.g., active mode FTP),
      so applications should carefully consider the implications of
      using this capability.  Static mappings for that Internal
      Address (e.g., those created by a command-line interface on the
      PCP server or PCP-controlled device) may exist to a certain
      External Address, and if the Suggested External IP Address is
      the all-zeros address, PCP SHOULD assign its mappings to the same
      External Address, as this can also help applications using a mix
      of both static mappings and PCP-created mappings.  If, on the other
      hand, the Suggested External IP Address contains a non-zero IP address
      the PCP Server SHOULD create a mapping to that external address, even if
      there are other mappings from that same Internal Address to a
      different External Address.
      Once an
      Internal Address has no implicit dynamic mappings and no
      explicit dynamic mappings in the PCP-controlled device, a
      subsequent implicit or explicit mapping for that Internal
      Address MAY be assigned to a different External
      Address. Generally, this re-assignment would occur when a CGN
      device is load balancing newly-seen Internal Addresses to its
      public pool of External Addresses.</t>

      <!--
        <t>On many common platforms (i.e., those making use of the BSD sockets
        API), using PCP for purposes of application keepalives by issuing a
        PCP request followed by a dynamic connection to the server is
        difficult to implement properly. This is therefore NOT RECOMMENDED.
        Instead, client applications SHOULD first establish a dynamic
        connection to a server, and then issue a PCP request related to that
        connection, including the REMOTE_PEER Option.</t>
-->

      <?rfc needLines="30" ?>
      <t>The following table summarizes how various common PCP deployments use
      IPv6 and IPv4 addresses.</t>
      <t>The 'internal' address is implicitly the same
      as the source IP address of the PCP request, except when the THIRD_PARTY
      option is used.</t>
      <t>The 'external' address is the Suggested External Address field of the
      MAP or PEER request, and is address family is usually the same as the
      'internal' address family, except when technologies like NAT64 are
      used.</t>
      <t>The 'remote peer' address is the Remote Peer IP Address of the PEER
      request or the FILTER option of the MAP request, and is always the same
      address family as the 'internal' address, even when NAT64 is used.</t>
      <figure align="left" anchor="AF_diagram" title="Address Families with MAP and PEER">
<preamble>In NAT64, the IPv6 PCP client is not necessarily aware of the NAT64
   or aware of the actual IPv4 address of the remote peer, so it
   expresses the IPv6 address from its perspective, as shown in the
   table.</preamble>
        <artwork align="center">
              internal  external  PCP remote peer  actual remote peer
              --------  -------   ---------------  ------------------
IPv4 firewall   IPv4      IPv4         IPv4              IPv4
IPv6 firewall   IPv6      IPv6         IPv6              IPv6 
        NAT44   IPv4      IPv4         IPv4              IPv4
        NAT46   IPv4      IPv6         IPv4              IPv6
        NAT64   IPv6      IPv4         IPv6              IPv4
        NPTv6   IPv6      IPv6         IPv6              IPv6
</artwork>
      </figure>

<!--  moved
        <t>PCP MAP and PEER requests cannot delete or shorten the lifetime of an
        existing implicit outbound mapping for the indicated internal address and port.
        PCP MAP requests can delete or shorten
        the lifetime of an existing explicit dynamic inbound mapping, but cannot affect
        the lifetime of an existing explicit static inbound mapping.</t>
-->

      <section anchor="operating_a_server" title="For Operating a Server">
        <t>A host operating a server (e.g., a web server) listens for traffic
        on a port, but the server never initiates traffic from that port. For
        this to work across a NAT or a firewall, the host needs to (a) create
        a mapping from a public IP address, protocol, and port to itself as described in
        <xref target="map_opcodes"></xref>, (b) publish that public IP
        address, protocol, and port via some sort of rendezvous server (e.g., DNS, a SIP
        message, a proprietary protocol), and (c) ensure that any other
        non-PCP-speaking packet filtering middleboxes on the path (e.g.,
        host-based firewall, network-based firewall, or other NATs) will also
        allow the incoming traffic.  Publishing the public IP address and
        port is out of scope of this specification. To accomplish (a), the
        host follows the procedures described in this section.</t>

        <t>As normal, the application needs to begin listening on a port.
        Then, the application constructs a PCP message with the MAP Opcode,
        with the external address set to the appropriate all-zeroes address,
        depending on whether it wants a public IPv4 or IPv6 address.</t>

        <figure align="left" anchor="fig_operate_server" title="Pseudo-code for using PCP to operate a server">
          <preamble>The following pseudo-code shows how PCP can be reliably
          used to operate a server:</preamble>

          <artwork align="center"><![CDATA[
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);

getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));

while (1)
    {
    /* Note: The "time_to_send_pcp_request()" check below includes:
     * 1. Sending the first request
     * 2. Retransmitting requests due to packet loss
     * 3. Resending a request due to impending lease expiration
     * 4. Resending a request due to server state loss
     * The PCP packet sent is identical in all four cases; from
     * the PCP server's point of view they are the same operation.
     * The Suggested External Address and Port may be updated
     * repeatedly during the lifetime of the mapping.
     * Other fields in the packet generally remain unchanged.
     */
    if (time_to_send_pcp_request())
        pcp_send_map_request(internal_sockaddr.sin_port,
            internal_sockaddr.sin_addr,
            &external_sockaddr, /* will be zero the first time */
            requested_lifetime, &assigned_lifetime);

    if (pcp_response_received())
        update_rendezvous_server("Client Ident", external_sockaddr);

    if (received_incoming_connection_or_packet())
        process_it(s);

    if (other_work_to_do())
        do_it();

    /* ... */

    block_until_we_need_to_do_something_else();
    }]]></artwork>
        </figure>
      </section>

      <section anchor="pcp_symmetric" title="For Operating a Symmetric Client/Server">
        <t>A host operating a client and server on the same port (e.g.,
        <xref target="RFC4961">Symmetric RTP</xref> or <xref target="RFC3581">SIP
        Symmetric Response Routing (rport)</xref>) first establishes a local
        listener, (usually) sends the local and public IP addresses, protocol, and ports
        to a rendezvous service (which is out of scope of this document), and
        initiates an outbound connection from that same source address and
        same port. To accomplish this, the application uses the procedure
        described in this section.</t>

        <t>An application that is using the same port for outgoing connections
        as well as incoming connections MUST first signal its operation of a
        server using the PCP MAP Opcode, as described in
        <xref target="map_opcodes"></xref>, and receive a positive PCP response
        before it sends any packets from that port. <list style="empty">
            <t>Discussion: In general, a PCP client doesn't know in
            advance if it is behind a NAT or firewall. On detecting
            the host has connected to a new network, the PCP client
            can attempt to request a mapping using PCP, and if that
            succeeds then the client knows it has successfully created
            a mapping. If after multiple retries it has received no
            PCP response, then either the client is *not* behind a NAT
            or firewall and has unfettered connectivity, or the client
            *is* behind a NAT or firewall which doesn't support PCP
            (and the client may still have working connectivity by
            virtue of static mappings previously created manually by
            the user).  Retransmitting PCP requests multiple times
            before giving up and assuming unfettered connectivity adds
            delay in that case.  Initiating outbound TCP connections
            immediately without waiting for PCP avoids this delay, and
            will work if the NAT has endpoint-independent mapping
            EIM behavior, but may fail if the NAT has
            endpoint-dependent mapping EDM behavior.
            Waiting enough time to allow an explicit PCP MAP
            Mapping to be created (if possible) first ensures that the
            same External Port will then be used for all subsequent
            implicit dynamic mappings (e.g., TCP SYNs) sent from the specified Internal Address, Protocol, and 
            Port.  PCP supports both EIM and EDM NATs, so clients need
            to assume they may be dealing with an EDM NAT.  In this
            case, the client will experience more reliable
            connectivity if it attempts explicit PCP MAP requests
            first, before initiating any outbound TCP connections from
            that Internal Address and Port. See
            also <xref target="EDM"></xref>.</t>
          </list></t>

        <?rfc needLines="47" ?>
        <figure align="left" anchor="fig_pseudocode_symmetric" title="Pseudo-code for using PCP to operate a symmetric client/server">
          <preamble>The following pseudo-code shows how PCP can be used to
          operate a symmetric client and server:</preamble>

          <artwork align="center"><![CDATA[
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);

getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));

while (1)
    {
    /* Note: The "time_to_send_pcp_request()" check below includes:
     * 1. Sending the first request
     * 2. Retransmitting requests due to packet loss
     * 3. Resending a request due to impending lease expiration
     * 4. Resending a request due to server state loss
     */
    if (time_to_send_pcp_request())
        pcp_send_map_request(internal_sockaddr.sin_port,
            internal_sockaddr.sin_addr,
            &external_sockaddr, /* will be zero the first time */
            requested_lifetime, &assigned_lifetime);

    if (pcp_response_received())
        update_rendezvous_server("Client Ident", external_sockaddr);

    if (received_incoming_connection_or_packet())
        process_it(s);

    if (need_to_make_outgoing_connection())
        make_outgoing_connection(s, ...);

    if (data_to_send())
        send_it(s);

    if (other_work_to_do())
        do_it();

    /* ... */

    block_until_we_need_to_do_something_else();
    }]]></artwork>

          <postamble></postamble>
        </figure>
      </section>

      <section anchor="keepalives" title="For Reducing NAT or Firewall Keepalive Messages">
        <t>A host operating a client (e.g., XMPP client, SIP client) sends
        from a port, and may receive responses, but never accepts incoming
        connections from other Remote Peers on this port. It wants to ensure
        the flow to its Remote Peer is not terminated (due to inactivity) by
        an on-path NAT or firewall. To accomplish this, the application uses
        the procedure described in this section.</t>

        <t>Middleboxes such as NATs or firewalls need to see occasional
        traffic or will terminate their session state, causing application
        failures. To avoid this, many applications routinely generate
        keepalive traffic for the primary (or sole) purpose of maintaining
        state with such middleboxes. Applications can reduce such application
        keepalive traffic by using PCP. <list style="empty">
            <t>Note: For reasons beyond NAT, an application may find it useful
            to perform application-level keepalives, such as to detect a
            broken path between the client and server, keep state alive on the
            Remote Peer, or detect a powered-down client. These keepalives are
            not related to maintaining middlebox state, and PCP cannot do
            anything useful to reduce those keepalives.</t>
          </list></t>

        <t>To use PCP for this function, the application first
        connects to its server, as normal. Afterwards, it issues a PCP
        request with the PEER Opcode as described
        in <xref target="peer_opcodes"></xref>.</t>

        <figure align="left" anchor="fig_keepalive_pseudocode" title="Pseudo-code using PCP with a dynamic socket">
          <preamble>The following pseudo-code shows how PCP can be reliably
          used with a dynamic socket, for the purposes of reducing application
          keepalive messages:</preamble>

          <artwork align="center"><![CDATA[
int s = socket(...);
connect(s, &remote_peer, ...);

getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));

while (1)
    {
    /* Note: The "time_to_send_pcp_request()" check below includes:
     * 1. Sending the first request
     * 2. Retransmitting requests due to packet loss
     * 3. Resending a request due to impending lease expiration
     * 4. Resending a request due to server state loss
     */
    if (time_to_send_pcp_request())
        pcp_send_peer_request(internal_sockaddr.sin_port,
            internal_sockaddr.sin_addr,
            &external_sockaddr, /* will be zero the first time */
            remote_peer, requested_lifetime, &assigned_lifetime);

    if (data_to_send())
        send_it(s);

    if (other_work_to_do())
        do_it();

    /* ... */

    block_until_we_need_to_do_something_else();
    }]]></artwork>
        </figure>
      </section>

      <section anchor="restoring" title="For Restoring Lost Implicit TCP Dynamic Mapping State">
        <t>After a NAT loses state (e.g., because of a crash or power
        failure), it is useful for clients to re-establish TCP mappings on the
        NAT. This allows servers on the Internet to see traffic from the same
        IP address and port, so that sessions can be resumed exactly where
        they were left off. This can be useful for long-lived connections
        (e.g., instant messaging) or for connections transferring a lot of
        data (e.g., FTP). This can be accomplished by first establishing a TCP
        connection normally and then sending a PEER request/response and
        remembering the External Address and External Port. Later, when the NAT
        has lost state, the client can send a PEER request with the Suggested
        External Port and Suggested External Address remembered from the
        previous session, which will create a mapping in the NAT that
        functions exactly as an implicit dynamic mapping. The client then
        resumes sending TCP data to the server. <list style="empty">
            <t>Note: This procedure works well for TCP, provided the NAT
            creates a new implicit dynamic outbound mapping only for TCP segments with the
            SYN bit set (i.e., the newly-booted NAT drops the re-transmitted
            data segments from the client because the NAT does not have an
            active mapping for those segments), and if the server is not
            sending data that elicits a RST from the NAT. This is not the case
            for UDP, because a new UDP mapping will be created (probably on a
            different port) as soon as UDP traffic is seen by the NAT.</t>
          </list></t>
      </section>


    </section>

    <section anchor="map_opcodes" title="MAP Opcode">
      <t>This section defines an Opcode which controls forwarding from a NAT
      (or firewall) to an Internal Host.<list hangIndent="8" style="hanging">
          <t hangText="  MAP:">Create an explicit dynamic mapping between an
          Internal Address + Port and an External Address + Port.</t>
        </list></t>

      <t>PCP Servers SHOULD
      provide a configuration option to allow administrators to disable MAP
      support if they wish.</t>

      <t>Mappings created by PCP MAP requests are, by definition,
      Endpoint Independent Mappings (EIM) with Endpoint Independent
      Filtering (EIF) (unless the FILTER Option is used), even on a NAT
      that usually creates Endpoint Dependent Mappings (EDM) or Endpoint
      Dependent Filtering (EDF) for outgoing connections, since the
      purpose of an (unfiltered) MAP mapping is to receive inbound
      traffic from any remote endpoint, not from only one specific
      remote endpoint.</t>

      <t>Note also that all NAT mappings (created by PCP or otherwise) are by
      necessity bidirectional and symmetric. For any packet going in one
      direction (in or out) that is translated by the NAT, a reply going in
      the opposite direction needs to have the corresponding opposite
      translation done so that the reply arrives at the right endpoint. This
      means that if a client creates a MAP mapping, and then later
      sends an outgoing packet using the mapping's Internal Address, Protocol
      and Port, the NAT should translate that packet's Internal Address
      and Port to the mapping's External Address and Port, so that replies
      addressed to the External Address and Port are correctly translated
      back to the mapping's Internal Address and Port.</t>

      <t>On Operating Systems that allow multiple listening servers to
      bind to the same internal address, protocol and port, servers MUST ensure that they
      have exclusive use of that internal address, protocol and port (e.g., by binding the
      port using INADDR_ANY, or using SO_EXCLUSIVEADDRUSE or similar)
      before sending their PCP MAP request, to ensure that no other
      PCP clients on the same machine are also listening on the same
      internal protocol and internal port.</t>

      <t>As a side-effect of creating a mapping, ICMP messages associated
      with the mapping MUST be forwarded (and also translated, if
      appropriate) for the duration of the mapping's lifetime. This is done
      to ensure that ICMP messages can still be used by hosts, without
      application programmers or PCP client implementations needing to
      use PCP separately to create ICMP mappings for those flows.</t>

      <t>The operation of the MAP Opcode is described in this section.</t>

      <section anchor="MAPPacket" title="MAP Operation Packet Formats">
        <t>The MAP Opcode has a similar packet layout for
        both requests and responses.  If the Assigned External IP address and
        Port in the PCP response always match the Internal IP Address
        and Port from the PCP request, then the
        functionality is purely a firewall; otherwise it pertains to a network
        address translator which might also perform firewall-like
        functions.</t>

        <figure align="left" anchor="map_request" title="MAP Opcode Request">
          <preamble>The following diagram shows the format of the
          Opcode-specific information in a request for the MAP Opcode.
          </preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 bits)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 bits)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Suggested External Port    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           Suggested External IP Address (128 bits)            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <?rfc needLines="4" ?>
        <t>These fields are described below:<list style="hanging">
            <t hangText="Requested lifetime (in common header):">Requested
            lifetime of this mapping, in seconds. The value 0 indicates
            "delete".</t>

            <t hangText="Mapping Nonce:">Random value chosen by the PCP client.
            See <xref target="map_opcode_client_operation"/>.
            Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).</t>

            <t hangText="Protocol:">Upper-layer protocol associated with this
            Opcode. Values are taken from the
            <xref target="proto_numbers">IANA protocol registry</xref>. For example,
            this field contains 6 (TCP) if the Opcode is intended to create a
            TCP mapping. The value 0 has a special meaning for 'all
            protocols'.</t>

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

            <t hangText="Internal Port:">Internal port for the mapping. The
            value 0 indicates 'all ports', and is legal when the lifetime
            is zero (a delete request), if the Protocol does not use
            16-bit port numbers, or the client is requesting 'all ports'.
            If Protocol is zero (meaning 'all protocols'), then Internal Port
            MUST be zero on transmission and MUST be ignored on reception.</t>

            <t hangText="Suggested External Port:">Suggested external port for
            the mapping. This is useful for refreshing a mapping, especially
            after the PCP server loses state. If the PCP client does not know
            the external port, or does not have a preference, it MUST use
            0.</t>

            <t hangText="Suggested External IP Address:">Suggested external
            IPv4 or IPv6 address. This is useful for refreshing a mapping,
            especially after the PCP server loses state. If the PCP client
            does not know the external address, or does not have a preference,
            it MUST use the address-family-specific all-zeroes address (see
            <xref target="fixed-size-addr"/>).</t>
          </list></t>

        <t>The internal address for the request is the source IP address of
        the PCP request message itself, unless the THIRD_PARTY Option is
        used.</t>

        <figure align="left" anchor="map_response" title="MAP Opcode Response">
          <preamble>The following diagram shows the format of Opcode-specific
          information in a response packet for the MAP Opcode:</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 bits)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 bits)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Assigned External Port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            Assigned External IP Address (128 bits)            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>These fields are described below:<list style="hanging">
            <t hangText="Lifetime (in common header):">On an error
            response, this indicates how long clients should assume
            they'll get the same error response from the PCP server if
            they repeat the same request. On a success response, this
            indicates the lifetime for this mapping, in seconds.</t>

            <t hangText="Mapping Nonce:">Copied from the request.</t>

            <t hangText="Protocol:">Copied from the request.</t>

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

            <t hangText="Internal Port:">Copied from the request.</t>

            <t hangText="Assigned External Port:">On a success response, this
            is the assigned external port for the mapping. On an error
            response, the Suggested External Port is copied from the
            request.</t>

            <t hangText="Assigned External IP Address:">On a success response,
            this is the assigned external IPv4 or IPv6 address for the
            mapping.  An IPv4 address is encoded using IPv4-mapped IPv6
            address.  On an
            error response, the Suggested External IP Address is copied from
            the request.</t>
          </list></t>
      </section>


      <section anchor="map_opcode_client_operation" title="Generating a MAP Request">
        <t>This section describes the
        operation of a PCP client when sending requests with the MAP Opcode.</t>

        <t>The request MAY contain values in the Suggested External Port and
        Suggested External IP Address fields. This allows the PCP client to
        attempt to rebuild lost state on the PCP server, which improves the
        chances of existing connections surviving, and helps the PCP client
        avoid having to change information maintained at its rendezvous
        server. Of course, due to other activity on the network (e.g., by
        other users or network renumbering), the PCP server may not be able to
        grant the suggested External IP Address, Protocol, and Port, and in that case it
        will assign a different External IP Address and Port.</t>

        <t>A PCP client MUST be written assuming that it may *never* be
        assigned the external port it suggests. In the case of recreating state
        after a NAT gateway crash, the Suggested External Port, being one that
        was previously allocated to this client, is likely to be available for
        this client to continue using. In all other cases, the client MUST
        assume that it is unlikely that its Suggested External Port will be
        granted. For example, when many subscribers are sharing a Carrier-Grade
        NAT, popular ports such as 80, 443 and 8080 are likely to be in high
        demand. At most one client can have each of those popular ports for
        each External IP Address, and all the other clients will be assigned
        other, dynamically allocated, External Ports. Indeed, some ISPs may, by
        policy, choose not to grant those External Ports to *anyone*, so that none
        of their clients are *ever* assigned External Ports 80, 443 or 8080. </t>

<t>If the Protocol does not use 16-bit port numbers (e.g., RSVP, IP protocol number 46),
the port number MUST be zero.  This will cause all traffic matching
that protocol to be mapped.</t>

<t>If the client wants all protocols mapped it uses Protocol 0 (zero)
and Internal Port 0 (zero).</t>

        <t>The Mapping Nonce value is randomly chosen by the PCP client, following
        <xref target="RFC4086">accepted practices for generating unguessable random numbers</xref>,
        and is used as part of the validation of PCP responses (see
        below) by the PCP client, and validation for mapping refreshes
        by the PCP server.  The client MUST use a different Mapping
        Nonce for each PCP server it communicates with, and it is
        RECOMMENDED to choose a new random Mapping Nonce whenever the
        PCP client is initialized.  The client MAY use a different
        Mapping Nonce for every mapping.</t>

        <section anchor="renewal" title="Renewing a Mapping">
        <t>An existing mapping can have its lifetime extended by the PCP
        client. To do this, the PCP client sends a new MAP request indicating
        the internal port. The PCP MAP request SHOULD also include the
        currently assigned external IP address and port in the Suggested
        External IP address and Suggested External Port fields, so if the PCP server has lost
        state it can recreate the lost mapping with the same parameters.</t>

        <t>The PCP client SHOULD renew the mapping before its expiry
        time, otherwise it will be removed by the PCP server
        (see <xref target="lifetime"></xref>).  To reduce the risk of
        inadvertent synchronization of renewal requests, a random
        jitter component should be included. It is RECOMMENDED that
        PCP clients send a single renewal request packet at a time
        chosen with uniform random distribution in the range 1/2 to
        5/8 of expiration time.  If no SUCCESS response is received,
        then the next renewal request should be sent 3/4 to 3/4 + 1/16
        to expiration, and then another 7/8 to 7/8 + 1/32 to
        expiration, and so on, subject to the constraint that renewal
        requests MUST NOT be sent less than four seconds apart (a PCP
        client MUST NOT send a flood of ever-closer-together requests
        in the last few seconds before a mapping expires).</t>
        </section>
      </section>

      <section anchor="map-opcode_server_operation" title="Processing a MAP Request">
        <t>This section describes the
        operation of a PCP server when processing a request with the MAP
        Opcode. Processing SHOULD be performed in the order of the following
        paragraphs.</t>

        <t>The Protocol, Internal Port, and Mapping Nonce fields from
        the MAP request are copied into the MAP response. If present
        and processed by the PCP server the THIRD_PARTY Option is also
        copied into the MAP response.</t>

        <t>If the Requested Lifetime is non-zero then:<list style="symbols">
            <t>If both the protocol and internal port are non-zero, it
            indicates a request to create a mapping or extend the
            lifetime of an existing mapping.  If the PCP server or
            PCP-controlled device does not support the Protocol, the
            UNSUPP_PROTOCOL error MUST be returned.</t>

            <t>If the protocol is non-zero and the internal port is
            zero, it indicates a request to create or extend a mapping
            for all incoming traffic for that entire Protocol. If this
            request cannot be fulfilled in its entirety, the
            UNSUPP_PROTOCOL error MUST be returned.</t>


            <t>If both the protocol and internal port are zero, it
            indicates a request to create or extend a mapping for all
            incoming traffic for all protocols (commonly called a "DMZ host").
            If this request cannot be fulfilled in its entirety, the
            UNSUPP_PROTOCOL error MUST be returned.</t>

            <t>If the protocol is zero and the internal port is non-zero,
            then the request is invalid and the PCP Server MUST return
            a MALFORMED_REQUEST error to the client.</t>
          </list></t>

        <t>If the requested lifetime is zero, it indicates a request to
        delete an existing mapping.</t>

        <t>Further processing of the
        lifetime is described in <xref target="lifetime"></xref>.</t>

        <t>If operating in the <xref target="SimpleThreat">Simple
Threat Model</xref>, and the Internal port, Protocol, and Internal
Address match an existing explicit dynamic mapping, but the Mapping
Nonce does not match, the request MUST be rejected with a
NOT_AUTHORIZED error with the Lifetime of the error indicating
duration of that existing mapping.  The PCP server only needs to
remember one Mapping Nonce value for each explicit dynamic
mapping.</t>

<t>If the Internal port, Protocol, and Internal Address match an
existing static mapping (which will have no nonce) then a PCP reply is
sent giving the External Address and Port of that static mapping,
using the nonce from the PCP request. The server does not record the
nonce.</t>

        <t>If an Option with value less than 128 exists (i.e., mandatory to
        process) but that Option does not make sense (e.g., the PREFER_FAILURE
        Option is included in a request with lifetime=0), the request is
        invalid and generates a MALFORMED_OPTION error.</t>

        <t>If the PCP-controlled device is stateless (that is, it does not
        establish any per-flow state, and simply rewrites the address and/or
        port in a purely algorithmic fashion), the PCP server simply returns
        an answer indicating the external IP address and port yielded by this
        stateless algorithmic translation. This allows the PCP client to learn
        its external IP address and port as seen by remote peers. Examples of
        stateless translators include stateless NAT64, 1:1 NAT44, and
        <xref target="RFC6296">NPTv6</xref>, all of which modify addresses but
        not port numbers.</t>


<!--  text from -22 is here, commented out.

        <t>It is possible that a mapping might already exist for a
        requested Internal Address and Port, for example because of a
        previous MAP request, or an implicit dynamic mapping (e.g.,
        created by TCP SYN), or other
        reasons.  If an explicit inbound mapping (created by MAP) already exists for the requested
        Internal Address and Port and the PREFER_FAILURE Option is not
        present, the PCP server makes this a MAP-managed mapping and
        MUST refresh (i.e., extend) the lifetime of that
        already-existing mapping, and return the already-existing
        External Address and Port in its response, regardless of the
        Suggested External Address and Port in the request.  If a
        mapping already exists for the requested Internal Address and
        Port and the request contains the PREFER_FAILURE Option, but
        the Suggested External Address and Port do not match the
        actual External Address and Port of the already existing
        mapping, the error CANNOT_PROVIDE_EXTERNAL is returned.  If an
        implicit outbound mapping (e.g., created by PEER or created by
        a TCP SYN) already exists for the requested
        Internal Address and Port, a new explicit mapping should be
        made replicating the ports and addresses from the implicit
        outbound mapping (but the implicit outbound mapping continues
        to exist, and remains in effect if the explicit mapping is
        later deleted).</t>
-->


<t>
   It is possible that a mapping might already exist for a requested
   Internal Address, Protocol, and Port.  If so, the PCP server takes the
   following actions:
<list style="numbers">
<t>If the MAP request contains the PREFER_FAILURE Option, but the
      Suggested External Address and Port do not match the External
      Address and Port of the existing mapping, the PCP server MUST
      return CANNOT_PROVIDE_EXTERNAL.</t>
   
<t>If the existing mapping is static (created outside of PCP), the PCP
      server MUST return the External Address and Port of the existing
      mapping in its response and SHOULD indicate a Lifetime of 2^32-1
      seconds, regardless of the Suggested External Address and
      Port in the request.</t>
   
<t>If the existing mapping is explicit dynamic inbound (created by a
      previous MAP request), the PCP server MUST return the existing
      External Address and Port in its response, regardless of the
      Suggested External Address and Port in the request.  Additionally,
      the PCP server MUST update the lifetime of the existing mapping, in
      accordance with section 10.5.</t>
   
<t>If the existing mapping is dynamic outbound (created by outgoing
      traffic or a previous PEER request), the PCP server SHOULD create a
      new explicit inbound mapping, replicating the ports and addresses
      from the outbound mapping (but the outbound mapping continues to
      exist, and remains in effect if the explicit inbound mapping is
      later deleted).</t>
</list>   
</t>

        <t>If no mapping exists for the Internal Address, Protocol, and Port,
        and the PCP server is able to create a mapping using the Suggested
        External Address and Port, it SHOULD do so. This is beneficial
        for re-establishing state lost in the PCP server (e.g., due to
        a reboot). There are, however, cases where the PCP server is not able
        to create a new mapping using the Suggested External Address and Port:
        <list style="symbols">

            <t>The Suggested External Address, Protocol, and Port is already
            assigned to another existing explicit or implicit mapping (i.e., is
            already forwarding traffic to some other internal address and
            port).</t>

            <t>The Suggested External Address, Protocol, and Port is already
            used by the NAT gateway for one of its own services. For example,
            TCP port 80 for the NAT gateway's own configuration web pages, or
            UDP ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT
            create client mappings for External UDP ports 5350 or 5351.</t>

            <t>The Suggested External Address, Protocol, and Port is otherwise
            prohibited by the PCP server's policy.</t>

            <t>The Suggested External IP Address, Protocol, or
            Suggested Port are invalid or invalid combinations (e.g.,
            External Address 127.0.0.1, ::1, a multicast address, or
            the Suggested Port is not valid for the Protocol).</t>

            <t>The Suggested External Address does not belong to the
            NAT gateway.</t>

            <t>The Suggested External Address is not configured to be
            used as an external address of the firewall or NAT gateway.</t>
          </list></t>

        <t>If the PCP server cannot assign the Suggested External Address,
        Protocol, and Port, then:<list style="symbols">
          <t>If the request contained the PREFER_FAILURE Option, then the PCP
          server MUST return CANNOT_PROVIDE_EXTERNAL.</t>
          <t>If the request did not contain the PREFER_FAILURE Option, and the
          PCP server can assign some other External Address and Port for that
          protocol, then the PCP server MUST do so and return the newly assigned
          External Address and Port in the response. In no case is the client
          penalized for a 'poor' choice of Suggested External Address and Port.
          The Suggested External Address and Port may be used by the server to
          guide its choice of what External Address and Port to assign, but in
          no case do they cause the server to fail to allocate an External
          Address and Port where otherwise it would have succeeded. The
          presence of a non-zero Suggested External Address or Port is
          merely a hint; it never does any harm.</t>
        </list></t>

        <t>By default, a PCP-controlled device MUST NOT create mappings for a
        protocol not indicated in the request. For example, if the request was
        for a TCP mapping, a UDP mapping MUST NOT be created.</t>

<!--
All of this is discussed in the section for THIRD_PARTY option;
shouldn't be here.
        <t>If the THIRD_PARTY Option is not present in the request, the source
        IP address of the PCP packet is used as the Internal Address for the
        mapping. If the THIRD_PARTY Option is present, the PCP server
        validates that the client is authorized to make mappings on behalf of
        the indicated Internal IP Address. This validation depends on the PCP
        deployment scenario; see <xref target="DSLiteDeployment"></xref> for
        an example validation procedure. If the source IP address of the PCP
        request is not authorized to make mappings on behalf of the indicated
        internal IP address, an error response MUST be generated with result
        code NOT_AUTHORIZED.</t>
-->

        <t>Mappings typically consume state on the PCP-controlled device, and
        it is RECOMMENDED that a per-host and/or per-subscriber limit be
        enforced by the PCP server to prevent exhausting the mapping state. If
        this limit is exceeded, the result code USER_EX_QUOTA is returned.</t>

        <t>If all of the preceding operations were successful (did not
        generate an error response), then the requested mapping is created or
        refreshed as described in the request and a SUCCESS response is built.</t>
      </section>

      <section title="Processing a MAP Response">
        <t>This section describes the operation of the PCP client when it
        receives a PCP response for the MAP Opcode.</t>

        <t>After performing common PCP response processing, the
        response is further matched with a previously-sent MAP request
        by comparing the Internal IP Address (the destination IP
        address of the PCP response, or other IP address specified via
        the THIRD_PARTY option), the Protocol, the Internal Port, and
        the Mapping Nonce.  Other fields are not compared, because the
        PCP server sets those fields.  The PCP server will send a
        <xref target="update">Mapping Update</xref> if the mapping changes
        (e.g., due to IP renumbering).</t>

        <t>If the result code is NO_RESOURCES and the request was for
        the creation or renewal of a mapping, then the PCP client
        SHOULD NOT send further requests for any new mappings to that
        PCP server for the (limited) value of the Lifetime.  If the
        result code is NO_RESOURCES and the request was for the
        deletion of a mapping, then the PCP client SHOULD NOT send
        further requests of *any kind* to that PCP server for the
        (limited) value of the Lifetime.</t>

        <t>On a success response, the PCP client can use the External
        IP Address and Port as needed.  Typically the PCP client will
        communicate the External IP Address and Port to another host
        on the Internet using an application-specific rendezvous
        mechanism such as DNS SRV records.</t>

        <t>As long as renewal is desired, the PCP client MUST also set a timer or otherwise schedule an event
        to renew the mapping before its lifetime expires. Renewing a mapping
        is performed by sending another MAP request, exactly as described
        in <xref target="map_opcode_client_operation"></xref>, except that the
        Suggested External Address and Port SHOULD be set to the values
        received in the response. From the PCP server's point of view a MAP
        request to renew a mapping is identical to a MAP request to create a
        new mapping, and is handled identically.  Indeed, in the event of PCP
        server state loss, a renewal request from a PCP client will appear to
        the server to be a request to create a new mapping, with a particular
        Suggested External Address and Port, which happens to be what the PCP
        server previously assigned. See also <xref target="reboot"></xref>.</t>

        <t>On an error response, the client SHOULD NOT repeat the same request
        to the same PCP server within the lifetime returned in the
        response.</t>
      </section>

      <section anchor="renumbering" title="Address Change Events">
        <t>A customer premises router might obtain a new External IP address, for a
        variety of reasons including a reboot, power outage, DHCP lease
        expiry, or other action by the ISP. If this occurs, traffic forwarded
        to the host's previous address might be delivered to another host
        which now has that address. This affects all mapping types, whether
        implicit or explicit. This same problem
        already occurs today when a host's IP address is re-assigned, without
        PCP and without an ISP-operated CGN. The solution is the same as
        today: the problems associated with host renumbering are caused by
        host renumbering, and are eliminated if host renumbering is avoided.
        PCP defined in this document does not provide machinery to reduce the
        host renumbering problem.</t>

        <t>When an Internal Host changes its Internal IP address (e.g., by having a
        different address assigned by the DHCP server) the NAT (or firewall)
        will continue to send traffic to the old IP address. Typically, the
        Internal Host will no longer receive traffic sent to that old IP
        address. Assuming the Internal Host wants to continue receiving
        traffic, it needs to install new mappings for its new IP address. The
        suggested external port field will not be fulfilled by the PCP server,
        in all likelihood, because it is still being forwarded to the old IP
        address. Thus, a mapping is likely to be assigned a new External Port
        number and/or External IP Address. Note that such host renumbering is
        not expected to happen routinely on a regular basis for most hosts,
        since most hosts renew their DHCP leases before they expire (or
        re-request the same address after reboot) and most DHCP servers honor
        such requests and grant the host the same address it was previously
        using before the reboot.</t>

        <t>A host might gain or lose interfaces while existing mappings are
        active (e.g., Ethernet cable plugged in or removed, joining/leaving a
        Wi-Fi network). Because of this, if the PCP client is sending a PCP
        request to maintain state in the PCP server, it SHOULD ensure those
        PCP requests continue to use the same interface (e.g., when refreshing
        mappings). If the PCP client is sending a PCP request to create new
        state in the PCP server, it MAY use a different source interface or
        different source address.</t>
      </section>

      <section title="Learning the External IP Address Alone" anchor="alone">
        <t><xref target="I-D.cheshire-nat-pmp">NAT-PMP</xref> includes
        a mechanism to allow clients to learn the External IP Address
        alone, without also requesting a port mapping. NAT-PMP was designed
        for residential NAT gateways, where such an operation makes sense
        because the residential NAT gateway has only one External IP Address.
        PCP has broader scope, and also supports Carrier-Grade
        NATs (CGN) which may have a pool of External IP Addresses,
        not just one. A client may not be assigned any particular
        External IP Address from that pool until it has at least
        one implicit, explicit or static port mapping, and even
        then only for as long as that mapping remains valid.
        Client software that just wishes to display the user's External
        IP Address for cosmetic purposes can achieve that by requesting
        a short-lived mapping
        (e.g., to the Discard service (TCP/9 or UDP/9) or some other port)
        and then displaying the resulting External
        IP Address.  However, once that mapping expires a subsequent
        implicit or explicit dynamic mapping might be mapped to a
        different external IP address.</t>
      </section>
    </section>

    <section anchor="peer_opcodes" title="PEER Opcode">
      <t>This section defines an Opcode for controlling dynamic mappings.
        <list hangIndent="8" style="hanging">
          <t hangText="  PEER:">Create a new dynamic
          outbound mapping to a remote peer's IP address and port,
          or extend the lifetime of an existing outbound mapping.</t>

        </list>The use of this Opcodes is described in this section.</t>

      <t>PCP Servers SHOULD
      provide a configuration option to allow administrators to disable PEER
      support if they wish.</t>

      <t>Because a mapping created or managed by PEER behaves
      almost exactly like an implicit dynamic mapping created as a side-effect of
      a packet (e.g., TCP SYN) sent by the host,
      mappings created or managed using PCP PEER requests may be
      Endpoint Independent Mappings (EIM) or Endpoint Dependent Mappings
      (EDM), with Endpoint Independent Filtering (EIF) or Endpoint Dependent
      Filtering (EDF), consistent with the existing behavior of the NAT
      gateway or firewall in question for implicit outbound mappings it creates
      automatically as a result of observing outgoing traffic from Internal
      Hosts.</t>

      <?rfc needLines="6" ?>
      <section anchor="PEERPacket" title="PEER Operation Packet Formats">
        <t>The PEER Opcode allows a PCP client to create a new explicit
        dynamic outbound mapping (which functions similarly to an outbound mapping
        created implicitly when a host sends an outbound TCP SYN) or to
        extend the lifetime of an existing outbound mapping.</t>

        <figure align="left" anchor="peer_request" title="PEER Opcode Request">
          <preamble>The following diagram shows the Opcode layout for
          the PEER Opcode. This packet format is aligned with the response
          packet format:</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 bits)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 bits)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Suggested External Port    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           Suggested External IP Address (128 bits)            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Remote Peer Port        |     Reserved (16 bits)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Remote Peer IP Address (128 bits)               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>These fields are described below:<list style="hanging">
            <t hangText="Requested Lifetime (in common header):">Requested
            lifetime of this mapping, in seconds. Note that it is not
            possible to reduce the lifetime of a mapping (or delete it, with
            requested lifetime=0) using PEER.</t>

            <t hangText="Mapping Nonce:">Random value chosen by the PCP client.
            See <xref target="peer_opcode_client_operation"/>.
            Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).</t>

            <t hangText="Protocol:">Upper-layer protocol associated with this
            Opcode. Values are taken from the
            <xref target="proto_numbers">IANA protocol registry</xref>. For example,
            this field contains 6 (TCP) if the Opcode is describing a TCP
            mapping. Protocol MUST NOT be zero.</t>

            <t hangText="Reserved:">24 reserved bits, MUST be set to 0 on
            transmission and MUST be ignored on reception.</t>

            <t hangText="Internal Port:">Internal port for the mapping.
            Internal Port MUST NOT be zero.</t>

            <t hangText="Suggested External Port:">Suggested external port for
            the mapping. If the PCP client does not know the external port, or
            does not have a preference, it MUST use 0.</t>

            <t hangText="Suggested External IP Address:">Suggested External IP
            Address for the mapping. If the PCP client does not know the
            external address, or does not have a preference, it MUST use the
            address-family-specific all-zeroes address (see
            <xref target="fixed-size-addr"/>).</t>

            <t hangText="Remote Peer Port:">Remote peer's port for the
            mapping. Remote Peer Port MUST NOT be zero.</t>

            <t hangText="Reserved:">16 reserved bits, MUST be set to 0 on
            transmission and MUST be ignored on reception.</t>

            <t hangText="Remote Peer IP Address:">Remote peer's IP
            address. This is from the perspective of the PCP client, so that the PCP
            client does not need to concern itself with NAT64 or NAT46 (which
            both cause the client's idea of the remote peer's IP address to
            differ from the remote peer's actual IP address). This field
            allows the PCP client and PCP server to disambiguate multiple
            connections from the same port on the Internal Host to different
            servers. An IPv6 address is
            represented directly, and an IPv4 address is represented
            using the IPv4-mapped address syntax
            (<xref target="fixed-size-addr"></xref>).</t>
          </list></t>

        <t>When attempting to re-create a lost mapping, the Suggested External
        IP Address and Port are set to the External IP Address and Port fields
        received in a previous PEER response from the PCP server. On an
        initial PEER request, the External IP Address and Port are set to
        zero.</t>

        <t>Note that semantics similar to the PREFER_FAILURE option are automatically
        implied by PEER requests.  If the Suggested External IP
        Address or Suggested External Port fields are non-zero, and
        the PCP server is unable to honor the Suggested External IP
        Address, Protocol, or Port, then the PCP server MUST return a
        CANNOT_PROVIDE_EXTERNAL error response.  The
        PREFER_FAILURE Option is neither required nor allowed in PEER
        requests, and if PCP server receives a PEER request containing
        the PREFER_FAILURE Option it MUST return a MALFORMED_REQUEST
        error response.</t>

        <figure align="left" anchor="peer_response" title="PEER Opcode Response">
          <preamble>The following diagram shows the Opcode response for
          the PEER Opcode:</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 bits)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 bits)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Assigned External Port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            Assigned External IP Address (128 bits)            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Remote Peer Port        |     Reserved (16 bits)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Remote Peer IP Address (128 bits)               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="hanging">
            <t hangText="Lifetime (in common header):">On a success response,
            this indicates the lifetime for this mapping, in seconds. On an
            error response, this indicates how long clients should assume
            they'll get the same error response from the PCP server if they
            repeat the same request.</t>

            <t hangText="Mapping Nonce:">Copied from the request.</t>

            <t hangText="Protocol:">Copied from the request.</t>

            <t hangText="Reserved:">24 reserved bits, MUST be set to 0 on
            transmission, MUST be ignored on reception.</t>

            <t hangText="Internal Port:">Copied from request.</t>

            <t hangText="Assigned External Port:">On a success response, this
            is the assigned external port for the mapping. On an error
            response, the Suggested External Port is copied from the
            request.</t>

            <t hangText="Assigned External IP Address:">On a success
            response, this is the assigned external IPv4 or IPv6
            address for the mapping.  On an error response, the
            Suggested External IP Address is copied from the
            request.</t>

            <t hangText="Remote Peer port:">Copied from request.</t>

            <t hangText="Reserved:">16 reserved bits, MUST be set to 0 on
            transmission, MUST be ignored on reception.</t>

            <t hangText="Remote Peer IP Address:">Copied from the request.</t>
          </list></t>
      </section>

      <section anchor="peer_opcode_client_operation" title="Generating a PEER Request">
        <t>This section describes the operation of a client when generating
        a message with the PEER Opcode.</t>

        <t>The PEER Opcode MAY be sent before or after
        establishing bi-directional communication with the remote peer.</t>

        <t>If sent before, this is considered a PEER-created mapping
        which creates a new dynamic outbound mapping in the
        PCP-controlled device.  This is useful for restoring a
        mapping after a NAT has lost its mapping state (e.g., due to a
        crash).</t>

        <t>If sent after, this allows the PCP client to learn the IP address,
        port, and lifetime of the assigned External Address and Port
        for the existing implicit dynamic outbound mapping,
        and potentially to extend this lifetime (for the
        purpose described in <xref target="keepalives"></xref>).</t>

        <t>The Mapping Nonce value is randomly chosen by the PCP client, following
        <xref target="RFC4086">accepted practices for generating unguessable random numbers</xref>,
        and is used as part of the validation of PCP responses (see
        below) by the PCP client, and validation for mapping refreshes
        by the PCP server.  The client MUST use a different Mapping
        Nonce for each PCP server it communicates with, and it is
        RECOMMENDED to choose a new random Mapping Nonce whenever the
        PCP client is initialized.  The client MAY use a different
        Mapping Nonce for every mapping.</t>

        <t>The PEER Opcode contains a Remote Peer Address field, which is
        always from the perspective of the PCP client.  Note that when
        the PCP-controlled device is performing address family translation
        (NAT46 or NAT64), the remote peer address from the perspective of the
        PCP client is different from the remote peer address on the other side
        of the address family translation device.</t>
      </section>

      <section anchor="peer-opcode_server_operation" title="Processing a PEER Request">
        <t>This section describes the operation of a server when receiving a
        request with the PEER Opcode.  Processing SHOULD be performed
        in the order of the following paragraphs.</t>

        <t>The following fields from a PEER request are copied into
        the response: Protocol, Internal Port, Remote Peer IP Address,
        Remote Peer Port, and Mapping Nonce.</t>

        <t>When an implicit dynamic mapping is created, some NATs and
        firewalls validate destination addresses and will not create
        an implicit dynamic mapping if the destination address is
        invalid (e.g., 127.0.0.1).  If a PCP-controlled device does
        such validation for implicit dynamic mappings, it SHOULD also
        do a similar validation of the Remote Peer IP Address, Protocol, and Port
        for PEER-created explicit dynamic mappings.  If the validation determines
        the Remote Peer IP Address of a PEER request is
        invalid, then no mapping is created, and a MALFORMED_REQUEST
        error result is returned.</t>

        <t>On receiving the PEER Opcode, the PCP server examines the mapping
        table for a matching five-tuple { Protocol, Internal Address, Internal
        Port, Remote Peer Address, Remote Peer Port }.</t>

        <t>If no matching mapping is found, and the Suggested
        External Address and Port are either zero or can be honored for the
        specified Protocol, a new mapping is created.  By having PEER create
        such a mapping, we avoid a race condition between the PEER request or
        the initial outgoing packet arriving at the NAT or firewall device
        first, and allow PEER to be used to recreate an outbound dynamic
        mapping (see last paragraph of <xref target="reboot"></xref>).
        Thereafter, this PEER-created mapping is treated as if it was an
        implicit dynamic outbound mapping (e.g., as if the PCP client sent a
        TCP SYN) and a Lifetime appropriate to such a mapping is returned
        (note: on many NATs and firewalls, such mapping lifetimes are very
        short until the bi-directional traffic is seen by the NAT or firewall).</t>

        <t>If no matching mapping is found, and the Suggested External Address
        and Port cannot be honored, then no new state is created, and the error
        CANNOT_PROVIDE_EXTERNAL is returned.</t>

        <t>If a matching mapping is found, but no pervious PEER Opcode
        was successfully processed for this mapping, then the
        Suggested External Address and Port values in the request are
        ignored, Lifetime of that mapping is adjusted as described below, and information about the existing mapping is
        returned. This allows a client to explicitly extend the
        lifetime of an existing mapping and/or to learn an existing
        mapping's External Address, Port and lifetime.  The Mapping
        Nonce is remembered for this mapping.</t>

        <t>If operating in the <xref target="SimpleThreat">Simple
Threat Model</xref>, and the Internal port, Protocol, and Internal
Address match a mapping that already exists, but the Mapping Nonce
does not match (that is, a previous PEER request was processed), the
request MUST be rejected with a NOT_AUTHORIZED error with the Lifetime
of the error indicating duration of that existing mapping.  The PCP
server only needs to remember one Mapping Nonce value for each
mapping.</t>

<t>Processing the lifetime value of the PEER Opcode is described
in <xref target="lifetime"></xref>.  Sending a PEER request with a very short
Requested Lifetime can be used to query the lifetime of an existing
mapping.</t>


        <t>If all of the preceding operations were successful (did not
        generate an error response), then a SUCCESS response is generated,
        with the Lifetime field containing the lifetime of the mapping.</t>

        <t>If a PEER-created or PEER-managed mapping is not renewed
        using PEER, then it reverts to the NAT's usual behavior for
        implicit mappings, e.g., continued outbound traffic keeps the
        mapping alive, as per the NAT or firewall device's existing policy.
        A PEER-created or PEER-managed mapping may be
        terminated at any time by action of the TCP client or server
        (e.g., due to TCP FIN or TCP RST), as per the NAT or firewall
        device's existing policy.</t>

      </section>

      <section title="Processing a PEER Response">
        <t>This section describes the operation of a client when processing a
        response with the PEER Opcode.</t>

        <t>After performing common PCP response processing, the response
        is further matched with an outstanding PEER request by comparing the
        Internal IP Address (the destination IP address of the PCP
        response, or other IP address specified via the THIRD_PARTY
        option), the Protocol, the Internal Port, the Remote Peer
        Address, the Remote Peer Port, and the Mapping Nonce. Other fields are not compared,
        because the PCP server sets those fields to provide
        information about the mapping created by the Opcode.
        The PCP server will send a <xref target="update">Mapping Update</xref>
        if the mapping changes (e.g., due to IP renumbering).</t>

        <t>If the result code is NO_RESOURCES and the request was for
        the creation or renewal of a mapping, then the PCP client
        SHOULD NOT send further requests for any new mappings to that
        PCP server for the (limited) value of the Lifetime.</t>

        <t>On a successful response, the application can use the assigned
        lifetime value to reduce its frequency of application keepalives for
        that particular NAT mapping. Of course, there may be other reasons,
        specific to the application, to use more frequent application
        keepalives. For example, the PCP assigned lifetime could be one hour
        but the application may want to maintain state on its server (e.g.,
        "busy" / "away") more frequently than once an hour.  If the response
        indicates an unexpected IP address or port (e.g., due to IP 
        renumbering), the PCP client will want to re-establish its
        connection to its remote server.</t>

        <t>If the PCP client wishes to keep this mapping alive beyond the
        indicated lifetime, it MAY rely on continued inside-to-outside
        traffic to ensure the mapping will continue to exist, or it MAY
        issue a new PCP request prior to the expiration. The recommended
        timings for renewing PEER mappings are the same as for MAP
        mappings, as described in <xref target="renewal"/>.</t>

        <t><list style="empty">
            <t>Note: Implementations need to expect the PEER response may
            contain an External IP Address with a different family than the
            Remote Peer IP Address, e.g., when NAT64 or NAT46 are being
            used.</t>
          </list></t>
      </section>
    </section>

    <section anchor="map_peer_options" title="Options for MAP and PEER Opcodes">
      <t>This section describes Options for the MAP and PEER
      Opcodes.  These Options MUST NOT appear with other Opcodes, unless
      permitted by those other Opcodes.</t>

      <section anchor="third_party" title="THIRD_PARTY Option for MAP and PEER Opcodes">
        <t>This Option is used when a PCP client wants to control a
        mapping to an Internal Host other than itself. This is used
        with both MAP and PEER Opcodes.</t>

<!-- OLD
        <t>Due to security concerns with the THIRD_PARTY option, this
        Option MUST only be implemented or deployed when access
        control lists are installed on the PCP client, PCP server, and
        the network between them, so those ACLs allow only
        communications from a trusted PCP client to the PCP server.</t>
-->

<t>Due to security concerns with the THIRD_PARTY option, this Option
MUST NOT be implemented or used unless the network on which the
PCP messages are to be sent is fully trusted. For example if
access control lists are
installed on the PCP client, PCP server, and the network between
them, so those ACLs allow only communications from a trusted PCP
client to the PCP server.
</t>


<!--
in equipment that
        would be operated by separate administrative domains.  For
        example, this option MUST NOT be implemented or deployed where
        a residental gateway is deployed in conjunction with a CGN,
        because the residential gateway is under the physical control
        (and thus, administrative control) of a different entity than
        is operating the CGN.  This option MAY be deployed where the
        PCP client and server and network between them are operated
        by the same administrative domain, and 
access control lists
        are installed on the network and hosts so that only the
        PCP client communicates with the PCP server.</t>
-->

        <t>A management device would use this Option to control a PCP
        server on behalf of users.  For example, a management device
        located in a network operations center, which presents a user
        interface to end users or to network operations staff, and
        issues PCP requests with the THIRD_PARTY option to the appropriate
        PCP server.</t>

        <figure align="left" anchor="fig_third_party" title="THIRD_PARTY Option">
          <preamble>The THIRD_PARTY Option is formatted as follows:</preamble>
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code=1 |  Reserved     |   Option Length=16            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                Internal IP Address (128 bits)                 |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>The fields are described below:<list style="hanging">
            <t hangText="Internal IP Address:">Internal IP address for this
            mapping. </t>
          </list></t>

        <?rfc needLines="7" ?>
        <t><list style="empty">
            <?rfc subcompact="yes"?>
            <t>Option Name: THIRD_PARTY</t>
            <t>Number: 1</t>
            <t>Purpose: Indicates the MAP or PEER request is for a host other
            than the host sending the PCP Option.</t>
            <t>Valid for Opcodes: MAP, PEER</t>
            <t>Length: 16 octets</t>
            <t>May appear in: request. May appear in response only if it
            appeared in the associated request.</t>
            <t>Maximum occurrences: 1</t>
            <?rfc subcompact="no"?>
        </list></t>

        <t>A THIRD_PARTY Option MUST NOT contain the same address as the
        source address of the packet. This is because many PCP servers may
        not implement the THIRD_PARTY Option at all, and with those servers
        a client redundantly using the THIRD_PARTY Option to specify its own
        IP address would cause such mapping requests to fail where they
        would otherwise have succeeded. A PCP server receiving a THIRD_PARTY
        Option specifying the same address as the source address of the
        packet MUST return a MALFORMED_REQUEST result code.</t>

        <t>A PCP server MAY be configured to permit or to prohibit the use of
        the THIRD_PARTY Option. If this Option is permitted, properly
        authorized clients may perform these operations on behalf of other
        hosts. If this Option is prohibited, and a PCP server receives a PCP
        MAP request with a THIRD_PARTY Option, it MUST generate a
        UNSUPP_OPTION response.</t>

        <t>It is RECOMMENDED that customer premises equipment implementing a
        PCP Server be configured to prohibit third party mappings by default.
        With this default, if a user wants to create a third party mapping,
        the user needs to interact out-of-band with their customer premises
        router (e.g., using its HTTP administrative interface).</t>

        <t>It is RECOMMENDED that service provider NAT and firewall devices
        implementing a PCP Server be configured to permit the THIRD_PARTY
        Option, when sent by a properly authorized host. If the packet arrives
        from an unauthorized host, the PCP server MUST generate an
        UNSUPP_OPTION error.</t>

<!--
        <t>Determining which PCP clients are authorized to use the
        THIRD_PARTY Option for which other hosts is
        deployment-dependent. For example, an ISP using Dual-Stack
        Lite could choose to allow a client connecting over a given
        IPv6 tunnel to manage mappings for any other host connecting
        over the same IPv6 tunnel, or the ISP could choose to allow
        only the DS-Lite B4 element to manage mappings for other hosts
        connecting over the same IPv6 tunnel. A cryptographic
        authentication and authorization model is outside the scope of
        this specification.
-->

        <t>Note that the THIRD_PARTY Option is not
        needed for today's common scenario of an ISP offering a single
        IP address to a customer who is using NAT to share that
        address locally, since in this scenario all the customer's
        hosts appear, from the point of view of the ISP, to be a single host.</t>

        <t>When a PCP client is using the THIRD_PARTY Option to make
        and maintain mappings on behalf of some other device, it may
        be beneficial if, where possible, the PCP client verifies that
        the other device is actually present and active on the network.
        Otherwise the PCP client risks maintaining those mappings forever,
        long after the device that required them has gone. This would defeat
        the purpose of PCP mappings having a finite lifetime so that they
        can be automatically deleted after they are no longer needed.</t>

<!-- Unnecessary

<t>A PCP client MAY be configured so that the Mapping Nonce is
not matched when mappings are deleted.  This allows a network management
system to use the THIRD_PARTY Option to flush PCP-created mappings created
by other devices, such as by a subscriber host or subscriber CPE router,
and useful when an IP address is no longer assigned to the subscriber
that originally created a mapping.</t>
-->
      </section>

      <section anchor="prefer_failure" title="PREFER_FAILURE Option for MAP Opcode">
        <t>This Option is only used with the MAP Opcode.</t>

        <t>This Option indicates that if the PCP server is unable to
        map both the Suggested External Port and Suggested External
        Address, the PCP server should not create a mapping.  This
        differs from the behavior without this Option, which is to
        create a mapping.</t>

<!-- RFC Editor note:  Move the "never necessary" paragraph,
whih is on the next page, to this location here -->

        <figure align="left" anchor="fig_prefer_failure" title="PREFER_FAILURE Option">
          <preamble>The PREFER_FAILURE Option is formatted as follows:</preamble>
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code=2 |  Reserved     |   Option Length=0             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <?rfc needLines="7" ?>
        <t><list style="empty">
            <?rfc subcompact="yes"?>
            <t>Option Name: PREFER_FAILURE</t>
            <t>Number: 2</t>
            <t>Purpose: indicates that the PCP server should not create an
            alternative mapping if the suggested external port and address
            cannot be mapped.</t>
            <t>Valid for Opcodes: MAP</t>
            <t>Length: 0</t>
            <t>May appear in: request. May appear in response only if it
            appeared in the associated request.</t>
            <t>Maximum occurrences: 1</t>
            <?rfc subcompact="no"?>
        </list></t>

        <t>The result code CANNOT_PROVIDE_EXTERNAL is returned if
        the Suggested External Address, Protocol, and Port
        cannot be mapped. This can occur because the External Port is
        already mapped to another host's outbound dynamic mapping, an
        inbound dynamic mapping, a static mapping, or the same
        Internal Address, Protocol, and Port already has an outbound dynamic mapping
        which is mapped to a different External Port than
        suggested. This can also occur because the External Address is
        no longer available (e.g., due to renumbering).  The server
        MAY set the Lifetime in the response to the remaining lifetime
        of the conflicting mapping + TIME_WAIT <xref target="RFC0793"></xref>,
        rounded up to the next larger integer number of seconds.</t>


<!-- the paragraph below should be moved up a few paragraphs -->

<t>PREFER_FAILURE is never necessary for a PCP client to manage
mappings for itself, and its use causes additional work in the PCP
client and in the PCP server.  This Option exists for interworking
with non-PCP mapping protocols that have different semantics than PCP
(e.g.,
        <xref target="I-D.ietf-pcp-upnp-igd-interworking">UPnP IGDv1
        interworking</xref>, where the semantics of UPnP IGDv1 only
        allow the UPnP IGDv1 client to dictate mapping a specific
        port), or separate port allocation systems which allocate
        ports to a subscriber (e.g., a subscriber-accessed web portal
        operated by the same ISP that operates the PCP server).  A PCP
        server MAY support this Option, if its designers wish to
        support such downstream devices or separate port allocation
        systems.  PCP servers that are not intended to interface with
        such systems are not required to support this Option. PCP
        clients other than UPnP IGDv1 interworking clients or other
        than a separate port allocation system SHOULD NOT use this
        Option because it results in inefficient operation, and they
        cannot safely assume that all PCP servers will implement
        it. It is anticipated that this Option will be deprecated in
        the future as more clients adopt PCP natively and the need for
        this Option declines.</t>


<t>If a PCP request contains the PREFER_FAILURE option and has zero in
  the Suggested External Port field, or has the all-zeros IPv4 or
  all-zeros IPv6 address in the Suggested External Address field, it
  is invalid.  The PCP server MUST reject such a message with the
  MALFORMED_OPTION error code.</t>

        <t>PCP servers MAY choose to rate-limit
        their handling of PREFER_FAILURE requests, to protect
        themselves from a rapid flurry of 65535 consecutive
        PREFER_FAILURE requests from clients probing to discover which
        external ports are available.</t>

        <t>There can exist a race condition between the MAP
        Opcode using the PREFER_FAILURE option and
        <xref target="update">Mapping Update</xref>.
        For example, a previous host on the local network could have
        previously had the same Internal Address, with a mapping for the same
        Internal Port. At about the same moment that the current host sends
        a MAP Request using the PREFER_FAILURE option, the PCP server could
        send a spontaneous mapping update for the old mapping due to an
        external configuration change, which could appear to be a reply
        to the new mapping request. Because of this, the PCP client MUST
        validate that the External IP Address, Protocol, Port and Nonce in a
        success response matches the associated suggested values from the
        request.  If they don't match, it is because the Mapping Update was
        sent before the MAP request was processed.</t>

      </section>

      <section anchor="filter" title="FILTER Option for MAP Opcode">
        <t>This Option is only used with the MAP Opcode.</t>

        <t>This Option indicates that filtering incoming packets is desired.
        The protocol being filtered is indicated by the Protocol field
        in the MAP Request, and the Remote Peer IP Address and Remote
        Peer Port of the FILTER Option indicate the permitted remote
        peer's source IP address and source port for packets from the
        Internet; other traffic from other addresses is blocked.
        The remote peer prefix length indicates the length of the
        remote peer's IP address that is significant; this allows a single
        Option to permit an entire subnet. After processing this MAP request
        containing the FILTER Option and generating a successful response, the
        PCP-controlled device will drop packets received on its public-facing
        interface that don't match the filter fields. After dropping the
        packet, if its security policy allows, the PCP-controlled device MAY
        also generate an ICMP error in response to the dropped packet.</t>

        <t>The use of the FILTER Option can be seen as a performance
        optimization. Since all software using PCP to receive incoming
        connections also has to deal with the case where it may be directly
        connected to the Internet and receive unrestricted incoming TCP
        connections and UDP packets, if it wishes to restrict incoming traffic
        to a specific source address or group of source addresses such
        software already needs to check the source address of incoming traffic
        and reject unwanted traffic. However, the FILTER Option is a
        particularly useful performance optimization for battery powered
        wireless devices, because it can enable them to conserve battery power
        by not having to wake up just to reject unwanted traffic.</t>

        <figure align="left" anchor="fig_filter" title="FILTER Option layout">
          <preamble>The FILTER Option is formatted as follows:</preamble>
          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code=3 |  Reserved     |   Option Length=20            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   | Prefix Length |      Remote Peer Port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Remote Peer IP address (128 bits)               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>These fields are described below:<list style="hanging">
            <t hangText="Reserved:">8 reserved bits, MUST be sent as 0 and
            MUST be ignored when received.</t>

            <t hangText="Prefix Length:">indicates how many bits of the IPv4
            or IPv6 address are relevant for this filter. The value 0
            indicates "no filter", and will remove all previous filters. See
            below for detail.</t>

            <t hangText="Remote Peer Port:">the port number of the remote
            peer. The value 0 indicates "all ports".</t>

            <t hangText="Remote Peer IP address:">The IP address of the remote peer.</t>
          </list></t>

        <?rfc needLines="7" ?>
        <t><list style="empty">
            <?rfc subcompact="yes"?>
            <t>Option Name: FILTER</t>
            <t>Number: 3</t>
            <t>Purpose: specifies a filter for incoming packets</t>
            <t>Valid for Opcodes: MAP</t>
            <t>Length: 20 octets</t>
            <t>May appear in: request. May appear in response only if it
            appeared in the associated request.</t>
            <t>Maximum occurrences: as many as fit within maximum PCP message
            size</t>
            <?rfc subcompact="no"?>
        </list></t>

        <!--

This paragraph is detail justifying why FILTER is complicated with
PEER.  FILTER is only defined for MAP, so this detail is unnecessary.

        <t>On networks with a NAT, there can be an interactions with
        EDM NATs and this Opcode
        (see <xref target="EDM"></xref>).  Because of this, the
        FILTER Option MUST only be used by a client that is operating
        a server (that is, using the MAP Opcode), as this ensures that
        no other application will be assigned the same port for its
        outgoing connection. It is RECOMMENDED that the PCP client
        avoid other use, because it will cause some UNSAF NAT
        traversal mechanisms <xref target="RFC3424"></xref> to fail
        where they would have otherwise succeeded, breaking other
        applications running on this same host.  Networks without a
        NAT do not have these restrictions.</t>
-->

        <t>The Prefix Length indicates how many bits of the address
        are used for the filter.  For IPv4 addresses (which are
        encoded using the IPv4-mapped address format (::FFFF:0:0/96)),
        this means valid prefix lengths are between 96 and 128 bits,
        inclusive.  That is, add 96 to the IPv4 prefix length.  For
        IPv6 addresses, valid prefix lengths are between 0 and 128
        bits, inclusive.  Values outside those ranges cause the PCP
        server to return the MALFORMED_OPTION result code.</t>

        <t>If multiple occurrences of the FILTER Option exist in the
        same MAP request, they are processed in the order
        received (as per normal PCP Option processing) and they MAY
        overlap the filtering requested. If an existing mapping exists
        (with or without a filter) and the server receives a MAP
        request with FILTER, the filters indicated in the new request
        are added to any existing filters. If a MAP request has a
        lifetime of 0 and contains the FILTER Option, the error
        MALFORMED_OPTION is returned.</t>

        <t>If any occurrences of the FILTER Option in a request packet are
        not successfully processed then an error is returned (e.g.,
        MALFORMED_OPTION if one of the Options was malformed) and as with
        other PCP errors, returning an error causes no state to be changed in
        the PCP server or in the PCP-controlled device.</t>

        <t>To remove all existing filters, the Prefix Length 0 is used. There
        is no mechanism to remove a specific filter.</t>

        <t>To change an existing filter, the PCP client sends a MAP request
        containing two FILTER Options, the first Option containing a Prefix
        Length of 0 (to delete all existing filters) and the second containing
        the new remote peer's IP address, protocol, and port. Other FILTER Options in
        that PCP request, if any, add more allowed Remote Peers.</t>

        <t>The PCP server or the PCP-controlled device is expected to have a
        limit on the number of remote peers it can support. This limit might
        be as small as one. If a MAP request would exceed this limit, the
        entire MAP request is rejected with the result code
        EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is
        unchanged.</t>

        <t>All PCP servers MUST support at least one filter per MAP mapping.</t>
      </section>

      <!--
      <section title="EVEN_PLUS_ONE">
        <t><xref target="RFC3550">RTP</xref> has historically used an
        even-numbered port, and RTCP the next-higher port (often abbreviated
        as "port + 1"). Some equipment still expects RTP/RTCP on adjacent
        ports. To accommodate that, the PCP Option EVEN_PLUS_ONE can be used
        by the PCP client and server, with the following procedure.</t>

        <t><list style="empty">
            <t>[Ed.&#160;Note: Are there any other protocols that need adjacent
            ports?]</t>
          </list></t>

        <t>The procedure is for the PCP client to bind to two ports on its
        local interface. It then sends a PCP request for external port 0
        (indicating it will accept any port from the server) for one of those
        internal ports and includes the PCP Option EVEN_PLUS_ONE with this
        request. If the server understands this Option, it will choose an
        even-numbered external port and will reserve the next-higher port with
        a short timeout (suggested duration is 10 seconds) for this same PCP
        client to allocate in a subsequent PCP request. The PCP server sends a
        response and indicates it performed that operation by including the
        PCP Option EVEN_PLUS_ONE in the response. The PCP client then sends a
        second PCP request for the next-higher external port. Refreshing and
        deleting the ports works as normal.</t>

        <figure align="left" anchor="even_plus_one_message_flow" title="Message Flow, EVEN_PLUS_ONE">
          <preamble>A diagram of the message flow:</preamble>

          <artwork align="center"><![CDATA[
PCP Client                               PCP server
   |                                          |
   |....request ext-port=0, EVEN_PLUS_ONE....>|
   |<.response ext-port=23456, EVEN_PLUS_ONE..|
   |....request ext-port=23457...............>|
   |<-response ext-port=23457.................|
   |                                          |
]]></artwork>
        </figure>

        <t>The PCP Option EVEN_PLUS_ONE always has an Option Length of 0. When
        the PCP client wants an even-numbered port and the next-higher
        adjacent port, it includes the PCP Option EVEN_PLUS_ONE in its PCP
        request. If the server understands the Option, has successfully mapped
        an even-numbered external-port, and temporarily reserved the
        next-higher port for this PCP client, the server MUST include the
        EVEN_PLUS_ONE Option in its response. If the server understands the
        Option, but was unsuccessful at mapping an even-numbered port or
        unsuccessful at temporarily reserving the next-higher port for this
        PCP client, the server MUST NOT include the EVEN_PLUS_ONE Option in
        its response. If the server receives a PCP request with the
        EVEN_PLUS_ONE Option for an odd-numbered suggested-external-port, it
        MUST return an error.</t>

        <t>This Option is permitted with the following Opcodes: MAP44, MAP64,
        MAP46, MAP66.</t>
      </section>
-->

      <!--
        <section title="REMOTE_PEER">
          <t>Due to a pre-existing dynamic mapping, a PCP server may not be
          able to instantiate a filter on a specific port. It is thus
          recommended that applications bind to the source port (to prevent
          other applications from using that same source port) prior to using
          this PCP Option.</t>

          <t>In those situations, the Option REMOTE_PEER is necessary to
          disambiguate the mappings. This Option does not change filtering
          behavior of the NAT or firewall.</t>

          <figure>
            <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved                   |   Remote Peer Port            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:     Remote Peer IP address (32 bits if MAP44 or MAP64,        :
:              1 28 bits if MAP46 or MAP66)                     :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure>

          <t><list style="empty">
              <t>This Option:<list style="empty">
                  <t>value: 129</t>
                  <t>is valid for Opcodes: MAP44, MAP64, MAP46, or MAP66</t>
                  <t>is included in responses: MUST</t>
                  <t>length: 8 or 20</t>
                  <t>maximum occurrences:  1</t>
                </list></t>
            </list></t>
        </section>
-->
    </section>

    <!--
    <section title="NAT-PMP Transition">
      <t>Port Control Protocol (PCP) is a successor to NAT Port
      Mapping Protocol (NAT-PMP), and shares similar semantics,
      concepts, and packet formats. Because of this NAT-PMP and PCP
      can both use the same port, and use the NAT-PMP and PCP's
      version negotiation capabilities to determine which version to
      use.  This section describes how an orderly transition may be
      achieved.</t>

      <section title="NAT-PMP Clients Updated to Add PCP Support">
        <t>A client supporting both NAT-PMP and PCP SHOULD optimistically
        assume that the gateway supports PCP, since we expect that this will
        rapidly become the case, and we want to optimize for better
        performance in this case. A dual-mode client SHOULD send all its
        requests first using PCP packet format. If the gateway responds with a
        packet four or more octets long, containing the following (NAT-PMP
        format) data in the first four octets, then the dual-mode client SHOULD
        conclude that this NAT gateway supports only NAT-PMP, and SHOULD retry
        its request in the older NAT-PMP format.</t>

        <figure align="left" anchor="PMPGate" title="NAT-PMP Gateway Response to PCP Request">
          <preamble>NAT-PMP gateways respond to PCP requests with the
          following packet. The first octet (supported version) is zero. The
          second octet (Opcode) echoes back the request Opcode, with the top
          bit set. The third octet (high octet of the NAT-PMP result code) is
          zero. The fourth octet is 1 (NAT-PMP and PCP result code "Unsupported
          Version").</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Version = 0 |R| OP = any    | Zero          |  Result = 1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
      </section>

      <section title="NAT-PMP Gateways Updated to Add PCP Support">
        <t>A gateway supporting both NAT-PMP and PCP is able to handle and
        respond to requests using both packet formats. If the first octet of
        the packet is zero, a dual-mode gateway SHOULD parse the request as a
        NAT-PMP-format message and reply using a NAT-PMP-format response.
        Otherwise it should parse the request as a PCP-format message and
        respond accordingly.</t>

        <t>A PCP-only gateway receiving a NAT-PMP request (identified by the
        first octet being zero) MUST reply with the packet shown below, so that
        the NAT-PMP may log an error message informing the user that they need
        to update to a PCP-capable client.</t>

        <figure align="left" anchor="PCPGate" title="PCP Gateway Response to NAT-PMP Request">
          <preamble>PCP gateways respond to NAT-PMP requests (identified by
          the first octet being zero) with the following packet. The first octet
          (supported version) is 1. The second octet (Opcode) echoes back the
          request Opcode, with the top bit set. The third octet (high octet of
          the NAT-PMP result code) is zero. The fourth octet is 1 (NAT-PMP and
          PCP result code "Unsupported Version").</preamble>

          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Version = 1 |R| OP = any    | Zero          |  Result = 1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
      </section>
    </section>
-->



      <section anchor="Rapid_Recovery" title="Rapid Recovery">

      <t>PCP includes a rapid recovery feature, which allows PCP clients
      to repair failed mappings within seconds, rather than the minutes
      or hours it might take if they relied solely on waiting for the
      next routine renewal of the mapping.  Mapping failures may occur
      when a NAT gateway is rebooted and loses its mapping state, or
      when a NAT gateway has its external IP address changed so that its
      current mapping state becomes invalid.</t>

      <t>The PCP rapid recovery feature enables users to, for
      example, connect to remote machines using ssh, and then reboot
      their NAT or firewall device (or even replace it with completely
      new hardware) without losing their established ssh
      connections.</t>

      <t>Use of PCP rapid recovery is a performance optimization to
      PCP's routine self-healing.  Without rapid recovery, PCP clients
      will still recreate their correct state when they next renew
      their mappings, but this routine self-healing process may take
      hours rather than seconds, and will probably not happen fast
      enough to prevent active TCP connections from timing out.</t>

     <t>There are two mechanisms to perform rapid recovery, described
below.  A PCP server that can lose state (e.g., due to reboot) or
might have a mapping change (e.g., due to IP renumbering) MUST
implement either the Announce Opcode or the Mapping Update mechanism
and SHOULD implement both mechanisms.  Failing to implement and deploy
a rapid recovery mechanism will encourage application developers to
feel the need to refresh their PCP state more frequently than necessary,
causing more network traffic.</t>

    <section anchor="announcement" title="ANNOUNCE Opcode">

<t>This rapid recovery mechanism uses the ANNOUNCE Opcode.  When the
PCP server loses its state (e.g., it lost its state when rebooted), it
sends the ANNOUNCE response to the link-scoped multicast address
(specific address explained below) if a multicast network exists on
its local interface or, if configured with the IP address(es) and port(s) of PCP
client(s), sends unicast ANNOUNCE responses to those address(es) and port(s).  This
means ANNOUNCE may not be available on all networks (such as networks
without a multicast link between the PCP server and its PCP clients).
Additionally, an ANNOUNCE request can be sent (unicast) by a PCP
client which elicits a unicast ANNOUNCE response like any other
Opcode.</t>

<section title="ANNOUNCE Operation">
<t>The PCP ANNOUNCE Opcode requests and respones have no
Opcode-specific payload (that is, the length of the Opcode-specific
data is zero).  The Requested
Lifetime field of requests and Lifetime field of responses are both
set to 0 on transmission and ignored on reception.</t>

      <t>If a PCP server receives an ANNOUNCE request, it first parses
      it and generates a SUCCESS if parsing and processing of ANNOUNCE
      is successful. An error is generated if the Client's IP
      Address field does not match the packet source address, or the
      request packet is otherwise malformed, such as packet length less
      than 24 octets.  Note that, in the future, Options MAY be sent
      with the PCP ANNOUNCE Opcode; PCP clients and servers need to be
      prepared to receive Options with the ANNOUNCE Opcode.</t>

      <t><list style="empty"><t>Discussion: Client-to-server request messages
      are sent to listening UDP port 5351 on the server; server-to-client multicast
      notifications are sent to listening UDP port 5350 on the client. The reason
      the same UDP port is not used for both purposes is that a single device
      may have multiple roles.  For example, a multi-function home
      gateway that provides NAT service (PCP server) may also provide printer
      sharing (which wants a PCP client), or a home computer (PCP client) may
      also provide "Internet Sharing" (NAT) functionality (which needs to offer
      PCP service). Such devices need to act as both a PCP Server and a PCP Client
      at the same time, and the software that implements the PCP Server on
      the device may not be the same software component that
      implements the PCP Client.  The software that implements the PCP
      Server needs to listen for unicast client requests, whereas the
      software that implements the PCP Client needs to listen for
      multicast restart announcements.  In many networking APIs it is
      difficult or impossible to have two independent clients
      listening for both unicasts and multicasts on the same port at
      the same time. For this reason, two ports are used.</t>
      </list></t>


</section>

<section title="Generating and Processing a Solicited ANNOUNCE Message">
<t>The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client.  The
Requested Lifetime value MUST be set to zero.</t>

<t>When the PCP server receives the ANNOUNCE Opcode and successfully
parses and processes it, it generates SUCCESS response with an Assigned
Lifetime of zero.</t>

<t>This functionality allows a PCP client to determine a server's
Epoch, or to determine if a PCP server is running, without changing the
server's state.</t>
</section>

<section title="Generating and Processing an Unsolicited ANNOUNCE Message">

      <t>When sending unsolicited responses, the ANNOUNCE Opcode MUST
      have Result Code equal to zero (SUCCESS), and the packet MUST be
      sent from the unicast IP address and UDP port number on which PCP
      requests are received (so PCP response processing accepts the
      message, see <xref target="pcp_processing_response"></xref>).
      This message is most typically multicast, but can also be unicast.
      Multicast PCP restart announcements are sent to 224.0.0.1:5350
      and/or [ff02::1]:5350, as described below.
      Sending PCP restart announcements via unicast requires that the PCP
      server know the IP address(es) and port(s) of its listening clients,
      which means that sending PCP restart announcements via unicast is only
      applicable to PCP servers that retain knowledge of the IP address(es)
      and port(s) of their clients even after they otherwise lose the rest of
      their state.</t>

<!--
     <t>PCP Servers that accept PCP requests from multicast-reachable
      clients (e.g., from clients directly attached via Ethernet or
      Wi-Fi) SHOULD send the PCP ANNOUNCE Opcode response packet
      described below to signal restarts.  PCP Clients that send PCP
      requests to a PCP Server via a multicast-capable path (e.g., to a
      PCP server attached to the same Ethernet or Wi-Fi link) SHOULD
      listen for and process these Restart Announcements sent by PCP
      Servers.  If a multicast-capable path is not available, PCP 
      Clients MAY listen on port 5350 for these Restart Announcements.</t>
-->

      <t>When a PCP server device that implements this functionality
      reboots, restarts its NAT engine, or otherwise enters a state
      where it may have lost some or all of its previous mapping state
      (or enters a state where it doesn't even know whether it may
      have had prior state that it lost) it MUST inform PCP clients of
      this fact by unicasting or multicasting a gratuitous PCP
      ANNOUNCE Opcode response packet, as shown below, via paths over
      which it accepts PCP requests.  If sending a multicast ANNOUNCE
      message, a PCP server device which accepts PCP requests over
      IPv4 sends the Restart Announcement to the IPv4 multicast
      address 224.0.0.1:5350 (224.0.0.1 is the All Hosts multicast
      group address), and a PCP
      server device which accepts PCP requests over IPv6 sends the
      Restart Announcement to the IPv6 multicast address
      [ff02::1]:5350 (ff02::1 is for all nodes on the local segment).
      A PCP server device which accepts PCP requests over both IPv4
      and IPv6 sends a pair of Restart Announcements, one to each
      multicast address.  If sending a unicast ANNOUNCE messages, it
      sends ANNOUNCE response message to the IP address(es) and port(s)
      of its PCP clients.  To accommodate packet loss,
      the PCP server device MAY transmit such packets (or packet pairs) 
      up to ten times (with an appropriate Epoch time value in each to
      reflect the passage of time between transmissions) provided that
      the interval between the first two notifications is at least
      250ms, and the interval between subsequent notification at least
      doubles.</t>

      <t>A PCP client that sends PCP requests to a PCP Server via a
      multicast-capable path, and implements the Restart Announcement
      feature, and wishes to receive these announcements, MUST listen
      to receive these PCP Restart Announcements (gratuitous PCP
      ANNOUNCE Opcode response packets) on the appropriate
      multicast-capable interfaces on which it sends PCP requests,
      and MAY also listen for unicast announcements from the server too,
      (using the UDP port it already uses to issue unicast PCP requests to,
      and receive unicast PCP responses from, that server).

      A PCP client device which sends PCP requests using IPv4 listens
      for packets sent to the IPv4 multicast address 224.0.0.1:5350.
      A PCP client device which sends PCP requests using IPv6 listens
      for packets sent to the IPv6 multicast address [ff02::1]:5350.
      A PCP client device which sends PCP requests using both IPv4 and
      IPv6 listens for both types of Restart Announcement.  The
      SO_REUSEPORT socket option or equivalent should be used for the
      multicast UDP port, if required by the host OS to permit
      multiple independent listeners on the same multicast UDP port.</t>

      <t>Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode
      response packet, a PCP client MUST (as it does with all received
      PCP response packets) inspect the Announcement's source IP
      address, and if the Epoch time value is outside the expected
      range for that server, it MUST wait a random amount of time
      between 0 and 5 seconds (to prevent synchronization of all PCP
      clients), then for all PCP mappings it made at that server
      address the client issues new PCP requests to recreate any lost
      mapping state. The use of the Suggested External IP Address and
      Suggested External Port fields in the client's renewal requests
      allows the client to remind the restarted PCP server device of
      what mappings the client had previously been given, so that in
      many cases the prior state can be recreated. For PCP server
      devices that reboot relatively quickly it is usually possible to
      reconstruct lost mapping state fast enough that existing TCP
      connections and UDP communications do not time out, and continue
      without failure.  As for all PCP response messages, if the Epoch
      time value is within the expected range for that server, the PCP
      client does not recreate its mappings.  As for all PCP response
      messages, after receiving and validating the ANNOUNCE message, the
      client updates its own Epoch time for that server, as described in
      <xref target="epoch"></xref>.</t>
</section>

    </section>

    <section anchor="update" title="PCP Mapping Update">

<t>This rapid recovery mechanism is used when the PCP server
remembers its state and determines its existing mappings are
invalid (e.g., IP renumbering changes the External IP Address of
a PCP-controlled NAT).</t>

<t>It is anticipated that servers which
      are routinely reconfigured by an administrator or have their WAN
      address changed frequently will implement this feature (e.g.,
      residential CPE routers).  It is anticipated that servers which
      are not routinely reconfigured will not implement this
      feature (e.g., service provider-operated CGN).</t>
      
      <t>If a PCP server device has not forgotten its mapping state,
      but for some other reason has determined 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 device automatically repairs its
      mappings and notifies its clients by following the procedure
      described below.</t>

      <t>For PCP-managed mappings, for each one the
      PCP server device should update the External IP Address and
      External Port to appropriate available values, and then send
      unicast PCP MAP or PEER responses (as appropriate for the
      mapping) to inform the PCP client of the new External IP Address
      and External Port. Such unsolicited responses are identical to
      the MAP or PEER responses normally returned in response to
      client MAP or PEER requests, containing newly updated External IP
      Address and External Port values, and are sent to the same
      client IP address and port that the PCP server used to send
      the prior response for that mapping. If the earlier associated
      request contained the THIRD_PARTY Option, the THIRD_PARTY Option
      MUST also appear in the Mapping Update as it is necessary for
      the PCP client to disambiguate the response.  If the earlier
      associated request contained the PREFER_FAILURE option, and the
      same external IP address, protocol, and port cannot be provided, the error
      CANNOT_PROVIDE_EXTERNAL SHOULD be sent.  If the earlier associated
      request contained the FILTER option, the filters are moved to
      the new mapping and the FILTER Option is sent in the Mapping
      Update response.  Non-mandatory Options SHOULD NOT be sent in
      the Mapping Update response.</t>


      <t><list style="empty">
          <t>Discussion:  It could have been possible to design this
          so that the PCP server (1) sent an ANNOUNCE Opcode to the
          PCP client, the PCP client reacted by (2) sending a new
          MAP request and (3) receiving a MAP response.  Instead,
          that design is short-cutted by the server simply sending
          the message it would have sent in (3).</t></list></t>

      <t>To accommodate packet loss, the PCP server device SHOULD
      transmit such packets 3 times, with an appropriate Epoch time
      value in each to reflect the passage of time between
      transmissions.  The interval between the first two notifications
      MUST be at least 250ms, and the third packet after a 500ms
      interval.  Once the PCP server has received a refreshed state
      for that mapping, the PCP server SHOULD cease those
      retransmissions for that mapping, as it serves no further
      purpose to continue sending messages regarding that mapping.</t>

      <t>Upon receipt of such an updated MAP or PEER response, a PCP
      client uses the information in the response to adjust rendezvous
      servers or re-connect to servers, respectively.  For MAP, this
      would means updating the DNS entries or other address and port
      information recorded with some kind of application-specific
      rendezvous server.  For PEER responses giving a
      CANNOT_PROVIDE_EXTERNAL error, this would typically mean
      establishing new connections to servers.  Any time the external
      address or port changes, existing TCP and UDP connections will
      be lost; PCP can't avoid that, but does provide immediate
      notification of the event to lessen the impact.</t>
    </section>

</section>

      <section anchor="lifetime" title="Mapping Lifetime and Deletion">
        <t>The PCP client requests a certain lifetime, and the PCP server
        responds with the assigned lifetime. The PCP server MAY grant a
        lifetime smaller or larger than the requested lifetime. The PCP server
        SHOULD be configurable for permitted minimum and maximum lifetime, and
        the minimum value SHOULD be 120 seconds.  The maximum value SHOULD
        be the remaining lifetime of the IP address assigned to the
        PCP client if that information is available (e.g., from the
        DHCP server), or half the lifetime of IP address assignments on
        that network if the remaining lifetime is not available, or
        24 hours.  Excessively long lifetimes can cause consumption of
        ports even if the Internal Host is no longer
        interested in receiving the traffic or is no longer connected to the
        network.  These recommendations are not strict, and deployments should
        evaluate the trade offs to determine their own minimum and maximum
        lifetime values.</t>

        <t>Once a PCP server has responded positively to a MAP request
        for a certain lifetime, the port mapping is active for the
        duration of the lifetime unless the lifetime is reduced
        by the PCP client (to a
        shorter lifetime or to zero) or until the PCP server loses its
        state (e.g., crashes). Mappings created by PCP MAP requests
        are not special or different from mappings created in other
        ways. In particular, it is implementation-dependent if
        outgoing traffic extends the lifetime of such mappings beyond
        the PCP-assigned lifetime. PCP clients MUST NOT depend on this
        behavior to keep mappings active, and MUST explicitly renew
        their mappings as required by the Lifetime field in PCP
        response messages.</t>

<!-- removed, becuase it is duplicate

        <t>If a PCP client sends a PCP MAP request to create a mapping
        that already exists as a static mapping, the PCP server will
        return a successful result, confirming that the requested
        mapping exists. The lifetime the PCP server returns for such a
        static mapping SHOULD be 2^32-1.
-->
<t>Upon receipt of a PCP response with an absurdly long Assigned Lifetime the
        PCP client SHOULD behave as if it received a more sane value
        (e.g., 24 hours), and renew the mapping accordingly, to ensure
        that if the static mapping is removed the client will continue
        to maintain the mapping it desires.</t>

        <t>An application that forgets its PCP-assigned mappings (e.g., the
        application or OS crashes) will request new PCP mappings. This may
        consume port mappings, if the application binds to a different
        Internal Port every time it runs. The application will also likely
        initiate new implicit dynamic outbound mappings without using PCP, which will
        also consume port mappings. If there is a port mapping quota for the
        Internal Host, frequent restarts such as this may exhaust the quota
and using the same Mapping Nonce can help alleviate such exhaustion.</t>

<!--
        PCP provides some protections against such port consumption: When a
        PCP client first acquires a new IP address (e.g., reboots or joins a
        new network), it SHOULD remove mappings that may already be
        instantiated for that new Internal Address. To do this, the PCP client
        sends a MAP request with protocol, internal port, and lifetime set to
        0. Some port mapping APIs (e.g., the "DNSServiceNATPortMappingCreate"
        API provided by Apple's Bonjour on Mac OS X, iOS, Windows, Linux
        <xref target="Bonjour"></xref>) automatically monitor for process exit
        (including application crashes) and automatically send port mapping
        deletion requests if the process that requested them goes away without
        explicitly relinquishing them.</t>
-->

<t>To help clean PCP state, it is RECOMMENDED that devices which
combine IP address assignment (e.g., DHCP server) with the PCP server
function (e.g., such as a residential CPE) flush PCP state when an
IP address is allocated to a new host, because the new host will be
unable perform the functions described in the previous paragaph
because the new host does not know the previous host's Mapping Nonce
value.  It is good hygiene to also flush TCP and UDP flow state of NAT
or fireall functions, although out of scope of this document.</t>


<t>To reduce unwanted traffic and data corruption for both TCP and
   UDP, the Assigned External Port created by the MAP Opcode or PEER
   Opcode SHOULD NOT be re-used for the same interval enforced by NAT
   for implicitly creating mappings, which is typically the maximum
   segment lifetime interval of 120
   seconds <xref target="RFC0793"></xref>.  To reduce port stealing
   attacks, the Assigned External Port SHOULD NOT be re-used by the
   same Client IP Address (or Internal IP Address if using the
   THIRD_PARTY Option) for the duration the PCP-controlled device
   keeps a mapping for active bi-directional traffic (e.g., 2 minutes
   for UDP <xref target="RFC4787"></xref>, 2 hours 4 minutes for
   TCP <xref target="RFC5382"></xref>).  However, within the above
   times, the PCP server SHOULD allow a request using the same
   Client IP Address (and same Internal IP Address if using the
   THIRD_PARTY Option), Internal Port, and Mapping Nonce to re-acquire
   the same External Port.</t>


<t>The assigned lifetime is calculated by subtracting (a) zero or the
number of seconds since the internal host sent a packet for this
mapping from (b) the lifetime the PCP-controlled device uses for
transitory connection idle-timeout (e.g., a NAT device might use 2
minutes for UDP <xref target="RFC4787"></xref> or 4 minutes for
TCP <xref target="RFC5382"></xref>).  If the result is a negative
number, the assigned lifetime is 0.</t>


<section title="Lifetime Processing for the MAP Opcode">
        <t>If the the requested lifetime is zero then:<list style="symbols">
            <t>If both the protocol and internal port are non-zero, it
            indicates a request to delete the indicated mapping immediately.</t>

            <t>If the protocol is non-zero and the internal port is zero, it
            indicates a request to delete a previous 'wildcard' (all-ports)
            mapping for that protocol.</t>

            <t>If both the protocol and internal port are zero, it
            indicates a request to delete all mappings for this
            Internal Address for all transport protocols.  Such a
            request is rejected with a NOT_AUTHORIZED error.  To
            delete all mappings the client has to send separate MAP
            requests with appropriate Mapping Nonce values.</t>

            <t>If the protocol is zero and the internal port is non-zero,
            then the request is invalid and the PCP Server MUST return
            a MALFORMED_REQUEST error to the client.</t>

          </list></t>

        <t>In requests where the requested Lifetime is 0, the
        Suggested External Address and Suggested External Port fields
        MUST be set to zero on transmission and MUST be ignored on
        reception, and these fields MUST be copied into the Assigned
        External IP Address and Assigned External Port of the response.</t>

<t>PCP MAP requests can only delete or shorten lifetimes of
   MAP-created mappings.  If the PCP client
   attempts to delete a static mapping (i.e., a mapping created
   outside of PCP itself), or an outbound (implicit or PEER-created)
   mapping, the PCP server MUST return NOT_AUTHORIZED.  If the PCP
   client attempts to delete a mapping that does not exist, the
   SUCCESS result code is returned (this is necessary for PCP to
   return the same response for the same request). 



<!-- no longer possible with Mapping Nonce change
 If the PCP MAP request was for
   port=0 (indicating 'all ports'), the PCP server deletes all of the
   explicit dynamic mappings it can (but not any implicit or static
   mappings), and returns a SUCCESS response.
-->

   If the deletion request was properly formatted and successfully
   processed, a SUCCESS response is generated with the assigned
   lifetime of the mapping and the server copies the protocol and
   internal port number from the request into the response.  An
   inbound mapping (i.e., static mapping or MAP- created dynamic
   mapping) MUST NOT have its lifetime reduced by transport protocol
   messages (e.g., TCP RST, TCP FIN).  Note the THIRD_PARTY Option, if
   authorized, can also delete PCP-created mappings
   (see <xref target="third_party"></xref>).</t>
</section>

      </section>



    <section anchor="implementation_considerations" title="Implementation Considerations">

      <t><xref target="implementation_considerations"/> provides
      non-normative guidance that may be useful to implementers.</t>

      <section anchor="EDM" title="Implementing MAP with EDM port-mapping NAT">

        <t>For implicit dynamic outbound mappings, some existing NAT devices have
        endpoint-independent mapping (EIM) behavior while other NAT devices
        have endpoint-dependent mapping (EDM) behavior. NATs which have EIM
        behavior do not suffer from the problem described in this section. The
        IETF strongly encourages EIM behavior
        <xref target="RFC4787"></xref><xref target="RFC5382"></xref>.</t>

        <t>In EDM NAT devices, the same external port may be used
        by an outbound dynamic mapping and an inbound dynamic mapping
        (from the same Internal Host or from a different Internal Host).
        This complicates the interaction with the MAP Opcode.  With such
        NAT devices, there are two ways envisioned to implement the MAP
        Opcode: <list style="numbers">
            <t>Have outbound mappings use a different set of External
            ports than inbound mappings (e.g., those created with MAP),
            thus reducing the interaction problem between them; or</t>

            <t>On arrival of a packet (inbound from the Internet or outbound from an
            Internal Host), first attempt to use a dynamic outbound mapping to
            process that packet. If none match, attempt to use an inbound mapping to
            process that packet. This effectively 'prioritizes' outbound mappings
            above inbound mappings.</t>
          </list></t>
      </section>

      <section title="Lifetime of Explicit and Implicit Dynamic Mappings">
        <t>No matter if a NAT is EIM or EDM, it is possible that one (or more)
        outbound mappings, using the same internal port on the
        Internal Host, might be created before or after a MAP request. When
        this occurs, it is important that the NAT honor the Lifetime returned
        in the MAP response. Specifically, if a mapping was created with the
        MAP Opcode, the implementation needs to ensure that termination of an
        outbound mapping (e.g., via a TCP FIN handshake) does not
        prematurely destroy the MAP-created inbound mapping.</t>
      </section>

      <section anchor="failurerecovery" title="PCP Failure Recovery">
        <t>If an event occurs that causes the PCP server to lose
        dynamic mapping state (such as a crash or power outage), the mappings
        created by PCP are lost. Occasional loss of state may be unavoidable
        in a residential NAT device which does not write transient
        information to non-volatile memory. Loss of state is expected
        to be rare in a service provider environment (due to redundant
        power, disk drives for storage, etc.). Of course, due to
        outright failure of service provider equipment (e.g., software
        malfunction), state may still be lost.</t>

        <t>The Epoch Time allows a client to deduce when a PCP server may have
        lost its state. When the Epoch Time value is observed to be outside the
        expected range, the PCP client can attempt to recreate the mappings
        following the procedures described in this section.</t>

        <t>Further analysis of PCP failure scenarios is in
        <xref target="I-D.boucadair-pcp-failure"></xref>.</t>

        <section title="Recreating Mappings" anchor="reboot">
<!--
          <t>The PCP server SHOULD store mappings in persistent storage so
          when it is powered off or rebooted, it remembers the port mapping
          state of the network. Due to the physical architecture of some PCP
          servers, this is not always achievable (e.g., some non-volatile
          memory can withstand only a certain number of writes, so writing PCP
          mappings to such memory is generally avoided).</t>

          <t>However, maintaining this state is not essential for correct
          operation.
-->
          <t>A mapping renewal packet is formatted identically to an original
          mapping request; from the point of view of the client it is a
          renewal of an existing mapping, but from the point of view of a
          newly rebooted PCP server it appears as a new mapping request. In
          the normal process of routinely renewing its mappings before they
          expire, a PCP client will automatically recreate all its lost
          mappings.</t>

          <t>When the PCP server loses state and begins processing new PCP
          messages, its Epoch time is reset and begins counting again. As the result
          of receiving a packet where the Epoch time field is outside the
          expected range (<xref target="epoch"></xref>), indicating that a reboot or similar loss of
          state has occurred, the client can renew its port mappings
          sooner, without waiting for the normal routine renewal time.</t>
        </section>

        <section title="Maintaining Mappings" anchor="maintaining_mappings">
          <t>A PCP client refreshes a mapping by sending a new PCP request
          containing information from the earlier PCP response. The PCP server
          will respond indicating the new lifetime. It is possible, due to
          reconfiguration or failure of the PCP server, that the External IP
          Address and/or External Port, or the PCP server itself, has changed
          (due to a new route to a different PCP server). Such events are
          rare, but not an error. The PCP server will simply return a new External
          Address and/or External Port to the client, and the client should
          record this new External Address and Port with its rendezvous service.
          To detect such events more quickly, a server that requires extremely high
          availability may find it beneficial to use shorter lifetimes in its
          PCP mappings requests, so that it communicates with the PCP
          server more often. This is an engineering trade-off based on
          (i) the acceptable downtime for the service in question,
          (ii) the expected likelihood of NAT or firewall state loss,
          and (iii) the amount of PCP maintenance traffic that is acceptable.</t>

          <t>If the PCP client has several mappings, the Epoch Time
          value only needs to be retrieved for one of them to determine
          whether or not it appears the PCP server may have suffered a
          catastrophic loss of state.
          If the client wishes to check the PCP server's Epoch Time, it sends a
          PCP request for any one of the client's mappings. This will return
          the current Epoch Time value. In that request the PCP client could extend
          the mapping lifetime (by asking for more time) or maintain the
          current lifetime (by asking for the same number of seconds that it
          knows are remaining of the lifetime).</t>

          <t>If a PCP client changes its Internal IP Address (e.g., because
          the Internal Host has moved to a new network), and the PCP client
          wishes to still receive incoming traffic, it needs create new
          mappings on that new network. New mappings will typically also
          require an update to the application-specific rendezvous server if
          the External Address or Port are different from the previous values
          (see <xref target="operating_a_server"></xref> and
          <xref target="renumbering"></xref>).</t>
        </section>


        <section title="SCTP">
          <t>Although SCTP has port numbers like TCP and UDP, SCTP works
          differently when behind an address-sharing NAT, in that SCTP port
          numbers are not changed <xref target="I-D.ietf-behave-sctpnat"></xref>.
          Outbound dynamic SCTP mappings use the verification tag of the
          association instead of the local and remote peer port numbers.  As
          with TCP, explicit outbound mappings can be made to reduce keepalive
          intervals, and explicit inbound mappings can be made by passive
          listeners expecting to receive new associations at the external
          port.</t>

          <t>Because an SCTP-aware NAT does not (currently) rewrite
          SCTP port numbers, it will not be able to assign an External
          Port that is different from the client's Internal Port. A
          PCP client making a MAP request for SCTP should be aware of
          this restriction. The PCP client SHOULD make its SCTP MAP
          request just as it would for a TCP MAP request: in its
          initial PCP MAP request it SHOULD specify zero for the
          External Address and Port, and then in subsequent renewals
          it SHOULD echo the assigned External Address and
          Port. However, since a current SCTP-aware NAT can only
          assign an External Port that is the same as the Internal
          Port, it may not be able to do that if the External Port is
          already assigned to a different PCP client. This is likely
          if there is more than one instance of a given SCTP service
          on the local network, since both instances are likely to
          listen on the same well-known SCTP port for that service on
          their respective hosts, but they can't both have the same
          External Port on the NAT gateway's External Address.  A
          particular External Port may not be assignable for other
          reasons, such as when it is already in use by the NAT device
          itself, or otherwise prohibited by policy, as described
          in <xref target="map-opcode_server_operation"></xref>.  In
          the event that the External Port matching the Internal Port
          cannot be assigned (and the SCTP-aware NAT does not perform
          SCTP port rewriting) then the SCTP-aware NAT MUST return a
          CANNOT_PROVIDE_EXTERNAL error to the requesting PCP
          client. Note that this restriction places extra burden on
          the SCTP server whose MAP request failed, because it then
          has to tear down its exiting listening socket and try again
          with a different Internal Port, repeatedly until it is
          successful in finding an External Port it can use.</t>

          <t>The SCTP complications described above occur because of
          address sharing.  The SCTP complications are avoided when
          address sharing is avoided (e.g., 1:1 NAT, firewall).</t>
        </section>

      </section>

      <section title="Source Address Replicated in PCP Header" anchor="implement_source_address">
        <t>All PCP requests include the PCP client's IP address replicated in
        the PCP header.  This is used to detect address rewriting (NAT)
        between the PCP client and its PCP server.  On operating systems that
        support the sockets API, the following steps are RECOMMENDED for a PCP
        client to insert the correct source address and port in the
        PCP header:</t>

        <t><list style="numbers">
            <?rfc subcompact="yes"?>
            <t>Create a UDP socket.</t>
            <t>Call "connect" on this UDP socket using the
            address and port of the desired PCP server.</t>
            <t>Call the getsockname() function to retrieve a sockaddr
            containing the source address the kernel will use
            for UDP packets sent through this socket.</t>
            <t>If the IP address is an IPv4 address, encode the
            address into an IPv4-mapped IPv6 address.  Place the
            native IPv6 address or IPv4-mapped IPv6 address into
            the PCP Client's IP Address field in the PCP header.</t>
            <t>Send PCP requests using this connected UDP socket.</t>
            <?rfc subcompact="no"?>
          </list></t>
</section>

<section anchor="state_section" title="State Diagram">

<t>Each mapping entry of the PCP-controlled device would go through the 
state machine shown below.  This state diagram is non-normative.</t>

<figure align="left" anchor="state_diagram" title="PCP State Diagram">
        <artwork align="center"><![CDATA[
  CLOSE_MSG or
 (NO_TRAFFIC and EXPIRY)   +---------+  NO_TRAFFIC and EXPIRY
           +-------------->|         |<------------+
           |               |NO_ENTRY |             |
           |   +-----------|         |---------+   |
           |   |           +---------+         |   |
           |   |              ^  |             |   |
           |   |   NO_TRAFFIC |  |             |   |
           |   |           or |  |             |   |
           |   |   CLOSE_MSGS |  |             |   |
           |   |              |  |             |   |
           |   |PEER request  |  |  MAP request|   |
           |   V              |  |             V   |
        +---------+           |  |         +---------+
    +-->|  "P",   |           |  |    M-R  |  "M",   |<--+
P-R |   | PEER    |-----------|--|-------->| MAP     |   | M-R or
    +---|  mapping|           |  |         |  mapping|---+ P-R or
        +---------+           |  |         +---------+  CLOSE_MSGS
           |   ^              |  |             ^   |              
           |   |PEER request  |  |  MAP request|   |
           |   |              |  |             |   |
           |   |              |  |             |   |
           |   |              |  |             |   |
           |   |              |  | outbound    |   |
           |   |              |  | TRAFFIC     |   |
           |   |              |  V             |   |       
           |   |           +---------+         |   |             
           |   +-----------| "I",    |---------+   |
           |               | implicit|             |
           +-------------->| mapping |<------------+
       TRAFFIC and EXPIRY  +---------+  TRAFFIC and EXPIRY
]]></artwork>
      </figure>

<?rfc needLines="15" ?>
<t>The meanings of the states and events are:
<list style="hanging"  hangIndent="8">

<t hangText="  NO_ENTRY:">Invalid state represents Entry does not
                exist. This is the only possible start state.</t>

<t hangText="  M-R:">MAP request</t>

<t hangText="  P-R:">PEER request</t>

<t hangText="  M:">Mapping entry when created by MAP request</t>

<t hangText="  P:">Mapping entry when created/managed by PEER request</t>

<t hangText="  I:">Implicit mapping created by an outgoing packet from
the client (e.g., TCP SYN), and also the state when a PCP-created
mapping's lifetime expires while there is still active traffic.</t>

<t hangText="  EXPIRY:">PEER or MAP lifetime expired</t>

<t hangText="  TRAFFIC:">Traffic seen by PCP-controlled device using
this entry within the expiry time for that entry.  This
traffic may be inbound or outbound.</t>

<t hangText="  NO_TRAFFIC:">Indicates that there is no TRAFFIC.</t>

<t hangText="  CLOSE_MSG:">Protocol messages from the client or server
      to close the session (e.g., TCP FIN or TCP RST), as per the NAT
      or firewall device's handling of such protocol messages.</t>

</list></t>

<t>Notes on the diagram:<list style="numbers">
<t>The 'and' clause indicates the events on either side of 'and' are
    required for the state-transition.  The 'or' clause indicates
    either one of the events are enough for the state-transition.</t>
<t>Transition from state M to state I is implementation dependent.</t>
</list></t>
</section>






    </section>

    <!--
    <section anchor="scenarios" title="Deployment Scenarios">
      <section title="Dual-Stack Lite">
        <t>The interesting components in a Dual-Stack Lite deployment are the
        B4 element (which is the customer premises router) and the
        Address Family Transition Router (AFTR) element. The AFTR element
        terminates the IPv6-over-IPv4 tunnel and also implements a
        Carrier-Grade NAT44 function. The B4 element does not need to perform
        a NAT function (and usually does not perform a NAT function), but it
        does operate its own DHCP server and is the local network's default
        router.</t>

          <t>Various PCP deployment scenarios can be considered to control the
          PCP server in the AFTR element:<list style="numbers">
              <t>If UPnP IGDv1 and NAT-PMP
              <xref target="I-D.cheshire-nat-pmp"></xref> are used in the LAN: an
              interworking function is required to be implemented by the B4
              element to ensure interworking between the protocol used in the
              LAN and PCP. Details of this interworking function are left for future work.</t>


              <t>Hosts behind the B4 element will either include a PCP client, UPnP IGDv1 client, NAT-PMP client, or combination of these three.  <list style="letters">
                  <t>if a UPnP IGDv1 client, the B4 element will need to include
                  an interworking function from UPnP IGDv1 to PCP.</t>

                  <t>if a PCP client, the PCP client will communicate
                  directly with its nearest PCP server (e.g., built
                  into its B4 element).</t>
<t>if a NAT-PMP client, the NAT-PMP client will communicate with its default gateway (its B4 element), which will proxy NAT-PMP to the Dual-Stack Lite AFTR element.  Details of this proxy function are left for future work.</t>
                </list></t>

              <t>The B4 element includes a PCP client which is invoked by an
              HTTP-based configuration (as is common today). The internal IP
              address field in the PCP payload would be the Internal Host used
              in the port forwarding configuration.</t>
            </list></t>

          <t>In Dual-Stack Lite, the B4 element encapsulates its PCP messages
          into the IPv6 tunnel towards the AFTR element.  When proxying
          for other hosts, the B4 element will use the THIRD_PARTY
          Option with the MAP and PEER Opcodes.</t>
      </section>

      <section title="NAT64">
        <t>Hosts behind a NAT64 device can make use of PCP in order to
        perform port reservation (to get a publicly routable IPv4
        port).  For example, in such situations, the IPv6 host can use
        the MAP4 Opcode to operate a server that listens on the IPv4
        Internet.</t>

        <t>If the IANA-assigned IP address is used for the discovery of the
        PCP server, that IPv4 address can be placed into the IPv6 destination
        address following that particular network's well-known prefix or
        network-specific prefix, per <xref target="RFC6052"></xref>.</t>

      </section>

      <section title="NAT44 and NAT444">
        <t>Residential subscribers in NAT44 (and NAT444) deployments are
        usually given one IPv4 address, but may also be given several IPv4
        addresses. These addresses are not routable on the IPv4 Internet, but
        are routable between the subscriber's home and the ISP's CGN. To
        accommodate multiple hosts within a home, especially when provided
        insufficient IPv4 addresses for the number of devices in the home,
        subscribers operate a NAT device. When this occurs in conjunction
        with an upstream NAT44, this is nicknamed "NAT444".</t>


<list style="empty">
            <t>[Ed.&#160;Note: Does PCP need a mechanism to detect a
            non-PCP-supporting NAT between a PCP client and a PCP server? Or
            can that problem be detected by relying on the failure of PCP
            server Discovery? This is tracked as PCP Issue #25
            <xref target="PCP-Issues"></xref>.]</t>
          </list></t>

      </section>

      <section title="IPv6 Simple Firewall">
        <t>Many IPv6 deployments will include a <xref target="RFC6092">simple
        firewall</xref>, which permits outgoing packets to initiate
        bi-directional communication but blocks unsolicited incoming packets,
        which is similar to PCP's security model that allows a host to create
        a mapping to itself. In many situations, especially residential
        networks that lack an IT staff, the security provided by an IPv6
        simple firewall and the security provided by PCP are compatible. In
        such situations, the IPv6 simple firewall and the IPv6 host can use
        the MAP6 Opcode to allow unsolicited incoming packets, so the host can
        operate a server.</t>
      </section>
    </section>
-->

    <!--
    <section anchor="upnp-interworking" title="Interworking with UPnP IGD 1.0 and 2.0">
      <t><list style="empty">
          <t>[Ed.&nbsp;Note: This UPnP IGD Interworking section will likely be
          moved to a separate document which will fully describe how a proxy
          needs to translate UPnP IGD messages into PCP messages. This is
          tracked as PCP Issue #28 <xref target="PCP-Issues"></xref>.]</t>
        </list></t>

      <t>The following diagram shows how UPnP IGD can be interworked with PCP,
      using an interworking function (IWF).</t>

      <figure align="center" anchor="igd-interworking-function" title="Network Diagram, Interworking UPnP IGD and PCP">
        <artwork><![CDATA[

xxx
]]></artwork>
      </figure>

      <section title="UPnP IGD 1.0 with AddPortMapping Action">
        <t>In <xref target="IGDv1">UPnP IGD 1.0</xref> it is only possible to
        request a specific port using the AddPortMapping action. Requiring a
        specific port is incompatible with both (1) a Carrier-Grade NAT and
        with (2) widely-deployed applications. Regarding (1), another
        subscriber is likely to already be using the same port, so it will be
        unavailable to this application to operate a server. Regarding (2), if
        the same popular application exists on two devices behind the same
        NAT, they cannot both get the same port. PCP cannot correct this
        behavior of UPnP IGD:1, but PCP does work with this behavior.</t>

        <t>Due to this incompatibility with address sharing and popular
        applications, future hosts and applications will either support UPnP
        IGD 2.0's AddAnyPortMapping method (see
        <xref target="upnp-2-interworking"></xref>) or, more likely, will support
        PCP natively.</t>

        <t>When a requested port assignment fails, most UPnP IGD control
        points will retry the port assignment requesting the next higher port
        or requesting a random port. These UPnP IGD requests are translated to
        PCP requests and sent to the PCP server. The requests include the
        PREFER_FAILURE Option, which causes the PCP server to return an error
        if it cannot allocate the suggested port. The interworking function
        translates the PCP error response to a UPnP IGD error response. This
        repeats until the UPnP IGD client gives up or until the PCP server is
        able to return the suggested port.</t>

        <figure align="left" anchor="message-flow-upnp-1"
                title="Message Flow: Interworking from UPnP IGD 1.0 AddPortMapping action to PCP">
          <preamble>Message flow would be similar to this:</preamble>

          <artwork align="center"><![CDATA[
UPnP Control Point             in-home CPE                 PCP server

xxx
]]></artwork>
        </figure>
      </section>

      <section anchor="upnp-2-interworking" title="UPnP IGD 2.0 with AddAnyPortMapping Action">
        <t>If the UPnP IGD control point and the UPnP IGD interworking
        function both implement <xref target="IGD-2">UPnP IGD 2.0</xref> and
        the UPnP IGD control point uses IGD 2's new AddAnyPortMapping action,
        only one round-trip is necessary. This is because AddAnyPortMapping
        has semantics similar to PCP's semantics, allowing the PCP server to
        assign any port.</t>

        <figure align="left" anchor="message-flow-upnp-2"
                title="Message Flow: Interworking from UPnP IGD 2.0 AddAnyPortMapping action to PCP">
          <preamble>Message flow would be similar to this:</preamble>

          <artwork align="center"><![CDATA[
UPnP Control Point           in-home CPE                 PCP server

xxx

]]></artwork>
        </figure>
      </section>

      <section title="Lifetime Maintenance">
        <t>UPnP IGD 1.0 and 2.0 provide a lifetime (PortMappingLeaseDuration),
        but it is seldom used by UPnP IGD control points, and does not allow
        the UPnP IGD to override the requested duration. Thus, the UPnP
        IGD/PCP interworking function is responsible for extending the
        lifetime of mappings that are still interesting to the UPnP IGD
        control point.</t>

        <t><list style="empty">
            <t>Note: It can be an implementation advantage, where possible,
            for the UPnP IGD/PCP interworking function to request a port
            mapping lifetime only while that client is active and connected.
            For example, creating a PCP mapping that is equal to the client's
            remaining DHCP lifetime is one useful approach.</t>
          </list></t>
      </section>
    </section>

-->

    <?rfc needLines="6" ?>
    <section title="Deployment Considerations">
      <section title="Ingress Filtering" anchor="ingress_filtering">
        <t>As with implicit dynamic mappings created by outgoing TCP SYN packets,
        explicit dynamic mappings created via PCP use the source IP address of
        the packet as the Internal Address for the mappings. Therefore
        <xref target="RFC2827">ingress filtering</xref> SHOULD be used on the path
        between the Internal Host and the PCP Server to prevent the injection
        of spoofed packets onto that path.</t>
      </section>

      <section anchor="quota" title="Mapping Quota">
        <t>On PCP-controlled devices that create state when a mapping is
        created (e.g., NAT), the PCP server SHOULD maintain per-host and/or
        per-subscriber quotas for mappings. It is implementation-specific
        whether the PCP server uses a separate quotas for implicit, explicit,
        and static mappings, a combined quota for all of them, or some other
        policy.</t>
      </section>
    </section>

    <?rfc needLines="6" ?>
    <section anchor="security" title="Security Considerations">

      <t>The goal of the PCP protocol is to improve the ability of end
      nodes to control their associated NAT state, and to improve the
      efficiency and error handling of NAT mappings when compared to
      existing implicit mapping mechanisms in NAT boxes and stateful
      firewalls.  It is the security goal of the PCP protocol to limit
      any new denial of service opportunities, and to avoid introducing
      new attacks that can result in unauthorized changes to mapping
      state.  One of the most serious consequences of unauthorized
      changes in mapping state is traffic theft.  All mappings that
      could be created by a specific host using implicit mapping
      mechanisms are inherently considered to be authorized.
      Confidentiality of mappings is not a requirement, even in cases
      where the PCP messages may transit paths that would not be
      travelled by the mapped traffic.</t>

      <section anchor="SimpleThreat" title="Simple Threat Model">
        <t>PCP is secure against off-path attackers who cannot spoof a
        packet that the PCP Server will view as a packet received from
        the internal network.  PCP is secure against off-path attackers
        who can spoof the PCP server's IP address.</t>

        <t>Defending against attackers who can modify or drop packets
        between the internal network and the PCP server, or who can
        inject spoofed packets that appear to come from the internal
        network is out of scope.  Such an attacker can re-direct traffic
        to a host of their choosing.</t>

        <t>A PCP Server is secure under this threat model if the PCP
        Server is constrained so that it does not configure any
        explicit mapping that it would not configure implicitly.  In
        most cases, this means that PCP Servers running on NAT boxes
        or stateful firewalls that support the PEER and MAP Opcodes can
        be secure under this threat model if (1) all of their hosts
        are within a single administrative domain (or if the internal
        hosts can be securely partitioned into separate administrative
        domains, as in the DS-Lite B4 case), (2) explicit mappings are
        created with the same lifetime as implicit mappings, and (3)
        the THIRD_PARTY option is not supported.  PCP Servers can also
        securely support the MAP Opcode under this threat model if the
        security policy on the device running the PCP Server would
        permit endpoint independent filtering of implicit
        mappings.</t>

        <t>PCP Servers that comply with the Simple Threat Model and do
        not implement a PCP security mechanism described in
        <xref target="AdvancedThreat"/> MUST enforce the constraints
        described in the paragraph above.</t>

        <?rfc needLines="6" ?>
        <section title="Attacks Considered" anchor="AttacksConsidered">
          <t><list style='symbols'>
            <t>If you allow multiple administrative domains to send PCP
            requests to a single PCP server that does not enforce a
            boundary between the domains, it is possible for a node in
            one domain to perform a denial of service attack on other
            domains, or to capture traffic that is intended for a node
            in another domain.</t>

            <t>If explicit mappings have longer lifetimes than implicit
            mappings, it makes it easier to perpetrate a denial of
            service attack than it would be if the PCP Server was not
            present.</t>

            <t>If the PCP Server supports deleting or reducing the
            lifetime of existing mappings, this allows an attacking node
            to steal an existing mapping and receive traffic that was
            intended for another node.</t>

            <t>If the THIRD_PARTY Option is supported, this also allows
            an attacker to open a window for an external node to attack
            an internal node, allows an attacker to steal traffic that
            was intended for another node, or may facilitate a denial of
            service attack.  One example of how the THIRD_PARTY Option
            could grant an attacker more capability than a spoofed
            implicit mapping is that the PCP server (especially if it is
            running in a service provider's network) may not be aware of
            internal filtering that would prevent spoofing an equivalent
            implicit mapping, such as filtering between a guest and
            corporate network.</t>

            <t>If the MAP Opcode is supported by the PCP server in
            cases where the security policy would not support endpoint
            independent filtering of implicit mappings, then the MAP
            Opcode changes the security properties of the device running
            the PCP Server by allowing explicit mappings that violate
            the security policy.</t>
          </list></t>
        </section>

        <section title="Deployment Examples Supporting the Simple Threat Model">
          <t>This section offers two examples of how the Simple Threat
          Model can be supported in real-world deployment scenarios.</t>
          <section title="Residential Gateway Deployment">
            <t>Parity with many currently-deployed residential gateways
            can be achieved using a PCP Server that is constrained as
            described in <xref target="SimpleThreat"/> above.</t>
          </section>

<!--
          <section anchor="DSLiteDeployment" title="DS-Lite Deployment">
            <t>A DS-Lite deployment could be secure under the Simple
            Threat Model, even if the B4 device makes PCP mapping
            requests on behalf of internal clients using the THIRD_PARTY
            option.  In this case the DS-Lite PCP server MUST be
            configured to only allow the B4 device to make THIRD_PARTY
            requests, and only on behalf of other Internal Hosts sharing
            the same DS-Lite IPv6 tunnel.  The B4 device MUST guard
            against spoofed packets being injected into the IPv6 tunnel
            using the B4 device's IPv4 source address, so the DS-Lite
            PCP Server can trust that packets received over the DS-Lite
            IPv6 tunnel with the B4 device's source IPv4 address do in
            fact originate from the B4 device. The B4 device is in a
            position to enforce this requirement, because it is the
            DS-Lite IPv6 tunnel endpoint.</t>

            <t>Allowing the B4 device to use the THIRD_PARTY Option to
            create mappings for hosts reached via the IPv6 tunnel
            terminated by the B4 device is acceptable, because the B4
            device is capable of creating these mappings implicitly and
            can prevent others from spoofing these mappings.</t>
          </section>
-->
        </section>
      </section>

      <section anchor="AdvancedThreat" title="Advanced Threat Model">
        <t>In the Advanced Threat Model the PCP protocol ensures
        that attackers (on- or off-path) cannot create unauthorized
        mappings or make unauthorized changes to existing mappings.
        The protocol must also limit the opportunity for on- or off-path
        attackers to perpetrate denial of service attacks.</t>

        <t>The Advanced Threat Model security model will be needed in
        the following cases:</t>

        <t><list style='symbols'>
          <t>Security infrastructure equipment, such as corporate
          firewalls, that does not create implicit mappings.</t>

          <t>Equipment (such as CGNs or service provider firewalls) that
          serve multiple administrative domains and do not have a
          mechanism to securely partition traffic from those
          domains.</t>

          <t>Any implementation that wants to be more permissive in
          authorizing explicit mappings than it is in authorizing
          implicit mappings.</t>

<!--
          <t>Implementations that support the THIRD_PARTY Option (unless
          they can meet the constraints outlined in
          <xref target="DSLiteDeployment"/>).</t>
-->

          <t>Implementations that wish to support any deployment
          scenario that does not meet the constraints described in
          <xref target="SimpleThreat"/>.</t>
        </list></t>

        <t>To protect against attacks under this threat model, a
        PCP security mechanism that
        provides an authenticated, integrity-protected signaling
        channel would need to be specified.</t>

        <t>PCP Servers that implement a PCP security mechanism MAY
        accept unauthenticated requests.  PCP Servers implementing the
        PCP security mechanism MUST enforce the constraints described in
        <xref target="SimpleThreat"/> above, in their default
        configuration, when processing unauthenticated requests.</t>

      </section>

      <section title="Residual Threats">
        <t>This section describes some threats that are not addressed in
        either of the above threat models, and recommends appropriate
        mitigation strategies.</t>

        <section title="Denial of Service">
          <t>Because of the state created in a NAT or firewall, a
          per-host and/or per-subscriber quota will likely exist for
          both implicit dynamic mappings and explicit dynamic mappings.
          A host might make an excessive number of implicit or explicit
          dynamic mappings, consuming an inordinate number of ports,
          causing a denial of service to other hosts.
          Thus, <xref target="quota"/> recommends that hosts be limited
          to a reasonable number of explicit dynamic mappings.</t>

          <t>An attacker, on the path between the PCP client and PCP
          server, can drop PCP requests, drop PCP responses, or spoof
          a PCP error, all of which will effectively deny service.
          Through such actions, the PCP client might not be aware the
          PCP server might have actually processed the PCP request.
          An attacker sending a NO_RESOURCES error can cause the PCP
          client to not send messages to that server for a while.  There
          is no mitigation to this on-path attacker.</t>
        </section>

        <section title="Ingress Filtering">
          <t>It is important to prevent a host from fraudulently
          creating, deleting, or refreshing a mapping (or filtering)
          for another host, because this can expose the other host to
          unwanted traffic, prevent it from receiving wanted traffic,
          or consume the other host's mapping quota. Both implicit and
          explicit dynamic mappings are created based on the source IP
          address in the packet, and hence depend on ingress filtering
          to guard against spoof source IP addresses.</t>
        </section>

        <section title="Mapping Theft">
          <t>In the time between when a PCP server loses state and the
          PCP client notices the lower-than-expected Epoch Time value, it is
          possible that the PCP client's mapping will be acquired by
          another host (via an explicit dynamic mapping or implicit
          dynamic mapping).  This means incoming traffic will be sent to
          a different host ("theft").  Rapid Recovery reduces
          this interval, but would not completely eliminate this threat.
          The PCP client can reduce this interval by using a relatively
          short lifetime; however, this increases the amount of PCP
          chatter.  This threat is reduced by using persistent storage
          of explicit dynamic mappings in the PCP server (so it does not
          lose explicit dynamic mapping state), or by ensuring the
          previous external IP address, protocol, and port cannot be used by
          another host (e.g., by using a different IP address pool).</t>
        </section>

        <section title="Attacks Against Server Discovery">
<t>This document does not specify server discovery, beyond contacting
the default gateway.</t>
        </section>
      </section>

    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>IANA is requested to perform the following actions:</t>

      <section anchor="iana_port" title="Port Number">
        <t>PCP will use ports 5350 and 5351 (currently assigned by IANA to
        <xref target="I-D.cheshire-nat-pmp">NAT-PMP</xref>). We request that IANA
        re-assign those ports to PCP, and relinquish UDP port 44323.</t>

        <t>[Note to RFC Editor: Please remove the text about relinquishing
        port 44323 prior to publication.]</t>
      </section>

      <section anchor="iana_opcodes" title="Opcodes">
        <t>IANA shall create a new protocol registry for PCP Opcodes,
        numbered 0-127, initially populated with the values:</t>

      <figure>
        <artwork align="center"><![CDATA[
value            Opcode
-----            -------------------------
0                ANNOUNCE
1                MAP
2                PEER
3-31             Standards Action [RFC5226]
32-63            Specification Required [RFC5226]
96-126           Private Use [RFC5226]
127              Reserved, Standards Action [RFC5226]]]></artwork>
      </figure>

        <t>The value 127 is Reserved and may be assigned via
<xref target="RFC5226">Standards Action</xref>.  
The values in the
range 3-31 can be assigned via <xref target="RFC5226">Standards
Action</xref>, 32-63 via <xref target="RFC5226">Specification
Required</xref>, and 96-126 is for <xref target="RFC5226">Private
Use</xref>.</t>


      </section>

      <section anchor="iana_result_codes" title="Result Codes">
        <t>IANA shall create a new registry for PCP result codes, numbered
        0-255, initially populated with the result codes from
        <xref target="result_codes"></xref>. The value 255 is Reserved
        and may be assigned via <xref target="RFC5226">Standards
        Action</xref>.</t>

<t>The values in the
range 14-127 can be assigned via <xref target="RFC5226">Standards
Action</xref>, 128-191 via <xref target="RFC5226">Specification
Required</xref>, and 191-254 is for <xref target="RFC5226">Private
Use</xref>.</t>
      </section>

      <section anchor="iana_ie" title="Options">
        <t>IANA shall create a new registry for PCP Options, numbered
        0-255, each with an associated mnemonic. The values 0-127 are
        mandatory-to-process, and 128-255 are optional to process. The
        initial registry contains the Options described in
        <xref target="map_peer_options"/>.  The Option values 0, 127 and
        255 are Reserved and may be assigned
        via <xref target="RFC5226">Standards Action</xref>.</t>

        <t>Additional PCP Option codes in the ranges 4-63 and 128-191
        can be created via <xref target="RFC5226">Standards Action
        </xref>, the ranges 64-95 and 192-223 are for 
<xref target="RFC5226">Specification Required</xref> and the ranges
96-126 and 224-254 are for <xref target="RFC5226">Private
Use</xref>.</t>

        <t>Documents describing an Option should describe if the
        processing for both the PCP client and server and the
        information below: <list style="empty">
        <?rfc subcompact="yes"?>
            <t>Option Name: &lt;mnemonic&gt;</t>
            <t>Number: &lt;value&gt;</t>
            <t>Purpose: &lt;textual description&gt;</t>
            <t>Valid for Opcodes: &lt;list of Opcodes&gt;</t>
            <t>Length: &lt;rules for length&gt;</t>
            <t>May appear in: &lt;requests/responses/both&gt;</t>
            <t>Maximum occurrences: &lt;count&gt;</t>
            <?rfc subcompact="no"?>
        </list></t>

      </section>
    </section>

    <section title="Acknowledgments">
      <t>Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet,
      Jacni Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU),
      Felipe Miranda Costa, James Woodyatt, Dave Thaler, Masataka
      Ohta, Vijay K. Gurbani, Loa Andersson, Richard Barnes, Russ
      Housley, Adrian Farrel, Pete Resnick, Pasi Sarolahti, Robert
      Sparks, Wesley Eddy, Dan Harkins, Peter Saint-Andre, Stephen
      Farrell, Ralph Droms, Felipe Miranda Costa, Amit Jain, and Wim
      Henderickx for their comments and review.</t>
<t>Thanks to Simon Perreault for highlighting the
      interaction of dynamic connections with PCP-created
      mappings.</t>

      <t>Thanks to Francis Dupont for his several thorough reviews of the
      specification, which improved the protocol significantly.</t>

      <t>Thanks to T. S. Ranganathan for the state diagram.</t>

      <t>Thanks to Peter Lothberg for clock skew information.</t>

      <t>Thanks to Margaret Wasserman and Sam Hartman for writing the
      Security Considerations section.</t>

      <t>Thanks to authors of DHCPv6 for retransmission text.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.0768"?>
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.2827"?>
      <?rfc include='reference.RFC.4086'?>
      <?rfc include='reference.RFC.4193'?>
      <?rfc include='reference.RFC.4291'?>
      <?rfc include="reference.RFC.5226"?>
      <?rfc include='reference.RFC.6056'?>

      <reference anchor="proto_numbers"
                 target="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml">
        <front>
          <title>Protocol Numbers</title>
          <author fullname="IANA" surname="IANA">
            <organization></organization>
          </author>
          <date year="2011" />
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.3007'?>
      <?rfc include='reference.RFC.2136'?>
      <?rfc include='reference.RFC.0793'?>
      <?rfc include='reference.RFC.4303'?>
      <?rfc include='reference.RFC.1918'?>
      <?rfc include='reference.RFC.3022'?>
      <?rfc include='reference.RFC.3581'?>
      <?rfc include='reference.RFC.3587'?>
      <?rfc include='reference.RFC.4941'?>
      <?rfc include='reference.RFC.4961'?>
      <?rfc include='reference.RFC.5382'?>
      <?rfc include='reference.RFC.4787'?>
      <?rfc include='reference.RFC.6092'?>
      <?rfc include='reference.RFC.6296'?>
      <?rfc include='reference.RFC.6145'?>
      <?rfc include='reference.RFC.6146'?>
      <?rfc include='reference.RFC.6333'?>
      <?rfc include='reference.RFC.4960'?>
      <?rfc include='reference.RFC.4340'?>
      <?rfc include='reference.I-D.miles-behave-l2nat'?>
<!--      <?rfc include='reference.I-D.penno-pcp-zones'?> -->
      <?rfc include='reference.I-D.ietf-behave-sctpnat'?>
      <?rfc include='reference.I-D.ietf-pcp-upnp-igd-interworking'?>
      <?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
      <?rfc include='reference.I-D.cheshire-nat-pmp'?>
      <!--<?rfc include='reference.I-D.cheshire-pcp-recovery'?>-->
      <?rfc include='reference.RFC.6619'?>
      <?rfc include='reference.I-D.boucadair-pcp-failure'?>
      <!-- <?rfc include='reference.I-D.dupont-pcp-dslite'?> -->

      <!--
      <?rfc include='reference.RFC.5461'?>
      <?rfc include='reference.RFC.3424'?>
      -->
      <?rfc include='reference.I-D.cheshire-dnsext-dns-sd'?>

<!--
      <reference anchor="Bonjour"
                 target="http://en.wikipedia.org/wiki/Bonjour_(software)">
        <front>
          <title>Bonjour</title>
          <author></author>
          <date />
        </front>
      </reference>
-->

      <reference anchor="IGDv1"
                 target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf">
        <front>
          <title>WANIPConnection:1</title>
          <author fullname="UPnP Gateway Committee"
                  surname="UPnP Gateway Committee">
            <organization>UPnP Forum</organization>
          </author>
          <date month="November" year="2001" />
        </front>
      </reference>

      <!--
      <reference anchor="IGD-2"
                 target="http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf">
        <front>
          <title>Internet Gateway Device (IGD) V 2.0</title>

          <author fullname="UPnP Gateway Committee"
                  surname="UPnP Gateway Committee">
            <organization>UPnP Forum</organization>
          </author>

          <date month="September" year="2010" />
        </front>
      </reference>
-->

      <!--
      <reference anchor="PCP-Issues"
                 target="http://trac.tools.ietf.org/wg/pcp/trac/report/1">
        <front>
          <title>PCP Active Tickets</title>

          <author fullname="PCP Working Group" surname="PCP Working Group">
            <organization>IETF</organization>
          </author>

          <date month="January" year="2011" />
        </front>
      </reference>
-->

      <!--
      <reference anchor="I-D.bpw-pcp-proxy">
        <front>
          <title>Port Control Protocol (PCP) Proxy Function</title>

          <author fullname="Mohammed Boucadair" initials="M"
                  surname="Boucadair">
            <organization></organization>
          </author>

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

          <author fullname="Dan Wing" initials="D" surname="Wing">
            <organization></organization>
          </author>

          <author fullname="Francis Dupont" initials="F" surname="Dupont">
            <organization></organization>
          </author>

          <date day="27" month="February" year="2011" />

          <abstract>
            <t>This document specifies the behavior of a PCP Proxy element,
            for instance implemented in Customer Premises routers.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-bpw-pcp-proxy-00" />

        <format target="http://www.ietf.org/internet-drafts/draft-bpw-pcp-proxy-00.txt"
                type="TXT" />
      </reference>
-->

      <!--
      <reference anchor="I-D.wing-pcp-nested-nat">
        <front>
          <title>Using PCP With One Nested NAT</title>

          <author fullname="Dan Wing" initials="D" surname="Wing">
            <organization></organization>
          </author>

          <date month="January" year="2011" />
        </front>

        <seriesInfo name="Internet-Draft" value="draft-wing-pcp-nested-nat-00" />

        <format target="http://www.ietf.org/internet-drafts/draft-wing-pcp-nested-nat-00.txt"
                type="TXT" />
      </reference>
-->
    </references>

    <section title="NAT-PMP Transition">
      <t>The Port Control Protocol (PCP) is a successor to the NAT Port
      Mapping Protocol, <xref target="I-D.cheshire-nat-pmp">NAT-PMP</xref>,
      and shares similar semantics, concepts, and packet formats. Because of
      this NAT-PMP and PCP both use the same port, and use NAT-PMP and PCP's
      version negotiation capabilities to determine which version to use. This
      section describes how an orderly transition may be achieved.</t>

      <t>A client supporting both NAT-PMP and PCP SHOULD send its request
      using the PCP packet format. This will be received by a NAT-PMP server
      or a PCP server. If received by a NAT-PMP server, the response will be
      as indicated by <xref target="I-D.cheshire-nat-pmp">the NAT-PMP
      specification</xref>, which will cause the client to downgrade to
      NAT-PMP and re-send its request in NAT-PMP format. If received by a PCP
      server, the response will be as described by this document and
      processing continues as expected.</t>

      <t>A PCP server supporting both NAT-PMP and PCP can handle requests in
      either format. The first octet of the packet indicates if it is NAT-PMP
      (first octet zero) or PCP (first octet non-zero).</t>

      <t>A PCP-only gateway receiving a NAT-PMP request (identified by the
      first octet being zero) will interpret the request as a version mismatch.
      Normal PCP processing will emit a PCP response that is compatible with
      NAT-PMP, without any special handling by the PCP server.</t>
    </section>

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

<section title="Changes from draft-ietf-pcp-base-28 to -29">
        <t><list style="symbols">
<t>Removed text suggesting PCP client can remove old mappings when
it acquires a new IP address.</t>
</list></t>
</section>

<section title="Changes from draft-ietf-pcp-base-27 to -28">
        <t><list style="symbols">
<t>When processing MAP request or processing PEER request, Mapping Nonce
validation only applies to Basic Threat Model, and not to THIRD_PARTY.</t>
<t>A maximum payload size of 1100 keeps PCP packets below IPv6's 1280
MTU limit while still allowing some room for encapsulation.  This
accomodates EAP over PANA over PCP (EAP needs 1020 octets, per
RFC3748), should PCP authentication decide to use EAP over PANA over
PCP.</t>
<t>Both MAP and PEER-created mappings cannot have their lifetimes
reduced beyond normal UDP/TCP timesouts.</t>
<t>Disallow re-assigning External Port to same internal host.</t>
</list></t>
</section>

<section title="Changes from draft-ietf-pcp-base-26 to -27">
        <t><list style="symbols">
<t>For table, reverted the NAT64 remote peer to IPv6 -- because
from the IPv6 PCP client's perspective, the remote peer really is
IPv6.</t>
<t>"list of PCP server addresses" changed to "longer list of PCP
server addresses"</t>
<t>Clarify that unsolicited ANNOUNCE messages are sent from the PCP
server IP address and PCP port.</t>
<t>"1024 bytes" changed to "1024 octets".</t>
<t>Clarify that re-transmitted requests must use same Mapping Nonce
value (beginning of <xref target="retransmission"></xref>).</t>
<t>Describe that de-synchronization that can occur (end of 
<xref target="retransmission"></xref>).</t>
<t>For devices that lose state or expect IP renumbering, Rapid
Recovery is now a MUST, with SHOULD for implementing both multicast
Announce mechanism and unicast mechanisms.</t>
<t>For refreshing MAP or PEER, Mapping Nonce has to match the
previous MAP or PEER.  This protects from off-path attackers
stealing MAP or shortening PEER mappings.</t>
<t>With the Mapping Nonce change, we now allow PEER to reduce mapping lifetime
to same lifetime as implicit mapping lifetime (but not shorter).  Changes for
this are in both PEER section and Security Considerations.</t>
<t>With Mapping Nonce change, can no longer delete a 'set of mappings' (because we cannot send multiple Mapping Nonce values), so removed text that allowed that.</t>
<t>Send Mapping Update only 3 times (used to be 10 times).</t>
<t>General PCP processing now requires validating Mapping Nonce, if
the opcode uses a Mapping Nonce <xref target="pcp_processing_response"></xref>.</t> 
<t>Moved text describing NO_RESOURCES handling from General Processing
section to MAP and PEER processing sections, as it NO_RESOURCES processing
should be done after validating Mapping Nonce.</t>
<t>Clarified SCTP NAT behavior (port numbers stay the same, causing
grief).</t>
<t>added EIM definition.</t>
<t>Clarified Mapping Type definitions.</t>
<t>PCP Client definition simplified to no longer obliquely and
erroneously reference UPnP IGD.</t>
<t>Clarified using network-byte order.</t>
<t>Epoch time comparison now allows slight packet re-ordering.</t>
<t>Encourage that when new address is assigned (e.g., DHCP) that
PCP as well as non-PCP mappings be cleaned up.</t>
<t>Simplified formatting of retransmission, but no normative change.</t>
<t>Clarified how server chooses ports and how Suggested External Port
can gently influence that decision.</t>
<t>Described how PCP client can use PCP Client Address with a non-PCP-aware
inner NAT (<xref target="general_generate_request"></xref>.)</t>
<t>Clarified 1024 octet length applies to UDP payload itself, and 
that error responses copy 1024 of UDP payload.</t>
<t>Lifetime for both MAP and PEER should not exceed the remaining 
IP address lifetime of the PCP client (if known) or half the
typical IP address lifetime (if the remaining lifetime is unknown).</t>
<t>Lifetime section was (mistakenly) a subsection of the MAP section, but referenced by both MAP and PEER.  It is now a top-level section.</t>
<t>Clarified that PEER cannot reduce lifetime beyond normal implicit
mapping lifetime, no matter what.  This restriction prevents malicious or
accidental deletion of a quiescent connection that was not using PCP.</t>
<t>Clarified port re-use of PCP-created mappings should follow same
port re-use algorithm used by the NAT for implicitly-created mappings
(likely maximum segment lifetime).</t>
<t>Other minor text changes; consult diffs.</t>
</list></t>
</section>

<section title="Changes from draft-ietf-pcp-base-25 to -26">
        <t><list style="symbols">
<t>Changed "internal address and port" to "internal address, protocol,
and port" in several more places.</t>
<t>Improved wording of THIRD_PARTY restrictions.</t>
<t>Bump version number from 1 to 2, to accommodate pre-RFC PCP client
implementations without needing a heuristic.</t>
</list></t>
</section>

      <section title="Changes from draft-ietf-pcp-base-24 to -25">
        <t><list style="symbols">
<t>Clarified the port used by the PCP server when sending unsolicited
unicast ANNOUNCE.</t>
<t>Removed parenthetical comment implying ANNOUNCE was not a normal
Opcode; it is a normal Opcode.</t>
<t>Explain that non-PCP-speaking host-based and network-based firewalls need to
allow incoming connections for MAP to work.</t>
<t>For race condition with PREFER_FAILURE, clarified that it is the
PCP client's responsibility to delete the mapping if the PCP client
doesn't need the mapping.</t>
<t>For table, the NAT64 remote peer is IPv4 (was IPv6).</t>
<t>Added a Mapping Nonce field to both MAP and PEER requests and responses,
to protect from off-path attackers spoofing the PCP server's IP address.</t>
<t>Security considerations: added 'PCP is secure against off-path attackers
who can spoof the PCP server's IP address', because of the addition of
the Mapping Nonce.</t>
<t>Removed reference to DS-Lite from Security Considerations, as part of
the changes to THIRD_PARTY from IESG review.</t>
<t>Rapid Recovery is now a SHOULD implement.</t>
<t>Clarify behavior of PREFER_FAILURE with zeros in Suggested External
Port or Address fields.</t>
<t>PCP server is now more robust and insistent about 
informing PCP client of state changes.</t>
<t>When PCP server sends Mapping Update to a specific PCP client,
and gets an update for a particular mapping, it doesn't need to
send reminders about that mapping any more.</t>
<t>THIRD_PARTY is now prohibited on subscriber PCP clients.</t>
</list></t>
</section>

      <section title="Changes from draft-ietf-pcp-base-23 to -24">
        <t><list style="symbols">
<t>Explained common questions regarding PCP's design, such as lack of
transction identifiers and its request/response semantics and operation
(<xref target="protocol_design_note">Protocol Design Note</xref>).</t>
<t>added MUST for all-zeros IPv6 and IPv4 address formats.</t>
<t>included field definitions for Opcode-specific information
and PCP options under both <xref target="common_request"></xref>
and <xref target="common_response"></xref>.</t>
<t>adopted retransmission mechanism from DHCPv6.</t>
<t>1024 message size limit described in PCP message restriction.</t>
<t>Explained PCP server list, with example of host with IPv4 and IPv6
addresses having two PCP servers (one IPv4 PCP server for IPv4
mappings and one IPv6 PCP server for IPv6 mappings).</t>
<t>mention PCP client needs to expect unsolicited PCP responses from
previous incarnations of itself (on the same host) or of this host (using
same IP address as another PCP client).</t>
<t>eliminated overuse of 'packet format' when it was 'opcode format'.</t>
<t>for IANA registries, added code points assignable via Standards Action
(previously was just Specification Required).</t>
<t>Version negotiation, added explanation that retrying after 30 minutes 
makes the protocol self-healing if the PCP server is upgraded.</t>
<t>Version negotiation now accomodates non-contiguous version numbers.</t>
<t>Tweaked definition of VERSION field (that "1" is for this version,
but other values could of course appear in the future).</t>
<t>when receiving unsolicited ANNOUNCE, PCP client now waits random
0-5 seconds.</t>
<t>Removed 'interworking function' from list of terminology because
we no longer use the term in this document.</t>
<t>tightened definitions of 'PCP client' and 'PCP server'.</t>
<t>For 'Requested Lifetime' definitions, removed text requiring its
value be 0 for not-yet-defined opcodes.</t>
<t>Removed some unnecessary text suggesting logging (is an implementation
detail).</t>
<t>Added active-mode FTP as example protocol that can break with mappings
to different IP addresses.</t>
<t>Clarified that if PCP request contains a Suggested External Address,
the PCP server should try to create a mapping to that address even if
other mappings already exist to a different external address.</t>
<t>Changed "internal address and port" to "internal address, protocol,
and port" in several places.</t>
<t>Clarified which 96 bits are copied into error response.  Clarified that
only error responses are copied verbatim from request.</t>
<t>a single PCP server can control multiple NATs or multiple firewalls (<xref
target="relationship"></xref>).</t>
<t>Clarified that sending unsolicited multicast ANNOUNCE is not always available on all networks.</t>
<t>Clarified option length error example is when option length exceeds UDP length</t>
<t>Explained that an on-path attacker that can spoof packets can re-direct
traffic to a host of their choosing.</t>
<t>Instead of saying IPv4-mapped addresses won't appear on the wire,
say they aren't used for mappings.</t>
<t>THIRD_PARTY is useful for management device (e.g., in a network operations
center).</t>
<t>Clarified PCP responses have fields updated as indicated with 'set by
the server' from field definitions.</t>
<t>Disallow using MAP to the PCP ports themselves and encourage implementations
have policy control for other ports.</t>
<t>Instead of 'idempotent', now says 'identical requests generate
identical response'.</t>
<t>Described which Options are included when sending Mapping Update (unsolicited responses), <xref target="update"></xref>.</t>
<t>Dropped <xref target="RFC2136"></xref> and <xref target="RFC3007"></xref> to informative references.</t>
<t>Updated from 'should' to 'SHOULD' in <xref target="ingress_filtering"></xref>.</t>
<t>Described 'hairpin' in terminology section.</t>
</list></t>
</section>

      <section title="Changes from draft-ietf-pcp-base-22 to -23">
        <t><list style="symbols">
<t>Instead of returning error NO_RESOURCES when requesting a MAP
for all protocols or for all ports, return UNSUPP_PROTOCOL.</t>
<t>Clarify that PEER-created mappings are treated as if it
was implicit dynamic outbound mapping 
(<xref target="peer-opcode_server_operation"></xref>).</t>
<t>Point out that PEER-created mappings may be very short until
bi-directional traffic is seen by the PCP-managed device.</t>
<t>Clairification that an existing implicit mapping (created e.g., by TCP SYN)
can become managed by a MAP request (<xref target="map-opcode_server_operation"></xref>.</t>
<t>Clarified the ANNOUNCE Opcode is being defined in <xref target="announcement"></xref>, and that the length of requests (as well as responses) is zero.</t>
<t>Clarify that ANNOUNCE has Lifetime=0 for requests and responses.</t>
<t>Clarify ANNOUNCE can be sent unicast by the client (to solicit a
response), or can be multicasted (unsolicited) by the server.</t>
<t>Allow ANNOUNCE to be sent unicast by the server, to accomodate case
where PCP server fails but knows the IP address of a PCP client (e.g.,
web portal).</t>
<t>Clarified ports used for unicast and multicast unsolicited ANNOUNCE.</t>
<t>Tweaked NO_RESOURCES handling, to just disallow *new* mappings.</t>
<t>State diagram is now non-normative, because it overly simplifies
that implicit mappings become MAP (when they actually still retain
their previous behavior when the MAP expires).</t>
<t>In section <xref target="lifetime"></xref>, clarified that PEER
cannot delete or shorten any lifetime, and that MAP can only shorten
or delete lifetimes of MAP-created mappings.</t>
<t>Clarified handling of MAP when mapping already exists (4 steps).</t>
<t>2^32-1</t>
<t>Randomize retry interval (1.5-2.5), and maximum retry interval is
now 1024 seconds (was 15 minutes).</t>
<t>Remove MUST be 0 for Reserved field when sending error responses for
un-parseable message.</t>
<t>Whenever PCP client includes Suggested IP Address (in MAP or PEER),
the PCP server should try to fulfill that request, even if creating a
mapping on that IP address means the internal host will have mappings
on different IP addresses and ports.</t>
<t>For NO_RESOURCES error, the PCP client can attempt to renew and
attempt to delete mappings (as they can help shed load) -- it just
can't try to create new ones.</t>
<t>Removed the overly simplistic normative text regarding honoring
Suggested External Address
from <xref target="opcode_introduction"></xref> in favor of
the text in <xref target="map-opcode_server_operation"></xref> which has
significantly more detail.</t>
</list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-21 to -22">
        <t><list style="symbols">
<t>Removed paragraph discussing multiple addresses on the same
(physical) interface; those will work with PCP.</t>
<t>The FILTER Option's Prefix Length field redefined to simply be
a count of the relevant bits (rather than 0-32 for IPv4-mapped
addresses).</t>
<t>Point out NO_RESOURCES attack vector in security considerations.</t>
<t>Tighten up recommendation for client handling long Lifetimes, and
moved from the MAP-specific section to the General PCP Processing
section.  Client should normalize to 24 hours maximum for success and
30 minute maximum for errors.</t>
</list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-20 to -21">
        <t><list style="symbols">
            <t>To delete all mappings using THIRD_PARTY, use the
all-zeros IP address (rather than previous text which used length=0).</t>
<t>added normative text for what PCP server does when it receives
all-zeros IP address in THIRD_PARTY option.</t>
<t>PREFER_FAILURE allowed for use by web portal.</t>
<t>clarifications to mandatory option processing.</t>
<t>cleanup and wordsmithing of the THIRD_PARTY text.</t>
        </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-19 to -20">
        <t><list style="symbols">
            <t>clarify if Options are included in responses.</t>
            <t>clarify when External Address can be ignored by the
     PCP server / PCP-controlled device</t>
            <t>added 'Transition from state M to state I is
            implementation dependent' to state diagram</t>
        </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-18 to -19">
        <t><list style="symbols">
        <t>Described race condition with MAP containing PREFER_FAILURE
and Mapping Update.</t>
<t>Added state machine (<xref target="state_section"></xref>).</t>
        <t>Fully integrated Rapid Recovery, with a separate Opcode 
having its own processing description.</t>
<t>Clarified that due to Mapping Update, a single MAP or PEER request
can receive multiple responses, each updating the previous request,
and that the PCP client needs to handle MAP updates or PEER updates
accordingly.</t>
        </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-17 to -18">
        <t><list style="symbols">
            <t>Removed UNPROCESSED option.  Instead, unprocessed options
are simply not included in responses.</t>
            <t>Updated terminology section for Implicit/Explicit and Outbound/Inbound.</t>
            <t>PEER requests cannot delete or shorten the lifetime of a mapping.</t>
            <t>Clarified that PCP clients only retransmit mapping requests for
            as long as they actually want the mapping.</t>
            <t>Revised Epoch time calculations and explanation.</t>
            <t>Renamed the announcement opcode from No-Op to ANNOUNCE.</t>
        </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-16 to -17">
        <t><list style="symbols">
            <t>suggest acquiring a mapping to the Discard port if
              there is a desire to show the user their external
              address (<xref target="alone"></xref>).</t>
            <t>Added Restart Announcement.</t>
            <t>Tweaked terminology.</t>
            <t>Detailed how error responses are generated.</t>
       </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-15 to -16">
        <t><list style="symbols">
<t>fixed mistake in PCP request format (had 32 bits of extraneous fields)</t>
<t>Allow MAP to request all ports (port=0) for a specific protocol
(protocol!=0), for the same reason we added support for all ports
(port=0) and all protocols (protocol=0) in -15</t>
<t>corrected text on Client Processing a Response related to receiving
ADDRESS_MISMATCH error.</t>
<t>updated Epoch text.</t>
<t>Added text that MALFORMED_REQUEST is generated for MAP if Protocol is
zero but Internal Port is non-zero.</t>
</list></t>
</section>

      <section title="Changes from draft-ietf-pcp-base-14 to -15">
        <t><list style="symbols">
        <t>Softened and removed text that was normatively explaining
how PEER is implemented within a NAT.</t>
<t>Allow a MAP request for protocol=0, which means "all protocols".
This can work for an IPv6 or IPv4 firewall.  Its use with a NAPT
is undefined.</t>
<t>combined SERVER_OVERLOADED and NO_RESOURCES into one error code,
NO_RESOURCES.</t>
<t>SCTP mappings have to use same internal and suggested
external ports, and have implied PREFER_FAILURE semantics.</t>
<t>Re-instated ADDRESS_MISMATCH error, which only checks the
client address (not its port).</t>
</list></t>
</section>

      <section title="Changes from draft-ietf-pcp-base-13 to -14">
        <t><list style="symbols">
          <t>Moved discussion of socket operations for PCP source
          address into Implementation Considerations section.</t>
          <t>Integrated numerous WGLC comments.</t>
          <t>NPTv6 in scope.</t>
          <t>Re-written security considerations section.  Thanks, Margaret!</t>
          <t>Reduced PEER4 and PEER6 Opcodes to just a single Opcode, PEER.</t>
          <t>Reduced MAP4 and MAP6 Opcodes to just a single Opcode, MAP.</t>
          <t>Rearranged the PEER packet formats to align with MAP.</t>
          <t>Removed discussion of the "O" bit for Options, which was
          confusing.  Now the text just discusses the most significant
          bit of the Option code which indicates mandatory/optional,
          so it is clearer the field is 8 bits.</t>
          <t>The THIRD_PARTY Option from an unauthorized host
          generates UNSUPP_OPTION, so the PCP server doesn't disclose
          it knows how to process THIRD_PARTY Option.</t>
          <t>Added table to show which fields of MAP or PEER need
          IPv6/IPv4 addresses for IPv4 firewall, DS-Lite, NAT64,
          NAT44, etc.</t>
          <t>Accommodate the server's Epoch going up or down, to better
          detect switching to a different PCP server.</t>
          <t>Removed ADDRESS_MISMATCH; the server always includes its idea of
          the Client's IP Address and Port, and it's up to the client to
          detect a mismatch (and rectify it).</t>
        </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-12 to -13">
        <t><list style="symbols">
          <t>All addresses are 128 bits.  IPv4 addresses are
represented by IPv4-mapped IPv6 addresses (::FFFF/96)</t>
<t>PCP request header now includes PCP client's port (in addition
to the client's IP address, which was in -12).</t>
<t>new ADDRESS_MISMATCH error.</t>
<t>removed PROCESSING_ERROR error, which was too similar to
MALFORMED_REQUEST.</t>
<t>Tweaked text describing how PCP client deals with multiple PCP
server addresses (<xref target="general_generate_request"></xref>)</t>
<t>clarified that when overloaded, the server can send
SERVER_OVERLOADED (and drop requests) or simply drop requests.</t>
<t>Clarified how PCP client chooses MAP4 or MAP6, depending on the
presence of its own IPv6 or IPv4 interfaces
(<xref target="opcode_introduction"></xref>).</t>
<t>compliant PCP server MUST support MAPx and PEERx, SHOULD support
ability to disable support.</t>
<t>clarified that MAP-created mappings have no filtering, and
PEER-created mappings have whatever filtering and mapping
behavior is normal for that particular NAT / firewall.</t>
<t>Integrated WGLC feedback (small changes to abstract,
definitions, and small edits throughout the document)</t>
<t>allow new Options to be defined with a specification
(rather than standards action)</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-11 to -12">
        <t><list style="symbols">
            <t>added implementation note that MAP and implicit dynamic
            mappings have independent mapping lifetimes.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-10 to -11">
        <t><list style="symbols">
            <t>clarified what can cause CANNOT_PROVIDE_EXTERNAL error to
            be generated.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-09 to -10">
        <t><list style="symbols">
            <t>Added External_AF field to PEER requests. Made PEER's Suggested
            External IP Address and Assigned External IP Address always be 128
            bits long.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-08 to -09">
        <t><list style="symbols">
            <t>Clarified in PEER Opcode introduction (<xref
            target="peer_opcodes"></xref>) that they can also create mappings.</t>

            <t>More clearly explained how PEER can re-create an implicit
            dynamic mapping, for purposes of rebuilding state to maintain an
            existing session (e.g., long-lived TCP connection to a
            server).</t>

            <t>Added Suggested External IP Address to the PEER Opcodes, to
            allow more robust rebuilding of connections. Added related text to
            the PEER server processing section.</t>

            <t>Removed text encouraging PCP server to statefully remember its
            mappings from <xref target="reboot"></xref>, as it didn't belong
            there. Text in Security Considerations already encourages
            persistent storage.</t>

            <t>More clearly discussed how PEER is used to re-establish TCP
            mapping state. Moved it to a new section, as well (it is now
            <xref target="restoring"></xref>).</t>

            <t>MAP errors now copy the Suggested Address (and port) fields
            to Assigned IP Address (and port), to allow PCP client to
            distinguish among many outstanding requests when using
            PREFER_FAILURE.</t>

            <t>Mapping theft can also be mitigated by ensuring hosts can't
            re-use same IP address or port after state loss.</t>

            <t>the UNPROCESSED option is renumbered to 0 (zero), which ensures
            no other option will be given 0 and be unable to be expressed by
            the UNPROCESSED option (due to its 0 padding).</t>

            <t>created new Implementation Considerations section (<xref
            target="implementation_considerations"></xref>) which discusses
            non-normative things that might be useful to implementers. Some
            new text is in here, and the Failure Scenarios text (<xref
            target="failurerecovery"></xref>) has been moved to here.</t>

            <t>Tweaked wording of EDM NATs in <xref target="EDM"></xref> to
            clarify the problem occurs both inside-&gt;outside and
            outside-&gt;inside.</t>

            <t>removed "Interference by Other Applications on Same Host"
            section from security considerations.</t>

            <t>fixed zero/non-zero text in
            <xref target="lifetime"></xref>.</t>

            <t>removed duplicate text saying MAP is allowed to delete an
            implicit dynamic mapping. It is still allowed to do that, but it
            didn't need to be said twice in the same paragraph.</t>

            <t>Renamed error from UNAUTH_TARGET_ADDRESS to
            UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS.</t>

            <t>for FILTER option, removed unnecessary detail on how FILTER
            would be bad for PEER, as it is only allowed for MAP anyway.</t>

            <t>In Security Considerations, explain that PEER can create a
            mapping which makes its security considerations the same as
            MAP.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-07 to -08">
        <t><list style="symbols">
            <t>moved all MAP4-, MAP6-, and PEER-specific options into a single
            section.</t>

            <t>discussed NAT port-overloading and its impact on MAP (new
            section <xref target="EDM"></xref>), which allowed removing the
            IMPLICIT_MAPPING_EXISTS error.</t>

            <t>eliminated NONEXIST_PEER error (which was returned if a PEER
            request was received without an implicit dynamic mapping already
            being created), and adjusted PEER so that it creates an implicit
            dynamic mapping.</t>

            <t>Removed Deployment Scenarios section (which detailed NAT64,
            NAT44, Dual-Stack Lite, etc.).</t>

            <t>Added Client's IP Address to PCP common header. This allows
            server to refuse a PCP request if there is a mismatch with the
            source IP address, such as when a non-PCP-aware NAT was on the
            path. This should reduce failure situations where PCP is deployed
            in conjunction with a non-PCP-aware NAT. This addition was
            consensus at IETF80.</t>

            <t>Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that
            MALFORMED_REQUEST is for malformed requests (and not related to
            failed attempts to process the request).</t>

            <t>Removed MISORDERED_OPTIONS. Consensus of IETF80.</t>

            <t>SERVER_OVERLOADED is now a common PCP error (instead of
            specific to MAP).</t>

            <t>Tweaked PCP retransmit/retry algorithm again, to allow more
            aggressive PCP discovery if an implementation wants to do
            that.</t>

            <t>Version negotiation text tweaked to soften NAT-PMP reference,
            and more clearly explain exactly what UNSUPP_VERSION should
            return.</t>

            <t>PCP now uses NAT-PMP's UDP port, 5351. There are no normative
            changes to NAT-PMP or PCP to allow them both to use the same port
            number.</t>

            <t>New Appendix A to discuss NAT-PMP / PCP interworking.</t>

            <t>improved pseudocode to be non-blocking.</t>

            <t>clarified that PCP cannot delete a static mapping (i.e., a
            mapping created by CLI or other non-PCP means).</t>

            <t>moved theft of mapping discussion from Epoch section to
            Security Considerations.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-06 to -07">
        <t><list style="symbols">
            <t>tightened up THIRD_PARTY security discussion. Removed "highest
            numbered address", and left it as simply "the CPE's IP
            address".</t>

            <t>removed UNABLE_TO_DELETE_ALL error.</t>

            <t>renumbered Opcodes</t>

            <t>renumbered some error codes</t>

            <t>assigned value to IMPLICIT_MAPPING_EXISTS.</t>

            <t>UNPROCESSED can include arbitrary number of option codes.</t>

            <t>Moved lifetime fields into common request/response headers</t>

            <t>We've noticed we're having to repeatedly explain to people that
            the "requested port" is merely a hint, and the NAT gateway is free
            to ignore it. Changed name to "suggested port" to better convey
            this intention.</t>

            <t>Added NAT-PMP transition section</t>

            <t>Separated Internal Address, External Address, Remote Peer
            Address definition</t>

            <t>Unified Mapping, Port Mapping, Port Forwarding definition</t>

            <t>adjusted so DHCP configuration is non-normative.</t>

            <t>mentioned PCP refreshes need to be sent over the same
            interface.</t>

            <t>renamed the REMOTE_PEER_FILTER option to FILTER.</t>

            <t>Clarified FILTER option to allow sending an ICMP error if
            policy allows.</t>

            <t>for MAP, clarified that if the PCP client changed its IP
            address and still wants to receive traffic, it needs to send a new
            MAP request.</t>

            <t>clarified that PEER requests have to be sent from same
            interface as the connection itself.</t>

            <t>for MAP opcode, text now requires mapping be deleted when
            lifetime expires (per consensus on 8-Mar interim meeting)</t>

            <t>PEER Opcode: better description of remote peer's IP address,
            specifically that it does not control or establish any filtering,
            and explaining why it is 'from the PCP client's perspective'.</t>

            <t>Removed latent text allowing DMZ for 'all protocols'
            (protocol=0). Which wouldn't have been legal, anyway, as protocol
            0 is assigned by IANA to HOPOPT (thanks to James Yu for catching
            that one).</t>

            <t>clarified that PCP server only listens on its internal
            interface.</t>

            <t>abandoned 'target' term and reverted to simplier 'internal'
            term.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-05 to -06">
        <t><list style="symbols">
            <t>Dual-Stack Lite: consensus was encapsulation mode. Included a
            suggestion that the B4 will need to proxy PCP-to-PCP and
            UPnP-to-PCP.</t>

            <t>defined THIRD_PARTY Option to work with the PEER Opcode, too.
            This meant moving it to its own section, and having both MAP and
            PEER Opcodes reference that common section.</t>

            <t>used "target" instead of "internal", in the hopes that
            clarifies internal address used by PCP itself (for sending its
            packets) versus the address for MAPpings.</t>

            <t>Options are now required to be ordered in requests, and
            ordering has to be validated by the server. Intent is to ease
            server processing of mandatory-to-implement options.</t>

            <t>Swapped Option values for the mandatory- and
            optional-to-process Options, so we can have a simple
            lowest..highest ordering.</t>

            <t>added MISORDERED_OPTIONS error.</t>

            <t>re-ordered some error messages to cause MALFORMED_REQUEST
            (which is PCP's most general error response) to be error 1,
            instead of buried in the middle of the error numbers.</t>

            <t>clarified that, after successfully using a PCP server, that PCP
            server is declared to be non-responsive after 5 failed
            retransmissions.</t>

            <t>tightened up text (which was inaccurate) about how long general
            PCP processing is to delay when receiving an error and if it
            should honor Opcode-specific error lifetime. Useful for MAP errors
            which have an error lifetime. (This all feels awkward to have only
            some errors with a lifetime.)</t>

            <t>Added better discussion of multiple interfaces, including
            highlighting Wi-Fi+Ethernet. Added discussion of using IPv6 Privacy
            Addresses and RFC1918 as source addresses for PCP requests. This
            should finish the section on multi-interface issues.</t>

            <t>added some text about why server might send SERVER_OVERLOADED,
            or might simply discard packets.</t>

            <t>Dis-allow internal-port=0, which means we dis-allow using PCP
            as a DMZ-like function. Instead, ports have to be mapped
            individually.</t>

            <t>Text describing server's processing of PEER is tightened
            up.</t>

            <t>Server's processing of PEER now says it is
            implementation-specific if a PCP server continues to allow the
            mapping to exist after a PEER message. Client's processing of PEER
            says that if client wants mapping to continue to exist, client has
            to continue to send recurring PEER messages.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-04 to -05">
        <t><list style="symbols">
            <t>tweaked PCP common header packet layout.</t>

            <t>Re-added port=0 (all ports).</t>

            <t>minimum size is 12 octets (missed that change in -04).</t>

            <t>removed Lifetime from PCP common header.</t>

            <t>for MAP error responses, the lifetime indicates how long the
            server wants the client to avoid retrying the request.</t>

            <t>More clearly indicated which fields are filled by the server on
            success responses and error responses.</t>

            <t>Removed UPnP interworking section from this document. It will
            appear in
            <xref target="I-D.ietf-pcp-upnp-igd-interworking"></xref>.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-03 to -04">
        <t><list style="symbols">
            <t>"Pinhole" and "PIN" changed to "mapping" and "MAP".</t>

            <t>Reduced from four MAP Opcodes to two. This was done by
            implicitly using the address family of the PCP message itself.</t>

            <t>New option THIRD_PARTY, to more carefully split out the case
            where a mapping is created to a different host within the
            home.</t>

            <t>Integrated a lot of editorial changes from Stuart and
            Francis.</t>

            <t>Removed nested NAT text into another document, including the
            IANA-registered IP addresses for the PCP server.</t>

            <t>Removed suggestion (MAY) that PCP server reserve UDP when it
            maps TCP. Nobody seems to need that.</t>

            <t>Clearly added NAT and NAPT, such as in residential NATs, as
            within scope for PCP.</t>

            <t>HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE</t>

            <t>Added 'Lifetime' field to the common PCP header, which replaces
            the functions of the 'temporary' and 'permanent' error types of
            the previous version.</t>

            <t>Allow arbitrary Options to be included in PCP response, so that
            PCP server can indicate un-supported PCP Options. Satisfies PCP
            Issue #19</t>

            <t>Reduced scope to only deal with mapping protocols that have
            port numbers.</t>

            <t>Reduced scope to not support DMZ-style forwarding.</t>

            <t>Clarified version negotiation.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-02 to -03">
        <t><list style="symbols">
            <t>Adjusted abstract and introduction to make it clear PCP is
            intended to forward ports and intended to reduce application
            keepalives.</t>

            <t>First bit in PCP common header is set. This allows DTLS and
            non-DTLS to be multiplexed on same port, should a future update to
            this specification add DTLS support.</t>

            <t>Moved subscriber identity from common PCP section to MAP*
            section.</t>

            <t>made clearer that PCP client can reduce mapping lifetime if it
            wishes.</t>

            <t>Added discussion of host running a server, client, or symmetric
            client+server.</t>

            <t>Introduced PEER4 and PEER6 Opcodes.</t>

            <t>Removed REMOTE_PEER Option, as its function has been replaced
            by the new PEER Opcodes.</t>

            <t>IANA assigned port 44323 to PCP.</t>

            <t>Removed AMBIGUOUS error code, which is no longer needed.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-01 to -02">
        <t><list style="symbols">
            <t>more error codes</t>

            <t>PCP client source port number should be random</t>

            <t>PCP message minimum 8 octets, maximum 1024 octets.</t>

            <t>tweaked a lot of text in section 7.4, "Opcode-Specific Server
            Operation".</t>

            <t>opening a mapping also allows ICMP messages associated with
            that mapping.</t>

            <t>PREFER_FAILURE value changed to the mandatory-to-process
            range.</t>

            <t>added text recommending applications that are crashing obtain
            short lifetimes, to avoid consuming subscriber's port quota.</t>
          </list></t>
      </section>

      <section title="Changes from draft-ietf-pcp-base-00 to -01">
        <t><list style="symbols">
            <t>Significant document reorganization, primarily to split base
            PCP operation from Opcode operation.</t>

            <t>packet format changed to move 'protocol' outside of PCP common
            header and into the MAP* opcodes</t>

            <t>Renamed Informational Elements (IE) to Options.</t>

            <t>Added REMOTE_PEER (for disambiguation with dynamic ports),
            REMOTE_PEER_FILTER (for simple packet filtering), and
            PREFER_FAILURE (to optimize UPnP IGDv1 interworking) options.</t>

            <t>Is NAT or router behind B4 in scope?</t>

            <t>PCP option MAY be included in a request, in which case it MUST
            appear in a response. It MUST NOT appear in a response if it was
            not in the request.</t>

            <t>Result code most significant bit now indicates
            permanent/temporary error</t>

            <t>PCP Options are split into mandatory-to-process ("P" bit), and
            into Specification Required and Private Use.</t>

            <t>Epoch discussion simplified.</t>
          </list></t>
      </section>
    </section>

    <!--

    <section anchor="discovery_analysis" title="Analysis of Techniques to Discover PCP Server">
      <t><list style="empty">
          <t>[Ed. Note: This Appendix will be removed in a later version of
          this document. It is included here for reference and discussion
          purposes. This is tracked as PCP Issue #8
          <xref target="PCP-Issues"></xref>.]</t>
        </list></t>

      <t><list style="empty">
          <t>Discussion Note: A deployment model is a non-PCP aware NAT in a
          home, and a PCP-aware CGN operated by the ISP. For example, the home
          users purchased a NAT last year at a computer shop (to extend their
          home's Wi-Fi network). This could work by having the host use UPnP
          IGDv1 with the in-home NAT, and the host use PCP with the CGN. But
          this deployment model is impossible with several of the mechanisms
          below. Is this deployment model important, or can we wait for PCP to
          be enabled on CPE?</t>
        </list></t>

      <t>Several mechanisms for discovering the PCP server can be envisaged as
      listed below:</t>

      <t><list style="numbers">
          <t>A special-purpose IPv4 or IPv6 address, assigned by IANA, which
          is routed normally until it hits a PCP server, which responds. <list
              style="empty">
              <t>Analysis: This solution can be deployed in the context of
              DS-Lite architecture. Concretely, a well-known IPv4 address can
              be used to reach a PCP server in the device that provides
              the AFTR capabilities. Since all IPv4 messages issued by a
              DS-Lite CP router will be encapsulated in IPv6, no state
              synchronisation issues will be experienced because PCP messages
              will be handled by the appropriate PCP server.</t>

              <t>In some deployment scenarios (e.g., deployment of several
              stateful NAT64/NAT46 in the same domain), the use of this
              address is not recommended since PCP messages, issued by a given
              host, may be handled by a PCP server in a NAT node
              which is not involved to handle IP packets issued from that
              host. The use of this special-purpose IP address may induce
              session failures and therefore the customer may experience
              troubles when accessing its services.</t>

              <t>Consequently, the use of a special-purpose IPv4 address is
              suitable for DS-Lite NAT44. As for NAT46/NAT64, this is left to
              the Service Providers according to their deployment
              configuration.</t>

              <t>The special-use address MUST NOT be advertised in the global
              routing table. Packets with that destination address SHOULD be
              filtered so they are not transmitted on the Internet.</t>
            </list></t>

          <t>Assume the default router is a PCP server, and send PCP packets
          to the IP address of the default router. <list style="empty">
              <t>Analysis: This solution is not suitable for DS-Lite NAT44 nor
              for all variants of NAT64/NAT46. <list style="empty">
                  <t>In the context of DS-Lite: There is no default IPv4
                  router configured in the CP router. All outgoing IPv4
                  traffic is encapsulated in IPv6 and then forwarded to a
                  pre-configured DS-Lite AFTR device. Furthermore, if IPv6 is
                  used to reach the PCP server, the first router may not be
                  the one which implements the AFTR.</t>

                  <t>For NAT64/NAT46 scenarios: The NAT function is not
                  implemented by the first router, therefore this solution
                  candidate does not allow to discover a valid PCP server.</t>
                </list></t>

              <t>Therefore, this alternative is not recommended.</t>
            </list></t>

          <t>Service Location Protocol (<xref
          target="RFC2608">SLP</xref>).<list style="empty">
              <t>Analysis: This solution is not suitable in scenarios where
              multicast is not enabled. SLP is a chatty protocol. Also, as
              with UPnP IGDv1's use of SSDP, SLP will discover NAT gateways
              which exist on the local network, but are not actually on the
              path that packets will take from the Internal Host to the
              Internet, leading to the situation where Internal Hosts create
              apparently-successful mappings, which are in fact completely
              worthless for the purpose of establishing useful communication
              with Remote Hosts on the Internet. This alternative is not
              recommended.</t>
            </list></t>

          <t>NAPTR. The host would issue a DNS query for a NAPTR record,
          formed from some bits of the host's IPv4 or IPv6 address. For
          example, a host with the IPv6 address 2001:db8:1:2:3:4:567:89ab
          would first send an NAPTR query for
          3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements,
          representing a /64 network prefix), which returns the PCP server's
          IPv6 address. A similar scheme can be used with IPv4 using, for
          example, the first 24 bits of the IPv4 address.<list style="empty">
              <t>Analysis: This solution candidate requires more configuration
              effort by the Service Provider so as to redirect a given client
              to the appropriate PCP server. Any change of the engineering
              policies (e.g., introduce new CGN device, load-based
              dimensioning, load-balancing, etc.) would require to update the
              zone configuration. This would be a hurdle for the flexibility
              of the operational networks. Adherence to DNS is not encouraged
              and means which allows for more flexibility are to be
              promoted.</t>

              <t>Therefore, this mechanism is not recommended.</t>
            </list></t>

          <t>New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a
          PCP server.<list style="empty">
              <t>Analysis: Since DS-Lite and NAT64/NAT46 are likely to be
              deployed in provider-provisioned environments, DHCP (both DHCPv6
              and IPv4 DHCP) is convenient to provision the address/FQDN of
              the PCP server.</t>
            </list></t>
        </list></t>
    </section>
-->

    <!--
<section title="Contributors' Addresses">
<t>The following individuals contributed substantial text to this
   document and are listed in alphabetical order:</t>

      <figure>
        <artwork align="left"><![CDATA[
   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com


   Mohamed Boucadair
   France Telecom
   Rennes,   35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Reinaldo Penno
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale, California  94089
   USA

   Email: rpenno@juniper.net


   Francis Dupont
   Internet Systems Consortium

   Email: fdupont@isc.org
]]></artwork>
      </figure>
</section>
-->
  </back>
</rfc>
