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

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

Softwire working group                                           D. Wing
Internet-Draft                                                     Cisco
Intended status: Standards Track                                R. Penno
Expires: January 10, 2011                               Juniper Networks
                                                            M. Boucadair
                                                          France Telecom
                                                            July 9, 2010


                     Pinhole Control Protocol (PCP)
              draft-wing-softwire-port-control-protocol-02

Abstract

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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 10, 2011.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Wing, et al.            Expires January 10, 2011                [Page 1]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Deployment Scenarios . . . . . . . . . . . . . . . . . . .  4
     1.3.  Companion Documents  . . . . . . . . . . . . . . . . . . .  5
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Supported Transport Protocols  . . . . . . . . . . . . . .  5
     2.2.  Single-homed CP Routers  . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Port Forwarding  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  PCP Client . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  PCP Server . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  PCP Interworking Function  . . . . . . . . . . . . . . . .  7
   4.  PCP Server Discovery . . . . . . . . . . . . . . . . . . . . .  7
   5.  PCP Message Format . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  PCP Header . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  OpCodes  . . . . . . . . . . . . . . . . . . . . . . . . .  8
       5.2.1.  Pinhole Requests and Reponses  . . . . . . . . . . . .  9
       5.2.2.  Error Response . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Information Elements . . . . . . . . . . . . . . . . . . . 13
   6.  Processing Pinhole Requests and Responses  . . . . . . . . . . 13
     6.1.  Generating and Sending a Request . . . . . . . . . . . . . 14
     6.2.  Processing a Request and Generating the Response . . . . . 14
     6.3.  Processing a Response  . . . . . . . . . . . . . . . . . . 16
   7.  PCP Client Operation . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Pinhole Lifetime Extension . . . . . . . . . . . . . . . . 16
     7.2.  Pinhole Deletion . . . . . . . . . . . . . . . . . . . . . 16
     7.3.  Multi-interface Issues . . . . . . . . . . . . . . . . . . 17
     7.4.  Renumbering  . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  PCP Server Operation . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Pinhole Lifetime . . . . . . . . . . . . . . . . . . . . . 17
     8.2.  Pinhole deletion . . . . . . . . . . . . . . . . . . . . . 18
     8.3.  Subscriber Identification  . . . . . . . . . . . . . . . . 18
     8.4.  External IP Address  . . . . . . . . . . . . . . . . . . . 19
     8.5.  Policy Configuration . . . . . . . . . . . . . . . . . . . 20
   9.  Failure Scenarios  . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Host Reboot/PCP Client Failure . . . . . . . . . . . . . . 21
     9.2.  Provider NAT or PCP Server Reboot  . . . . . . . . . . . . 21



Wing, et al.            Expires January 10, 2011                [Page 2]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


     9.3.  PCP Proxy/PCP Interworking Function  . . . . . . . . . . . 21
   10. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Dual Stack-Lite  . . . . . . . . . . . . . . . . . . . . . 22
       10.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
       10.1.2. Encapsulation Mode . . . . . . . . . . . . . . . . . . 22
       10.1.3. Plain IPv6 Mode  . . . . . . . . . . . . . . . . . . . 23
     10.2. NAT64  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
     11.1. Forbidden Mapping Requests . . . . . . . . . . . . . . . . 24
     11.2. PCP Response Integrity . . . . . . . . . . . . . . . . . . 24
     11.3. Unwanted Deleting/Modification of Mappings . . . . . . . . 24
     11.4. Protection Against Creating Unwanted Mappings  . . . . . . 24
       11.4.1. DS-Lite  . . . . . . . . . . . . . . . . . . . . . . . 24
       11.4.2. NAT64  . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.5. Protection Against DoS Attacks . . . . . . . . . . . . . . 25
     11.6. Stale Mappings . . . . . . . . . . . . . . . . . . . . . . 25
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
     12.1. PCP IP address . . . . . . . . . . . . . . . . . . . . . . 25
     12.2. PCP Port Number  . . . . . . . . . . . . . . . . . . . . . 25
     12.3. PCP OpCodes  . . . . . . . . . . . . . . . . . . . . . . . 25
     12.4. PCP Error Codes  . . . . . . . . . . . . . . . . . . . . . 26
     12.5. PCP Information Elements . . . . . . . . . . . . . . . . . 26
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     14.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Analysis of Techniques to Discover PCP Server . . . . 28
   Appendix B.  DSCP Informational Element  . . . . . . . . . . . . . 30
     B.1.  Generation and Processing the DSCP IE  . . . . . . . . . . 31
     B.2.  DSCP Policy  . . . . . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32




















Wing, et al.            Expires January 10, 2011                [Page 3]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


1.  Introduction

1.1.  Protocol Overview

   Pinhole Control Protocol (PCP) provides a mechanism to control how
   incoming packets are forwarded by upstream devices such as NATs.  PCP
   is primarily designed to be implemented in the context of large scale
   NAT deployments.  Especially, it offers the ability to configure a
   port forwarding capability in Service Provider NATs.  Therefore,
   similar service features as per current CP (Customer Premises) router
   model can be offered to Customers who are serviced behind a Provider
   NAT.

   PCP allows applications to learn their external IP address and also
   to instantiate mappings in the PCP-controlled devices.  These
   mappings are required for successful inbound communications destined
   to machines located behind a large scale NAT
   [I-D.ford-shared-addressing-issues].  Owing to PCP, the overall
   performance of the Provider NAT would not be altered since PCP is a
   means to avoid enabling numerous ALGs (Application Level Gateways) in
   the CGN.  Because applications may learn their external reachability
   information, ALGs are de-activated for the configured mappings.  This
   behaviour would enhance the performance of PCP-controlled devices.

   The main design principles of PCP are as follows:

   o  address-family dependent; it can be used over IPv4 and IPv6, and
      for any transport protocol;

   o  lightweight on both the Client and Server;

   o  request/response protocol running over UDP;

   o  no permanent sessions are required to be maintained between the
      Client and the Server;

   o  client can be implemented within customer premise equipment (e.g.,
      a router), or by an application running on a host;

   o  allows opening ports on behalf of other devices belonging to the
      same (home) network such as a webcam or a webserver.

