Summary

  • RFC 5221 requires dynamically updated address-selection policy to support central control without erasing differences among nodes, applications and interfaces, and to coordinate with next-hop selection. A controller receipt and a host installation record are therefore only intermediate facts.
  • Leadership needs a policy-state receipt that separates controller authority, policy integrity, delivery, applicable scope, installed state, route synchronization, the selected source and destination, peer reachability and application outcome.

A green distribution graph can conceal a red decision

The controller reported success at 09:00. Every managed host had received version 47 of the address-selection policy. The signature verified. Configuration agents showed no errors. The deployment dashboard was entirely green.

At 09:01, the organisation knew that bytes had travelled from a controller to a population of machines. It did not yet know that version 47 belonged on every one of those machines, applied to every application using them, matched every active interface, agreed with the next hop each host would choose, or produced a usable conversation with a peer.

That distinction is the durable value of RFC 5221. The 2008 memo did not standardise a single policy-distribution protocol. It instead stated requirements for mechanisms that can update the default source- and destination-address selection rules. Its difficult requirement is not merely dynamic update. It is differentiated control: policy may need to vary by node, application and interface, while remaining coordinated with next-hop selection and compatible with ordinary socket use.

Central administration promises consistency. Address selection needs contextual correctness. Those are not the same property.

The policy has more than one state

An operational record often compresses policy into two states: deployed or not deployed. RFC 5221 implies a longer chain.

First, a controller must be an authorised source for the population it addresses. Second, the policy object must retain integrity in transit. Third, it must reach the intended node. Fourth, the node must install the intended version. Fifth, the rule must be applicable to the application and interface involved in a particular communication. Sixth, its preferences must still make sense alongside the host's current next-hop information. Seventh, the stack must choose the expected source and destination pair. Eighth, the peer must be reachable through the resulting path.

Ninth, the application must obtain the outcome for which the policy was issued.

Each transition can fail while the previous one remains true. A valid signature cannot prove that the signing authority chose the correct scope. Installation cannot prove that an application-specific exception was preserved. Correct matching cannot prove that routing state has not changed. A chosen address pair cannot prove that the peer will answer. An established flow cannot prove that the user received a useful result.

The correct ledger therefore does not store one deployment percentage. It stores a dated chain of evidence and names the owner of every transition.

Central control meets local heterogeneity

RFC 5221 explicitly asks for node-specific, application-specific and interface-specific policy behavior. That requirement matters because a host is not a featureless endpoint. Two nodes at the same site may have different capabilities or duties. Two applications on one node may use different APIs, destinations or continuity assumptions. Two interfaces may lead through different administrative domains or next hops.

A universal table can be syntactically valid and operationally indiscriminate. If a central system publishes one preference order without recording which node class, application class and interface state it governs, it has distributed an assertion with an incomplete subject.

The problem becomes sharper during change. Interfaces appear and disappear. A mobile system changes attachment. Router information changes the preferred next hop. An application opens a long-lived session while a policy version turns over. The controller may possess a coherent global model that was accurate five minutes earlier, while the host is acting on a local state the controller has not yet observed.

This is not an argument against central policy. It is an argument for preserving the dimensions that make central policy meaningful. Consistency without scope is merely repeatable error.

Address preference and next-hop choice share one outcome

RFC 5221 requires coordination with next-hop selection. RFC 4191 separately shows that hosts can receive router and route preferences that influence which next hop they use. The two records do not prove that any named implementation synchronizes those planes. They do show why an operator cannot audit them in isolation.

Address selection may prefer a source or destination under assumptions about reachability, topology or administrative intent. Next-hop state determines where packets are actually sent. If the policy version and routing snapshot were produced at different times, or apply to different interfaces, both subsystems can be individually healthy while their composition is wrong.

The audit object must therefore be a decision, not a file. For a sampled flow it should record the node, application, interface, policy version, matched rule, candidate addresses, selected pair, route and next hop, observation time, peer response and application result. That trace turns “the policy was installed” into a proposition that can be tested.

Security starts before the host accepts the table

RFC 5221 names three security concerns that are easy to lose inside a deployment success metric. Policy can leak information. A maliciously injected or modified policy can redirect traffic. Denial of service against the policy controller can prevent nodes from receiving the policy needed for appropriate communication.

These are control-plane risks, but their consequences occur in data paths and user tasks. Authentication of the transport is necessary and insufficient. Operators also need authorisation for scope, replay and rollback controls, version provenance, safe behavior when the controller is unavailable, and evidence that local exceptions were neither stripped nor silently broadened.

A stale but authentic policy deserves its own state. So does an authentic policy issued by a controller that was not authorised for a particular application population. “Cryptographically valid” and “operationally applicable” answer different questions.

What the record does not establish

RFC 5221 is a requirements document. It does not demonstrate that one mechanism satisfies the requirements, that a specific vendor distributes unsafe policy, or that a present network has suffered policy injection. RFC 3484 supplied the historical default model and RFC 6724 later replaced it; this article is not an attempt to restore the older default table.

Nor does this analysis reopen the separate RFC 5220 question of half-closed networks and missing return paths. It does not prescribe Happy Eyeballs behavior or a destination-family race. The claim is narrower: where policy is centrally managed, evidence of delivery must not be mistaken for evidence of correct scope, synchronized routing state or successful communication.

Keep a policy-state receipt

For each material policy release, preserve the authorised controller identity, signer and approval; the exact policy hash and version; intended node, application and interface scopes; issue and expiry times; delivery and installation counts; local overrides; routing-state assumptions; sampled decision traces; controller-unavailable behavior; rollback conditions; and measured application outcomes.

The receipt should retain exceptions and negative evidence. Nodes that rejected the policy, interfaces without a matching rule, applications using an unexpected API path, decisions made against a newer route snapshot, peer failures and fallback behavior are not deployment noise. They define the real boundary of the policy.

Lu Heng's reality-first frame is useful here because institutional ownership is not operational proof. The team operating the controller can attest to issuance. The endpoint team can attest to installation. The network team can attest to current routes. The application owner can attest to outcome. None should borrow the others' evidence.

Sources

Additional standards record

  1. RFC 5221 plain text
  2. RFC 5221 information record
  3. RFC 5221 Datatracker record
  4. RFC 5221 errata record
  5. RFC 3484 information record
  6. RFC 6724 information record
  7. RFC 4191 information record