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

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

PCP working group                                                D. Wing
Internet-Draft                                                     Cisco
Intended status: Standards Track                         January 4, 2011
Expires: July 8, 2011


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

Abstract

   Port Control Protocol is an address-family independent mechanism to
   control how incoming packets are forwarded by upstream devices such
   as network address translators (NATs) and simple 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 July 8, 2011.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Wing                      Expires July 8, 2011                  [Page 1]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   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.  Relationship of PCP Server and its NAT . . . . . . . . . . . .  7
   5.  Common Request and Response Header Format  . . . . . . . . . .  7
     5.1.  Request Header . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Response Header  . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Options  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Result Codes . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  General Operation  . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  General PCP Client Operation . . . . . . . . . . . . . . . 12
       6.1.1.  Generating and Sending a Request . . . . . . . . . . . 12
       6.1.2.  Processing a Response  . . . . . . . . . . . . . . . . 13
       6.1.3.  Multi-interface Issues . . . . . . . . . . . . . . . . 14
     6.2.  General PCP Server Operation . . . . . . . . . . . . . . . 14
   7.  Pinhole Operation  . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  OpCode Packet Format . . . . . . . . . . . . . . . . . . . 15
     7.2.  OpCode-Specific Result Codes . . . . . . . . . . . . . . . 18
     7.3.  OpCode-Specific Client Operation, Processing a Response  . 18
     7.4.  OpCode-Specific Server Operation . . . . . . . . . . . . . 19
       7.4.1.  Maintaining Same External IP Address . . . . . . . . . 20
       7.4.2.  Pinhole Lifetime . . . . . . . . . . . . . . . . . . . 21
       7.4.3.  Pinhole deletion . . . . . . . . . . . . . . . . . . . 21
       7.4.4.  Subscriber Identification  . . . . . . . . . . . . . . 22
       7.4.5.  Subscriber Renumbering . . . . . . . . . . . . . . . . 23
       7.4.6.  Disambiguating Remote Peer . . . . . . . . . . . . . . 23
     7.5.  PCP Options for PIN OpCodes  . . . . . . . . . . . . . . . 24
       7.5.1.  REMOTE_PEER_FILTER . . . . . . . . . . . . . . . . . . 24
       7.5.2.  REMOTE_PEER  . . . . . . . . . . . . . . . . . . . . . 25
       7.5.3.  HONOR_EXTERNAL_PORT  . . . . . . . . . . . . . . . . . 25
     7.6.  Interaction with Dynamic Connections . . . . . . . . . . . 26
     7.7.  Using PCP to Eliminate Application Keepalive Messages  . . 26
     7.8.  PCP Mapping State Maintenance  . . . . . . . . . . . . . . 27
       7.8.1.  Epoch  . . . . . . . . . . . . . . . . . . . . . . . . 27
       7.8.2.  Recreating Pinholes  . . . . . . . . . . . . . . . . . 28
       7.8.3.  Maintaining Pinholes . . . . . . . . . . . . . . . . . 29
     7.9.  Nested NATs  . . . . . . . . . . . . . . . . . . . . . . . 30



Wing                      Expires July 8, 2011                  [Page 2]

Internet-Draft         Port Control Protocol (PCP)          January 2011


     7.10. Pinhole Deletion . . . . . . . . . . . . . . . . . . . . . 30
     7.11. Pinhole Lifetime Extension . . . . . . . . . . . . . . . . 30
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 30
     8.1.  Dual Stack-Lite  . . . . . . . . . . . . . . . . . . . . . 30
       8.1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 31
       8.1.2.  Encapsulation Mode . . . . . . . . . . . . . . . . . . 31
       8.1.3.  Plain IPv6 Mode  . . . . . . . . . . . . . . . . . . . 31
     8.2.  NAT64  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     8.3.  NAT44 and NAT444 . . . . . . . . . . . . . . . . . . . . . 32
     8.4.  IPv6 Firewall  . . . . . . . . . . . . . . . . . . . . . . 32
   9.  Interworking with UPnP IGD 1.0 and 2.0 . . . . . . . . . . . . 32
     9.1.  UPnP IGD 1.0 with AddPortMapping Action  . . . . . . . . . 33
     9.2.  UPnP IGD 2.0 with AddAnyPortMapping Action . . . . . . . . 34
     9.3.  Lifetime Maintenance . . . . . . . . . . . . . . . . . . . 35
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 35
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
     11.1. PCP Server IP address  . . . . . . . . . . . . . . . . . . 35
     11.2. Port Number  . . . . . . . . . . . . . . . . . . . . . . . 36
     11.3. OpCodes  . . . . . . . . . . . . . . . . . . . . . . . . . 36
     11.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 36
     11.5. Options  . . . . . . . . . . . . . . . . . . . . . . . . . 36
   12. Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 37
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
     14.2. Informative References . . . . . . . . . . . . . . . . . . 38
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 39
     A.1.  Changes from draft-ietf-pcp-base-01 to -02 . . . . . . . . 39
     A.2.  Changes from draft-ietf-pcp-base-00 to -01 . . . . . . . . 40
   Appendix B.  Analysis of Techniques to Discover PCP Server . . . . 40
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42




















Wing                      Expires July 8, 2011                  [Page 3]

Internet-Draft         Port Control Protocol (PCP)          January 2011


1.  Introduction

   Port 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 small-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 rendezvous server
   specific to that game (or specific to that game developer), and a SIP
   phone would use a SIP proxy.  PCP does not provide this rendezvous
   function.


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], including a NAT and
      including a router behind the B4 element, and;

         [Ed.  Note: Do we want 'NAT behind the B4 element' in our
         scope?  This affects PCP server discovery, among other things.
         However, users deploy these NATs.  Do we want PCP to work with
         this, detect this, or quietly fail??  This is tracked as PCP
         Issues #1 and #25 [PCP-Issues].]

   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;




Wing                      Expires July 8, 2011                  [Page 4]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

2.2.  Supported Transport Protocols

   The PCP OpCodes defined in this document are designed to support
   transport protocols that use a 16-bit port number (e.g., TCP, UDP,
   SCTP, DCCP).  Transport protocols that do not use a port number
   (e.g., IPsec ESP) 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.

2.3.  Single-homed Customer Premise Network

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


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 or NAPT, the internal address and
         external address are different.  In the context of a firewall,
         the internal address and external address are different.  In
         both contexts, if an internal host is listening to connections
         on a specific port (that is, operating as a server), the
         external IP address and port number need to be port forwarded
         to the internal IP address and port number.  In the context of
         a NAPT, it is possible that both the IP address and port are
         modified.  For example with a NAPT, a webcam might be listening



Wing                      Expires July 8, 2011                  [Page 5]

Internet-Draft         Port Control Protocol (PCP)          January 2011


         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.

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

   PCP Client:

         A PCP software instance responsible for issuing PCP requests to
         a PCP Server.  One or several PCP Clients can be embedded in
         the same host.  Several PCP Clients can be located in the same
         local network of a given subscriber.  A PCP Client can issue
         PCP request on behalf of a third party device of the same
         subscriber.  An interworking function, from UPnP IGD to PCP, or
         from PCP to PCP (for nested NATs) is another example of a PCP
         client.

   PCP Server:

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

   Mapping:

         See also Port Forwarding.  A mapping exists only in the context
         of a Network Address Translator.  A NAT mapping creates a
         relationship between an internal IP transport address and an
         external IP transport address.  More specifically, it creates a
         translation rule where packets destined to the external IP and
         port are translated to the internal IP and port.

   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 functional element responsible for
      interworking another protocol with PCP.  For example interworking
      between UPnP IGD [IGD] with PCP.

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






Wing                      Expires July 8, 2011                  [Page 6]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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


4.  Relationship of PCP Server and its NAT

   The PCP server receives PCP requests.  The PCP server might be
   integrated within the NAT or firewall device (as shown in Figure 1)
   which is expected to be a common deployment.
                                  +-----------------+
         +------------+           | NAT or firewall |
         | PCP Client |-<network>-+                 +---<Internet>
         +------------+           |  with embedded  |
                                  |    PCP server   |
                                  +-----------------+

                 Figure 1: 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 2).  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>           | any suitable control protocol
     +------------+          \          v
                              \   +------------+
                               +--+ PCP Server |
                                  +------------+

                  Figure 2: NAT with Separate PCP Server


5.  Common Request and Response Header Format

   All PCP messages contain a request (or response) header, opcode-
   specific information, and (optional) informational elements.  The
   packet layout for the common header, and operation of the PCP client
   and PCP server are described in the following sections.  The
   information in this section applies to all OpCodes.  Behavior of
   specific OpCodes defined in this document is described in Section 7,
   and behavior of new OpCodes are described in their own documents
   following a similar format as in Section 7.





Wing                      Expires July 8, 2011                  [Page 7]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

                  Figure 3: Common Request Packet Format

   These fields are described below:

   Ver:  Version is 0

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

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

   OpCode:  Opcodes are defined in Figure 7.  More can be defined per
      rules described in Section 11.

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















Wing                      Expires July 8, 2011                  [Page 8]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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|R|   Opcode    |  Reserved     |  Result Code  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Epoch                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) OpCode-specific response data          :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :             (optional) Informational Elements                 :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: 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.

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

   OpCode:  The OpCode value from the request.

   Protocol:  Protocol field, echoed exactly from the request

   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.8.1 for discussion.

5.3.  Options

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