1.2.  Deployment Scenarios

   PCP can be used in various deployment scenarios, including:

   o  DS-Lite AFTR [I-D.ietf-softwire-dual-stack-lite]




Wing, et al.            Expires January 10, 2011                [Page 4]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   o  Stateful NAT64 [I-D.ietf-behave-v6v4-xlate-stateful]

   o  Stateless NAT64 [I-D.ietf-behave-v6v4-xlate]

   o  Large-Scale NAT44 [I-D.nishitani-cgn]

   o  Layer-2 aware NAT [I-D.miles-behave-l2nat]

   o  IPv6 firewall control [I-D.ietf-v6ops-cpe-simple-security]

1.3.   Companion Documents

   This document specifies the base PCP protocol.  Other documents are
   edited to elaborate on additional aspects such as:

   o  Interworking with UPnP-IGD
      [I-D.bpw-softwire-upnp-pcp-interworking].

   o  DHCP options to provision PCP Servers [I-D.bpw-softwire-pcp-dhcp].

   o  PCP flow examples [I-D.bpw-softwire-pcp-flow-examples].


2.  Scope

2.1.  Supported Transport Protocols

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

2.2.  Single-homed CP Routers

   The PCP machinery assumes a single-homed subscriber model.  That is,
   for a given IP version, only one default route exists to reach the
   Internet.  This restriction exists because otherwise there would need
   to be one PCP servers 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].



Wing, et al.            Expires January 10, 2011                [Page 5]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


3.1.  Port Forwarding

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

   In the context of a NAT with internal and external IP addresses, if
   an internal host is listening to connections on a specific port (that
   is, operating as a server), the external IP address and port number
   need to be port forwarded (also called "mapped") to the internal IP
   address and port number.  The internal and external IP addresses are
   different, and a key point is that the internal and external
   transport destination port numbers could be different.  For example,
   a webcam might be listening on port 80 on its internal address
   192.168.1.1, while its publicly-accessible external address is
   192.0.2.1 and port is 12345.  The NAT does 'port forwarding' of one
   to the other.

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

3.2.  PCP Client

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

3.3.  PCP Server

   A network element which receives and processes PCP requests from a
   PCP Client.  This element might be the same as the device embedding
   the controlled NAT (as shown in Figure 1) or might be a different
   element in the network which interacts with the NAT (e.g., using out-
   of-band XML, as shown in Figure 2).
                                  +-----------------+
         +------------+           | NAT or firewall |
         | PCP Client |-<network>-+                 +---<Internet>
         +------------+           |  with embedded  |
                                  |    PCP server   |
                                  +-----------------+

                 Figure 1: device with Embedded PCP Server









Wing, et al.            Expires January 10, 2011                [Page 6]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


                                  +-----------------+
                               +--+ NAT or firewall +---<Internet>
                              /   +-----------------+
     +------------+          /          ^
     | PCP Client +-<network>           | Interaction (e.g., using XML)
     +------------+          \          v
                              \   +------------+
                               +--+ PCP Server |
                                  +------------+

                  Figure 2: NAT with Separate PCP Server

3.4.  PCP Interworking Function

   A PCP Interworking Function denotes a functional element which is
   responsible for interworking PCP with another control protocol.  This
   interworking function functions as a PCP client towards the PCP
   server, and functions as a server towards the user's network.  For
   example, if interworking with UPnP IGD, the interworking function
   would appear as a UPnP IGD server
   [I-D.bpw-softwire-upnp-pcp-interworking].  Interworking other control
   protocols, or interworking with a customer premise router's HTTP
   configuration, would also be a PCP Interworking Function.


4.  PCP Server Discovery

   After considering several discovery mechanisms (Appendix A) we
   propose two mechanisms for the PCP client to discover its PCP server:

   o  a new DHCP option [I-D.bpw-softwire-pcp-dhcp]

   o  a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA.
      This is necessary in some expected environments, including

      *  where the customer premise NAT is unable to forward a new DHCP
         option to internal hosts,

      *  or where the OS running on internal hosts does not provide an
         API to request the new DHCP option.


5.  PCP Message Format

   PCP messages start with one PCP header, one OpCode, and zero or more
   Informational Elements.





Wing, et al.            Expires January 10, 2011                [Page 7]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


5.1.  PCP Header

   All PCP messages MUST begin with the following header.

      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|  RESERVED |S|    OpCode   |         OpCode-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Transaction-ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: PCP Generic Header

   The description of the fields is as follows:

   o  Ver: This 2 bit field indicates the PCP version.  The version
      defined in this document is version 0, and it MUST be set to 0.
      Other values, when received, generate an error.

   o  Reserved bits: These 6 bits are reserved for future use.  They
      MUST be zero when sending, and their value MUST be ignored when
      receiving.

   o  S bit, indicates request (0) or response (1).

   o  OpCode: Operation code, a 7 bit field.  Section 12.3 lists the
      OpCodes as defined in this document.

   o  Length: 16 bits.  Indicates the length of the OpCode Payload, in
      bytes.  After this offset start the Informational Elements, if
      any.  They contain their own length fields.

   o  Transaction-ID: 32 bits.  This transaction ID is randomly
      generated by the PCP Client for each new PCP Request;
      retransmitted requests use the same value.  The value of this
      field MUST be echoed by the PCP Server in the response.
      Transaction-ID allows several messages to be in flight between the
      PCP Client and PCP Server.

