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