Hello fellow QUIC enthusiast, We've published an initial draft[0] that specifies an extension to QUIC that allows the server to request a connection migration to a new preferred address after the handshake.
This is useful in peer-to-peer applications, as who is the server is somewhat arbitrary. This extension allows both sides to do connection migration, rather than limiting it to just the client. This can also be useful in certain hole-punching scenarios to establish a direct connection after being connected over a proxy. I imagine other applications may find this useful as well. Perhaps migrating to another address after authentication or some other challenge? At a high level, the extension builds upon the existing logic of the preferred_address transport parameter. It specifies a new frame that the server can send to the client that the client treats the same as the address from the preferred_address transport parameter. As a proof of concept, I've implemented a prototype of this extension in quic-go[1]. Chairs, I would appreciate some time at IETF 124 to discuss this and some open questions in draft. Thanks, -Marco [0]: https://datatracker.ietf.org/doc/draft-munizaga-quic-new-preferred-address/ [1]: https://github.com/quic-go/quic-go/compare/master...MarcoPolo:quic-go:new_preferred_address