5.2.  OpCodes

   This section defines PCP OpCodes.  A request or response MUST contain
   one OpCode.  New OpCodes can be defined following the policy
   described in Section 12.3.






Wing, et al.            Expires January 10, 2011                [Page 8]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


5.2.1.  Pinhole Requests and Reponses

   The following OpCodes are defined and indicate if an IPv4 address (or
   IPv6 address) is provided in the request and its associated response:

   PIN44:   Pinhole IPv4 address and port to IPv4 address and port,
      which has an IPv4 address in the request and an IPv6 address in
      the response.

   PIN64:   Pinhole IPv6 address and port to IPv4 address and port,
      which has an IPv6 address in the request an IPv4 address in the
      response.

   PIN46:   Pinhole IPv4 address and port to IPv6 address and port,
      which has an IPv4 address in the request and an IPv6 address in
      the response.

   PIN66:   Pinhole IPv6 address and port to IPv6 address and port,
      which has an IPv6 address in the request and an IPv4 address in
      the response.

   These OpCodes all share the same OpCode format, shown below.  The
   difference is only the length of the IP address fields.

   +------------+--------------------------+---------------------------+
   |     PIN    |    Request Internal IP   |    Response External IP   |
   |   message  |          address         |          address          |
   +------------+--------------------------+---------------------------+
   |    PIN44   |           IPv4           |            IPv4           |
   |    PIN64   |           IPv6           |            IPv4           |
   |    PIN46   |           IPv4           |            IPv6           |
   |    PIN66   |           IPv6           |            IPv6           |
   +------------+--------------------------+---------------------------+

              Table 1: IP addresses in various PINxy messages
















Wing, et al.            Expires January 10, 2011                [Page 9]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :              Internal IP address (32 or 128 bits)             :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Proto     |W|R|   Reserved                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Requested Pinhole Lifetime (seconds)              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : Internal Port                 | Requested External Port       :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : Internal Port                 : Requested External Port       :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 4: PIN-REQUEST

   The description of the fields is as follows:

   o  Internal IP address

   o  Proto indicates the protocol, with values taken from IANA's
      protocol registry.

   o  The "W" bit indicates 'wildcard', which means 'any protocol', and
      the protocol value is meaningless when W is set.  When the W bit
      is set, the internal and external port numbers MUST NOT be
      included in the request.  The wildcard is intended to function
      similar to the "DMZ" function for IPv4 hosts or a firewall pinhole
      for IPv6 firewalls.

   o  The "M" bit indicates that mapping all of the Requested External
      Ports are mandatory; if any cannot be mapped, the transaction
      fails.

   o  Requested Pinhole Lifetime is the desired lifetime of this
      pinhole.

   o  Internal port indicates the internal host's port

   o  Requested external port indicates the requested external port.
      This is often the same as the internal port, or a popular port
      (e.g., TCP/80).

   Pairs of internal port and external port MAY be repeated, indicating
   the PCP client wishes to allocate several ports in one PCP request.
   This is an optimization to reduce chattiness of the protocol when
   several ports are needed by an application.




Wing, et al.            Expires January 10, 2011               [Page 10]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   Non-Error responses use the same OpCode and Transaction-ID as the
   associated request, set the S bit, and use 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :               Internal IP address (32 or 128 bits)            :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :               External IP address (32 or 128 bits)            :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Proto       |W|    Reserved                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Assigned Pinhole Lifetime in Seconds         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : Internal Port                 |    Assigned External Port     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : Internal Port                 |    Assigned External Port     :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 5: PIN-RESPONSE

   The description of the fields is as follows:

   o  Internal IP address of the host.  This is simply echoed from the
      request.

   o  External IP address of the pinhole.  If the PCP controlled element
      is a NAT, this value will differ from the internal IP address of
      the host.

   o  Proto indicates the protocol, which is echoed from the request.

   o  The "W" bit indicates 'wildcard', which means 'any protocol', and
      the protocol value is meaning less when this bit is set.  When the
      W bit is set, it means all traffic (no matter the protocol) is
      sent from the external IP address to the internal IP address.
      When the W bit is set, the internal port and external port MUST
      NOT be returned in the response.

   o  Assigned pinhole Lifetime is the lifetime of this pinhole, and may
      be greater or less than the requested pinhole lifetime.

   o  Internal port indicates the internal host's port, and is echoed
      from the request.

   o  External port indicates the assigned external port.  This MAY be
      different from the requested external port, especially on a busy
      NAT.



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

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


5.2.2.  Error Response

   This OpCode MUST only be present in a PCP response (that is, the S
   bit in the PCP header MUST be set).  If a PCP client or PCP server
   receives a request with this OpCode, it MUST be silently dropped.
   The PCP Server generates this response if a PCP request cannot
   successfully be processed.

      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 0 0 0 0 0|S|    OpCode   |         OpCode-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Transaction-ID                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Error Code                    | Error SubCode                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

                         Figure 6: Error response

   The following error codes are defined in this document.  For certain
   errors, additional information is in the error subcode.

   code    error subcode               meaning
   ----    ----------                  -----------
     1     highest supported version   unsupported PCP version
                                       (do we need this error code?)
     2     0                           user not authorized
     3     0                           (reserved)
     4     0                           out of resources
     5     OpCode received             unsupported OpCode
     6     transport protocol received unsupported transport protocol
     7     subscriber's port limit     subscriber port limit exceeded
     8     0                           parsing error
     9     0                           internal/external mismatch
    10     0                           other error
    11     0                           unsupported use of wildcard
    13     0                           cannot assign mandatory ports

                                 Figure 7

      Notes: error-code 7 indicates that 'available number of ports' can
      never be relied upon because its value depends on the port
      utilization of the NAT across all users and the number of sessions
      consumed by other applications running on the same computer or
      other computers belonging to the same subscriber.  As these are
      constantly changing, the value returned should only be considered
      a hint to the PCP client in determining the number of ports



Wing, et al.            Expires January 10, 2011               [Page 12]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


      available to PCP.  Also, the value returned does not necessarily
      have any relation with the number of ports available to the
      subscriber for dynamic forwarding, as it is expected some PCP
      servers and some NATs will permit only a subset of a subscriber's
      ports to be forwarded using PCP.

5.3.  Information Elements

   Information Elements (IE) MAY appear in requests and are associated
   with the request being sent.  If a PCP request contains several IEs,
   they MAY be encoded in any order in the request and MUST be encoded
   in the same order in the response.  If a PCP client or PCP server
   receives an IE it does not understand, or is malformed, it simply
   ignores the IE (as if that IE was not present); note this can cause a
   response to contain fewer IEs than the request if the PCP server does
   not understand an IE.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Information-Element-Code      |          IE-Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                            (data)                             :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: Informational Element header

   When a new IE is defined, it MUST cause the PCP server to generate an
   indication the IE was processed by the PCP server (e.g., by including
   an IE in the response).  For example, if the PCP server supported a
   newly-defined IE which provides descriptive text for a port mapping
   ("webcam on 4th floor"), the mapping would be created and the PCP
   server would respond with an IE indicating it included that
   descriptive text in the mapping.  New IEs MUST be registered with
   IANA following the procedure described in Section 12.5.

   One Information Element, for DSCP, is defined in Appendix B.


6.  Processing Pinhole Requests and Responses

   PCP messages MUST be sent over UDP, and the PCP Server MUST listen
   for PCP requests on the PCP-PORT port number (Section 12.2).

   Every PCP request generates a response, so PCP does not need to run
   over a reliable transport protocol.





Wing, et al.            Expires January 10, 2011               [Page 13]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


6.1.  Generating and Sending a Request

   To create a pinhole, the PCP client generates a PCP request for the
   appropriate address family of the internal host and the desired
   public mapping.  The PCP request contains a PCP header, PCP OpCode,
   and optional Information Elements.  Each of these elements contain a
   length and their own encoding.

   The PCP Client MAY request an external port matching the internal
   port.

   Once a PCP client has discovered its PCP Server (Section 4), and has
   prepared a PCP Request message for its PCP server, it tries
   communicating with the first PCP server on its list.  It initializes
   its retransmission timer, RETRY_TIMER, to the round trip time between
   the PCP client and PCP server.  If this value is unknown, 250ms is
   RECOMMENDED.  The PCP Client sends its PCP message to the server and
   waits RETRY_TIMER for a response.  If no response is received, it
   doubles the value of RETRY_TIMER, sends another (identical) PCP
   message with the same Transaction-ID, and waits again.  This
   procedure is repeated three times, doubling the value of RETRY_TIMER
   each time.  If no response is received, the PCP client tries with the
   next IP address in its list of PCP servers.  If it has exhausted its
   list, it SHOULD abort the procedure.  If, when sending PCP requests
   the PCP Client receives an ICMP error (e.g., port unreachable,
   network unreachable) it SHOULD immediately abort the procedure.  Once
   a PCP client has successfully communicated with a PCP server, it
   continues communicating with that PCP server until that PCP server
   becomes non-responsive, which causes the PCP client to attempt to re-
   iterate the procedure starting with the first PCP server on its list.

6.2.  Processing a Request and Generating the Response

   Upon receiving a PCP request message, it is parsed.  A valid request
   has the "S" bit cleared, contains a valid PCP header, one valid PCP
   Opcode, and optional Informational Elements (which the server might
   or might not comprehend).  If an error is encountered during
   processing, an error response (Section 5.2.2) is generated and
   immediately sent back to the PCP client.  This error response SHOULD
   include those IEs from the request that are understood by the server.

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




Wing, et al.            Expires January 10, 2011               [Page 14]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   If the requested lifetime is 0, it indicates the pinhole described by
   the internal IP address (and internal ports, if W is cleared) should
   be deleted; the requested external port is ignored by the server.  If
   such a pinhole exists, it is deleted and a positive response MUST be
   generated, echoing the information in the request.  If the "W" bit is
   set, it indicates all pinholes for the indicated internal IP address
   are to be deleted.  If the internal IP address is all zeros, it
   indicates that all pinholes for all hosts belonging to the subscriber
   are to be deleted for all protocols (if "W" is set) or the indicated
   protocol (if "W" is cleared).  For all cases with lifetime is 0, if
   such a pinhole does not exist, it could be because the pinhole was
   already deleted and the response was lost, so the same positive
   response (as described above) MUST be generated.

   If the requested lifetime is not 0, but a pinhole already exists for
   the indicated internal IP address (and port(s)), the PCP server
   replies with a successful response, as if this was a newly-created
   pinhole.  This can occur because the PCP client is either asking for
   a renewal of their lifetime, because the original response was lost,
   or because the PCP client has forgotten about its mapping (e.g.,
   application crashed) and it is requesting a mapping for the same
   internal IP address and internal port.

   If any of the requested external port number(s) is not available, and
   the "M" bit is set, the PCP-controlled device MUST NOT create any
   pinholes and MUST return an error code=13.

   If any of the requested external port number is not available, the
   PCP-controlled device MUST return an available external port number
   or, if no ports are available or the user has exhausted their port
   limit, return an error response.  If several ports were requested,
   but not all could be mapped, the PCP server MUST NOT map any of them,
   and MUST return an error code=7.

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

   By default, a PCP-controlled device MUST NOT create mappings for a
   protocol not indicated in the request; that is, 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 the companion port so the same PCP Client can map
   it in the future.

   If all of the proceeding operations were successful (did not generate



Wing, et al.            Expires January 10, 2011               [Page 15]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   an error response), then the requested pinholes are created as
   described in the request and a positive response is built.  This
   positive response contains the same OpCode and Transaction-ID as the
   request, sets the "S" bit, and uses the PIN-RESPONSE.  If multiple
   ports were in the request, they are all included in the response, in
   the same order, with their associated assigned external port numbers.
   If there were Informational Elements in the request, which the server
   understood and processed (as described by the documents that define
   those IEs), the necessary IE responses are included.  If there were
   IEs in the request, which the server did not understand, they are
   simply ignored as if they were not present.

