BondingShouldBeFree Open-source Network Aggregation & Redundancy Solution

[Daniel Golle]

On Sat, May 23, 2026 at 06:46:33PM +0000, Chester A. Unal wrote:
> On 23/05/2026 17:34, Jonas Lochmann wrote:
> > Am Sat, May 23, 2026 at 02:03:17PM +0000, schrieb Chester A. Unal:
> > > Daniel, Jonas.
> > > 
> > > I've been keeping track of MP-QUIC for a while now. The RFC is still a
> > > draft but there's a working group and they're making steady progress, last
> > > I checked a few months ago. I'm waiting for the RFC to finalise and have a
> > > proper implementation ready before I try it.
> > 
> > I am also waiting to see the end result. Not only what the implementations
> > provide but how common its deployment will be.
> > 
> > With OpenWrt and IPv6, it works out of the box to let the clients know
> > that they are in multiple IPv6 subnets and the clients pick one IP
> > per subnet. I once developed a local proxy server application that
> > randomly chose one source IP/subnet per TCP socket because the default
> > address selection is deterministic and does not distribute load over
> > multiple links. However, with a good MP-QUIC result, the usage of
> > multiple uplinks would work automatically in this case, without my
> > extra proxy server and maybe with load distribution within one stream.
> > Failover is already part of the regular QUIC.
> 
> True. The problem with MPTCP is, and this should apply to MP-QUIC too, the
> host that creates the connections usually does not have access to the
> multiple paths. It's usually a router in between that does. 

In IPv6-enabled deployments (which are becoming the norm, also because of
the v4 address shortness) this is radically different, multi-homing all the
way to the edge is common.

> That's why,
> even if every host on the internet supported MPTCP or MP-QUIC, you'd still
> need to run a proxy programme on your router to be able to utilise multiple
> paths.

True for IPv4 legacy Internet access where the router does NAT, not true
for IPv6.