Discovering PREF64 in Router Advertisements
Extracted elements (24)
Including the NAT64 prefix in the RA achieves atomic configuration: a single RA packet completes the full network setup, eliminating the possibility of an incomplete Layer 3 configuration and speeding up network attachment.
NAT64 requires routing to be configured, which in turn requires receiving an IPv6 RA; distributing the NAT64 prefix via RAs ensures 'fate sharing' so that NAT64 reachability information is always consistent with the rest of the host's network configuration.
RA-based PREF64 discovery is preferred over alternatives like PCP (RFC 7225) for deployability, because all IPv6 hosts and networks already support Neighbor Discovery, requiring only a minor extension rather than implementing an additional protocol.
The Scaled Lifetime field encodes the NAT64 prefix lifetime in units of 8 seconds (rather than 1 second) to ensure the NAT64 prefix lifetime can be at least as long as the 16-bit Router Lifetime defined in RFC 4861, preventing premature expiry between unsolicited RAs.
If the network operator needs to route different parts of the IPv4 address space to different NAT64 devices, this is accomplished by routing more-specific subprefixes of the single advertised NAT64 prefix—the PREF64 option itself specifies exactly one prefix for all IPv4 destinations.
Networks providing PREF64 via both the RA option and PCP (RFC 7225) should note that hosts may use the RA-discovered prefix immediately before PCP completes, so some traffic may not reflect more detailed PCP-provided configuration.
The PREF64 option may appear more than once in a single RA (e.g., during graceful renumbering from one NAT64 prefix to another). Hosts must handle multiple PREF64 options per RA and follow RFC 7050 Section 3 for address synthesis, using only prefixes with nonzero lifetimes.
A Scaled Lifetime of 0 indicates that the prefix SHOULD NOT be used anymore. By default, the Scaled Lifetime SHOULD be set to the lesser of 3 × MaxRtrAdvInterval / 8 or 8191.
It is NOT RECOMMENDED to configure default Router Lifetimes greater than 65528 seconds when using the PREF64 option, to ensure the NAT64 prefix does not expire before the default router.
Router vendors SHOULD allow administrators to specify nonzero lifetime values not divisible by 8, and the router SHOULD round such values up to the nearest multiple of 8 before encoding; if the value is less than 8 seconds, the Scaled Lifetime SHOULD be set to 1.
Routers SHOULD inspect valid PREF64 options received on a given link and verify consistency among routers. Detected inconsistencies SHOULD be logged to system or network management.
Routers that are aware of PvD MUST only compare PREF64 information scoped to the same implicit or explicit PvD when checking consistency.
The host SHOULD treat the PREF64 as specific to the network interface on which it was received. PvD-aware hosts MUST treat the PREF64 as scoped to the implicit or explicit Provisioning Domain (PvD).
The receiver MUST ignore the PREF64 option if the Prefix Length Code (PLC) field is not set to one of the valid values (0–5, encoding prefix lengths 96, 64, 56, 48, 40, and 32 bits respectively).
The receiver MUST multiply the Scaled Lifetime value by 8 to calculate the maximum time in seconds the prefix MAY be used, giving a maximum NAT64 prefix lifetime of 65528 seconds.
The sender MUST set the Length field to 2. The receiver MUST ignore the PREF64 option if the Length field value is not 2.
When different PREF64s are discovered via multiple mechanisms, hosts SHOULD select one source only. The RECOMMENDED priority order is: PCP-discovered prefixes (RFC 7225), then RA PREF64 option, then RFC 7050 DNS-based discovery.
When multiple PREF64s are discovered via the RA PREF64 option, host behavior for synthesizing IPv6 addresses SHOULD follow RFC 7050 Section 3, limited to prefixes with a nonzero lifetime.
The PREF64 option is a Neighbor Discovery option carried in Router Advertisements to communicate NAT64 prefixes to hosts. It consists of a Type (8-bit, value 38), Length (8-bit), Scaled Lifetime (13-bit), Prefix Length Code (3-bit), and the highest 96 bits of the NAT64 prefix.
The Prefix Length Code (PLC) is a 3-bit field encoding the NAT64 prefix length as defined in RFC 6052. PLC values 0–5 map to prefix lengths 96, 64, 56, 48, 40, and 32 bits respectively.
IANA assigned option type 38 for the PREF64 option in the 'IPv6 Neighbor Discovery Option Formats' registry (ICMPv6 Parameters).
An incorrect NAT64 prefix provided to a host can prevent communication with IPv4-only destinations. If attackers can send rogue RAs, they can perform denial-of-service or man-in-the-middle attacks as described in RFC 6104; RA-Guard (RFC 6105) MUST already be deployed to secure all RA-delivered configuration.
Providing all configuration (including the NAT64 prefix) in RAs reduces the attack surface compared to distributing configuration through multiple mechanisms that each need independent security. Existing RA security measures (e.g., RA-Guard) also eliminate the NAT64 prefix validation problem described in RFC 7050 Section 3.1.
The PREF64 option is 16 octets (Length=2 in units of 8 octets). Fields: Type (8 bits, value 38), Length (8 bits, must be 2), Scaled Lifetime (13 bits, units of 8 seconds), PLC/Prefix Length Code (3 bits), and Highest 96 bits of the Prefix (96 bits).