Summary

  • RFC 9527 defines three DHCPv6 options that deliver a Registered Homenet Domain and the forward and reverse Distribution Manager coordinates to a Homenet Naming Authority.
  • A correct Reply proves that configuration crossed one control channel. It does not prove parent delegation, zone acceptance, DNSSEC validity, authoritative reachability or clean retirement of old state.
  • Operators should keep seven linked receipts: configuration, authority, control-channel authentication, publication, validation, external reachability and lifecycle recovery.

The replacement router booted, requested its options and received exactly what the ISP intended. The Registered Homenet Domain matched the subscriber record. The forward Distribution Manager and Reverse Distribution Manager names were present. Both advertised the required transport. The dashboard turned green.

Outside the home, resolvers still reached the zone published by the retired router.

That is an illustrative control failure, not a reported incident. It identifies the boundary of RFC 9527. The standard makes an important part of Homenet naming automatable: it tells a Homenet Naming Authority, or HNA, which domain and managers to use. It does not collapse configuration, authority, publication and observation into one event.

Three options make the handoff concrete

The first option, OPTION_REGISTERED_DOMAIN with code 145, carries the fully qualified domain name associated with the home network. The second, OPTION_FORWARD_DIST_MANAGER with code 146, carries the forward Distribution Manager FQDN and supported transports. The third, OPTION_REVERSE_DIST_MANAGER with code 147, does the same for the reverse side.

The client asks for those codes through the DHCPv6 Option Request Option. A configured server returns them in its Reply. The client then passes the values to the HNA. This is useful evidence: it can show which server supplied which bytes, on which interface, under which lease and at what time.

It is still configuration evidence. The manager FQDN must resolve. A connection must be made. The HNA must be authenticated. The zone must be built and accepted. Parent and reverse delegations must point to the intended authority. Authoritative servers must serve the intended version. None of those outcomes is encoded in the mere presence of options 145, 146 and 147.

RFC 9526 begins where the Reply ends

RFC 9527 deliberately relies on RFC 9526 for the outsourcing procedure. After receiving the options, the HNA should proceed under that protocol: authenticate to the Distribution Manager and Reverse Distribution Manager, construct the public forward or reverse zone and upload it.

This separation is architecturally healthy. DHCPv6 is carrying coordinates. The naming workflow is establishing authority and changing DNS state. Treating the former as proof of the latter erases the most failure-prone transitions.

The transport field makes the distinction visible. RFC 9527 requires the DomTLS bit in manager options. That says the manager supports DNS over mutually authenticated TLS and DNS zone transfer over TLS. A set bit is not a completed TLS exchange. It is not proof of the peer certificate used, the trust rule applied, the zone serial accepted or the response later served to an independent resolver.

A registry coordinates meaning, not deployment

IANA records the three DHCPv6 codes and the Supported Transport registry. This prevents two implementations from assigning different meanings to the same values. It gives software a shared vocabulary.

It does not certify that a CPE requests the options, that an ISP populates them correctly, that a manager accepts the HNA or that public authority follows the subscriber when hardware changes. Registry state is specification evidence. Product behavior and running service remain separate.

The same distinction applies to a green DHCP trace. A Reply can be byte-perfect while the server holds a stale subscriber-domain association. The HNA can accept a manager FQDN whose DNS points to an old endpoint. A manager can authenticate the HNA yet reject the zone. A parent delegation can lag behind a successful upload. DNSSEC can fail because DS and DNSKEY state cross at different times.

Forward and reverse authority can diverge

RFC 9527 carries separate forward and reverse manager options because the control relationships can differ. An ISP naturally controls the delegated prefix and may host reverse authority, while a third party can host the subscriber's forward domain. A single “naming configured” flag hides that split.

The receipt should therefore identify the forward and reverse paths independently: registered domain, delegated prefix, manager, authenticated endpoint, accepted zone version, authoritative server set, signature state and observed answers. Success on one side must not be projected onto the other.

This matters during prefix rotation. A new prefix can arrive while the old reverse zone remains visible. Forward names can point to the new address while reverse records lag. Both zones can be individually valid but mutually inconsistent. DHCP lease state alone cannot resolve which public observation is authoritative for a given time.

Zero configuration concentrates control

The base scenario lets one ISP operate the DHCPv6 server, forward manager and reverse manager. The gain is real: a subscriber can replace equipment without manually rebuilding naming configuration. The cost is concentration. The same organisation can assign the domain, name the managers, authenticate the HNA and host the authoritative service.

That arrangement deserves evidence, not suspicion. A provider may operate it well. But a dashboard sourced only from the provider's internal steps cannot prove what independent recursive resolvers see. The control surface should expose both the internal custody chain and an external observation.

Third-party domains add more joins. The subscriber may register a separate name and redirect it to an ISP-provided domain, or use a third-party DNS infrastructure. Domain ownership, registrar state, redirection, HNA credentials and manager acceptance then belong to different actors. RFC 9527 can deliver the intended coordinates without proving those actors agree.

Multiple ISPs add another lifecycle problem. Each interface may receive a different Registered Homenet Domain. RFC 9527 says handling multiple domains is an implementation issue. That means failover of access connectivity is not automatically failover of naming authority. Operators must decide which domain survives, how stale zones are retired and which observation closes the incident.

Seven receipts preserve the reality layers

The first receipt records configuration: Solicit/Request/Reply context, raw option bytes, server identity, interface, lease and time. The second records authority: who controls the Registered Homenet Domain and reverse prefix, plus the parent delegation expected for each.

The third records the control channel: resolved manager address, mutually authenticated TLS peer, certificate rule and accepted transaction. The fourth records publication: zone version or serial, forward and reverse contents, authoritative-server set and acceptance time.

The fifth records validation: DNSSEC chain, signature validity and negative-answer behavior. The sixth records reachability from independent networks over IPv4 and IPv6. The seventh records lifecycle: renew, rebind, prefix change, router replacement, multi-ISP switch, rollback and verified retirement of the superseded zone.

Heng Lu's distinction between specification, running code and observed reality is practical here. The RFC defines a portable minimum. Local operators decide how to join it to credentials, providers and recovery. Public DNS supplies the external observation. A credible assurance claim keeps those layers connected without pretending they are identical.

What the evidence does not establish

The source set contains no deployment census, named outage, vendor-support inventory or measured failure rate. The replacement-router opening is a control hypothesis. RFC 9527 does not promise that a DHCPv6 Reply alone creates delegation, publishes a zone or proves reachability.

That limitation does not diminish the standard. It clarifies what its success can honestly authorize. “The HNA received the RFC 9527 configuration” is a precise claim. “The home is authoritatively named on the public Internet” requires the rest of the chain.

Sources