How will MPQUIC support the scenario where the client connects with a dual-stack server via both IPv4 and IPv6 paths?

[yangfurong]

Considering a scenario where a server has both IPv4 and IPv6 addresses and a client has two interfaces (one with IPv4 and the other with IPv6), how will MPQUIC support it?

It seems like there should be an address announcement mechanism in MPQUIC to support such a scenario.

[qdeconinck]

Currently, the base MPQUIC draft assumes that either the server has a single address (while the client may have several), or it knows additional addresses by side-channels (like preferred_address TP or application information). One solution could be to bring back the ADD_ADDRESS/REMOVE_ADDRESS frames defined in a previous draft version (see https://datatracker.ietf.org/doc/html/draft-deconinck-quic-multipath-07#section-6.4).

The question being, should it be part of the base draft, or be an extension to the multipath extension?

[LPardue]

I think any work needs to be motivated by practical use cases.

Commonly, a server that supports listening on multiple IP addresses would declare them in the DNS. Is that not already good enough?

[yangfurong]

I think any work needs to be motivated by practical use cases.

Commonly, a server that supports listening on multiple IP addresses would declare them in the DNS. Is that not already good enough?

If we rely on DNS to handle this case, the DNS resolver must ensure that the resolved v6 and v4 addresses are attached to the same cluster. In our usecase, the DNS resolver can not garuantee that. Here is an example.

[LPardue]

You can use load balancer techniques to resolve that, for example using CID based routing to ensure cluster affinity.

[huitema]

@LPardue You are proposing to have the client use the DNS to find alternate IP or IPv6 addresses. That will not work naturally if the client just picks the first address returned by the DNS. The client has connection set with Cluster2, IPv4: a2. The DNS proposes AAAA records for IPv6:aa1 or IPv6:aa2. If the client sends a "PATH_CHALLENGE" towards IPv6:aa1, it will arrive at Cluster 1, the CID will probably not be recognized, and the challenge will fail.

However, since the DNS has returned 2 IPv6 addresses, the client could prepare as many path challenges as it has learned addresses. That's a bit wasteful, but one of them will arrive at Cluster2, and if the CID is recognized and routed to the correct server the second path will eventually be established.

@yangfurong we have discussed similar scenarios before. The general consensus is that handling the general case for "client connects to an alternate server address" would require a new frame, through which the server advertises a list of addresses -- see for example this discussion. We explicitly decided to not do that in the first version of the multipath draft -- it is already very complex, and we don't need the extra complexity of this feature now. It could be added by an extension on top of the multipath draft, defining a new frame, explaining its use, and most importantly analyzing the related security issues.

[LPardue]

The presented scenario, of a client supporting two interfaces with no overlap of IP version, seems a bit arbitrary. However, I don't think it's unique to multipath and could happen with vanilla QUIC.

If the client sends a "PATH_CHALLENGE" towards IPv6:aa1, it will arrive at Cluster 1, the CID will probably not be recognized, and the challenge will fail.

This depends on the deployment architecture, load balancer, and CID-based routing. If a packet shouldn't go to the wrong cluster, don't forward it there. These capabilities exist today without multipath.

I don't find it a compelling to make the protocol more complicated when other solutions can already be used.

[obonaventure]

There is a separate draft that addresses this issue, see https://datatracker.ietf.org/doc/html/draft-piraux-quic-additional-addresses-03

[Yanmei-Liu]

Address Discovery might also help in this use case:
https://datatracker.ietf.org/doc/html/draft-seemann-quic-address-discovery-04