Many applications and
network equipment deployments require their network locations to be reachable from outside their
local networks, following the originally envisioned model of
IP end-to-end connectivity across the Internet, so they can operate as network servers and accept connections from remote
clients. An example of such equipment is an
IP camera, which includes a network server that provides remote
surveillance over IP networks. Usually, network equipment deployments place the devices behind routers or firewalls that perform NAT (to enable sharing of an
IPv4 address, for example) or packet filtering (for improved
network security and protection), ending up with breaking the end-to-end connectivity and rendering the equipment and applications inaccessible from the rest of the Internet.
The problem Making the deployed equipment accessible, by extending its server role beyond the local network, requires either manual configuration of port forwarding at the
network gateway (which is usually a
CPE), or application-level workarounds that initiate connections from the deployed equipment to additional intermediate servers used for "merging" those "firewall punching" connections and connections from the actual clients. Both approaches have their downsides manual CPE configuration is usually either inconvenient or not possible, while using additional intermediate servers increases complexity and cost. For example, an
online computer game (which acts as a client) requires communication with a game server for exchanging
gameplay data. In order to make it possible for a game server to provide data to its clients, those clients must be made accessible to the server. Usually, clients initiate connections to the game server to open communication channels. However, such open connections can become idle and can subsequently be closed by network gateways, leading to the necessity of maintaining them by using a form of keepalive messages. Keepalive messages are small messages that are sent between client and server that create traffic over a communication channel and therefore prevent gateway servers from closing it. Thus, keeping a connection alive requires a constant exchange of empty messages between client and server. This increases network chatter, wastes
network bandwidth and
CPU cycles, and decreases the autonomy of
battery-powered devices. Additionally, some network applications (for example,
FTP) require dynamic opening of multiple connections, which involves
application-level gateways (ALGs) and additionally increases complexity.
PCP as a solution PCP allows equipment and applications to create explicit mappings between an external
IP address,
protocol and
port, and an internal IP address, protocol and port. With such explicit mappings in place, inbound communication can reach the hosts behind a NAT or firewall, which either expands their server roles beyond boundaries of local networks, or makes use of various services simplified and less resource-consuming. Created mappings are permanent to the extent of having a known lifetime that can be extended, which is similar to the way
Dynamic Host Configuration Protocol (DHCP) implements its
leases. At the same time, PCP allows applications to create additional mappings dynamically as required, which reduces or eliminates the need for having
ALG-enabled NAT devices and firewalls. Created explicit mappings have a known lifetime, commonly several hours, with no need for application-level keepalive messages to be exchanged between hosts and servers for the purpose of preserving the mapping. As a result, network usage and power consumption are reduced, and application-level keepalive logic no longer needs to be implemented at client and server sides. The PCP mapping response provides the application with associated externally visible parameters (IP address, protocol and port) that can then be announced to other clients in application-specific ways so incoming connections can be established. Additionally, PCP can inform applications when the external IP address is changed while a mapping is already established. Various types of NAT can be handled by PCP, providing support for
NAT64,
NAT66, and
NAT44; inclusion of PCP into IPv4 and IPv6 firewall devices is also supported. PCP is designed to be used on both large-scale aggregation points (for example, as part of
carrier-grade NATs), and inside less expensive
consumer-grade devices. Both long-term (for an IP camera or a temperature sensor acting as a server, for example) and short-term mappings (while playing an online computer game, for example) are supported. PCP supports
transport layer protocols that use 16-bit port numbers (for example,
TCP,
UDP,
Stream Control Transmission Protocol (SCTP) or
Datagram Congestion Control Protocol (DCCP). Protocols that do not use port numbers (for example,
Resource Reservation Protocol (RSVP),
Encapsulating Security Payload (ESP),
ICMP or
ICMPv6) are supported for IPv4 firewall, IPv6 firewall and
NPTv6 (IPv6 prefix translation) functions, but cannot be supported by more than one client per external IP address in the case of NAT. The PCP specification does not define a mechanism for dealing with
multi-homed networks (which have multiple network gateways or
default routes). It is nonetheless possible to implement PCP in such networks using a coordination mechanism such as
conntrackd. However, if the different networks each have their own external IP address(es), a given PCP mapping can only use one or the other because the protocol requires one specific external IP address to be provided to the client. If that network should then become unavailable the PCP mapping would have to be updated to use an external IP address from the other network. The PCP specification does not define a mechanism for dealing with how to inform remote computers about the IP address, protocol, and port for the incoming connection. RFC6887 states, that PCP does not provide any rendezvous function and this has to been done in an application-specific manner, like using external nameservice servers. == History ==