Summary

  • RFC 5223 defines DHCPv4 option 137 and DHCPv6 option 51 to deliver exactly one encoded LoST server FQDN. The name becomes input to DNS-based U-NAPTR resolution; it is not itself a server address, authenticated authority, mapping answer or completed emergency request.
  • Leadership needs a discovery-chain receipt that separates DHCP provenance, option parsing, FQDN, DNS/U-NAPTR result, selected URI and address, LoST security, mapping response and downstream service outcome.

The access network handed the client a noun, not a guarantee

A device joined a network and asked DHCP for the local LoST discovery option. The reply contained a well-formed domain. Its labels decoded cleanly, the final root label was present and the configuration agent accepted it. A dashboard could reasonably mark the DHCP step complete.

Nothing in that completion establishes that the domain belongs to the right operational principal. It does not show what DNS and U-NAPTR will return, whether the selected LoST service is authentic, whether its mapping is current, or whether anyone will answer an emergency request.

RFC 5223 is precise about what it transports. The DHCPv4 option numbered 137 and DHCPv6 option numbered 51 carry one fully qualified domain name. That name is used as input to the DNS-based resolution procedure described through LoST and URI-enabled NAPTR. The RFC does not collapse the chain into one discovery event.

That narrowness is the control. The access network supplies a starting point. Every later claim needs its own evidence.

One option, one domain, several independent transitions

The wire format is deliberately constrained. Labels follow RFC 1035 encoding, each label has a length octet, the entire name is at most 255 octets, and the option must contain exactly one root-terminated domain. These rules let an implementation decide whether the option is syntactically valid.

Syntax is not provenance. A client must still establish which DHCP exchange supplied the value and which administrative domain was authorised to do so. The FQDN then feeds a DNS/U-NAPTR procedure, which yields another object. Resolution can change with time, resolver view and network attachment. The selected URI or address then leads to a service whose identity and LoST security properties must be evaluated.

Only after that can a mapping query be considered. RFC 5222 owns the separate questions of submitted location, mapping source, expiry, boundary and returned destination. A returned URI still does not prove that a downstream responder answered. Each stage transforms evidence; none inherits the authority of the previous stage.

Local discovery creates a delegation decision

RFC 5223 allows an access network that operates a LoST server, or knows a third party that does, to provide the discovery domain. That is operationally useful. It is also a delegation: the access network influences which discovery namespace the client enters.

The party operating DHCP may not operate DNS. The DNS operator may delegate U-NAPTR records to another party. The resolved LoST service may be run by a third party. Emergency service destinations lie still further downstream. Treating the DHCP operator as the implicit guarantor of every later step erases the actual control boundaries.

A serious record therefore names the principals. Who authorised the DHCP option? Who owns the domain? Who controls the relevant DNS records? Which LoST identity was expected? Who can revoke a bad delegation? Who detects that a network attachment supplied a different domain from the one previously observed?

Without those answers, “locally discovered” is a routing convenience, not an accountability model.

The security failure can begin before DNS

RFC 5223 warns that an adversary who modifies a DHCP response or inserts a response can lead the client to a rogue LoST server or give it an invalid address. The threat appears before the client has made a LoST request. A perfectly functioning DNS resolver cannot repair a domain selected by a malicious discovery response.

The opposite is also true: authentic DHCP does not make all later resolution trustworthy. The chain needs controls at the boundaries appropriate to each stage. DHCP provenance, DNS security and consistency, U-NAPTR interpretation, server authentication, LoST protocol protections, mapping freshness and downstream reachability answer different questions.

Failure modes should remain distinguishable. No option received is different from malformed option data. A valid FQDN with no usable U-NAPTR result is different from a result that points to an unauthenticated service. A secure service that returns no mapping is different from a mapping whose eventual destination cannot be reached.

Proximity is an objective, not a measured outcome

The RFC says that placing a LoST server closer to the end host is desirable and may improve resilience during disaster conditions with intermittent connectivity. That is a design rationale. It is not a measurement of latency, availability or emergency-service performance in a named network.

Closer in topology also does not automatically mean controlled by the access provider, authoritative for every location, reachable after all failures or synchronized with other mapping systems. Resilience must be observed across the actual dependency chain: DHCP renewal, resolver availability, record freshness, service authentication, mapping response and downstream communication.

An organisation should therefore avoid using “local server discovered” as a resilience score. It should publish the dependency graph and test the failure combinations that the design is meant to survive.

What the record does not establish

These standards do not prove a current deployment of option 137 or option 51. They do not identify a compromised DHCP server, rogue LoST service, failed emergency request or vendor defect. RFC 3315 is the historical DHCPv6 reference used by RFC 5223 and was later obsoleted by RFC 8415; that status does not by itself prove or disprove current use of the LoST option.

This analysis also stops before the RFC 5222 boundary already covered elsewhere. It does not claim that a valid mapping proves physical presence or delivered emergency service. Its proposition is earlier and narrower: the domain delivered by DHCP is a discovery input, and every authority and outcome beyond that input must be proved separately.

Build a discovery-chain receipt

For each observed discovery, record the network attachment, DHCP version, server identity or provenance available, option code, raw option hash, parse result, FQDN and root-label validity, lease or observation time, resolver view, U-NAPTR records, TTLs, selected URI and address, server identity check, LoST request and response identifiers, mapping age, downstream attempt and application outcome.

Keep negative evidence. Missing options, competing replies, malformed labels, unexpected domain changes, failed NAPTR processing, inconsistent resolver views, expired records, authentication failures, fallback to manual configuration and unreachable services define the real discovery surface.

Lu Heng's running-code and agency frame makes the responsibility split explicit. The access network can attest to its DHCP configuration. The domain operator can attest to DNS delegation. The LoST operator can attest to service behavior. The application can attest to the downstream result. Leadership should require the chain, not allow one operator's receipt to stand in for everyone else's authority.

Sources

Additional standards record

  1. RFC 5223 plain text
  2. RFC 5223 information record
  3. RFC 5223 Datatracker record
  4. RFC 5223 errata record