Port Control Protocol - The Internet Protocol Journal, Volume 14, No. 4

Dan Wing, Cisco Systems

After the transition to Internet Protocol Version 6 (IPv6), hosts will often be behind IPv6 firewalls. But before the transition, mobile wireless devices will want to reduce their keepalive messages, and hosts of all sorts will share IPv4 addresses using a variety of address-sharing technologies. To meet these needs, the IETF formed the Port Control Protocol Working Group in August 2010 to define a new protocol for hosts to communicate with such devices. The initial output of this Working Group is the Port Control Protocol (PCP) [1]. Interoperability between two independently developed implementations of PCP was demonstrated at the IETF meeting in July 2011, highlighting the importance of this protocol to the industry. After it becomes a standard, PCP is expected to be deployed in various operating systems, IPv6 home gateways, IPv4 home gateways (Network Address Translators [NATs]), mobile third- and fourth-generation (3G and 4G, respectively) gateways (Gateway GPRS Support Nodes [GGSNs]), and Carrier-Grade NATs (CGNs).

Introduction to PCP

PCP performs two major functions: It allows packets to be received from the Internet to a host (such as to operate a server), and allows a host to reduce keepalive traffic of connections to a server. PCP can be extended in two ways: with new OpCodes or with new Options. The base PCP specification defines two OpCodes: map and peer, and defines several Options that can be carried with those OpCodes.

To operate a server, packets are sent from a host on the Internet to a server. The IP model expects devices to be connected to a network and be able to exchange packets with each other. However, few deployed networks actually permit hosts to receive packets from the Internet because of business needs (for example, to protect wireless spectrum from malicious or accidental packets originated on the Internet) or because of technology restrictions (for example, IPv4 address-sharing devices such as Network Address and Port Translators [NAPT]). To operate a server, a host uses the map OpCode.

To reduce keepalives, a host needs to send traffic before a middlebox will destroy an idle connection. Many middleboxes, such as firewalls or NATs, maintain state and will destroy mappings if the connection has been idle. Today, in order to prevent destruction of mappings, hosts send keepalive traffic to keep those mappings alive. The keepalive traffic has several disadvantages, including reduction of battery lifetime, network chatter, and server scalability (servers have to discard the keepalive traffic). PCP allows a host to determine how aggressively a middlebox will destroy an idle connection, allowing the host to reduce its keepalive traffic with the PEER OpCode.

PCP is encoded in binary and carried over the User Datagram Protocol (UDP), which eases implementation on clients and servers. The client is responsible for retransmitting messages, and all messages are idempotent. The PCP client can be part of the operating system (much like a Dynamic Host Configuration Protocol [DHCP] client or a Universal Plug and Play [UPnP] Internet Gateway Device Protocol [IGD] client) or the PCP client can be coded entirely in an application (much like any other application-level protocol such as the Network Time Protocol [NTP]). A major feature of PCP is its flexibility and simple messaging, so it can be implemented easily in a variety of systems and at high scale.


When installing an IPv4 NAPT on a residential network, the NAPT has a side effect: it prevents unsolicited incoming traffic from reaching hosts inside the home. Traffic that originates inside the home can traverse the NAPT toward the Internet. This function is expected by many users to such a degree that when IPv6-capable routers were first installed on residential networks, users complained that their IPv6 hosts were seeing traffic from the Internet. This visibility meant that IPv6 printers, webcams, and other hosts had to be protected from malicious traffic from the Internet. Based on this experience, IPv6 Customer Premises Equipment (CPE) routers intended for installation in the residential market filter most unsolicited incoming traffic by default [3]. Thus, IPv6 CPE routers provide filtering similar to what users experience today with IPv4 NAPT devices.

With both IPv4 NAPT and RFC 6092 IPv6 routers, outgoing traffic from a host creates a mapping that then allows bidirectional traffic to a specific (Transmission Control Protocol [TCP] or UDP) port on the internal host, meaning when a host sends a TCP SYN, a SYN ACK can be returned to the host. Neither IPv4 NAPT devices nor RFC 6092 IPv6 routers have to do any additional filtering of that mapping, and after that mapping is created will allow traffic from any host on the Internet to reach the internal host—not just traffic from that particular host. This lack of filtering is necessary for certain applications to function.

PCP was built with a security model similar to that deployed on home networks. With PCP, a host can send a PCP packet requesting a mapping so that any host on the Internet can now initiate communications with the internal host. Similarly, without PCP, a host could send a TCP SYN from a specific port (for example, port 80), thereby creating a mapping nearly identical to a PCP mapping. As with sending a TCP SYN, PCP allows a host to open mappings only for itself, unless the network administrator has taken the extra step to enable the PCP THIRD_PARTY option.

You may wish to have additional restrictions for some networks. PCP is extensible to support authorization, and there is ongoing work to support authentication and authorization within PCP [8].

PCP is extensible and there are already several proposed extensions to the protocol, including a way to control which IP address pool is assigned to a mapping [5], bulk port allocation to optimize acquiring a large set of ports [6], and rapid recovery after NAT failure or network renumbering [7].

PCP Scenarios

PCP works in all scenarios with IPv4 address sharing (using an IPv4 NAT or using other techniques), an IPv4 or IPv6 firewall, and NATs that translate from IPv6 to IPv4, IPv4 to IPv6, or IPv6 to IPv6. When working with nested NAT, such as a NAT in the home and a NAT operated by the Internet Service Provider (ISP), PCP can create the NAT mappings in both devices. When working with IPv6, PCP can create mappings in an IPv6 CPE router. In some networks we expect to see IPv6-only devices that IPv4 clients may need to access. For those devices to work, an IPv6/IPv4 translator (NAT64) [10, 11] can translate between IPv6 and IPv4. PCP can work with an IPv6/IPv4 translator as well. In other scenarios IPv6/IPv6 translation may be necessary, and although translating IPv6 to IPv6 is far from desirable, PCP can also support IPv6/IPv6 (NPTv6) [12].

A server, such as a one running on a sensor (for example, thermometer or electric meter), can use PCP to determine its publicly routable IPv4 or IPv6 address and port, and then populate a Rendezvous server with that IP address and port. For example, an IPv6-only thermostat might want to be accessible over IPv6 and IPv4, so it can be accessed by both the power company (to push new electricity rate information to the thermostat) and the homeowner (who might have IPv4 access only at work). The thermostat can use PCP to create a TCP mapping in the IPv6 CPE router (necessary because the IPv6 CPE router will, by default, filter unsolicited incoming IPv6 packets) and use PCP to create a TCP mapping in a NAT64 (necessary so the homeowner can access the thermostat). The IPv6 address and its TCP port, and the IPv4 address and its TCP port, can be published to the Domain Name System (DNS) (using DNS Server [SRV] records) or published to some other Rendezvous server. Then the power company or the homeowner can use the DNS (or the other Rendezvous server) to communicate directly with the thermostat.

Because PCP can inform the PCP client of address changes, network renumbering can be communicated immediately to hosts—something that cannot be done with most other NAT or firewall control mechanisms. Therefore, devices running on nomadic networks, such as in a connected vehicle, that use PCP will immediately learn when they have connected to a new network. This knowledge can allow them to update information in the DNS or in some other Rendezvous server so they remain accessible from the Internet.

PCP is expected to be implemented in home gateways and Carrier-Grade NATs, which provide value for both IPv6 (to operate a server and learn keepalive timeouts) and IPv4. Figure 1 shows how a dual-stack host would use PCP to operate an IPv6 or IPv4 server.

Figure 1: PCP Mapping IPv6 and IPv4

PCP Interworking with UPnP IGD

UPnP IGD Version 1 is widely available on residential-class NAT devices and host operating systems (Windows and OS X). However, because of security concerns it is often disabled by vendors, ISPs, or end users. UPnP IGD itself only works with a single layer of NAT, but it is possible to interwork between UPnP IGD and PCP [4]. To do this interworking, a home gateway (NAT) processes UPnP IGD messages on its LAN interface and translates those messages to PCP messages on its WAN interface, as depicted in Figure 2.

Figure 2: UPnP-to-PCP Interworking, Showing AddPortMapping Success

One difficulty with UPnP IGD is its AddPortMapping action, which maps a specific port on the home gateway. If that requested port is already mapped to another host, that port cannot be mapped to a new host (because it is already mapped to a different host). This problem exists today with UPnP IGD if two hosts in a home need the same port (for example, TCP port 80) because only one of them can map the port. In a CGN environment, where many subscribers share one IPv4 address, it is almost guaranteed that another subscriber has already mapped a "good" port (for example, 80 for HTTP, 8080 for HTTP, 5001 for Slingbox, 5060 for Session Initiation Protocol [SIP], etc.). Today, when a UPnP IGD port mapping is refused, the application may overwrite the first host's mapping (causing significant problems), "hunt" for an available port, or simply give up and display an error to the user. The "hunting" is often sequential (trying the next-higher port number) but is sometimes random, and is done by the application itself, the operating system UPnP framework, or both.

UPnP IGD Version 2 [2] introduced the AddAnyPortmapping action, which avoids the need to “hunt” for an available port and allows the NAT to assign an available port. But UPnP IGD Version 2 is not yet widely available in home gateways, operating systems, or applications. Until IPv6 is ubiquitously available, applications (and users) will need to practice better port agility than has been practiced in the past, because "good" ports will simply not be available when IPv4 addresses are shared.

To ease the interworking with the UPnP IGD AddPortMapping action, the base PCP specification includes a PREFER_FAILURE option, which avoids creating a mapping if the requested port is unavailable. A message flow of this behavior is shown in Figure 3.

In a Dual-Stack Lite [9] deployment, the home gateway is typically operated without a NAT function. In that configuration, the home gateway is expected to interwork between UPnP IGD (within the home) and PCP (toward the service provider’s CGN). The PCP packets sent by the home gateway will have the source IP address of the home gateway, rather than the IP address of the host that initiated the UPnP IGD action. To accommodate that situation, the home gateway populates the THIRD_PARTY option with the IP address of the internal host needing the mapping. The THIRD_PARTY option is useful in other scenarios as well, including interworking with other protocols (such as the NAT Port-Mapping Protocol [NAT-PMP] [13]) to PCP, using PCP to create mappings for a device that does not support PCP (for example, an IP-enabled webcam), or using it as the protocol between a web portal operated by the ISP and its CGN.

Figure 3: UPnP-to-PCP Interworking, Showing AddPortMapping Failure


PCP provides functions necessary for IPv6 hosts on home networks; it is a simple, scalable protocol that supports simple firewalling of IPv6 and IPv4 hosts, and to accommodate the transition to IPv6 also supports every conceived IPv4/IPv6 translation mechanism.


[1] Dan Wing, ed., Stuart Cheshire, Mohamed Boucadair, Reinaldo Penno, and Paul Selkirk, "Port Control Protocol (PCP)," Internet Draft, work in progress, July 2011, draft-ietf-pcp-base

[2] "UPnP Gateway committee: IGD:2 improvements over IGD:1," March 2009,

[3] James Woodyatt, ed., "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service," RFC 6092, January 2011.

[4] Mohamed Boucadair, Reinaldo Penno, Dan Wing, and Francis Dupont, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function," Internet Draft, work in progress, February 2011, draft-bpw-pcp-upnp-igd-interworki

[5] Reinaldo Penno, "PCP Support for Multi-Zone Environments," Internet Draft, work in progress, June 2011, draft-penno-pcp-zones

[6] Cathy Zhou, Tina Tsou, Xiaohong Deng, Mohamed Boucadair, and Qiong Sun, "Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation," Internet Draft, work in progress, July 2011, draft-tsou-pcp-natcoord

[7] Stuart Cheshire, “PCP Rapid Recovery,” Internet Draft, work in progress, June 2011, draft-cheshire-pcp-recovery

[8] Margaret Wasserman, Sam Hartman, and Dacheng Zhang, "Port Control Protocol (PCP) Authentication Mechanism," Internet Draft, work in progress, October 2011, draft-wasserman-pcp-authentication

[9] Alain Durand, Ralph Droms, James Woodyatt, and Yiu L. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion," RFC 6333, August 2011.

[10] Congxiao Bao, Christian Huitema, Marcelo Bagnulo, Mohamed Boucadair, and Xing Li, "IPv6 Addressing of IPv4/IPv6 Translators," RFC 6052, October 2010.

[11] Marcelo Bagnulo, Philip Matthews, and Iljitsch van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers," RFC 6146, April 2011.

[12] Margaret Wasserman and Fred Baker, "IPv6-to-IPv6 Network Prefix Translation," RFC 6296, June 2011.

[13] Stuart Cheshire, Marc Krochmal, and Kiren Sekar, “NAT Port Mapping Protocol (NAT-PMP),” Internet Draft, (expired), April 2008, draft-cheshire-nat-pmp-03.txt

DAN WING is the editor of the Port Control Protocol base specification and co-author of the PCP-UPnP interworking function specification. Dan has co-chaired the IETF's BEHAVE Working Group since 2006. He is a Distinguished Engineer at Cisco Systems, where he works on IPv6 transition technologies. E-mail: