quic: Add support for `quic` codepoint , interpreted as QUIC version draft-29

[elenaf9]

Description

The QUIC transport currently only supports the quic-v1 codepoint in multiaddresses. This codepoint was recently added to represent QUIC version 1 / RFC 9000, whereas the previous codepoint quic should be interpreted as QUIC version draft-29. See multiformats/multiaddr#145.

quinn supports the versions draft-29..34 and version 1. On the server side this means that our users could already advertise each quic-v1 address also as quic address.
For dialing however we have to set one version, right now we use the default v1. We can add support for quic(-draft-29) by checking the multiaddress on dials and set the current version in the quinn_proto::ClientConfig.

Motivation

go-libp2p does not support quic-v1 yet, although there is WIP to add support in the very near future: libp2p/go-libp2p#1841. However, even when support is added we won't be able to communicate via QUIC with any go-libp2p nodes that did not upgrade to the newest version. cc @dignifiedquire.

Requirements

1. Allow dialing quic multiaddresses
2. Use QUIC draft-29 version when dialing quic addresses, use version 1 for quic-v1
3. To be discussed: support quic codepoint in listening addresses

Open questions

go-libp2p is planning a transition period (6 months?) before removing support for quic. @marten-seemann raised a valid point on whether it even makes sense for rust-libp2p to add support, if ideally eventually the quic codepoint dies out because all new nodes run on v1.

I am in favor of at least adding support for dialing quic addresses so that we can connect to old go-libp2p nodes. I don't see any drawbacks in that.
I would propose to not add support for quic listening addresses. However, since in practice we still support draft-29 as servers, users are still free to announce a quic-v1 address also as quic if they need it. They can already do this right now anyway unless we explicitly remove support for draft-29 in our config.
Wdyt @marten-seemann @mxinden?

Are you planning to do it yourself in a pull request?

Yes (if folks agree with this).

[marten-seemann]

They can already do this right now anyway unless we explicitly remove support for draft-29 in our config.

I must have missed that in code review, I would've expected that draft-29 is disabled by default.

go-libp2p is planning a transition period (6 months?) before removing support for quic. @marten-seemann raised a valid point on whether it even makes sense for rust-libp2p to add support, if ideally eventually the quic codepoint dies out because all new nodes run on v1.

go-libp2p v0.24.0, to be released next week, will include support for the new code point. This will most likely ship in the December kubo release. The only reason we're still supporting draft-29 is that we don't want to cause a regression in go-libp2p.

[dariusc93]

I think it make more sense to add support for it for now since a large amount of peers would be go-libp2p nodes, which would already have support for draft-29.

[mxinden]

I don't have a strong opinion here. I do see the benefit of it for @dariusc93 (https://github.com/dariusc93/rust-ipfs) and @dignifiedquire (https://github.com/n0-computer/iroh) and potentially @divagant-martian (https://github.com/sigp/lighthouse). That said, they can still connect via TCP.

They can already do this right now anyway unless we explicitly remove support for draft-29 in our config.

I must have missed that in code review, I would've expected that draft-29 is disabled by default.

@marten-seemann are there any technical downsides (e.g. security vulnerabilities) to supporting draft-29?

In case there are no technical downsides and in case the amount of work required is minimal (correct me if I am wrong @elenaf9) I am in favor of adding support for dialing /quic addresses. I am also in favor of adding support for /quic listenaddresses.

(Appreciate moving this discussion to GitHub and the detailed write-up @elenaf9!)

[dignifiedquire]

From my side I agree it would be useful to have support for dialing at least, but it is not super critical for iroh, as we can happily continue using tcp for older nodes and I assume the large deployments will update fairly quic(k)ly.

[thomaseizinger]

In case there are no technical downsides and in case the amount of work required is minimal (correct me if I am wrong @elenaf9) I am in favor of adding support for dialing /quic addresses. I am also in favor of adding support for /quic listenaddresses.

I am in the same camp.

[elenaf9]

@marten-seemann are there any technical downsides (e.g. security vulnerabilities) to supporting draft-29?

Friendly ping @marten-seemann. Unless there are major downsides in supporting draft-29 I'll move forward with #3151, adding opt-in support for draft-29.

[thomaseizinger]

Done in #3151.