Wing                      Expires July 8, 2011                  [Page 9]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   Options use the following Type-Length-Value format:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option Code  |  Reserved     |       Option-Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                             data                              :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5: Options Header

   The description of the fields is as follows:

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

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

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

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

   A given Option MAY be included in a request.  An Option MUST NOT
   appear in a PCP response unless solicited in the associated request.
   If a given Option was included in a request, and understood and
   processed by the PCP server, it MUST be included in the response.
   The handling of an Option by the PCP Client and Server MUST be
   specified in a appropriate document and must include whether the PCP
   Option can appear (one or more times) in a request, and indicate the
   contents of the Option in the response.

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

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

   o  if the PCP server does not implement this Option, it MUST generate
      a failure response without including this Option in the response.

   o  If the PCP server does implement this Option, but cannot perform
      the function indicated by this Option, it MUST generate a failure
      response and include this Option (and its arguments) in the
      response.




Wing                      Expires July 8, 2011                 [Page 10]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

   If several Options are to be included in a PCP request or response,
   the Options MAY be encoded in any order by the PCP Client.  The
   response MUST encode them in the same order, but may omit some PCP
   Options in the response (e.g., to indicate the PCP server does not
   understand that Option, or that Option is not included in responses).
   A single Option MAY appear more than once, if permitted by the
   definition of the Option itself.  If the Option's definition allows
   the Option to appear only once, the PCP server MUST respond to such a
   PCP request with an error message [[which error?]]

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

   New Options MUST include the information below:

      This Option:

         name: <mnemonic>

         number: <value>

         purpose:

         is valid for OpCodes: <list of OpCodes>

         has length: <rules for length>

         appear more than once: <yes/no>

5.4.  Result Codes

   The following result codes may be returned as a result of any OpCode
   received by the PCP server.  Result codes are 8 bits long and the
   most significant bit indicates if the error is transient or
   permanent.  A transient error is one that might resolve itself, such
   that an identical PCP request submitted later would be successful
   (e.g., a resource is consumed and might become available later).  A
   permanent error is one that cannot reasonably be successful if an
   identical PCP request is submitted (e.g., re-sending a PCP request
   containing an OpCode the server does not support).  Future result
   codes should follow this same format.







Wing                      Expires July 8, 2011                 [Page 11]

Internet-Draft         Port Control Protocol (PCP)          January 2011


        0 - SUCCESS, success
      128 - UNSUPP_VERSION, unsupported version
      129 - UNSUPP_OPCODE, unsupported OpCode
      130 - UNSUPP_OPTION, unsupported Option
      131 - MALFORMED_OPTION, malformed Option (e.g., exists too many
            times, invalid length)
      132 - UNSPECIFIED_ERROR, server encountered unspecified error
      133 - MALFORMED_REQUEST

                        Figure 6: PCP Result Codes

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


6.  General Operation

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

6.1.  General PCP Client Operation

   This section details operation specific to a PCP client, for any
   OpCode.  Procedures specific to the PIN OpCodes are described in
   Section 7.

6.1.1.  Generating and Sending a Request

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

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

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

   3.  if the PCP working group decides an IANA-allocated address for
       the PCP server is suitable, it is added to the list of PCP
       servers, else;

   4.  the address of the default router, it is added to the list of PCP
       servers.



Wing                      Expires July 8, 2011                 [Page 12]

Internet-Draft         Port Control Protocol (PCP)          January 2011


      [Ed.  Note: more discussion around these methods is necessary to
      reach consensus on the best approach(es) for PCP.  Also see
      Appendix B for further analysis.  This is tracked as PCP Issue #1
      [PCP-Issues].]

   With that list of PCP servers, the PCP client formulates its PCP
   request.  The PCP request contains a PCP common header, PCP OpCode
   and payload, and optional Information Elements.  It initializes a
   retransmission timer to 4 seconds.  The PCP Client SHOULD be bound to
   one single UDP port which SHOULD be randomly generated as per
   [I-D.ietf-tsvwg-port-randomization].  When several PCP Clients are
   embedded in the same host, each uses a distinct port number to
   disambiguate their requests and replies.  The PCP client sends a PCP
   message to each server in sequence, waiting for a response until its
   timer expires.  Once a PCP client has successfully communicated with
   a PCP server, it continues communicating with that PCP server until
   that PCP server becomes non-responsive, which causes the PCP client
   to attempt to re-iterate the procedure starting with the first PCP
   server on its list.  If a hard ICMP error is received (e.g., port
   unreachable, network unreachable) the PCP client SHOULD immediately
   abort trying to contact that PCP server.  If no response is received
   from any of those servers, it doubles its retransmission timer and
   tries each server again.  This is repeated 4 times (for a total of 5
   transmissions to each server).  If, after these transmissions, no PCP
   server has responded the PCP client SHOULD abort the procedure.

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

6.1.2.  Processing a Response

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

   If it is an error response (>0), the request failed.  If the error
   response is less than 128, retrying the same request sometime in the
   future might be successful.  If the error response is greater or
   equal to 128, retrying the same request is unlikely to be successful.




Wing                      Expires July 8, 2011                 [Page 13]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   If it is the success response (0), the PCP client knows the request
   was successful.

6.1.3.  Multi-interface Issues

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

   IPv6 addresses with global reachability scope SHOULD be used as
   internal IP address when 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.

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

