Summary

  • RFC 9298 requires a UDP proxy to answer without waiting for a packet from the destination because UDP has no connection handshake. Success means the proxy opened a socket toward the requested target and is willing to forward payloads.
  • That receipt does not establish target reachability, payload delivery, application identity, application acceptance or continuing bidirectional service. DNS resolution, socket state, datagram movement and inner-protocol outcome need separate evidence.
  • David Schinazi's most useful contribution here is not a broader promise but a clean limit. Operators can build better automation by preserving the standard's distinction between what the proxy did and what the destination has not yet proved.

The green light belongs to the proxy

Consider a monitoring panel with one line: CONNECT-UDP 200 — healthy. The HTTP exchange succeeded. A URI identified a host and port. The proxy accepted the request. Yet at the instant the status turned green, the destination may have been offline, filtered, black-holed, listening on another port or simply silent by design.

Nothing has contradicted the standard. The dashboard has merely assigned the proxy's statement to the wrong witness.

RFC 9298 defines a way to carry UDP through an HTTP proxy. A client is configured with an absolute URI Template containing target_host and target_port. It sends a CONNECT-UDP request to the proxy. Depending on the HTTP version, the exchange uses Extended CONNECT or HTTP Upgrade, while HTTP Datagrams carry the UDP payloads. The proxy reconstructs the requested target and opens a UDP socket toward it.

TCP would normally provide a handshake before an application tunnel begins moving data. UDP does not. Opening a UDP socket creates local operating-system state; it does not elicit a SYN-ACK or any equivalent consent from the remote endpoint. RFC 9298 therefore says the proxy has no way to know whether the destination is reachable when it opens the socket and must respond without waiting for a target packet.

The document then defines the successful response with unusual honesty. It indicates that the proxy has opened a socket to the requested target and is willing to proxy UDP payloads. Every noun matters. The actor is the proxy. The completed act is opening a socket. The policy decision is willingness to forward. Reachability, receipt and application outcome are absent.

That narrowness is not a deficiency to be repaired by optimistic language. It is the accurate boundary of a connectionless protocol.

A name can resolve while the service remains unknowable

RFC 9298 does place one condition before the response when the target is a DNS name: the proxy must resolve it. A DNS error requires the request to be rejected, and the proxy can use the dns_error vocabulary supplied by RFC 9209's Proxy-Status field.

Resolution adds evidence, but only of a specific kind. It can show that a resolver produced an address result under a cache and policy at a particular time. It cannot show that the address hosts the intended application, that the application is accepting traffic or that the mapping will still be current later in the tunnel's life.

A useful receipt therefore records the input name, the selected address, address family, resolution time and cache or TTL context. It also records the peer tuple actually bound to the socket. “DNS succeeded” and “target responded” must remain two different fields.

The distinction becomes sharper when a name changes after the socket is opened. The existing socket does not float automatically to the new address merely because authoritative DNS has changed. An operator that shows only the name can make old and new destination state look continuous when the packets are still travelling to the earlier result.

RFC 9209 offers further negative vocabulary: a proxy may know that a destination is unavailable, prohibited or unroutable. Those observations are valuable. But the absence of a recorded error cannot be inverted into positive proof. ICMP may not arrive. A firewall may discard packets silently. The application may discard syntactically invalid datagrams without answering. Silence has many causes and no single meaning.

A socket is a local fact with a remote address

The phrase “opened a socket to the requested target” sounds end-to-end because it contains the target. Operationally, the socket is state owned by the proxy's host.

If the operating system supports connected UDP sockets, the proxy can use one so the kernel returns only datagrams matching the expected five-tuple. If it uses a non-connected socket, RFC 9298 requires explicit checking of the source IP address and UDP source port; mismatches must be discarded. This is an important anti-spoofing boundary.

It is not application authentication. A datagram matching the requested address and port may still carry an unauthenticated, replayed or meaningless payload. The inner protocol—QUIC, DNS, a game transport or something else—has to define peer identity and what counts as acceptance.

Socket lifetime is tied to the HTTP request stream. The proxy keeps the socket open while the stream is open and closes the stream if the socket becomes unusable. An operating-system notification such as ICMP Destination Unreachable can produce that transition. Inactivity can also lead to closure, although RFC 9298 advises against a timeout shorter than two minutes.

This relationship produces two strong receipts: socket-created and socket-closed, including the close reason. It does not produce a continuous certificate of destination health between them. “Still open” means that no observed closing condition has ended the local state. It cannot mean that every packet would succeed now.

A requested tunnel can lose datagrams lawfully

RFC 9298 uses the HTTP Datagram and Capsule Protocol substrate co-authored by Schinazi and Lucas Pardue in RFC 9297. UDP payloads use Context ID zero. Other Context IDs support extension semantics within a request-specific namespace.

The machinery deliberately accommodates reordering. A datagram with an unknown Context ID may be dropped or buffered briefly while registration arrives. A datagram that reaches the proxy before its corresponding request may also be dropped or temporarily buffered. The client is even allowed to send optimistically before it receives the CONNECT-UDP response, with the warning that those packets may never be processed if the request fails or the proxy declines to buffer them.

