[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-wing-pcp-base) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 RFC 6887

PCP working group                                           D. Wing, Ed.
Internet-Draft                                                     Cisco
Intended status: Standards Track                        February 7, 2011
Expires: August 11, 2011



                      Port Control Protocol (PCP)
                         draft-ietf-pcp-base-04

Abstract

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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 11, 2011.

Copyright Notice




Wing, et al.             Expires August 11, 2011                [Page 1]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Deployment Scenarios . . . . . . . . . . . . . . . . . . .  4
     2.2.  Supported Transport Protocols  . . . . . . . . . . . . . .  5
     2.3.  Single-homed Customer Premises Network . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Relationship of PCP Server and its NAT . . . . . . . . . . . .  8
   5.  Common Request and Response Header Format  . . . . . . . . . .  8
     5.1.  Request Header . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Response Header  . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  Options  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Result Codes . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  General PCP Operation  . . . . . . . . . . . . . . . . . . . . 14
     6.1.  General PCP Client Operation . . . . . . . . . . . . . . . 14
       6.1.1.  Generating and Sending a Request . . . . . . . . . . . 14
       6.1.2.  Processing a Response  . . . . . . . . . . . . . . . . 15
       6.1.3.  Multi-interface Issues . . . . . . . . . . . . . . . . 16
       6.1.4.  Epoch  . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.2.  General PCP Server Operation . . . . . . . . . . . . . . . 17
     6.3.  General PCP Options  . . . . . . . . . . . . . . . . . . . 18
       6.3.1.  UNPROCESSED  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Introduction to MAP and PEER OpCodes . . . . . . . . . . . . . 19
     7.1.  For Operating a Server . . . . . . . . . . . . . . . . . . 20
     7.2.  For Reducing NAT Keepalive Messages  . . . . . . . . . . . 20
     7.3.  For Operating a Symmetric Client/Server  . . . . . . . . . 21
   8.  MAP OpCodes  . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  OpCode Packet Formats  . . . . . . . . . . . . . . . . . . 23
     8.2.  OpCode-Specific Result Codes . . . . . . . . . . . . . . . 25
     8.3.  OpCode-Specific Client Operation, Processing a Response  . 26
     8.4.  OpCode-Specific Server Operation . . . . . . . . . . . . . 27
       8.4.1.  Maintaining Same External IP Address . . . . . . . . . 29
       8.4.2.  Mapping Lifetime . . . . . . . . . . . . . . . . . . . 29



Wing, et al.             Expires August 11, 2011                [Page 2]

Internet-Draft         Port Control Protocol (PCP)         February 2011


       8.4.3.  Mapping Deletion . . . . . . . . . . . . . . . . . . . 30
       8.4.4.  Subscriber Renumbering . . . . . . . . . . . . . . . . 30
     8.5.  PCP Options for MAP OpCodes  . . . . . . . . . . . . . . . 31
       8.5.1.  THIRD_PARTY  . . . . . . . . . . . . . . . . . . . . . 31
       8.5.2.  REMOTE_PEER_FILTER . . . . . . . . . . . . . . . . . . 32
       8.5.3.  PREFER_FAILURE . . . . . . . . . . . . . . . . . . . . 33
     8.6.  PCP Mapping State Maintenance  . . . . . . . . . . . . . . 34
       8.6.1.  Recreating Mappings  . . . . . . . . . . . . . . . . . 34
       8.6.2.  Maintaining Mappings . . . . . . . . . . . . . . . . . 35
   9.  PEER OpCodes . . . . . . . . . . . . . . . . . . . . . . . . . 36
     9.1.  OpCode Packet Formats  . . . . . . . . . . . . . . . . . . 36
     9.2.  OpCode-Specific Result Codes . . . . . . . . . . . . . . . 39
     9.3.  OpCode-Specific Client Operation, Processing a Response  . 39
     9.4.  OpCode-Specific Server Operation . . . . . . . . . . . . . 40
   10. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 40
     10.1. Dual Stack-Lite  . . . . . . . . . . . . . . . . . . . . . 40
       10.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 41
       10.1.2. Encapsulation Mode . . . . . . . . . . . . . . . . . . 41
       10.1.3. Plain IPv6 Mode  . . . . . . . . . . . . . . . . . . . 41
     10.2. NAT64  . . . . . . . . . . . . . . . . . . . . . . . . . . 42
     10.3. NAT44 and NAT444 . . . . . . . . . . . . . . . . . . . . . 42
     10.4. IPv6 Firewall  . . . . . . . . . . . . . . . . . . . . . . 42
     10.5. Subscriber Identification  . . . . . . . . . . . . . . . . 42
   11. Interworking with UPnP IGD 1.0 and 2.0 . . . . . . . . . . . . 44
     11.1. UPnP IGD 1.0 with AddPortMapping Action  . . . . . . . . . 44
     11.2. UPnP IGD 2.0 with AddAnyPortMapping Action . . . . . . . . 47
     11.3. Lifetime Maintenance . . . . . . . . . . . . . . . . . . . 47
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 47
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 48
     13.1. Port Number  . . . . . . . . . . . . . . . . . . . . . . . 48
     13.2. OpCodes  . . . . . . . . . . . . . . . . . . . . . . . . . 48
     13.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 48
     13.4. Options  . . . . . . . . . . . . . . . . . . . . . . . . . 48
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 49
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 49
     15.2. Informative References . . . . . . . . . . . . . . . . . . 50
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 51
     A.1.  Changes from draft-ietf-pcp-base-03 to -04 . . . . . . . . 51
     A.2.  Changes from draft-ietf-pcp-base-02 to -03 . . . . . . . . 52
     A.3.  Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . . 53
     A.4.  Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . . 53
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54








Wing, et al.             Expires August 11, 2011                [Page 3]

Internet-Draft         Port Control Protocol (PCP)         February 2011


1.  Introduction

   Port Control Protocol (PCP) provides a mechanism to control how
   incoming packets are forwarded by upstream devices such as NAT64,
   NAT44, and firewall devices, and a mechanism to reduce application
   keepalive traffic.  PCP is primarily designed to be implemented in
   the context of both Carrier-Grade NATs (CGN) and small NATs (e.g.,
   residential NATs).  PCP allows hosts to operate server for a long
   time (e.g., a webcam) 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.

   PCP allows applications to create mappings from an external IP
   address and port to an internal IP address and port.  If the PCP-
   controlled device is a NAT, a mapping is created; if the PCP-
   controlled device is a firewall, a mapping is created in the
   firewall.  These mappings are required for successful inbound
   communications destined to machines located behind a NAT.

   After creating a mapping for incoming connections, it is necessary to
   inform remote computers about the IP address and port for the
   incoming connection.  This is usually done in an application-specific
   manner.  For example, a computer game would use a rendezvous server
   specific to that game (or specific to that game developer), and a SIP
   phone would use a SIP proxy.  PCP does not provide this rendezvous
   function.

   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 those NAT
   keepalive messages by using PCP to learn (or control) the NAT mapping
   lifetime.  This helps reduce bandwidth on the subscriber's access
   network, traffic to the server, and battery consumption on mobile
   devices.


2.  Scope

2.1.  Deployment Scenarios

   PCP can be used in various deployment scenarios, including:

   o  Dual Stack-Lite [I-D.ietf-softwire-dual-stack-lite], and;

   o  NAT64, both Stateful [I-D.ietf-behave-v6v4-xlate-stateful] and
      Stateless [I-D.ietf-behave-v6v4-xlate], and;



Wing, et al.             Expires August 11, 2011                [Page 4]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   o  Carrier-Grade NAT [I-D.ietf-behave-lsn-requirements], and;

   o  Basic NAT [RFC3022], and;

   o  Network Address and Port Translation (NAPT) [RFC3022], such as
      commonly deployed in residential NAT devices, and;

   o  Layer-2 aware NAT [I-D.miles-behave-l2nat] and Dual-Stack Extra
      Lite [I-D.arkko-dual-stack-extra-lite], and;

   o  IPv6 firewall control [RFC6092].

2.2.  Supported Transport Protocols

   The PCP OpCodes defined in this document are designed to support
   transport protocols that use a 16-bit port number (e.g., TCP, UDP,
   SCTP, DCCP).  Transport protocols that do not use a port number
   (e.g., IPsec ESP), and the ability to use PCP to forward all traffic
   to a single default host (often nicknamed "DMZ"), are beyond the
   scope of this document.

2.3.  Single-homed Customer Premises Network

   The PCP machinery assumes a single-homed host model.  That is, for a
   given IP version, only one default route exists to reach the
   Internet.  This is important because after a PCP mapping is created
   and an inbound packet (e.g., TCP SYN) arrives at the host the
   outbound response (e.g., TCP SYNACK) has to go through the same path
   so the proper address rewriting takes place on that outbound response
   packet.  This restriction exists because otherwise there would need
   to be one PCP server for each egress, because the host could not
   reliably determine which egress path packets would take, so 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.


3.  Terminology

   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 RFC 2119 [RFC2119].

   Internal Host:
      A host served by a NAT gateway, or protected by a firewall.






Wing, et al.             Expires August 11, 2011                [Page 5]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Remote Host:
      A host with which an Internal Host is communicating.

   Internal Address, External Address, Remote Address:
      An Internal Address is the address of an Internal Host served by a
      NAT gateway (typically a private address [RFC1918]) or an Internal
      Host protected by a firewall.

      An External Address is the address of an Internal Host as seen by
      other Remote Hosts 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.

      A Remote Address is the address of a Remote Host, as seen by the
      Internal Host.  A Remote Address is generally a public routable
      address.  In the case of a Remote Host that is itself served by a
      NAT gateway, the Remote Address my in fact be the Remote Host's
      External Address, but since this is remote translation generally
      invisible to software running on the Internal Host, the
      distinction can safely be ignored for the purposes of this
      document.

   Target Address:
      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.

      In the case where one device is managing Mappings on behalf of
      some other device which does not implement PCP, the presence of a
      Target Address option in the PCP request signifies that the
      specified Target Address, not the source IP address of the PCP
      request packet, should be used as the Internal Address for the
      Mapping.  When PCP requests are used with a Target Address option,
      appropriate security measures MUST be used to ensure that the
      device creating, renewing, or deleting mappings is authorized to
      do so on behalf of the given Target Address.

   Mapping:
      A NAT mapping creates a relationship between an internal IP
      transport address and an external IP transport address.  More
      specifically, it creates a translation rule where packets destined
      to the external IP and port are translated to the internal IP and
      port.  In the case of a pure firewall, the "Mapping" is the
      identity function, translating an internal port number to the same
      external port number and vice versa, and this "Mapping" indicates



