Hi Olivier, Many thx for sharing this proposal. Three easy questions ..
1. Do you envision that IP:PORT pairs would be manually configured by the operator ? 2. Do you envision that such addresses may span multiple servers ? 3. Isn't this a bit overlapping (or to say stronger replacing) function of load balancers ? Many thx, R. On Wed, Oct 26, 2022 at 5:03 PM Olivier Bonaventure < [email protected]> wrote: > Dear rtgwgers, > > > A few years ago, the RTGWG adopted RFC8678 "Enterprise Multihoming Using > Provider-Assigned IPv6 Addresses without Network Prefix Translation: > Requirements and Solutions". From a routing viewpoint, using PA IPv6 > addresses in enterprise networks scales much better than using PI > addresses and BGP to announce each enterprise prefix in the DFZ. > > An enterprise can easily use RFC8678 for its client hosts. Each host is > assigned one IPv6 address per provider. Each host can select the best > source address to reach a given server and with QUIC, the host can > switch to another address when the selected one or the associated fails > thanks to QUIC's connection migration. > > However, for enterprise servers, the situation is different. While > RFC9000 supports client-initiated connection migrations, it does not > allow a server that has several IPv6 addresses to announce them to its > clients so that they can migrate to another server address in case the > initial one fails. > > A recent draft, draft-piraux-quic-additional-addresses, proposes a > simple extension to QUIC that enables a server to advertise the > different addresses that it owns. This extension has applications for > RFC8678 and also for other deployments were servers are attached to > different subnetworks. It enables clients to migrate to any of the > server's addresses if one of them becomes unreachable. > > Comments on > > https://www.ietf.org/archive/id/draft-piraux-quic-additional-addresses-00.html > > are more than welcome > > Best regards, > > > Olivier Bonaventure > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg >
