A ULD Handoff Needs a Local-Service Continuity Receipt

Summary

The first DNSSD working-group draft for Unicast Local Discovery makes clients converge on one preferred server per link and requires a migrating client to re-register all of its services when that server changes.
Selection and continuity are different proofs. A useful handoff receipt should bind the old and new servers, the trigger and preference evidence, the expected registration inventory, acceptance and lease outcomes, proxy visibility, address-family checks, exceptions and fallback.

The handoff that looks healthier than it is

Imagine a small office after its gateway has been replaced. Laptops still reach the Internet. The new router advertises itself as the infrastructure ULD server. Clients compare the available choices, prefer the infrastructure service and move. DNS queries answer. The migration dashboard turns green.

Then a meeting begins. The room display is absent from discovery. One printer is visible over IPv6 but not to an IPv4-only tablet. A sensor registered again, but under a collision-adjusted name that its controller does not know. None of these failures means the new server election was wrong. They mean the election answered a narrower question than the operator thought it answered.

draft-ietf-dnssd-uld-00 is an active IETF DNSSD working-group draft dated 18 August 2026. It proposes Unicast Local Discovery, or ULD, as a way for hosts to advertise and find services on the local link using unicast SRP and DNS while remaining interoperable with mDNS devices. The draft is Standards Track work in progress, would update RFC 6762 if approved, and still contains unfinished Security, SNAC and IANA sections. It is not an RFC and supplies no deployment result on which to base a claim of operational success.

The architecture deliberately gathers several functions behind one service. An SRP registrar accepts service registrations into a .local zone. An authoritative DNS server answers unicast queries. A Discovery Proxy contributes records still advertised through mDNS, while an Advertising Proxy makes SRP registrations visible to mDNS clients. On shared record sets, the answer normally combines the zone and the proxy’s view. The result can look like one catalogue even though its entries arrived through different mechanisms.

That is precisely why continuity cannot be inferred from a responsive DNS endpoint. The server can be alive, authoritative and correctly preferred while one part of the catalogue is incomplete.

ULD elects a server; clients carry the state

ULD does not treat every available server as equivalent. Each server advertises a numeric pri value. Lower numbers are preferred: infrastructure is 0, ordinary ad-hoc services occupy higher bands, and the numerically lowest IPv6 link-local address breaks a tie. An infrastructure server also announces a ULD option in IPv6 Router Advertisements. IPv6 clients must use that option to find the infrastructure service or to verify an infrastructure claim first learned through DNS-SD.

The draft’s operational model is one infrastructure server per link. In a managed network, an operator explicitly enables the designation and must ensure that no more than one router advertises the ULD RA option. In an unmanaged home, a customer-edge router may claim the role by default when it is already the effective gateway. A device that is not clearly the primary gateway must not assume infrastructure status without explicit configuration.

Clients first seek that infrastructure server. If it is absent, they choose among ad-hoc servers. If none works, they fall back to mDNS. Once a client has adopted ULD, it should stop participating directly in mDNS for that link and rely on the selected service for .local operations.

The model is not a one-time election. A client must treat persistent query timeouts, failed SRP lease refreshes or a lost DNS Push session as signs that its server is unavailable. A client using an ad-hoc server must also keep watching for a better candidate. Failure and improvement can therefore produce the same state transition: leave the old server, select another one, and migrate.

At that moment the draft gives the client an unambiguous duty: it must re-register all its services with the new server.

The duty reveals where the continuity risk lives. ULD chooses deterministic convergence rather than requiring the servers to replicate registration state. Appendix C explains the choice. Multiple independent registrars could accept conflicting names and discover the conflict only later through mDNS, perhaps without useful feedback to either client. Getting all clients onto one preferred server avoids that split. It also means the new server does not necessarily inherit the old registrar’s state. The clients must recreate it.

An older, now-expired SRP Replication draft illustrates the alternative. Its purpose was to retain state across server loss, avoid name collisions during changes and sometimes make a failover invisible to clients. ULD revision 00 does not silently import that mechanism. Its handoff depends on clients observing the change and replaying what they own.

“Re-register all” is a requirement, not a receipt

One successful registration proves one service instruction was accepted. It does not prove the client submitted every service it had previously advertised. A count on the new server proves how many entries arrived, but not whether that number matches the client’s intended inventory. A successful DNS browse proves what one query could see from one address family and one cache state. It does not prove that the Advertising Proxy exposed the same records to mDNS clients or that the Discovery Proxy contributed everything it should.