6.2.  General PCP Server Operation

   This section details operation specific to a PCP server.

   Upon receiving a PCP request message, the PCP Server parses and
   validates it.  Requests MUST be less than or equal to 1024 octets,
   and requests MUST be at least 8 octets.  Requests outside those
   limits are malformed and MUST result in a MALFORMED_REQUEST error.  A
   valid request contains a valid PCP common header, one valid PCP
   Opcode, and zero or more Options (which the server might or might not
   comprehend).  If an error is encountered during processing, the
   server generates an error response which is sent back to the PCP
   client.  Processing an OpCode and the Options are specific to each
   OpCode.

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






Wing                      Expires July 8, 2011                 [Page 14]

Internet-Draft         Port Control Protocol (PCP)          January 2011


7.  Pinhole Operation

   This document defines four OpCodes for forwarding ports and
   controlling dynamic connections.  These four OpCodes share a similar
   packet layout for requests and responses.  They are:


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

                             Figure 7: OpCodes

   These operation of these OpCodes is described in this section.

7.1.  OpCode Packet Format

   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 request's internal IP address and internal port fields both
   matche the response's external ip address and external port fields,
   the IP addresses and ports are not changed and thus the functionality
   is purely a firewall; otherwise it pertains to a network address
   translator which might also perform firewall functions.

   The following diagram shows the request packet format for PIN44,
   PIN46, PIN64, and PIN66.  This packet format is aligned with the
   response packet format:





















Wing                      Expires July 8, 2011                 [Page 15]

Internet-Draft         Port Control Protocol (PCP)          January 2011


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |          Reserved                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : 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 8: PIN OpCode Request Packet Format

   These fields are described below:

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

   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 MUST use 0.

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

   internal port:  Internal port for the pinhole.

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



Wing                      Expires July 8, 2011                 [Page 16]

Internet-Draft         Port Control Protocol (PCP)          January 2011


      doesn't have a preference, it MUST use 0.

   The following diagram shows the response 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Protocol     |          Reserved                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     : 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 9: PIN OpCode Response Packet Format

   These fields are described below:

   Protocol:  Copied from the request.

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

   Pinhole Internal IP address:  Copied from the 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







Wing                      Expires July 8, 2011                 [Page 17]

Internet-Draft         Port Control Protocol (PCP)          January 2011


7.2.  OpCode-Specific Result Codes

   In addition to the result codes described in Figure 6, the following
   additional result codes may be returned as a result of the four PIN
   OpCodes received by the PCP server.

     3 - NETWORK_FAILURE, e.g., NAT device has not obtained a DHCP lease
     4 - NO_RESOURCES, e.g., NAT device cannot create more mappings
         at this time.  This is a system-wide error, and different from
         USER_EX_QUOTA.
     5 - AMBIGUOUS, a dynamic connection already exists, and REMOTE_PEER
         was not included on the request to disambiguate the pinhole.
         If the client is attempting to query/control a dynamic
         connection, it should re-issue the request and include the
         REMOTE_PEER Option.
   150 - UNSUPP_PROTOCOL, unsupported Protocol
   151 - NOT_AUTHORIZED, e.g., PCP server supports mapping, but the
         feature is disabled for this PCP client, or the PCP client
         requested a pinhole that cannot be fulfilled by the PCP
         server's security policy.
   152 - USER_EX_QUOTA, mapping would exceed user's port quota
   153 - CANNOT_HONOR_EXTERNAL_PORT, indicates the port is already
         in use or otherwise unavailable (e.g., special port that
         cannot be allocated by the server's policy).  This error
         is only returned if the request included the Option
         HONOR_EXTERNAL_PORT.
   154 - UNABLE_TO_DELETE_ALL, indicates the PCP server was not able
         to delete all pinholes.
   155 - CANNOT_FORWARD_PORT_ZERO, indicates the requested external
         port 0 cannot be fulfilled, because the PCP-controlled
         device is a firewall.

              Figure 10: Result Codes specific to PIN OpCodes

   Other OpCodes are in result codes are defined following the procedure
   in Section 11.4.

7.3.  OpCode-Specific Client Operation, Processing a Response

   This section describes the operation of a client when sending the
   OpCodes PIN44, PIN64, PIN46, or PIN66.

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




Wing                      Expires July 8, 2011                 [Page 18]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

   If an unsuccessful result code greater than or equal to 128, the PCP
   client SHOULD NOT re-issue the same request.  If a result code less
   than or equal to 127, the PCP client MAY, if it wishes, resend the
   same message after a delay of at least 5 seconds.

7.4.  OpCode-Specific Server Operation

   This section describes the operation of a client when processing the
   OpCodes PIN44, PIN64, PIN46, or PIN66.

   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 properly
   formatted, and the associated pinhole (if present) is deleted, and a
   positive response is generated containing external port of 0 and
   lifetime of 0.  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 NOT_AUTHORZED result code.

      [Ed.  Note: Should we similarly return an error if attempting to
      delete mappings that were created dynamically (e.g., TCP SYN)?]
      This is tracked as PCP Issues #9 [PCP-Issues].]

   A client can request the explicit deletion of all its UDP or TCP
   mappings by sending a PCP request with a PIN OpCode 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 its PCP-controlled device 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 tool,
   the PCP server MUST still delete as many port mappings as possible,
   and respond with the result code UNABLE_TO_DELETE_ALL.

   The PCP Server MAY reduce the lifetime that was requested by the PCP
   Client.  The PCP Server SHOULD NOT offer a lease lifetime greater
   than that requested by the PCP Client.  See Section 7.4.2 for a
   discussion of lifetime.




Wing                      Expires July 8, 2011                 [Page 19]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   If the requested external port is 0, and the PCP-controlled device
   does not change port numbers (that is, it does not do port
   translation), it cannot fulfill the request.  In that case, the PCP
   server MUST return the response code CANNOT_FORWARD_PORT_ZERO.

   If the PCP-controlled device is stateless (that is, does not
   establish any per-flow state), the PCP server simply returns an
   answer, without creating any "pinholes".

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

   If a dynamic mapping already exists for the internal IP address and
   internal port, and the REMOTE_PEER option is not included in the
   request, it is impossible to establish a pinhole.  In such a case,
   the PCP server responds with the error AMBIGUOUS.  The client needs
   to choose a different internal port and send a new PCP request.

   By default, a PCP-controlled device MUST NOT create pinholes 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-
   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 result contains the same OpCode as the request, but with the
   "R" bit set.

   As a side-effect of creating a pinhole, ICMP messages associated with
   the pinhole are also translated (if appropriate) and forwarded.  This
   is done to ensure that ICMP messages can still be used by hosts,
   without application programmers or PCP client implementations needing
   to signal PCP separately to create ICMP pinholes for those flows.
   When the pinhole is deleted (or its lifetime expires), ICMP messages
   associated with the pinhole are no longer translated or forwarded.

7.4.1.  Maintaining Same External IP Address

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



Wing                      Expires July 8, 2011                 [Page 20]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

7.4.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 or until the PCP server
   loses its state (e.g., crashes).  This has interactions with
   dynamically-created mappings, see Sections Section 7.6.

   The PCP Client requests a certain lifetime, and the PCP Server
   responds with the assigned lifetime.  The PCP Server can minimize and
   maximize the requested lifetime.  The PCP server SHOULD be
   configurable for permitted minimum and maximum lifetime, and the
   RECOMMENDED values are 120 seconds for the minimum value and 24 hours
   for the maximum.  It is NOT RECOMMENDED that the server allow 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.

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

7.4.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
   another host for 120 seconds (MSL, [RFC0793]).

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








Wing                      Expires July 8, 2011                 [Page 21]

Internet-Draft         Port Control Protocol (PCP)          January 2011


7.4.4.  Subscriber Identification

   The PIN OpCodes require subscriber identification because they
   allocate resources to a subscriber.  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, a
   PCP client cannot 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 (e.g., /64), and that
      length must be configurable by the network operator.

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

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

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

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





Wing                      Expires July 8, 2011                 [Page 22]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   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.

7.4.5.  Subscriber Renumbering

   The customer premise router might obtain a new IP 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.

   When a new IP address is assigned to a host embedding a PCP Client,
   the NAT (or firewall) controlled by the PCP server will continue to
   send traffic to the old IP address.  Assuming the PCP client wants to
   continue receiving traffic, it needs to install new mappings.  The
   requested external port field will not be honored by the PCP server,
   in all likelihood, because it is still being forwarded to the old IP
   address.  Thus, the PCP client will assigned new port numbers.

7.4.6.  Disambiguating Remote Peer

   When operating a UDP or TCP server, one application is listening on a
   port and no other application will be assigned that port by the
   operating system.  However, ephemeral connections (that is, outgoing
   connections) to different servers can share the same ephemeral port,
   even between applications.  If a PCP request with a PIN OpCode is
   sent after such a dynamic connection is established (potentially by
   another application), the PCP server cannot reliable distinguish if
   the PIN request is referring to the current connection or to a new
   connection.  To eliminate this ambiguity, the remote peer's IP
   address and port can be specified in the REMOTE_PEER Option.

   This Option does not create or modify filtering on the NAT (for that,
   use REMOTE_PEER_FILTER) and have no effect on the NAT or firewall's
   normal filtering which will be any combination of Endpoint-
   Independent Filtering, Address-Dependent Filtering, or Address and
   Port-Dependent Filtering (these terms are originally defined and
   explained in [RFC4787]).



Wing                      Expires July 8, 2011                 [Page 23]

Internet-Draft         Port Control Protocol (PCP)          January 2011


7.5.  PCP Options for PIN OpCodes

7.5.1.  REMOTE_PEER_FILTER

   This Option indicates packet filtering is desired.  The remote peer
   port and remote peer IP Address indicate the permitted remote peer's
   source IP address and port for packets from the Internet.  That is,
   packets with a source IP address, transport, or port that do not
   match those fields of the PCP request are dropped by the PCP server-
   controlled NAT/firewall device.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved                   |   Remote Peer Port            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :     Remote Peer IP address (32 bits if PIN44 or PIN64,        :
     :              1 28 bits if PIN46 or PIN66)                     :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This Option:

         value: 128

         is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66

         is included in responses: MUST

         has length: 2 or 5

         may appear more than once: no

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

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





Wing                      Expires July 8, 2011                 [Page 24]

Internet-Draft         Port Control Protocol (PCP)          January 2011


7.5.2.  REMOTE_PEER

   Due to a per-existing dynamic mapping, a PCP server may not be able
   to instantiate a filter on a specific port.  It is thus recommended
   that applications bind to the source port (to prevent other
   applications from using that same source port) prior to using this
   PCP Option.

   In those situations, the Option REMOTE_PEER is necessary to
   disambiguate the mappings.  This option does not change filtering
   behavior of the NAT or firewall.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved                   |   Remote Peer Port            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :     Remote Peer IP address (32 bits if PIN44 or PIN64,        :
     :              1 28 bits if PIN46 or PIN66)                     :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This Option:

         value: 129

         is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66

         is included in responses: MUST

         has length: 2 or 5

         may appear more than once: no

7.5.3.  HONOR_EXTERNAL_PORT

   This option indicates the PCP client needs to have the indicated
   requested external port allocated.  If the PCP server cannot provide
   that port for the exclusive use of the PCP client, the PCP server
   MUST return result code CANNOT_HONOR_EXTERNAL_PORT.

   This option is intended for use by UPnP IGD interworking (Section 9).

      This Option:

         value: 130





Wing                      Expires July 8, 2011                 [Page 25]

Internet-Draft         Port Control Protocol (PCP)          January 2011


         is valid for OpCodes: PIN44, PIN64, PIN46, or PIN66

         is included in responses: MUST

         has length: 0

         may appear more than once: no

7.6.  Interaction with Dynamic Connections

   Dynamic connections are created by hosts sending a TCP or UDP packet
   across their NAT.  PCP can be used with such dynamic connections.
   There are two interesting cases: PCP before a dynamic connection, and
   PCP after a dynamic connection.

   If two applications on the same host communicate with different
   destinations, it is possible for them to be allocated the same
   ephemeral source port -- without either of the applications using the
   REUSEADDR socket option.  Thus, one application's use of PCP (to
   adjust the NAT or firewalls behavior) can affect an unrelated
   application on the same host.  This is why the four PIN OpCodes
   include the remote peer fields.  The remote peer fields allow the PCP
   server to disambiguate which mapping applies to the PIN OpCode
   message.

   Because PCP is not intended to adjust NAT behavior for dynamically-
   created connections, it is possible (and reasonable) for that second
   dynamic connection to be mapped to a different public port.  Even if
   that occurs, the other application can issue its own PCP request (to
   determine the mapping lifetime) following the same procedure
   described in this section.

