On Fri, Oct 09, 2020 at 05:46:10PM +0000, Simon Ser wrote: > On Friday, October 9, 2020 4:28 PM, Frederic Lecaille <[email protected]> > wrote: > > > > > The IETF-QUIC transport protocol spec [1] hasn't been ratified, but > > > > there exists a number of QUIC deployments in the wild. I'm writing a > > > > proxy and I'd like to add support for QUIC. Are there any plans to add > > > > QUIC4/QUIC6 to the list of PROXY transport protocols? > > > > > > from what I know the ongoing work on haproxy side is visible here > > > https://github.com/haproxytech/quic-dev > > > I let haproxy team answer if they have more details but there are > > > already some preparation work done in haproxy.git mainline. > > > Best, > > > > As already mentioned by William, I confirmed we have started to work on > > QUIC support for HAProxy. > > > > Note that the last QUIC draft version is 31. > > Thanks both for replying. > > My question was less about haproxy and more about the PROXY protocol > specification [1]. How should proxies forward QUIC connection metadata > via the PROXY protocol? There is \x11 for TCP over IPv4, but nothing > for QUIC over IPv4. > > [1]: https://www.haproxy.org/download/2.3/doc/proxy-protocol.txt
I think we'll think about completing it once we start to have a working implementation. As you probably know, QUIC supports source address migration and I suspect that passing the initial ip+port in the proxy protocol header is one of the least interesting information. Maybe some combinations of ip+port+connection ID or anything else that doesn't immediately come to my mind could be more relevant. In general I think that the proxy protocol is not suitable for anything HTTP-related since HTTP requests must be independent on each other and that doesn't work once you chain two proxies, so this also applies to QUIC, which seems to me to make little sense to convey over the PROXY protocol in general. But I could admit that there would be special cases and these are the ones that should be identified if we want to come to a reasonably good solution. Regards, Willy
