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

Versions: (draft-wing-softwire-port-control-protocol) 00 01 draft-ietf-pcp-base

PCP working group                                                D. Wing
Internet-Draft                                                     Cisco
Intended status: Standards Track                        October 25, 2010
Expires: April 28, 2011


                     Pinhole Control Protocol (PCP)
                         draft-wing-pcp-base-01

Abstract

   Pinhole Control Protocol is an address-family independent mechanism
   to control how incoming packets are forwarded by upstream devices
   such as IPv4 NAT devices, NAT64 devices, and IPv6 firewalls.

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 April 28, 2011.

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



Wing                     Expires April 28, 2011                 [Page 1]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   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 Premise Network  . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  PCP Server Discovery . . . . . . . . . . . . . . . . . . . . .  6
   5.  Common Request and Response Header Format  . . . . . . . . . .  7
     5.1.  Request Header . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Response Header  . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Information Elements . . . . . . . . . . . . . . . . . . .  9
     5.4.  Result Codes . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  OpCodes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  PIN OpCodes  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  PCP Mapping State Maintenance  . . . . . . . . . . . . . . . . 14
     7.1.  Epoch  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.  Recreating Pinholes  . . . . . . . . . . . . . . . . . . . 15
     7.3.  Maintaining Pinholes . . . . . . . . . . . . . . . . . . . 17
     7.4.  Nested NATs  . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Processing Pinhole Requests and Responses  . . . . . . . . . . 18
     8.1.  Generating and Sending a Request . . . . . . . . . . . . . 18
     8.2.  Processing a Request and Generating the Response . . . . . 18
     8.3.  Processing a Response  . . . . . . . . . . . . . . . . . . 20
   9.  PCP Client Operation . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Pinhole Lifetime Extension . . . . . . . . . . . . . . . . 20
     9.2.  Pinhole Deletion . . . . . . . . . . . . . . . . . . . . . 20
     9.3.  Multi-interface Issues . . . . . . . . . . . . . . . . . . 21
     9.4.  Renumbering  . . . . . . . . . . . . . . . . . . . . . . . 21
   10. PCP Server Operation . . . . . . . . . . . . . . . . . . . . . 21
     10.1. Relationship of PCP Server and its NAT . . . . . . . . . . 21
     10.2. Pinhole Lifetime . . . . . . . . . . . . . . . . . . . . . 22
     10.3. Pinhole deletion . . . . . . . . . . . . . . . . . . . . . 22
     10.4. Subscriber Identification  . . . . . . . . . . . . . . . . 23
     10.5. External IP Address  . . . . . . . . . . . . . . . . . . . 24
   11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24
     11.1. Dual Stack-Lite  . . . . . . . . . . . . . . . . . . . . . 24
       11.1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . 24
       11.1.2.  Encapsulation Mode  . . . . . . . . . . . . . . . . . 25
       11.1.3.  Plain IPv6 Mode . . . . . . . . . . . . . . . . . . . 25
     11.2. NAT64  . . . . . . . . . . . . . . . . . . . . . . . . . . 25



Wing                     Expires April 28, 2011                 [Page 2]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


     11.3. NAT44 and NAT444 . . . . . . . . . . . . . . . . . . . . . 26
     11.4. IPv6 Firewall  . . . . . . . . . . . . . . . . . . . . . . 26
   12. Adjacent Port Procedure  . . . . . . . . . . . . . . . . . . . 26
   13. Interworking with UPnP IGD . . . . . . . . . . . . . . . . . . 27
     13.1. UPnP IGD 1.0 with AddPortMapping Action  . . . . . . . . . 27
     13.2. UPnP IGD 2.0 with AddAnyPortMapping Action . . . . . . . . 29
     13.3. Lifetime Maintenance . . . . . . . . . . . . . . . . . . . 30
   14. NAT-PMP Backwards Compatibility  . . . . . . . . . . . . . . . 30
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
     16.1. PCP Server IP address  . . . . . . . . . . . . . . . . . . 31
     16.2. Port Number  . . . . . . . . . . . . . . . . . . . . . . . 31
     16.3. OpCodes  . . . . . . . . . . . . . . . . . . . . . . . . . 31
     16.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 31
     16.5. Information Elements . . . . . . . . . . . . . . . . . . . 31
   17. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     18.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     18.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Appendix A.  Analysis of Techniques to Discover PCP Server . . . . 34
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36






























Wing                     Expires April 28, 2011                 [Page 3]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


1.  Introduction

   Pinhole Control Protocol (PCP) provides a mechanism to control how
   incoming packets are forwarded by upstream devices such as NATs and
   firewalls.  PCP is primarily designed to be implemented in the
   context of both large scale NAT and low-scale NAT (e.g., residential
   NATs).  PCP allows hosts to operate servers permanently (e.g., a
   webcam) or temporarily (e.g., while playing a game) when behind one
   or more NAT devices, including when behind a large-scale NAT operated
   by their Internet service provider.

   PCP allows applications to create pinholes from an external IP
   address 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 pinhole is created in the firewall.  These pinholes
   are required for successful inbound communications destined to
   machines located behind a NAT.

   After creating a pinhole 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 rendzevous 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.


2.  Scope

2.1.  Deployment Scenarios

   PCP can be used in various deployment scenarios, including:

   o  DS-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;

   o  Large-Scale NAT44 [I-D.ietf-behave-lsn-requirements], including
      nested NATs ("NAT444"), 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 [I-D.ietf-v6ops-cpe-simple-security].






Wing                     Expires April 28, 2011                 [Page 4]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


2.2.  Supported Transport Protocols

   The PCP OpCodes defined in this document are designed to support
   transport protocols that uses a port number (e.g., TCP, UDP, SCTP,
   DCCP).  Transport protocols that do not use a port number (e.g.,
   IPsec ESP) can be wildcarded (allowing any traffic with that protocol
   to pass), provided of course the upstream device being controlled by
   PCP supports that functionality, or new PCP OpCodes can be defined to
   support those protocols.

   In this document, only TCP and UDP are defined.

2.3.  Single-homed Customer Premise Network

   The PCP machinery assumes a single-homed subscriber model.  That is,
   for a given IP version, only one default route exists to reach the
   Internet, much as there is only one default route for a dynamic
   connection (e.g., TCP SYN) towards the Internet.  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.


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

   Port Forwarding:

         Port forwarding allows a host to receive traffic sent to a
         specific IP address and port.

         In the context of a NAT with internal and external IP
         addresses, 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 (also called
         "mapped") to the internal IP address and port number.  The
         internal and external IP addresses are different, and a key
         point is that the internal and external transport destination
         port numbers could be different.  For example, 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.





Wing                     Expires April 28, 2011                 [Page 5]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


         In the context of a firewall, the internal and external IP
         addresses (and ports) are not changed.

   PCP Client:

         The network element that sends PCP requests to the PCP Server.
         This network element could be an application running on a host,
         embedded in the host's OS or libraries, or running on a network
         device (such as a customer premise router).

   PCP Server:

         A network element which receives and processes PCP requests
         from a PCP Client.  See also Section 10.1.

   Mapping:

         In the context of Network Address Translation a 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.

   Mapping Types:

         There are three different ways to create mappings: dynamic
         (e.g., outgoing TCP SYN), PCP, and static configured (e.g., CLI
         or web page) .  These mappings are one and the same but their
         attributes such as lifetime or filtering might be different.

   Interworking Function:  A PCP Interworking Function denotes a
      functional element which is responsible for another protocol with
      PCP, for example interworking with UPnP IGD [IGD] described in
      Section 13.


4.  PCP Server Discovery

   There are several possible methods to discover a PCP Service:

   o  sending the PCP message to the default router.  This requires the
      default router to support PCP.

   o  a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA.
      This follows the same routing path as other Internet-bound
      traffic.





Wing                     Expires April 28, 2011                 [Page 6]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


         [Ed.  Note: For an IPv4 address, would the AFTR element's IPv4
         address, 192.0.0.1, be suitable as this address for DS-Lite
         deployments?  Would that same address be suitable for all PCP
         deployment scenarios?]

   o  New DHCP option.  This requires the local network's DHCP server
      support the new option.

      [Ed.  Note: more discussion around these methods is necessary to
      reach consensus on the best approach(es)s for PCP.]


5.  Common Request and Response Header Format

   PCP is intended to be backwards compatible with NAT-PMP so that a
   NAT-PMP client (or server) will receive an error message when sending
   a request to a PCP server (or client).

   All PCP messages contain a request (or response) header, opcode-
   specific information, and (optional) informational elements.  These
   are described in the following sections.

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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver=1 |reserve|     OpCode    |    Protocol   |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Reserved (32 bits)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Informational Elements                 :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: Common Request Packet Format

   These fields are described below:

   Ver:  Version is 1






Wing                     Expires April 28, 2011                 [Page 7]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   reserve:  4 reserved bits, MUST be sent as 0, MUST be ignored when
      received.

   OpCode:  defined in Figure 5.

   Protocol:  indicates protocol associated with this opcode.  For
      example, this field contains 6 (TCP) if the opcode is intended to
      create a TCP mapping.  Values are taken from the IANA protocol
      registry [proto_numbers].  If a particular OpCode does not need
      the field, it MUST sent as 0 and MUST be ignored when received.

   Reserved:  The reserved fields 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver=1 |reserve|  Opcode+128   |    Protocol   |  Result Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Epoch                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) OpCode-specific response data          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Informational Elements                 :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Common Response Packet Format

   These fields are described below:

   Ver:  Version is 1

   reserve:  4 reserved bits, MUST be sent as 0, MUST be ignored when
      received.

   OpCode+128:  The OpCode value from the request plus 128.

   Protocol:  Protocol field, echoed exactly from the request







Wing                     Expires April 28, 2011                 [Page 8]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


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

   Epoch:  The server's Epoch value.  The same value is used for all PCP
      clients.  See Section 7.1 for discussion.

5.3.  Information Elements

   The Informational Elements (IE) allow extending PCP, without defining
   a new PCP version and without consuming additional opcodes.  IEs can
   be used in requests and responses.  It is anticipated that IEs will
   include information which are associated with the normal function of
   an OpCode, such as one of the PIN OpCodes defined in this document.
   For example, an IE could indicate DSCP markings to apply to incoming
   or outgoing traffic associated with a PCP pinhole, or an IE could
   include descriptive text (e.g., "for my webcam").

   IEs 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   IE Code     | Reserved      |          IE-Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                             data                              :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: Informational Element header

   The description of the fields is as follows:

   IE Code:  IE codes MUST be registered with IANA following the
      procedure described in Section 16.5.

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

   IE-Length:  Indicates in units of 4 octets the length of the enclosed
      data.  IEs MUST be padded when necessary to 32 bits boundaries.
      IEs with length of 0 are allowed.

   A given IE MAY be included in the request and/or the response.  The
   handling of an IE at the PCP Client and the PCP Server sides MUST be
   specified in dedicated document(s).

      [Ed.  Note: Do we want to allow an unsolicited IE to appear in a
      response?]

   If several IEs are to be included in a PCP request or response, IEs



Wing                     Expires April 28, 2011                 [Page 9]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   MAY be encoded in any order by the PCP Client or the PCP Server.

      [Ed.  Note: There are two proposals to handle unsupported IEs on
      the server: (1) return a notification in the response with the
      Code(s) of unsupported IEs, (2) every IE that appears in a request
      will cause an IE to appear in the response if the server
      understood the request' IE(s).  Consensus is needed.]

      [Ed.  Note: There is a proposal to define a Mandatory bit, so that
      the PCP server will not process a PCP request at all if it
      encounters an unsupported IE with the Mandatory bit set.  This
      diverges from IE being "informational", but may have some value.
      Consensus is needed.]

   New IEs are defined in companion documents and MUST follow the format
   shown in Figure 1.  To avoid errors and increased complexity, it is
   RECOMMENDED to define one single IE which carry all the required
   information for a given usage instead of defining several IEs to be
   included simultaneously in the same PCP message.  Interdependence
   between IEs SHOULD be avoided at maximum.

5.4.  Result Codes

   The following response codes are defined:

     0 - Success
     1 - Unsupported Version
     2 - Not Authorized/Refused
           (e.g., PCP server supports mapping, but feature is disabled)
     3 - Network Failure
           (e.g., NAT device has not obtained a DHCP lease)
     4 - Out of resources
           (e.g., NAT device cannot create more mappings at this time)
     5 - Unsupported opcode

                        Figure 4: PCP Result Codes

   Additional result codes are defined following the procedure in
   Section 16.4.


6.  OpCodes

   This document defines four OpCodes which share a similar packet
   layout for requests and responses.  For these OpCodes, the request
   and response packet formats take the same space and layout.  New
   OpCodes MAY choose to follow the same format.  The OpCodes defined in
   this document are:



Wing                     Expires April 28, 2011                [Page 10]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


     PIN44 = 0 = IPv4 address to IPv4 address (NAT44 or IPv4 firewall)
     PIN46 = 1 = IPv4 address to IPv6 address (NAT46)
     PIN64 = 2 = IPv6 address to IPv4 address (NAT64)
     PIN66 = 3 = IPv6 address to IPv6 address (NAT66 or IPv6 firewall)

                             Figure 5: OpCodes

6.1.  PIN OpCodes

   The four PIN OpCodes (PIN44, PIN46, PIN64, PIN66) share a similar
   packet layout for both requests and responses.  Because of this
   similarity, they are shown together.  For all of the PIN OpCodes, if
   the internal-ip-address and internal-port matches (requested)
   external-ip-address and (requested) external-port, the (request or)
   response pertains to a firewall; otherwise it pertains to a NAT.

   The following diagram shows the request packet format for PIN44,
   PIN46, PIN64, and PIN66:


      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 (always 160 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Pinhole Internal IP address (32 or 128, depending on OpCode)  :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Requested external IP address (32 or 128, depending on OpCode):
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Requested lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        internal port          |   requested external port     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 6: PIN OpCode Request Packet Format

   These fields are described below:






Wing                     Expires April 28, 2011                [Page 11]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


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

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

   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 MAY place any value into this
      field including 0.  If the Pinhole Internal IP Address equals the
      Requested External IP Address, it indicates the PCP client wants
      firewall (versus NAT) behavior.

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

   internal port:  Internal port for the pinhole.

   requested external port:  requested external port.

   internal port:  Internal port for the pinhole, copied from request.

   Assigned 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 SHOULD use 0.

      [Ed.  Note: for firewall, we need to add fields indicating the
      remote peer address (address family will match the address family
      of the requsted IP address).  Addition permission for multiple
      remote peers is possible (by sending multiple PCP requests, one
      for each remote peer's IP address).  Deleting a single permission
      would require a new OpCode.  Should perhaps firewall use different
      OpCodes than NAT??]

   The following diagram shows the response packet format for PIN44,
   PIN46, PIN64, and PIN66:












Wing                     Expires April 28, 2011                [Page 12]

Internet-Draft       Pinhole Control Protocol (PCP)         October 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PCP Request Address Family    |    PCP Request Port           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Request IP Address (always 128 bits)           |
     |                (first 32 bits are XOR'd)                      |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Pinhole Internal IP address (32 or 128, depending on OpCode)  :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : Assigned external IP address (32 or 128, depending on OpCode) :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Assigned lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       internal port           |    assigned external port     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: PIN OpCode Response Packet Format

   These fields are described below:

   PCP Request Address Family:  The IP address family of the PCP
      request, as received in the IP header by the PCP server.  Will
      usually be 1 (IPv4) or 2 (IPv6).  This is used by the PCP client
      to determine if there is a NAT between the PCP client and PCP
      server (see Section 7.4).

   PCP Request Port:  The port of the PCP request, as received in the
      UDP header by the PCP server.  This is used by the PCP client to
      determine if there is a NAT between the PCP client and PCP server
      (see Section 7.4).

   PCP Request IP Address:  The IPv4 or IPv6 address of the PCP request,
      as received in the IP header by the PCP server.  This is used by
      the PCP client to determine if there is a NAT between the PCP
      client and PCP server (see Section 7.4).  As some NATs rewrite
      IPv4 packets containing the NAT's public IPv4 address in the UDP
      payload, the first 32 bits of the address are XOR'd with
      0xFFFFFFFF if it contains an IPv4 address; IPv6 addresses are not
      XOR'd.





Wing                     Expires April 28, 2011                [Page 13]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   Pinhole Internal IP address  Copied from request.  IPv4 or IPv6
      address is indicated by the OpCode.

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

   Assigned Lifetime  Lifetime for this mapping, in seconds

   internal port  Internal port for the pinhole, copied from request.

   Assigned external port  requested external port for the mapping.
      IPv4 or IPv6 address is indicated by the OpCode


7.  PCP Mapping State Maintenance

   If an event occurs that causes the PCP server and NAT to lose state
   (such as a crash or power outage), the pinholes 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 indicates if the PCP server has lost its state.  If this
   occurs, the PCP client can attempt to recreate the pinholes following
   the procedures described in this section.

7.1.  Epoch

   Every packet sent by the PCP Server includes a "Seconds since start
   of epoch" field (SSSOE).  The PCP Server MUST set its Epoch time to
   zero when it is ready to accept new connections.  If the PCP Server
   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 PCP Server, 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 as
   described in Section 7.2.






Wing                     Expires April 28, 2011                [Page 14]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


7.2.  Recreating Pinholes

   The NAT gateway MAY store mappings in persistent storage so when it
   is powered off or rebooted, it remembers the port mapping state of
   the network.

   However, maintaining this state is not essential for correct
   operation.  When the NAT gateway powers on or clears its port mapping
   state as the result of a configuration change, it MUST reset the
   epoch time.

   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 freshly-
   rebooted NAT gateway it appears as a new mapping request.

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

   The remarkable reliability of the Internet as a whole derives in
   large part from the fact that important state is held in the
   endpoints, not in the network itself [Saltzer84]].  Power-cycling an
   Ethernet switch results only in a brief interruption in the flow of
   packets; established TCP connections through that switch are not
   broken, merely delayed for a few seconds.  Indeed, an old Ethernet
   switch can even be replaced with a new one, and as long as the cables
   are transferred over reasonably quickly, after the upgrade all the
   TCP connections that were previously going though the old switch will
   be unbroken and now going through the new one.  The same is true of
   IP routers, wireless base stations, etc.  The one exception is NAT
   gateways.  Because the port mapping state is required for the NAT
   gateway to know where to forward inbound packets, loss of that state
   breaks connectivity through the NAT gateway.  By allowing clients to
   detect when this loss of NAT gateway state has occurred, and recreate
   it on demand, we turn hard state in the network into soft state, and
   allow it to be recovered automatically when needed.

   Without this automatic recreation of soft state in the NAT gateway,
   reliable long-term networking would not be achieved.  As mentioned
   above, the reliability of the Internet does not come from trying to
   build a perfect network in which errors never happen, but from
   accepting that in any sufficiently large system there will always be
   some component somewhere that's failing, and designing mechanisms
   that can handle those failures and recover.  To illustrate this point
   with an example, consider the following scenario: Imagine a network
   security camera that has a web interface and accepts incoming
   connections from web browser clients.  Imagine this network security
   camera uses NAT-PMP or a similar protocol to set up an inbound port
   mapping in the NAT gateway so that it can receive incoming



Wing                     Expires April 28, 2011                [Page 15]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   connections from clients the other side of the NAT gateway.  Now,
   this camera may well operate for weeks, months, or even years.
   During that time it's possible that the NAT gateway could experience
   a power failure or be rebooted.  The user could upgrade the NAT
   gateway's firmware, or even replace the entire NAT gateway device
   with a newer model.  The general point is that if the camera operates
   for a long enough period of time, some kind of disruption to the NAT
   gateway becomes inevitable.  The question is not whether the NAT
   gateway will lose its port mappings, but when, and how often.  If the
   network camera and devices like it on the network can detect when the
   NAT gateway has lost its port mappings, and recreate them
   automatically, then these disruptions are self-correcting and largely
   invisible to the end user.  If, on the other hand, the disruptions
   are not self-correcting, and after a NAT gateway reboot the user has
   to manually reset or reboot all the other devices on the network too,
   then these disruptions are *very* visible to the end user.  This
   aspect of the design is what makes the difference between a protocol
   that keeps on working indefinitely over a time scale of months or
   years, and a protocol that works in brief testing, but in the real
   world is continually failing and requiring manual intervention to get
   it going again.

   When a client renews its port mappings as the result of receiving a
   packet where the "Seconds since start of epoch" field (SSSoE)
   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 port mapping request.  After that request is
   acknowledged by the gateway, the client may then send its second
   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.]

   The discussion in this section focusses on recreating inbound port
   mappings after loss of NAT gateway 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,



Wing                     Expires April 28, 2011                [Page 16]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   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 NAT-PMP.  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 later to recreate the
   mapping if it determines that the NAT gateway has lost its mapping
   state.

7.3.  Maintaining Pinholes

   A PCP client can refresh a pinhole 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 pinholes, the Epoch value only needs to be retrieved for one
   of them to verify the PCP server has not lost port forwarding state.

7.4.  Nested NATs

   A PCP Client can detect the presence of a NAT on the path between the
   PCP client and PCP server by sending a PCP request to the PCP server
   and comparing fields in the PCP response.  If the request's IP
   address family, IP address, and source port match the information in
   the PCP response's payload (PCP Request Address Family, PCP Request
   Port, and PCP Request XOR'd IP Address), there is no NAT on the path.
   If they differ, there is a NAT on the path.

      Note: this provides a function similar to STUN [RFC5389].  Being
      integrated within PCP itself provides the advantage of checking
      the path to the PCP server, which may be a different path than to
      the STUN server.

   After determining a NAT is on the path, the PCP application can take
   appropriate action based on this information.  This action would
   require using another mechanism to open pinholes in the intervening
   NATs (e.g., UPnP IGD, NAT-PMP) or returning an error to the user.




Wing                     Expires April 28, 2011                [Page 17]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


8.  Processing Pinhole Requests and Responses

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

8.1.  Generating and Sending a Request

   To create a pinhole, the PCP client generates a PCP request for the
   appropriate address family of the internal host and the desired
   public mapping.  The PCP request contains a PCP common header, PCP
   OpCode and payload, and optional Information Elements.

   The PCP client determines its PCP server using the procedure
   described in Section 4.  It initializes its retransmission timer,
   RETRY_TIMER, to the round trip time between the PCP client and PCP
   server.  If this value is unknown, 250ms is RECOMMENDED.  The PCP
   Client sends its PCP message to the PCP server and waits RETRY_TIMER
   for a response.  If no response is received, it doubles the value of
   RETRY_TIMER, sends another (identical) PCP message and waits
   RETRY_TIMER*2.  This procedure is repeated three times, doubling the
   value of RETRY_TIMER each time.  If no response is received after 4
   attempts, the PCP client tries with the next IP address in its list
   of PCP servers.  If it has exhausted its list, it SHOULD abort the
   procedure.  If, when sending PCP requests the PCP Client receives an
   ICMP error (e.g., port unreachable, network unreachable) it SHOULD
   immediately abort the procedure.  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.

8.2.  Processing a Request and Generating the Response

   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 optional Informational Elements (which the
   server might or might not comprehend).  If an error is encountered
   during processing, an error response is generated and sent back to
   the PCP client.

   After successful parsing of the message, the PCP server validates
   that the internal IP address in the PCP request belongs to that
   subscriber.  This validation depends on the deployment scenario; see
   Section 10.4.  If the internal IP address in the PCP request does not
   belong to the subscriber, an error response MUST be generated with
   error-code=2.



Wing                     Expires April 28, 2011                [Page 18]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   If the requested lifetime is 0, it indicates a Delete request.  This
   means the pinhole described by the internal IP address should be
   deleted, and requested external port field is ignored by the server
   (that is, it isn't validated).  If the deletion request was
   successful, apositive response generated containing external port of
   0 and lifetime of 0.  If the deletion request was unsusccessful a
   non-zero result code is returned and the lifetime is undefined.  If
   the client attempts to delete a port mapping which was manually
   assigned by some kind of configuration tool, the PCP server MUST
   respond with a 'Not Authorized' error (result code 2).

      [Ed.  Note: Should we similarly return an error if attempting to
      delete mappings that were created dynamically (e.g., TCP SYN)?]

   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 PCP server and NAT MUST delete all the port mappings.  The PCP
   server responds to such a deletion request with a response as
   described above, with the internal port set to zero.  If the PCP
   server is unable to delete a port mapping, for example, because the
   mapping was manually configured by a configuration tooll, 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.

   The PCP-controlled device MAY reduce the lifetime that was requested
   by the PCP Client.  The PCP-controlled device SHOULD NOT offer a
   lease lifetime greater than that requested by the PCP Client.  The
   RECOMMENDED lifetime assigned by the server is 7200 seconds (i.e.,
   two hours).

   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.
   Nevertheless, a configurable feature MAY be supported by the PCP-



Wing                     Expires April 28, 2011                [Page 19]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   controlled device, which MAY reserve (but not forward) the companion
   port so the same PCP Client can request it in the future.

   If all of the proceeding operations were successful (did not generate
   an error response), then the requested pinholes are created as
   described in the request and a positive response is built.  This
   positive response contains the same OpCode as the request plus 128.

8.3.  Processing a Response

   The PCP client receives the response and checks that the response
   matches one of its outstanding requests.  If it is an error response,
   the PCP client knows that none of the requested pinholes were
   created, and can attempt to resolve the problem based on the error
   code and error subcode.

   If it is an positive response, the PCP client knows the request was
   entirely successful and 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 mechanism.


9.  PCP Client Operation

   This section details operation specific to a PCP client.

9.1.  Pinhole Lifetime Extension

   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
   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 10.3).
   In order to prevent excessive PCP chatter, it is RECOMMENDED to renew
   only 60 seconds before expiration time (to account for
   retransmissions that might be necessary due to packet loss, clock
   synchronization between PCP client and PCP server, and so on).

9.2.  Pinhole Deletion

   A PCP Client MAY delete a pinhole prior to its natural expiration by
   sending a PCP Map Request with a lifetime of 0.  The PCP server
   responds by returning a PCP Map Response with a lifetime of 0.

   To delete all pinholes for all ports, the "W" (wildcard) bit is set,
   and no internal port/external port is included in the PCP request.



Wing                     Expires April 28, 2011                [Page 20]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


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

9.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 instructing a PCP mapping in a PCP-
   controlled device.  IPv6 addresses with limited scope (e.g., ULA),
   SHOULD NOT be indicated as internal IP address in a PCP message.

   As mentioned in Section 2.3, only mono-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.

9.4.  Renumbering

   The customer premise router might obtain a new IPv6 prefix, either
   due to a reboot, power outage, DHCPv6 lease expiry, or other action.
   If this occurs, the ports reserved using PCP might be delivered to
   another customer who now has that (old) address.  This same problem
   can occur if an IP address is re-assigned today, without PCP.  The
   solution is the same as today: ISPs should not re-assign IP
   addresses.


10.  PCP Server Operation

   This section details operation specific to a PCP server.

10.1.  Relationship of PCP Server and its NAT

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









Wing                     Expires April 28, 2011                [Page 21]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


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

                 Figure 8: device with Embedded PCP Server

   However, it is useful to also model a separation of the PCP server
   from the NAT, as shown below (Figure 9).  The PCP server would
   communicate with the NAT using a protocol beyond the scope of this
   document, such as a proprietary protocol or any suitable standard
   protocol for NAT control).
                                  +-----------------+
                               +--+ NAT or firewall +---<Internet>
                              /   +-----------------+
     +------------+          /          ^
     | PCP Client +-<network>           | suitable NAT control protocol
     +------------+          \          v
                              \   +------------+
                               +--+ PCP Server |
                                  +------------+

                  Figure 9: NAT with Separate PCP Server

10.2.  Pinhole Lifetime

   Once a PCP server has responded positively to a pinhole request for a
   certain lifetime, the port forwarding is active for the duration of
   the lifetime unless deleted by the PCP client.  Also see XXX.

   It is NOT RECOMMENDED that the server allow long 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.

   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.

10.3.  Pinhole deletion

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



Wing                     Expires April 28, 2011                [Page 22]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   another host for 120 seconds (MSL, [RFC0793]).

      [Ed.  Note: it should (MUST?) allow the same host to re-acquire
      the same port, though.]

10.4.  Subscriber Identification

   Subscribers identification is required for several reasons such as
   the following:

   o  Allow access to the network resources;

   o  Configure service profiles such as a bandwidth and/or port usage
      quotas for fairness service usage among all subscribers;

   o  Blacklist a subscriber because of abuse or non-payment of service
      fee, etc.

   o  Legal requirements such as legal intercept or legal storage.

   A PCP Client can create mappings in a PCP-controlled device on behalf
   of a third party device (e.g., a computer can create PCP mappings on
   behalf of a webcam).  However, it is not desirable for a PCP client
   to open pinholes for a different subscriber.  The mechanism to
   identify "same subscriber" depends on the sort of NAT on this
   network:

   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.

   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 11.1.2 and Section 11.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 CGN with a routed network, each subscriber has one IPv4 address
      and all PCP requests MUST be sent from only that IP address and
      MUST only open pinholes towards its own IP address.

   PCP-controlled devices can be a DS-Lite AFTR or an IPv4-IPv6
   interconnection node such as NAT46 or NAT64.  These nodes are



Wing                     Expires April 28, 2011                [Page 23]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   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.

10.5.  External IP Address

   If there are active mappings for a particular PCP Client -- created
   via dynamic assignment or created by PCP -- subsequent mapping
   requests from that same PCP Client MUST use the same external IP
   address.  This is necessary because some protocols require using the
   same IP address for several ports, and follows REQ-1 of
   [I-D.ietf-behave-lsn-requirements].  Additionally, all PCP-mapped
   requests MUST also use the same external IP address.  Once a client
   has no active dynamic mappings and no PCP pinholes, a subsequent
   dynamic mapping or PCP request MAY be assigned to a different
   external IP address.


11.  Deployment Scenarios

11.1.  Dual Stack-Lite

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

11.1.1.  Overview

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





Wing                     Expires April 28, 2011                [Page 24]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   1.  UPnP IGD and 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 13.

   2.  Hosts behind the B4 element include a PCP Client, and communicate
       directly with the PCP server.  No interworking function is
       required to be embedded in the B4 element.

   3.  The B4 element include a PCP Client which is invoked by an HTTP-
       based configuration (as is common today).  The internal-IP-
       address 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.]

11.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 AFTR decapsulates the IPv4 packets and processes
   the PCP requests (because the destination IPv4 address points to the
   PCP Server embedded in the AFTR).

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

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



Wing                     Expires April 28, 2011                [Page 25]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   network-specific prefix, per [I-D.ietf-behave-address-format].

11.3.  NAT44 and NAT444

   Subscribers are given only one IPv4 address.  To accomodate multiple
   hosts within the home, subscribers operate a NAPT device.  When this
   occurs in conjunction with an upstream NAT44, this is nicknamed
   "NAT444".

   In either environment (with or without a NAPT in the home), the
   service provider and PCP server see only one IPv4 address from each
   subscriber.

   PCP includes a function to detect a NAT between the PCP client and
   PCP server, described in Section 7.4.

11.4.  IPv6 Firewall

   [Ed.  Note: PCP packet format needs changes to support IPv6 firewall,
   or we need additional OpCodes for IPv6 firewall.]


12.  Adjacent Port Procedure

   RTP and RTCP have historically run on adjacent ports, and some
   existing equipment still expects them to be on adjacent ports.  To
   accomodate that, a procedure can be used rather than adding
   complexity to the protocol or to the server implementation.

      [Ed.  Note: Are there any other referencable protocols that need
      adjacent ports?]

   The procedure is for the PCP client to bind to two ports on its local
   interface.  It then sends a PCP request for external port 0
   (indicating it will accept any port from the server) for one of those
   internal ports.  This request can have a short lifetime (e.g., 5
   seconds) to avoid the need to delete the pinhole.  It receives the
   PCP response indicating it now has external port N. The PCP client
   then attempts to obtain a port on either side of this external port.
   It sends two PCP requests, using the same internal port number in
   both requests, for external port N-1 and for external port N+1.  The
   adjacent external ports N-1 and N+1 are either (a) not available, (b)
   only one is available, or (c) both are available.  If (a), an
   unrelated port will be assigned and the procedure can be repeated.
   If (b) the procedure was successful.  Case (c) is also successful,
   because the PCP client cannot distinguish it from case (b), because
   the PCP server maps an specific internal IP address and internal port
   to a single external IP address and port.



