[Docs] [txt|pdf] [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:  September 9, 2010                             Juniper Networks
                                                            M. Boucadair
                                                          France Telecom
                                                           March 8, 2010


                      Port Control Protocol (PCP)
              draft-wing-softwire-port-control-protocol-01

Abstract

   It is desirable to operate a server behind a device that does not
   normally permit operating a server, such as a carrier's NAT64, a
   carrier's NAT44 (including the AFTR element described in Dual-Stack
   Lite).  This document proposes an application-level protocol to allow
   a host to request opening a port in such an upstream device.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   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 September 9, 2010.



Wing, et al.            Expires September 9, 2010               [Page 1]

Internet-Draft         Port Control Protocol (PCP)            March 2010


Copyright Notice

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

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





































Wing, et al.            Expires September 9, 2010               [Page 2]

Internet-Draft         Port Control Protocol (PCP)            March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Scope and Requirements . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Port Forwarding  . . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Basic Port Forwarding  . . . . . . . . . . . . . . . .  6
       3.1.2.  Dynamic Port Forwarding  . . . . . . . . . . . . . . .  6
       3.1.3.  Port Forwarding and Redirection  . . . . . . . . . . .  6
   4.  Other Commonly-Deployed Port Reservation Mechanisms  . . . . .  6
     4.1.  Comparison . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Interoperation with Commonly-Deployed Port-Reservation
           Protocols  . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Port Control Protocol Functional Elements  . . . . . . . . . .  8
     5.1.  PCP Client . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  PCP Server . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  PCP Proxy  . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Discovery of PCP Server  . . . . . . . . . . . . . . . . . . .  9
   7.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Protocol and Packet Format . . . . . . . . . . . . . . . . 10
       7.1.1.  Requests and Responses . . . . . . . . . . . . . . . . 11
       7.1.2.  Requesting a Port Mapping  . . . . . . . . . . . . . . 12
       7.1.3.  Returning a Mapping  . . . . . . . . . . . . . . . . . 13
       7.1.4.  Destroying a Port Mapping  . . . . . . . . . . . . . . 15
       7.1.5.  List Port Mappings . . . . . . . . . . . . . . . . . . 16
       7.1.6.  PCP Server Availability  . . . . . . . . . . . . . . . 16
       7.1.7.  Modifying an Existing Mapping  . . . . . . . . . . . . 16
       7.1.8.  Result Codes . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  Interactions with Outgoing Sessions  . . . . . . . . . . . 17
   8.  Failure Scenarios  . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Host Reboot  . . . . . . . . . . . . . . . . . . . . . . . 18
     8.2.  CP router reboot . . . . . . . . . . . . . . . . . . . . . 18
     8.3.  NAT or PCP Server reboot . . . . . . . . . . . . . . . . . 18
   9.  PCP and Dual Stack-Lite  . . . . . . . . . . . . . . . . . . . 18
   10. PCP and NAT64  . . . . . . . . . . . . . . . . . . . . . . . . 19
   11. PCP IANA-Assigned Address  . . . . . . . . . . . . . . . . . . 19
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     15.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  PCP Implemented on a Host . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22







Wing, et al.            Expires September 9, 2010               [Page 3]

Internet-Draft         Port Control Protocol (PCP)            March 2010


1.  Introduction

   Port Control Protocol (PCP) provides a simple mechanism to request a
   TCP or UDP port from an upstream NAT (e.g., NAT64 or NAT44).  PCP can
   be implemented within customer premise equipment (e.g., a router), or
   by an application running on a host.  Such a protocol is necessary
   when deploying NATs (both NAT64 and NAT44), so that servers can be
   operated behind the NAT (e.g., webcam).


