Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All
     

    Related Documentation

     

    Port Control Protocol Overview

    Port Control Protocol (PCP) provides a mechanism to control the forwarding of incoming packets by upstream devices such as NAT44, and firewall devices, and a mechanism to reduce application keepalive traffic. PCP is not supported if you are using MS-MPCs or MS-MICs. 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

    Many NAT-friendly applications send frequent application-level messages to ensure their sessions are not being timed out by a NAT. These applications can reduce the frequency of such NAT keepalive messages by using PCP to learn and influence the NAT mapping lifetime. Using PCP helps reduce bandwidth on the subscriber's access network, traffic to the server, and battery consumption on mobile devices.

    Junos OS enables configuring PCP servers for mapping flows using NAPT44 capablilites 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

      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 show in Figure 2

      Figure 2: PCP with DS-Lite Plain Mode

      PCP with DS-Lite Plain Mode

    Note: Junos OS does not support deterministic port block allocation for PCP-originated traffic.

    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 mechanism to control the forwarding of incoming packets by upstream devices such as NAT44, and firewall devices, and a mechanism 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. A nonce payload is sent by default unless it is explicitly disabled. With nonce payload, the device expects Online Certificate Status Protocol (OCSP) responses to contain a nonce payload, otherwise the revocation check will fail. If OCSP responders are not capable of responding with a nonce payload, disable this option.

    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.

     

    Related Documentation

     

    Release History Table

    Release
    Description
    Starting with Junos OS Release 15.1, Port Control Protocol (PCP) version 2 is supported, which is in compliance with RFC 6887.

    Modified: 2017-06-26