Summary

  • RFC 5223's DHCPv4 option 137 and DHCPv6 option 51 each carry one FQDN. A valid decode proves that one configuration value arrived; it does not prove who legitimately supplied it or what service the name will ultimately reach.
  • The FQDN is input to a U-NAPTR and DNS resolution chain. DNS selection, address resolution, protected transport, service-identity checking and the later LoST exchange are independent receipts, not invisible properties of the DHCP option.
  • An honest control plane records every join from network attachment to responder outcome. A single discovered=true flag erases the exact boundary the standard preserves.

One green light, six exchanges too early

Consider a constructed audit sequence, not a reported incident. At 08:14:00 an endpoint joins an access network and asks for configuration. At 08:14:01 a DHCPACK arrives with option 137. Its payload decodes cleanly to lost.access.example and ends in exactly one DNS root label. At 08:14:02 the discovery dashboard turns green.

Nothing in that green light yet records a U-NAPTR response. There is no selected service record, resolved address, DNS validation state, transport peer, TLS service-identity result, LoST XML response, mapping version, contact URI, signaling attempt or responder answer. The parser succeeded. The dashboard silently promoted syntax into authority.

RFC 5223 is more disciplined. It defines a DHCPv4 option and a DHCPv6 option that let a client obtain a domain name for local LoST discovery. The access network may run the service itself or know a third party that does. The name is then fed into the DNS-based LoST discovery procedure. That sequence contains verbs—supply, resolve, connect, authenticate, query, map—which should never be compressed into one past tense.

The document's small scope is its strength. It does not ask DHCP to return the final mapping or emergency contact. It does not pretend the access network can testify about a session that has not happened. It standardizes the handoff.

Option 137 carries one name, not a failover policy

The DHCPv4 field is OPTION_V4_LOST, code 137. The DHCPv6 equivalent is OPTION_V6_LOST, code 51. In both cases the payload is one FQDN encoded as DNS labels, limited by the ordinary label and name-length rules and terminated by a single root label. The client may request the value through the appropriate DHCP option-request mechanism.

This sounds like wire trivia until an operator tries to reconstruct a failure. The field is not an IP address. It is not a URI. It is not an ordered collection of preferred LoST servers. It is one name to be used as discovery input. The caption in the IPv6 figure says “List,” but the normative text immediately states that the option contains a single domain name. Treating it as an invented failover list creates policy the standard did not supply.

An audit receipt should therefore preserve the raw option bytes, option code, transaction context, decoded FQDN and syntax verdict separately. If a system stores only the decoded string, it cannot later show whether a malformed encoding was accepted. If it stores only “option present,” it cannot distinguish a value change from a stable configuration. If it stores only the final IP address, it has erased the standard's deliberate DNS indirection.

The same restraint applies to an IANA assignment. A registered code makes implementations agree on the field's meaning. It does not make every value carried in that field legitimate. Syntax coordinates machines; it does not appoint the speaker.

DHCP can identify a supplier without proving the service

RFC 2131 defines the DHCPv4 client-server exchange, including server selection, acknowledgements, configuration parameters and lease behavior. RFC 8415 supplies the modern DHCPv6 base. These exchanges can tell an endpoint what configuration the selected DHCP path offered at a moment in time.

That receipt is valuable and bounded. The DHCP server identifier identifies a participant in the configuration exchange. It does not prove that the named LoST service is operated by the same party, authorised for every location, reachable from the client or current after the endpoint changes networks. RFC 3046 can add relay-agent information that helps locate the access path. Relay metadata is topology evidence, not a service credential.

The distinction becomes critical at renewal and mobility. A client may retain configuration across part of a lease lifecycle. A laptop, handset or vehicle may attach through another interface or administrative network. If the implementation treats the LoST FQDN as timeless application configuration rather than attachment-scoped input, a once-correct pointer can outlive the network context that supplied it.

The minimum useful record joins the FQDN to interface identity, DHCP transaction, server identifier, relay path where present, receipt time, lease state and the event that invalidated or refreshed it. Without that join, “we used the network-provided LoST server” cannot answer which network or which moment the word “provided” describes.

The standard names the rogue-server risk directly

RFC 5223 does not leave the trust problem implicit. If an adversary modifies a DHCP response or inserts one, the client may be directed to a rogue LoST server or an invalid address. RFC 5069 places this within the security problem of emergency-service marking and mapping.