2.  Scope and Requirements

   PCP is not meant to be a general purpose NAT or Firewall port
   reservation protocol.  PCP has a very focused goal of allowing port
   reservation in the context of Dual-Stack Lite (DS-Lite,
   [I-D.ietf-softwire-dual-stack-lite]) which is an ISP-operated large
   scale NAT44 (LSN), NAT64 [I-D.ietf-behave-v6v4-framework].  Other
   scenarios are out of scope.

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

   1.   Lightweight protocol:  minimal reliability support, avoid
        maintaining permanent sessions between the client and the
        server.  In particular, the port control feature, when embedded
        in a carrier grade NAT, should not severely alter the overall
        performance of such devices;

   2.   Ability to service a large number of customers:  the protocol
        should be able to manage NAT mapping issued by terminals and
        machines located in premises of several thousands of customers;

   3.   Support IPv4 and IPv6.  In other words, the protocol semantics
        is independent of the IP version used for transport .  For
        example, a server can be reachable over plain IPv6 while the
        mapping request are related to an external IPv4 address/port
        number;

   4.   Extensible:  allows to gracefully define new objects and
        operations;

   5.   Ability to negotiate port mapping;

   6.   Ability to propose alternate port mapping when the requested
        port mapping is in use;

   7.   Ability to restrict the maximum number of mappings per user.
        This restriction can even be notified to a client so as to



Wing, et al.            Expires September 9, 2010               [Page 4]

Internet-Draft         Port Control Protocol (PCP)            March 2010


        prevent against overloading the server with huge port control
        requests;

   8.   Ability to detect if port control server is alive;

   9.   Ability to withdraw (delete) existing mapping;

   10.  Ability to indicate the transport protocol associated with a
        mapping;

   11.  Does not rely on a shared broadcast or multicast domain between
        the client requesting the mapping and the server providing the
        mapping;

   12.  For NATted environments (NAT44 and NAT64), allows the NAT to
        choose the public UDP/TCP port.  This is necessary in large-
        scale NAT environments where a port might be requested that is
        already in use;

   13.  Does not require modifying code in the application needing the
        incoming port.  Rather, another application on the same host or
        on a different host can open the port.  This permits, for
        example, a PC to use PCP to open ports for an IP-enabled webcam,
        and permits a CP router to open ports on behalf of devices
        behind the CP router; in those cases, the webcam or devices
        behind the CP router are manually configured to listen on
        necessary TCP or UDP port;

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

   15.  Does not support multihoming.


3.  Terminology

3.1.  Port Forwarding

   Port forwarding is normally used when several hosts behind a NAT
   device share a single external IP address.  If an internal host is
   listening to connections on a specific port (that is, operating as a
   server), the external IP and port need to be port forwarded (also
   called "mapped") to the internal IP address and port.  The key point



Wing, et al.            Expires September 9, 2010               [Page 5]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   is that the internal and external transport destination ports could
   be different; for example, a webcam might be listening on 192.168.1.1
   and TCP/80, but the public address is 192.0.2.1 and TCP/12345; the
   NAT does 'port forwarding' of one to the other.  This can be used in
   conjunction with dynamic DNS services and HTML frames to provide a
   reasonable service on the Internet[I-D.wing-behave-http-46-relay].

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

3.1.1.  Basic Port Forwarding

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

   Today, users typically configure basic port forwarding on their CP
   router using HTTP-based configuration.

3.1.2.  Dynamic Port Forwarding

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

3.1.3.  Port Forwarding and Redirection

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


4.  Other Commonly-Deployed Port Reservation Mechanisms

4.1.  Comparison

   This section compares commonly-deployed port reservation mechanisms
   to PCP.






Wing, et al.            Expires September 9, 2010               [Page 6]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   UPnP IGD 1.0:  IPv4 only.  Relatively complicated to implement in the
             UPnP IGD server, due to reliable HTTPU (HTTP over reliable
             UDP), XML, and UPnP's multicast discovery.

                       Note:  UPnP IGD version 2 [IGD-2] adds IPv6
                       support and the ability for the host ("control
                       point") to request the upstream NAT choose the
                       port.

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

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

4.2.  Interoperation with Commonly-Deployed Port-Reservation Protocols

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

   Scenario 1

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

               Figure 1: Scenario 1, CP router as PCP client










Wing, et al.            Expires September 9, 2010               [Page 7]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   Scenario 2

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

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

      Note regarding UPnP IGD:  UPnP IGD version 2 [IGD-2] adds the
      necessary AddAnyPortmapping API for this to work effectively.
      Without this new API, the host running UPnP IGD (which UPnP calls
      the 'control point') dictates the public port number; on a large
      NAT, that port number will likely already be used by another
      client.


5.  Port Control Protocol Functional Elements

   This section provides an overview on the main PCP functional
   elements.

5.1.  PCP Client

   A network element (including a host) that sends PCP requests to the
   PCP Server.

5.2.  PCP Server

   A network element which receives and processes PCP requests from a
   PCP Client.  This element might be the same as the NAT64 or NAT44 (as
   shown in Figure 3) 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 4).
                                +-------------+
                                | Dual-Stack  |
                +-----------+   |  Lite AFTR  |
                | PCP Client|---+             +--<Internet>
                +-----------+   |with embedded|
                                | PCP server  |
                                +-------------+

                  Figure 3: AFTR with Embedded PCP Server





Wing, et al.            Expires September 9, 2010               [Page 8]

Internet-Draft         Port Control Protocol (PCP)            March 2010


                                 +-------+
                              +--+ NAT44 +-------<Internet>
                             /   +-------+
     +-----------+          /          ^
     | PCP Client+---<network>         | interaction (e.g., using XML)
     +-----------+          \          v
                             \   +------------+
                              +==+ PCP server |
                                 +------------+

                  Figure 4: AFTR with Separate PCP Server

5.3.  PCP Proxy

   A IPv4-IPv6 PCP proxy can be proposed to avoid maintaining any state
   in the CP router to treat received PCP responses.

   All PCP messages are sent by the CP router using plain IPv6.  IPv4-
   Embedded IPv6 addresses are used for relaying PCP messages to the PCP
   Server.


6.  Discovery of PCP Server

      NOTE:  There are too many Discovery mechanisms listed here;
      analysis and consensus on the best discovery mechanism is
      necessary.

   The authors have considered several mechanisms for discovery of the
   PCP Server:

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

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

   3.  Service Location Protocol (SLP [RFC2608]).  SLP is supported in
       several platforms such as Linux Suse (mainly cupsd, rsyncd,
       ypserv, openldap2, ksysguardd, saned, kdm vnc login, smpppd,



Wing, et al.            Expires September 9, 2010               [Page 9]

Internet-Draft         Port Control Protocol (PCP)            March 2010


       rpasswd, postfix, and sshd), Solaris, Nevel, etc.

   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.

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


7.  Protocol

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

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

7.1.  Protocol and Packet Format

   [[Note-1:  need to mention if client wants multiple PCP transactions
   active at once, it uses different UDP source ports.]]

   [[Note-2:  change to a generic TLV, for easier extensibility?]]

   PCP runs over UDP, which keeps the protocol lightweight.  Reliability
   is achieved using retransmissions and a request/response protocol.
   Every packet starts with an 8 bit version followed by an 8 bit
   operation code (OpCode).

   This document specifies version 0 of the protocol.  Any PCP Server
   implementing this version of the protocol, receiving a packet with a
   version number other than 0, MUST return result code 1 (Unsupported
   Version), indicating the highest version number it does support
   (i.e., 0) in the version field of the reply.




Wing, et al.            Expires September 9, 2010              [Page 10]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   OpCodes between 0 and 127 are reserved for client requests.  Opcodes
   from 128 to 255 are reserved for server responses.  Responses always
   contain a 16 bit result code in network byte order.  A result code of
   zero indicates success.

   PCP Clients send their PCP requests to the address of their PCP
   Server (see Section 6 for a discussion).

7.1.1.  Requests and Responses

   [[Note-3:  discuss why no additional identifier is needed for DS-
   Lite]]

   [[Note-4:  should we add challange/response to protocol.  The main
   motivation for such feature is to prevent that third parties
   installs/deletes NAT entries.  A registration procedure can be
   envisaged at the bootstrapping of the PCP client/proxy and the PCP
   server to retrieve such security key to be used in subsequent PCP
   requests.  This feature can be configurable and not part of the
   mandatory features of the protocol.]]

   [[Note-5:  This key can be used to delete existing mapping when a new
   IPv6 prefix is assigned to the DS-Lite CP router otherwise these
   ports may not be used until their expiry]]

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

   As a performance optimization the PCP Client MAY record this
   information and use it to suppress further attempts to use PCP, but
   the client should not retain this information for too long.

   When deleting a port mapping, the client uses the same initial 250ms
   timeout, doubling on each successive interval, except that clients
   may choose not to try the full nine times before giving up.  This is
   because mapping deletion requests are in some sense advisory.  They
   are useful for efficiency, but not required for correctness; it is
   always possible for client software to crash, or for power to fail,
   or for a client device to be physically unplugged from the network



