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

Abstract

Port Control Protocol is an address-family independent mechanism to control how incoming packets are forwarded by upstream devices such as network address translators (NATs) and simple IPv6 firewalls.

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on June 6, 2011.

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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
2.  Scope
    2.1.  Deployment Scenarios
    2.2.  Supported Transport Protocols
    2.3.  Single-homed Customer Premise Network
3.  Terminology
4.  PCP Server Discovery
5.  Common Request and Response Header Format
    5.1.  Request Header
    5.2.  Response Header
    5.3.  Information Elements
    5.4.  Result Codes
6.  OpCodes
    6.1.  PIN OpCodes
7.  PCP Mapping State Maintenance
    7.1.  Epoch
    7.2.  Recreating Pinholes
    7.3.  Maintaining Pinholes
    7.4.  Nested NATs
8.  Processing Pinhole Requests and Responses
    8.1.  Generating and Sending a Request
    8.2.  Processing a Request and Generating the Response
    8.3.  Processing a Response
9.  PCP Client Operation
    9.1.  Pinhole Lifetime Extension
    9.2.  Pinhole Deletion
    9.3.  Multi-interface Issues
    9.4.  Renumbering
10.  PCP Server Operation
    10.1.  Relationship of PCP Server and its NAT
    10.2.  Pinhole Lifetime
    10.3.  Pinhole deletion
    10.4.  Subscriber Identification
    10.5.  External IP Address
11.  Deployment Scenarios
    11.1.  Dual Stack-Lite
        11.1.1.  Overview
        11.1.2.  Encapsulation Mode
        11.1.3.  Plain IPv6 Mode
    11.2.  NAT64
    11.3.  NAT44 and NAT444
    11.4.  IPv6 Firewall
12.  Adjacent Port Procedure
13.  Interworking with UPnP IGD
    13.1.  UPnP IGD 1.0 with AddPortMapping Action
    13.2.  UPnP IGD 2.0 with AddAnyPortMapping Action
    13.3.  Lifetime Maintenance
14.  Security Considerations
15.  IANA Considerations
    15.1.  PCP Server IP address
    15.2.  Port Number
    15.3.  OpCodes
    15.4.  Result Codes
    15.5.  Information Elements
16.  Authors
17.  Acknowledgments
18.  References
    18.1.  Normative References
    18.2.  Informative References
Appendix A.  Analysis of Techniques to Discover PCP Server
§  Author's Address

1.  Introduction

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

PCP allows applications to create pinholes from an external IP address to an internal IP address and port. If the PCP-controlled device is a NAT, a mapping is created; if the PCP-controlled device is a firewall, a pinhole is created in the firewall. These pinholes are required for successful inbound communications destined to machines located behind a NAT.

After creating a pinhole for incoming connections, it is necessary to inform remote computers about the IP address and port for the incoming connection. This is usually done in an application-specific manner. For example, a computer game would use a rendzevous server specific to that game (or specific to that game developer), and a SIP phone would use a SIP proxy. PCP does not provide this rendezvous function.

2.  Scope

2.1.  Deployment Scenarios

PCP can be used in various deployment scenarios, including:

• DS-Lite (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.) [I‑D.ietf‑softwire‑dual‑stack‑lite], and;
• NAT64, both Stateful (Bagnulo, M., Matthews, P., and I. Beijnum, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,” July 2010.) [I‑D.ietf‑behave‑v6v4‑xlate‑stateful] and Stateless (Li, X., Bao, C., and F. Baker, “IP/ICMP Translation Algorithm,” September 2010.) [I‑D.ietf‑behave‑v6v4‑xlate], and;
• Large-Scale NAT44 (Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, “Common requirements for IP address sharing schemes,” October 2010.) [I‑D.ietf‑behave‑lsn‑requirements], including nested NATs ("NAT444"), and;
• Layer-2 aware NAT (Miles, D. and M. Townsley, “Layer2-Aware NAT,” March 2009.) [I‑D.miles‑behave‑l2nat] and Dual-Stack Extra Lite (Arkko, J. and L. Eggert, “Scalable Operation of Address Translators with Per-Interface Bindings,” October 2010.) [I‑D.arkko‑dual‑stack‑extra‑lite], and;
• IPv6 firewall control (Woodyatt, J., “Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service,” October 2010.) [I‑D.ietf‑v6ops‑cpe‑simple‑security].

2.2.  Supported Transport Protocols

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

In this document, only TCP and UDP are defined.

2.3.  Single-homed Customer Premise Network

The PCP machinery assumes a single-homed subscriber model. That is, for a given IP version, only one default route exists to reach the Internet, much as there is only one default route for a dynamic connection (e.g., TCP SYN) towards the Internet. This restriction exists because otherwise there would need to be one PCP server for each egress, because the host could not reliably determine which egress path packets would take.

3.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Port Forwarding:

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

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

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

PCP Client:

A PCP software instance responsible for issuing PCP requests to a PCP Server. One or several PCP Clients can be embedded in the same host. Several PCP Clients can be located in the same local network of a given subscriber. A PCP Client can issue PCP request on behalf of a third party device of the same subscriber.

PCP Server:

A network element which receives and processes PCP requests from a PCP Client. See also Section 10.1 (Relationship of PCP Server and its NAT).

Mapping:

In the context of Network Address Translation a mapping creates a relationship between an internal IP transport address and an external IP transport address. More specifically, it creates a translation rule where packets destined to the external IP and port are translated to the internal IP and port.

Mapping Types:

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

Interworking Function:

A PCP Interworking Function denotes a functional element which is responsible for another protocol with PCP, for example interworking with UPnP IGD (UPnP Gateway Committee, “WANIPConnection:1,” November 2001.) [IGD] described in Section 13 (Interworking with UPnP IGD).

4.  PCP Server Discovery

There are several possible methods to discover a PCP Service:

