Hi Ted and Christian,
Thanks for taking a look. Responses inline:
On Thu Oct 16, 2025 at 8:59 AM PDT, Christian Huitema wrote:
> 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.
Agreed, that's the intent here.
> 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.
Please correct me if I'm wrong, but my reading of RFC 9000 is that
migrating to a new server address (outside of the preferred address
transport parameter) is not supported.
>From RFC 9000:
> This document limits migration of connections to new client addresses, except
> as described in Section 9.6 [Server's Preferred Address].
> ...
> 9.6. Server's Preferred Address
> ...
> Migrating a connection to a new server address mid-connection is not
> supported by the version of QUIC specified in this document.
My goal with this draft is to define a minimal extension to enable
migrating to a new server address mid-connection.
I believe the Multipath Extension for QUIC could also solve this use case
by allowing the client to establish paths to multiple server addresses
mid-connection. The main downside being that it's a bigger change if the
application only wants connection migration and not simultaneous usage of
multiple paths.
Perhaps this draft could be even smaller by omitting the New Preferred
Address frame, and defining the extension to simply allow the client to migrate
to a new server address. Address discovery could be out of scope, just
as in the Multipath Extension for QUIC. My one hesitation is that this
seems too open ended. A nice property of the new preferred address
extension is that it builds on top of the existing logic of a server's
preferred address.
> I would also suggest taking a look at draft-seemann-quic-nat-traversal,
> which explores many of the same concepts.
Marten Seemann is a co-author to this draft. I won't speak for him, but
in my mind this is a smaller building block for a more general
NAT traversal strategy. For example, as mentioned in Section 3 of the
draft[1], the application could use an external signaling channel and
have the server send a New Preferred Address frame to specify its
preferred address for the direct connection.
---
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).
Yes, you're right. NAT traversal is a sort of dark art that is very NAT
implementation specific. I didn't want to specify the NAT traversal
technique as I feared it would derail the draft. As mentioned above, I
imagine this extension being a building block to some other robust NAT
traversal technique that ultimately ends on migrating to some new server
address.
> 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.
Thanks for this callout. I'd like to be consistent with the Server's
Preferred Address in RFC 9000. I'm not sure I see much there on this
topic except for this security consideration in Section 21.5.6:
> Similarly, endpoints could regard a change in address to a link-local
> address [RFC4291] or an address in a private-use range [RFC1918] from a
> global, unique-local [RFC4193], or non-private address as a potential
> attempt at request forgery. Endpoints could refuse to use these
> addresses entirely, but that carries a significant risk of interfering
> with legitimate uses. Endpoints SHOULD NOT refuse to use an address
> unless they have specific knowledge about the network indicating that
> sending datagrams to unvalidated addresses in a given range is not
> safe.
> 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.
I'd like to keep it more general if possible. Having new text consistent
with RFC 9000 makes sense. I'll think about it. Suggestions welcome of
course!
Thanks,
-marco
[1]:
https://datatracker.ietf.org/doc/html/draft-seemann-quic-nat-traversal-02#section-3