6.3.  Processing a Response

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

   If it is an positive response, the PCP client knows the transaction
   was entirely successful and can use the external IP address and
   port(s) as desired.  Typically the PCP client will communicate the
   external IP address and port(s) to another host on the Internet using
   an application-specific mechanism.


7.  PCP Client Operation

   This section details operation specific to a PCP client.

7.1.  Pinhole Lifetime Extension

   An existing mapping can have its lifetime extended by the PCP client.
   To do this, the PCP client sends a new PCP map request to the server
   indicating the internal IP address and port(s).

   The PCP Client SHOULD renew the mapping before its expiry time,
   otherwise it will be removed by the PCP Server (see Section 8.2).  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).

7.2.  Pinhole Deletion

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



Wing, et al.            Expires January 10, 2011               [Page 16]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   responds by returning a PCP Map Response with a lifetime of 0.

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

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

7.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.2, 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.

7.4.  Renumbering

   The CP router might obtain a new IPv6 prefix, either due to a reboot,
   power outage, DHCPv6 lease expiry, or other action.  If this occurs,
   the ports reserved using PCP might be delivered to another customer.
   This same problem can occur if an IP address is re-assigned today,
   without PCP.  The solution is the same as today: don't re-assign IP
   addresses.  PCP provides a solution, as well: the PCP client can
   request the mappings be re-assigned to its new IP address, using the
   procedure described in Section 7.1.7.


8.  PCP Server Operation

   This section details operation specific to a PCP server.

8.1.  Pinhole Lifetime

   Once a PCP server has responded positively to a pinhole request for a
   certain lifetime, the PCP-controlled device (e.g., NAT, firewall)
   MUST keep that pinhole open for the duration of the lifetime that was



Wing, et al.            Expires January 10, 2011               [Page 17]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   indicated in the PCP response.  This is very much akin to how DHCP
   works today, in that an IP address assigned via DHCP can be used for
   the duration of the DHCP lease, but this is different from how other
   protocols (e.g., NAT-PMP) function where the NAT device is permitted
   to reboot and lose its pinholes.  This is by design, because the
   service provider-operated PCP server and PCP-controlled device are
   expected to have persistent storage so that pinholes are not
   forgotten upon failure of the PCP server or failure of the PCP-
   controlled device (e.g., NAT or firewall).

   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 (e.g., due to crash
   or power failure of the PCP client).  Other mechanisms, such as a web
   portal or even a publicly-routed IP address, are probably more
   appropriate for such long-duration mappings.

   The PCP server SHOULD be configurable for permeated minimum and
   maximum lifetime, and the RECOMMENDED values are 60 seconds for the
   minimum value and 24 hours for the maximum.

8.2.  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 MUST NOT assign that same external port to
   another client for 30 seconds, and SHOULD NOT assign it for 120
   seconds.

8.3.  Subscriber Identification

   A PCP Client can instruct mappings in a PCP-controlled device on
   behalf of a third party device (e.g., webcam).  In order to prevent a
   PCP Client to ask for mappings on behalf of a device belonging to
   another subscriber, the following rules are to be followed depending
   on the PCP-controlled device:

   o  If the PCP-controlled device is a NAT64: the internal IP address
      indicated in the PCP message and the source IPv6 address of
      received PCP request MUST belong to the same IPv6 prefix.  The
      length of the IPv6 prefix is the same as the length assigned to
      each subscriber on that particular network.

   o  If the PCP-controlled device is a DS-Lite AFTR: DS-Lite (Section
      11 of [I-D.ietf-softwire-dual-stack-lite]) already requires the
      tunnel transport source address be validated, and that same



Wing, et al.            Expires January 10, 2011               [Page 18]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


      address is used by PCP to assign the tunnel-ID to the requested
      mapping (see Section 10.1.2 and Section 10.1.3).  Thus, PCP
      acquires the same security properties as DS-Lite.  If address
      validation is implemented correctly, the PCP Client can not
      instruct mappings on behalf of devices of another subscriber.

   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., CGN facility) to only subscribed users should
   be supported by these devices.  Access control can be implicit or
   explicit:

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

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

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

   o  Allow access to the network resources;

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

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

   o  Legal requirements such as legal intercept or legal storage;

   o  Etc.

8.4.  External IP Address

   If there are active mappings for a particular PCP Client -- created
   via dynamic assignment or created by PCP -- subsequent mapping
   requests from that same PCP Client MUST use the same external IP
   address.  This is necessary because some protocols require using the
   same IP address for several ports.




Wing, et al.            Expires January 10, 2011               [Page 19]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


8.5.  Policy Configuration

   A PCP Server MAY be configured with various policies such as:

   o  Supported transport protocols;

   o  Ports to be excluded from the allocation process;

   o  Behaviour when a well-known port is requested: [[Note: A specific
      configuration: what to do when a PCP Client asks for a WKP but
      this port associated with the assigned external IP address (for
      dynamic mapping and not for configured mappings) is used but this
      port is available in other addresses.  This flexibility in the
      decision-making process of the PCP Server mitigates some of the
      limitations of sharing IP addresses.]]

   o  Maximum number of ports be assigned to that subscriber;

   o  Enable/disable port preservation; that means the PCP Server always
      assign the requested port number when that port is in not in use
      for the corresponding external IP address and transport protocol;

   o  Enable/disable port randomization;

   o  Enable/disable port range allocation policy;

   o  Enable/disable port parity preservation;

   o  Enable/disable port contiguity;

   o  Enable/disable DSCP re-marking;

   o  Enable/disable DSCP filtering;

   o  Enable/disable restricting remote IP address;

   o  Logging of PCP-mapped ports.

   PCP Server MUST be aware of the configured IPv4 address pool(s),
   ports in use, etc.  It is outside this document to specify how this
   information is known to the PCP Server.  This is implementation-
   specific.


9.  Failure Scenarios

   In the following sub-sections we discuss PCP failure scenarios.




Wing, et al.            Expires January 10, 2011               [Page 20]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


9.1.  Host Reboot/PCP Client Failure

   From a PCP Client perspective, several failure scenarios can be
   experienced by the host embedding that PCP Client (e.g., manual
   reboot, crashes, power outage, etc.).

   [[To be completed.  PCP client can request removal of its mappings
   (if any) and establish new mappings.]]

   If the PCP Client has instructed a PCP Server to create mappings on
   behalf of a third party (e.g., webcam device), any connectivity
   change occurred in that third party device requires updating its
   associated mappings.  Concretely, if a new IP address is assigned to
   that device: this change can be notified to the PCP Client by other
   means (e.g., the PCP Client is embedded in the same DHCP server which
   assigns IP addresses to internal hosts, administration GUI, etc.).
   In such case, the PCP Client MUST update the mapping with the new
   assigned internal IP address.

9.2.  Provider NAT or PCP Server Reboot

   The NAT operated by the Service Provider and the PCP Server are both
   expected to maintain PCP-initiated port mapping information in
   permanent storage, so a reboot will cause no loss of port mapping
   information.  Furthermore, If the NAT provides high availability
   (stateful switchover), it is RECOMMENDED that PCP-initiated port
   mappings be synchronized with the backup NAT device(s).

9.3.  PCP Proxy/PCP Interworking Function

   A failure/reboot of a device embedding a PCP Proxy or a PCP
   Interworking Function may lead to a change of the IP address of the
   external interface of that device and/or the loss of the mappings.
   The PCP Proxy or PCP Interworking Function behaves as follows
   according to its ability to recover locally installed mappings:

   o  Persistent storage of the mappings:

      *  Change of the IP address of the external interface of the PCP
         Proxy/PCP Interworking Function: the PCP Proxy/PCP Interworking
         Function MUST update all its associated mappings in the PCP
         Server (see Section 7.1);

      *  The same IP address is assigned to the external interface of
         the PCP Proxy/PCP Interworking Function: No action is to be
         undertaken by the PCP Proxy/PCP Interworking Function.





Wing, et al.            Expires January 10, 2011               [Page 21]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   o  Non-persistent storage of the mappings:

      *  The PCP Proxy MUST delete all pinholes the subscriber.


10.  Deployment Scenarios

10.1.  Dual Stack-Lite

10.1.1.  Overview

   Various PCP deployment scenarios can be considered to control an
   AFTR.

   1.  UPnP IGD and NAT-PMP are used in the LAN: an interworking
       function is required to be embedded in the CP router to ensure
       interworking between the protocol used in the LAN and PCP.  UPnP
       IGD-PCP Interworking Function is defined in
       [I-D.bpw-softwire-upnp-pcp-interworking].

   2.  Hosts behind the CP router embed a PCP Client, and communicate
       directly with the PCP server.  No interworking function is
       required to be embedded in the CP router.  In the LAN, the IP
       address to reach an external PCP Server or a local PCP Proxy is
       advertised to PCP Clients owing to one of the recommended methods
       in Section 4.

   3.  The CP router embeds a PCP Client invoked for HTTP-based
       configuration.  Indeed, PCP packets triggered by HTTP-based
       configuration would be crafted as described in Section 3.4.  The
       source IPv4 address would be the internal host used in the port
       forwarding configuration and the destination IPv4 address is
       provisioned owing to the one of the recommended methods in
       Section 4.  The UDP destination port number MUST be set to the
       IANA allocated destination port for PCP.

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

10.1.2.  Encapsulation Mode

   In this mode, CP router (B4) does no processing at all of the PCP
   messages, and forwards them as any other UDP traffic.  With DS-Lite,
   this means that PCP messages issued by internal PCP Clients are
   encapsulated in IPv6 packets and sent to the AFTR as for any other
   IPv4 packets.  The AFTR de-encapsulates the IPv4 packets and
   processes the PCP requests (because the destination IPv4 address



Wing, et al.            Expires January 10, 2011               [Page 22]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   points to the PCP Server embedded in the AFTR).

   Like for any other IPv4 packet received by the AFTR in the softwire
   tunnel, the source IPv6 address of the received IPv4-in-IPv6 PCP
   packet is stored by the PCP Server.

10.1.3.  Plain IPv6 Mode

   Another alternative for deployment of PCP in a DS-Lite context is to
   rely on a PCP Proxy in the CP router.  Protocol exchanges between the
   PCP Proxy and the PCP Server are conveyed using plain IPv6 (no
   tunnelling is used).  Nevertheless, the IPv6 address used as source
   address by the PCP Proxy MUST be the same as the one used by the B4
   element.  This IPv6 address is maintained by the PCP Server in its
   PCP mapping table.

10.2.  NAT64

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

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


11.  Security Considerations

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

   A PCP Client may open pinholes on behalf of devices belonging to the
   same administrative entity (e.g., residential customer, enterprise,
   etc.).  Nevertheless, a host belonging to subscriber A cannot open a
   pinhole for a host belonging to subscriber B (Section 11.4).

   The following sub-sections analyses how PCP mitigates some security
   issues that may be raised when using a tool to control a firewall or
   a NAT.




Wing, et al.            Expires January 10, 2011               [Page 23]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


11.1.  Forbidden Mapping Requests

   The PCP Server MUST NOT accept PCP requests from an Internet- facing
   interface, but only from subscribers belonging to the Service
   Provider.  Requests destined to one of the PCP-controlled device's
   external IP addresses MUST NOT be accepted by the PCP Server.

11.2.  PCP Response Integrity

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

   Upon receiving a PCP Map Create Response, the PCP Client MUST check
   if the included Internal IP address and Internal port numbers matches
   the ones includes in the PCP Map Create Request.  If not, the
   response is considered as invalid one (e.g., blind responses sent by
   a fake PCP Server) and it is ignored consequently.  In such case, the
   PCP Client has to issue its initial request.

11.3.  Unwanted Deleting/Modification of Mappings

   Removing or modifying an existing mapping in a PCP-controlled device
   would disturb and affect the successful delivery of wanted traffic to
   a legitimate subscriber.

11.4.  Protection Against Creating Unwanted Mappings

11.4.1.  DS-Lite

   In DS-Lite, the subscriber is identified by IPv6 address of their DS-
   Lite tunnel or an IPv6 prefix.  To prevent a subscriber from
   masquerading as another subscriber and using PCP to attract traffic
   to the victim, IPv6 source address validation is RECOMMENDED, as
   already suggested in Section 11 of
   [I-D.ietf-softwire-dual-stack-lite].

11.4.2.  NAT64

   In NAT64, subscribers are identified by their IPv6 prefix, whose
   length is determined by the network operator (e.g., /56 or /48).  The
   PCP server MUST be configured with the prefix-length, and uses that
   prefix-length to ensure the PCP request is for a host belonging to
   the same subscriber.







Wing, et al.            Expires January 10, 2011               [Page 24]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


11.5.  Protection Against DoS Attacks

   PCP Server may be subject to DoS attacks.  Therefore, PCP Servers
   SHOULD be protected against DoS attacks.

   A PCP Server may receive an excessive number of PCP messages from a
   PCP Client, in an effort to interfere with normal operation of the
   PCP Server.  In such a situation, the PCP Server MAY ignore messages
   from such misbehaving PCP clients.

11.6.  Stale Mappings

   Due to a change of IP address, a host may receive an unwanted traffic
   because the previous owner of that address has instructed some
   mappings in the PCP and didn't deleted them in a proper manner.  As a
   reminder, on today's Internet without an ISP-operated NAT,
   subscribers occasionally have their IPv4 addresses changed due to
   renumbering or because a service provider changes subscriber address
   (typically done to interfere with the subscriber operating a server).
   In those instances, traffic from the Internet is also sent to the
   previous address.  In the presence of PCP and a NAT, it is possible
   that subscribers behind a NAT would also have their IPv4 addresses
   changed, and also receive traffic from the Internet because the NAT
   is unaware that the subscriber's IPv4 address has changed.


12.  IANA Considerations

   IANA is requested to perform the following actions:

12.1.  PCP IP address

   Assign an IPv4 and an IPv6 address for PCP discovery.  This is
   denoted as PCP-IPV4 and PCP-IPV6 in this document.  [[RFC-Editor:
   please update occurrences with the IANA-assigned value.]]

12.2.  PCP Port Number

   IANA shall assign a UDP port number for PCP communication, preferably
   from the well-known port range (0-1023).  This is denoted as PCP-PORT
   in this document.

12.3.  PCP OpCodes

   Create a new protocol registry for PCP OpCodes populated with the
   following values:





Wing, et al.            Expires January 10, 2011               [Page 25]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   value   mnemonic
   -----   --------
       0   PIN44
       1   PIN64
       2   PIN46
       3   PIN66
     128   ERROR (only valid in responses)

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

12.4.  PCP Error Codes

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

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

12.5.  PCP Information Elements

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

   New information elements in the range 0-32768 can be created via
   Standards Action [RFC2434], new information elements in the range
   32769-64511 can be created with Expert Review [RFC2434], and the
   range 64512-65535 is for Private Use [RFC2434].


13.  Acknowledgments

   Thanks to Francis Dupont, Alain Durand, and C. Jacquenet for their
   comments and review.


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-20 (work in
              progress), May 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-11 (work in



Wing, et al.            Expires January 10, 2011               [Page 26]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


              progress), March 2010.

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

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

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

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

