Port Control Protocol (PCP) Proxy Function
Extracted elements (25)
A hop-by-hop PCP authentication scheme is used rather than end-to-end, so the PCP client authenticates with the PCP proxy, and the PCP proxy authenticates with the upstream server. This is more suitable from a deployment standpoint and allows the proxy to alter PCP messages (e.g., strip options, modify fields).
Optimized hairpin routing also applies to outermost external addresses; since the proxy knows these addresses, it can anticipate and perform hairpin rewriting locally, offering higher throughput and lower latency than routing packets all the way to the outermost NAT gateway.
The assigned external port and external IP address in the downstream PCP reply are copied from the upstream server's reply (the outermost external address/port, not the locally assigned ones). By recursive application, the outermost address/port propagate through intervening proxies to the downstream client.
The PCP proxy is logically equivalent to a PCP client back-to-back with a PCP server, enabling PCP clients that cannot be configured with the address of a PCP server more than one hop away to still communicate successfully. This architecture abstracts multiple upstream NATs from downstream clients, keeping client implementations simple.
Recursion termination can be achieved by detecting that the external address is a public routable address (not RFC 1918 or RFC 6598 private space), by absence of configured PCP servers, by an unresponsive default router, or by the upstream device not embedding a PCP proxy.
A PCP proxy co-located with a NAT MUST be configurable to disable relaying unknown Opcodes and mandatory-to-process unknown options, because such messages may carry hidden internal addresses or ports that would not be translated.
A PCP proxy MUST NOT copy the upstream PCP server's Epoch Time into its downstream PCP replies; each PCP server has its own independent Epoch Time so it can communicate its own state loss to clients.
A PCP proxy SHOULD implement optimized hairpin routing: if an outgoing packet is addressed to an external address/port in the NAT's own mapping table, the NAT SHOULD rewrite and deliver the packet locally rather than sending it to the outermost NAT and back.
ANNOUNCE requests received from PCP clients MUST NOT be relayed upstream to the provisioned PCP server; they are handled locally by the PCP proxy.
By default, when co-located with a NAT, the proxy MUST relay unknown Opcodes and mandatory-to-process unknown options upstream. Rejecting them would prevent clients from using new PCP server capabilities not yet supported by the proxy.
If the PCP proxy already has a valid active mapping for a mapping-creation request and the remaining lifetime is at least 3/4 of the requested lifetime, it SHOULD send an immediate reply with the outermost external address/port and actual remaining lifetime rather than generating an upstream request.
If the proxy grants a downstream lifetime greater than the upstream-granted lifetime (which is NOT RECOMMENDED), the PCP proxy MUST take responsibility for renewing the upstream mapping itself.
If the remaining lifetime on a local mapping is less than 3/4 of the lifetime requested by the PCP client, the PCP proxy MUST generate an upstream request to the upstream PCP server.
The PCP proxy MUST follow the procedure defined in Section 8.1 of the PCP specification (RFC 6887) to discover its upstream PCP server, using the same provisioning means available to a PCP client.
The requested lifetime in the upstream PCP request SHOULD be capped to appropriate minimum and maximum values configured for the upstream PCP server if the client's requested lifetime falls outside the acceptable range.
The suggested external address and port in the upstream PCP request SHOULD be copied from the original PCP request (typically the outermost external address/port previously learned by the client on renewal).
Upon change of its external IP address, the PCP proxy SHOULD renew its maintained mappings, and if the PCP server assigns a different external port, SHOULD follow the PCP mapping repair procedure (RFC 6887), requiring a full state table.
Upon receipt of an unsolicited ANNOUNCE from a PCP server indicating a change, the PCP proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate PCP clients; if no change is detected, no unsolicited ANNOUNCE is generated downstream.
When configured to disable unknown relaying, a PCP proxy co-located with a NAT MUST reject requests with unknown Opcodes via UNSUPP_OPCODE, and MUST reject requests with mandatory-to-process unknown options via UNSUPP_OPTION.
When multiple PCP servers are configured, the PCP proxy MUST ensure that requests of a given PCP client are relayed to the same PCP server, maintaining session affinity.
When the mapping's external address does not belong to the proxy node (e.g., firewall case), the proxy's client side MUST insert a THIRD_PARTY option in its upstream PCP request carrying the mapping's external address.
A PCP proxy MAY handle multiple PCP servers simultaneously, each with its own epoch value. PCP clients are unaware of multiple servers; the proxy follows RFC 7488 PCP Server Selection and contacts all configured servers in parallel.
A received request carrying an unknown Opcode or option SHOULD be dropped (or the non-mandatory unknown option removed) if it is not compatible with security controls provisioned to the PCP proxy, to prevent forwarding messages with hidden untranslated addresses.
The device embedding the PCP proxy MAY block PCP requests directly sent to the upstream PCP server(s) using ACLs, preventing clients from bypassing the proxy.
The PCP proxy MUST follow the security considerations in RFC 6887 for both its client and server sides. THIRD_PARTY options MUST NOT be enabled unless the network on which PCP messages are sent is fully trusted (via physical or cryptographic security), to prevent malicious users from creating mappings on behalf of third parties.