QUIC Alternative Server Address Frames
draft-munizaga-quic-alternative-server-address-01

QUIC                                                         M. Munizaga
Internet-Draft                                       Ethereum Foundation
Intended status: Standards Track                              M. Seemann
Expires: 22 January 2027                                    21 July 2026

                 QUIC Alternative Server Address Frames
           draft-munizaga-quic-alternative-server-address-01

Abstract

   This document specifies an extension to QUIC that allows a server to
   advertise a prioritized set of alternative addresses.  This allows a
   client to migrate the connection as the availability or preference of
   server addresses changes.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://marcopolo.github.io/alternative-server-address/draft-
   munizaga-quic-alternative-server-address.html.  Status information
   for this document may be found at https://datatracker.ietf.org/doc/
   draft-munizaga-quic-alternative-server-address/.

   Discussion of this document takes place on the QUIC Working Group
   mailing list (mailto:quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/quic/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/quic/.

   Source for this draft and an issue tracker can be found at
   https://github.com/MarcoPolo/alternative-server-address.

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."

Munizaga & Seemann       Expires 22 January 2027                [Page 1]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

   This Internet-Draft will expire on 22 January 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Negotiating Extension Use . . . . . . . . . . . . . . . . . .   3
   4.  Path Validation . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Alternative Address Frame . . . . . . . . . . . . . . . . . .   4
     5.1.  Address Selection and Reachability  . . . . . . . . . . .   6
   6.  Connection ID Management  . . . . . . . . . . . . . . . . . .   6
   7.  Interaction with the Multipath Extension for QUIC . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.1.  Request Forgery Attacks . . . . . . . . . . . . . . . . .   7
     8.2.  DDoS - Thundering herd  . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  QUIC Transport Parameter  . . . . . . . . . . . . . . . .   7
     9.2.  QUIC Frame Types  . . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   QUIC supports client-initiated connection migration, allowing a
   connection to survive changes to the client's address and enabling
   the client to select among available paths (Section 9 of [RFC9000]).
   A server can advertise a preferred address during the handshake
   (Section 9.6 of [RFC9000]), but cannot update that address or
   advertise additional addresses during the connection.

Munizaga & Seemann       Expires 22 January 2027                [Page 2]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

   Some deployments have multiple server addresses whose availability or
   preference can change over the lifetime of a connection.  These
   include multihomed endpoints, relays, proxies, and peer-to-peer
   systems.

   This document defines an extension that allows a server to advertise
   a prioritized and replaceable set of alternative addresses.  The
   client remains responsible for validating these addresses and
   initiating any connection migration.

   Address discovery and NAT traversal mechanisms, including hole
   punching, are out of scope of this document.

2.  Conventions and Definitions

   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.

3.  Negotiating Extension Use

   alternative_address (0xff0969d85c):

   Clients advertise their support of this extension by sending the
   alternative_address (0xff0969d85c) transport parameter (Section 7.4
   of [RFC9000]) with an empty value.  Sending this transport parameter
   signals to the server that the client understands the
   ALTERNATIVE_ADDRESS frame.

   Servers MUST NOT send this transport parameter.  A client that
   supports this extension and receives this transport parameter MUST
   abort the connection with a TRANSPORT_PARAMETER_ERROR.

   Endpoints MUST NOT remember the value of this extension for 0-RTT.

4.  Path Validation

   Advertising an alternative address does not create a new path or
   initiate connection migration.  As in Section 9 of [RFC9000], clients
   remain responsible for initiating all connection migrations.  A
   client initiates path validation by sending probing packets to an
   advertised address and only migrates after validation succeeds.
   Packets from unadvertised server addresses are handled as specified
   by RFC 9000, except while validating an advertised address as
   described below.  Such packets do not create new paths.

Munizaga & Seemann       Expires 22 January 2027                [Page 3]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

   The response to a client-initiated PATH_CHALLENGE can arrive from a
   server address other than the address being validated.  Section 8.2.2
   of [RFC9000] requires the server to send the PATH_RESPONSE on the
   path where it received the PATH_CHALLENGE, but prohibits the client
   from enforcing this requirement.  A matching PATH_RESPONSE received
   on any path validates the path on which the PATH_CHALLENGE was sent
   (Section 8.2.3 of [RFC9000]).  The server might also send a
   PATH_CHALLENGE to validate the path in its sending direction.
   Consequently, while validating an advertised address, a client MUST
   NOT discard a successfully authenticated probing packet solely
   because it was received from an unadvertised server address.
   Processing the packet does not validate its source address or make
   that address eligible for migration.

5.  Alternative Address Frame

   A server uses an ALTERNATIVE_ADDRESS frame to advertise its complete
   set of alternative addresses and their priority relative to the
   current path.  Each frame replaces the state established by any
   previously processed ALTERNATIVE_ADDRESS frame.

   The frame uses the following format, following the conventions
   described in Section 12.4 of [RFC9000]:

   ALTERNATIVE_ADDRESS Frame {
     Type (i) = 0x1d5845e2,
     Sequence Number (i),
     Entry Count (i),
     Address Entry (..) ...,
   }

   The Entry Count field contains the number of Address Entry fields in
   the frame.  An Address Entry starts with an 8-bit Address Type and
   has one of the following formats:

Munizaga & Seemann       Expires 22 January 2027                [Page 4]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

   CURRENT_PATH Entry {
     Address Type (8) = 0x00,
   }

   IPV4 Entry {
     Address Type (8) = 0x01,
     Priority Hint (i),
     IPv4 Address (32),
     IPv4 Port (16),
   }

   IPV6 Entry {
     Address Type (8) = 0x02,
     Priority Hint (i),
     IPv6 Address (128),
     IPv6 Port (16),
   }

   The Priority Hint field is a QUIC variable-length integer.  On each
   side of the CURRENT_PATH entry, lower values indicate higher priority
   and entries with the same value form a priority group in which the
   server expresses no preference.  Entries on each side MUST appear in
   ascending Priority Hint order.  Priority Hint values have meaning
   only relative to other values on the same side of the CURRENT_PATH
   entry; values on opposite sides are unrelated.  A server can assign
   the same value to every entry.

   The CURRENT_PATH entry is a sentinel representing the server address
   of the current path and carries no priority hint, address, or port.
   A frame MUST contain exactly one CURRENT_PATH entry and MUST contain
   each IP address and port tuple at most once.  Receipt of a frame that
   violates these requirements, does not order entries as required, or
   contains an unknown Address Type MUST be treated as a connection
   error of type FRAME_ENCODING_ERROR.

   IPV4 and IPV6 entries before CURRENT_PATH have higher priority than
   the current path.  The client SHOULD promptly validate these
   addresses and migrate to a validated address.  Entries after
   CURRENT_PATH are backup addresses.  The client MAY validate paths to
   these addresses, but SHOULD NOT migrate to one solely because it was
   advertised.

   Priority hints are advisory.  A client MAY use them to decide which
   addresses to validate, which validations to perform in parallel, and
   which validated address to use.  A client MAY disregard priority
   hints based on local policy.

Munizaga & Seemann       Expires 22 January 2027                [Page 5]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

   A server MUST use a larger Sequence Number for each address-set
   update.  A client MUST ignore an ALTERNATIVE_ADDRESS frame whose
   Sequence Number is not greater than that of the most recently
   processed ALTERNATIVE_ADDRESS frame.  Therefore, a newer frame
   atomically replaces an older address set even if the frames are
   received out of order.  An address omitted from the newer frame is no
   longer advertised by this extension.  The client SHOULD stop probing
   or using a non-current path associated with an address that is no
   longer advertised.

   ALTERNATIVE_ADDRESS frames are ack-eliciting and MUST only be sent in
   the application data packet number space.

5.1.  Address Selection and Reachability

   The mechanism by which a server discovers and selects addresses to
   advertise is outside the scope of this document.  An advertised
   address is a candidate and does not imply reachability from the
   client.  A server SHOULD limit the advertised set to addresses that
   it has reason to believe might be reachable, and SHOULD update the
   set when it learns that an address is no longer usable.

   Advertised addresses can include private-use, unique-local, or other
   limited-scope addresses.  A client MAY decline to probe an address
   according to local policy.  A client MUST successfully validate a
   path before sending non-probing frames on it.  The request forgery
   considerations in Sections 21.5.3 and 21.5.6 of [RFC9000] apply.

6.  Connection ID Management

   Each endpoint SHOULD advertise an active_connection_id_limit that
   allows its peer to supply enough connection IDs for all paths that
   the endpoint might probe concurrently.  This applies in both
   directions.

   The server SHOULD ensure that the client has a sufficient number of
   available and unused connection IDs, as the client will be unable to
   probe paths without an unused connection ID.  The server MAY bundle
   one or more NEW_CONNECTION_ID frames with an ALTERNATIVE_ADDRESS
   frame.  Likewise, the client SHOULD ensure that the server has enough
   connection IDs to probe new paths.

7.  Interaction with the Multipath Extension for QUIC

   This extension complements the Multipath extension for QUIC by
   allowing the server to contribute more information to the client for
   alternative paths.

Munizaga & Seemann       Expires 22 January 2027                [Page 6]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

8.  Security Considerations

8.1.  Request Forgery Attacks

   The same considerations from Section 21.5 of [RFC9000] apply here as
   well.

8.2.  DDoS - Thundering herd

   A malicious server could wait until it has received a large number of
   clients, and request a migration from all of them at the same time to
   a victim endpoint.  If the clients all migrate at the same time, they
   may overload or otherwise negatively impact the victim endpoint.

   Clients may mitigate this by randomly delaying the migration.

9.  IANA Considerations

9.1.  QUIC Transport Parameter

   This document registers the alternative_address transport parameter
   in the "QUIC Transport Parameters" registry established in
   Section 22.3 of [RFC9000].  The following fields are registered:

   Value:  0xff0969d85c

   Parameter Name:  alternative_address

   Status:  Provisional

   Specification:  This document

   Change Controller:  IETF (iesg@ietf.org)

   Contact:  Marco Munizaga (marco@marcopolo.io)

9.2.  QUIC Frame Types

   This document registers the ALTERNATIVE_ADDRESS frame in the "QUIC
   Frame Types" registry established in Section 22.4 of [RFC9000].  The
   following fields are registered:

   Value:  0x1d5845e2

   Frame Type Name:  ALTERNATIVE_ADDRESS

   Status:  Provisional

Munizaga & Seemann       Expires 22 January 2027                [Page 7]
Internet-Draft   QUIC Alternative Server Address Frames        July 2026

   Specification:  This document

   Change Controller:  IETF (iesg@ietf.org)

   Contact:  Marco Munizaga (marco@marcopolo.io)

10.  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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

Acknowledgments

   TODO acknowledge.

Questions

   *  Any new security considerations from allowing a dynamically chosen
      preferred address?

Authors' Addresses

   Marco Munizaga
   Ethereum Foundation
   Email: marco@marcopolo.io

   Marten Seemann
   Email: martenseemann@gmail.com

Munizaga & Seemann       Expires 22 January 2027                [Page 8]