]> Okayama University

kozuka@okayama-u.ac.jp

Web and Internet Transport QUIC next generation unicorn sparkling distributed ledger This document specifies an extension of QUIC that allows the server to initiate connection migration. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction RFC 9000 defines connection migration as a mechanism initiated by the client to change its IP address or network path without disrupting the QUIC connection. This mechanism is based on the assumption that a client may be behind a NAT and a server has a public address. However, there is a reversed situation where a client has a public address and a server is behind a NAT. This document specifies an extension that reverses this role: the server initiates migration.

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 when, and only when, they appear in all capitals, as shown here.

Motivation A key scenario is:

• The server is initially behind a NAT and cannot accept direct connections.
• The client has a public IP address.
• The server first establishes the QUIC connection via a relay server.
• Immediately after the handshake, the server migrates the connection to the client’s public address, reducing latency.

This specification does not define how the server obtains the public address of the client. Possible methods include application-level signaling or external mechanisms, but these are out of scope.

Scope

• Reverse migration roles defined in RFC 9000.
• Maintain QUIC security guarantees.
• No new NAT traversal mechanism.

Negotiating Extension Use allow_server_migration (0x3e764478): Clients advertise their support of this extension by sending the allow_server_migration (0x3e764478) transport parameter () with an empty value. Sending this transport parameter signals to the server that the client will accept the server-initiated migration. Servers also send this parameter with an empty value. The server informs the client that it will initiate the connection migration by sending this parameter. When this extension is negotiated, the server-initiated migration is only permitted and the client-initiated migration is prohibited. An implementation that understands this transport parameter MUST treat the receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. Endpoints MUST NOT remember the value of this extension for 0-RTT.

Connection Migration Procedure The connection migration procedure is the same as () except that the roles between the client and the server are reversed.

Security Considerations TODO Security

IANA Considerations

QUIC Transport Parameter This document registers the allow_server_migration transport parameter in the "QUIC Transport Parameters" registry established in . The following fields are registered:

Value:

0x3e764478

Parameter Name:

allow_server_migration

Status:

Provisional

Specification:

This document

Change Controller:

IETF (iesg@ietf.org)

Contact:

Masahiro Kozuka (kozuka@okayama-u.ac.jp)

Normative References Fastly Mozilla In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.

Questions

• Sould we extend this extension to allow both clients and servers to initiate connection migration?
• Any new security conserations from allowing servers to initiate connection migration?