The same issue arose during the development of the extension for using
QUIC on multiple paths. We know that we do not want the server to
initiate path, at least not without also solving NAT and Firewall
traversal problems. The general solution is indeed to have the server
provide an address to the client, and let the client initiate a path
towards that address. It is not at all clear that this should be done at
the QUIC level -- it would be easy for applications to just pass the
suggested address in an application level message, and then use the
multiple path API to add a path to the desired address.
I would also suggest taking a look at draft-seemann-quic-nat-traversal,
which explores many of the same concepts.
-- Christian Huitema
On 10/16/2025 1:35 AM, Ted Hardie wrote:
Hi Marco,
Thanks for sharing the draft. I believe I understand the motivation, but I
have concerns that this approach is missing some critical issues that will
crop up for this use case. You note in passing that this may be used for
NAT traversal, but the issues with the timing of candidate gathering could
result in the candidates gathered no longer being appropriate targets when
the transition occurs (especially given the port portion of the
candidates). You are also providing this as a proposed structure:
NEW_PREFERRED_ADDRESS Frame {
Type (i) = 0x1d5845e2,
Sequence Number (i),
IPv4 Address (32),
IPv4 Port (16),
IPv6 Address (128),
IPv6 Port (16),
}
Where there do not appear to be any restrictions on IPv6 address family or
IPv4 reachability. In the previous use case,there was a general reliance
on the server either having public address space to supply or a way to
confirm that the client was within the same administrative boundary and
thus could use restricted space (like RFC 1918 or ULA space). In a peer to
peer setting, reachability may be more difficult to confirm without
additional mechanisms (perhaps analogous to the SIP selection process).
Each of those has its own consequences for the performance and security
properties.
If you plan to use this in a context where this is not an issue, describing
that and limiting this extension to that context may work; if you want this
to be useful more generally (and I encourage that), I think this would need
significant new text.
regards,
Ted Hardie
On Wed, Oct 15, 2025 at 7:04 PM Marco Munizaga <marco=
[email protected]> wrote:
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