Wing, et al.            Expires September 9, 2010              [Page 11]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   before it gets a chance to send its mapping deletion request(s), so
   NAT gateways already need to cope with this case.  Because of this,
   it may be acceptable for a client to retry only once or twice before
   giving up on deleting its port mapping(s), but a client SHOULD always
   send at least one deletion request whenever possible, to reduce the
   amount of stale state that accumulates on NAT gateways.  A client
   need not continue trying to delete a port mapping after the time when
   that mapping would naturally have expired anyway.

7.1.2.  Requesting a Port Mapping

   To create a mapping, the PCP Client sends a UDP packet to the PCP
   server with 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Version = 0   |   OpCode = x  |  DSCP     |  reserved (0)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Internal IPv4 or IPv6 address                            |
     |      (32 or 128 bits, depending on value of OpCode)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Internal Port                 | Hinted External Port          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Requested Port Mapping Lifetime in Seconds                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OpCodes supported:

      1=Map IPv4 UDP

      2=Map IPv4 TCP

      3=Map IPv6 UDP

      4=Map IPv6 TCP

   [[Note-6:  Do we want to support multiple mapping requests in one
   message?]]

   The DSCP field indicates the DSCP value the NAT64 or NAT44 will
   remark incoming packets (packets towards the CP router).  Their
   effect on incoming packets is out of scope of this document.

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

   If the client would prefer to have a high-numbered "anonymous"



Wing, et al.            Expires September 9, 2010              [Page 12]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   external port assigned, then it should set the Requested External
   Port to zero, which indicates to the gateway that it should allocate
   a high-numbered port of its choosing.  If the client would prefer
   instead to have the mapped external port be the same as its local
   Internal Port if possible (e.g., a web server listening on port 80
   that would ideally like to have external port 80) then it should set
   the Hinted External Port to the desired value.  However, the gateway
   is not obliged to assign the hinted port, and may choose not to,
   either for policy reasons (e.g., port 80 is reserved and clients may
   not request it) or because that port has already been assigned to
   some other client.  Because of this, some product developers have
   questioned the value of having the Hinted External Port field at all.

   The RECOMMENDED Port Mapping Lifetime is 3600 seconds (one hour).

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

7.1.3.  Returning a Mapping

   Upon receiving a PCP request, the PCP Server creates a mapping in the
   NAT, and responds with the following PCP message:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Version = 0   | OP = 128 + x  | Result Code                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | External IP Address (IPv4)                                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Internal Port                 | Mapped External Port          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Port Mapping Lifetime in Seconds                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'x' in the OP (OpCode) field MUST match what the client
   requested.  A NAT gateway which implements this protocol MUST be able
   to create TCP-only and UDP-only port mappings.  If a NAT silently
   creates a pair of mappings for a client that only requested one
   mapping, the NAT is exposing that client to receiving inbound UDP
   packets or inbound TCP connection requests that it did not ask for
   and does not want.

   If the CP router is allocated fixed ports, the PCP Server simply
   returns a UDP or TCP port that allocated to the CP router.

   While a NAT gateway MUST NOT automatically create mappings for TCP



Wing, et al.            Expires September 9, 2010              [Page 13]

Internet-Draft         Port Control Protocol (PCP)            March 2010


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

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

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

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

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

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

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

   The PCP Client SHOULD begin trying to renew the mapping before its



Wing, et al.            Expires September 9, 2010              [Page 14]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   expiry time.  Renewing halfway to expiry time is RECOMMENDED.
   Nevertheless, in the context of large scale deployment mapping
   renewal should not be so that frequent to avoid altering the
   performance of the CGN.  This may be a configurable feature in the
   PCP.  The renewal packet should look exactly the same as a request
   packet, except that the PCP Client SHOULD set the requested external
   port to what the PCP server previously returned, not what the client
   originally requested.