14.2.  Informative References

   [I-D.bpw-softwire-pcp-dhcp]
              Boucadair, M., Penno, R., and D. Wing, "DHCP and DHCPv6
              Options for Port Control Protocol (PCP)",
              draft-bpw-softwire-pcp-dhcp-01 (work in progress),
              May 2010.

   [I-D.bpw-softwire-pcp-flow-examples]
              Boucadair, M., Penno, R., and D. Wing, "PCP Flow
              Examples", draft-bpw-softwire-pcp-flow-examples-00 (work
              in progress), June 2010.

   [I-D.bpw-softwire-upnp-pcp-interworking]
              Boucadair, M., Penno, R., and D. Wing, "UPnP IGD-PCP
              Interworking Function",
              draft-bpw-softwire-upnp-pcp-interworking-00 (work in
              progress), May 2010.

   [I-D.ford-shared-addressing-issues]
              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing",
              draft-ford-shared-addressing-issues-02 (work in progress),
              March 2010.

   [I-D.ietf-behave-address-format]
              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-08 (work in progress),



Wing, et al.            Expires January 10, 2011               [Page 27]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


              May 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-12
              (work in progress), June 2010.

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

   [I-D.nishitani-cgn]
              Yamagata, I., Nishitani, T., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common requirements for IP address sharing
              schemes", draft-nishitani-cgn-04 (work in progress),
              March 2010.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

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


Appendix A.  Analysis of Techniques to Discover PCP Server

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

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

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

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




Wing, et al.            Expires January 10, 2011               [Page 28]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


          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
             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,



Wing, et al.            Expires January 10, 2011               [Page 29]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


       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 CGN device, load-
          based dimensioning, load-balancing, etc.) would require to
          update the zone configuration.  This would be a hurdle for the
          flexibility of the operational networks.  Adherence to DNS is
          not encouraged and means which allows for more flexibility are
          to be promoted.

          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.


Appendix B.  DSCP Informational Element

      [[Note: This Appendix may be moved into the main body of the PCP
      specification, or may be moved into a separate document.  It is
      currently here to show how an Informational Element can extend the
      functionality of PCP.]]

   PCP controls NAT and firewall devices which are typically at a
   network boundary where it is useful to map between different DSCP
   values.  This section describes an extension to the PCP base protocol
   to allow the PCP client to request special handling of Differentiated
   Services (DSCP [RFC2475]).

   Two scenarios are supported: all packets in a certain direction are
   remarked to a specific DSCP value (no matter their original DSCP
   value), and where certain DSCP values are remarked to other certain
   DSCP values.  In eiher situation, packets are forwarded (that is,
   packets not matching the indicated DSCP values are not dropped).

   If the PCP server supports the DSCP Informational Element, and it
   successfully installs the configuration into the controlled NAT or
   firewall device, it MUST include the same DSCP Informational Element
   in the PCP response.  In other cases it does not include hte DSCP IE



Wing, et al.            Expires January 10, 2011               [Page 30]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


   in the response, but still performs the pinhole control operation
   specified by the PCP message.

   The DSCP IE has the following syntax.  The value of the DSCP_IE_CODE
   is to be assigned.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | DSCP_IE_CODE                  |          IE-Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :DIR |inside DSCP| out DSCP  |      RESERVED (must be 0)        :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 9: Informational Element header

   Where DIR is encoded so its left bit indicate wildcard (1=wildcard)
   and its right bit indicates the direction of the mapping (0=inside to
   outside, 1=outside to inside).  Thus, 00 indicates a mapping of
   'inside DSCP' to 'outside DSCP' for packets from the inside to the
   outside, and 11 indicates a mapping of any DSCP value to 'insside
   DSCP' for packets from the outside to the inside.

   To establish multiple DSCP mappings the fields DIR, inside DSCP, out
   DSCP, and RESERVED MAY be repeated.  If both wildcards and specific
   mappings are provided, the behavior is not defined. [[do we want to
   define behavior?]]

B.1.  Generation and Processing the DSCP IE

   A PCP client MAY include the DSCP IE in any PINHOLE-REQUEST message.
   Multiple DSCP IEs MAY be included.

   When the PCP server processes the DSCP IE, the PCP server instructs
   the PCP-controlled device to install the indicated DSCP mappings.  If
   all of the mappings are installed successfully, the DSCP IE is echoed
   back to the PCP client exactly as it appeared in the request.  If all
   of mappings could not be installed successfully, the DSCP IE that is
   echoed contains only those DSCP mappings that were successfully
   installed (which might also mean none were successfully installed).

   Upon receipt of the PCP response, the PCP client knows all the
   requested DSCP mappings were successfully installed if the IE-length
   is the same as it sent.  If the IE-length was shorter, it indicates
   some of the mappings were not successfully installed.






Wing, et al.            Expires January 10, 2011               [Page 31]

Internet-Draft       Pinhole Control Protocol (PCP)            July 2010


B.2.  DSCP Policy

   A Service Provider MAY allow its customers to configure their DSCP
   marking policies in an upstream device.  Distinct DSCP marking
   policies can be implemented in th internal and external side of the
   controlled device.  A PCP Client MAY issue a PCP Map Create Request
   indicating its internal DS code point and the external DSCP value.

   PCP allows also to instruct forwarding policies only for packets
   marked with a given DSCP value.

   Note that a Service Provider may not support such feature and adopt a
   transparent scheme to QoS policy enforcement, that is, not
   controllable by subscribers.  Generic QoS enforcement policies can be
   enforced for all customers: such as leave DSCP field values
   unchanged.


Authors' Addresses

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

   Email: dwing@cisco.com


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

   Email: rpenno@juniper.net


   Mohamed Boucadair
   France Telecom
   Rennes,   35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com







Wing, et al.            Expires January 10, 2011               [Page 32]


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