This distinction matters because the transition can produce partial success without producing a total outage. Suppose a device owns four service instances. Three SRP updates are accepted and one conflicts. The server is responsive, the client has a lease and most applications work. If monitoring asks only whether the preferred server changed and whether SRP returned success at least once, the missing fourth service is administratively invisible.

The same problem appears across links. ULD instances and preferred choices are link-scoped. A multihomed host can use ULD on one interface and mDNS on another. A global “migration complete” flag collapses several independent transitions into one statement. It cannot tell an operator which interface, zone or address-family view was actually reconciled.

The required evidence is therefore a handoff receipt. It need not be a new DNS record or an IETF wire object. It can be an implementation and operations record assembled by the client, server and network-management plane. What matters is that its fields answer the continuity question without pretending the protocol already does so.

A defensible receipt would identify the link and interface; the old and new server link-local addresses; their advertised priority, deployment class and tie-break values; and the instant at which the choice changed. It would state whether the trigger was persistent failure, a lease-refresh failure, a lost push session, a newly appeared higher-priority server or explicit operator action.

It would also record why the new server was allowed to claim authority. In a managed network, that means the configuration or change record enabling infrastructure status. In an unmanaged network, it may be the device’s documented gateway role. The receipt can note whether the ULD RA option was observed and which RA Guard policy applied. Neither fact should be promoted into proof of server authentication: the draft permits self-signed certificates, advises clients not to reject them and says authentication is not the goal of this TLS use.

Most important, the receipt would reconcile inventories. Before leaving, the client can commit to a digest of the service descriptions it expects to replay. Afterward it can record each accepted, refused, conflicting or timed-out registration, the granted lease and the retry result. The new server can report a corresponding zone digest. Tests can compare the unicast answer, the Discovery Proxy contribution and the Advertising Proxy’s mDNS-visible result. Dual-stack deployments should include both IPv6 and IPv4 observation, because the discovery paths are not identical.

Exceptions belong in the record rather than outside it. A device may intentionally withdraw a service during the move. A new conflict may require a renamed instance. An IPv4-only client may fall back to mDNS because the preferred server is unreachable over IPv4. Those are legitimate outcomes when they are named. They are not evidence of full continuity when hidden inside one success counter.

Proof without turning the local catalogue into surveillance

A continuity record can itself become a privacy problem. Local service names often reveal people, rooms, device models and routines. Keeping a permanent central copy of every printer, television, camera and personal device would convert operational assurance into an unnecessary inventory of behaviour.

The answer is not to abandon evidence. It is to minimise it. A client can produce a salted digest over canonical service descriptions, counts by coarse service type, and explicit exception codes. The salt and full comparison set can be retained briefly on the device or in a protected operator domain. Longer-lived records can keep only the transition identifier, aggregate counts, discrepancies, timing and the cryptographic commitment needed to show that the comparison was not rewritten later.

Retention should follow the failure window. Keep enough detail to investigate lease expiry, cache turnover and delayed reports, then delete names that are no longer necessary. Access to the receipt should be narrower than access to ordinary network-health metrics. The purpose is to prove that a handoff preserved an intended service surface, not to build a historical directory of every local object.

What the current draft can and cannot support

The draft gives a solid basis for the narrow claim that server preference and registration replay are separate operations. It specifies a deterministic selection order, ongoing monitoring and re-registration on migration. It also makes each link its own scope and requires proxy interoperability that can be checked from more than one client perspective.

It does not specify the receipt described here. Its empty Security Considerations section means no final working-group threat model can be attributed to it. Its reference to RA Guard does not erase the deployment weaknesses catalogued by RFC 7113. Its opportunistic TLS rules do not establish an authenticated appointment chain. And no source in this evidence set supplies measured loss rates, recovery times or multivendor interoperability results.

The careful conclusion is consequently operational, not promotional. ULD can make local discovery more efficient by moving routine traffic to a preferred server. But the moment clients stop speaking mDNS directly and entrust their catalogue to that server, continuity depends on a transition that deserves its own evidence. “We selected the right server” and “our services survived” should never share one checkbox.

A ULD Server Handoff Needs Proof That Local Services Survived

Why it matters

Summary

The handoff that looks healthier than it is

ULD elects a server; clients carry the state

“Re-register all” is a requirement, not a receipt

Proof without turning the local catalogue into surveillance

What the current draft can and cannot support

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing