Summary

  • RFC 9762 places a positive, prefix-scoped preference in a Router Advertisement: a supporting host should try DHCPv6 Prefix Delegation before creating new individual addresses from a PIO that also permits SLAAC.
  • The P bit is not a lease. A defensible result needs separate receipts for the RA, the client decision, the DHCP Reply, prefix suitability, relay binding, route and filter installation, source and first-hop selection, and actual traffic.
  • Absence is deliberately asymmetric. No P bit does not mean DHCPv6-PD is unavailable, while a received P bit inherits the trust limits of Router Advertisements and can be abused to delay address configuration.

The access-network change looked successful in the packet capture. The router emitted a Prefix Information Option with P=1. New hosts saw it and stopped forming fresh SLAAC addresses from the shared prefix. The intended policy had crossed the link exactly as configured.

But no usable delegated prefix followed.

That sequence is not a contradiction in RFC 9762. It is the reason to read the new bit narrowly. The RFC gives a network a way to express a preference early, before a client commits applications to addresses it may soon deprecate. It does not compress the later DHCPv6, routing and delivery system into the Router Advertisement.

The distinction is easy to lose because P has a strong name: the DHCPv6-PD Preferred Flag. A dashboard can render it as “prefix delegation available”, then reuse the green state as if a prefix had been allocated and routed. Yet the wire fact is smaller. A particular interface received an RA. A particular PIO named a prefix and carried a bit. A supporting client was invited to attempt another protocol.

The bit arrives before the decision it is meant to change

The timing explains why the signal belongs in the PIO. If a host first creates SLAAC addresses from a shared on-link prefix, applications may start using them immediately. If the host later receives a unique delegated prefix, it faces an awkward choice: retain both address families and dilute the scalability benefits, or deprecate the first addresses and disrupt live flows.

RFC 9762 lets the router state its preference before that fork. For clients implementing DHCPv6-PD, a PIO with P=1 says: prefer the per-client prefix model described by RFC 9663 over obtaining another individual address from this shared prefix. The message is specific to that PIO. One prefix can carry the preference while another, including a ULA prefix, can still be used through ordinary SLAAC. Different upstreams can also make different choices.

The bit is independent of the RA's M and O flags. Older devices may use those flags as the reason to start DHCPv6-PD, so a network supporting them may need to set M or O as well. Router implementations must let operators configure P separately from the PIO's Autonomous A flag. Turning on P is not permission for software to rewrite A behind the operator's back.

That separation preserves fallback. A network can advertise both P=1 and A=1. A supporting client should treat A as unset while the preference is being honoured, but the underlying SLAAC possibility remains available if no suitable delegation is obtained and local policy permits fallback. RFC 4862 supplies the address-autoconfiguration rules that RFC 9762 updates; RFC 4861 supplies the Neighbor Discovery and RA context. The new bit changes a decision inside those systems. It does not erase either system.

A list gives the preference a lifetime

A supporting client does not react only to the last packet it happened to see. Per interface, it keeps a list of every prefix received in a PIO with P=1 whose preferred lifetime remains non-zero. A transition from an empty list to one entry should start DHCPv6-PD unless the client is already requesting prefixes. Expiry or a new PIO with zero preferred lifetime removes the entry.

The other edge is intentionally qualified. When the list falls to zero, the client should stop requesting or renewing prefixes only if it has no other reason to continue. Existing delegated-prefix lifetimes do not vanish because the RA preference vanished. A router withdrawal is evidence about this invitation, not authority to rewrite a lease already granted by a DHCP server.

If the list changes while the client already has delegated prefixes, the change is treated as new configuration information and normally triggers REBIND unless the list has become empty. RFC 8415 defines that DHCPv6 state machine. The resulting Rebind/Reply exchange is a separate event with its own server selection, status, IA_PD data and lifetimes.

This produces the first important ledger boundary. Record the RA source, interface, PIO prefix, P and A values, preferred lifetime and the exact list transition. Then record whether the client actually started Solicit or Rebind. “The bit was seen” and “the DHCP state machine moved” are adjacent facts, not synonyms.

The DHCP reply still has work to do

When a client asks for prefix delegation under this model, it must use a prefix-length hint short enough to form SLAAC addresses. The response can still be unsuitable. A delegated prefix longer than the length usable for SLAAC must be ignored. A shorter prefix can be accepted and divided into suitable longer prefixes.

No field in the original RA predicts which of those outcomes will occur. The DHCP server may be unreachable. The pool may be exhausted. Policy may reject the client. A Reply may carry a failure status. A prefix may arrive with an unusable length or an unexpected lifetime. The host may have disabled P processing after a bounded unsuccessful attempt and fallen back to SLAAC or IA_NA.

The RFC permits that fallback. It therefore cannot be honest to label the P bit itself as completed delegation. A stronger record joins the client request and its prefix-length hint to the selected server or relay, the Reply, the returned IAPREFIX, its preferred and valid lifetimes, and the client's acceptance decision.

