Port Control Protocol Overview
Port Control Protocol (PCP) provides a way to control the forwarding of incoming packets by upstream devices, such as NAT44 and firewall devices, and a way to reduce application keepalive traffic. PCP is supported on the MS-DPC, MS-100, MS-400, and MS-500 MultiServices PICs. Starting in Junos OS Release 17.4R1, PCP for NAPT44 is also supported on the MS-MPC and MS-MIC. Starting in Junos 20.2R1, PCP for CGNAT DS-Lite services are supported for Next Gen Services.Starting in Junos OS Release 18.2R1, PCP on the MS-MPC and MS-MIC supports DS-Lite. In Junos OS Release 18.1 and earlier releases, PCP on the MS-MPC and MS-MIC does not support DS-Lite.
PCP is designed to be implemented in the context of both Carrier-Grade NATs (CGNs) and small NATs (for example, residential NATs). PCP enables hosts to operate servers for a long time (as in the case of a webcam) or a short time (for example, while playing a game or on a phone call) when behind a NAT device, including when behind a CGN operated by their ISP. PCP enables applications to create mappings from an external IP address and port to an internal IP address and port. These mappings are required for successful inbound communications destined to machines located behind a NAT or a firewall. After a mapping for incoming connections is created, remote computers must be informed about the IP address and port for the incoming connection. This is usually done in an application-specific manner.
Junos OS supports PCP version 2 and version 1.
PCP consists of the following components:
PCP client—A host or gateway that issues PCP requests to a PCP server in order to obtain and control resources.
PCP server—Typically a CGN gateway or co-located server that receives and processes PCP requests
Junos OS enables configuring PCP servers for mapping flows using NAPT44 capabilities such as port forwarding and port block allocation. Flows can be processed from these sources:
Traffic containing PCP requests received directly from user equipment, as shown in Figure 1.
Figure 1: Basic PCP NAPT44 Topology
Mapping of traffic containing PCP requests added by a router functioning as a DS-Lite softwire initiator (B4). This mode, known as DS-Lite plain mode, is shown in Figure 2.
Figure 2: PCP with DS-Lite Plain Mode
Junos OS does not support deterministic port block allocation for PCP-originated traffic.
Benefits of Port Control Protocol
Many NAT-friendly applications send frequent application-level messages to ensure their sessions are not being timed out by a NAT device. PCP is used to:
Reduce the frequency of these NAT keepalive messages
Reduce bandwidth on the subscriber's access network
Reduce traffic to the server
Reduce battery consumption on mobile devices
Port Control Protocol Version 2
Starting with Junos OS Release 15.1, Port Control Protocol (PCP) version 2 is supported, which is in compliance with RFC 6887. PCP provides a way to control the forwarding of incoming packets by upstream devices, such as NAT44, and firewall devices, and a way to reduce application keep-alive traffic. PCP version 2 supports nonce authentication. PCP allows applications to create mappings from an external IP address and port to an internal IP address and port. A nonce payload prevents a replay attack and it is sent by default unless it is explicitly disabled.
Client nonce verification for version 2 map requests (for refresh or delete) requires that the nonce received in the original map request that causes the PCP mapping to be created is preserved. The version of the initial request that enables the mapping to be created is also preserved. This behavior of saving the nonce and version parameters denotes that 13 bytes per PCP mapping are used. This slight increase in storage space is not significant when matched with the current memory usage of a system for a single requested mapping (taking into account the endpoint-independent mapping (EIM) and endpoint-independent filtering (EIF) that are created along with it). In a customer deployment, PCP causes EIM and EIF mappings to represent a fraction of all such mappings.
Until Junos Release 15.1, services PICs support PCP servers on Juniper Networks routers in accordance with PCP draft version 22 with version 1 message encoding. With PCP being refined from the draft version as defined in Port Control Protocol (PCP) draft-ietf-pcp-base-22 (July 2012 expiration) to a finalized, standard version as defined in RFC 6887 -- Port Control Protocol (PCP), the message encoding changed to version 2 with the addition of a random nonce payload to authenticate peer and map requests as necessary. Version 1 does not decode messages compliant with version 2 format and nonce authentication is not supported. In a real-word network environment, with customer premises equipment (CPE) devices increasingly supporting version 2 only, it is required to parse and send version 2 messages. Backward compatibility with version 1-supporting CPE devices is maintained (version negotiation is part of the standard) and authenticates request nonce payload packets when v2 messages are in use.
The output of the show services pcp statistics command
contains the PCP unsupported version field, which is incremented to
indicate whenever the version is not 1 or 2. A new field, PCP request
nonce does not match existing mapping, is introduced to indicate the
number of PCP version 2 requests that were ignored because the nonce
payload did not match the one recorded in the mapping (authentication
failed). If version 2 is in use, the client nonce is used for authentication.