QUIC Alternative Server Address Frames

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

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

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

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:¶

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

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

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

8. Security Considerations

9. IANA Considerations

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