RFC 3118 specifies authentication and replay-related protection for DHCP messages. Its existence establishes an evidentiary layer: origin, integrity and replay state are separate from option syntax. It does not justify claiming that every production network deploys those mechanisms. A compliance report must record what was actually verified, not upgrade an available RFC into an observed control.

Nor does a trusted DHCP exchange settle every later question. An authenticated network can be misconfigured. A legitimate server can carry an obsolete FQDN. Administrative authority over access configuration is not automatically authority over every emergency mapping jurisdiction. The right control question is not “Was DHCP secure?” in the abstract. It is “Which protections were checked for this message, and what downstream assertions did they actually bind?”

Heng Lu's running-code principle supplies the practical test. Authority becomes operational where a component consumes an input, makes a bounded decision and exposes verifiable state. A DHCP client can prove the configuration it accepted. It cannot, from that proof alone, speak for the DNS operator, LoST authority or responder.

A domain name starts a resolution chain

RFC 5223 says the supplied domain becomes input to LoST's DNS-based discovery procedure. RFC 5222 defines the next steps and the eventual mapping protocol. Between one FQDN and a usable LoST exchange sit U-NAPTR processing, DNS answers, target and transport selection, address resolution and connection establishment.

Each step can fail while the original option remains perfectly valid. The FQDN can have no suitable service record. DNS can time out. A target can resolve to an unreachable address. A transport connection can fail. The peer can present an identity that does not match the intended service. RFC 8446 protects TLS exchanges, while RFC 9525 sharpens the service-identity question. Encryption to a peer selected through a corrupted chain is still encryption to the wrong peer.

That is why “DNS worked” is also too broad. A receipt should retain the question, answer, TTL, selected service record, address set, validation status where applicable, resolver path and decision time. A later IP address should not be backfilled into the original DHCP event as though DHCP had supplied it.

RFC 8917 later assigns a distinct S-NAPTR application-service tag for LoST validation. That separation is architectural evidence: discovery semantics can distinguish roles. A role label says which kind of service the client sought. It does not attest that the returned server performed the role correctly.

Reaching a LoST peer is not obtaining a valid mapping

Even successful DNS and TLS complete only the discovery and transport portion of the chain. A LoST request must still be formed, accepted and interpreted. The response may contain an error, warning, redirect or mapping whose source, age, boundary and applicability require their own checks.

The live RFC 5222 Article already owns that later boundary: a mapping result is not proof of current physical location, session establishment or delivered emergency service. RFC 5223 sits one layer earlier. Its option cannot pre-authorise mapping content the client has not received.

RFC 6739 protects server-to-server mapping synchronization and provenance. That can strengthen the backend source chain. It does not retroactively authenticate a forged DHCPACK, prove the client's DNS view, or show which peer the client reached. Backend integrity and client-path integrity meet only when their receipts can be joined.

RFC 6881 places discovery and mapping within the wider operational practice of emergency calling. That context should prevent category errors. Location acquisition, network configuration, service discovery, mapping, signaling and responder handling are connected dependencies. They are not synonyms.

Keep the chain narrow enough to debug

An accountable record can be compact without being vague:

  1. attachment interface and administrative network context;
  2. DHCP transaction, server identifier, relay evidence and receipt time;
  3. verified message-origin, integrity and replay state;
  4. raw option 137 or 51 and decoded single FQDN;
  5. lease/configuration lifetime and invalidation event;
  6. U-NAPTR query, response and selected service record;
  7. DNS address response, TTL and validation state;
  8. endpoint connection and TLS service-identity result;
  9. LoST request, response type and mapping provenance;
  10. mapping suitability for the location and service;
  11. downstream signaling result;
  12. responder acceptance and operational outcome.

No line inherits the authority of the next. That is not bureaucratic fragmentation. It is the shortest path to locating a break without accusing the wrong system.

Sources

  1. RFC 5223
  2. RFC 5223 on IETF Datatracker
  3. RFC 5223 status
  4. RFC 5223 history
  5. RFC 5223 errata
  6. RFC 2131
  7. RFC 2132
  8. RFC 8415
  9. RFC 3118
  10. RFC 3046
  11. RFC 5222
  12. RFC 5069
  13. RFC 6881
  14. RFC 8917
  15. RFC 6739
  16. RFC 8446
  17. RFC 9525
  18. Heng Lu — Running-Code Primacy
  19. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption