Summary

  • PCP let a host explicitly request a NAT mapping or firewall opening, but the server still chose the operative external endpoint, result and lifetime.
  • Nonces, expiry and Epoch Time made the mapping observable and recoverable without turning a temporary request into ownership or guaranteed reachability.

A host sends a PCP MAP request with a protocol, an internal port and, if it has a preference, a suggested external address and port. That suggestion is not a reservation. A successful response supplies the external address and port actually assigned, along with a lifetime set by the server. If the suggestion cannot be honoured, the normal outcome may be a different endpoint. Only a request carrying PREFER_FAILURE asks the server to fail instead of substituting another mapping.

That exchange is the protocol’s central allocation of authority. The client can state its need, renew it and ask for deletion. The gateway controls the translation or firewall state and answers within its own resources, quotas and policy. PCP’s result codes make the boundary visible: a request can be unsupported, unauthorized, over quota, short of resources, or impossible at the proposed external endpoint. A successful result is evidence of the mapping the server accepted—not proof that the host owns a public port.

PCP gives the request a 96-bit Mapping Nonce. The client chooses it; the server copies it into the response and uses it when validating later refreshes. Under the Simple Threat Model, a different nonce cannot casually seize an existing dynamic mapping. Yet the nonce is deliberately narrower than identity. It correlates one mapping lineage with one PCP server. It does not authenticate a person, establish durable host identity or defeat an attacker who can observe and alter traffic on the path.

Time is equally explicit. A client renews a mapping while it still needs it, and the response states how long the server will maintain it. A requested lifetime of zero has defined deletion meanings for MAP, with threat-model rules preventing it from becoming a universal eraser. The protocol therefore treats disappearance as ordinary state management, not an exceptional failure: stop renewing, delete correctly, or allow the lease to expire.

The server’s Epoch Time addresses a different uncertainty. It advances in responses, but resets or becomes inconsistent when the server restarts, loses explicit mapping state, or undergoes certain address changes. A client that detects a suspicious jump or reversal promptly recreates its mappings. Epoch Time is therefore evidence about continuity of the server’s state. It cannot prove that packets were accepted throughout the interval, and it cannot restore the state by itself.

PEER applies the same custodial logic to an explicit outbound mapping tied to a remote peer. It can create or extend that state, and its remote-address fields make it more specific than MAP. THIRD_PARTY, meanwhile, shows that the source host is not always the beneficiary: an authorized client may act for another host only where server policy permits it. Consumer gateways are advised to prohibit such requests by default.

RFC 7488 widened the operational picture. One PCP server may have several addresses, while one interface may lead to several independent PCP servers. A client tries addresses under a defined retry procedure, reuses a nonce across addresses of the same server, and uses different nonces for different servers. Requests to those servers do not share authority. They may produce several mappings, each maintained by a different device; a firewall path may require all of them when state is not replicated.

What the record establishes

The protocol record establishes the request and response fields, server-set lifetime, nonce checks, result codes, recovery signal and server-selection behaviour. It supports an interpretation of PCP as negotiated custody of finite edge state.

What remains unknown

These RFCs do not measure adoption, certify any implementation, explain a particular gateway’s policy, or guarantee end-to-end reachability from every network. They also do not define how a client learns that a provisioned server address is legitimate; RFC 7488 leaves that security question to the provisioning mechanism.

Sources