Port Control Protocol (PCP) Server Selection
updates
- rfc-6887 — Port Control Protocol (PCP)
Extracted elements (18)
A delayed response after four exponentially-spaced retransmissions is treated as an indicator of persistent path or server problems, justifying ignoring it and moving to the next address rather than accepting it.
Multiple PCP servers on the same interface are not required to have the same capabilities, and PCP requests to them are independent. This allows deployment scenarios such as firewall-only servers where the client must contact all servers to install state everywhere.
The configuration mechanism must distinguish IP addresses that belong to the same PCP server versus different PCP servers, because the Mapping Nonce reuse rule differs: same nonce within one server, different nonces across servers.
In the multihoming example, when a client falls back from an IPv4 address to an IPv6 address for a PCP server, it may need to use the THIRD_PARTY option to obtain IPv4 mappings via the IPv6-addressed server.
This document does not specify how PCP server addresses are provisioned; DHCP (RFC 7291) is one mechanism. Provisioning documents are responsible for elaborating security considerations around legitimate server discovery.
As specified in RFC 6887, the PCP client must use a different Mapping Nonce for each distinct PCP server with which it communicates.
For efficiency, the PCP client SHOULD use the same Mapping Nonce for requests sent to all IP addresses belonging to the same PCP server, to support nonce validation in the Simple Threat Model.
If the PCP client has exhausted all IP addresses configured for a given PCP server, the procedure SHOULD be repeated every 15 minutes until the PCP request is successfully answered.
The PCP client SHOULD ignore a delayed response received after exhausting MRC attempts for a particular IP address, as it indicates forwarding path problems.
When a PCP client receives a hard ICMP error, it MUST immediately try the next IP address from the list of PCP server IP addresses.
Each PCP server learned by a PCP client must be associated with the interface on which it was learned. PCP requests to different PCP servers are independent.
Once a PCP client successfully receives a response from a PCP server IP address, all subsequent requests to that server are sent to that same IP address until it becomes unresponsive, at which point the sorted address cache is cleared and the selection procedure restarts.
The PCP client initializes its Maximum Retransmission Count (MRC) to 4 when attempting to reach a PCP server IP address, following the retransmission procedure of RFC 6887 Section 8.1.1.
The PCP client sorts PCP server IP addresses per RFC 6724 Section 6 (destination address selection), using candidate source addresses as input, to determine the order in which to try addresses for a single PCP server.
When multiple PCP servers are configured, the PCP client contacts all PCP servers concurrently using the per-server procedure from Section 3. If the client knows server capabilities, it may contact them simultaneously or with a delay.
PCP-related security considerations are deferred to RFC 6887. The same Mapping Nonce SHOULD be reused across IP addresses of the same server to support nonce validation in the Simple Threat Model (RFC 6887 Section 18.1), which defends against off-path attacks.
Security for PCP server discovery and provisioning is out of scope for this document; it is the responsibility of PCP server provisioning specifications (e.g., DHCP options) to address how clients can identify legitimate PCP servers.
PCP client address-selection state: (1) build candidate source addresses, (2) sort server IP addresses via RFC 6724, (3) set MRC=4, (4) send with retransmission; on MRC exhaustion move to next address, on ICMP hard error immediately move to next address, on success pin that address until unresponsive.