Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)
Extracted elements (23)
The option allows the Suffix field to carry a non-null suffix (e.g., a checksum-neutral suffix) of length (12 - Prefix64 Length) octets, with no suffix field present when a /96 Prefix64 is used, addressing deployments that use non-standard suffixes per RFC 6052.
The PREFIX64 PCP option was chosen as a deterministic alternative to RFC 7050 (DNS-based discovery) because it solves all issues identified in RFC 7051, including stale prefix avoidance, multiple prefix discovery, DNSSEC compatibility, non-null suffix discovery, destination-based prefix discovery, and per-NAT64 prefix association.
The PREFIX64 option can be included in a MAP request used to learn the external IP address (per Section 11.6 of RFC 6887), allowing clients to retrieve both the external address and the NAT64 prefix in a single exchange.
The PREFIX64 option can be used by hosts implementing DNS64 in the stub resolver to synthesize AAAA records and to enable DNSSEC validation, since knowing the Pref64::/n allows the host to perform DNS64 locally rather than relying on a network-based DNS64 resolver.
The PREFIX64 option is used in conjunction with the PORT_SET option in SIP/RTP scenarios to enable IPv6-only SIP UAs to exchange media with IPv4-only UAs without requiring an ALG at the NAT64 or special functions at the IPv4-only SIP Proxy Server.
Address synthesis using the Prefix64 field MUST follow the guidelines documented in RFC 6052.
If a distinct Pref64::/n or suffix is configured to the PCP-controlled NAT64 device, the PCP server SHOULD issue an unsolicited PCP ANNOUNCE message to inform the PCP client about the new Pref64::/n and/or suffix.
If one or multiple received PREFIX64 options contain a destination IPv4 prefix list, the PCP client MUST associate the included IPv4 prefixes with the corresponding Pref64::/n and suffix, and the host MUST enforce destination-based prefix selection for local address synthesis.
If the PCP client fails to contact a given PCP server, it SHOULD clear the prefix(es) and suffix(es) learned from that server to avoid using stale Pref64::/n values.
If the PCP server is configured to honor the PREFIX64 option but no Pref64::/n is explicitly configured, the PCP server MUST NOT include any PREFIX64 option in its PCP messages.
It is NOT RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a customized (per-client or per-group) IPv6 prefix list is configured to the PCP server.
The IPv4 Prefix Count field MUST be set to 0 in a PREFIX64 request and MUST be set to the number of included IPv4 subnets in a response.
The PCP client MUST be prepared to receive multiple Pref64::/n prefixes and MUST associate each received Pref64::/n and suffix with the PCP server from which it was retrieved.
The PCP server controlling a NAT64 SHOULD be configured to return the Pref64::/n and suffix to requesting PCP clients. If no suffix is explicitly configured, the null suffix is used as the default.
When the PREFIX64 option is enclosed in a PCP request, the Prefix64 field MUST be set to ::/96.
The PREFIX64 option supports mapping of specific IPv4 address ranges (via the IPv4 Prefix List) to separate Pref64::/n prefixes, enabling destination-based NAT64 prefix selection. If no IPv4 Prefix List is returned, the client assumes the prefix is valid for any destination IPv4 address.
The PREFIX64 PCP option (Option Code 129) allows PCP clients to learn the Pref64::/n prefix and suffix used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. It is valid for MAP and ANNOUNCE opcodes and may appear in both requests and responses.
When the PCP server returns multiple PREFIX64 options without IPv4 prefix lists, the first option conveys the prefix/suffix for local IPv6 address synthesis; additional options convey other Pref64::/n values that allow the host to identify and potentially avoid NAT64 in the network.
A PCP Option Code value of 129 has been allocated in the optional-to-process range of the PCP parameters registry for the PREFIX64 option.
An attacker who can alter PCP messages or impersonate a PCP server can change the Pref64::/n delivered to clients, resulting in DoS, flooding, or man-in-the-middle attacks by directing traffic to an altered prefix. Means to defend against such attacks (e.g., ACLs between PCP client and server) SHOULD be enabled.
Learning Pref64::/n via PCP enables use of DNSSEC in NAT64 environments, which is better than no DNSSEC but less safe than DNSSEC without DNS64/NAT64. The best mitigation against Pref64::/n discovery attacks is adding IPv6 support to all endpoints to reduce reliance on address synthesis.
The IPv4 Prefix List sub-field within PREFIX64 contains an IPv4 Prefix Count (2 octets) followed by one or more entries each comprising IPv4 Prefix Length (2 octets) and IPv4 Address (32 bits). An empty list (count=0) MUST appear in requests.
The PREFIX64 option format includes: Option Code (1 octet, value 129), Reserved (1 octet), Option Length (2 octets), Prefix64 Length (2 octets, allowed values 4/5/6/7/8/12 per RFC 6052), Prefix64 (variable), Suffix (variable, length = 12 - Prefix64 Length octets), and an optional IPv4 Prefix List.