Wing                     Expires April 28, 2011                [Page 26]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


      [Ed.  Note: Add message flow diagram showing adjacent port
      procedure]


13.  Interworking with UPnP IGD

   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 10: Network Diagram, Interworking UPnP IGD and PCP

13.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.  Requesting a specific port is
   incompatible with both (1) a large-scale NAT and with (2) successful
   applications.  Regarding (1), other subscribers are likely to also be
   running the same application, all demanding (or desiring) the same
   port number.  Regarding (2), a popular application will exist on
   multiple devices within the home.  Thus, PCP is not designed to
   optimize for this behavior of requesting a particular port as it
   cannot work well in address sharing environments; but PCP will work
   with this behavior using the suggested procedure below.

   Due to this incompatibility with large-scale address sharing and
   popular applications, future hosts and applications will either
   support UPnP IGD 2.0 (which has improved behavior, see Section 13.2)
   or will support PCP.

   To interwork from UPnP IGD to PCP, our recommendation is that every
   UPnP request be forwarded to the PCP server -- this works no matter
   if the UPnP IGD control point is randomizing or incrementing each
   port number when its requests fail.  When a requested port assignment
   fails, most UPnP IGD control points will retry the port assignment



Wing                     Expires April 28, 2011                [Page 27]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   requesting the next higher port or requesting a random port.  In
   either case, the described procedure will work.  The UPnP IGD/PCP
   interworking function would request very short leases (e.g., 5
   seconds) in order to avoid the chatter of a Delete message
   (lifetime=0).  Once a port can be allocated, its lifetime is
   extended.  When interworking with UPnP IGD, the in-home CPE limits
   itself to sending one PCP message a second, which ensures there are
   only 5 outstanding PCP reservations at a time; this avoids consuming
   all of that subscriber's NAT mappings while trying to find an
   available port via the UPnP IGD->PCP interworking function).

      Note: for this to work successfully, the PCP server (large NAT)
      needs to honor the requested-external-port field in the PCP
      request.  Which is the purpose of that field, of course.





































Wing                     Expires April 28, 2011                [Page 28]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


                  Message flow would be similar to this:

        UPnP CP                in-home CPE                  PCP server
          |                         |                           |
          |-UPnP:give me port 80--->|                           |
          |                         |-PCP:request port 80------>|
          |                         |  with lifetime=5 seconds  |
          |                         |<-PCP:here is port 51389---|
          |<-UPnP: unavailable------|                           |
          |                         |                           |
          |        (allow port 51389 to naturally expire,       |
          |                 or actively Delete it)              |
          |                         |                           |
          |-UPnP:give me port 3213->|                           |
          |                         |-PCP:request port 3213---->|
          |                         |  with lifetime=5 seconds  |
          |                         |<-PCP:here is port 23831---|
          |<-UPnP: unavailable------|                           |
          |                         |                           |
          |          (allow port 23831 to naturally expire,     |
          |                 or actively Delete it)              |
          |                         |                           |
         ...       ...             ...                         ...
          |                         |                           |
          |-UPnP:give me port 8921->|                           |
          |                         |-PCP:request port 8921---->|
          |                         |  with lifetime=5 seconds  |
          |                         |<-PCP:here is port 8921----|
          |                         |                           |
          |                         |-PCP:life=1 hour,port=8921>|
          |                         |<-PCP:ok-------------------|
          |                         |                           |
          |<-UPnP: ok, port 8921----|                           |
          |                         |                           |

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

13.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 the IGD 2's new AddAnyPortMapping message, 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.





Wing                     Expires April 28, 2011                [Page 29]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


13.3.  Lifetime Maintenance

   UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
   interworking function is responsible for extending the lifetime of
   mappings that are still interesting to the UPnP IGD device.

      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.  The UPnP IGD/PCP
      interworking function is responsible for renewing the PCP lifetime
      as necessary.  As long as client renews its DHCP lease, the PCP
      lifetime should also be extended.  For clients not using DHCP,
      other mechanisms to check on the client host's liveliness can also
      be useful (e.g., ping, ARP, or WiFi association) can be used to
      discern liveliness of the UPnP IGD control point.  However, it is
      NOT RECOMMENDED to attempt to connect to the TCP or UDP port
      opened on the control point to determine if the host still wants
      to receive packets; the server could be temporarily down when
      tested, causing a false negative.


14.  NAT-PMP Backwards Compatibility

   Because NAT-PMP and PCP share the same port, it is important that a
   NAT-PMP client receive a NAT-PMP error message.  This is done by
   examining the version number of the incoming PCP message; if it is
   zero, the message is from a NAT-PMP client.  A valid NAT-PMP response
   (rather than a PCP response) is necessary, shown below.

   A server which supports both NAT-PMP and PCP would be able to process
   both NAT-PMP and PCP requests normally, and (if necessary) proxy
   between the protocols.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       0       | OP = 128 + x  | Response Code=1 (unsupp. ver.)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                           0 (96 bits)                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 12: NAT-PMP response





Wing                     Expires April 28, 2011                [Page 30]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


      [Ed.  Note: More analysis is necessary on NAT-PMP backward
      compatibility, including checking if NAT-PMP clients are compliant
      with [I-D.cheshire-nat-pmp]] regarding error handling.


15.  Security Considerations

   [Ed.  Note: to be completed.]


