Port Control Protocol


Port Control Protocol is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.
Additionally, explicit port forwarding rules available through PCP allow hosts to reduce the amount of generated traffic by eliminating workarounds in form of outgoing NAT keepalive messages, which are required for maintaining connections to servers and for various NAT traversal techniques such as TCP hole punching. At the same time, less generated traffic reduces the power consumption, directly improving the battery runtime for mobile devices.
PCP was standardized in 2013 as a successor to the NAT Port Mapping Protocol, with which it shares similar protocol concepts and packet formats. PCP adds support for IPv6 and additional NAT scenarios.
In environments where a UPnP IGD is used in the local network, an interworking function between the UPnP IGD and PCP is required to be embedded in the IGD. The UPnP IGD-PCP Interworking Function is specified in RFC6970.
DHCP options to configure hosts with Port Control Protocol server IP addresses are specified in RFC7291. The procedure to follow for selecting a server among a list of PCP servers is discussed in RFC7488.
In environments where NAT64 is deployed, PCP allows a host to learn the IPv6 prefix used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses by the NAT64.

Overview

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 or packet filtering, 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, 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 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 require dynamic opening of multiple connections, which involves application-level gateways 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 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 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, and inside less expensive consumer-grade devices. Both long-term and short-term mappings are supported.
PCP supports transport layer protocols that use 16-bit port numbers or Datagram Congestion Control Protocol. Protocols that do not use port numbers, Encapsulating Security Payload are supported for IPv4 firewall, IPv6 firewall and NPTv6 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. 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, 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

PCP was standardized in 2013 as a successor to Apple's NAT Port Mapping Protocol, sharing similar protocol concepts and packet formats with it. As one of the design differences, NAT-PMP is pretty much limited to the deployment on consumer-grade devices, while PCP is designed to also support carrier-grade equipment. Since 2005, NAT-PMP has been implemented in various Apple products.
PCP relates to the Internet Gateway Device Protocol, which was standardized in 2001 as part of the UPnP specification. While the UPnP IGD is complex and tailored toward manual configuration, PCP is designed for simplicity and automated use within software applications. The NAT-PMP specification contains a list of the problems with UPnP IGD that prompted the creation of NAT-PMP, and subsequently, its successor PCP.

Use scenarios

Clients

Security

Excluding the attackers capable of altering network packets exchanged while an explicit PCP mapping is created, PCP is considered to be secure as long as created explicit mappings do not exceed the domain of implicit mappings. In other words, implicit mappings are created as a result of the way NAT devices and firewalls are handling regular outbound client connections, meaning that PCP is safe as long as no new mapping possibilities are introduced through the explicit mapping mechanism.
From the security standpoint, an important PCP feature is the mapping request option. When used, this option signifies that the IP address specified additionally as part of the mapping request should be used as the internal address for the created explicit mapping, rather than following the default behavior of using source IP address of the actual mapping request packet for that purpose. Such mapping requests can end up with a PCP-enabled NAT device or firewall granting explicit mapping privileges higher than allowed by implicit mappings due to unknown rules imposed elsewhere for the specified IP address, allowing that way an attacker to steal some traffic, or to conduct a denial-of-service attack.
Additionally, explicit PCP security mechanisms are available as extensions to the PCP protocol, providing authentication and access control mechanisms by using an authenticated and integrity-protected in-band signalling channel, which relies on Extensible Authentication Protocol to perform the authentication between devices involved in a PCP negotiation session. Such PCP-enabled NAT devices or firewalls may still accept unauthenticated mapping requests; at the same time, all previously described explicit mapping constraints still apply.