Port Control Protocol (PCP)
updated by
Extracted elements (30)
Information is placed in fixed Opcode fields when it is usually required (simpler parsing, fixed offset) or in options when it is needed less often (smaller packets, allows implementations to omit code for unused features). For example, THIRD_PARTY is an option because most clients never manage mappings on behalf of other devices.
PCP assumes a single-homed address model: for a given internal IP address there is exactly one default path to the Internet. This is required because after a PCP mapping forwards an inbound packet, the host's outbound response must traverse the same NAT in reverse; multiple egress paths would make it impossible to guarantee which NAT rewrites the return traffic.
PCP has no transaction ID because it is designed as a hint/notification protocol rather than strict request/response: responses are self-describing (containing internal address, external address, protocol, port, and lifetime) and clients can correlate them from opcode-specific data alone. A transaction ID would unnecessarily limit the protocol and complicate implementations without providing benefit.
PCP retransmissions (awaiting a first response) and renewals (refreshing an established mapping) are identical packets on the wire. Both signal to the server that the client wants the stated mapping to exist; the server processes them identically regardless of the client's local state.
PCP version 2 supersedes NAT-PMP (RFC 6886). During version negotiation, if the server returns UNSUPP_VERSION with version number 0, this indicates a NAT-PMP server; a PCP client MAY fall back to the NAT-PMP protocol as described in Appendix A. PCP clients always start negotiation at version 2 and step downward.
A PCP server MUST only accept normal (non-THIRD_PARTY) requests arriving on the interface from which it normally receives traffic from that client, and MUST silently ignore requests on any other interface. A residential NAT gateway, for example, ignores PCP requests arriving on its WAN interface.
Clients validate Epoch Time by comparing client_delta (elapsed local time) to server_delta (elapsed server epoch). If client_delta+2 < server_delta - server_delta/16 or server_delta+2 < client_delta - client_delta/16, the client treats the Epoch Time as invalid and immediately renews all active mapping leases. The /16 tolerance accommodates up to 6.25% clock inaccuracy.
For multi-interface hosts, PCP requests SHOULD use a globally reachable IPv6 source address (GUA) and SHOULD NOT use ULA addresses. IPv4 private addresses MAY be used given NAT ubiquity. If IPv6 privacy addresses are used for PCP mappings, a new PCP request must be issued whenever the privacy address changes.
If an error is encountered while processing a PCP request or its options, any tentative state changes MUST be rolled back — the PCP server and PCP-controlled device must remain unchanged. The error response MUST be a complete copy of the request packet with the error code and appropriate fields set.
Multiple options in a PCP request MAY be encoded in any order by the client but MUST be processed by the server in the order they appear. If an option defined to appear only once appears more than once and is understood, the server MUST respond with MALFORMED_OPTION. Clients MUST ignore options they do not understand in responses, even mandatory-to-process ones.
PCP messages MUST be sent over UDP with a maximum UDP payload of 1100 octets. All numeric quantities larger than one octet are in network (big-endian) byte order; IP addresses and ports use the same representation as in IP/TCP headers (no byte swapping).
The PCP client MUST include its own source IP address in the PCP Client's IP Address field of every request. The server MUST return ADDRESS_MISMATCH if that field does not match the source IP of the received datagram, preventing silent creation of non-functional mappings via an undetected intermediate NAT.
When an application uses the same port for both incoming and outgoing connections (symmetric client/server, e.g., Symmetric RTP), it MUST send a MAP request and receive a positive response before sending any packets from that port, to ensure the NAT-assigned external port is consistent across both explicit and subsequent implicit mappings.
All PCP address fields are fixed-size 128 bits. IPv4 addresses are encoded as IPv4-mapped IPv6 addresses (::ffff:0:0/96): 80 zero bits, 16 one bits, 32-bit IPv4 address. When checking for IPv4-mapped addresses, all 96 prefix bits MUST be checked. The all-zeros IPv4 address is expressed as ::ffff:0:0.
Every PCP response includes a 32-bit Epoch Time that increments by one per second. The server MUST reset Epoch Time to its initial value (usually zero) upon losing explicit dynamic mapping state (reboot, power failure) or upon a change to the NAT's external IP address, signaling clients to promptly renew their mappings.
PCP defines 14 result codes: 0 SUCCESS, 1 UNSUPP_VERSION, 2 NOT_AUTHORIZED, 3 MALFORMED_REQUEST, 4 UNSUPP_OPCODE, 5 UNSUPP_OPTION, 6 MALFORMED_OPTION, 7 NETWORK_FAILURE (short lifetime), 8 NO_RESOURCES (short lifetime), 9 UNSUPP_PROTOCOL, 10 USER_EX_QUOTA (short lifetime), 11 CANNOT_PROVIDE_EXTERNAL, 12 ADDRESS_MISMATCH, 13 EXCESSIVE_REMOTE_PEERS. Long-lifetime errors SHOULD use 30-minute lifetime; short-lifetime errors SHOULD use 30-second lifetime.
The ANNOUNCE Opcode carries no opcode-specific payload. A PCP client sends a solicited ANNOUNCE to trigger the server to immediately respond with its current Epoch Time, enabling rapid detection of server state loss. The server also sends unsolicited ANNOUNCE responses to all clients with active mappings after a reconfiguration event.
The FILTER option (MAP only) restricts inbound traffic for a mapping to packets from a specific remote peer IP address and port prefix, providing per-mapping source filtering. If the server cannot create the requested number of filters it returns EXCESSIVE_REMOTE_PEERS (result code 13).
The MAP Opcode creates explicit dynamic inbound mappings: external IP address + protocol + port mapped to an internal IP address + port. The MAP-specific payload includes a 96-bit Mapping Nonce (for security and correlation), Protocol (8 bits), Internal Port (16 bits), Suggested External Port (16 bits), and Suggested External IP Address (128 bits).
The PEER Opcode creates explicit dynamic outbound mappings for existing or planned outbound connections and is used to learn the NAT-assigned external address or to reduce keepalive traffic. PEER adds Remote Peer Port (16 bits) and Remote Peer IP Address (128 bits) to the MAP fields, fully identifying the five-tuple.
The PREFER_FAILURE option (MAP only) instructs the server to return CANNOT_PROVIDE_EXTERNAL rather than assign an alternate external port/address when the suggested external port is unavailable. This is implied for SCTP MAP requests and for all PEER requests; it is useful when the application requires a specific external port (e.g., active-mode FTP).
The THIRD_PARTY option (valid for MAP and PEER) allows a PCP client to request mappings specifying a different internal IP address than its own source address, enabling proxy management of mappings for devices that do not implement PCP. The PCP server must enforce additional security measures before honoring THIRD_PARTY requests.
IANA assigned UDP port 5351 for PCP. IANA created four registries: PCP Opcodes (initial values: ANNOUNCE=0, MAP=1, PEER=2), PCP Result Codes (0–13 defined), PCP Options (THIRD_PARTY, PREFER_FAILURE, FILTER defined), and the port number assignment. New entries in all registries require IETF Review.
A malicious PCP client can use MAP requests to expose other hosts on the same subnet by creating mappings pointing inbound traffic at arbitrary internal addresses (mapping theft). PCP servers should implement per-subscriber mapping quotas and, for THIRD_PARTY requests, enforce authorization checks to prevent cross-subscriber mapping abuse.
A PCP server under denial-of-service attack from a high volume of requests MAY silently discard excess requests (relying on client retransmission) or MAY return NO_RESOURCES. Attacks against server discovery (e.g., rogue DHCP PCP-server options) can redirect clients to a malicious server that denies all mapping creation.
PCP's simple threat model assumes the client and the PCP-controlled device are in the same administrative domain. On-path attackers between client and server can forge or suppress responses. The 96-bit Mapping Nonce in MAP and PEER opcodes reduces, but does not eliminate, mapping hijacking by off-path attackers; full security requires an authentication mechanism beyond the base protocol.
PCP client retransmission uses exponential backoff: initial RT = (1+RAND)*IRT (IRT SHOULD be 3 s); subsequent RT = (1+RAND)*MIN(2*RTprev, MRT) (MRT SHOULD be 1024 s). RAND is uniform [-0.1, +0.1]. MRC and MRD default to 0 (no maximum). After a successful response, RT resets to a random value in [lifetime/2, 5*lifetime/8] for periodic renewal.
PCP options use TLV encoding: Option Code (8 bits; MSB=0 mandatory, MSB=1 optional-to-process), Reserved (8 bits), Option Length (16 bits, semantic length in octets, excluding padding), Data. Options are padded to 4-octet alignment; Option Length does not include padding.
PCP request header: Version (8 bits, value=2), R bit (0=request), Opcode (7 bits), Reserved (16 bits, MUST be zero on TX/ignored on RX), Requested Lifetime (32-bit unsigned, seconds), PCP Client's IP Address (128 bits). Fixed header is 24 octets, followed by optional opcode-specific data and options.
PCP response header: Version (8 bits), R bit (MUST be 1), Opcode (7 bits), Reserved (8 bits), Result Code (8 bits), Lifetime (32 bits), Epoch Time (32 bits), Reserved (96 bits), followed by opcode-specific data and options. On parse failure the server copies the last 96 bits of the client IP address field into the reserved field.