[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-wing-pcp-base

SOFTWIRE Working Group                                           D. Wing
Internet-Draft                                                     Cisco
Intended status:  Standards Track                               R. Penno
Expires:  September 2, 2010                             Juniper Networks
                                                           March 1, 2010

                      Port Control Protocol (PCP)


   It is desirable to operate a server behind a device that does not
   normally permit operating a server, such as a carrier's NAT64, a
   carrier's NAT44, or an IPv6 customer premise router that filters
   incoming packets.  This document proposes an application-level
   protocol, derived from NAT-PMP, to allow a host to request opening a
   port in such an upstream device.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 2, 2010.

Wing & Penno            Expires September 2, 2010               [Page 1]

Internet-Draft         Port Control Protocol (PCP)            March 2010

Copyright Notice

   Copyright (c) 2010 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 BSD License.

Wing & Penno            Expires September 2, 2010               [Page 2]

Internet-Draft         Port Control Protocol (PCP)            March 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Scope and Requirements . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Port Forwarding  . . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Basic Port Forwarding  . . . . . . . . . . . . . . . .  5
       3.1.2.  Dynamic Port Forwarding  . . . . . . . . . . . . . . .  5
       3.1.3.  Port Forwarding and Redirection  . . . . . . . . . . .  6
   4.  Other Commonly-Deployed Port Reservation Mechanisms  . . . . .  6
     4.1.  Comparison . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Interoperation with commonly-deployed port-reservation
           protocols  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Discovery of PCP Server  . . . . . . . . . . . . . . . . . . .  7
   6.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Protocol and Packet Format . . . . . . . . . . . . . . . .  8
       6.1.1.  Requests and Responses . . . . . . . . . . . . . . . .  9
       6.1.2.  Determining the External Address . . . . . . . . . . .  9
       6.1.3.  Returning a Mapping  . . . . . . . . . . . . . . . . . 10
       6.1.4.  Destroying a Mapping . . . . . . . . . . . . . . . . . 13
       6.1.5.  Result Codes . . . . . . . . . . . . . . . . . . . . . 15
       6.1.6.  Seconds Since Start of Epoch . . . . . . . . . . . . . 16
     6.2.  Interactions with Outgoing Sessions  . . . . . . . . . . . 16
   7.  PCP and Dual Stack-Lite  . . . . . . . . . . . . . . . . . . . 16
   8.  PCP and NAT64  . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  PCP and IPv6 Simple Security . . . . . . . . . . . . . . . . . 17
   10. PCP IANA-Assigned Address  . . . . . . . . . . . . . . . . . . 17
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     14.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  PCP implemented on host . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Wing & Penno            Expires September 2, 2010               [Page 3]

Internet-Draft         Port Control Protocol (PCP)            March 2010

1.  Introduction

   Port Control Protocol (PCP) provides a simple mechanism to request a
   TCP or UDP port from an upstream NAT (NAT64 or NAT44) or firewall
   (IPv6 or IPv4).  PCP can be implemented within customer premise (CP)
   routers, or by an application running on a host.

   Such a protocol is necessary during the deployment of large-scale
   NATs (both NAT64 and NAT44) and with IPv6 CPE which filter incoming
   connections [I-D.ietf-v6ops-cpe-simple-security].

   Both NAT-PMP [I-D.cheshire-nat-pmp] and SP-NAT-PMP
   [I-D.woodyatt-spnatpmp-appl] were used as the basis for the protocol
   described in this document.

2.  Scope and Requirements

   PCP is not meant to be a general purpose NAT or Firewall port
   reservation protocol.  PCP has a very focused goal of allowing port
   reservation in the context of Dual-Stack Lite
   [I-D.ietf-softwire-dual-stack-lite], NAT64
   [I-D.ietf-behave-v6v4-framework], and IPv6 Simple CPE Security
   [I-D.ietf-v6ops-cpe-simple-security].  Other scenarios are out of

   The requirements of the Port Control Protocol described in this
   document are:

   1.  trivial to implement in a large-scale NAT.  This includes minimal
       state and timers on the NAT.

   2.  support IPv4 and IPv6.

   3.  cannot rely on a shared broadcast domain between the PCP client
       and its PCP server, as these are point-to-point links (in the
       case of Dual-Stack Lite) or a network of routers (in the case of

   4.  for NATted environments (NAT44 and NAT64), allows the NAT to
       choose the public UDP port or public TCP port.  This is necessary
       in large-scale NAT environments where a client might otherwise
       request ports that are already being used.

   5.  does not require modifying code in the application needing the
       incoming port; rather, another application can open the port.
       This permits a PC to use PCP to open ports for an IP-enabled
       webcam, and permits a CP router to open ports on behalf of

Wing & Penno            Expires September 2, 2010               [Page 4]

Internet-Draft         Port Control Protocol (PCP)            March 2010

       devices behind the CP.

   6.  for NATted environments (NAT44 and NAT64), the NAT must not
       forward traffic to other internal hosts (subscribers) until the
       mapping lifetime expires or the host expliticly releases it.
       This differs from UPnP IGD and NAT-PMP, which allow the NAT to
       destroy its binding if the NAT is reset (e.g., rebooted), and
       forward incoming traffic to those ports to other internal hosts.

   The following are also considered out of scope:

   1.  Multihoming is not supported.

3.  Terminology

3.1.  Port Forwarding

   Port forwading is normally used when several hosts behind a NAT
   device share a single external IP address to communicate.  If an
   internal host is listening to connections on a specific port (that
   is, operating as a server), the external IP and port need to be port
   forwarded (also called "mapped") to the internal IP address and port.
   The key point is that the internal and external transport destination
   ports could be different; for example, a webcam might be listening on and TCP/80, but the public address is and TCP/
   12345; the NAT does 'port forwarding' of one to the other.

   There are some variations of port forwarding in respect to the fields
   in the IP and Transport headers that get modified as packets traverse
   a device and the nature of the mapping.  These are discussed below.

3.1.1.  Basic Port Forwarding

   In the most basic definition port forwarding means the static, pre-
   determined mapping of a transport destination port, protocol and IP
   address 3-tuple into another by a device.  Following the nomenclature
   first introduced by RFC2633, this would be called basic-port-

   Today, users typically configure basic port forwarding on their CP
   router using the CP router's HTTP configuration.

3.1.2.  Dynamic Port Forwarding

   The mapping on the device could be installed dynamic based on
   application requests through protocols such as UPnP IGD [UPnP-IGD] or
   NAT-PMP.  In this case these protocols in conjunction with the CPE

Wing & Penno            Expires September 2, 2010               [Page 5]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   NAT device automatically take care of mapping management.

3.1.3.  Port Forwarding and Redirection

   Certain protocols such as HTTP can redirect a client to use a
   different port without translation.  This is widely used, specially
   in Content Delivery Networks, but not for the same purposes as port
   forwarding.  On the other hand, port forwarding and HTTP redirection
   meet as a possible solution to manage inbound connections through
   Large Scale NATs (e.g., [I-D.wing-behave-http-46-relay]).

4.  Other Commonly-Deployed Port Reservation Mechanisms

4.1.  Comparison

   This section compares commonly-deployed port reservation mechanisms.

   UPnP IGD:  IPv4 only.  Relatively complicated to implement in the
      UPnP IGD server, due to reliable HTTPU (HTTP over reliable UDP),
      XML, and UPnP's multicast discovery.  IPv6 support is not yet
      available.  UPnP IGD 1.0 has the host decide and dictate the
      public port, which is not viable in a large scale NAT environment,
      as the port may already be allocated to another host.

   NAT-PMP:  IPv4 only.  NAT-PMP does not include discovery; it assumes
      the next-hop default router supports NAT-PMP.

   STUN:  Requires a STUN server, and requires discoverying/learning the
      IP address of the STUN server.  Requires using same source UDP/TCP
      port as being opened, which requires modifying the application
      itself (that is, the port opening can't be a separate application
      on the same system).

4.2.  Interoperation with commonly-deployed port-reservation protocols

   It is envisoned that customer premise equipment (CPE) routers will
   continue to offer popular LAN-based mechanisms to provide port
   mapping to computers, such as UPnP IGD, NAT-PMP, and HTTP-based
   configuration.  PCP is expected to operate between the CPE router and
   the service provider's NAT44 or NAT64.  This means the CPE router
   acts as client for HTML-based configuration and as a proxy between
   UPnP IGD and PCP, or between NAT-PMP and PCP, or both, as shown in
   the following diagrams.  Links with PCP are shown with "=", links
   that aren't using PCP are shown with "-".

Wing & Penno            Expires September 2, 2010               [Page 6]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   Scenario 1

                             +-------------+    +----------+
                             | PCP-proxying|    |Dual-Stack|
                             |   customer  +====+ Lite AFTR+--<Internet>
    IPv4 host using HTML-----+   premise   |    +----------+
                             |    router   |

              Figure 1: Scenario 1, CPE router as PCP client

   Scenario 2

                             +-------------+    +----------+
   IPv4 host using NAT-PMP---+ PCP-proxying|    |Dual-Stack|
                             |   customer  +====+ Lite AFTR+--<Internet>
   IPv4 host using UPnP IGD--+   premise   |    +----------+
                             |    router   |

   Figure 2: Scenario 2, CPE router as PCP client, proxying UPnP IGD or
                             NAT-PMP with PCP

   Note regarding UPnP IGD:  for UPnP IGD to provide the necessary
   functionality, the AddAnyPortmapping from UPnP IGD:2 [IGD-2] is
   needed in (a) IPv4 host's UPnP IGD stack, (b) the IPv4 host's
   application calling the UPnP IGD stack, and (c) the PCP-proxying CP
   router.  Without this, the host running UPnP IGD (which UPnP calls
   the 'control point') dictates the public port number; on a large NAT,
   that port number will likely already be used by another client.

5.  Discovery of PCP Server

   NOTE:  Analysis of these discovery mechanisms requires further

   The authors have considered two mechanisms for discovery of the PCP

   1.  a special-purpose IPv4 address, assigned by IANA, which is routed
       normally until it hits a PCP device, which responds.  This works
       well with NAT64, as there are normally routers between the PCP
       client (the CP router) and the NAT64 (operated by the service
       provider).  When a host wants to allow an incoming port, it sends
       a UDP packet to the IANA-assigned PCP discovery address and the
       PCP port.  The upstream NAT44, NAT64, or IPv6-CPE will be
       listening for that address and port, and respond accordingly.

Wing & Penno            Expires September 2, 2010               [Page 7]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   2.  assume the default router is a PCP server, and send PCP packets
       to the IP address of the default router.  This is how NAT-PMP
       operates today.  An advantage is this is simple and does not rely
       on routing of the special-use address.

   Although multi-homing is out of scope of PCP, it is worth pointing
   out that both techniques work poorly with multi-homing.

6.  Protocol

   PCP borrows heavily from NAT-PMP due to simplicity, available
   implementations and compatiblity.  This also provides better support
   in the scenario where the CPE implements a first layer of NAT and
   supports NAT-PMP, with a mostly one to one message compatibility.
   The text from NAT-PMP is copied here for continuity purposes.

   The protocol specified below is written from a PCP client perspective
   ("Scenario 1" (Figure 1)), and could be implemented in a CPE
   triggered by HTML-based configuration.  The applicability of PCP in a
   dual-stack lite or NAT64 network is discussed in further sections.  A
   detailed description of proxying UPnP IGD or NAT-PMP to PCP
   ("Scenario 2" (Figure 2)) will be discussed in companion documents.

6.1.  Protocol and Packet Format

   PCP runs over UDP.  Every packet starts with an 8 bit version
   followed by an 8 bit operation code.  This document specifies version
   0 of the protocol.  Any PCP gateway implementing this version of the
   protocol, receiving a packet with a version number other than 0, MUST
   return result code 1 (Unsupported Version), indicating the highest
   version number it does support (i.e. 0) in the version field of the

   Opcodes between 0 and 127 are client requests.  Opcodes from 128 to
   255 are server responses.  Responses always contain a 16 bit result
   code in network byte order.  A result code of zero indicates success.
   Responses also contain a 32 bit unsigned integer corresponding to the
   number of seconds since the NAT gateway was rebooted or since its
   port mapping state was reset.

   Clients always send their Port Mapping Protocol requests to the IANA-
   assigned address or their default gateway, depending on the consensus
   for PCP discovery (Section 5).

Wing & Penno            Expires September 2, 2010               [Page 8]

Internet-Draft         Port Control Protocol (PCP)            March 2010

6.1.1.  Requests and Responses

   To determine the external IP address or request a port mapping, a PCP
   client sends its request packet to port TBD of its gateway address,
   and waits 250ms for a response.  If no PCP response is received from
   the gateway after 250ms, the client retransmits its request and waits
   500ms.  The client SHOULD repeat this process with the interval
   between attempts doubling each time.  If, after sending its 9th
   attempt (and then waiting for 64 seconds), the client has still
   received no response, then it SHOULD conclude that this gateway does
   not support PCP and MAY log an error message indicating this fact.
   In addition, if the PCP client receives an "ICMP Port Unreachable"
   message from the gateway for port TBD then it can skip any remaining
   retransmissions and conclude immediately that the gateway does not
   support PCP.

   As a performance optimization the client MAY record this information
   and use it to suppress further attempts to use PCP, but the client
   should not retain this information for too long.  In particular, any
   event that may indicate a potential change of gateway or a change in
   gateway configuration (hardware link change indication, change of
   gateway MAC address, acquisition of new DHCP lease, receipt of PCP
   announcement packet from gateway, etc.) should cause the client to
   discard its previous information regarding the gateway's lack of PCP
   support, and send its next PCP request packet normally.

   When deleting a port mapping, the client uses the same initial 250ms
   timeout, doubling on each successive interval, except that clients
   may choose not to try the full nine times before giving up.  This is
   because mapping deletion requests are in some sense advisory.  They
   are useful for efficiency, but not required for correctness; it is
   always possible for client software to crash, or for power to fail,
   or for a client device to be physically unplugged from the network
   before it gets a chance to send its mapping deletion request(s), so
   NAT gateways already need to cope with this case.  Because of this,
   it may be acceptable for a client to retry only once or twice before
   giving up on deleting its port mapping(s), but a client SHOULD always
   send at least one deletion request whenever possible, to reduce the
   amount of stale state that accumulates on NAT gateways.  A client
   need not continue trying to delete a port mapping after the time when
   that mapping would naturally have expired anyway.

6.1.2.  Determining the External Address

   To determine the external address, the client behind the NAT sends
   the following UDP payload to port TBD of the gateway address:

Wing & Penno            Expires September 2, 2010               [Page 9]

Internet-Draft         Port Control Protocol (PCP)            March 2010

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     | Vers = 0      | OP = 0        |

   A compatible NAT gateway MUST generate a response with the following
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     | Version = 0   | OP = 128 + 0  | Result Code                   |
     | Seconds Since Start of Epoch                                  |
     | External IP Address (IPv4, 32 bits; IPv6 isn't NATted use "0")|

   This response indicates that the NAT gateway implements this version
   of the protocol and returns the external IP address of the NAT
   gateway.  If the result code is non-zero, the value of External IP
   Address is undefined (MUST be set to zero on transmission, and MUST
   be ignored on reception).

   When PCP is used to punch holes in a simple firewall, there is no NAT
   being performed.  Rather than indicating an IPv6 address (which is
   the same, as this isn't for NAT66), an IPv4 address of is

   The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field
   with the time elapsed since its port mapping table was initialized on
   startup or reset for any other reason (see "Seconds Since Start of
   Epoch" (Section 6.1.6)).

   Upon receiving a response packet, the client MUST check the source IP
   address, and silently discard the packet if the address is not the
   address of the gateway to which the request was sent.

6.1.3.  Returning a Mapping

   To create a mapping, the client sends a UDP packet to port TBD of the
   gateway's internal IP address with the following format:

Wing & Penno            Expires September 2, 2010              [Page 10]

Internet-Draft         Port Control Protocol (PCP)            March 2010

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   | Version = 0      | OP = x        | Reserved (MUST be zero)    |
   | Internal Port                 | Requested External Port       |
   | Requested Port Mapping Lifetime in Seconds                    |

   Opcodes supported:  1 - Map UDP, 2 - Map TCP

   The Reserved field MUST be set to zero on transmission and MUST be
   ignored on reception.  The Internal Port is set to the local port on
   which the client is listening.

   If the client would prefer to have a high-numbered "anonymous"
   external port assigned, then it should set the Requested External
   Port to zero, which indicates to the gateway that it should allocate
   a high-numbered port of its choosing.  If the client would prefer
   instead to have the mapped external port be the same as its local
   Internal Port if possible (e.g. a web server listening on port 80
   that would ideally like to have external port 80) then it should set
   the Requested External Port to the desired value.  However, the
   gateway is not obliged to assign the port requested, and may choose
   not to, either for policy reasons (e.g. port 80 is reserved and
   clients may not request it) or because that port has already been
   assigned to some other client.  Because of this, some product
   developers have questioned the value of having the Requested External
   Port field at all.  The reason is for failure recovery.  Most low-
   cost home NAT gateways do not record temporary port mappings in
   persistent storage, so if the gateway crashes or is rebooted, all the
   mappings are lost.  A renewal packet is formatted identically to an
   initial mapping request packet, except that for renewals the client
   sets the Requested External Port field to the port the gateway
   actually assigned, rather than the port the client originally wanted.
   When a freshly-rebooted NAT gateway receives a renewal packet from a
   client, it appears to the gateway just like an ordinary initial
   request for a port mapping, except that in this case the Requested
   External Port is likely to be one that the NAT gateway *is* willing
   to allocate (it allocated it to this client right before the reboot,
   so it should presumably be willing to allocate it again).

   The RECOMMENDED Port Mapping Lifetime is 3600 seconds.

   If the client is allocated fixed ports, the PCP server simply returns
   a UDP or TCP port that allocated to the client.

Wing & Penno            Expires September 2, 2010              [Page 11]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   After sending the port mapping request, the client then waits for the
   NAT gateway to respond.  If after 250ms, the gateway doesn't respond,
   the client SHOULD re-issue its request as described above in
   "Requests and Responses" (Section 6.1.1).

   The NAT gateway responds with the following 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
     | Version = 0   | OP = 128 + x  | Result Code                   |
     | Seconds Since Start of Epoch                                  |
     | Internal Port                 | Mapped External Port          |
     | Port Mapping Lifetime in Seconds                              |

   The 'x' in the OP field MUST match what the client requested.  Some
   NAT gateways are incapable of creating a UDP port mapping without
   also creating a corresponding TCP port mapping, and vice versa, and
   these gateways MUST NOT implement NAT Port Mapping Protocol until
   this deficiency is fixed.  A NAT gateway which implements this
   protocol MUST be able to create TCP-only and UDP-only port mappings.
   If a NAT gateway silently creates a pair of mappings for a client
   that only requested one mapping, then it may expose that client to
   receiving inbound UDP packets or inbound TCP connection requests that
   it did not ask for and does not want.

   While a NAT gateway MUST NOT automatically create mappings for TCP
   when the client requests UDP, and vice versa, the NAT gateway MUST
   reserve the companion port so the same client can choose to map it in
   the future.  For example, if a client requests to map TCP port 80, as
   long as the client maintains the lease for that TCP port mapping,
   another client with a different IP address MUST NOT be able to
   successfully acquire the mapping for UDP port 80.

   The client normally requests the external port matching the internal
   port.  If that external port is not available, the NAT gateway MUST
   return an available external port or return an error code if no ports
   are available.

   The source address of the packet MUST be used for the internal
   address in the mapping.  This protocol is not intended to facilitate
   one device behind a NAT creating mappings for other devices.  If
   there are legacy devices that require inbound mappings, permanent
   mappings can be created manually by the administrator, just as they
   are today.

Wing & Penno            Expires September 2, 2010              [Page 12]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   If a mapping already exists for a given internal port on a given
   local client (whether that mapping was created explicitly using PCP,
   implicitly as a result of an outgoing TCP SYN packet, or manually by
   a human administrator) and that client requests another mapping for
   the same internal port (possibly requesting a different external
   port) then the mapping request should succeed, returning the already-
   assigned external port.  This is necessary to handle the case where a
   client requests a mapping with requested external port X, and is
   granted a mapping with actual external port Y, but the
   acknowledgement packet gets lost.  When the client retransmits its
   mapping request, it should get back the same positive acknowledgement
   as was sent (and lost) the first time.

   The NAT gateway MUST NOT accept mapping requests destined to the NAT
   gateway's external IP address or received on its external network
   interface.  Only packets received on the internal interface(s) with a
   destination address matching the internal address(es) of the NAT
   gateway should be allowed.

   The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field
   with the time elapsed since its port mapping table was initialized on
   startup or reset for any other reason (see Section "Seconds Since
   Start of Epoch" (Section 6.1.6)).

   The Port Mapping Lifetime is an unsigned integer in seconds.  The NAT
   gateway MAY reduce the lifetime from what the client requested.  The
   NAT gateway SHOULD NOT offer a lease lifetime greater than that
   requested by the client.

   Upon receiving the response packet, the client MUST check the source
   IP address, and silently discard the packet if the address is not the
   address of the gateway to which the request was sent.

   The client SHOULD begin trying to renew the mapping halfway to expiry
   time, like DHCP.  The renewal packet should look exactly the same as
   a request packet, except that the client SHOULD set the requested
   external port to what the NAT gateway previously mapped, not what the
   client originally requested.  As described above, this enables the
   gateway to automatically recover its mapping state after a crash or

6.1.4.  Destroying a Mapping

   A mapping may be destroyed in a variety of ways.  If a client fails
   to renew a mapping, then when its lifetime expires the mapping MUST
   be automatically deleted.  In the common case where the gateway
   device is a combined DHCP server and NAT gateway, when a client's
   DHCP address lease expires, the gateway device MAY automatically

Wing & Penno            Expires September 2, 2010              [Page 13]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   delete any mappings belonging to that client.  Otherwise a new client
   being assigned the same IP address could receive unexpected inbound

   UDP packets or inbound TCP connection requests that it did not ask
   for and does not want.

   A client MAY also send an explicit packet to request deletion of a
   mapping that is no longer needed.  A client requests explicit
   deletion of a mapping by sending a message to the NAT gateway
   requesting the mapping, with the Requested Lifetime in Seconds set to
   0.  The requested external port MUST be set to zero by the client on
   sending, and MUST be ignored by the gateway on reception.

   When a mapping is destroyed successfully as a result of the client
   explicitly requesting the deletion, the NAT gateway MUST send a
   response packet which is formatted as defined in Section 6.1.3.  The
   response MUST contain a result code of 0, the internal port as
   indicated in the deletion request, an external port of 0, and a
   lifetime of 0.  The NAT gateway MUST respond to a request to destroy
   a mapping that does not exist as if the request were successful.
   This is because of the case where the acknowledgement is lost, and
   the client retransmits its request to delete the mapping.  In this
   case the second request to delete the mapping MUST return the same
   response packet as the first request.

   If the deletion request was unsuccessful, the response MUST contain a
   non-zero result code and the requested mapping; the lifetime is
   undefined (MUST be set to zero on transmission, and MUST be ignored
   on reception).  If the client attempts to delete a port mapping which
   was manually assigned by some kind of configuration tool, the NAT
   gateway MUST respond with a 'Not Authorized' error, result code 2.

   When a mapping is destroyed as a result of its lifetime expiring or
   for any other reason, if the NAT gateway's internal state indicates
   that there are still active TCP connections traversing that now-
   defunct mapping, then the NAT gateway SHOULD send appropriately-
   constructed TCP RST (reset) packets both to the local client and to
   the remote peer on the Internet to terminate that TCP connection.

   A client can request the explicit deletion of all its UDP or TCP
   mappings by sending the same deletion request to the NAT gateway with
   external port, internal port, and lifetime set to 0.  A client MAY
   choose to do this when it first acquires a new IP address in order to
   protect itself from port mappings that were performed by a previous
   owner of the IP address.  After receiving such a deletion request,
   the gateway MUST delete all its UDP or TCP port mappings (depending
   on the opcode).  The gateway responds to such a deletion request with
   a response as described above, with the internal port set to zero.

Wing & Penno            Expires September 2, 2010              [Page 14]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   If the gateway is unable to delete a port mapping, for example,
   because the mapping was manually configured by the administrator, the
   gateway MUST still delete as many port mappings as possible, but
   respond with a non-zero result code.  The exact result code to return
   depends on the cause of the failure.  If the gateway is able to
   successfully delete all port mappings as requested, it MUST respond
   with a result code of 0.

6.1.5.  Result Codes

   Currently defined result codes:

      0 - Success

      1 - Unsupported Version

      2 - Not Authorized/Refused

      (e.g. box supports mapping, but user has turned feature off)

      3 - Network Failure

      (e.g.  NAT box itself has not obtained a DHCP lease)

      4 - Out of resources

      (NAT box cannot create any more mappings at this time)

      5 - Unsupported opcode

      6 - Per-subscriber resource limit would be exceeded (from

   If the result code is non-zero, the format of the packet following
   the result code may be truncated.  For example, if the client sends a
   request to the server with an opcode of 17 and the server does not
   recognize that opcode, the server SHOULD respond with a message where
   the opcode is 17 + 128 and the result code is 5 (opcode not
   supported).  Since the server does not understand the format of
   opcode 17, it may not know what to place after the result code.  In
   some cases, relevant data may follow the opcode to identify the
   operation that failed.  For example, a client may request a mapping
   but that mapping may fail due to resource exhaustion.  The server
   SHOULD respond with the result code to indicate resource exhaustion
   (4) followed by the requested port mapping so the client may identify
   which operation failed.

   Clients MUST be able to properly handle result codes not defined in

Wing & Penno            Expires September 2, 2010              [Page 15]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   this document.  Undefined results codes MUST be treated as fatal
   errors of the request.

6.1.6.  Seconds Since Start of Epoch

   Every packet sent by the NAT gateway includes a "Seconds since start
   of epoch" field (SSSOE).  If the NAT gateway resets or loses the
   state of its port mapping table, due to reboot, power failure, or any
   other reason, it MUST reset its epoch time and begin counting SSSOE
   from 0 again.  Whenever a client receives any packet from the NAT
   gateway, either gratuitously or in response to a client request, the
   client computes its own conservative estimate of the expected SSSOE
   value by taking the SSSOE 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 SSSOE in the newly received packet is
   less than the client's conservative estimate by more than one second,
   then the client concludes that the NAT gateway has undergone a reboot
   or other loss of port mapping state, and the client MUST immediately
   renew all its active port mapping leases.

6.2.  Interactions with Outgoing Sessions

   There are a few important considerations when port forwarding is
   combained with a NAT that uses address pools.  First and foremost, if
   there is a port forwarding mapping between certain external and
   internal addresses, all sessions originated by the host associated
   with the internal address should use the same external address
   present in the port forwarding mapping.

7.  PCP and Dual Stack-Lite

   In the case of Dual Stack-Lite deployments, PCP packets triggered by
   HTML-based configuration would be crafted as described in Section 6
   and encapsulated in IPv4.  The source IPv4 would be the internal host
   used in the port forwarding configuration and the destination IPv4 is
   based on the decision of Section 5.  The UDP destination port MUST be
   set fo the IANA allocated desitnation port for PCP.  Then, the PCP
   request is encapsulated in an IPv6 packet following RFC2473 and sent
   to the softwire concentrator (which is called "AFTR" in Dual-Stack

   The AFTR decapsulates the IPv4 packet and processes the PCP packet.

8.  PCP and NAT64

   Hosts behind a NAT64 device can make use of PCP in order to perform

Wing & Penno            Expires September 2, 2010              [Page 16]

Internet-Draft         Port Control Protocol (PCP)            March 2010

   port reservation (to get a publicly-routable IPv4 port).

   If in "Discovery" (Section 5) we choose to have an IANA-assigned IP
   address for 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

9.  PCP and IPv6 Simple Security

   [[text to be added.]]

10.  PCP IANA-Assigned Address

   Using an IANA-assigned PCP address allows the device performing PCP
   to be located anywhere (rather than solely on the local LAN or on the
   next-hop router).

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

11.  Security Considerations

   Any software on the host can open a UDP or TCP port on an upstream
   NAT or upstream firewall, permitting incoming connections.  At first
   glance, this seems risky, as malicious software running on a host
   could allow that host's web server to be accessible from the
   Internet, for example.  However, that same malicious software, if it
   were restricted to only open incoming connections for itself could do
   so, and could then relay incoming traffic to the host's own
   webserver.  Thus, security is no worse by allowing an application to
   open other arbitrary ports.

12.  Acknowledgements

   PCP is very closely related to NAT-PMP [I-D.cheshire-nat-pmp] (Stuart
   Cheshire, Marc Krochmal, Kiren Sekar) and SP-NAT-PMP
   [I-D.woodyatt-spnatpmp-appl] (James Woodyatt).  Our thanks to authors
   of those documents.

Wing & Penno            Expires September 2, 2010              [Page 17]

Internet-Draft         Port Control Protocol (PCP)            March 2010

13.  IANA Considerations

   Assign an IPv4 and IPv6 address for PCP, should we decide to use the
   IP address discovery mechanism Section 5.

   Assign a UDP port for PCP communication, preferably from the well-
   known port range (0-1023).

14.  References

14.1.  Normative References

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

14.2.  Informative References

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

              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-04 (work in progress),
              January 2010.

              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation",
              draft-ietf-behave-v6v4-framework-07 (work in progress),
              February 2010.

              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-03 (work in progress),
              February 2010.

              Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment for Providing Residential IPv6
              Internet Service", draft-ietf-v6ops-cpe-simple-security-09
              (work in progress), February 2010.


Wing & Penno            Expires September 2, 2010              [Page 18]

Internet-Draft         Port Control Protocol (PCP)            March 2010

              Wing, D., "Relaying HTTP from IPv4 to IPv6",
              draft-wing-behave-http-46-relay-02 (work in progress),
              October 2009.

              Woodyatt, J., "Applicability of NAT-PMP with Service
              Provider Deployments of Network  Address Translation",
              draft-woodyatt-spnatpmp-appl-01 (work in progress),
              November 2008.

   [IGD-2]    UPnP Gateway Committee, "IGD:2 improvements over IGD:1",
              2009, <http://www.upnp.org/resources/documents/

              UPnP Forum, "Universal Plug and Play Internet Gateway
              Device", 2000,

Appendix A.  PCP implemented on host

   NOTE:  This is for future study.

   It is also possible for PCP to be implemented directly on a host, as
   shown below.

   Scenario 3

                             +-------------+    +----------+
   IPv4 host using PCP=======+             |    |Dual-Stack|
                             |   customer  +====+ Lite AFTR+--<Internet>
                             |   premise   |    +----------+
                             |    router   |

                     Figure 3: CPE router unaware PCP

Wing & Penno            Expires September 2, 2010              [Page 19]

Internet-Draft         Port Control Protocol (PCP)            March 2010

Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134

   Email:  dwing@cisco.com

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

   Email:  rpenno@juniper.net

Wing & Penno            Expires September 2, 2010              [Page 20]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/