7.1.4.  Destroying a Port Mapping

   A mapping may be destroyed in a variety of ways.  If a PCP Client
   fails to renew a mapping, then when its lifetime expires the mapping
   MUST be automatically deleted.  In the case where PCP is being
   proxied from another protocol (e.g., UPnP IGD), the CP router device
   is a combined DHCP server and NAT gateway, when a client's DHCP
   address lease expires, the gateway device MAY automatically delete
   any mappings belonging to that client.  Otherwise a new client being
   assigned the same IP address could receive unexpected inbound UDP
   packets or inbound TCP connection requests that it did not ask for
   and does not want.

   [[Note:  for DS-Lite, a change of IPv6 prefix should lead to update
   existing mappings to point to the newly assigned IPv6 address of B4]]

   A PCP Client MAY also send an explicit packet to request deletion of
   a given mapping.  A PCP Client requests explicit deletion of a
   mapping by sending a message to the PCP Server with the Requested
   Lifetime in Seconds set to 0.  The requested external port MUST be
   set to zero by the client on sending, and MUST be ignored by the
   gateway on reception.

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

   If the deletion request was unsuccessful (such as attempting to
   delete a mapping that doesn't exist on the NAT), the response MUST
   contain a non-zero result code and the requested mapping; the
   lifetime is undefined (MUST be set to zero on transmission, and MUST



Wing, et al.            Expires September 9, 2010              [Page 15]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   be ignored on reception).  If the client attempts to delete a port
   mapping which was manually assigned by some kind of configuration
   tool, the PCP Server MUST respond with a 'Not Authorized' error,
   result code 2.

   A PCP Client can request the explicit deletion of all its UDP or TCP
   mappings by sending the same deletion request to the PCP Server with
   external port, internal port, and lifetime set to 0.  A client MAY
   choose to do this when it first acquires a new IP address in order to
   protect itself from port mappings that were performed by a previous
   owner of the IP address.  After receiving such a deletion request,
   the gateway MUST delete all its UDP or TCP port mappings (depending
   on the OpCode).  The PCP Server responds to such a deletion request
   with a response as described above, with the internal port set to
   zero.  If the gateway is unable to delete a port mapping, for
   example, because the mapping was manually configured by the
   administrator, the gateway MUST still delete as many port mappings as
   possible, but respond with a non-zero result code.  The exact result
   code to return depends on the cause of the failure.  If the gateway
   is able to successfully delete all port mappings as requested, it
   MUST respond with a result code of 0.

7.1.5.  List Port Mappings

   PCP Client requests all port mappings belonging to that PCP Client
   (as maintained by the PCP Server).

7.1.6.  PCP Server Availability

   A PCP Client can determine if its PCP Server is responsive by sending
   a message with a PCP version number 0.  The PCP Server will respond
   with the version number it supports.

7.1.7.  Modifying an Existing Mapping

   A PCP Client can modify an existing mapping by destroying the
   previous mapping and creating a new mapping.

7.1.8.  Result Codes

   Currently defined result codes:

      0 - Success

      1 - Unsupported Version

      2 - Not Authorized/Refused




Wing, et al.            Expires September 9, 2010              [Page 16]

Internet-Draft         Port Control Protocol (PCP)            March 2010


      (e.g., box supports mapping, but the feature has been disabled)

      3 - [[deleted]]

      4 - Out of resources

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

      5 - Unsupported OpCode

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



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

   PCP Clients MUST be able to properly handle result codes not defined
   in this document.  Undefined results codes MUST be treated as fatal
   errors of the request.

7.2.  Interactions with Outgoing Sessions

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


8.  Failure Scenarios

   In the following sections we discuss a few failure scenarios and
   associated procedures for resolution.




Wing, et al.            Expires September 9, 2010              [Page 17]

Internet-Draft         Port Control Protocol (PCP)            March 2010


8.1.  Host Reboot

   If a end host is manually rebooted, crashes or otherwise becomes
   unresponsive, it may use the following procedure to resolve any state
   conflicts in the NAT device.

   1.  It sends a request a request for all port forwarding mappings for
       its IP address present in the NAT device.  If it determines based
       on some mechanism that some of these mappings are still usable,
       it might keep them, otherwise it can proceed to deletion

   2.  It sends a requests to delete all mappings assocaited with its IP
       address.

   A CP router that implements UPnP or NAT-PMP and is acting as a PCP
   proxy can follow the same procedure on behalf of the end hosts if it
   detects such critical events whether through UPnP, NAT-PMP or some
   other method.

8.2.  CP router reboot

   If the CP router is not a NAT, no PCP state needs to be kept in the
   CP router, therefore a reboot of the CP router should not affect PCP.
   If the CP router is a NAT and the CP router contains dynamic port
   forwarding entries in volatile memory reboots, it will need to
   install any new port forwarding mappings requested by the end hosts
   in the upstream PCP Server and ideally get rid of the old ones.

   Barring some keep-alive mechanism between CP router and PCP Server,
   or some out-of-band event notification, the PCP Server will continue
   forwarding ports to the CP router.  If there is WAN address reuse
   across CP routers (that is, between subscriber devices), the NAT's
   port forwarding mappings would forward unwanted traffic to the new CP
   router.

8.3.  NAT or PCP Server reboot

   With PCP, the NAT operated by the service provider and the PCP server
   are both expected to retain PCP-initiated port mapping information in
   permanent storage, so a reboot will cause no loss of port mapping
   information.


9.  PCP and Dual Stack-Lite

   In the case of Dual Stack-Lite deployments, PCP packets triggered by
   HTTP-based configuration would be crafted as described in Section 7
   and encapsulated in IPv4.  The source IPv4 would be the internal host



Wing, et al.            Expires September 9, 2010              [Page 18]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   used in the port forwarding configuration and the destination IPv4 is
   based on the decision of Section 6.  The UDP destination port MUST be
   set to the IANA allocated destination port for PCP.  Then, the PCP
   request is encapsulated in an IPv6 packet following RFC2473 and sent
   to the softwire concentrator (which is called "AFTR" in Dual-Stack
   Lite).  The AFTR de-capsulates the IPv4 packet and processes the PCP
   packet.

   Another alternative for deployment of PCP in DS-Lite context is to
   rely on a PCP Proxy in the CP router.  Protocol exchange between the
   PCP Proxy and the PCP Server are conveyed using plain IPv6 (no
   tunneling is used).  Nevertheless, the IPv6 address used by the PCP
   Proxy MUST be the same as the one used to mount the IPv6 interface of
   the B4 element.


10.  PCP and 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 in "Discovery" (Section 6) we choose to have an IANA-assigned IP
   address for discovery of the PCP Server, that IPv4 address can be
   placed into the IPv6 destination address following that particular
   network's well-known prefix or network-specific prefix, per
   [I-D.ietf-behave-address-format].


11.  PCP IANA-Assigned Address

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

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


12.  Security Considerations

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



Wing, et al.            Expires September 9, 2010              [Page 19]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   webserver.  Thus, security is no worse by allowing an application to
   open other arbitrary ports.


13.  Acknowledgements

   The protocol described in this document used NAT-PMP
   [I-D.cheshire-nat-pmp] (Stuart Cheshire, Marc Krochmal, Kiren Sekar)
   as a model, and considered the Service Provider extensions from SP-
   NAT-PMP [I-D.woodyatt-spnatpmp-appl] (James Woodyatt) .  Our thanks
   to authors of those documents.


14.  IANA Considerations

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

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


15.  References

15.1.  Normative References

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

15.2.  Informative References

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

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

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

   [I-D.ietf-softwire-dual-stack-lite]



Wing, et al.            Expires September 9, 2010              [Page 20]

Internet-Draft         Port Control Protocol (PCP)            March 2010


              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.

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

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

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

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

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [UPnP-IGD]
              UPnP Forum, "Universal Plug and Play Internet Gateway
              Device", 2000,
              <http://www.upnp.org/standardizeddcps/igd.asp>.


Appendix A.  PCP Implemented on a Host

   NOTE:  This is for future study.

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










Wing, et al.            Expires September 9, 2010              [Page 21]

Internet-Draft         Port Control Protocol (PCP)            March 2010


   Scenario 3

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

                     Figure 5: CPE router unaware PCP


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
   3, Av Francois Chateaux
   Rennes,   35000
   France

   Email:  mohamed.boucadair@orange-ftgroup.com












Wing, et al.            Expires September 9, 2010              [Page 22]


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