Summary

  • draft-munizaga-quic-alternative-server-address-02 lets a server advertise a sequence-numbered complete set of candidate addresses, divided by CURRENT_PATH into preferred and backup groups; it remains an individual Internet-Draft with no formal IETF standing.
  • Advertisement does not create a path. Priority values are relative hints, clients may disregard them under local policy, and non-probing traffic requires successful path validation in the relevant direction.
  • Operators need separate receipts for advertised state, local admission, validation, path use and aggregate effect, because synchronized compliance by many clients can turn one server hint into a thundering herd against another endpoint.

Imagine a long-lived QUIC connection whose server has learned that a different address should now carry traffic. Today’s preferred-address mechanism is fixed during the handshake. Revision 02 proposes something more dynamic: the server can send an ALTERNATIVE_ADDRESS frame during the protected connection, list several IPv4 or IPv6 candidates and later replace the entire set.

That sounds like remote route control. The draft carefully stops short of granting it. The client remains responsible for every migration. An advertised address is only a candidate. It may be private, unique-local or unreachable from this client. Local scope rules, enterprise policy, power budget, unused Connection IDs and the client’s own network view can all defeat the server’s preference without making the protocol exchange invalid.

The state model is unusually explicit. A frame carries a Sequence Number, an Entry Count and an ordered list. Exactly one CURRENT_PATH sentinel divides the list. Without negotiated multipath, entries before the sentinel rank above the present path; entries after it are backups. Lower Priority Hint values rank earlier only within their side. A 1 on the backup side cannot be compared with a 10 on the preferred side.

The hints are advisory. A client may choose which addresses to probe, which validations to run in parallel and which validated candidate to use. It may ignore the order under local policy. This is a concrete instance of Heng Lu’s localized-future-decision principle: the shared grammar communicates a server view, while the actor bearing the local path risk retains the decision.

A higher Sequence Number atomically replaces the older advertised set, even when packets arrive out of order. That provides a clean advertisement receipt. It does not prove that old probes stopped immediately, that packets already scheduled on a removed non-current path vanished, or that every client processed the replacement at the same instant. The draft says a client should stop probing or using a non-current omitted address. The operational ledger still needs the last accepted sequence, local cancellation time and remaining in-flight work.

Path validation supplies the next receipt, but only within its exact semantics. The client sends probing packets to the candidate and migrates only after validation succeeds. A matching PATH_RESPONSE may arrive on a different path and still validate the path on which the associated PATH_CHALLENGE was sent. Conversely, an authenticated probing packet from an unadvertised source does not validate that source or make it eligible for migration. Protected bytes prove participation in the connection; they do not promote every source address that carried them.

The server also has to validate the path in its sending direction before placing non-probing traffic there. This separates two reachability claims that dashboards often compress into one. A successful client challenge does not automatically prove that the return direction is ready for ordinary data, that NAT state will persist, or that congestion and MTU behavior match the old path.

Connection IDs impose a resource boundary. Each endpoint should allow enough active identifiers for the paths its peer might probe, and the server may bundle fresh identifiers with its advertisement. A client without an unused Connection ID cannot simply validate every entry in parallel. “Preferred” therefore competes with a finite local probe budget.

Multipath makes the limit more visible. The alternative-address extension can tell a client where candidates exist; the multipath specification can create and manage simultaneous paths. Neither decides the application’s scheduling policy. A validated path may supplement the current one, replace it, remain backup, or carry no application bytes. Per-path loss, RTT and congestion evidence belongs to the path actually used, not to the address advertisement.

The most important risk is collective rather than cryptographic. A malicious server can maintain connections to many clients and tell them all that one victim is the higher-priority alternative. If they move together, the protected and syntactically valid hint becomes an amplifier of coordination. The draft suggests random delay as a mitigation. It does not specify a universal distribution, victim-consent proof, fleet-wide budget or mechanism for measuring the load already converging on the target.

This is why server authentication cannot close the case. Authentication can establish which peer sent the frame inside this connection. It cannot establish that the advertised endpoint consented, that it has capacity, that the address belongs to the same operational service or that thousands of other clients were not given the same instruction. RFC 9000’s request-forgery analysis remains relevant, while the draft’s thundering-herd section adds an aggregate consequence that one-path validation cannot see.

Revision status matters. The 25 September 2026 text is revision 02 of an individual draft, with no stream or responsible Area Director and a Datatracker state of I-D Exists. It requests provisional transport-parameter, frame and address-type registrations, but the captured IANA registry does not show those requested values. Text in an IANA Considerations section is not a registration receipt; a registration is not an implementation receipt; an implementation is not a deployment measurement.

The right record is therefore a five-part chain. Preserve the server advertisement and sequence. Record the client’s local admission and jitter decision. Keep directional challenge/response evidence. Log the actual path and scheduler choice with per-path transport state. Finally, measure application continuity and aggregate load at the destination. One green “migration ready” flag erases the very boundaries the extension preserves.

Sources