• sending the PCP message to the default router. This requires the default router to support PCP.
• a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA. This follows the same routing path as other Internet-bound traffic.

  [Ed. Note: For an IPv4 address, would the AFTR element's IPv4 address, 192.0.0.1 [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.), be suitable as this address for DS-Lite deployments? Would that same address be suitable for all PCP deployment scenarios?]

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

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

5.  Common Request and Response Header Format

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

5.1.  Request Header

All requests have the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve|     OpCode    |    Protocol   |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Reserved (32 bits)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:             (optional) opcode-specific information            :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:             (optional) Informational Elements                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These fields are described below:

Ver:

Version is 1

reserve:

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

OpCode:

defined in Figure 5 (OpCodes).

Protocol:

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

Reserved:

The reserved fields MUST be sent as 0 and MUST be ignored when received.

5.2.  Response Header

All responses have the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve|  Opcode+128   |    Protocol   |  Result Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Epoch                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:             (optional) OpCode-specific response data          :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:             (optional) Informational Elements                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These fields are described below:

Ver:

Version is 1

reserve:

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

OpCode+128:

The OpCode value from the request plus 128.

Protocol:

Protocol field, echoed exactly from the request

Result Code:

The result code for this response. See Section 5.4 (Result Codes) for values.

Epoch:

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

5.3.  Information Elements

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

IEs use the following Type-Length-Value format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   IE Code     | Reserved      |          IE-Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                             data                              :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The description of the fields is as follows:

IE Code:

IE codes MUST be registered with IANA following the procedure described in Section 15.5 (Information Elements).

Reserved:

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

IE-Length:

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

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

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

If several IEs are to be included in a PCP request or response, IEs MAY be encoded in any order by the PCP Client or the PCP Server.

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

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

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

5.4.  Result Codes

The following response codes are defined:

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

Additional result codes are defined following the procedure in Section 15.4 (Result Codes).

6.  OpCodes

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

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

6.1.  PIN OpCodes

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                    Reserved (always 160 bits)                 |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
: Pinhole Internal IP address (32 or 128, depending on OpCode)  :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
: Requested external IP address (32 or 128, depending on OpCode):
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Requested lifetime                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        internal port          |   requested external port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These fields are described below:

Reserved:

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

Pinhole Internal IP Address:

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

Requested External IP Address:

Requested external IP address. This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP server can fulfill the request, it will do so. If the PCP client doesn't know the external address, or doesn't have a preference, it MAY place any value into this field including 0. If the Pinhole Internal IP Address equals the Requested External IP Address, it indicates the PCP client wants firewall (versus NAT) behavior.

Requested lifetime:

Requested lifetime of this pinhole, in seconds.

internal port:

Internal port for the pinhole.

requested external port:

requested external port.

internal port:

Internal port for the pinhole, copied from request.

Assigned external port:

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

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP Request Address Family    |    PCP Request Port           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            PCP Request IP Address (always 128 bits)           |
|                (first 32 bits are XOR'd)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
: Pinhole Internal IP address (32 or 128, depending on OpCode)  :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
: Assigned external IP address (32 or 128, depending on OpCode) :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Assigned lifetime                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       internal port           |    assigned external port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These fields are described below:

PCP Request Address Family:

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

PCP Request Port:

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

PCP Request IP Address:

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

Pinhole Internal IP address

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

Assigned external IP address

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

Assigned Lifetime

Lifetime for this mapping, in seconds

internal port

Internal port for the pinhole, copied from request.

Assigned external port

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

7.  PCP Mapping State Maintenance

If an event occurs that causes the PCP server and NAT to lose state (such as a crash or power outage), the pinholes created by PCP are lost. Such loss of state is rare in a service provider environment (due to redundant power, disk drives for storage, etc.). But such loss of state is more common in a residential NAT device which does not write information to its non-volatile memory.

The Epoch indicates if the PCP server has lost its state. If this occurs, the PCP client can attempt to recreate the pinholes following the procedures described in this section.

7.1.  Epoch

Every packet sent by the PCP Server includes a "Seconds since start of epoch" field (SSSOE). The PCP Server MUST set its Epoch time to zero when it is ready to accept new connections. If the PCP Server resets or loses the state of its port mapping table, due to reboot, power failure, or any other reason, it MUST reset its epoch time and begin counting SSSOE from 0 again. Whenever a client receives any packet from the PCP Server, either gratuitously or in response to a client request, the client computes its own conservative estimate of the expected SSSOE value by taking the SSSOE value in the last packet it received from the gateway and adding 7/8 (87.5%) of the time elapsed since that packet was received. If the SSSOE in the newly received packet is less than the client's conservative estimate by more than one second, then the client concludes that the NAT gateway has undergone a reboot or other loss of port mapping state, and the client MUST immediately renew all its active port mapping leases as described in Section 7.2 (Recreating Pinholes).

7.2.  Recreating Pinholes

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

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

A mapping renewal packet is formatted identically to an original mapping request; from the point of view of the client it is a renewal of an existing mapping, but from the point of view of the freshly-rebooted NAT gateway it appears as a new mapping request.

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

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

Without this automatic recreation of soft state in the NAT gateway, reliable long-term networking would not be achieved. As mentioned above, the reliability of the Internet does not come from trying to build a perfect network in which errors never happen, but from accepting that in any sufficiently large system there will always be some component somewhere that's failing, and designing mechanisms that can handle those failures and recover. To illustrate this point with an example, consider the following scenario: Imagine a network security camera that has a web interface and accepts incoming connections from web browser clients. Imagine this network security camera uses NAT-PMP or a similar protocol to set up an inbound port mapping in the NAT gateway so that it can receive incoming connections from clients the other side of the NAT gateway. Now, this camera may well operate for weeks, months, or even years. During that time it's possible that the NAT gateway could experience a power failure or be rebooted. The user could upgrade the NAT gateway's firmware, or even replace the entire NAT gateway device with a newer model. The general point is that if the camera operates for a long enough period of time, some kind of disruption to the NAT gateway becomes inevitable. The question is not whether the NAT gateway will lose its port mappings, but when, and how often. If the network camera and devices like it on the network can detect when the NAT gateway has lost its port mappings, and recreate them automatically, then these disruptions are self-correcting and largely invisible to the end user. If, on the other hand, the disruptions are not self-correcting, and after a NAT gateway reboot the user has to manually reset or reboot all the other devices on the network too, then these disruptions are *very* visible to the end user. This aspect of the design is what makes the difference between a protocol that keeps on working indefinitely over a time scale of months or years, and a protocol that works in brief testing, but in the real world is continually failing and requiring manual intervention to get it going again.

When a client renews its port mappings as the result of receiving a packet where the "Seconds since start of epoch" field (SSSoE) indicates that a reboot or similar loss of state has occurred, the client MUST first delay by a random amount of time selected with uniform random distribution in the range 0 to 5 seconds, and then send its first port mapping request. After that request is acknowledged by the gateway, the client may then send its second request, and so on, as rapidly as the gateway allows. The requests SHOULD be issued serially, one at a time; the client SHOULD NOT issue multiple requests simultaneously in parallel.

[Ed. Note: the paragraph above is copied from NAT-PMP, and seems to be advice specific to receiving asynchronous notification that the Epoch was reset. Asynchronous notification needs the delay described (in fact, it probably needs greater delay than 0-5 seconds if on a larger network) and also needs to discourage sending multiple PCP requests serially. However, PCP does not have asynchronous notification (yet), and has different needs/requirements for pacing. In short: the above paragraph needs some discussion.]

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

7.3.  Maintaining Pinholes

A PCP client can refresh a pinhole by sending a new PCP request containing information from the earlier PCP response. The PCP server will respond indicating the new lifetime. It is possible, due to failure of the PCP server, that the public IP address and/or public port, or the PCP server itself, has changed (due to a new route to a different PCP server). To detect such events more quickly, the PCP client may find it beneficial to use shorter lifetimes (so that it communicates with the PCP server more often). If the PCP client has several pinholes, the Epoch value only needs to be retrieved for one of them to verify the PCP server has not lost port forwarding state.

7.4.  Nested NATs

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

Note: this provides a function similar to STUN (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) [RFC5389]. Being integrated within PCP itself provides the advantage of checking the path to the PCP server, which may be a different path than to the STUN server.

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

8.  Processing Pinhole Requests and Responses

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

8.1.  Generating and Sending a Request

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

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

8.2.  Processing a Request and Generating the Response

Upon receiving a PCP request message, the PCP Server parses and validates it. A valid request contains a valid PCP common header, one valid PCP Opcode, and optional Informational Elements (which the server might or might not comprehend). If an error is encountered during processing, an error response is generated and sent back to the PCP client.

After successful parsing of the message, the PCP server validates that the internal IP address in the PCP request belongs to that subscriber. This validation depends on the deployment scenario; see Section 10.4 (Subscriber Identification). 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.

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

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

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

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

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

By default, a PCP-controlled device MUST NOT create mappings for a protocol not indicated in the request. For example, if the request was for a TCP mapping, a UDP mapping MUST NOT be created. Nevertheless, a configurable feature MAY be supported by the PCP-controlled device, which MAY reserve (but not forward) the companion port so the same PCP Client can request it in the future.

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

8.3.  Processing a Response

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

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

9.  PCP Client Operation

This section details operation specific to a PCP client.

9.1.  Pinhole Lifetime Extension

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

The PCP Client SHOULD renew the mapping before its expiry time, otherwise it will be removed by the PCP Server (see Section 10.3 (Pinhole deletion)). In order to prevent excessive PCP chatter, it is RECOMMENDED to renew only 60 seconds before expiration time (to account for retransmissions that might be necessary due to packet loss, clock synchronization between PCP client and PCP server, and so on).

9.2.  Pinhole Deletion

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

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

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

9.3.  Multi-interface Issues

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

IPv6 addresses with global reachability scope SHOULD be used as internal IP address when instructing a PCP mapping in a PCP-controlled device. IPv6 addresses with limited scope (e.g., ULA), SHOULD NOT be indicated as internal IP address in a PCP message.

As mentioned in Section 2.3 (Single-homed Customer Premise Network), only mono-homed CP routers are in scope. Therefore, there is no viable scenario where a host located behind a CP router is assigned with two GUA addresses belonging to the same global IPv6 prefix.

9.4.  Renumbering

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

10.  PCP Server Operation

This section details operation specific to a PCP server.

10.1.  Relationship of PCP Server and its NAT

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

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

However, it is useful to also model a separation of the PCP server from the NAT, as shown below (Figure 9 (NAT with Separate PCP Server)). The PCP server would communicate with the NAT using a protocol beyond the scope of this document, such as a proprietary protocol or any suitable standard protocol for NAT control).

                             +-----------------+
                          +--+ NAT or firewall +---<Internet>
                         /   +-----------------+
+------------+          /          ^
| PCP Client +-<network>           | suitable NAT control protocol
+------------+          \          v
                         \   +------------+
                          +--+ PCP Server |
                             +------------+

10.2.  Pinhole Lifetime

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

It is NOT RECOMMENDED that the server allow long lifetimes (exceeding 24 hours), because they will consume ports even if the internal host is no longer interested in receiving the traffic or no longer connected to the network.

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

10.3.  Pinhole deletion

A pinhole MUST be deleted by the PCP Server upon the expiry of its lifetime, or upon request from the PCP client.

In order to prevent another subscriber from receiving unwanted traffic, the PCP server SHOULD NOT assign that same external port to another host for 120 seconds (MSL, [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.)).

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

10.4.  Subscriber Identification

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

• Allow access to the network resources;
• Configure service profiles such as a bandwidth and/or port usage quotas for fairness service usage among all subscribers;
• Blacklist a subscriber because of abuse or non-payment of service fee, etc.
• Legal requirements such as legal intercept or legal storage.

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

• 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.
• If the PCP-controlled device is a DS-Lite AFTR: DS-Lite (Section 11 of [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.)) already requires the tunnel transport source address be validated, and that same address is used by PCP to assign the tunnel-ID to the requested mapping (see Section 11.1.2 (Encapsulation Mode) and Section 11.1.3 (Plain IPv6 Mode)). 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.
• If CGN with a routed network, each subscriber has one IPv4 address and all PCP requests MUST be sent from only that IP address and MUST only open pinholes towards its own IP address.

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

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

10.5.  External IP Address

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

11.  Deployment Scenarios

11.1.  Dual Stack-Lite

The interesting components in a Dual-Stack Lite deployment are the B4 element (which is the customer premise router) and the AFTR element (which is the device that both terminates the IPv6-over-IPv4 tunnel and also implements the large-scale NAT44 function). The B4 element does not need to perform a NAT function (and usually does not perform a NAT function), but it does operate its own DHCP server.

11.1.1.  Overview

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

1. UPnP IGD and NAT-PMP are used in the LAN: an interworking function is required to be embedded in the B4 element to ensure interworking between the protocol used in the LAN and PCP. UPnP IGD-PCP Interworking Function is described in Section 13 (Interworking with UPnP IGD).
2. Hosts behind the B4 element include a PCP Client, and communicate directly with the PCP server. No interworking function is required to be embedded in the B4 element.
3. The B4 element include a PCP Client which is invoked by an HTTP-based configuration (as is common today). The internal-IP-address in the PCP payload would be the internal host used in the port forwarding configuration.

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

[Ed. Note: We need to decide on Encapsulation Mode or Plain IPv6 Mode.]

11.1.2.  Encapsulation Mode

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

11.1.3.  Plain IPv6 Mode

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

11.2.  NAT64

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

If the IANA-assigned IP address is used for the discovery of the PCP Server, that IPv4 address can be placed into the IPv6 destination address following that particular network's well-known prefix or network-specific prefix, per [RFC6052] (Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, “IPv6 Addressing of IPv4/IPv6 Translators,” October 2010.).

11.3.  NAT44 and NAT444

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

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

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

11.4.  IPv6 Firewall

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

12.  Adjacent Port Procedure

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

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

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

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

13.  Interworking with UPnP IGD

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

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

13.1.  UPnP IGD 1.0 with AddPortMapping Action

In UPnP IGD 1.0 (UPnP Gateway Committee, “WANIPConnection:1,” November 2001.) [IGD] it is only possible to request a specific port using the AddPortMapping action. Requesting a specific port is incompatible with both (1) a large-scale NAT and with (2) successful applications. Regarding (1), other subscribers are likely to also be running the same application, all demanding (or desiring) the same port number. Regarding (2), a popular application will exist on multiple devices within the home. Thus, PCP is not designed to optimize for this behavior of requesting a particular port as it cannot work well in address sharing environments; but PCP will work with this behavior using the suggested procedure below.

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

To interwork from UPnP IGD to PCP, our recommendation is that every UPnP request be forwarded to the PCP server -- this works no matter if the UPnP IGD control point is randomizing or incrementing each port number when its requests fail. When a requested port assignment fails, most UPnP IGD control points will retry the port assignment requesting the next higher port or requesting a random port. In either case, the described procedure will work. The UPnP IGD/PCP interworking function would request very short leases (e.g., 5 seconds) in order to avoid the chatter of a Delete message (lifetime=0). Once a port can be allocated, its lifetime is extended. When interworking with UPnP IGD, the in-home CPE limits itself to sending one PCP message a second, which ensures there are only 5 outstanding PCP reservations at a time; this avoids consuming all of that subscriber's NAT mappings while trying to find an available port via the UPnP IGD->PCP interworking function).

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

Message flow would be similar to this:

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

13.2.  UPnP IGD 2.0 with AddAnyPortMapping Action

If the UPnP IGD control point and the UPnP IGD interworking function both implement UPnP IGD 2.0 (UPnP Gateway Committee, “Internet Gateway Device (IGD) V 2.0,” September 2010.) [IGD‑2] and the UPnP IGD control point uses the IGD 2's new AddAnyPortMapping message, only one round-trip is necessary. This is because AddAnyPortMapping has semantics similar to PCP's semantics, allowing the PCP server to assign any port.

13.3.  Lifetime Maintenance

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

Note: It can be an implementation advantage, where possible, for the UPnP IGD/PCP interworking function to request a port mapping lifetime only while that client is active and connected. For example, creating a PCP mapping that is equal to the client's remaining DHCP lifetime is one useful approach. The UPnP IGD/PCP interworking function is responsible for renewing the PCP lifetime as necessary. As long as client renews its DHCP lease, the PCP lifetime should also be extended. For clients not using DHCP, other mechanisms to check on the client host's liveliness can also be useful (e.g., ping, ARP, or WiFi association) can be used to discern liveliness of the UPnP IGD control point. However, it is NOT RECOMMENDED to attempt to connect to the TCP or UDP port opened on the control point to determine if the host still wants to receive packets; the server could be temporarily down when tested, causing a false negative.

14.  Security Considerations

[Ed. Note: to be completed.]

15.  IANA Considerations

IANA is requested to perform the following actions:

15.1.  PCP Server IP address

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

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

15.2.  Port Number

Need a UDP port allocated.

15.3.  OpCodes

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

New OpCodes can be created via Standards Action (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].

15.4.  Result Codes

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

New Result Codes can be created via Specification Required (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].

15.5.  Information Elements

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

New information elements in the range 0-127 can be created via Standards Action (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226], new information elements in the range 128-192 can be created with Expert Review (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226], and the range 193-255 is for Private Use (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].

16.  Authors

The following individuals contributed substantial text to this document and are listed in alphabetical order:

   Mohamed Boucadair
   France Telecom
   Email: mohamed.boucadair@orange-ftgroup.com

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

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

   Reinaldo Penno
   Juniper Networks
   Email: rpenno@juniper.net

17.  Acknowledgments

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

18.  References

18.1. Normative References

18.2. Informative References

Appendix A.  Analysis of Techniques to Discover PCP Server

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

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

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

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

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

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

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

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 (Guttman, E., Perkins, C., Veizades, J., and M. Day, “Service Location Protocol, Version 2,” June 1999.) [RFC2608]).

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

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

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

   Therefore, this mechanism is not recommended.

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

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

Author's Address