16.  IANA Considerations

   IANA is requested to perform the following actions:

16.1.  PCP Server IP address

   IANA shall assign an IPv4 and an IPv6 address for PCP discovery.

   [Ed.  Note: perhaps we can use the AFTR element's IPv4 address?  But
   still need an IPv6 address assigned for PIN64 and PIN66.]

16.2.  Port Number

   Re-use NAT-PMP port number, UDP/5351.

16.3.  OpCodes

   IANA shall create a new protocol registry for PCP OpCodes, initially
   populared with the values in Figure 5.

   New OpCodes can be created via Standards Action [RFC2434].

16.4.  Result Codes

   IANA shall create a new registry for PCP result codes, numbered
   0-255, initially populated with the error codes from Figure 4.

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

16.5.  Information Elements

   IANA shall create a new registry for PCP Information Elements,
   numbered 0-255 with associated mnemonic.

   New information elements in the range 0-127 can be created via
   Standards Action [RFC2434], new information elements in the range
   128-192 can be created with Expert Review [RFC2434], and the range
   193-255 is for Private Use [RFC2434].



Wing                     Expires April 28, 2011                [Page 31]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


17.  Acknowledgments

   Thanks to Alain Durand and Christian Jacquenet for their comments and
   review.

   Thanks to Mohamed Boucadair, Francis Dupont, and Reinaldo Penno for
   significant contributions.  Thanks to Stuart Cheshire for writing
   NAT-PMP [I-D.cheshire-nat-pmp] and for his contributions to this
   document.


18.  References

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

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

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





Wing                     Expires April 28, 2011                [Page 32]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


18.2.  Informative References

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

   [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-address-format]
              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-10 (work in progress),
              August 2010.

   [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.ietf-v6ops-cpe-simple-security]
              Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment for Providing Residential IPv6
              Internet Service", draft-ietf-v6ops-cpe-simple-security-16
              (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/igd2>.

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

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.



Wing                     Expires April 28, 2011                [Page 33]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [Saltzer84]
              Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments
              in system design", 1984, <http://web.mit.edu/Saltzer/www/
              publications/endtoend/endtoend.pdf>.


Appendix A.  Analysis of Techniques to Discover PCP Server

      [[Ed.  Note: This Appendix will be removed in a later version of
      this document.  It is included here for reference and discussion
      purposes.]]

   Several mechanisms for discovering the PCP Server can be envisaged as
   listed below:

   1.  A special-purpose IPv4 or IPv6 address, assigned by IANA, which
       is routed normally until it hits a PCP Server, which responds.

          Analysis: This solution can be deployed in the context of DS-
          Lite architecture.  Concretely, a well-known IPv4 address can
          be used to reach a PCP Server embedded in the device that
          embeds the AFTR capabilities.  Since all IPv4 messages issued
          by a DS-Lite CP router will be encapsulated in IPv6, no state
          synchronisation issues will be experienced because PCP
          messages will be handled by the appropriate PCP Server.

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

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

          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.




Wing                     Expires April 28, 2011                [Page 34]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   2.  Assume the default router is a PCP Server, and send PCP packets
       to the IP address of the default router.

          Analysis: This solution is not suitable for DS-Lite NAT44 nor
          for all variants of NAT64/NAT46.

             In the context of DS-Lite: There is no default IPv4 router
             configured in the CP router.  All outgoing IPv4 traffic is
             encapsulated in IPv6 and then forwarded to a pre-configured
             DS-Lite AFTR device.  Furthermore, if IPv6 is used to reach
             the PCP Server, the first router may not be the one which
             embeds the AFTR.

             For NAT64/NAT46 scenarios: The NAT function is not embedded
             in the first router, therefore this solution candidate does
             not allow to discover a valid PCP Server.

          Therefore, this alternative is not recommended.

   3.  Service Location Protocol (SLP [RFC2608]).

          Analysis: This solution is not suitable in scenarios where
          multicast is not enabled.  SLP is a chatty protocol.  This
          alternative is not recommended.

   4.  NAPTR.  The host would issue a DNS query for a NAPTR record,
       formed from some bits of the host's IPv4 or IPv6 address.  For
       example, a host with the IPv6 address 2001:db8:1:2:3:4:567:89ab
       would first send an NAPTR query for
       3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements,
       representing a /64 network prefix), which returns the PCP
       Server's IPv6 address.  A similar scheme can be used with IPv4
       using, for example, the first 24 bits of the IPv4 address.

          Analysis: This solution candidate requires more configuration
          effort by the Service Provider so as to redirect a given
          client to the appropriate PCP Server.  Any change of the
          engineering policies (e.g., introduce new LSN device, load-
          based dimensioning, load-balancing, etc.) would require to
          update the zone configuration.  This would be a hurdle for the
          flexibility of the operational networks.  Adherence to DNS is
          not encouraged and means which allows for more flexibility are
          to be promoted.

          Therefore, this mechanism is not recommended.






Wing                     Expires April 28, 2011                [Page 35]

Internet-Draft       Pinhole Control Protocol (PCP)         October 2010


   5.  New DHCPv6/DHCP option and/or a RA option to convey an FQDN of a
       PCP Server.

          Analysis: Since DS-Lite and NAT64/NAT46 are likely to be
          deployed in provider-provisioned environments, DHCP (both
          DHCPv6 and IPv4 DHCP) is convenient to provision the address/
          FQDN of the PCP Server.


Author's Address

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

   Email: dwing@cisco.com

































Wing                     Expires April 28, 2011                [Page 36]


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