7.7.  Using PCP to Eliminate Application Keepalive Messages

   Middleboxes such as NATs or firewalls need to see occasional traffic
   or will terminate their session state, causing application failures.
   To avoid this, many applications routinely generate keepalive traffic
   for the primary or sole purpose of maintaining state with such
   middleboxes.  Applications can avoid such application keepalive
   traffic by using PCP.

   To use PCP for this function, the applications first connects to its
   server, as normal.  Afterwards, it issues a PCP PIN request (PIN44,
   PIN64, PIN46, or PIN66, as appropriate) specifying the same 5-tuple
   as that connection in the PCP PIN request (internal IP address and
   port, transport protocol, and remote peer IP address and port), with
   the requested external address and requested external port fields
   both set to 0, and includes the REMOTE_PEER Option indicating the



Wing                      Expires July 8, 2011                 [Page 26]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   remote peer's IP address from the perspective of the PCP client.  The
   PCP response will indicate the lifetime for that session.

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

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

       int s = socket(...);
       connect(s, &remote_peer, ...);
       getsockname(s, &internal_address, ...);
       pcp_send_request(internal_address, 0, remote_peer, lifetime);
                /* external address is set to zero */

       Figure 11: Pseudo-code for using PCP to with a dynamic socket

7.8.  PCP Mapping State Maintenance

   If an event occurs that causes the PCP server 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.8.1.  Epoch

   Every PCP response sent by the PCP Server includes an Epoch field.
   This field increments by 1 every second, and indicates to the PCP
   client if PCP state needs to be restored.  If the PCP Server resets
   or loses the state of its port mapping table, due to reboot, power
   failure, or any other reason, it MUST reset its Epoch time to 0.
   Similarly, if the public IP address of the NAT (controlled by the PCP
   server) changes, the Epoch MUST be reset to 0.

   Whenever a client receives a PCP response, the client computes its
   own conservative estimate of the expected Epoch value by taking the



Wing                      Expires July 8, 2011                 [Page 27]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

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

7.8.2.  Recreating Pinholes

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

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

   A mapping renewal packet is formatted identically to an original
   mapping request; from the point of view of the client it is a renewal
   of an existing mapping, but from the point of view of the PCP server
   it appears as a new mapping request.

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

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



Wing                      Expires July 8, 2011                 [Page 28]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

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

   If the client wishes to check the PCP server's Epoch, it sends a PCP
   request for any one of the client's pinholes.  This will return the
   current Epoch value.  In that request the PCP client could extend the
   mapping lifetime (by asking for more time) or maintain the current
   lifetime (by asking for the same number of seconds that it knows are
   remaining of the lifetime).






Wing                      Expires July 8, 2011                 [Page 29]

Internet-Draft         Port Control Protocol (PCP)          January 2011


7.9.  Nested NATs

      [Ed.  Note: Nested NATs will be discussed in a later version of
      this document or, more likely, in a separate document.  The
      mechanism to support nested NATs is to have each NAT implement a
      PCP server (to service devices and NATs behind it) and a PCP
      client (to communicate with NATs above it).  This allows a PCP
      client to be unaware of the PCP communications going on between
      upstream NATs.]  This is tracked as PCP Issue #25 [PCP-Issues].]

7.10.  Pinhole Deletion

   A PCP Client can delete a pinhole immediately by sending the
   appropriate PIN OpCode with a lifetime of 0.  The PCP server responds
   by returning a PIN Response with a lifetime of 0.

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

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


8.  Deployment Scenarios

8.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 and is the
   local network's default router.







Wing                      Expires July 8, 2011                 [Page 30]

Internet-Draft         Port Control Protocol (PCP)          January 2011


8.1.1.  Overview

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

   1.  UPnP IGD and NAT-PMP 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 9.

   2.  Hosts behind the B4 element with either include a PCP client or
       UPnP IGD client.

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

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

   3.  The B4 element include a PCP Client which is invoked by an HTTP-
       based configuration (as is common today).  The internal IP
       address field in the PCP payload would be the internal host used
       in the port forwarding configuration.

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

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

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

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



Wing                      Expires July 8, 2011                 [Page 31]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   element.

8.2.  NAT64

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

   If the IANA-assigned IP address is used for the discovery of the PCP
   Server, that IPv4 address can be placed into the IPv6 destination
   address following that particular network's well-known prefix or
   network-specific prefix, per [RFC6052].

