Hi, Rich: I knew QUIC had such mechanism, as that are described in https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-migration. We just want to implement the similar procedure in TLS, for different scenarios, at the beginning of TLS handshake as quickly as possible.
Regarding to your proposal, b) is the ideal procedure. We need some negotiation at the TLS handshake phase, to let the server tell the client it’s switched unique address, to replace the original ANYCAST address. Aijun Wang China Telecom > On Mar 16, 2025, at 08:15, 【外部账号】 rs...@akamai.com <rs...@akamai.com> wrote: > > > We want to switch the TLS connection quickly to another address of the same > server, to keep the following transaction traffic stick to the same server … > The previous address of the server is one ANYCAST address that are shared by > several servers that can provide the same service. > > Are you trying to handle network path changes between client and server? This > is often called multi-path, and you might want to look at the QUIC multipath > drafts for some ideas. > > Or, are you trying to handle the case where the client is now connected to a > different server, at the same anycast address? I would think that only works > if either (a) all servers share all state; or (b) the client knows and start > a new resumption to the new server. > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
