Discovery of Agents With Names Y. Cui Internet-Draft Tsinghua University Intended status: Standards Track November 2026 Expires: 5 May 2027 Discovery of LLM API Services in Local Networks draft-cui-dawn-local-llm-api-discovery-00 Abstract Large Language Model (LLM) API services can be hosted on workstations, local servers, and other devices in a local network. AI applications commonly access these services through manually configured API base URLs and interface settings. When an application joins a different network or a service address changes, these settings may need to be updated even when a suitable local service is already available. This document specifies a DNS-Based Service Discovery (DNS-SD) profile for discovering LLM API services on a local link. An advertiser publishes the service location and a small set of API connection parameters. A discovery client resolves these records and offers the resulting connection information to an AI application or its configuration adapter. Subsequent LLM API requests are sent directly to the discovered service, not through the advertiser or discovery client. Discovery does not establish trust, distribute credentials, select models, or define an application's configuration file format. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cui-dawn-local-llm-api- discovery/. Discussion of this document takes place on the dawn Working Group mailing list (mailto:dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn/. Subscribe at https://www.ietf.org/mailman/listinfo/dawn/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Cui Expires 5 May 2027 [Page 1] Internet-Draft Local LLM API Discovery November 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope and Terminology . . . . . . . . . . . . . . . . . . . . 4 4. Use Cases and Architecture . . . . . . . . . . . . . . . . . 5 5. LLM API Service Advertisement . . . . . . . . . . . . . . . . 5 5.1. Service Type and DNS-SD Records . . . . . . . . . . . . . 5 5.2. TXT Parameters . . . . . . . . . . . . . . . . . . . . . 6 5.3. API Profile Binding . . . . . . . . . . . . . . . . . . . 8 6. Discovery Procedure and Application Handoff . . . . . . . . . 8 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Cui Expires 5 May 2027 [Page 2] Internet-Draft Local LLM API Discovery November 2026 1. Introduction An LLM API running on a workstation or an enterprise server may be reachable over a local network, yet an AI application cannot use it without knowing its API address and interface conventions. Today these settings are often entered manually. For example, a developer may need to edit an AI coding tool's base URL when moving from an office network to a home network, even though both networks offer accessible LLM services. Multicast DNS (mDNS) [RFC6762] and DNS-SD [RFC6763] already provide a way to discover network services without prior knowledge of their addresses. This document does not define another discovery transport. It defines how an LLM API service is advertised through DNS-SD, how a client obtains the minimum API connection information, and how that information may be passed to an AI tool after local approval. The advertised endpoint is the *actual LLM API service*. The component that publishes DNS-SD records may be a separate process and does not need to receive or forward model inference requests. 2. Problem Statement A locally deployed LLM service is typically configured in an AI application by supplying a base URL, an API interface type, and, when applicable, authentication and model settings. These settings are specific to a deployment rather than to the network service-discovery mechanisms already available to the operating system. This creates a recurring configuration problem. A laptop can move between an enterprise network, a home network, and a temporary development network, each with its own LLM API services. A service can also move to another host or port without changing its function. A client with a previously configured static endpoint does not automatically learn that a different local service is now available. The problem is *initial discovery and configuration of an accessible API endpoint*, not discovery of GPU hardware or selection of the best model. A common DNS-SD service profile is needed so that an advertiser and an independently implemented discovery client agree on (1) which local services are LLM APIs, (2) where their API endpoints are located, and (3) which API interface the client must support. The discovery result can then be supplied to an AI application without requiring the user to re-enter the endpoint manually. Cui Expires 5 May 2027 [Page 3] Internet-Draft Local LLM API Discovery November 2026 3. Scope and Terminology This document specifies discovery on a single local link using mDNS and DNS-SD. It covers directly hosted LLM API services as well as LLM APIs hosted behind a local proxy; the discovery procedure does not depend on the server's internal deployment architecture. It defines the service advertisement, minimum fields, discovery and resolution behavior, and the handoff of a candidate configuration. It does not define LLM inference messages, credential issuance, API key discovery, model selection, model catalogs, GPU resource discovery, or the configuration format of a particular AI application. Discovery across subnets, VLANs, or the public Internet is outside scope. This initial revision defines an API Profile binding for Open Responses. Additional LLM API interfaces can be supported through separately specified bindings. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. * *LLM API Service:* The HTTP-based [RFC9110] endpoint that receives LLM API requests. It may be hosted directly by a model server or exposed by a proxy. * *Discovery Advertiser:* A component configured by the service operator to publish DNS-SD records for an LLM API Service. It may run in the service process or separately. * *Discovery Client:* A component that browses DNS-SD services, resolves and checks their records, and constructs candidate API connection information. * *AI Application:* An AI coding tool, assistant, or other application that uses an LLM API. A local adapter or plugin may pass discovery results into the application's settings. * *API Profile:* An identifier for the application-layer API convention expected at a discovered endpoint. It is distinct from a model name. * *Candidate Configuration:* A discovered API address and profile that has not yet been approved or authenticated for use. Cui Expires 5 May 2027 [Page 4] Internet-Draft Local LLM API Discovery November 2026 4. Use Cases and Architecture The principal use case is a laptop running an AI application that moves between networks. On the office network, an authorized local LLM service is advertised by the enterprise. On the home network, a workstation exposes a different LLM API. In either location, the discovery client can locate an available API and present a candidate configuration. The application can use that configuration only after the applicable approval and security checks. The following diagram illustrates the discovery and configuration handoff process. Subsequent LLM API communication is not shown. +------------------+ +-------------+ | LLM API Service |--->| Discovery | | (Actual Server) | | Advertiser | +------------------+ +-------------+ Service Info mDNS / DNS-SD | v +-----------------+ +-----------------+ | Discovery |--->| AI Tool | | Client / Plugin | | (Configuration) | +-----------------+ +-----------------+ API Connection Info The advertiser MUST obtain its service information from the operator or another authorized local configuration source. This document does not define the advertiser-to-server configuration interface. The discovery client may be implemented as a plugin within an AI application or as a local helper. How it writes or updates application-specific settings is outside the wire protocol. 5. LLM API Service Advertisement 5.1. Service Type and DNS-SD Records This document proposes _llm-api._tcp as the DNS-SD service type for LLM API endpoints. On the local link, the corresponding browse name is _llm-api._tcp.local.. The service name is proposed for registration and is not assumed to be already assigned. The advertiser MUST publish the DNS-SD information needed to browse and resolve a service instance: * *PTR:* Identifies an advertised LLM API service instance. * *SRV:* Identifies the service host and listening port. Cui Expires 5 May 2027 [Page 5] Internet-Draft Local LLM API Discovery November 2026 * *TXT:* Carries the minimum API connection parameters specified below. * *A/AAAA:* Resolves the SRV target to an address reachable in the intended local-link context. One instance describes one API Profile at one API base path on one listener. A listener that supports multiple distinct API Profiles MAY publish a separate service instance for each. A service offering several models through the same API Profile does not need one discovery instance per model. A Discovery Advertiser MUST NOT place credentials, prompts, complete model catalogs, or GPU resource details in TXT records. SRV already carries the host and port, which MUST NOT be duplicated in TXT [RFC6763]. 5.2. TXT Parameters This version proposes the following TXT keys. All keys and values follow the DNS-SD TXT encoding rules in [RFC6763]. The table defines the *discovery interface*, not a model invocation API. Cui Expires 5 May 2027 [Page 6] Internet-Draft Local LLM API Discovery November 2026 +===========+=============+================+======================+ | Key | Requirement | Meaning | Example | +===========+=============+================+======================+ | txtvers | REQUIRED | Version of | txtvers=1 | | | | this TXT | | | | | record format | | +-----------+-------------+----------------+----------------------+ | api | REQUIRED | Identifier of | api=openresponses | | | | the advertised | | | | | API Profile | | +-----------+-------------+----------------+----------------------+ | protovers | Conditional | Version of the | protovers=2026-04-24 | | | | API Profile, | | | | | when required | | | | | by its binding | | +-----------+-------------+----------------+----------------------+ | scheme | REQUIRED | URL scheme, | scheme=https | | | | http or https | | +-----------+-------------+----------------+----------------------+ | base | REQUIRED | Path component | base=/v1 | | | | of the API | | | | | base URL | | +-----------+-------------+----------------+----------------------+ | auth | OPTIONAL | Authentication | auth=required | | | | hint: required | | | | | or none | | +-----------+-------------+----------------+----------------------+ Table 1 The txtvers, api, scheme, and base parameters MUST be present and nonempty. The advertiser SHOULD place txtvers first in the TXT record, as recommended by [RFC6763]. A Discovery Client MUST NOT interpret an unsupported TXT format version using version 1 rules. Unknown TXT keys MUST be ignored in accordance with [RFC6763]. The protovers parameter MUST be present when required by the selected API Profile binding. An unknown API Profile MUST NOT be treated as supported. An absent auth parameter indicates that the authentication requirement is unknown; auth=none does not constitute authorization. The base value MUST be either / or an absolute URI path beginning with / and not ending with /. It MUST NOT contain a scheme, authority, query, fragment, or userinfo, and MUST NOT contain . or .. path segments. The Discovery Client MUST reject malformed values rather than silently repairing them. Cui Expires 5 May 2027 [Page 7] Internet-Draft Local LLM API Discovery November 2026 The API base URL is constructed using the advertised scheme, the SRV target host, the SRV port, and the base path, following [RFC3986]. Operation-specific paths are appended according to the selected API Profile binding without introducing duplicate slashes or additional version prefixes. For example, an SRV target llm-node.local., port 8443, scheme=https, and base=/v1 produce the candidate API base URL https://llm- node.local:8443/v1. No fixed port or universal /v1 prefix is required: the path is taken from the actual service advertisement. 5.3. API Profile Binding The api parameter identifies the API Profile exposed by the discovered service. An API Profile defines the interface convention and the rules for interpreting the advertised API base URL. A Discovery Client MUST NOT assume that different API Profiles are interchangeable. This document defines an initial binding for api=openresponses, using protovers=2026-04-24 to identify the Open Responses specification [OPENRESPONSES]. For this binding, the response creation operation uses HTTP POST at the relative path responses. For example, a base path of /v1 yields /v1/responses. An advertiser using this binding MUST set auth=required. Other interfaces, including Chat Completions-style APIs, may be supported through additional API Profile bindings. Each binding needs to specify its identifier, applicable protocol version, and endpoint construction rules. The existence of an API Profile identifier does not by itself establish compatibility between different server implementations. 6. Discovery Procedure and Application Handoff The following diagram illustrates the logical flow of LLM API discovery, from service advertisement to the delivery of candidate connection information to an AI tool. The diagram covers discovery and configuration handoff only; subsequent API communication is outside the discovery process. Cui Expires 5 May 2027 [Page 8] Internet-Draft Local LLM API Discovery November 2026 LLM API Discovery Discovery User/Local AI Service Advertiser Client/Plugin Policy Tool | | | | | |-- Info --->| | | | | | | | | | | Publish DNS-SD | | | | | service records| | | | | | | | | |<--- Browse -----| | | | |---- PTR ------->| | | | | | | | | |<--- Resolve ----| | | | |---- SRV/TXT --->| | | | | A/AAAA | | | | | | | | | | Validate records | | | | Construct API Base URL | | | | | | | | | |-- Candidate ->| | | | |<-- Decision --| | | | | | | | | |-- Approved Configuration ->| | | | | | 1. *Service preparation.* The LLM API Service is already running. Its operator supplies the endpoint and API Profile to the advertiser; this may be an internal process configuration, not a network exchange. 2. *Advertisement.* The advertiser publishes the DNS-SD service instance on the authorized local interface, following mDNS procedures in [RFC6762]. 3. *Discovery.* The client browses _llm-api._tcp.local., resolves the chosen instance, and obtains the SRV and TXT information. 4. *Resolution.* The client validates the parameters and constructs the candidate API base URL and API Profile. It does not make an inference request to verify discovery. 5. *Approval.* The Discovery Client presents the candidate connection information to the user or an independently established local authorization policy. Approval MUST NOT rely solely on the advertised service name. 6. *Configuration handoff.* After approval, the Discovery Client or its adapter MAY provide the API base URL and API Profile to the AI application's configuration mechanism. Application-specific Cui Expires 5 May 2027 [Page 9] Internet-Draft Local LLM API Discovery November 2026 configuration formats are outside the scope of this document. Any required model identifier or credential is obtained separately. 7. *API use.* The AI application communicates directly with the LLM API Service. The service identity MUST be verified before transmitting credentials or sensitive application data. The Discovery Advertiser and Discovery Client do not forward inference requests. On an attachment change, the Discovery Client MUST stop offering candidates from the previous attachment for new connections and rediscover on the current one. It MUST respect DNS-SD record lifetimes and withdrawals. A prior approval or API credential MUST NOT be carried to a newly discovered service merely because the instance name or API Profile matches. Automatic replacement of an active model connection is outside scope. 7. Example The following illustrative DNS-SD records describe an LLM API Server whose API base URL is https://llm-node.local:8443/v1. _llm-api._tcp.local. PTR Office-LLM._llm-api._tcp.local. Office-LLM._llm-api._tcp.local. SRV 0 0 8443 llm-node.local. Office-LLM._llm-api._tcp.local. TXT ( "txtvers=1" "api=openresponses" "protovers=2026-04-24" "scheme=https" "base=/v1" "auth=required" ) llm-node.local. A 192.168.10.20 The discovery client can pass the following _candidate_ values to an application adapter: API profile: openresponses (2026-04-24) API base URL: https://llm-node.local:8443/v1 API operation: POST /v1/responses Authentication: required (hint only) This example does not supply a model identifier, issue a credential, or make a trust decision. The client must be able to authenticate and authorize the intended local endpoint before sending sensitive prompts or credentials. Cui Expires 5 May 2027 [Page 10] Internet-Draft Local LLM API Discovery November 2026 8. Security Considerations mDNS and DNS-SD advertisements on a local network are not inherently trustworthy. A malicious device may forge a service instance, replace the advertised address or API base path, or impersonate a familiar display name. A Discovery Client MUST treat discovery records as untrusted input and MUST NOT transmit credentials or prompts merely because a valid-looking service has been discovered. Clients MUST validate advertised URL components and apply local destination restrictions. For HTTPS endpoints, TLS server identity verification MUST follow [RFC9525]. TLS verification of a name learned only from unauthenticated DNS-SD is not, by itself, sufficient authorization to release existing application credentials or private information; trusted service identity and allowed endpoint scope need an independent policy or trust arrangement. Plain HTTP is permitted as an advertised endpoint for deployments that explicitly allow it, but it MUST NOT be treated as confidentiality- or integrity-protected, and clients MUST NOT send sensitive data or credentials over it. Advertisers SHOULD publish only on intended interfaces and SHOULD avoid disclosing sensitive project or model details. A local network may not be private merely because it uses mDNS. An application MUST NOT reuse a cloud-provider API key for a newly discovered local service without separate authorization. Redirects to a different destination require fresh validation and authorization. This document does not define cryptographic integrity protection for the DNS-SD advertisement. Consequently, discovery records MUST be treated as untrusted information until the intended service and destination have been independently authorized. Authentication of the subsequent HTTPS connection does not, by itself, authenticate the original DNS-SD records. An interoperable mechanism for protecting discovery information and binding it to an authorized service identity remains to be specified or referenced in a future revision. 9. IANA Considerations This document requests registration of the service name llm-api for TCP in the Service Name and Transport Protocol Port Number Registry, following [RFC6335], with the description "LLM API service discovery" and this document as the reference. The registration is for the service name only; no fixed port number is requested. For an assignment resulting from an IETF-stream RFC, the assignee and contact follow the defaults in [RFC6335]. The registered service Cui Expires 5 May 2027 [Page 11] Internet-Draft Local LLM API Discovery November 2026 name is used in DNS-SD as _llm-api._tcp. No new DNS resource record type or port number is requested. This text is a proposed IANA action, not a statement that the service name has already been registered. 10. Normative References [OPENRESPONSES] Open Responses, "Open Responses Specification (2026-04-24)", April 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . Cui Expires 5 May 2027 [Page 12] Internet-Draft Local LLM API Discovery November 2026 [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . Appendix A. Acknowledgements The author would like to thank Chenguang Du and Yihan Chao for their valuable discussions and contributions to the development of this document. Author's Address Yong Cui Tsinghua University Email: cuiyong@tsinghua.edu.cn Cui Expires 5 May 2027 [Page 13]