8.3.  NAT44 and NAT444

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

      [Ed.  Note: Does PCP need a mechanism to detect a non-PCP-
      supporting NAT between a PCP client and a PCP server?  Or can that
      problem be detected by relying on the failure of PCP Server
      Discovery?  This is tracked as PCP Issue #25 [PCP-Issues].]

8.4.  IPv6 Firewall

   See Section 7.5.1.

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


9.  Interworking with UPnP IGD 1.0 and 2.0

      [Ed.  Note: This UPnP IGD Interworking section will likely be
      moved to a separate document which will fully describe how a proxy
      needs to translate UPnP IGD messages into PCP messages.  This is
      tracked as PCP Issue #28 [PCP-Issues].]

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






Wing                      Expires July 8, 2011                 [Page 32]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

         Figure 12: Network Diagram, Interworking UPnP IGD and PCP

9.1.  UPnP IGD 1.0 with AddPortMapping Action

   In UPnP IGD 1.0 [IGD] it is only possible to request a specific port
   using the AddPortMapping action.  Requiring a specific port is
   incompatible with both (1) a large-scale NAT and with (2) widely-
   deployed applications.  Regarding (1), another subscriber is likely
   to already be using the same port, so it will be unavailable to this
   application to operate a server.  Regarding (2), if the same popular
   application exists on two devices behind the same NAPT, they cannot
   both get the same port.  PCP cannot correct this behavior of UPnP
   IGD:1, but PCP does work with this behavior.

   Due to this incompatibility with large-scale address sharing and
   popular applications, future hosts and applications will either
   support UPnP IGD 2.0's AddAnyPort method (see Section 9.2) or will
   support PCP.

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









Wing                      Expires July 8, 2011                 [Page 33]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   Message flow would be similar to this:

   UPnP Control Point             in-home CPE                 PCP server
         |                            |                           |
         |-UPnP:AddPortMapping(80)--->|                           |
         |                            |-PCP:request port 80------>|
         |                            | HONOR_EXTERNAL_PORT       |
         |                            |                           |
         |                            |<-PCP:error----------------|
         |<-UPnP: unavailable---------|                           |
         |                            |                           |
         |-UPnP:AddPortMapping(3213)->|                           |
         |                            |-PCP:request port 3213---->|
         |                            | HONOR_EXTERNAL_PORT       |
         |                            |                           |
         |                            |<-PCP:error----------------|
         |<-UPnP: unavailable---------|                           |
         |                            |                           |
        ...         ...              ...                         ...
         |                            |                           |
         |-UPnP:AddPortMapping(8921)->|                           |
         |                            |-PCP:request port 8921---->|
         |                            | HONOR_EXTERNAL_PORT       |
         |                            |                           |
         |                            |<-PCP:ok, port 8921--------|
         |<-UPnP: ok, port 8921-------|                           |
         |                            |                           |

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

9.2.  UPnP IGD 2.0 with AddAnyPortMapping Action

   If the UPnP IGD control point and the UPnP IGD interworking function
   both implement UPnP IGD 2.0 [IGD-2] and the UPnP IGD control point
   uses IGD 2's new AddAnyPortMapping action, only one round-trip is
   necessary.  This is because AddAnyPortMapping has semantics similar
   to PCP's semantics, allowing the PCP server to assign any port.













Wing                      Expires July 8, 2011                 [Page 34]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   Message flow would be similar to this:

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

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

9.3.  Lifetime Maintenance

   Neither UPnP IGD 1.0 nor 2.0 provide a lifetime.  Thus, the UPnP IGD/
   PCP interworking function is responsible for extending the lifetime
   of mappings that are still interesting to the UPnP IGD control point.

      Note: It can be an implementation advantage, where possible, for
      the UPnP IGD/PCP interworking function to request a port mapping
      lifetime only while that client is active and connected.  For
      example, creating a PCP mapping that is equal to the client's
      remaining DHCP lifetime is one useful approach.  The UPnP IGD/PCP
      interworking function is responsible for renewing the PCP lifetime
      as necessary.  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, as
      the server could be temporarily down when tested, causing a false
      negative.


10.  Security Considerations


11.  IANA Considerations

   IANA is requested to perform the following actions:

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



Wing                      Expires July 8, 2011                 [Page 35]

Internet-Draft         Port Control Protocol (PCP)          January 2011


   tracked as PCP Issue #8 [PCP-Issues].]

11.2.  Port Number

   Need a UDP port allocated.

11.3.  OpCodes

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

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

11.4.  Result Codes

   IANA shall create a new registry for PCP result codes, numbered
   0-255, initially populated with the result codes from both Figure 6
   and Figure 10.

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

11.5.  Options

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

   New information elements in the range 0-64 and 128-192 can be created
   via Standards Action [RFC5226], and the range 64-127 and 192-255 is
   for Private Use [RFC5226].




















Wing                      Expires July 8, 2011                 [Page 36]

Internet-Draft         Port Control Protocol (PCP)          January 2011


12.  Authors

   The following individuals contributed substantial text to this
   document and are listed in alphabetical order:
      Mohamed Boucadair
      France Telecom
      Email: mohamed.boucadair@orange-ftgroup.com

      Stuart Cheshire
      Apple Inc.
      1 Infinite Loop
      Cupertino, California 95014  USA
      Phone: +1 408 974 3207
      EMail: cheshire@apple.com

      Francis Dupont
      ISC
      Email: Francis.Dupont@fdupont.fr

      Reinaldo Penno
      Juniper Networks
      Email: rpenno@juniper.net



13.  Acknowledgments

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


14.  References

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



Wing                      Expires July 8, 2011                 [Page 37]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

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

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

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

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

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

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

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



Wing                      Expires July 8, 2011                 [Page 38]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

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

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

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

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

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.


Appendix A.  Changes

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

   o  more error codes

   o  PCP client source port number should be random

   o  PCP message minimum 8 octets, maximum 1024 octets.

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





Wing                      Expires July 8, 2011                 [Page 39]

Internet-Draft         Port Control Protocol (PCP)          January 2011


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

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

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

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

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

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

   o  Renamed Informational Elements (IE) to Options.

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

   o  Is NAT or router behind B4 in scope?

   o  PCP option MAY be included in a request, in which case it MUST
      appear in a response.  It MUST NOT appear in a response if it
      wasn't in the request.

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

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

   o  Epoch discussion simplified.


Appendix B.  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.  This is tracked as PCP Issue #8 [PCP-Issues].]

      Discussion Note: A deployment model is a non-PCP aware NAT in a
      home, and a PCP-aware large scale NAT (LSN) operated by the ISP.
      For example, the home users purchased a NAT last year at a
      computer shop (to extend their home's WiFi network).  This could



Wing                      Expires July 8, 2011                 [Page 40]

Internet-Draft         Port Control Protocol (PCP)          January 2011


      work by having the host use UPnP IGD with the in-home NAT, and the
      host use PCP with the LSN.  But this deployment model is
      impossible with several of the mechanisms below.  Is this
      deployment model important, or can we wait for PCP to be enabled
      on CPE?

   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.

   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



Wing                      Expires July 8, 2011                 [Page 41]

Internet-Draft         Port Control Protocol (PCP)          January 2011


             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.

   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.








Wing                      Expires July 8, 2011                 [Page 42]

Internet-Draft         Port Control Protocol (PCP)          January 2011


Author's Address

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

   Email: dwing@cisco.com










































Wing                      Expires July 8, 2011                 [Page 43]


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