The distinction also prevents a false negative. Section 7.3 makes P a purely positive indicator. If no PIO has the bit set, the client must not infer that DHCPv6-PD is absent. A CE router or an explicitly configured host can have an independent reason to run PD. RFC 7084 is one source of that established router behaviour. “No invitation observed” is not “the service does not exist.”

A prefix in a Reply is not yet a forwarding result

RFC 9663 describes what makes the per-client-prefix model useful. The server delegates a prefix, and the first-hop router installs a route for it toward the client's link-local address. Infrastructure treats the prefix as off-link, avoiding a Neighbor Cache entry for every global address the client creates. The client can create multiple addresses or provide prefixes to internal components while the network carries one route for the device.

That benefit depends on state outside the client. RFC 8987 requires a delegating relay to maintain leases, next hops and local routes, update ingress filters, retain or remove state according to DHCP lifetimes, and expose enough operational data for troubleshooting. A server Reply captured at the host does not prove the relay installed the corresponding route. A route shown on one first-hop router does not prove redundant routers share the binding. A route entry does not prove the data plane used it.

The client also has obligations. A delegated prefix is off-link on the interface from which it was obtained. The client must not send or forward a packet destined inside that prefix back toward that interface, because that can create a loop. A high-metric discard route is one possible safeguard. When the client creates addresses from the delegation, source-address selection should treat them as associated with the receiving interface under RFC 6724.

Multihoming adds another join. A client should associate the delegated prefix with the link-local address of the DHCP server or relay that supplied it, and may need several such associations when redundant systems return the same prefix. RFC 8028 explains why source prefix and first-hop choice cannot be separated casually in a multi-prefix network. A valid prefix sent through the wrong router can still fail.

So the full evidence chain is longer than the flag: RA receipt; P-list generation; DHCP request; accepted Reply; lease; relay binding; installed next-hop route; active ingress filter; address construction; selected source; selected first hop; packet delivery; application completion. The green state at each stage proves only that stage.

On-link traffic changes shape as well

Unique prefixes per client make other clients' global addresses off-link. Same-link traffic initially travels through the default router. An ICMPv6 Redirect may allow a more direct path, and RFC 9762 recommends that supporting hosts process redirects unless configured otherwise. Devices or routers that do not do so can see additional latency.

This is not merely a control-plane detail. A deployment can show a valid delegation and working upstream connectivity while local peer-to-peer traffic takes a surprising route or fails under a filtering policy. The operator needs to test both off-link service and same-link communication rather than treating one successful ping as universal proof.

The policy also changes resource economics. RFC 9663 trades larger prefix-pool consumption and route state for fewer per-address Neighbor Discovery entries and stronger per-device fate sharing. That may be attractive in a large Wi-Fi or virtualized network. It can be a poor default in a home network whose upstream has supplied only a small prefix. The P bit communicates a selected model; it does not prove that the pool sizing decision was sound.

Trust attaches to the sender, not to the bit allocation

The IANA IPv6 Neighbor Discovery Prefix Information Option Flags registry records bit 3 and points to RFC 9762. That registry settles syntax. It does not authenticate an RA on a particular access link.

RFC 9762 inherits the ordinary RA security model. Without the protection described in RFC 6105, a local attacker can emit a matching PIO with P=1 and cause supporting hosts to treat A as unset. If no usable DHCPv6-PD infrastructure answers, address acquisition may fail or be delayed. RFC 7113 documents implementation concerns that make “RA-Guard enabled” weaker than proof that every evasion path is closed.

DHCP is another boundary. Without RFC 7610 controls, a rogue DHCPv6 server can return invalid configuration. The RA sender and DHCP server are separate actors even when one operator controls both. Trust in one received frame cannot be borrowed to authenticate the later Reply.

An attacker or misconfiguration can also alternate P between set and clear. List changes can trigger REBIND and load the DHCP infrastructure. RFC 8415 rate limiting bounds client transmission, but a rate limit is not proof that churn is harmless. Monitor the input, the state transition and the downstream work separately.

The narrow signal is a strength

The proper conclusion is not that the bit is too weak. Its small authority is what makes it composable. It solves an ordering problem: tell a capable client which address-assignment path to try before it creates an address that will be expensive to withdraw. It leaves allocation policy, prefix length, relay state, routing, filtering, fallback and application success to the systems that actually control them.

That follows Heng Lu's account of a minimum initial specification with localized future decision. A common bit can align timing without centralizing every later choice. His principle of running-code primacy supplies the verification rule: configured intent is not executable state, and executable state is not delivered outcome. The distinction among reality layers prevents a standards label, packet capture, lease record and user experience from being collapsed into one assertion.

The flag is useful precisely when the evidence remains no larger than the bit.