Wing, et al.             Expires August 11, 2011                [Page 6]

Internet-Draft         Port Control Protocol (PCP)         February 2011


      to the firewall that traffic to and from this internal port number
      is permitted to pass.  See also Port Forwarding.

   Mapping Types:
      There are three different ways to create mappings: implicit
      dynamic mappings, explicit dynamic mappings, and static mappings.
      Implicit dynamic mappings are created as a result of a TCP SYN or
      outgoing UDP packet.  Explicit dynamic mappings are created as a
      result of PCP requests.  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 which they are automatically deleted unless
      the lifetime is extended by action by the Internal Host.  Static
      mappings are created by manual configuration (e.g., command
      language interface or web page) and differ from dynamic mappings
      in that their lifetime is typically infinite (they exist until
      manually removed) but otherwise they behave exactly the same as
      dynamic mappings.  E.g. a PCP request to create a mapping that
      already exists as a static mapping will return a successful
      result, confirming that the requested mapping exists.

   Port Forwarding, Port Mapping:
      Port forwarding (or port mapping) allows a host to receive traffic
      sent to a specific IP address and port.

      In the context of a NAT or NAPT, the Internal Address and External
      Address are different.  In the context of a pure firewall, the
      Internal Address and External Address are the same.  In both
      contexts, if an internal host is listening to connections on a
      specific port (that is, operating as a server), the external IP
      address and port number need to be port forwarded to the internal
      IP address and port number, which may be the same, in the case of
      a pure firewall.  In the context of a NAPT, it is possible that
      both the IP address and port are modified.  For example with a
      NAPT, a webcam might be listening on port 80 on its internal
      address 192.168.1.1, while its publicly-accessible external
      address is 192.0.2.1 and port is 12345.  The NAT does 'port
      forwarding' of one to the other.

   PCP Client:
      A PCP software instance responsible for issuing PCP requests to a
      PCP server.  One or several PCP Clients can be embedded in the
      same host.  Several PCP Clients can be located in the same local
      network of a given subscriber.  A PCP Client can issue PCP request
      on behalf of a third party device of the same subscriber.  An
      interworking function, from UPnP IGD to PCP, or from NAT-PMP
      [I-D.cheshire-nat-pmp] is another example of a PCP Client.  A PCP
      server in a NAT gateway that is itself a client of another NAT



Wing, et al.             Expires August 11, 2011                [Page 7]

Internet-Draft         Port Control Protocol (PCP)         February 2011


      gateway (nested NAT) may itself act as a PCP client to the
      upstream NAT.

   PCP Server:
      A network element which receives and processes PCP requests from a
      PCP client.  See also Section 4.

   Interworking Function:
      a functional element responsible for interworking another protocol
      with PCP.  For example interworking between UPnP IGD [IGD] with
      PCP or NAT-PMP [I-D.cheshire-nat-pmp] and PCP.

   subscriber:
      an entity provided access to the network.  In the case of a
      commercial ISP, this is typically a single home.

   host:
      a device which can have packets sent to it, as a result of PCP
      operations.  A host is not necessarily a PCP client.

   5-tuple  The 5 pieces of information that fully identify a flow:
      source IP address, destination IP address, protocol, source port
      number, destination port number.


4.  Relationship of PCP Server and its NAT

   The PCP server receives PCP requests.  The PCP server might be
   integrated within the NAT or firewall device (as shown in Figure 1)
   which is expected to be a common deployment.

                                  +-----------------+
         +------------+           | NAT or firewall |
         | PCP client |-<network>-+      with       +---<Internet>
         +------------+           |    PCP server   |
                                  +-----------------+

            Figure 1: NAT or Firewall with Embedded PCP Server

   It is also possible to operate the PCP server in a separate device
   from the NAT, so long as such operation is indistinguishable from the
   PCP client's perspective.


5.  Common Request and Response Header Format

   All PCP messages contain a request (or response) header containing an
   opcode, any relevant opcode-specific information, and zero or more



Wing, et al.             Expires August 11, 2011                [Page 8]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   options.  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
   Section 8 and Section 9.

5.1.  Request Header

   All requests have the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|Ver=0|R|   OpCode    |                                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+                                       |
     |                         Reserved (84 bits)                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Common Request Packet Format

   These fields are described below:

   1  A single bit set to 1.  This allows DTLS and non-DTLS to be
      multiplexed on same port, should a future update to this
      specification add DTLS support.

   Ver:  This document specifies protocol version 0.  Should later
      updates to this document specify different message formats with a
      version number greater than zero, the first two bytes of those new
      message formats will still contain the version number and opcode
      as shown here, so that a PCP server receiving a message format
      newer or older than the version(s) it understands can still parse
      enough of the message to correctly identify the version number,
      and determine whether the problem is that this server is too old
      and needs to be updated to work with the PCP client, or whether
      the PCP client is too old and needs to be updated to work with
      this server.





Wing, et al.             Expires August 11, 2011                [Page 9]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   R: Indicates Request (0) or Response (1).  All Requests MUST use 0.

   OpCode:  Opcodes are defined in Section 8 and Section 9.  New OpCodes
      can be defined per rules described in Section 13.

   Reserved:  84 reserved bits, MUST be sent as 0 and MUST be ignored
      when received.

5.2.  Response Header

   All responses have the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|Ver=0|R|   Opcode    |      Reserved         |  Result Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Lifetime                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Epoch                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) OpCode-specific response data          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Options                                :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: Common Response Packet Format

   These fields are described below:

   Ver:  This document specifies protocol version 0.  Should later
      updates to this document specify different message formats with a
      version number greater than zero, the first four bytes of those
      new message formats will still contain the version number, opcode,
      and result code, as shown here, so that a PCP client receiving a
      message format newer or older than the version(s) it understands
      can still parse enough of the message to correctly identify the
      version number, and determine whether the problem is that this
      client is too old and needs to be updated to work with the PCP
      server, or whether the PCP server is too old and needs to be
      updated to work with this client.

   R: Indicates Request (0) or Response (1).  All Responses MUST use 1.






Wing, et al.             Expires August 11, 2011               [Page 10]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   OpCode:  The OpCode value from the request.

   Reserved:  12 reserved bits, MUST be sent as 0, MUST be ignored when
      received.

   Result Code:  The result code for this response.  See Section 5.4 for
      values.

   Lifetime:  The value is in seconds.  On a success response this
      indicates the lifetime of the successful mapping.  If a client
      wishes to maintain its mapping beyond this lifetime it MUST renew
      the mapping *before* it expires (typically halfway to expiry,
      analogous to how clients renew a DHCP lease).  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.  Clients SHOULD NOT repeat the same request to the
      same PCP server within the lifetime given in the error response.
      In the case of the SERVER_OVERLOADED error response, clients
      SHOULD NOT send *any* further requests to the that PCP server
      within the lifetime given in the SERVER_OVERLOADED error response.

   Epoch:  The server's Epoch value.  See Section 6.1.4 for discussion.

5.3.  Options

   A PCP OpCode can be extended with an Option.  Options can be used in
   requests and responses.  It is anticipated that Options will include
   information which are associated with the normal function of an
   OpCode.  For example, an Option could indicate DSCP [RFC2474]
   markings to apply to incoming or outgoing traffic associated with a
   PCP mapping, or an Open could include descriptive text (e.g., "for my
   webcam").

   Options use the following Type-Length-Value format:
      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                         :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: Options Header

   The description of the fields is as follows:






Wing, et al.             Expires August 11, 2011               [Page 11]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Option Code:  Option code, 8 bits.  The first bit of the option code
      is the "P" bit, described below.  Option codes MUST be registered
      with IANA following the procedure described in Section 13.

   Reserved:  MUST be set to 0 on transmission and MUST be ignored on
      reception.

   Option-Length:  Indicates in units of 4 octets the length of the
      enclosed data.  Options with length of 0 are allowed.

   data:  Option data.  The option data MUST end on a 32 bit boundary,
      padded with 0's when necessary.

   A given Option MAY be included in a request or a response, as
   permitted by that Option.  If a given Option was included in a
   request, and understood and processed by the PCP server, it MUST be
   included in the response.  The handling of an Option by the PCP
   client and PCP server MUST be specified in an appropriate document
   and must include whether the PCP Option can appear (one or more
   times) in a request, and indicate the contents of the Option in the
   request and in the response.  If several Options are included in a
   PCP request or response, they can be encoded in any order by the PCP
   client.  The response MUST encode them in the same order, but may
   omit some PCP Options in the response (e.g., omitting them is
   necessary to indicate the PCP server does not understand that Option,
   or simply because that Option is not included in responses), and
   additional options (if any) are included at the end.  A single Option
   MAY appear more than once, if permitted by the definition of the
   Option itself.  If the Option's definition allows the Option to
   appear once but it appears more than once, the PCP server MUST
   respond with the MALFORMED_OPTION response code.

   If the "P" bit in the OpCode is set,

   o  the PCP server MUST only generate a positive PCP response if it
      can successfully process the PCP request and this Option.

   o  if the PCP server does not implement this Option, or cannot
      perform the function indicated by this Option (e.g., due to a
      parsing error with the option), it MUST generate a failure
      response and include the UNPROCESSED option in the response
      (Section 6.3.1).

   If the "P" bit is clear, the PCP server MAY process or ignore this
   Option.

   To enhance interoperability, newly defined Options should avoid
   interdependencies with each other.



Wing, et al.             Expires August 11, 2011               [Page 12]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   New Options MUST include the information below:

      This Option:

         name: <mnemonic>

         number: <value>

         purpose:

         is valid for OpCodes: <list of OpCodes>

         has length: <rules for length>

         may appear in requests or responses: <requests/responses/both>

         may appear more than once: <yes/no>

5.4.  Result Codes

   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.

   0  SUCCESS, success

   1  UNSUPP_VERSION, unsupported version

   2  UNSUPP_OPCODE, unsupported OpCode

   3  UNSUPP_OPTION, unsupported Option

   4  MALFORMED_OPTION, malformed Option (e.g., exists too many times,
      invalid length)

   5  UNSPECIFIED_ERROR, server encountered unspecified error

   6  MALFORMED_REQUEST

   7  SERVER_OVERLOADED.  Client should wait for at least the time
      specified in the "Lifetime" field before sending any further PCP
      requests to this server.

   Additional result codes, specific to the OpCodes defined in this
   document, are listed in Section 8.2 and Section 9.2 .






Wing, et al.             Expires August 11, 2011               [Page 13]

Internet-Draft         Port Control Protocol (PCP)         February 2011


6.  General PCP Operation

   PCP messages MUST be sent over UDP, and the PCP server MUST listen
   for PCP requests on the PCP port number (Section 13.1).  Every PCP
   request generates a response, so PCP does not need to run over a
   reliable transport protocol.

   PCP is idempotent, so if the PCP client sends the same request
   multiple times and the PCP server processes those requests, the same
   result occurs.  The order of operation is that a PCP client generates
   and sends a request to the PCP server which processes the request and
   generates a response back to the PCP client.

6.1.  General PCP Client Operation

   This section details operation specific to a PCP client, for any
   OpCode.  Procedures specific to the MAP OpCodes are described in
   Section 8, and procedures specific to the PEER OpCodes are described
   in Section 9.

6.1.1.  Generating and Sending a Request

   Prior to sending its first PCP message, the PCP client determines
   which servers to use.  The PCP client tries the following to get a
   list of PCP servers:

   1.  if a PCP server is configured (e.g., in a configuration file),
       the address(es) of the PCP server(s) are used as the list of PCP
       server(s), else;

   2.  if DHCP indicates the PCP server(s), the address(es) of the
       indicated PCP server(s) are used as the list of PCP server(s),
       else;

   3.  the address of the default router is used as the PCP server.

   With that list of PCP servers, the PCP client formulates its PCP
   request.  The PCP request contains a PCP common header, PCP OpCode
   and payload, and (possibly) Options.  It initializes a retransmission
   timer to 4 seconds.  (As with all UDP or TCP clients on any operating
   system, when several PCP clients are embedded in the same host, each
   uses a distinct source port number to disambiguate their requests and
   replies.)  The PCP client sends a PCP message to each server in
   sequence, waiting for a response until its timer expires.  Once a PCP
   client has successfully communicated with a PCP server, it continues
   communicating with that PCP server until that PCP server becomes non-
   responsive, which causes the PCP client to attempt to re-iterate the
   procedure starting with the first PCP server on its list.  If a hard



Wing, et al.             Expires August 11, 2011               [Page 14]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   ICMP error is received the PCP client SHOULD immediately abort trying
   to contact that PCP server (see Section 2 of [RFC5461] for discussion
   of ICMP and ICMPv6 hard errors).  If no response is received from any
   of those servers, it doubles its retransmission timer and tries each
   server again.  This is repeated 4 times (for a total of 5
   transmissions to each server).  If, after these transmissions, the
   PCP client has still not received a response, the PCP client SHOULD
   abort the procedure.

      [Ed. Note: We need to define precisely what we mean by "non-
      responsive".  No response after some number of retransmissions?
      How many?  No response within what time period? -- SC]

   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.

6.1.2.  Processing a Response

   The PCP client receives the response and verifies the source IP
   address and port belong to the PCP server of an outstanding request.
   It validates the version number and OpCode matches an outstanding
   request.  Responses shorter than 8 octets, longer than 1024 octets,
   or not a multiple of 4 octets are invalid and ignored.  The response
   is further matched by comparing fields in the response OpCode-
   specific data to fields in the request OpCode-specific data.  After a
   successful match with an outstanding request, the PCP client checks
   the Epoch field to determine if it needs to restore its state to the
   PCP server (see Section 6.1.4).

   If the response code is 0, the PCP client knows the request was
   successful.

   If the response code is not 0, the request failed.  The PCP client
   MAY resend the same message but MUST first wait until the smaller of
   30 minutes or the value of the Lifetime field.  If the PCP client has
   re-discovered a new PCP server (e.g., connected to a new network),
   the PCP client is not restricted from communicating immediately with
   its new PCP server.

   A PCP client sends its requests using PCP version number 0.  Should
   later updates to this document specify different message formats with
   a version number greater than zero it is expected that PCP servers
   will still support version 0 in addition to the newer version(s).
   However, in the event that a server returns a response with error
   code UNSUPP_VERSION, 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 (in case this



Wing, et al.             Expires August 11, 2011               [Page 15]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   was a temorary condition and the server configuration is changed to
   rectify the situation).

   If future PCP versions greater than zero are specified, version
   negotiation is expected to proceed as follows:

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

   2.  Client sends first request using highest (i.e. presumably 'best')
       version number it supports.

   3.  If server supports that version it responds normally.

   4.  If server does not support that version it replies giving a
       response containing the error 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).

   5.  If the client receives an UNSUPP_VERSION response 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).

   6.  If the client receives an UNSUPP_VERSION response 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.

6.1.3.  Multi-interface Issues

   Hosts which desire a PCP mapping might be multi-interfaced (i.e., own
   several logical/physical interfaces).  Indeed, a host can be dual-
   stack or be configured with several IP addresses.  These IP addresses
   may have distinct reachability scopes (e.g., if IPv6 they might have
   global reachability scope as for GUA (Global Unicast Address) or
   limited scope such as ULA (Unique Local Address, [RFC4193])).

   IPv6 addresses with global reachability scope SHOULD be used as
   internal IP address when requesting a PCP mapping in a PCP-controlled
   device.  IPv6 addresses with limited scope (e.g., ULA), SHOULD NOT be



Wing, et al.             Expires August 11, 2011               [Page 16]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   indicated as internal IP address in a PCP message.

   As mentioned in Section 2.3, only single-homed CP routers are in
   scope.  Therefore, there is no viable scenario where a host located
   behind a CP router is assigned with two GUA addresses belonging to
   the same global IPv6 prefix.

      [Ed. Note: text regarding multi-homing needs work.]

