RFC 10069 nechá jedno spojení QUIC běžet přes Wi-Fi i mobilní síť zároveň

Rozšíření protokolu QUIC o souběžné používání víc síťových cest vyšlo 7. listopadu 2026 jako RFC 10069 ve stavu navrhovaný standard. Dokument má 33 stran, vznikl v pracovní skupině QUIC a je pod ním šest jmen z Alibaby, Harvey AI, univerzity v Monsu, UCLouvain, Private Octopus a Ericssonu.

Dosavadní QUIC podle RFC 9000 zná jen migraci. Klient přesměruje spojení na novou adresu, a když se nová cesta osvědčí, zdroje té staré se uvolní. Telefon, který odchází z dosahu Wi-Fi, tedy o spojení nepřijde, ale v každém okamžiku používá jedinou síť.

Každá cesta dostane svoje číslo

Jádrem rozšíření je identifikátor cesty. První cesta má číslo 0, další rostou po jedné a žádné se nepoužije podruhé. Totéž číslo platí v obou směrech. Každý identifikátor spojení patří právě jedné cestě, takže z identifikátoru v paketu je poznat, kam ten paket patří.

Z toho plyne druhá změna: pořadová čísla paketů se vedou pro každou cestu zvlášť a každá řada začíná nulou. Detekce ztrát a řízení zahlcení z RFC 9002 se tím dají použít na každou cestu beze změny. Daň za to je trojí. Identifikátory spojení nesmějí mít nulovou délku, do výpočtu kryptografické jednorázové hodnoty vstupuje číslo cesty, a šifrovací sady, které mají tu hodnotu kratší než dvanáct bajtů, se s rozšířením použít nedají.

Zapíná se jedním parametrem

Podporu obě strany ohlásí v přenosovém parametru initial_max_path_id s kódem 0x3e. Hodnota není počet cest, ale nejvyšší povolené číslo cesty: při hodnotě 1 se smí otevřít cesta 0 a 1, tedy dvě. Nula znamená, že protistrana rozšíření zapíná, ale zatím žádnou cestu navíc nepřipouští. Nejvyšší přípustná hodnota je 4 294 967 295 a vyšší číslo spojení shodí s chybou TRANSPORT_PARAMETER_ERROR. Mez jde později zvednout rámcem MAX_PATH_ID.

Rámců je nových devět a IANA je zapsala do rejstříku QUIC Frame Types už 30. března 2026, tedy sedm měsíců před vydáním dokumentu.

Kód	Rámec	K čemu je
0x3e-0x3f	PATH_ACK	potvrzení paketů s uvedením cesty, na které byly poslány
0x3e75	PATH_ABANDON	uzavření cesty, se čtyřmi novými kódy důvodu
0x3e76	PATH_STATUS_BACKUP	cesta se má použít jen jako záloha
0x3e77	PATH_STATUS_AVAILABLE	cesta je k dispozici pro běžný provoz
0x3e78	PATH_NEW_CONNECTION_ID	nový identifikátor spojení pro konkrétní cestu
0x3e79	PATH_RETIRE_CONNECTION_ID	vyřazení identifikátoru spojení
0x3e7a	MAX_PATH_ID	zvýšení nejvyššího povoleného čísla cesty
0x3e7b	PATHS_BLOCKED	dál by to šlo, brání tomu ohlášená mez
0x3e7c	PATH_CIDS_BLOCKED	na cestu došly identifikátory spojení

Cestu otevírá klient, server ji ověřuje

Server si cestu sám nezaloží. Otevřít ji smí jen klient a server ji pak ověří stejnou výzvou jako při migraci. Každá strana si navíc může říct, kterou cestu má protějšek používat přednostně a kterou jen jako zálohu. Preference se nastavují nezávisle, takže obě strany klidně můžou chtít něco jiného, a je to jen doporučení: odesílatel se jím řídit nemusí.

Když cesta přestane fungovat, je lepší ji zavřít rámcem PATH_ABANDON než ji nechat být. Protistrana po ní jinak posílá dál a přepnutí na zálohu se zdrží.

Co standard neřeší

Dvě podstatné věci zůstaly mimo. RFC nepopisuje, jak se zjišťují a spravují adresy, a nepopisuje ani plánovač, tedy pravidlo, podle kterého se vybere cesta pro další paket. To je místní rozhodnutí aplikace a implementace a žádná specifikace IETF zatím plánovač pro souběžné používání cest nedefinuje. Jiné rozdělení provozu mezi víc tras popsalo v říjnu RFC 10066 pro protokol PCEP, tam o poměrech ale rozhoduje řídicí prvek sítě, ne koncové body spojení.

Dokument zato varuje před dvěma pastmi. Cesty nemusí být oddělené a při společném úzkém hrdle by spojení přes víc cest ukrojilo větší díl pásma než konkurenční jednocestná spojení. Řešení je stejné jako u vícecestného TCP: provázané řízení zahlcení podle RFC 6356. Druhá past je měření doby obrátky. Potvrzení může přijít jinou cestou, než kterou šla data, a výsledek pak popisuje obě dohromady. Na příkladu pozemní trasy s 50 ms a geostacionární družice s 300 ms v každém směru vyjde kombinací 100, 350 nebo 600 ms podle toho, kudy šla data a kudy potvrzení.

Bezpečnostní oddíl upozorňuje na zesílený útok odepřením služby. Útočník si může nastavit nebo podvrhnout adresy několika cest tak, aby pakety ze serveru mířily přes jedno místo v síti. Rada zní držet počet cest malý, rozkládat ověřování v čase a zdroje pro cestu přidělit až po jejím ověření. Proti běžnému QUIC se ale meze zesílení nemění, útočník by téhož dosáhl otevřením mnoha obyčejných spojení.

Implementace jsou rozeseté po starších konceptech

Praktický háček je v tom, že se čísla rámců během vývoje měnila. Knihovna picoquic, za kterou stojí jeden ze spoluautorů, má kódy z poslední podoby návrhu, tedy ty z tabulky výš. Její dokumentace z konce září zároveň přiznává odchylku: parametr s nulovou hodnotou picoquic vůbec neposílá, takže kdo by nulou začínal, rozšíření si tím vypne.

Ostatní jsou dál. Tencent TQUIC čte PATH_ABANDON pod kódem 0x15228c05 a v komentáři se odvolává na pátou revizi konceptu, README u Alibaba XQUIC jmenuje revize čtyři až šest. Ani Wireshark na tom není líp: jeho rozbor QUIC zná přenosový parametr 0x3e, ale tabulku rámců má podle patnácté revize a nové kódy 0x3e7x v něm 9. listopadu 2026 nebyly ani jednou. Vlastní dokumentace picoquicu to shrnuje jednou větou: nasazení je v rané fázi.

Cesta k dokumentu byla dlouhá. Pracovní skupina vydala první revizi 2. února 2022, poslední dvacátou druhou 17. března 2026. Rejstříky IANA ostatně pořád odkazují na tu poslední revizi konceptu, ne na číslo RFC.

Zdroje

• RFC 10069: Managing Multiple Paths for a QUIC Connection, IETF, 7. listopadu 2026
• draft-ietf-quic-multipath, IETF Datatracker (historie revizí a událost published_rfc)
• QUIC registries, IANA (rejstříky rámců, přenosových parametrů a kódů chyb)
• QUIC Multipath, dokumentace knihovny picoquic
• packet-quic.c, zdrojový kód rozboru QUIC ve Wiresharku
• frame.rs, zdrojový kód knihovny TQUIC