Port Control Protocol (PCP) Third-Party ID Option
updates
- rfc-6887 — Port Control Protocol (PCP)
Extracted elements (21)
The THIRD_PARTY_ID field is intentionally deployment-specific with no fixed semantics—it can hold any value agreed upon by PCP client and server, such as an L2TPv3 session ID or MPLS label. Variable length (up to 1016 octets) was chosen to accommodate diverse identifier types; Mohamed Boucadair suggested this variable length approach.
The THIRD_PARTY_ID option is applicable to scenarios where a PCP Interworking Function (IWF) acts as a proxy for multiple subscribers, such as a carrier-hosted UPnP IGD-PCP IWF or a carrier web portal, where the IWF retrieves the subscriber's tunnel ID from an AAA server and includes it as the THIRD_PARTY_ID in PCP requests to the CGN.
The THIRD_PARTY_ID option was introduced because some CGN deployments use overlapping private/shared IP address spaces (RFC 1918, RFC 6598) for different subscribers, requiring an additional identifier (e.g., tunnel ID) beyond the IP address to uniquely identify internal hosts. The THIRD_PARTY option alone is insufficient in these L2-aware NAT scenarios.
If two or more different tunnel technologies are being used simultaneously, precautions must be taken to handle potential overlap of the ID spaces of these technologies—for example, by using different PCP client/PCP server pairs per tunnel technology.
If an identifier does not align to an octet boundary (e.g., a 20-bit MPLS label), padding is done by appending 0 bits until the byte boundary is reached, after which the padding rules of RFC 6887 apply.
If an identifier used in THIRD_PARTY_ID is based on an existing standard (e.g., L2TPv3 session ID), the encoding rules of that standard must be followed to allow simple octet-by-octet comparison at the PCP-controlled device.
If the PCP client receives a THIRD_PARTY_ID_UNKNOWN, UNSUPP_THIRD_PARTY_ID_LENGTH, or THIRD_PARTY_MISSING_OPTION error response, it SHOULD report an error; where to report is based on policy.
If the PCP server does not support the THIRD_PARTY_ID option, it MUST return an UNSUPP_OPTION response, since the option is in the mandatory-to-process range (0-127).
If the PCP server receives a request with an unsupported THIRD_PARTY_ID option length, it MUST return an UNSUPP_THIRD_PARTY_ID_LENGTH (code 26) response.
If the PCP server receives a THIRD_PARTY_ID option without a THIRD_PARTY option, it MUST return a THIRD_PARTY_MISSING_OPTION (code 25) response.
If the provided identifier in a THIRD_PARTY_ID option is unknown or unavailable, the PCP server MUST return a THIRD_PARTY_ID_UNKNOWN (code 24) response.
The THIRD_PARTY_ID option MUST be used in combination with the THIRD_PARTY option, which provides the IP address. It MAY be included in a PCP MAP or PEER opcode request.
The THIRD_PARTY_ID option should not be included unless the PCP client is certain that a mapping without the THIRD_PARTY_ID is impossible, since it is in the mandatory-to-process range and a server not supporting it will reject the entire request.
Upon receiving a valid request with a legal THIRD_PARTY_ID option, the PCP server uses the combination of values from both THIRD_PARTY and THIRD_PARTY_ID options to access the internal Internet address and internal realm of a NAT map entry, instead of the THIRD_PARTY IP address alone.
The THIRD_PARTY_ID carries a context identifier that might contain privacy-sensitive information. Creation of PCP messages containing the THIRD_PARTY_ID option should be done by operator-controlled entities (e.g., the web portal or UPnP IGD-PCP IWF), not directly by the subscriber, to prevent exposure of sensitive identifiers.
The THIRD_PARTY_ID option (Option Code 13) is a new PCP option designed to be used together with the THIRD_PARTY option to uniquely identify a third party (internal host) in cases where the IP address alone is insufficient, such as CGN deployments with overlapping private address spaces.
Three new PCP Result Codes are defined: 24 (THIRD_PARTY_ID_UNKNOWN) for an unknown/unavailable identifier, 25 (THIRD_PARTY_MISSING_OPTION) when one of the two required options is missing, and 26 (UNSUPP_THIRD_PARTY_ID_LENGTH) for an unsupported option length. All are long lifetime errors.
IANA allocated PCP Option Code 13 for the THIRD_PARTY_ID option in the mandatory-to-process range, and PCP Result Codes 24 (THIRD_PARTY_ID_UNKNOWN), 25 (THIRD_PARTY_MISSING_OPTION), and 26 (UNSUPP_THIRD_PARTY_ID_LENGTH).
All security considerations from RFC 6887 Section 18.1.1 apply. The network carrying PCP messages must be sufficiently protected, and it is RECOMMENDED to use PCP authentication (RFC 7652) unless the network already has appropriate authentication means in place.
The THIRD_PARTY_ID option may carry privacy-sensitive information in its deployment-specific identifier. It is RECOMMENDED to use identifiers without privacy concerns; means to protect unauthorized access MUST be in place, and the identifier MUST only be accessible by the network operator and handled on operator equipment.
The THIRD_PARTY_ID option uses Option Code 13, a Reserved byte, a variable Option Length field, and a variable-length THIRD_PARTY_ID field of up to 1016 octets. It follows the standard PCP option format from RFC 6887, with a 1-octet option code, 1-octet reserved, 2-octet length, and variable payload.