Summary

  • A Provisioning Domain is a consistency boundary for addresses, DNS, routers and related configuration. Its FQDN, Router Advertisement flags and sequence number identify and refresh that boundary; none of them selects an interface or route for the host.
  • Trust is assembled in stages. The host must retrieve additional information through the same PvD, authenticate the PvD ID, validate identifier, expiry and prefix coverage, then apply local or application policy and record the source address, resolver and next hop actually used.

The familiar name was not the winning path

A laptop joins a network that advertises two explicit Provisioning Domains on the same link. The first carries the FQDN of a familiar operator. Its H flag announces additional information, and its sequence number is newer than the value in yesterday's trace. The second has a less recognizable name.

An operations panel highlights the familiar PvD and labels it selected. Yet the authenticated JSON for that domain contains noInternet: true. It offers a restricted service. The other PvD is the only candidate for general Internet access, and the host's policy chooses it for a browser connection.

Nothing failed. The first domain was correctly named, current and useful. The panel confused four different states: identification, freshness, eligibility for a purpose and actual selection.

That confusion matters because multihomed hosts have long suffered from configuration leakage. A source address learned from one network may be paired with another network's resolver or default router. The pieces can each be valid and the result still be wrong. RFC 7556 introduced the Provisioning Domain, or PvD, as a way to preserve the context in which those pieces belong together. RFC 8801 later defined an explicit identity and discovery mechanism. Neither standard made the network the final chooser of an application's path.

A domain is not an interface

RFC 7556 defines a PvD as a consistent set of network configuration information. Typical elements include source-address prefixes, DNS servers, search suffixes, proxy information and default gateways. A classic single-interface host may appear to have one such set, but modern multihoming breaks that shortcut.

Several PvDs can arrive over one link. A single PvD can also extend across multiple links. Treating a PvD as a synonym for an interface therefore discards the architecture's central insight: the boundary is semantic and administrative, not merely physical.

The architecture recognizes implicit domains inferred from their configuration source and explicit domains marked with an identity. In either form, the host associates information with the domain that supplied it. When it creates a connection, it selects a PvD under operating-system, user or application policy, then chooses compatible configuration inside that domain.

The standard intentionally leaves room for local judgment. Security, cost, reachability, captive state, application scope and user preference may point in different directions. A corporate application can legitimately use a restricted enterprise PvD while a browser uses a general-access PvD on the same device. One domain does not have to win the machine.

The Router Advertisement names a context

RFC 8801 places the PvD Option in IPv6 Router Advertisements as Neighbor Discovery option type 21. The option carries a PvD ID encoded as a fully qualified domain name, flags, a sequence number, a delay value and, when indicated, nested Router Advertisement information.

The FQDN is not decorative. The operator advertising it is expected to own and manage the name. The same ID should represent service that is ultimately identical; materially different services should use distinct IDs. This gives an operator a stable namespace for a configuration context without pretending that the name itself authenticates the local router.

The flags are capability statements with narrow meanings. H says additional information is available over HTTPS. L associates legacy DHCPv4 information. R indicates that an inner RA header and options are present for PvD-aware hosts. H does not prove a host fetched the object, that the certificate validated or that the JSON was accepted. R does not say the domain is preferred. L does not merge every DHCP observation into the domain.

The sequence number is equally easy to overread. A change invalidates previously retrieved additional information and can initiate a delayed refresh. It is not a priority score. A PvD with sequence 42 does not outrank one with sequence 7; the values belong to different update streams.

Additional information must travel inside its own domain

When H is set, a host may request https://<PvD-ID>/.well-known/pvd. When H is clear, it must not use that discovery mechanism. The response uses the application/pvd+json media type and can expose information too large or noncritical for a Router Advertisement.

RFC 8801 imposes a stringent path invariant on the retrieval. DNS resolution of the PvD ID, certificate-status traffic, the HTTPS request, source-address selection and next-hop selection must all use configuration from the PvD being evaluated. The host cannot ask one network's resolver where another network's metadata server is, then fetch it through a third route and still claim an intact binding.

This is more than implementation neatness. Split DNS can make the same FQDN resolve differently by context. A source prefix can determine which first-hop router will return traffic. Sending the query through another PvD can leak which operator-specific domain the host has encountered. The retrieval path is part of the evidence.

The TLS certificate must contain a DNS-ID equal to the PvD ID. If validation fails, the host closes the connection and treats that PvD as having no additional information. This proves that the FQDN owner authorizes the information service for the name. It does not, by itself, prove that the local Router Advertisement was honest or that every claimed prefix belongs in the domain.

The JSON closes a second binding

A valid object contains identifier, expires and prefixes. The identifier must match the advertised PvD ID. The expiry must be a future time. The prefixes must cover every Prefix Information Option associated with the Router Advertisement; otherwise the information is misconfigured and must not be used.

These checks join two statements made on different surfaces. The local router says, “this configuration belongs to this PvD name.” The authenticated information service says, “this name recognizes these prefixes.” An attacker controlling only one surface cannot silently substitute every part of the relationship.

Optional keys add bounded meaning. dnsZones can identify names available through the domain. noInternet: true says the PvD is restricted. It does not say the configuration is invalid, unreachable or worthless. A hospital, factory or enterprise service can be intentionally local. The right question is whether that scope satisfies the application requesting a connection.

Unknown keys are ignored so the format can evolve. IANA maintains the shared registry, while private experiments belong in organizational or vendor-* sub-dictionaries. Registration gives a key interoperable syntax and review; it does not prove that an advertised value is accurate or widely implemented.

Freshness has a stopping rule

The sequence number and JSON expiry prevent a host from treating one retrieved object as permanent. A sequence change or expiry deprecates the information. The Delay field and randomized refresh windows reduce synchronized load when many hosts observe an update together.

Absolute time remains a weak foundation for security. A host clock can be wrong, so RFC 8801 warns against using the expiry value for security-sensitive decisions. Freshness is a maintenance signal, not an independent trust anchor.

The protocol also treats retrieval as an attack surface. An adversarial router could emit many PvD IDs and cause hosts to open DNS, TLS and HTTP exchanges toward arbitrary servers. Hosts rate-limit requests, stop retrying a PvD after invalid TLS, HTTP or JSON, and stop all such retrieval on the current network attachment after repeated failures. An operator that sets H also assumes a service obligation: even a captive portal must allow the necessary DNS, certificate and HTTPS traffic before login.

Privacy is part of the same boundary. A host should use a temporary IPv6 address when one is available in the PvD and avoid cookies or identifying headers. Otherwise an optional metadata fetch can become the first durable correlation event after attachment.

Selection occurs on the host

Once the host has assembled eligible configuration sets, policy decides which one fits a connection. That policy may be embedded in the operating system, expressed by the user or supplied by the application. RFC 7556 provides the consistency model, not a universal ranking formula.

This separates operator authority from host authority. The operator names and supplies a domain. The FQDN owner authenticates the additional-information endpoint. The object describes properties and bounds. The host decides whether those properties meet a current purpose. Then the running connection proves which source address, resolver, next hop and destination were actually used.

Running-Code Primacy is especially concrete here. A label in an RA is a useful common convention only because implementations preserve its associations. The minimum shared specification keeps configuration from being mixed accidentally. It need not centralize every application decision in the router, nor let the host reinterpret the operator's domain arbitrarily.

Sources