6.1.4.  Epoch

   Every PCP response sent by the PCP server includes an Epoch field.
   This field increments by 1 every second, and indicates to the PCP
   client if PCP state needs to be restored.  If the PCP server resets
   or loses the state of its Mappings, due to reboot, power failure, or
   any other reason, it MUST reset its Epoch time to 0.  Similarly, if
   the public IP address(es) of the NAT (controlled by the PCP server)
   changes, the Epoch MUST be reset to 0.  A PCP server MAY maintain one
   Epoch value for all PCP clients, or MAY maintain distinct Epoch
   values for each PCP client; this choice is implementation-dependent.

   Whenever a client receives a PCP response, the client computes its
   own conservative estimate of the expected Epoch value by taking the
   Epoch value in the last packet it received from the gateway and
   adding 7/8 (87.5%) of the time elapsed since that packet was
   received.  If the Epoch value in the newly received packet is less
   than the client's conservative estimate by more than one second, then
   the client concludes that the PCP server lost state, and the client
   MUST immediately renew all its active port mapping leases as
   described in Section 8.6.1.

      [Ed. Note: comment from Dave Thaler: "So spoofed packets with
      Epoch=0 that look like they come from the server could result in a
      big amplification attack on the PCP server.  How is this
      mitigated?".  This is tracked as PCP Issue #21, [PCP-Issues].]

6.2.  General PCP Server Operation

   This section details operation specific to a PCP server.

   Upon receiving a PCP request message, 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.




Wing, et al.             Expires August 11, 2011               [Page 17]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   If the received message is shorter than 4 octets, has the R bit set,
   or the first bit is clear, the request is simply dropped.  If the
   version number is not supported, a response is generated containing
   the UNSUPP_VERSION response code and the protocol version which the
   server does understand (if the server understands a range of protocol
   versions then it returns the supported version closest to the version
   in the request).

   If the OpCode is not supported, a response is generated with the
   UNSUPP_OPCODE response code.  If the length of the request exceeds
   1024 octets or is not a multiple of 4 octets, it is invalid.  Invalid
   requests are handled by copying up to 1024 octets of the request into
   the response, setting the response code to MALFORMED_REQUEST, and
   zero-padding the response to a multiple of 4 octets if necessary.

   Error responses have the same packet layout as success responses,
   with fields copied from the request copied into the response, and
   other fields assigned by the PCP server set to 0.

      [Ed. Note: Need more detail around how an error response is
      formed, and what it contains.]

6.3.  General PCP Options

   The following options can appear in certain PCP responses.

6.3.1.  UNPROCESSED

   If the PCP server cannot process a mandatory-to-process option, for
   whatever reason, it includes this Option in the response.  This helps
   with debugging interactions between the PCP client and PCP server.
   For simplicity, no more than 4 options can be encoded.  This option
   MUST NOT appear more than once in a PCP response, no matter how many
   PCP options appeared in the request and were unprocessed by the PCP
   server.  If only one Option code was unprocessed, that option code it
   is placed in option-code-1 (and the other three fields are set to
   zero), if two Option codes were unprocessed, their option codes are
   placed in option-code-1 and option-code-2, and so on.  If a certain
   Option appeared more than once in the PCP request, that Option value
   only appears once in the option-code fields.  The order of the
   Options in the PCP request has no relationship with the order of the
   Option values in this UNPROCESSED Option.  This Option MUST NOT
   appear in a response unless the associated request contained at least
   one mandatory-to-process Option.







Wing, et al.             Expires August 11, 2011               [Page 18]

Internet-Draft         Port Control Protocol (PCP)         February 2011


      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 | option-code-2 | option-code-3 | option-code-4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5: UNPROCESSED option

      This Option:

         name: UNPROCESSED

         number: TBD

         purpose: indicates which PCP options in the request are not
         supported by the PCP server

         is valid for OpCodes: all

         has length: 1

         may appear in requests or responses: responses, and only if the
         response code is non-zero.

         may appear more than once: no


7.  Introduction to MAP and PEER OpCodes

   There are three uses for the MAP and PEER OpCodes defined in this
   document: a host operating a server (and wanting an incoming
   connection), a host operating a client (and wanting to optimize the
   application keepalive traffic), and a host operating a client and
   server on the same port.  These are discussed in the following
   sections.

   When operating a server (Section 7.1 and Section 7.3) 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 interface on
   itself or an IPv6 interface on itself.  It takes the union of this
   knowledge to decide to send a one or two MAP requests for each of its
   interfaces.  Applications that embed IP addresses in payloads (e.g.,
   FTP, SIP) will find it beneficial to avoid address family
   translation, if possible.







Wing, et al.             Expires August 11, 2011               [Page 19]

Internet-Draft         Port Control Protocol (PCP)         February 2011


7.1.  For Operating a Server

   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 application needs to (a)
   create a mapping from a public IP address and port to itself as
   described in Section 8 and (b) publish that public IP address and
   port via some sort of rendezvous server (e.g., DNS, a SIP message, a
   proprietary protocol).  Publishing the public IP address and port is
   out of scope of this specification.  To accomplish (a), the
   application follows the procedures described in this section.

   As normal, the application needs to begin listening to a port, and to
   ensure that it can get exclusive use of that port it needs to choose
   a port that is not in the operating system's ephemeral port range.
   Then, the application constructs a PCP message with the appropriate
   MAP OpCode depending on if it is listening on an IPv4 or IPv6
   interface and if it wants a public IPv4 or IPv6 address.

   The following pseudo-code shows how PCP can be reliably used to
   operate a server:

   /* start listening on the local server port */
   int s = socket(...);
   internal_sockaddr = ...;
   bind(s, &internal_sockaddr, ...);
   listen(s, ...);
   requested_external_sockaddr = 0;
   pcp_send_map_request(internal_sockaddr,
      requested_external_sockaddr, &assigned_external_sockaddr,
      requested_lifetime, &assigned_lifetime);
   update_rendezvous_server("Client 12345", assigned_external_sockaddr);
   while (1) {
       int c = accept(s, ...);
       /* ... */
   }

          Figure 6: Pseudo-code for using PCP to operate a server

7.2.  For Reducing NAT Keepalive Messages

      [Ed. Note: This section creates a difference between an
      implicitly-created mapping, which PCP then tries to query/control
      using the PEER OpCode, and a explicitly-created mapping which was
      created with a MAP OpCode.  This section attempts to address PCP
      Issue #9 and PCP Issue #35.]

   A host operating a client (e.g., XMPP client, SIP client) sends from



Wing, et al.             Expires August 11, 2011               [Page 20]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   a port but never accepts incoming connections on this port.  It wants
   to ensure the flow to its server is not terminated (due to
   inactivity) by an on-path NAT or firewall.  To accomplish this, the
   applications uses the procedure described in this section.

   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.

      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, detect a crashed server, 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.

   To use PCP for this function, the applications first connects to its
   server, as normal.  Afterwards, it issues a PCP request with the
   PEER4 or PEER6 OpCode as described in Section 9.  The PEER4 OpCode is
   used if the host is using IPv4 for its communication to its peer;
   PEER6 if using IPv6.  The same 5-tuple as used for the connection to
   the server is placed into the PEER4 or PEER6 payload.

   The following pseudo-code shows how PCP can be reliably used with a
   dynamic socket, for the purposes of reducing application keepalive
   messages:

         int s = socket(...);
         connect(s, &remote_peer, ...);
         getsockname(s, &internal_address, ...);
         external_address = NUL;
         pcp_send_peer_request(internal_address,
            requested_external_address, &assigned_external_address,
            remote_peer, requested_lifetime, &assigned_lifetime);

           Figure 7: Pseudo-code using PCP with a dynamic socket

7.3.  For Operating a Symmetric Client/Server

      [Ed. Note: The PEER4 and PEER6 OpCodes, discussed here, are
      intended to resolve PCP Issue #35.]

   A host operating a client and server on the same port (e.g.,
   Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport)
   [RFC3581]) first establishes a local listener, (usually) sends the



Wing, et al.             Expires August 11, 2011               [Page 21]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   local and public IP addresses and ports to a rendezvous service
   (which is out of scope of this document), and (usually) initiates
   outbound connections from that same source address.  To accomplish
   this, the application uses the procedure described in this section.

   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 Section 8, and
   receive a positive PCP response before it sends any packets from that
   port.

      Discussion: Although reversing those steps is tempting (to
      eliminate the PCP round trip before a packet can be sent from that
      port) and will work if the NAT has endpoint-independent mappings
      (EIM) behavior, reversing the steps will fail if the NAT does not
      have EIM behavior.  With a non-EIM NAT, the implicit mapping
      created by an outgoing TCP SYN and the explicit mapping created
      using the MAP OpCode will cause different ports to be assigned
      (which is not desirable; after all, the application is using the
      same port for outgoing and incoming traffic on purpose) and they
      will generally also have different lifetimes.  PCP does not
      attempt to change or dictate how a NAT creates its mappings
      (endpoint independent mapping, or otherwise) so there is no
      assurance that an implicit mapping will be EIM or non-EIM.  Thus,
      it is necessary for applications to first signal its operation of
      a server using hte PCP MAP OpCode.

























Wing, et al.             Expires August 11, 2011               [Page 22]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   The following pseudo-code shows how PCP can be used to operate a
   symmetric client and server:

   /* start listening on the local server port */
   int s = socket(...);
   internal_sockaddr = ...;
   bind(s, &internal_sockaddr, ...);
   listen(s, ...);
   requested_external_sockaddr = 0;
   pcp_send_map_request(internal_sockaddr,
      requested_external_sockaddr, &assigned_external_sockaddr,
      requested_lifetime, &assigned_lifetime);
   update_rendezvous_server("Client 12345", assigned_external_sockaddr);
   send_packet(s, "Hello World");
   while (1) {
       int c = accept(s, ...);
       /* ... */
   }


    Figure 8: Pseudo-code for using PCP to operate a symmetric client/
                                  server


8.  MAP OpCodes

   This section defines four OpCodes which control forwarding from a NAT
   (or firewall) to an internal host.  They are:

     MAP4=0:  create a mapping between an internal address and public
              IPv4 address (e.g., NAT44, NAT64, or firewall)

     MAP6=1:  create a mapping between an internal address and public
              IPv6 address (e.g., NAT46, NAT66, or firewall)

   The operation of these OpCodes is described in this section.

8.1.  OpCode Packet Formats

   The two MAP OpCodes (MAP4, MAP6) share a similar packet layout for
   both requests and responses.  Because of this similarity, they are
   shown together.  For both of the MAP OpCodes, if the assigned
   external IP address and assigned external port both match the
   request's source IP address and MAP OpCode's internal IP address, the
   functionality is purely a firewall; otherwise it pertains to a
   network address translator which might also perform firewall
   functions.




Wing, et al.             Expires August 11, 2011               [Page 23]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   The following diagram shows the request packet format for MAP4 and
   MAP6.  This packet format is aligned with the response packet format:


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |          Reserved (24 bits)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Requested external IP address (32 or 128, depending on OpCode):
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Requested lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        internal port          |   requested external port     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: MAP OpCode Request Packet Format

   These fields are described below:

   Requested External IP Address:  Requested external IP address.  This
      is useful for refreshing a mapping, especially after the PCP
      server loses state.  If the PCP server can fulfill the request, it
      will do so.  If the PCP client doesn't know the external address,
      or doesn't have a preference, it MUST use 0.

   Requested lifetime:  Requested lifetime of this mapping, in seconds.

   Internal port:  Internal port for the mapping.

   Requested external port:  requested external port for the mapping.
      This is useful for refreshing a mapping, especially after the PCP
      server loses state.  If the PCP server can fulfill the request, it
      will do so.  If the PCP client doesn't know the external port, or
      doesn't have a preference, it uses 0.

   The following diagram shows the response packet format for MAP4 and
   MAP6 OpCodes:











Wing, et al.             Expires August 11, 2011               [Page 24]

Internet-Draft         Port Control Protocol (PCP)         February 2011


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Assigned external IP address (32 or 128, depending on OpCode) :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       internal port           |    assigned external port     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 10: MAP OpCode Response Packet Format

   These fields are described below:

   Assigned external IP address:  Assigned external IPv4 or IPv6 address
      for the mapping.  IPv4 or IPv6 address is indicated by the OpCode

   Internal port:  Internal port for the mapping, copied from request.

   Assigned external port:  assigned external port for the mapping.
      IPv4 or IPv6 address is indicated by the OpCode.  If the NAT
      gateway can allocate the requested external port it SHOULD do so.
      This is beneficial for re-establishing state lost when a NAT
      gateway fails or loses its state due to reboot.  If the NAT
      gateway cannot allocate the requested external port but can
      allocate some other port, it MUST do so and return the allocated
      port in the response.  Cases where a NAT gateway cannot allocate
      the requested external port include when the requested external
      port is prohibited by policy, already used by the NAT gateway for
      one of its own services (e.g. port 80 for the NAT gateway's own
      configuration pages) already allocated to another explicit mapping
      (by static manual allocation or by a prior PCP request by a
      different Internal Host) or the rare case where the requested
      external port was already allocated to an implicit mapping which
      cannot be 'promoted' to an explicit mapping for this Internal Host
      (a different Internal Host already made a prior outbound
      connection for which the NAT gateway happened to assign the
      external port requested in this explicit PCP request).

8.2.  OpCode-Specific Result Codes

   In addition to the general PCP result codes (Section 5.4), the
   following additional result codes may be returned as a result of the
   four MAP OpCodes received by the PCP server.







Wing, et al.             Expires August 11, 2011               [Page 25]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   20 NETWORK_FAILURE, e.g., NAT device has not obtained a DHCP lease

   21 NO_RESOURCES, e.g., NAT device cannot create more mappings at this
      time.  This is a system-wide error, and different from
      USER_EX_QUOTA.

   22 UNSUPP_PROTOCOL, unsupported Protocol

   23 NOT_AUTHORIZED, e.g., PCP server supports mapping, but the feature
      is disabled for this PCP client, or the PCP client requested a
      mapping that cannot be fulfilled by the PCP server's security
      policy.

   24 USER_EX_QUOTA, mapping would exceed user's port quota

   25 CANNOT_PROVIDE_EXTERNAL_PORT, indicates the port is already in use
      or otherwise unavailable (e.g., special port that cannot be
      allocated by the server's policy).  This error is only returned if
      the request included the Option PREFER_FAILURE.

   26 UNABLE_TO_DELETE_ALL, indicates the PCP server was not able to
      delete all mappings.

   Other result codes are defined following the procedure in
   Section 13.3.

8.3.  OpCode-Specific Client Operation, Processing a Response

   This section describes the operation of a PCP client when sending
   requests with OpCodes MAP4 and MAP6, and processing those responses.

   A PCP client can delete a mapping immediately by sending the
   appropriate MAP OpCode with a lifetime of 0.  The PCP server responds
   by returning a MAP Response with a lifetime of 0.

   To delete all mappings for all hosts associated with this subscriber,
   an all-zero internal IP address is used.

   The request MAY contain values in the requested-external-ip-address
   and requested-external-port fields.  This allows the PCP client to
   attempt to rebuild the PCP server's state, so that the PCP client
   could avoid having to change information maintained at the 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 fulfill the request.

   An existing mapping can have its lifetime extended by the PCP client.
   To do this, the PCP client sends a new PCP map request to the server



Wing, et al.             Expires August 11, 2011               [Page 26]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   indicating the internal IP address and port(s).

   The PCP client SHOULD renew the mapping before its expiry time,
   otherwise it will be removed by the PCP server (see Section 8.4.3).
   In order to prevent excessive PCP chatter, it is RECOMMENDED to send
   a single renewal request packet when a mapping is halfway to
   expiration time, then, if no positive response is received, another
   single renewal request 3/4 of the way to expiration time, and then
   another at 7/8 of the way to expiration time, 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 an infinite number of ever-
   closer-together requests in the last few seconds before a mapping
   expires).

   To delete a mapping, lifetime=0 is used.  To delete a mapping for a
   specific protocol and port, the MAP request contains that specific
   internal port and protocol.  To delete all mappings for a particular
   protocol, port 0 is used to indicate a wildcard.

   A response is matched with a request by comparing the protocol,
   internal IP address, internal port, external address and external
   port.  Other fields are not compared, because the PCP server changes
   those fields to provide information about the mapping created by the
   OpCode.

   If a successful response, the PCP client can use the external IP
   address and port(s) as desired.  Typically the PCP client will
   communicate the external IP address and port(s) to another host on
   the Internet using an application-specific rendezvous mechanism such
   as DNS SRV records.

   When a PCP client first acquires a new IP address, it may want to
   remove mappings that may have been instantiated for a previous host.
   To do this, the PCP client sends a MAP request with external port,
   internal port, and lifetime set to 0.

8.4.  OpCode-Specific Server Operation

   This section describes the operation of a PCP server when processing
   the OpCodes MAP4 or MAP6.

   If the requested lifetime is 0, it indicates a request to delete the
   mapping immediately.  The contents of the protocol field or the
   internal-port field can be zero, indicating a wildcard.  If the
   protocol field is 0, it indicates all protocols (and the internal-
   port field is ignored).  If the internal-port is 0, it means all
   ports for the particular protocol.  On a deletion request, the
   requested external port field is ignored by the server.  If the



Wing, et al.             Expires August 11, 2011               [Page 27]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   deletion request was properly formatted, and the associated mapping
   (if present) is deleted, a positive response is generated with
   lifetime of 0 and copies the protocol and internal port number from
   the request into the response.  If the PCP client attempts to delete
   a port mapping which was manually assigned by some kind of
   configuration tool, the PCP server MUST respond with
   UNABLE_TO_DELETE_ALL result code, but the other fields are encoded as
   described above.  If the PCP client attempts to delete a mapping that
   does not exist, the success response code is returned.  If the PCP
   client is not authorized to delete this mapping, NOT_AUTHORIZED is
   returned.

   If the requested lifetime is not zero, it indicates a request to
   create a mapping or extend the lifetime of an existing mapping.

   If the PCP request contains protocol=255, it indicates the PCP client
   wants to map all protocols.  If this cannot be fulfilled by the PCP-
   controlled device, UNSUPP_PROTOCOL is returned.

   See Section 8.4.2 for processing the lifetime.

   If the requested external port is 0, and the PCP-controlled device
   does not change port numbers (that is, it does not do port
   translation) the PCP server MUST return a response indicating that
   the assigned external port is the same as the internal port.

   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 and 1:1
   NAT44 (both of which modify addresses but not port numbers).

   If an option with value greater than 128 exists but that option does
   not make sense (e.g., the PREFER_FAILURE option is included in a
   request with lifetime=0 (indicating a delete request)), the request
   is invalid and generates a MALFORMED_OPTION error.

   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.

   If the THIRD_PARTY option is not present in the request, the source
   IP address of the PCP packet is used when creating the mapping.  If
   the THIRD_PARTY option is present, the PCP server then validates that
   internal IP address indicated in that option belongs to the same



Wing, et al.             Expires August 11, 2011               [Page 28]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   subscriber.  This validation depends on the PCP deployment scenario;
   see Section 10.5 for the validation procedure.  If the internal IP
   address in the PCP request does not belong to the subscriber, an
   error response MUST be generated with result code NOT_AUTHORIZED.

   If all of the proceeding operations were successful (did not generate
   an error response), then the requested mappings are created as
   described in the request and a positive response is built.  This
   positive result contains the same OpCode as the request, but with the
   "R" bit set.

   As a side-effect of creating a mapping, ICMP messages associated with
   the mapping are also translated (if appropriate) and forwarded 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 signal PCP
   separately to create ICMP mappings for those flows.

8.4.1.  Maintaining Same External IP Address

   If there are active mappings associated with a given subscriber (see
   Section 10.5) -- created via dynamic assignment, by PCP or any other
   means -- subsequent PCP mapping requests belonging to the same
   subscriber MUST use the same external IP address.  This follows the
   intent of REQ-1 of [I-D.ietf-behave-lsn-requirements].

   Once an internal host has no active mapping in the PCP-controlled
   device, a subsequent PCP request for that host MAY be assigned to a
   different external IP address.

8.4.2.  Mapping Lifetime

   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 RECOMMENDED values are 120 seconds for the minimum
   value and 24 hours for the maximum.  It is NOT RECOMMENDED that the
   server allow lifetimes exceeding 24 hours, because they will consume
   ports even if the internal host is no longer interested in receiving
   the traffic or no longer connected to the network.

   Once a PCP server has responded positively to a mapping request for a
   certain lifetime, the port forwarding 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).




Wing, et al.             Expires August 11, 2011               [Page 29]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   An application that forgets its PCP-assigned mappings (e.g., the
   application or OS crashes) will request new PCP mappings (consuming
   the user's port quota (if there is a quota) and the resource limit
   for number of mappings), and the application will also probably
   initiate dynamic connections to servers without using PCP (also
   consuming the user's port quota).  PCP provides no explicit
   protection against such port consumption.  In such environments, it
   is RECOMMENDED that applications use shorter PCP lifetimes to reduce
   the impact of consuming the user's port quota.

   An OS that issues a "delete all" request on reboot protects itself
   against this resource exhaustion by voluntarily relinquishing all of
   its old mappings before beginning to request new ones.  The PCP
   server MAY chose to allocate the same (recently relinquished)
   mappings when mappings are re-requested by the booting OS.

   Some port mapping APIs (such as the "DNSServiceNATPortMappingCreate"
   API provided by Apple's Bonjour on Mac OS X, iOS, Windows, Linux,
   etc.) 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.

8.4.3.  Mapping Deletion

   A mapping MUST be deleted by the PCP server upon the expiry of its
   lifetime, or upon request from the PCP client.

   In order to prevent another subscriber from receiving unwanted
   traffic, the PCP server SHOULD NOT assign that same external port to
   another host for 120 seconds (MSL, [RFC0793]).  The PCP server MUST
   allow the same host to re-acquire the same port during that same
   interval.

8.4.4.  Subscriber Renumbering

   The customer premises router might obtain a new IPv4 address or new
   IPv6 prefix.  This can occur because of 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 subscriber
   might be delivered to another customer who now has that address --
   both traffic mapped with MAP requests and dynamic traffic.  This same
   problem can occur if an IP address is re-assigned today, without PCP
   and without an ISP-operated CGN.  The solution is the same as today:
   the problems associated with subscriber renumbering are eliminated if
   the ISP avoids re-assigning IP addresses to different subscribers.

   When a new Internal Address is assigned to a host embedding a PCP



Wing, et al.             Expires August 11, 2011               [Page 30]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   client, the NAT (or firewall) controlled by the PCP server will
   continue to send traffic to the old IP address.  Assuming the PCP
   client wants to continue receiving traffic, it needs to install new
   mappings for its new IP address.  The requested 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 public IP
   address.  Note that this scenario 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.

8.5.  PCP Options for MAP OpCodes

8.5.1.  THIRD_PARTY

   This Option is used when a PCP client wants to control a mapping to
   another host.  A PCP server will only support this option if sent by
   an authorized PCP client, which depends on the deployment scenario.
   For Dual-Stack Lite deployments, the PCP server only supports this
   option if the source IPv4 address is the B4's source IP address.  For
   other scenarios, the subscriber has only one IPv4 address and this
   Option serves no purpose.  If a subscriber has more than one IPv4
   address, the ISP MUST determine its own policy for how to identify
   the trusted device within the subscriber's home.  This might be, for
   example, the lowest- or highest-numbered host address for that user's
   IPv4 prefix.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol     |          Reserved (24 bits)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   : Mapping Internal IP address (32 or 128, depending on OpCode)  :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Protocol:  indicates protocol associated with this OpCode.  Values
      are taken from the IANA protocol registry [proto_numbers].  For
      example, this field contains 6 (TCP) if the opcode is intended to
      create a TCP mapping.

   Reserved:  24 reserved bits, MUST be 0 on transmission and MUST be
      ignored on reception.





Wing, et al.             Expires August 11, 2011               [Page 31]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Mapping Internal IP Address:  Internal IP address of the mapping.
      This can be IPv4 or IPv6, depending on the OpCode.

8.5.2.  REMOTE_PEER_FILTER

   This Option indicates packet filtering is desired.  The remote peer
   port and remote peer IP Address indicate the permitted remote peer's
   source IP address and port for packets from the Internet.  That is,
   packets with a source IP address, transport, or port that do not
   match those fields of the PCP request are dropped by the PCP server-
   controlled NAT/firewall device.
      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   | prefix-length |   Remote Peer Port            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :     Remote Peer IP address (32 bits if MAP4,                  :
     :              1 28 bits if MAP6)                               :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This Option:

         name: REMOTE_PEER_FILTER

         number: 128

         is valid for OpCodes: MAP44, MAP64, MAP46, or MAP66

         is included in responses: MUST

         has length: 2 or 5

         may appear in requests or responses: requests

         may appear more than once: no

   Because of interactions with dynamic ports this Option MUST only be
   used by a client that is operating a server, as this ensures that no
   other application will be assigned the same ephemeral port for its
   outgoing connection.  Other use by a PCP client is NOT RECOMMENDED
   and will cause some UNSAF NAT traversal mechanisms [RFC3424] to fail
   where they would have otherwise succeeded, breaking other
   applications running on this same host.

   The prefix-length indicates how many bits of the IPv6 address or IPv4
   address are used for the filter.  For MAP4, a prefix-length of 32



Wing, et al.             Expires August 11, 2011               [Page 32]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   indicates the entire IPv4 address is used; a prefix-length of 0
   indicates none of the IPv4 address is used (which is effectively the
   same as not adding a filter at all).  For MAP4 the minimum value is 0
   and the maximum value is 32; for MAP6 the minimum value is 0 and the
   maximum value is 128.  Values outside that range cause an
   MALFORMED_OPTION response code.

      [Ed. Note: How do we want to remove a filter?  Do we want to allow
      removing a filter at all -- is there a use-case for that or can
      the application just create a new mapping?  If we have a use-case,
      perhaps use 0.0.0.0 as the remote IP address to remove all
      filters?  This is tracked as PCP Issue #10 [PCP-Issues].]

8.5.3.  PREFER_FAILURE

   This option indicates that if the PCP server is unable to allocate
   the requested port, then instead of returning an available port that
   it *can* allocate, the PCP server should instead allocate no port and
   return result code CANNOT_HONOR_EXTERNAL_PORT.

   This option is intended solely for use by UPnP IGD interworking
   (Section 11), where the semantics of IGD version 1 do not provide any
   way to indicate to an IGD client that any port is available other
   than the one it requested.  A PCP server MAY support this option, if
   its designers wish to support downstream devices that perform IGD
   interworking.  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.  PCP servers that are
   not intended to support downstream devices that perform IGD
   interworking are not required to support this option.  PCP clients
   other than IGD interworking clients MUST NOT use this option because
   it results in inefficient operation, and they cannot safely assume
   that all PCP servers will implement it.  The option is provided only
   because the semantics of IGD version 1 offer no viable alternative
   way to implement an IGD interworking function.  It is anticipated
   that this option will be deprecated in the future as more clients
   adopt PCP natively and the need for IGD interworking declines.

      This Option:

         name: PREFER_FAILURE

         number: 130

         is valid for OpCodes: MAP4, MAP6





Wing, et al.             Expires August 11, 2011               [Page 33]

Internet-Draft         Port Control Protocol (PCP)         February 2011


         is included in responses: MUST

         has length: 0

         may appear in requests or responses: requests

         may appear more than once: no

8.6.  PCP Mapping State Maintenance

   If an event occurs that causes the PCP server to lose state (such as
   a crash or power outage), the mappings created by PCP are lost.  Such
   loss of state is rare in a service provider environment (due to
   redundant power, disk drives for storage, etc.).  But such loss of
   state is more common in a residential NAT device which does not write
   information to its non-volatile memory.

   The Epoch allows a client to deduce when a PCP server may have lost
   its state.  If this occurs, the PCP client can attempt to recreate
   the mappings following the procedures described in this section.

8.6.1.  Recreating Mappings

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

   However, maintaining this state is not essential for correct
   operation.  When the PCP server loses state and begins processing new
   PCP messages, its Epoch is reset to zero (per the procedure of
   Section 6.1.4).

   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 the PCP server
   it appears as a new mapping request.

   This self-healing property of the protocol is very important.

   When a client renews its port mappings as the result of receiving a
   packet where the Epoch field indicates that a reboot or similar loss
   of state has occurred, the client MUST first delay by a random amount
   of time selected with uniform random distribution in the range 0 to 5
   seconds, and then send its first PCP request.  After that request is
   acknowledged by the PCP server, the client may then send its second



Wing, et al.             Expires August 11, 2011               [Page 34]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   request, and so on, as rapidly as the gateway allows.  The requests
   SHOULD be issued serially, one at a time; the client SHOULD NOT issue
   multiple requests simultaneously in parallel.

      [Ed. Note: the paragraph above is copied from NAT-PMP, and seems
      to be advice specific to receiving asynchronous notification that
      the Epoch was reset.  Asynchronous notification needs the delay
      described (in fact, it probably needs greater delay than 0-5
      seconds if on a larger network) and also needs to discourage
      sending multiple PCP requests serially.  However, PCP does not
      have asynchronous notification (yet), and has different needs/
      requirements for pacing.  In short: the above paragraph needs some
      discussion.  This is tracked as PCP Issue #11 [PCP-Issues].]

   The discussion in this section focuses on recreating inbound port
   mappings after loss of PCP server state, because that is the more
   serious problem.  Losing port mappings for outgoing connections
   destroys those currently active connections, but does not prevent
   clients from establishing new outgoing connections.  In contrast,
   losing inbound port mappings not only destroys all existing inbound
   connections, but also prevents the reception of any new inbound
   connections until the port mapping is recreated.  Accordingly, we
   consider recovery of inbound port mappings the more important
   priority.  However, clients that want outgoing connections to survive
   a NAT gateway reboot can also achieve that using PCP.  After
   initiating an outbound TCP connection (which will cause the NAT
   gateway to establish an implicit port mapping) the client should send
   the NAT gateway a port mapping request for the source port of its TCP
   connection, which will cause the NAT gateway to send a response
   giving the external port it allocated for that mapping.  The client
   can then store this information, and use it later to recreate the
   mapping if it determines that the NAT gateway has lost its mapping
   state.

8.6.2.  Maintaining Mappings

   A PCP client can refresh 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
   failure of the PCP server, that the public IP address and/or public
   port, or the PCP server itself, has changed (due to a new route to a
   different PCP server).  To detect such events more quickly, the PCP
   client may find it beneficial to use shorter lifetimes (so that it
   communicates with the PCP server more often).  If the PCP client has
   several mappings, the Epoch value only needs to be retrieved for one
   of them to verify the PCP server has not lost port forwarding state.

   If the client wishes to check the PCP server's Epoch, it sends a PCP



Wing, et al.             Expires August 11, 2011               [Page 35]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   request for any one of the client's mappings.  This will return the
   current Epoch 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).


9.  PEER OpCodes

   This section defines two OpCodes for controlling dynamic connections.
   They are:

     PEER4=2:  Set or query lifetime for flow from IPv4 address to a
               remote peer's IPv4 address.

     PEER6=3:  Set or query lifetime for flow from IPv6 address to a
               remote peer's IPv6 address.

   The operation of these OpCodes is described in this section.

9.1.  OpCode Packet Formats

   The two PEER OpCodes (PEER4 and PEER6) share a similar packet layout
   for both requests and responses.  Because of this similarity, they
   are shown together.  For both of the PEER OpCodes, if the internal IP
   address and internal port fields of the request both match the
   external IP address and external port fields of the response, the IP
   addresses and ports are not changed and thus the functionality is
   purely a firewall; otherwise it pertains to a network address
   translator which might also perform firewall functions.

   The following diagram shows the request packet format for PEER4 and
   PEER6.  This packet format is aligned with the response packet
   format:

















Wing, et al.             Expires August 11, 2011               [Page 36]

Internet-Draft         Port Control Protocol (PCP)         February 2011


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |        Reserved (24 bits)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :  Internal IP address (32 bits if PEER4, 128 bits if PEER6)    :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :  Remote Peer IP address (32 bits if PEER4, 128 bits if PEER6) :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :                 Reserved (128 bits)                           :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Requested lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        internal port          |     reserved (16 bits)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       remote peer port        |     reserved (16 bits)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 11: PEER OpCode Request Packet Format

   These fields are described below:

   Protocol:  indicates protocol associated with this OpCode.  Values
      are taken from the IANA protocol registry [proto_numbers].  For
      example, this field contains 6 (TCP) if the OpCode is describing a
      TCP peer.

   Reserved:  24 reserved bits, MUST be 0 on transmission and MUST be
      ignored on reception.

   Mapping Internal IP Address:  Internal IP address of the 5-tuple.
      This can be 32 bits long (if OpCode is PEER4) or 128 bits long (if
      OpCode is PEER6).

   Remote Peer IP Address:  Remote peer's IP address, from the
      perspective of the PCP client.

   Reserved:  128 reserved bits, MUST be 0 on transmission and MUST be
      ignored on reception.






Wing, et al.             Expires August 11, 2011               [Page 37]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Requested lifetime:  Requested lifetime of this mapping, in seconds.
      Unlike the MAP OpCode, there is no special meaning of 0.

   internal port:  Internal port for the of the 5-tuple.

   Reserved:  16 reserved bits, MUST be 0 on transmission and MUST be
      ignored on reception.

   Remote Peer Port:  Remote peer's port of the 5-tuple.

   Reserved:  16 reserved bits, MUST be 0 on transmission and MUST be
      ignored on reception.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |  External_AF  |       Reserved (16 bits)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :  Internal IP address (32 bits if PEER4, 128 bits if PEER6)    :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :  Remote Peer IP address (32 bits if PEER4, 128 bits if PEER6) :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :   External IP address (always 128 bits)                       :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        internal port          |     external port             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       remote peer port        |     reserved (16 bits)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 12: PEER OpCode Request Packet Format

   Protocol:  Copied from the request.

   External_AF  The address family of the external IP address associated
      with this peer connection.  Values are from IANA's address family
      numbers (IPv4 is 1, IPv6 is 2).

   Reserved:  16 reserved bits, MUST be 0 on transmission, MUST be
      ignored on reception.





Wing, et al.             Expires August 11, 2011               [Page 38]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Internal IP address  Copied from the request.

   remote Peer IP address  Copied from the request.

   External IP Address  External IP address, assigned by the NAT (or
      firewall) to this mapping.  If firewall, this will match the
      internal IP address.  This field is always 128 bits long.  If
      External_AF indicates IPv4, the IPv4 address is encoded in the
      first 32 bits of the External IP Address field and the remaining
      96 bits are zero.

   internal port:  copied from request.

   external port:  External port number, assigned by the NAT (or
      firewall) to this mapping.  If firewall or 1:1 NAT, this will
      match the internal port.

   remote peer port:  Copied from request.

   Reserved:  16 reserved bits, MUST be 0 on transmission, MUST be
      ignored on reception.

9.2.  OpCode-Specific Result Codes

   In addition to the general PCP result codes (Section 5.4) the
   following additional result codes may be returned as a result of the
   two PEER OpCodes received by the PCP server.

   50 NONEXIST_PEER, the connection to that peer does not exist in the
      mapping table

   Other result codes are defined following the procedure in
   Section 13.3.

9.3.  OpCode-Specific Client Operation, Processing a Response

   This section describes the operation of a client when sending the
   OpCodes PEER4 or PEER6.

   After connecting to a server using UDP or TCP, the PCP client sends a
   PCP request containing the PEER4 or PEER6 OpCode.

   A response is matched with a request by comparing the protocol,
   external AF, internal IP address, internal port, remote peer address
   and remote peer port.  Other fields are not compared, because the PCP
   server changes those fields to provide information about the mapping
   created by the OpCode.




Wing, et al.             Expires August 11, 2011               [Page 39]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   If a successful response, the PCP client uses the assigned lifetime
   value to reduce its frequency of application keepalives for the NAT.
   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
   ensure the server is still accessible (e.g., has not crashed) more
   frequently than once an hour.

9.4.  OpCode-Specific Server Operation

   This section describes the operation of a client when processing the
   OpCodes PEER4 or PEER6.

   The PEER OpCodes provide a single function: the ability for the PCP
   client to query and (possibly) extend the lifetime of an existing
   mapping.

   On receiving the PEER4 or PEER6 OpCode, the PCP server examines the
   mapping table.  If a mapping does not exist, the NONEXIST_PEER error
   is returned.  Otherwise, the PCP server chooses the smaller of the
   requested lifetime and its configured maximum lifetime value, and
   sets the lifetime of the existing mapping.  This means that a PEER4
   or PEER6 request does not reduce the lifetime of an existing mapping,
   nor can the PEER OpCodes delete a mapping.  If the mapping is
   terminated by the TCP client or server (e.g., TCP FIN or TCP RST),
   the mapping will eventually be destroyed normally; the earlier use of
   PEER does not extend the lifetime in that case.

   If all of the proceeding operations were successful (did not generate
   an error response), then a SUCCESS response is generated, with the
   assigned-lifetime containing the lifetime of the mapping.


10.  Deployment Scenarios

10.1.  Dual Stack-Lite

   The interesting components in a Dual-Stack Lite deployment are the B4
   element (which is the customer premises router) and the AFTR element
   (which is the device that both terminates the IPv6-over-IPv4 tunnel
   and also implements the 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.







Wing, et al.             Expires August 11, 2011               [Page 40]

Internet-Draft         Port Control Protocol (PCP)         February 2011


10.1.1.  Overview

   Various PCP deployment scenarios can be considered to control the PCP
   server embedded in the AFTR element:

   1.  UPnP IGD and NAT-PMP [I-D.cheshire-nat-pmp] are used in the LAN:
       an interworking function is required to be embedded in the B4
       element to ensure interworking between the protocol used in the
       LAN and PCP.  UPnP IGD-PCP Interworking Function is described in
       Section 11.

   2.  Hosts behind the B4 element will either include a PCP client or
       UPnP IGD client, or both.

       A.  if a UPnP IGD client, the B4 element will need to include an
           interworking function from UPnP IGD to PCP.

       B.  if a PCP client, the PCP client will communicate directly
           with the PCP server.

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

   Two modes are identified to forward PCP packets to a PCP server
   controlling the provisioned AFTR as described in the following sub-
   sections.

      [Ed. Note: We need to decide on Encapsulation Mode or Plain IPv6
      Mode.  This is tracked as PCP Issue #13 [PCP-Issues].]

10.1.2.  Encapsulation Mode

   In this mode, B4 element does no processing at all of the PCP
   messages, and forwards them as any other UDP traffic.  With DS-Lite,
   this means that IPv4 PCP messages issued by internal PCP clients are
   encapsulated into the IPv6 tunnel sent to the AFTR as for any other
   IPv4 packets.  The IPv6 address used as source address MUST be the
   same as the one used by the B4 element.  The AFTR decapsulates the
   IPv4 packets and processes the PCP requests (because the destination
   IPv4 address points to the PCP server embedded in the AFTR).

10.1.3.  Plain IPv6 Mode

   Another alternative for deployment of PCP in a DS-Lite context is to
   rely on a PCP Proxy in the B4 element.  Protocol exchanges between
   the PCP Proxy and the PCP server are conveyed using plain IPv6 (no



Wing, et al.             Expires August 11, 2011               [Page 41]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   tunnelling is used).  Nevertheless, the IPv6 address used as source
   address by the PCP Proxy MUST be the same as the one used by the B4
   element.

10.2.  NAT64

   Hosts behind a NAT64 device can make use of PCP in order to perform
   port reservation (to get a publicly routable IPv4 port).

   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 [RFC6052].

10.3.  NAT44 and NAT444

   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 NAPT device.  When this occurs in conjunction
   with an upstream NAT44, this is nicknamed "NAT444".

      [Ed. 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 [PCP-Issues].]

10.4.  IPv6 Firewall

   See Section 8.5.2.

      [Ed. Note: this IPv6 firewall section needs more text.  This is
      tracked as PCP Issue #10 [PCP-Issues].]

10.5.  Subscriber Identification

   The MAP OpCodes require subscriber identification because they
   allocate resources or adjust resources allocated to a subscriber.
   For the MAP OpCode, it is permitted for a PCP client to create a
   mapping on behalf of a third party device (e.g., a computer can
   create PCP mappings on behalf of a webcam).  However, a PCP client
   cannot open mappings for a different subscriber.  The mechanism to
   identify "same subscriber" depends on the sort of NAT on this
   network:




Wing, et al.             Expires August 11, 2011               [Page 42]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   o  If the PCP-controlled device is a NAT64: the internal IP address
      indicated in the PCP message and the source IPv6 address of
      received PCP request MUST belong to the same IPv6 prefix.  The
      length of the IPv6 prefix is the same as the length assigned to
      each subscriber on that particular network (e.g., /64), and that
      length must be configurable by the network operator.

   o  If the PCP-controlled device is a DS-Lite AFTR: DS-Lite (Section
      11 of [I-D.ietf-softwire-dual-stack-lite]) already requires the
      tunnel transport source address be validated, and that same
      address is used by PCP to assign the tunnel-ID to the requested
      mapping (see Section 10.1.2 and Section 10.1.3).  Thus, PCP
      acquires the same security properties as DS-Lite.  If address
      validation is implemented correctly, the PCP client can not
      instruct mappings on behalf of devices of another subscriber.

   o  If LSN with a routed network (NAT44), each subscriber has a known
      set of IPv4 address (usually one IPv4 address) and all PCP
      requests MUST be sent from only one of the subscriber's IP
      addresses and MUST only open mappings towards the subscriber's own
      IP address.

   o  If IPv6 firewall: the internal IP address indicated in the PCP
      message and the source IPv6 address of received PCP request MUST
      belong to the same IPv6 prefix.  The length of the IPv6 prefix is
      the same as the length assigned to each subscriber on that
      particular network (e.g., /64), and that length must be
      configurable by the network operator.

   PCP-controlled devices can be a DS-Lite AFTR or an IPv4-IPv6
   interconnection node such as NAT46 or NAT64.  These nodes are
   deployed by Service Providers to deliver global connectivity service
   to their customers.  Appropriate functions to restrict the use of
   these resources (e.g., LSN facility) to only subscribed users should
   be supported by these devices.  Access control can be implicit or
   explicit:

   o  It is said to be explicit if an authorisation procedure is
      required for a user to be granted access to such resources.  For
      such variant of PCP-controlled device, a subscriber can be
      identified by an IPv6 address, an IPv4 address, a MAC address, or
      any other information.

   o  For other scenarios, such as plain IPv4-in-IPv6 encapsulation for
      a DS-Lite architecture, the access to the service is based on the
      source IPv6 prefix.  No per-user polices is pre-configured in the
      PCP-controlled device.




Wing, et al.             Expires August 11, 2011               [Page 43]

Internet-Draft         Port Control Protocol (PCP)         February 2011


11.  Interworking with UPnP IGD 1.0 and 2.0

      [Ed. 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 [PCP-Issues].]

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


      +-------------+
      | IGD Control |
      |   Point     |-----+
      +-------------+     |   +---------+       +--------+
                          +---| IGD-PCP |       |  PCP   |
                              |   IWF   +-------+ Server |--<Internet>
                          +---|         |       |        |
      +-------------+     |   +---------+       +--------+
      | Local Host  |-----+
      +-------------+              |                  |
                                   |                  |
                     LAN Side      |     WAN side     |
      <======UPnP IGD=============>|<========PCP=====>|

         Figure 13: Network Diagram, Interworking UPnP IGD and PCP

11.1.  UPnP IGD 1.0 with AddPortMapping Action

   In UPnP IGD 1.0 [IGD] 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 NAPT, they cannot
   both get the same port.  PCP cannot correct this behavior of UPnP
   IGD:1, but PCP does work with this behavior.

   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 Section 11.2) or, more
   likely, will support PCP natively.

   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



Wing, et al.             Expires August 11, 2011               [Page 44]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   PREFER_FAILURE option, which causes the PCP server to return an error
   if it cannot allocate the requested 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 requested port.

   Message flow would be similar to this:












































Wing, et al.             Expires August 11, 2011               [Page 45]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   UPnP Control Point             in-home CPE                 PCP server
         |                            |                           |
         |-UPnP:AddPortMapping(80)--->|                           |
         |                            |-PCP:request port 80------>|
         |                            | PREFER_FAILURE            |
         |                            |                           |
         |                            |<-PCP:error----------------|
         |<-UPnP: unavailable---------|                           |
         |                            |                           |
         |-UPnP:AddPortMapping(81)--->|                           |
         |                            |-PCP:request port 81------>|
         |                            | PREFER_FAILURE            |
         |                            |                           |
         |                            |<-PCP:error----------------|
         |<-UPnP: unavailable---------|                           |
         |                            |                           |
         |                            |                           |
         |-UPnP:AddPortMapping(82)--->|                           |
         |                            |-PCP:request port 82------>|
         |                            | PREFER_FAILURE            |
         |                            |                           |
         |                            |<-PCP:error----------------|
         |<-UPnP: unavailable---------|                           |
         |                            |                           |
         |                            |                           |
         |-UPnP:AddPortMapping(83)--->|                           |
         |                            |-PCP:request port 83------>|
         |                            | PREFER_FAILURE            |
         |                            |                           |
         |                            |<-PCP:error----------------|
         |<-UPnP: unavailable---------|                           |
         |                            |                           |
        ...         ...              ...                 84      ...
        ...         ...              ...                 85      ...
        ...         ...              ...                 ..      ...
        ...         ...              ...                 96      ...
        ...         ...              ...                 97      ...
         |                            |                           |
         |-UPnP:AddPortMapping(98)--->|                           |
         |                            |-PCP:request port 98------>|
         |                            | PREFER_FAILURE            |
         |                            |                           |
         |                            |<-PCP:ok, port 98----------|
         |<-UPnP: ok, port 98---------|                           |
         |                            |                           |

          Figure 14: Message Flow: Interworking from UPnP IGD 1.0
                       AddPortMapping action to PCP



Wing, et al.             Expires August 11, 2011               [Page 46]

Internet-Draft         Port Control Protocol (PCP)         February 2011


11.2.  UPnP IGD 2.0 with AddAnyPortMapping Action

   If the UPnP IGD control point and the UPnP IGD interworking function
   both implement UPnP IGD 2.0 [IGD-2] 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.

   Message flow would be similar to this:

    UPnP Control Point           in-home CPE                 PCP server
          |                           |                          |
          |-UPnP:AddAnyPortMapping()->|                          |
          |                           |-PCP:external port 0----->|
          |                           |<-PCP:external port=12345-|
          |<-UPnP:port=12345----------|                          |
          |                           |                          |

          Figure 15: Message Flow: Interworking from UPnP IGD 2.0
                      AddAnyPortMapping action to PCP

11.3.  Lifetime Maintenance

   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.

      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.


12.  Security Considerations

   The PCP client's source port SHOULD be randomly generated as per
   [I-D.ietf-tsvwg-port-randomization].

   On today's Internet, ISPs do not typically filter incoming traffic
   for their subscribers.  However, when ISP introduce stateful address
   sharing with NAPT devices, such filtering will occur as a side
   effect.  PCP allows controlling that filtering, and PCP allows
   indicating the 'inside' IP address that should have the filtering
   removed.  It is important that PCP allows removing the filtering for
   hosts belonging to one subscriber, but not hosts belonging to another



Wing, et al.             Expires August 11, 2011               [Page 47]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   subscriber.  This is done in different ways depending on the
   architecture of the address sharing device and how subscribers are
   identified behind that device, and described in detail in
   Section 10.5.

   Because of the state created in a NAPT or firewall, it is anticipated
   that port forwarding (MAP OpCodes) will have a quota applied to each
   subscriber.  If the quota is small and the maximum lifetime is large,
   a faulty or disconnected PCP client could cause a denial of service
   for other PCP clients belonging to that same subscriber.  To prevent
   this problem, if a PCP server is configured for a small per-
   subscriber quota (e.g., less than 15 ports) then it is RECOMMENDED it
   also be be configured for a short maximum lifetime (e.g., 5 minutes).


13.  IANA Considerations

   IANA is requested to perform the following actions:

13.1.  Port Number

   IANA has assigned UDP port 44323 for PCP.

13.2.  OpCodes

   IANA shall create a new protocol registry for PCP OpCodes, initially
   populated with the values in Section 8 and Section 9.

   New OpCodes in the range 1-95 can be created via Standards Action
   [RFC5226], and the range 96-128 is for Private Use [RFC5226].

13.3.  Result Codes

   IANA shall create a new registry for PCP result codes, numbered
   0-255, initially populated with the result codes from Section 5.4,
   Section 8.2, and Section 9.2.

   New Result Codes can be created via Specification Required [RFC5226].

13.4.  Options

   IANA shall create a new registry for PCP Options, numbered 0-255 with
   an associated mnemonic.  The values 0-127 are optional-to-process,
   and 128-255 are mandatory-to-process.  The initial registry contains
   the options described in Section 8.5, and the option values 0 and 255
   are reserved.

   New PCP option codes in the range 0-63 and 128-192 can be created via



Wing, et al.             Expires August 11, 2011               [Page 48]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   Standards Action [RFC5226], and the range 64-127 and 192-255 is for
   Private Use [RFC5226].


14.  Acknowledgments

   Thanks to Alain Durand, Christian Jacquenet, and Simon Perreault for
   their comments and review.  Thanks to Simon Perreault for
   highlighting the interaction of dynamic connections with PCP-created
   mappings.


15.  References

15.1.  Normative References

   [I-D.ietf-behave-v6v4-xlate]
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
              progress), September 2010.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress), July 2010.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
              in progress), August 2010.

   [I-D.ietf-tsvwg-port-randomization]
              Larsen, M. and F. Gont, "Transport Protocol Port
              Randomization Recommendations",
              draft-ietf-tsvwg-port-randomization-09 (work in progress),
              August 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,



Wing, et al.             Expires August 11, 2011               [Page 49]

Internet-Draft         Port Control Protocol (PCP)         February 2011


              May 2008.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [proto_numbers]
              IANA, "Protocol Numbers", 2010, <http://www.iana.org/
              assignments/protocol-numbers/protocol-numbers.xml>.

15.2.  Informative References

   [I-D.arkko-dual-stack-extra-lite]
              Arkko, J., Eggert, L., and M. Townsley, "Scalable
              Operation of Address Translators with Per-Interface
              Bindings", draft-arkko-dual-stack-extra-lite-05 (work in
              progress), February 2011.

   [I-D.cheshire-nat-pmp]
              Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
              draft-cheshire-nat-pmp-03 (work in progress), April 2008.

   [I-D.ietf-behave-lsn-requirements]
              Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida,
              "Common requirements for IP address sharing schemes",
              draft-ietf-behave-lsn-requirements-00 (work in progress),
              October 2010.

   [I-D.miles-behave-l2nat]
              Miles, D. and M. Townsley, "Layer2-Aware NAT",
              draft-miles-behave-l2nat-00 (work in progress),
              March 2009.

   [IGD]      UPnP Gateway Committee, "WANIPConnection:1",
              November 2001, <http://upnp.org/specs/gw/
              UPnP-gw-WANIPConnection-v1-Service.pdf>.

   [IGD-2]    UPnP Gateway Committee, "Internet Gateway Device (IGD) V
              2.0", September 2010, <http://upnp.org/specs/gw/
              UPnP-gw-WANIPConnection-v2-Service.pdf>.

   [PCP-Issues]
              PCP Working Group, "PCP Active Tickets", January 2011,
              <http://trac.tools.ietf.org/wg/pcp/trac/report/1>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.




Wing, et al.             Expires August 11, 2011               [Page 50]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC3581]  Rosenberg, J. and H. Schulzrinne, "An Extension to the
              Session Initiation Protocol (SIP) for Symmetric Response
              Routing", RFC 3581, August 2003.

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, July 2007.

   [RFC5461]  Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
              February 2009.

   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment (CPE) for Providing
              Residential IPv6 Internet Service", RFC 6092,
              January 2011.


Appendix A.  Changes

A.1.  Changes from draft-ietf-pcp-base-03 to -04

   o  "Pinhole" and "PIN" changed to "mapping" and "MAP".

   o  Reduced from four MAP OpCodes to two.  This was done by implicitly
      using the address family of the PCP message itself.

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

   o  Integrated a lot of editorial changes from Stuart and Francis.





Wing, et al.             Expires August 11, 2011               [Page 51]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   o  Removed nested NAT text into another document, including the IANA-
      registered IP addresses for the PCP server.

   o  Removed suggestion (MAY) that PCP server reserve UDP when it maps
      TCP.  Nobody seems to need that.

   o  Clearly added NAT and NAPT, such as in residential NATs, as within
      scope for PCP.

   o  HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE

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

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

   o  Reduced scope to only deal with mapping protocols that have port
      numbers.

   o  Reduced scope to not support DMZ-style forwarding.

   o  Clarified version negotiation.

A.2.  Changes from draft-ietf-pcp-base-02 to -03

   o  Adjusted abstract and introduction to make it clear PCP is
      intended to forward ports and intended to reduce application
      keepalives.

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

   o  Moved subscriber identity from common PCP section to MAP* section.

   o  made clearer that PCP client can reduce mapping lifetime if it
      wishes.

   o  Added discussion of host running a server, client, or symmetric
      client+server.

   o  Introduced PEER4 and PEER6 OpCodes.

   o  Removed REMOTE_PEER Option, as its function has been replaced by
      the new PEER OpCodes.



Wing, et al.             Expires August 11, 2011               [Page 52]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   o  IANA assigned port 44323 to PCP.

   o  Removed AMBIGUOUS error code, which is no longer needed.

A.3.  Changes from draft-ietf-pcp-base-01 to -02

   o  more error codes

   o  PCP client source port number should be random

   o  PCP message minimum 8 octets, maximum 1024 octets.

   o  tweaked a lot of text in section 7.4, "Opcode-Specific Server
      Operation".

   o  opening a mapping also allows ICMP messages associated with that
      mapping.

   o  PREFER_FAILURE value changed to the mandatory-to-process range.

   o  added text recommending applications that are crashing obtain
      short lifetimes, to avoid consuming subscriber's port quota.

A.4.  Changes from draft-ietf-pcp-base-00 to -01

   o  Significant document reorganization, primarily to split base PCP
      operation from OpCode operation.

   o  packet format changed to move 'protocol' outside of PCP common
      header and into the MAP* opcodes

   o  Renamed Informational Elements (IE) to Options.

   o  Added REMOTE_PEER (for disambiguation with dynamic ports),
      REMOTE_PEER_FILTER (for simple packet filtering), and
      PREFER_FAILURE (to optimize UPnP IGD interworking) options.

   o  Is NAT or router behind B4 in scope?

   o  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
      wasn't in the request.

   o  Response code most significant bit now indicates permanent/
      temporary error

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



Wing, et al.             Expires August 11, 2011               [Page 53]

Internet-Draft         Port Control Protocol (PCP)         February 2011


   o  Epoch discussion simplified.


Authors' Addresses

   Dan Wing (editor)
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com


   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






Wing, et al.             Expires August 11, 2011               [Page 54]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/