Network Working Group C. Su Internet-Draft Router-for-Me Intended status: Informational 26 October 2026 Expires: 29 April 2027 DNS-Based Service Discovery for AI Gateways draft-su-ai-gateway-discovery-00 Abstract This document defines how a multi-protocol AI gateway announces itself on a local network using DNS-Based Service Discovery (DNS-SD), and how a client discovers it. A gateway publishes its host name, TCP port, gateway mount path (path), and supported protocol identifiers using _ai-gateway._tcp, DNS-SD subtypes, and a compact, vendor-neutral TXT record. A single AI gateway listener can expose text, reasoning, token counting, image generation, video generation, speech synthesis, realtime voice, and search across HTTP, Server-Sent Events (SSE), WebSocket, and WebRTC/SDP sessions. This profile lets clients discover those capabilities without hardcoding addresses, ports, or vendor-specific TXT keys, while keeping the default DNS TXT payload under 200 bytes (and strictly capped at 400 bytes). This document only covers service discovery. It does not define AI request payloads, model catalogs, API key distribution, or trust bootstrap. Data learned from mDNS or DNS-SD is untrusted network input and does not prove who operates the gateway. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 29 April 2027. Su Expires 29 April 2027 [Page 1] Internet-Draft AI Gateway Discovery October 2026 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 1.1. Status of This Proposal . . . . . . . . . . . . . . . . . 3 1.2. What This Document Covers and What It Does Not . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Service Records . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Service Type and Transports . . . . . . . . . . . . . . . 5 3.2. Instance, Target Host, and IP Addresses . . . . . . . . . 6 3.3. Capability Subtypes and Wire-Protocol Routes . . . . . . 6 3.3.1. Core Subtypes . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Extended Subtypes . . . . . . . . . . . . . . . . . . 7 4. TXT Record Format . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Rules, Key Length Compliance, and the 400-Byte Budget . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Required Attributes . . . . . . . . . . . . . . . . . . . 10 4.3. Validation of path and Endpoint Construction . . . . . . 11 4.4. Optional Attributes and Capability Vocabulary . . . . . . 12 4.4.1. Standard protocols Tokens . . . . . . . . . . . . . . 12 4.4.2. Standard auth_type Tokens . . . . . . . . . . . . . . 13 4.4.3. Exclusion of Management Interfaces . . . . . . . . . 13 5. How a Client Uses Discovery Results . . . . . . . . . . . . . 13 6. Example DNS-SD Records (CLIProxyAPI Default Profile) . . . . 14 7. Operational Guidance . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1. Spoofing on the Local Network . . . . . . . . . . . . . . 16 8.2. Protecting API Keys and Credentials . . . . . . . . . . . 16 8.3. Preventing SSRF and Internal Network Probing . . . . . . 16 8.4. DoS and Local Privacy . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 Su Expires 29 April 2027 [Page 2] Internet-Draft AI Gateway Discovery October 2026 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Local developer tools, CLI agents (such as Codex CLI, Claude Code, and DeepSeekHarness), IDE extensions, and desktop apps increasingly connect to AI models through a unified gateway. Unlike a single- purpose inference server, a full-featured AI gateway (such as CLIProxyAPI) acts as a protocol router and translator across multiple wire protocols and transport modes on a single listening port: * *Text and reasoning*: Open Responses [OpenResponses] (/v1/ responses over HTTP, SSE, compaction, and persistent WebSocket streams), Chat Completions (/v1/chat/completions), Legacy Completions (/v1/completions), Messages (/v1/messages), and GenerateContent / Interactions (/v1beta/ models/{model}:generateContent, :streamGenerateContent, /v1beta/ interactions). * *Token accounting and model metadata*: Authenticated model catalogs (/v1/models, /v1beta/models) and token counting (/v1/messages/count_tokens, :countTokens). * *Multimodal generation*: Image generation and editing (/v1/images/ generations, /v1/images/edits), video generation and retrieval (/v1/videos*), and speech synthesis (/v1/audio/speech, /v1/tts). * *Realtime and agentic extensions*: Realtime WebSocket and WebRTC/ SDP call sessions (/v1/realtime*, /v1/live*) and agentic search (/v1/alpha/search). On a local network, that gateway's IP address or port can change, and users should not have to type connection settings by hand on every device. Multicast DNS (mDNS) [RFC6762] and DNS-Based Service Discovery (DNS- SD) [RFC6763] already solve host and port discovery on a LAN. This document defines a vendor-neutral DNS-SD profile using the proposed service type _ai-gateway._tcp, capability subtypes, and a 9-key TXT record format where every key is at most 9 characters long (per Section 6.4 of [RFC6763]). 1.1. Status of This Proposal This is an initial individual draft (-00). Writing or submitting an Internet-Draft does not mean the IETF has endorsed it, adopted it in a Working Group, or approved it as a standard. Su Expires 29 April 2027 [Page 3] Internet-Draft AI Gateway Discovery October 2026 The service name ai-gateway is a proposal, not an existing IANA assignment. Before submitting an IANA registration request, the author MUST check the current registry, and the final service name might change during review. 1.2. What This Document Covers and What It Does Not This document covers four things: * how to list AI gateways on a local network; * how to find a gateway's host, port, and root mount path (path); * how to advertise supported wire protocols and multimodal capabilities using vendor-neutral identifiers; * how a client validates discovery data safely before authenticating and querying model catalogs. This document does not cover: * model names, per-model capabilities, or model routing rules; * request or response JSON schemas for any AI API; * sending API keys, OAuth tokens, or passwords over discovery; * automatic pairing, trust bootstrap, or certificate issuance; * gateway administration (/v0/management, /v8/management), billing, or control-plane cluster protocols; * wide-area discovery relays or standalone UDP/QUIC mDNS records. 2. Conventions and Terminology 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. Gateway: An HTTP server or reverse proxy that exposes one or more AI wire protocols over a TCP listener. Advertiser: The component that publishes the gateway's DNS-SD records. Su Expires 29 April 2027 [Page 4] Internet-Draft AI Gateway Discovery October 2026 Client: An application, CLI, or library that browses and resolves those records. Gateway mount path (path): The root URI path prefix where the gateway is mounted on the target host (normally /, or a reverse- proxy prefix such as /ai). Each individual wire protocol appends its own standard versioned route (such as /v1/responses or /v1beta/interactions) beneath path. Candidate endpoint: A discovered gateway endpoint that has been parsed, but has not yet been trusted or approved for sending credentials. 3. Service Records 3.1. Service Type and Transports The proposed DNS-SD service type is _ai-gateway._tcp. In the IANA Service Name and Transport Protocol Port Number Registry, this corresponds to service name ai-gateway over TCP. This specification does not ask for a fixed TCP port. Clients MUST read the port from the SRV record and MUST NOT fall back to hardcoded ports such as 80, 443, or 8317. On a local link using mDNS, the discovery domain is local., so the full service browse name is _ai-gateway._tcp.local.. Standard mDNS and DNS-SD rules from [RFC6762] and [RFC6763] apply without change. The advertised TCP listener speaks HTTP [RFC9110], optionally protected by TLS [RFC8446]. Within that HTTP listener, individual endpoints MAY use: * standard HTTP request/response (JSON, binary audio/video content, or SDP payloads [RFC9429]); * Server-Sent Events (SSE) for streaming token or event output; * HTTP/2 [RFC9113] negotiated via ALPN or cleartext upgrade; * WebSocket upgrades [RFC6455] on supported paths (such as /v1/responses and /v1/realtime). Su Expires 29 April 2027 [Page 5] Internet-Draft AI Gateway Discovery October 2026 While _ai-gateway._tcp advertises the initial TCP listener, a gateway that also enables HTTP/3 [RFC9114] over QUIC (when tls=1) MAY upgrade discovered HTTPS connections to HTTP/3 using the standard HTTP Alt- Svc header field [RFC7838]. Direct advertisement of QUIC-only listeners via _ai-gateway._udp or DNS SVCB records is left for a future extension. 3.2. Instance, Target Host, and IP Addresses As required by [RFC6763], an advertiser MUST publish: * a PTR record from _ai-gateway._tcp. to the service instance name; * an SRV record giving the target host name and TCP port for that instance; * a TXT record carrying the metadata defined in this document; * A and/or AAAA records for the target host name. The SRV target is a DNS host name, not a URL. If the SRV target is ., the service is unavailable and clients MUST ignore it. A gateway MUST only advertise addresses that are actually reachable on the network interface where the announcement is sent. It MUST NOT advertise a loopback-only listener (127.0.0.1 or ::1) on a LAN. Each service instance represents one listening port and one TLS mode. If a gateway listens on both plaintext HTTP and HTTPS, it MUST advertise them as two separate service instances. Instance naming, uniqueness probing, conflict resolution, TTL handling, cache-flush flags, and goodbye packets MUST follow [RFC6762] and [RFC6763]. A gateway MAY append a short stable suffix (such as CPA-8F3B) so humans can recognize it across restarts, but clients MUST NOT treat the instance name or id as proof of identity. Clients MUST retain the network interface scope when handling IPv6 link-local addresses. 3.3. Capability Subtypes and Wire-Protocol Routes A gateway MAY publish DNS-SD subtype PTR records so clients can filter by wire protocol during browsing. Every subtype name is vendor-neutral and names the wire operation rather than a company or model brand. Su Expires 29 April 2027 [Page 6] Internet-Draft AI Gateway Discovery October 2026 To prevent mDNS packet bloat while supporting rich gateways, subtypes are organized into two tiers: *Core Subtypes* (advertised by default when supported) and *Extended Subtypes* (advertised when configured by the operator). 3.3.1. Core Subtypes +=================+=================================+==============+ |Subtype label | Primary Inference Route |Optional Model| | | |Catalog Route | +=================+=================================+==============+ |_responses | POST/GET /v1/responses, |GET /v1/| | | /v1/responses/compact |models | +-----------------+---------------------------------+--------------+ |_chat-completions| POST /v1/chat/completions |GET /v1/| | | |models | +-----------------+---------------------------------+--------------+ |_messages | POST /v1/messages, |GET /v1/| | | /v1/messages/count_tokens |models | +-----------------+---------------------------------+--------------+ |_generate-content| POST /v1beta/ |GET | | | models/{model}:generateContent, |/v1beta/| | | :streamGenerateContent |models | +-----------------+---------------------------------+--------------+ |_interactions | POST /v1beta/interactions |GET | | | |/v1beta/| | | |models | +-----------------+---------------------------------+--------------+ Table 1 3.3.2. Extended Subtypes Gateways that expose multimodal, realtime, or specialized agent endpoints MAY also advertise the following subtypes: Su Expires 29 April 2027 [Page 7] Internet-Draft AI Gateway Discovery October 2026 +===============+==========================+======================+ | Subtype label | Standard Route Relative | Capability | | | to path | | +===============+==========================+======================+ | _completions | POST /v1/ | Legacy text | | | completions | completions | +---------------+--------------------------+----------------------+ | _responses-ws | GET /v1/responses | Persistent WebSocket | | | (WebSocket) | Responses stream | +---------------+--------------------------+----------------------+ | _realtime | GET/POST /v1/ | Realtime voice/video | | | realtime*, /v1/live* | (WebSocket, WebRTC | | | | SDP, SIP control) | +---------------+--------------------------+----------------------+ | _images | POST /v1/images/ | Image generation and | | | generations, /v1/images/ | editing | | | edits | | +---------------+--------------------------+----------------------+ | _videos | POST/GET /v1/ | Video generation, | | | videos* | editing, and | | | | retrieval | +---------------+--------------------------+----------------------+ | _audio | POST /v1/audio/ | Speech synthesis | | | speech, /v1/tts | (TTS) | +---------------+--------------------------+----------------------+ | _count-tokens | POST /v1/messages/ | Standalone token | | | count_tokens, | counting | | | :countTokens | | +---------------+--------------------------+----------------------+ | _search | POST /v1/alpha/ | Agentic web/code | | | search | search | +---------------+--------------------------+----------------------+ Table 2 For example, a gateway advertising the _responses subtype over mDNS publishes a PTR record at: _responses._sub._ai-gateway._tcp.local. pointing to the same service instance name as _ai- gateway._tcp.local.. A gateway MUST only advertise subtypes for routes that are enabled on that listener. Advertising a subtype does not guarantee that every user credential or upstream model supports that operation. If a client sees a subtype it does not recognize, it MUST ignore the unknown subtype rather than rejecting the gateway. Su Expires 29 April 2027 [Page 8] Internet-Draft AI Gateway Discovery October 2026 4. TXT Record Format 4.1. Basic Rules, Key Length Compliance, and the 400-Byte Budget TXT records follow Section 6 of [RFC6763]: * Each attribute is stored as a separate DNS TXT character-string in the form key=value. * Keys are case-insensitive. Advertisers MUST write keys in lowercase. * *Strict 9-character key limit*: Every TXT key defined in this specification is *at most 9 characters long* (txtvers, path, tls, auth, auth_type, protocols, product, id, role), strictly complying with Section 6.4 of [RFC6763], and contains no vendor or model trademarks. * Values are case-sensitive unless stated otherwise. * Advertisers MUST NOT put duplicate keys in the same TXT record. If a client receives duplicate keys (even with different casing), it MUST keep the first one and ignore the rest, as required by Section 6.4 of [RFC6763]. To keep mDNS packets small and avoid IP fragmentation on local networks: * each key=value string MUST be at most 255 bytes; * the entire TXT record payload (including the 1-byte length prefix in front of each string) MUST be at most 400 bytes; * all keys and values defined here use printable US-ASCII (0x20 to 0x7E), and every key requires a non-empty value after =. Advertisers pack TXT attributes in priority order: 1. *Priority 1 (Mandatory Core)*: txtvers (placed first per Section 6.7 of [RFC6763]), path, tls, auth. 2. *Priority 2 (Capabilities & Identity)*: protocols, auth_type, product, id. 3. *Priority 3 (Optional Hints)*: role. Su Expires 29 April 2027 [Page 9] Internet-Draft AI Gateway Discovery October 2026 If adding an optional attribute would push the TXT record over 400 bytes, the advertiser MUST omit that optional attribute rather than truncating a value or dropping a required attribute. 4.2. Required Attributes Every advertisement under this profile MUST include these four attributes: +=========+========+===============+================================+ | Key | Length | Allowed value | Meaning | +=========+========+===============+================================+ | txtvers | 7 | 1 | Version of this discovery | | | | | TXT format ([RFC6763] | | | | | Section 6.7) | +---------+--------+---------------+--------------------------------+ | path | 4 | Valid | Root mount path of the | | | | relative path | gateway on the HTTP host | | | | (typically /) | ([RFC6763] Section 6.5) | +---------+--------+---------------+--------------------------------+ | tls | 3 | 0 or 1 | 0 for HTTP/WS, 1 for | | | | | HTTPS/WSS | +---------+--------+---------------+--------------------------------+ | auth | 4 | 0 or 1 | 0 if unauthenticated | | | | | requests are allowed, 1 if | | | | | credentials are required | +---------+--------+---------------+--------------------------------+ Table 3 * txtvers: Placed as the first TXT key per Section 6.7 of [RFC6763]. It identifies the discovery metadata format, not the gateway's software version. Clients that do not support the advertised txtvers MUST NOT parse the record as version 1. * path: Uses the standard DNS-SD HTTP path key ([RFC6763] Section 6.5) to indicate the gateway's root mount prefix on the target host and port. For a standalone gateway, path is /. For a gateway mounted behind a reverse proxy at /ai, path is /ai. * tls: Selects http/ws (0) or https/wss (1). If tls is missing or invalid, the client MUST reject the candidate and MUST NOT default to plaintext. * auth: Uses compact 0/1 boolean encoding (1 means authentication required, 0 means not required). If auth is missing or invalid, the client MUST reject the candidate and MUST NOT assume 0. Su Expires 29 April 2027 [Page 10] Internet-Draft AI Gateway Discovery October 2026 4.3. Validation of path and Endpoint Construction The path value is always an absolute-path reference [RFC3986] on the discovered host and port, never a full URI. To be valid, path: * MUST start with a single /; * MAY be / (the default for standalone gateways); * MUST NOT start with // or contain ://; * MUST NOT contain ?, #, \, spaces, or control characters; * MUST NOT end with / (unless the entire path is /); * MUST NOT contain empty segments (//), . segments, .. segments, or percent-encoding (%xx). If path is missing or fails validation, the client MUST treat the service instance as unusable. To construct a request URL for a supported wire protocol, the client concatenates the scheme (http/https or ws/wss), the SRV target host (or a resolved A/AAAA IP address) and SRV port, the validated path (omitting a trailing slash when path is /), and the protocol's standard route from Section 3.3: * When path=/ (for example, on 192.0.2.10:8317 with tls=0): - _responses -> http://192.0.2.10:8317/v1/responses - _chat-completions -> http://192.0.2.10:8317/v1/chat/completions - _messages -> http://192.0.2.10:8317/v1/messages - _interactions -> http://192.0.2.10:8317/v1beta/interactions - _generate-content -> http://192.0.2.10:8317/v1beta/ models/{model}:generateContent - Model catalog -> http://192.0.2.10:8317/v1/models (or http://192.0.2.10:8317/v1beta/models) * When path=/ai (mounted behind a reverse-proxy prefix): - _responses -> ://:/ai/v1/responses Su Expires 29 April 2027 [Page 11] Internet-Draft AI Gateway Discovery October 2026 - _interactions -> ://:/ai/v1beta/ interactions - Model catalog -> ://:/ai/v1/models 4.4. Optional Attributes and Capability Vocabulary +===========+========+=================+==========================+ | Key | Length | Format | Meaning | +===========+========+=================+==========================+ | protocols | 9 | Comma-separated | Supported wire protocols | | | | tokens | and capabilities | +-----------+--------+-----------------+--------------------------+ | auth_type | 9 | Comma-separated | Accepted authentication | | | | tokens | mechanisms | +-----------+--------+-----------------+--------------------------+ | product | 7 | Non-empty | Software identifier | | | | printable ASCII | (e.g., cliproxyapi) | +-----------+--------+-----------------+--------------------------+ | id | 2 | Non-empty | Short non-cryptographic | | | | printable ASCII | instance ID (e.g., 8F3B) | +-----------+--------+-----------------+--------------------------+ | role | 4 | Non-empty | Deployment role hint | | | | printable ASCII | (e.g., standalone) | +-----------+--------+-----------------+--------------------------+ Table 4 For comma-separated lists (protocols, auth_type), tokens use lowercase ASCII letters, digits, -, or _, with no spaces or empty items. Clients MUST ignore unknown tokens. 4.4.1. Standard protocols Tokens The protocols list is the single TXT capability list. Its tokens match the subtype labels in Section 3.3 without their leading underscore: * *Core default set*: chat-completions, responses, messages, generate-content, interactions * *Extended tokens* (may be advertised when enabled and within the 400-byte budget): completions, responses-ws, realtime, images, videos, audio, count-tokens, search Su Expires 29 April 2027 [Page 12] Internet-Draft AI Gateway Discovery October 2026 4.4.2. Standard auth_type Tokens * api_key: API key authentication. The client sends the key using the standard HTTP header for the wire protocol being called: - /v1/responses, /v1/chat/completions, /v1/models, and other /v1/* routes: Authorization: Bearer - /v1/messages and /v1/messages/count_tokens: x-api-key: or Authorization: Bearer - /v1beta/* (:generateContent, /interactions, /v1beta/models): x- goog-api-key: * oauth: OAuth / token-backed client sessions where applicable. 4.4.3. Exclusion of Management Interfaces Gateways MUST NOT use _ai-gateway._tcp to advertise management endpoints (such as /v0/management, /v8/management, or /management.html), and advertisers SHOULD NOT emit any management TXT key. 5. How a Client Uses Discovery Results A client follows five steps: 1. *Browse*: Query _ai-gateway._tcp (or a desired subtype such as _responses._sub._ai-gateway._tcp) on allowed local interfaces. Clients looking for a specific gateway product (such as CPA) MAY prioritize instances with product=cliproxyapi while retaining standard gateways as fallbacks. 2. *Resolve*: Fetch SRV, TXT, and A/AAAA records for each discovered instance. 3. *Validate*: Check that txtvers=1, path, tls, auth, the TCP port (1..65535), and usable IP addresses are present and valid. 4. *Filter addresses and preserve IPv6 scope*: Reject loopback, unspecified (0.0.0.0, ::), multicast, or other addresses blocked by local policy. When connecting to an IPv6 link-local address (fe80::/10), the client MUST attach the local network interface zone identifier (for example, %en0) learned during discovery. 5. *Confirm trust before sending requests (and optionally query /v1/models)*: Show the candidate to the user or match it against pre-configured trust rules. Querying /v1/models or Su Expires 29 April 2027 [Page 13] Internet-Draft AI Gateway Discovery October 2026 /v1beta/models is OPTIONAL: a client that already knows the target model name MAY send inference requests directly after trust confirmation. When a client does query the model catalog to populate a model selector: * When auth=0 (unauthenticated LAN gateway): after trust confirmation, the client MAY query GET /v1/models or GET /v1beta/models without an API key. * When auth=1 (authenticated gateway): if the client queries /v1/models or /v1beta/models, it MUST include a valid API key and MUST NOT call those endpoints unauthenticated; pre-authentication filtering relies on DNS-SD subtypes and TXT protocols (and optional GET/HEAD /healthz liveness checks). Clients MUST NOT automatically send API keys to a newly discovered gateway just because its instance name, product, or id matches a previously seen gateway. On HTTP redirects to a different origin, clients MUST NOT automatically forward credentials. 6. Example DNS-SD Records (CLIProxyAPI Default Profile) The example below shows a CLIProxyAPI instance (CPA-8F3B) advertising on port 8317 over mDNS with its core subtypes and 9-key TXT record: Su Expires 29 April 2027 [Page 14] Internet-Draft AI Gateway Discovery October 2026 _ai-gateway._tcp.local. PTR CPA-8F3B._ai-gateway._tcp.local. CPA-8F3B._ai-gateway._tcp.local. SRV 0 0 8317 cpa-8f3b.local. CPA-8F3B._ai-gateway._tcp.local. TXT ( "txtvers=1" "path=/" "tls=0" "auth=1" "auth_type=api_key" "product=cliproxyapi" "id=8F3B" "role=standalone" "protocols=responses,chat-completions,messages,interactions" ) cpa-8f3b.local. A 192.0.2.10 cpa-8f3b.local. AAAA 2001:db8::10 _responses._sub._ai-gateway._tcp.local. PTR CPA-8F3B._ai-gateway._tcp.local. _chat-completions._sub._ai-gateway._tcp.local. PTR CPA-8F3B._ai-gateway._tcp.local. _messages._sub._ai-gateway._tcp.local. PTR CPA-8F3B._ai-gateway._tcp.local. _interactions._sub._ai-gateway._tcp.local. PTR CPA-8F3B._ai-gateway._tcp.local. The TXT payload above is *151 bytes* (or *168 bytes* when all five core protocols including generate-content are listed, including the 1-byte length prefix for each of the 9 strings) — well under half of the 400-byte limit — with every key at most 9 characters long and zero vendor trademarks in the TXT schema. 7. Operational Guidance * *Off by default unless enabled*: Gateways SHOULD keep LAN broadcasting disabled until enabled in configuration. * *Physical LAN interfaces only (Scheme C)*: Gateways SHOULD filter out loopback (lo*), container bridges (docker*, veth*, br-*), VPN tunnels (utun*, tailscale*, wg*, tun*, tap*), and virtual interfaces (awdl*, llw*) by default, and refuse to fall back to all interfaces if no physical LAN interface qualifies. In Docker, host networking (--net=host) is required to multicast on the physical LAN. Su Expires 29 April 2027 [Page 15] Internet-Draft AI Gateway Discovery October 2026 * *Zero-config CLI discovery*: Implementations SHOULD provide a standalone discovery command (such as cli-proxy-api -discover or cli-proxy-api discover) that can browse the LAN before loading a server configuration file. * *Two-stage discovery (unauthenticated mDNS, authenticated /models)*: Do not place model catalogs, per-provider quotas, or secrets in TXT records. Because different API keys on a gateway can have different model permissions, there is no single unauthenticated model list. Clients filter gateways before authentication using DNS-SD subtypes and TXT protocols, and query /v1/models or /v1beta/models with the user's API key after authentication. * *Flood protection*: Clients MUST cap retained services, IP addresses per service, and TXT entries per service (for example: at most 256 services, 64 IP addresses per service, and 64 TXT strings per service), cancel internal browsing once the service cap is reached, and strictly respect the caller's cancellation or deadline policy without injecting hidden shorter timeouts. 8. Security Considerations 8.1. Spoofing on the Local Network Anyone on the local network segment can broadcast forged mDNS packets, impersonate CPA-, claim auth=0, or point the SRV record at an attacker-controlled host. Clients MUST treat all discovery fields as untrusted hints until verified by user confirmation, TLS server identity verification [RFC9525], pinned certificates, or pre- configured policy. 8.2. Protecting API Keys and Credentials Advertisers MUST NOT place API keys, OAuth tokens, management keys, or private URLs in TXT records. Clients MUST NOT send reusable API keys over plaintext HTTP or WS (tls=0) unless explicitly approved by the user or operator for a trusted local environment. A new mDNS announcement with tls=0 MUST NOT downgrade a previously trusted HTTPS/WSS gateway to plaintext. 8.3. Preventing SSRF and Internal Network Probing Because the SRV target host, resolved IPs, and path come from untrusted multicast input, clients MUST validate path using Section 4.3, reject loopback/unspecified/special-purpose IP addresses, and re-verify destinations on any HTTP redirect. Su Expires 29 April 2027 [Page 16] Internet-Draft AI Gateway Discovery October 2026 8.4. DoS and Local Privacy Clients MUST enforce hard bounds on discovered services, addresses, and TXT bytes to prevent memory exhaustion from mDNS packet floods. Operators SHOULD be able to customize or disable advertised instance names when LAN privacy is required. 9. IANA Considerations This document proposes registering a DNS-SD service name (without a fixed port) in the IANA Service Name and Transport Protocol Port Number Registry under [RFC6335]: +====================+======================================+ | Field | Proposed Value | +====================+======================================+ | Service Name | ai-gateway | +--------------------+--------------------------------------+ | Transport Protocol | TCP | +--------------------+--------------------------------------+ | Description | AI Gateway Local Discovery | +--------------------+--------------------------------------+ | Port Number | None (service name only) | +--------------------+--------------------------------------+ | Assignee | Changshan Su (Router-for-Me), | | | suchangshan@foxmail.com | +--------------------+--------------------------------------+ | Contact | Changshan Su (Router-for-Me), | | | suchangshan@foxmail.com | +--------------------+--------------------------------------+ | Reference | This document, if published | +--------------------+--------------------------------------+ | Defined TXT Keys | txtvers, path, tls, auth, auth_type, | | | protocols, product, id, role | +--------------------+--------------------------------------+ | Assignment Notes | Listening port is discovered via | | | DNS-SD SRV records | +--------------------+--------------------------------------+ Table 5 This draft does not ask IANA to create any new registries for subtypes or TXT keys; general registration procedures are described in [RFC8126]. Su Expires 29 April 2027 [Page 17] Internet-Draft AI Gateway Discovery October 2026 10. Implementation Status This section records current implementation experience for reader context and is intended to be removed before final RFC publication. CLIProxyAPI (CPA) implements LAN service advertisement and discovery in internal/discovery and sdk/cliproxy using github.com/libp2p/zeroconf/v2, paired with the cli-proxy-api -discover CLI command. Repository: https://github.com/router-for-me/ CLIProxyAPI (https://github.com/router-for-me/CLIProxyAPI) CPA exposes Open Responses (/v1/responses), Chat Completions (/v1/chat/completions), Messages (/v1/messages), GenerateContent and Interactions (/v1beta/*), and multimodal/realtime endpoints on a unified TCP listener (supporting HTTP/1.1, HTTP/2, SSE, WebSocket, and WebRTC SDP calls), and advertises _ai-gateway._tcp over mDNS. 11. Acknowledgments This document draws on the DNS-SD and mDNS specifications ([RFC6762], [RFC6763]), the Open Responses specification [OpenResponses], and implementation work in CLIProxyAPI. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . Su Expires 29 April 2027 [Page 18] Internet-Draft AI Gateway Discovery October 2026 [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, . [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, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . 12.2. Informative References [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [RFC9429] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 9429, DOI 10.17487/RFC9429, April 2024, . Su Expires 29 April 2027 [Page 19] Internet-Draft AI Gateway Discovery October 2026 [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [OpenResponses] "Open Responses Specification", April 2026, . Author's Address Changshan Su Router-for-Me Email: suchangshan@foxmail.com URI: https://github.com/router-for-me/CLIProxyAPI Su Expires 29 April 2027 [Page 20]