Size supplies another delivery gap. Context ID zero cannot carry more than 65,527 bytes of UDP payload. More commonly, the outgoing path's MTU is smaller. The proxy must not introduce IP fragmentation and may have no choice but to silently discard an oversized HTTP Datagram.

The result is a protocol in which tunnel acceptance and individual datagram forwarding are intentionally separate events. A status derived from the first cannot account for losses in the second. Datagram counters can show that the proxy observed and attempted to forward traffic. Only an authenticated inner exchange can show that the intended application received it and behaved as expected.

Schinazi's contribution is a disciplined boundary

In August 2022, the IETF published RFC 9298 as a Standards Track document naming David Schinazi as its author. The IETF Datatracker profile captured for this article on 2 September 2026 describes him as a senior staff software engineer and senior manager at Google whose work includes Privacy Proxy, MASQUE and OHTTP. It also records earlier leadership in QUIC and Chrome Networking and earlier networking work at Apple. These facts are capture-dated; they are context, not permanent credentials or proof of any deployment.

The wider architecture is collaborative. RFC 9297 is co-authored with Lucas Pardue. RFC 9484, written by Tommy Pauly, Schinazi, Alex Chernyakhovsky, Mirja Kühlewind and Magnus Westerlund, later extends the family to IP proxying and updates the masque well-known URI registration. The MASQUE Working Group itself is a collective IETF programme. Schinazi should neither be reduced to one sentence in RFC 9298 nor credited with every component around it.

What RFC 9298 contributes to operational thinking is a well-scoped success statement. Standards often become less truthful in product dashboards: several state transitions are compressed into one word because a single green badge is convenient. Here the source document resists that compression. It tells the reader exactly what the response means and exposes what remains unknown.

Heng Lu's doctrine of running-code primacy reaches the same conclusion from another direction. A system should claim only the facts produced by its actual execution. Here the proxy can attest to its authorization decision, resolution step, socket creation and forwarding observations. It cannot borrow authority from the target before the target has emitted evidence.

The note on minimum initial specification adds the complementary design principle. CONNECT-UDP should remain a small interoperable tunnel contract. Different inner protocols can define different acknowledgements, authentication and failure semantics. Forcing a universal application-success claim into the tunnel layer would enlarge the common mechanism by pretending that all UDP applications share one outcome model.

Five receipts instead of one invented certainty

A production system can preserve the boundary with an event chain.

The first receipt is proxy authorization. It records the authenticated client or authorization class, the requested target, applicable target policy, rate or byte budget and the allow or deny decision. Because arbitrary proxy access can make harmful traffic appear to originate from the proxy, RFC 9298 recommends authenticated users and restrictions on vulnerable destinations such as localhost, link-local, multicast and broadcast addresses.

The second receipt is resolution. For a DNS target, it records the resolver result, selected address, address family and time. For an address literal, it records the literal and policy checks. Resolution should never be relabelled as application discovery.

The third is socket state. It records socket creation, local egress identity, connected or non-connected mode, peer tuple, owning request stream and eventual close reason. It can include ICMP-derived errors without promising that every network supplies them.

The fourth is datagram movement. Counters by direction, first and last packet times, bytes, drops by reason, oversized payloads, unknown Context IDs and buffer exhaustion show what crossed the proxy boundary. They should be bounded and access controlled; proving movement does not require retaining sensitive payloads.

The fifth is the inner protocol's outcome. A QUIC handshake, authenticated response, DNS transaction identifier, application acknowledgement or explicit error belongs here. Timeouts and retries belong here too. This is the only layer capable of defining what “the destination answered” means for the actual application.

With those receipts, a control plane can display several honest states: proxy ready; name resolved; outbound datagrams observed; inbound datagrams observed; inner handshake complete; application response accepted. The user gains more information than a green lie and can see exactly where uncertainty begins.

Success without borrowed testimony

The deepest lesson in RFC 9298 is not that UDP is unreliable. Engineers already know that. It is that a well-designed protocol does not claim testimony from an actor that has not spoken.

The proxy can say that it is willing and ready. The resolver can say what address it returned. The operating system can report socket state transitions. The proxy can count datagrams at its boundary. The application can say whether an authenticated exchange completed. Each statement has an owner, a time and a limited scope.

Automation becomes dangerous when it merges those statements and promotes the earliest one to the strongest one. A load balancer may keep sending to a silent destination because the HTTP tunnel still opens. An incident responder may blame the application for packets discarded at an MTU boundary. A compliance report may describe source validation as peer authentication. A capacity model may treat long-lived, zero-response sockets as useful traffic.

David Schinazi's RFC gives operators a better vocabulary. A CONNECT-UDP success is not empty; it is exact. It tells us that the proxy has completed its part. The responsible next question is not “why doesn't the status promise more?” It is “whose receipt do we still need before we say the destination answered?”

Sources