Summary

  • RFC 5192 gives a PANA client an ordered list of candidate PAA addresses and requires the client to try them in that order. The order is an execution instruction, not evidence that any candidate is currently healthy, authentic or capable of completing PANA.
  • Requesting the option, receiving it, validating its length, preserving its exact order, attempting each candidate and completing a PANA exchange are separate receipts. Presence or absence of the option must never be converted into a policy decision about whether PANA is required.

An address list looks modest enough to fit in one database column. RFC 5192 makes that shortcut dangerous. Its DHCPv4 and DHCPv6 options do not merely announce a set. They carry a preference order, and the PaC is required to try records in the order listed by the DHCP server.

That requirement gives the order operational force. It does not give the order omniscience. The option contains no observation time for endpoint health, no authenticated PAA identity, no capacity or load value, no failure class, no retry deadline and no proof that a PANA exchange ever began. A first address can be the preferred candidate and still be unreachable. A second can work and still not be the endpoint that policy intended for a different interface or list version.

The correct model is neither “the first address is authoritative” nor “the order is just decoration”. It is: the received order controls the attempt sequence, while every attempt produces its own evidence.

A preference is an instruction, not a measurement

For DHCPv4, option 136 carries one or more 32-bit PAA addresses. The payload length must be a multiple of four. For DHCPv6, option 40 carries 128-bit addresses and its length must be a multiple of sixteen. In both cases the addresses are listed in order of preference, and the PaC must try them in that order.

“Preferred” answers which candidate comes first. It does not answer why the server preferred it, when that preference was computed, whether the candidate has failed since then, or whether the client’s path reaches it. The option has no fields for those facts.

Operations should therefore resist two opposite errors. Sorting or deduplicating the list can destroy the server’s instruction. Treating the first record as a health verdict can suppress necessary failover. The stored object needs an immutable list version, exact ordinal positions and a separate attempt log.

A useful report says: “DHCP transaction 8f2a supplied [A, B]; A was attempted first and timed out; B was attempted second and answered.” “PAA discovered: B” erases both the normative sequence and the incident.

Request and delivery are different events

RFC 5192 says a DHCPv4 client should request the option in its Parameter Request List, and a DHCPv6 client should request it in the Option Request Option. It also says a configured server should send the PAA option even when the client did not explicitly request it.

An option can therefore be present without proving that the client asked for it. This matters whenever telemetry turns receipt into intent. A compliance engine may report that the client “selected PANA discovery” merely because the response contained option 136. The packet proves only that the server supplied it.

Record the request and response independently: client message, transaction identifier, requested option codes, responding server, relay context, interface and exact response bytes. Then record whether the response contained a syntactically valid PAA option. The two Boolean values—requested and received—are not interchangeable.

The distinction also explains absence. A client may request an option and receive none. A server may send one without a request. Neither state alone tells the operator whether PANA is required.

Absence is not permission to downgrade

RFC 5192 explicitly forbids using these options to negotiate the use of PANA. Presence must not mean “PANA required”, and absence must not mean “PANA optional”. The security reason is direct: an attacker able to remove an unprotected option could make a client choose a weaker mechanism or no security mechanism.

This is a more exact lesson than the familiar warning that DHCP may be untrusted. Even a perfectly parsed absence has no authority to change the security requirement. Policy must come from another configured or authenticated surface.

The evidence model should keep option absent as an observation, not normalize it into PANA not required. If a local profile requires PANA, that profile remains in force. If the client has another discovery method, the missing option may trigger it. RFC 5192 does not define that local decision tree, so the implementation must declare it rather than attribute it to the standard.

Validation precedes interpretation

The option length is part of the contract. Four-byte divisibility is required for the IPv4 address list; sixteen-byte divisibility is required for IPv6. A parser that rounds a malformed payload, drops residual bytes or invents padding has converted invalid input into plausible configuration.

RFC 5192 does not specify a detailed recovery algorithm for malformed options. That absence is not permission to silently repair them. Store the option code, declared length, captured length, raw bytes and validation result. If the option cannot be decoded according to its address-family structure, the honest result is “invalid option”, followed by the implementation’s explicit fallback policy.

This preserves a critical distinction between “no candidates were supplied” and “candidate data were supplied but failed validation”. They can have identical user symptoms and completely different owners.

The list belongs to a DHCP exchange

A PAA list does not float above time and topology. DHCPv4 has transaction, server, relay, lease, renewal and rebinding context. DHCPv6 has corresponding message, transaction, relay and renewal surfaces. Those records locate the origin of the option and the network attachment on which it was learned.

If a later DHCP exchange supplies a different order, operations should create a new list version. Do not mutate the old array while an attempt sourced from it is still in flight. Link each candidate attempt to the exact DHCP receipt that authorized its position.

RFC 5192 does not say how an implementation arbitrates simultaneous IPv4 and IPv6 lists, races candidates or caches results across attachments. Those are local choices. They should be visible as algorithm version, address-family policy and attempt chronology.

One global primary_paa field cannot preserve two ordered lists. It also cannot explain whether the chosen address came from DHCPv4, DHCPv6, static configuration or another discovery method.

Protection must be proved on the actual exchange

The security considerations state that, in most networks, the DHCP exchange delivering the option before access authentication is neither integrity protected nor origin authenticated. A modified or injected reply can lead the PaC to a rogue PAA that intercepts authentication requests or denies access.

DHCP authentication machinery exists in the surrounding standards. Its existence does not retroactively protect a concrete packet. The evidence must say whether this transaction was verified, with which mechanism and identity, or whether protection is unknown or absent.

Nor does authenticated delivery make a PAA healthy. It establishes provenance and integrity for the option within the mechanism’s scope. The subsequent endpoint attempt and PANA exchange still need their own receipts.

This layered account avoids both exaggeration and complacency: an unprotected option is not trustworthy policy, while a protected preference list is still not a service monitor.

Contact is not a completed PANA service

An IP response from the first candidate proves less than many dashboards imply. It may establish address reachability or a transport observation. It does not prove that the endpoint is the expected PAA, that it accepts this client, or that authentication and authorization will succeed.

The attempt ledger should progress through named states: scheduled from list version; attempted at ordinal N; network observation; PANA initial exchange; peer/session validation; terminal PANA result. A timeout before any reply differs from a syntactically invalid PANA message, an authentication failure and an authorization rejection.

This Article stops before the enforcement and data-plane boundary owned by the retained RFC 5191 Article. Its concern is the integrity of the discovery-to-attempt sequence. Once a PANA result exists, later control surfaces have their own receipts.

The minimum operational receipt

For every list, retain the DHCP family, interface, transaction, server and relay provenance, client request set, response time, security status, raw option, validation outcome, exact address order and list hash. For every candidate, retain its ordinal, address, attempt policy, start and end, observation class and terminal reason.

For the selected candidate, link the subsequent PANA session rather than copying its status into discovery. If no candidate succeeds, preserve every failed attempt. If a new DHCP exchange arrives, start a new list version and record how local policy treats work already in flight.

Heng Lu’s reality-layer discipline is useful here because it denies symbolic records the authority of the systems they describe. The DHCP option is a real instruction. The candidate’s current condition is a different reality. A faithful system keeps both.

Sources

  1. RFC 5192 HTML
  2. RFC 5192 text
  3. RFC 5192 record
  4. IETF Datatracker RFC 5192
  5. RFC 5192 history
  6. RFC 5192 references
  7. RFC 5192 errata
  8. RFC 2131
  9. RFC 2131 record
  10. RFC 2132
  11. RFC 8415
  12. RFC 8415 record
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. IANA BOOTP/DHCP parameters
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy