Summary

  • IPV6_ADDR_PREFERENCES records what an application would like the host to choose; RFC 5014 deliberately makes that request a preference, not a hard requirement.
  • A defensible claim must preserve the candidate set, actual selection, address readback, attribute validation, transmission and application result as separate evidence.

A compliance screen shows a green check beside “temporary source preferred.” The ticket closes with a comforting sentence: privacy address used.

Only the preference has been evidenced.

RFC 5014 was published in 2007 to fill a specific API gap. IPv6 already had default address-selection rules and ways to bind a socket to an exact address. What applications lacked was a way to ask the host to reverse selected defaults without reimplementing the entire selection algorithm. The RFC added a per-socket option, IPV6_ADDR_PREFERENCES, and matching extensions to getaddrinfo().

The vocabulary is deliberately modest. An application can prefer a home address or a care-of address, a temporary address or a public address, a cryptographically generated address or a non-CGA address. Each preference has an opposite. An application may combine preferences across those dimensions, but it may not ask for both sides of the same pair. Contradictory socket flags produce EINVAL; contradictory resolver flags produce EAI_BADEXTFLAGS.

That input validation is useful, but it proves only that the request was coherent. The RFC states that the design expresses preferences, not requirements. If an application prefers a temporary address and none is available, the host may choose a public address instead. If one member of a combined preference is unavailable, another member can still influence selection while the system default governs the missing dimension. Unsupported flags should be ignored rather than treated as fatal.

The distinction creates an uncomfortable audit question. A zero return from setsockopt() can mean that a valid preference was stored. It does not mean the preferred attribute existed. It does not identify the candidate set, disclose which other rules won, or establish which source later appeared on a packet.

There is a second control surface. Resolver ordering depends partly on the source address the host expects to use. RFC 5014 therefore requires semantically equivalent IPV6_PREFER_SRC_* values in the getaddrinfo() extension and on the socket. If an application gives those layers different meanings, the RFC calls the behavior undefined. A report that records only the socket option may omit the decision that changed destination ordering before the socket connected.

An explicit choice can supersede the preference. If the application uses bind() or IPV6_PKTINFO to specify a source while also setting IPV6_ADDR_PREFERENCES, the explicit source wins. The preference receipt remains true as a configuration event and false as a description of controlling authority.

RFC 5014 anticipated the case in which “prefer” is not good enough. Its validation section says directly that address-selection preferences do not guarantee that application requirements are met. A hard-requirement application must express matching resolver and socket preferences, ask the stack to select a source, retrieve the selected source with getsockname(), test that address with inet6_is_srcaddr(), and abort if the result is unsuitable.

Even the selection call has an evidence boundary. On connection-oriented traffic, connect() may send a packet such as a TCP SYN before the application can inspect the chosen source. The RFC introduces bind2addrsel() for a program that must bind the would-be selection without transmitting first. For UDP, connect() can make the local selection without itself sending a datagram. “Selected” and “sent” are not synonyms.

The validator has three outcomes. It returns true when the address is local and satisfies all valid requested attributes, false when it does not satisfy them, and failure when the address is not local or the input flags are invalid. A true result is still bounded. The RFC notes that IPV6_PREFER_SRC_HOME can validate true when the host does not implement Mobile IPv6 or when the mobile node is at home. It is not a geolocation sensor.

The same restraint applies to the other attributes. RFC 8981 explains how changing temporary addresses can limit the window for trivial address-based activity correlation. It does not promise anonymity across DNS, transport, authentication or application identifiers. RFC 3972 binds a CGA to public-key material through address construction; it also says CGAs are not certified. Preferring a CGA is not signature verification, identity certification or authorization.

Historical defaults need equal care. RFC 5014 described the RFC 3484 environment, in which public source addresses were preferred by default. RFC 6724 later obsoleted RFC 3484 and changed that default toward temporary addresses. The older text is evidence of the API design and its period assumptions, not a universal inventory of current hosts.

A source-choice receipt should therefore record:

  1. the application, socket and decision identifier;
  2. the requested flags and the prior socket value;
  3. matching resolver flags and returned destination order;
  4. unsupported or contradictory-flag handling;
  5. the eligible source candidates and policy revision;
  6. any bind() or IPV6_PKTINFO override;
  7. the selection call and whether it could transmit first;
  8. the getsockname() readback;
  9. the validator flags and its 1, 0 or -1 result;
  10. the proceed or abort decision; and
  11. separately observed outbound traffic, return traffic and application result.

This receipt is an operating recommendation, not a hidden requirement of RFC 5014. It applies Heng Lu’s reality-layer discipline to a small but consequential interface. Intention belongs to the application. Selection belongs to the host at a particular moment. Attribute validation belongs to a local test. Reachability belongs to the path. Success belongs to the application. A single green preference indicator should not inherit all five claims.

Sources