Handle detected IPv6-only translation networks

Enable this special handling for a detected translation network, not every network.

• NAT64 translates IPv6 traffic to IPv4; DNS64 can synthesize IPv6 addresses from IPv4 DNS information. On platforms without464XLAT, the Happy Eyeballs engine SHOULD follow §7 on detected IPv6-only NAT64/DNS64 networks. These features SHOULD only be enabled when such a network is detected; routable IPv6, no routable IPv4 and an available DNS resolver form one simple heuristic (§7). The heuristic is not universal proof of a NAT64 service.
• For an IPv4 literal instead of a hostname in this context, discover the network’s NAT64 prefix using RFC7050, synthesize address candidates using RFC6052, then insert those candidates as if DNS had supplied them. The worked example uses a known usable64:ff9b::/96 prefix and192.0.2.33 →64:ff9b::c000:221. Discovery and other permitted prefix lengths are separate mechanisms, not implemented by this /96 arithmetic helper (§7.1).
• A hostname can have a positive but broken AAAA address. A DNS64 resolver does not synthesize a replacement merely because that address fails to connect: its synthesis normally relies on a no-error/no-answer AAAA result. In this separate IPv6-only case, local A lookup/synthesis is a last resort after giving up on the initial AAAA attempts (§7.2).
• The recommended Last Resort Local Synthesis Delay is2s, started when the last connection attempt is fired, not when the first attempt or initial DNS query begins. If none has succeeded when it fires, query A and treat a valid answer like an application-provided IPv4 literal. In the chosen example the last IPv6 attempt starts at500ms, so the fallback A query is at2500ms. This is not the dual-stack50ms Resolution Delay (§§7.2,8).
• A split VPN can have a corporate resolver that knows an internal hostname’s A record but not the underlying network’s NAT64 prefix. The underlying DNS64 resolver may not know that internal name. Resolve the A using the company resolver, then synthesize locally with the underlying network’s prefix. The diagram combines two contexts locally; it does not send the private name to the underlying resolver or change VPN routes (§7.3).