IPv6 má polovina uživatelů, většina zařízení už IPv4 nepotřebuje (Den IPv6)

Původní protokol IPv4 používá 32bitové adresy, což je překvapivě obrovský adresní prostor. Přesto se už v 90. letech ukázalo, že to nebude stačit, protože internet začal růst exponenciálně – začala přibývat mobilní zařízení, služby a také IoT. Potřeba adres výrazně narůstala a bylo třeba ji řešit.

Vznikla proto dvě dočasná a rychlá řešení: beztřídní dělení adresního prostoru (CIDR) a také překlad adres (NAT), který dovoluje používat neunikátní adresy v místních sítích. Od začátku se ale vědělo, že to je jen dočasné řešení, které pouze zpomaluje čerpání globálních adres a bude třeba najít dočasné řešení.

V roce 1992 byla v rámci IETF spuštěna soutěž nových protokolů nazvaná IPng. Cílem bylo posbírat návrhy od komunity a firem a vymyslet novou koncepci internetového protokolu. Prvními čtyřmi kandidáty byly CNAT, IP Encaps, Nimrod a Simple CLNP. Poté přibyli ještě další: PIP, SIP a TP/IX. Že to nebyl jednoduchý proces, dokládá následující vývoj, kdy se ze Simple CLNP se stal TUBA (TCP and UDP with Bigger Addresses), IP Encaps se vyvinul do IPAE (IP Address Encapsulation) a TP/IX změnil název na CATNIP (Common Architecture for the Internet).

Následný vývoj vedl ke sloučení projektu IPAE se SIP a poté navíc s PIP. Výsledkem byl nový protokol SIPP (Simple Internet Protocol Plus), který původně používal 64bitové adresy. Následně byl adresní prostor rozšířen na 128bitů a tato varianta byla následně vybrána jako výsledek výběrového řízení na IPng.

V dalších letech poté docházelo k úpravám návrhu, přípravě prvních specifikací a přejmenování protokolu na IPv6. V roce 1998 také vyšlo první RFC 1883, které začalo se standardizací protokolu. Následovaly první experimenty, implementace do softwaru a hardwaru a následné šíření do produkce. Celý tento proces zabral přibližně třicet let.

IPv6 má výrazně jednodušší formát hlaviček obsahující méně položek pro rychlejší zpracování. Především ale rozšiřuje adresu z 32 na 128 bitů. Máme k dispozici 3,4×10³⁸ adres, což znamená, že na každý milimetr čtvereční povrchu Země připadá 3,4×10¹⁵ adres.

Protokol mění pouze třetí síťovou vrstvu – ostatní nižší a vyšší vrstvy nejsou výměnou zasaženy. Můžeme stále používat Ethernet a na druhé straně například TCP nebo UDP. Někdy je potřeba upravit aplikační protokoly, zejména tam, kde se přímo pracuje s IP adresou – různé formuláře, databáze, konfigurační rozhraní a podobně.

V IPv6 se adresa zapisuje do osm skupin po čtyřech šestnáctkových číslicích, přičemž každá skupina obsahuje 16 bitů a oddělujeme je dvojtečkami. V každé čtveřici můžeme vynechat počáteční nuly a opakující se nuly můžeme také vynechat i napříč skupinami, ovšem kvůli jednoznačnosti jen jednou. Přesto z logiky věci vznikají dlouhé adresy a předpokládá se intenzivní využití DNS.

IPv6 není zpětně kompatibilní s IPv4, uzly používající nový a starý protokol se přímo nemohou domluvit. Taková situace by ovšem nastala s výměnou protokolu v každém případě. Není možné „jen“ prodloužit adresu, formát hlavičky v IPv4 je pevně stanoven a vždy tak vzniká nový protokol.

Od úplného začátku se proto počítalo s přechodovými mechanismy, už RFC 1933 z dubna 1996 rozebírá tunelování provozu po IPv4. Bylo jasné, že přechod celého internetu bude postupný a možná dokonce nekonečný – některé uzly budou navždy na IPv4. Postupně by ale měl provoz na IPv6 převážit a některé uzly kompatibilitu nebudou potřebovat vůbec, protože mohou komunikovat čistě po IPv6.

Běžným přechodovým mechanismem je dual-stack, kdy se k dosavadní síti IPv4 se přidá druhá síť IPv6. Každé síťové rozhraní má nezávislé IPv4 a IPv6 adresy a kooperace probíhá až na aplikační úrovni. Aplikace má přístup k oběma světům a pokud nechá výběr na operačním systému, preferuje se ve výchozím stavu použití novějšího protokolu IPv6.

Výhodou tohoto přístupu je, že se velmi snadno nasazuje a je kompatibilní se stávající infrastrukturou. Případné problémy IPv6 zakrývá algoritmus Happy Eyeballs, který se snaží vždy vybrat funkční cestu, i kdyby ta druhá byla rozbitá. Naopak nevýhodou je, že dual-stack vůbec neřeší problémy s nedostatkem adres v IPv4 a nutí správce udržovat dvě samostatné sítě. IPv6 je tak často občanem druhé kategorie, nemonitoruje se a problémy se řeší mnohem pomaleji.

Pokročilejší variantou je NAT64, kdy je v síti zavedena pouze IPv6, což vytváří jednodušší infrastrukturu s jednou adresací pro všechny uzly. Připojení do původní IPv4 je realizováno až na hranici sítě, kde DNS64 falšuje záznamy AAAA u cílů, které je nemají. Pokud do tohoto adresního prostoru odchází provoz, NAT64 se postará o překlad do IPv4 a případně zpět.

Tento přístup nefunguje v případě, že aplikace chce kontaktovat IPv4 literály, protože na rozhraní jednoduše není IPv4 adresa a takový provoz není kam poslat. Řešením je obrácený překlad 464XLAT implementovaný na koncovém zařízení. To si samo přidělí IPv4 adresu a provoz směřuje do lokálního překladače, který je schopen upravit provoz do podoby IPv6.

Nadstavbou tohoto řešení je pak IPv6-mostly, kdy v síti nabízíme i IPv4 pomocí DHCP, ale většina zařízení si takovou adresu nevyzvedne. DHCP server totiž vysílá volbu číslo 108 nazvanou IPv6-only Preferred, která značí, že v této síti není IPv4 potřeba. Staré zařízení, které volbu nezná a třeba IPv6 vůbec neřeší, si normálně vyzvedne starou adresu a může ji používat. Moderní zařízení ale přeruší objednávku adres a bude používat výhradně IPv6. V reálném nasazení dnes takové řešení podporuje zhruba 80 % zařízení a toto číslo postupně roste.

Pro Česko je relevantní také ještě přechodový mechanismus Dual-Stack Lite (DS Lite), který používá Vodafone ve své síti exUPC. Z hlediska klientů v koncové síti jde o dual-stack, protože mají obě adresy a mohou je plnohodnotně používat. Rozdíl je ovšem v přístupové síti poskytovatele, která je postavena výhradně na IPv6. V klientských sítích jsou nasazeny (privátní) adresy IPv4 a hraniční síťový prvek (B4), který ovšem nepoužívá NAT. Místo toho zabalí provoz IPv4 do tunelu a pošle po IPv6. U poskytovatele je prvek AFTR s připojením do IPv4, který implementuje NAT a umí provoz vybalit a odeslat.

Postupný přechod je potřeba řešit na několika místech: v infrastruktuře, na serverech a v koncových sítích. Infrastruktura je dávno vyřešena, páteřní sítě nemají s IPv6 problém, stejně jako například propojovací uzly. Například NIX.CZ spustil podporu IPv6 už v roce 2003. U serverů se situace různí, protože tam hodně záleží na vůli správce. V datacentrech je IPv6 dostupná, ale správce služby ji nesmí vypnout, musí správně nastavit DNS a podobně.

Největší práce je s koncovými přípojkami, protože ty jsou nejvíce závislé na práci mnoha různých lidí a subjektů. ČTÚ eviduje zhruba 1820 poskytovatelů a 4,2 milionů internetových přípojek. Obecně je jednodušší situace ve státech, kde převažuje několik velikých operátorů pokrývajících velkou část trhu. Horší konkurence má zase jiné problémy, ale jednodušeji se v takovém prostředí aplikují velké změny podobného typu.

Obecně je největším problémem nedostatek motivace na straně poskytovatelů, protože ti nevidí okamžitý přínos ani návratnost takové změny. Vyžaduje to další práci, školení správců a hlavně změnu zaběhlého myšlení. U konkrétních uživatelů pak záleží na použitých síťových prvcích a dalších zařízeních, obecně je situace jednodušší v sítích, kde poskytovatel klientovi spravuje i koncové zařízení. Uživatel pak nic neřeší a vlastně ani neví, že nějakou IPv6 používá.

Do celé situace zasahují také zákonné požadavky v různých zemích. Japonsko už v roce 2000 vyhlásilo podporu a rozjelo projekty podpory IPv6, včetně daňových úlev. Evropská komise v roce 2002 vydala nové priority pro internet a financované projekty musejí komunikovat po IPv6. Spojené státy zaúkolovaly administrativu už v roce 2005, podle původních plánů měly už v roce 2008 všechny vládní sítě podporovat IPv6. Česko v roce 2009 vydalo usnesení vlády, podle kterého měly být všechny služby od roku 2010 dostupné po IPv6.

Nejnovějším počinem v této oblasti je dokument Ministerstva práce a obchodu o zavádění IPv6 ve státní správě. Podle něj mají do 6. června 2032 orgány státní správy přestat poskytovat služby na IPv4. To je za šest let a bude zajímavé celý vývoj dále sledovat.

Mluvíme o tom, že to celé začalo před třiceti lety, ale ve skutečnosti jsme z hlediska nasazení IPv6 byli v roce 2010 na čisté nule. Kromě několika nadšenců a různých experimentálních sítí nový protokol vlastně ještě nikdo nepoužíval. Teprve poté se začala penetrace postupně zvedat, přičemž v roce 2015 jsme byli teprve na 5 %. Teprve před deseti lety se tak začalo něco opravdu dít.

Letos jsme překročili významný milník, protože 28. března 2026 hlásil Google poprvé 50 % přístupů ke svým službám realizovaných po IPv6. Polovina uživatelů na světě má tedy přístup k novému protokolu. Nejlépe jsou na tom Francie s 86 %, Německo se 77 %, Indie se 75 % a Saúdská Arábie s 69 %. V některém takovém státě může vzniknout nová služba, která už se zaměří jen na většinu uživatelů s IPv6.

V Česku hlásí Google přes 40 % přístupů po IPv6. To je sice podprůměr, ale čísla průběžně rostou. Před pěti lety jsme byli na 15 %, takže nárůst je v poslední době velmi dynamické. Podle statistik APNIC tvoří nejvíc provozu nepřekvapivě poskytovatelé O2, T-Mobile a Vodafone, u kterých přibližně polovina zákazníků na IPv6 dosáhne.

Statistiky na straně služeb nabízí CZ.NIC, který hlásí 38,7 % webových serverů dostupných po IPv6, celkem 90,1 % autoritativních serverů a 33,2 % dotazů na .CZ servery proudících novým protokolem.

Růst IPv6 obecně na celém světě táhnou mobilní sítě, protože je jich málo a mají celý řetězec pod kontrolou – od všech prvků sítě až po koncová zařízení. V této oblasti existuje také velmi silná standardizace na všech úrovních, což opět zjednodušuje zavádění novinek.

Všechny tři hlavní české sítě používají dual-stack, O2 ho zavedl v roce 2020, Vodafone v roce 2022 a T-Mobile vloni v roce 2025. Připravené jsou také obě hlavní platformy Android a iOS. Apple už od roku 2016 vyžaduje podporu režimu IPv6-only u všech aplikací přidávaných do obchodu App Store. Čísla postupně rostou s tím, jak uživatelé obměňují koncová zařízení.

IPv6 je z hlediska uživatelů technický implementační detail, který uživatele nezajímá. Stejně jako je nezajímají protokoly DNS, BGP, ICMP, TLS, DHCP, OSPF a mnoho dalších. Nikdy se nestalo, že by uživateli někdo zavolal, že by potřeboval některý z těchto protokolů. Přesto je uživatelé využívají a potřebují.

Internet ale potřebuje IPv6. Potřebuje nový protokol, aby se mohl svobodně rozvíjet a růst. IPv4 adresa je drahým zbožím pro firmy i koncové uživatele, její získání věci prodražuje a komplikuje.

Reálně nám hrozí, že internet ovládnou CDN a velké cloudy, které mají dlouhé peníze na pořízení ohromných adresních rozsahů. Získávají tím čím dál větší relevanci a moc a hrozí nám tím ztráta „malého internetu“, na kterém si mohl jednoduše kdokoliv spustit vlastní službu. Budeme ještě potřebovat IPv6, když síť ovládne deset firem?

Tohle všechno se stalo jen proto, že nám došla čísla. To je věc, která běžného uživatele vůbec nenapadne a kroutí nad tím hlavou. Nestává se, že by někdo nemohl postavit dům, protože v obci už bylo vyčerpáno všech 99 čísel popisných a další už není možné přidělit. Nám se to na internetu stalo a už to řešíme třicet let.

Radim Friedel: Už tam budem?

IPv6 se řeší už třicet let a pořád musíme odpovídat na stejné otázky o tom, proč potřebujeme nový protokol. Už ale víme, že je to budoucnost, která nás nevyhnutelně čeká. V loňském roce jsme se dočkali vlny, kdy T-Mobile spustil podporu na svém mobilním připojení. Pokud máte svého poskytovatele, otravujte to, vydržte a ono to přijde.

Google už také zaznamenal překonání padesátiprocentní hranice penetrace IPv6 adres mezi koncovými uživateli. Číslo kolísá, ale už neklesá pod 45 % ani během pracovních týdnů. Je to jasný směr a předpovídá to další vývoj.

Velkým skokanem je Svatá Helena, kde se během jednoho měsíce podařilo navýšit pokrytí na 86 %. Společným jmenovatelem je tu Starlink od Elona Muska. Ten se stává silnou konkurencí pro místní poskytovatele, kteří zaspali před patnácti lety.

Velkým krokem bylo v loňském roce také zveřejnění CLAT Windows Private Preview, což po Microsoftu chtěl především Google. Tomu se podařilo něco nemyslitelného, vyčerpal i privátní adresní prostor pro IPv4. Výsledek funguje velmi dobře a umožňuje to postavit sítě pouze na IPv6. Microsoft ale zatím neřekl, kdy to uvolní veřejně do produkce.

Konečně se snad na podzim v Network Manageru verze 1.58 objeví linuxový CLAT. Objeví se také první distribuce připravené na provoz v síti IPv6-mostly. Významně tuto změnu pomohl prosadit Ondřej Caletka, který se IPv6 dlouhodobě věnuje.

Síť CDN77 je schopna vygenerovat ve špičce více než 70 Tbps, ale jen deset procent z toho tvoří IPv6. Je třeba si uvědomit, že internet není jen Google a máme tu i další poskytovatele. Velkým podporovatelem IPv6 je Čína, ale ta není ve statistikách Googlu přítomna. Podobně nemáme plnohodnotná data například z Ruska nebo Íránu.

Z hlediska poskytovatelů služeb je dnes IPv6 naprosto zásadní u registrátorů DNS a webhosterů. Pokud narazíte na některého, který šestku nepodporuje, měli byste zpozornět a rozmyslet si, jestli s nimi chcete mít ještě něco společného.

Podobné je to u poskytovatelů cloudových služeb, kde obvykle jejich infrastruktura běží čistě po IPv6 a nabízejí ji i koncovým uživatelům. Jsou tu i výjimky, ale stále přicházejí nové zprávy o tom, kde všude byla šestka zpřístupněna. Velké e-mailové platformy dnes IPv6 umí a je velmi pravděpodobné, že pokud používáte například GMail, Outlook nebo český Seznam, proudí vaše pošta po šestce.

Mobilní operátoři jsou celosvětově tahouni zavádění šestky a je to tak už velmi dlouho. Už od roku 2012 je v Androidu podpora pro IPv6 a 464XLAT se objevil o rok později. Apple s ním přišel v roce 2016 s vydáním iPhone 7. Všichni tři naši mobilní operátoři šestku mají, díky za to, ale stále ji používají v režimu dual-stack. Je otázka, proč T-Mobile rovnou nezavedl IPv6-only síť a nezjednodušil si práci.

Různá situace je u poskytovatelů obsahu, například Alza.cz používá služeb firmy Cloudflare a dříve IPv6 podporovala. Z nějakého důvodu ale později na části svých služeb přešla zpět čistě na IPv4. Výsledek není dobrý ani u univerzit, například ČVUT ani VUT na svém webu IPv6 nepodporují, naopak dobře je na tom ostravská VŠB. Měli bychom se zamyslet nad lepší edukací, pořád je tu co zlepšovat.

Celosvětově máme stále problém s poskytovateli místního připojení. Ti se chlubí celou řadou moderních technologií, ale nepodporují IPv6. Najít poskytovatele, který má šestku plně zvládnutou, není někdy snadné, ale jde to. Často jde o jeden z požadavků ve veřejných zakázkách a poskytovatel pak často narychlo řeší, jak podmínku splnit.

Nejčastější je stále dual-stack, který je velmi jednoduchý pro nasazení. Ale nemá to být cíl, je to období, kdy platíme dva účty za jednu cestu. Poskytovatel pak musí řešit dvě sítě, monitorovat dvě prostředí a konfigurovat vše dvakrát. Od poskytovatele chceme příděl /56, stabilní rozsah adres a dobrou podporu.

Kdysi byla v New Yorku krize způsobená přílišným množstvím koní v ulicích. Kdybychom se tehdy zeptali kočích, co je potřeba, chtěli by lepší úklid a rychlejší koně. My ale už nemáme jak rozšiřovat starou čtyřku, musíme z koní přejít na automobily a rozvíjet nový protokol. IPv6 už není budoucnost. Je to současnost, kterou část trhu pořád odmítá zapnout a pořád ještě sedlá koně.

Jiří Chudoba: IPv6 v gridu pro LHC experimenty

V LHC byla od začátku v 90. letech spousta týmů o stovkách lidí, kteří byli z mnoha částí světa a potřebovali spolu komunikovat. Proto vznikl také WWW a my jsme byli také jedni z prvních, kteří jsme ho používali.

LHC je velký hadronový urychlovač, který leží ve 27 kilometrů dlouhém tunelu, na kterém jsou čtyři velké experimenty. Dochází v nich ke srážkám každých 25 nanosekund a produkuje to obrovské množství dat. Urychlovač začal pracovat v roce 2008 a v roce 2012 byl objeven Higgsův boson.

Už v roce 2012 začaly v CERNu docházet IPv4 adresy a v té době se mluvilo o zavádění IPv6. Organizace má podrobné vědecké plány do roku 2041: v následujících třech letech bude urychlovač vypnutý a experimenty se budou zásadním způsobem vylepšovat. Poté vzroste výrazně také objem dat, která budeme sbírat a zpracovávat. LHC to ale nekončí, připravuje se Future Curcular Collider (FCC), který bude mít 91 kilometrů.

Už okolo roku 2000 bylo jasné, že dat bude tolik, že není možné je v místně zpracovat. V té době neexistovala velká řešení pro distribuované počítání a začalo se připravovat ve formě takzvaných gridů. Výsledkem je Worldwide LHC Computing Grid (WLCG).

Vše je samozřejmě závislé na provozu rozsáhlé sítě, která je rozdělena na několik různých úrovní. Měli jsme připojení řádově o rychlostech megabitů za sekundu. Nebyla kapacita, aby jednotlivá střediska mohla komunikovat přímo s ostatními. Dnes je k dispozici více než 160 výpočetních uzlů, které jsou připojeny do 17 center. Jednotlivé propoje mají kapacitu ve škále stovek gigabitů za sekundu. Díky sítím CESNET a Geánt je Česko připojeno linkou 400 Gbps.

Kolem roku 2010 byla rozšiřována kapacita farmy o další servery. Už v té době nám docházely IPv4 adresy a začali jsme se zajímat o IPv6. Ukázalo se, že je možné šestku nasazovat, ale je potřeba stále provozovat IPv4 pomocí překladu adres. Původně bylo v plánu vše vyřešit během několik let a poté pracovní skupinu rozpustit. Řešíme přechod dodnes.

V současné době je veškerá disková kapacita v Tier-1 dostupná po šestce, disky v Tier-2 jsou dostupné z 98 %. Celkem 75 % výpočetních serverů má dostupnou také adresu IPv6. Nejdřív musíme mít všechny diskové servery na IPv6, protože se libovolný výpočetní server může obrátit na jakýkoliv storage server. Pak může nastat fáze, kdy se budou odebírat postupně IPv4 adresy z výpočetních serverů a teprve poté se budou odebírat z diskových serverů. Cílový stav není současný dual-stack, ale síť pouze na IPv6.

Václav Steiner: IPv6 v otevřeném standardu Matter

Za standardem Matter stojí konsorcium Connectivity Standards Alliance, které původní variantu nazvalo Connected Home over IP (CHIP). Cílem je, aby se veškerá komunikace mezi jednotlivými IoT zařízeními sjednotila. Vše je open-source a můžeme do toho všichni přispívat.

Matter je postavený na IPv6, protože nemusí řešit nepříjemnosti jako NAT. Máme poměrně velký rozsah adres, kde můžeme dělat mnoho věcí. Hlavní roli tu hraje multicast, který je v IPv6 implementován mnohem lépe. Automatickou konfiguraci zajišťuje SLAAC, takže si zařízení mohou okamžitě postavit svou síť a začít komunikovat.

Lokální komunikace probíhá bez nutnosti přístupu na internet, stačí ULA adresy a není potřeba mít vlastní globální prefix na IPv6. Pro ovládání sítě je pak možné nasadit Matter controller, který je dnes součástí mnoha zařízení jako je Apple TV, Apple Home Pod, Google Home, Amazon Echo Dot nebo můžeme využít softwarovou implementaci. Důležité je, že to není závislé na zařízení od konkrétních výrobců.

Párování je velmi jednoduché, stačí naskenovat QR kód, který je na každém zařízení. Otevře se vám nějaká nativní aplikace v telefonu, zařízení se připojí do sítě a funguje. Alternativou je opsání alfanumerického kódu ze štítku na přístroji. Každé zařízení dostane při výrobě vlastní certifikát, který je podepsán autoritou výrobce. O proces párování a komunikaci se stará Matter controller, který zajistí předání certifikátů a konfiguraci sítě.

Matter je vlastně jen aplikační vrstva a je možné jej posílat přes Wi-Fi nebo přes Thread. Wi-Fi zařízení je hodně, se standardem Thread začíná postupně pracovat třeba IKEA. Starší protokol Zigbee implementuje všechny vrstvy: aplikační, komunikační i bezdrátovou. Matter je proti tomu otevřenější a je možné jeho části postupně rozvíjet a obměňovat. Vhodná zařízení je možné vyhledávat na Matterdevices.io.

Pro provoz zařízení přes Wi-Fi není potřeba nic speciálního, bezdrátovou síť doma máme, zařízení se do ní připojí a vybere si link-local adresu, ULA adresu a případně i globální adresu. Všechny Wi-Fi čipy jsou dual-stackové, takže zařízení dostanou i IPv4 adresu. Čtyřková adresa je používána během aktualizací firmwaru, které někdy běží ze serverů pouze po IPv4.

Pokud pro přenos dat používáme Thread, používá se skutečně jen IPv6. Tato síť je velmi úsporná a je připravena na typický provoz na baterie. Běží to na 2,4 GHz, stejně jako Wi-Fi nebo Zigbee. Je potřeba na to při plánování sítě myslet. Zařízení jsou vzájemně propojená, vzniká mesh síť, ve které existuje více cest pro eliminaci výpadku.

V síti Thread vystupuje jedno zařízení v roli Leadera, což je centrální bod řídící celou síť. Poté je tam spousta zařízení v roli Router, která rozšiřují síť a přeposílají provoz mezi uzly. Poté jsou tu koncová zařízení, tedy typicky různé senzory, žárovky a vypínače. Mostem mezi threadovou sítí a ostatními sítěmi je tu takzvaný border router. Těch může být v síti víc a při výpadku jednoho se vám nestane, že se zařízení nedostanou ven.

Zařízení v síti Thread používají rozšířenou MAC adresu na 64 bitů, takže vytvoření link-local adresy je velmi jednoduché. Adresa je pak plně funkční a je možné ji normálně pingnout. Směrování sítě pak probíhá podle lokátoru RLOC, který popisuje, kde se zařízení v síti nachází. Spojením IPv6 prefixu v síti a konkrétním RLOC je pak získána konečná adresa pro směrování v dané síti.

Vyhledávání spojení, předávání parametrů a další zajišťování funkcí sítě je implementováno v protokolu Mesh Link Establishment (MLE), kterým se posílají všechny důležité parametry. Směrování je zajišťováno principem podobným RIP, takže je všechno velmi jednoduché a krásně to funguje.

Tomáš Tichý: Příprava státu na IPv6

Stát se zavázal, že do roku 2032 budou všechny veřejné instituce používat IPv6. Tomáš Tichý se rozhodl prozkoumat současný stav a posbíral detaily o obcích, vysokých školách, ministerstvech a dalších organizací. Celkem máme v Česku 6258 obcí, z čehož jsou čtyři vojenské újezdy.

Více než 77 % obecních webů používá IPv6, jen 3,6 % nepoužívá HTTPS a jen tři obce nemají dohledatelné webové stránky: Rodkov (okres Žďár nad Sázavou), Vápovice (okres Jihlava) a Žatec (okres Jihlava). Více než 92 % obcí má web na doméně .CZ, u městských částí je to 84 %. V případě krajů nabízí webové servery IPv6 jen v 35,7 %.

V případě organizačních složek státu je IPv6 dostupná na téměř 69 % webů. U veřejných vědeckých institucí je to ovšem jen 14 %. Veřejnoprávní média mají IPv6 ve 33 % případů, konkrétně jde o iRozhlas.cz a České noviny. Veřejné vysoké školy mají na web dostupný po IPv6 v 32 % případů. Týká se to hlavních stránek univerzity, ne jednotlivých kateder.

Vilém Veselý: Státní správa a IPv6

Vláda České republiky schválila dne 17. ledna 2024 umožnění plného přechodu státní správy z IPv4 na IPv6. Byl stanoven pevný termín 6. června 2032, což je neobvykle konkrétní datum. Je to vnímáno jako výhoda, mít takto jasný bod v čase. Neznamená to, že se nemůže změnit. Nemáme tu obvyklou mlhu ‚až někdy‘, ale víme, do kdy to chceme.

Kontrola stavu probíhá od července 2024 na měsíční bázi pomocí nástroje Fenix checker. Mezi lety 2024 a 2025 proběhl poměrně značný nárůst. Většina úřadů má IPv6 formálně zavedeno a webové služby jsou ve většina případů přes IPv6 dostupné.

Některé instituce bohužel stále nemají IPv6 zavedenu vůbec (csu.gov.cz, mzp.gov.cz, nbu.gov.cz a udh.gov.cz), v některých případech IPv6 nefunguje a někde funguje jen web, ale třeba je mailové služby.

MPO chce na svém webu začít zveřejňovat zprávy o stavu zavádění IPv6 ve státní správně, zintenzivnit komunikaci s hříšníky a formalizovat komunikaci v podobě oficiálních výzev. Chceme se do toho intenzivně opřít, zbývá nám šest let, takže čas na to ještě je.

Ondřej Filip: IPv6 ve světě

Česká vláda v roce 2024 přijala usnesení, podle kterého by státní správa měla v roce 2032 přejít kompletně na IPv6. Současný internet běží po IPv4. Má tedy smysl jedno nařízení vlády v jedné středně velké zemi? Jak bude vypadat internet v roce 2032 a co dělají velké země?

Ve Francii má více než 86 % uživatelů přístup k IPv6, což je jedno z nejvyšších čísel na světě. Přechod zde byl řízen silnou regulací, povinnými licenčními požadavky při získávání licencí na 5G, zveřejňováním pravidelných statistik a silnou komunikací s komunitou.

Složitější situace je v Německu, protože je rozdrobeno na řadu spolkových zemí. Přesto je v současné době nad 70 % a má národní strategii pro novou národní počítačovou síť, která má být spuštěna v roce 2030 a poběží pouze na IPv6.

Brazílie je na 55 % a jde o docela uzavřenou zemi, kde vládne organizace CGI.br, která se stará o osvětu, školení a spolupráci s univerzitami. Není to regulátor, ale má obrovskou sílu a dokáže motivovat všechny kolem sebe. Dokázali přesvědčit vládu, aby přešla na IPv6 a mobilní operátoři v Brazílii přešli na IPv6-only s využitím 464XLAT a NAT64.

Ve Spojených státech si stanovili původní rok přechodu na 2021, což se ale nestihlo a proto jsou stanoveny nové cíle a plný přechod by měl přijít v roce 2028. Je to kolébka internetu a ani tam zdaleka ne všechny vládní weby podporují IPv6.

Čína v roce 2017 oznámila nový plán pro nasazení IPv6 v celé zemi. V roce 2023 měli v plánu mít polovinu uživatelů připojených po IPv6 a oznámili, že tento plán splnili. Čína má plán a postupuje podle něj. Tvrdí, že kolem roku 2030 přejdou plně na nový protokol.

Nejlidnatější zemí světa je Indie a penetrace se tam pohybuje okolo 75 %. Mají tam řadu problémů, spoustu jazyků a přesto dokáží takovou věc zvládnout. Místní regulátor podporuje IPv6 aktivně již od roku 2005, všechny státní organizace měly přejít na IPv6 do roku 2022. Nestihli to, ale nemůžeme se divit, že v tak obrovské zemi nepanuje naprostý pořádek.

Česko se v současné době pohybuje okolo 40 %, což není nijak oslnivé. Statistiky NIX.CZ ukazují asi 16,5 % toku realizovaného pomocí IPv6. Není to příliš vysoké číslo, ale před rokem jsme se pohybovali okolo 11 %, takže pokrok v poslední době je docela velký.

Co tedy nastane v roce 2032? V Asii vidíme, že se IPv6 tlačí určitým způsobem silou a regulátoři jsou tam aktivní. Mají tam našlápnuto a myslí to vážně. Státy v EU a USA na to jdou jinak a snaží se motivovat trh. Největší brzdou jsou dnes podnikové sítě, kde vše trvá velmi dlouho často pod záminkou bezpečnosti.

Zdá se, že vypnutí IPv4 v roce 2032 už nebude tak rizikové. Možná to nebude, možná se to odloží, ale už to nebude tak mimo mísu. Zřejmě už budeme měřit jen nějaké zbytky a budeme hodně daleko.

Tomáš Hlaváček: IPv6 přestává být občanem druhé kategorie

Hypotéza říká, že IPv6 je stále méně spolehlivá než IPv4, ale postupně se to zlepšuje. Stále se ale můžeme setkat s několika implementačními problémy jako je zakázané ICMPv6, chybami v síťových prvcích nebo problémy v operačních systémech. Překvapilo mě, kolik chyb vzniklo při přechodu na systemd-networkd, který se teď stará o přidělování adres v Linuxu. Potýkalo se s nimi především Ubuntu 20.04, ale i pozdější 22.04.

Tomáš Hlaváček analyzoval data výpadků služeb mezi různými datacentry a provedl srovnání IPv4 a IPv6. Sledoval ztrátovost paketů a úplné výpadky spojení. Mezi lety 2024 a 2025 došlo ke zhoršení některých parametrů u IPv6, což přičítá různým akvizicím mezi firmami, čímž věci začaly fungovat hůře. Začaly se například objevovat výpadky pouze na IPv6, což vypadá na nějaký zásah správců, kteří si nejdřív vše zkoušeli na šestce.

V letošním roce se nám zlepšil stav IPv4, ale IPv6 se zlepšil ještě o něco více. Kumulovaná spolehlivost sítě se změnila radikálně. V letošním měření jsou na tom oba protokoly prakticky stejně, pokud jde o dlouhotrvající výpadky.

V IPv4 jsou taky problémy, o kterých všichni vědí, ale nechtějí s nimi nic dělat. Jsou tu například větší problémy s přetížením front (buffer-bloat), které vedou k rychlému nárůstu latencí pod zátěží. Tohle pod IPv6 problém není, ale důvod není úplně jasný. Zřejmě se používají jiné implementace, které nejsou na tyto problém náchylné.

Mnoho cest je dnes také rychlejších na IPv6 a mají kratší RTT. Šestka se posílá jinými cestami a zřejmě na tom má zásluhu firma Hurricane Electric. Ta nabízí štědře peering pro IPv6 a vznikají tak užitečné zkratky. IPv4 má obvykle také horší jitter než IPv6.

IPv4 adresy jsou vzácným zbožím, což nutí správce šetřit a výsledkem jsou méně optimální a robustní sítě. Jejich správci například nechtějí plýtvat adresami pro spoje a vytvářejí proto rozlehlé L2 sítě.

Michal Hrušecký: Útoky na IPv4 a IPv6

Turris vznikl v roce 2013 jako bezpečnostní projekt, který měl sbírat data o útocích na koncové sítě. Sonda musela být lákavá, proto jsme ji postavili jako router. Dnes projekt vytváří především routery, jejichž součástí je stále sonda, kterou je ale potřeba si dobrovolně zapnout.

Základem bezpečnostního výzkumu je Turris Sentinel, který implementuje minimální honeypoty v podobě falešných služeb HTTP, Telnet, SMTP a FTP. Na ně se útočník připojí a začne se nadšeně přihlašovat různými jmény a hesly. SSH je možné přesměrovat na externí honeypot, který je provozován na serverech CZ.NIC.

Od roku 2024 se sbírají také data o útocích na IPv6, ale k novému protokolu má přístup jen zhruba třetina routerů. Dvě třetiny routerů se aktualizují výhradně po IPv4. Existují ovšem vůbec nějaké útoky po IPv6? Současná data ukazují jen 0,013 % incidentů způsobených po IPv6.

Například na SMTP bylo za loňský rok zaznamenáno šest miliard přihlášení po IPv4, kdežto po IPv6 jich bylo jen 200 tisíc. Unikátních útočných IPv4 adres bylo za rok nasbírání 4,5 milionů, jakmile data agregujeme po /24, klesne počet na 900 tisíc. V případně IPv6 je pokles velmi malý, i když z /64 přejdeme na /56 nebo dokonce /48.

Pokud se na incidenty podíváme z hlediska ASN, útočí se za rok z 21 tisíc ASN v IPv4 a jen 216 ASN útočí po IPv6. Nejčastěji se útočí z Indie, Číny a Spojených států, ale to jsou obrovské země, takže lze předpokládat velkou aktivitu. Pokud se ale podíváme na šestku, vyskočí nám dopředu Německo a Francie.

Útočníci na IPv6 existují a pokud takového potkáte, je velká šance, že je z Německa. Zároveň jsou takoví útočníci méně častější a méně aktivnější. Jsou zdrženlivější, umírněnější a používají modernější technologie. Jsou to příjemnější lidé, které vlastně chcete potkat.

Ondřej Caletka: Rok IPv6-only desktopu

Rádi bychom přešli na IPv6, ale nemůžeme to udělat bez ohledu na IPv4. Internet prostě funguje na IPv4. Tečka. Přechodový protokol dual-stack vlastně selhal, protože neřeší nedostatek IPv4 adres a zároveň vlastně zakrývá problém v IPv6. Pořád tu totiž máme záchytnou síť v podobě IPv4, když IPv6 selže.

Konferenční síť pro RIPE Meeting je od roku 2022 přepnutá z původního dual-stacku na IPv6-mostly a většina mobilních zařízení a Macbooků vůbec nevyužívá IPv4. Vlastně se po přepnutí nic nestalo, nikdo si ničeho ani nevšiml.

Na straně sítě je pro IPv6-only nutné mít bezproblémově zprovozněnou IPv6 a tu je potřeba doplnit o NAT64. Existují dokonalejší přechodové mechanismy, ale odvětví si vybralo NAT64. Použití NAT64 přináší stejné problémy jako klasický NAT.

NAT64 se ale prosadil, protože pro klienty i síťové prostředí jde o běžný provoz po IPv6. Je vám jedno, jestli odesílaný provoz jde do nativní IPv6 nebo někdy po cestě dojde k překladu do IPv4. Všechny ostatní přechodové mechanismy vyžadují v cestě dvě zařízení: před přechodem do IPv6 a poté další po přechodu do IPv6 (například B4 a AFTR u DS-Lite). NAT64 je proti tomu jen jedno zařízení uvnitř sítě a na straně koncových zařízení se používá nativní schopnost komunikace po IPv6.

Na straně zařízení nesmí existovat žádná závislost na IPv4. Jenom proto, že jste nedostali odpověď od DHCPv4, nesmíte vyhazovat uživateli chybu. Třeba tam žádná IPv4 nemá být. Neplatí to ale jen pro operační systém, ale také pro všechny aplikace.

S jednoúčelovými zařízeními nebývá obvykle problém, typicky třeba IP telefony je možné začít okamžitě provozovat po IPv6. V uzavřených platformách může kompatibilitu vynutit výrobce, což se povedlo například Applu v iOS. Od 1. června 2016 musejí všechny nové aplikace v App Store být schopné fungovat na IPv6-only síti.

U ostatních zařízení je potřeba implementovat CLAT, který na straně zařízení zabalí provoz pro IPv4 do IPv6 pro provoz sítě. CLAT je dnes nutností pro bezproblémový zážitek na IPv6-only síti.

Poté je možné vytvořit síť IPv6-mostly, kde DHCPv6 odesílá volbu 108. Síť tím informuje zařízení, že je zde podporován provoz IPv6-only a v síti je NAT64. Zařízení si pak zvolí, že IPv4 nepotřebuje a adresu si vůbec neobjedná. Nemělo by se to stát, pokud je na zařízení IPv6 zakázána, ale děje se to a zařízení je pak úplně bez sítě.

Dnes tento režim podporují všechna současná zařízení s Androidem a iOS, protože některé mobilní sítě v zahraničí takové sítě provozují. Na klasických počítačích byl prvním operačním systémem připraveným pro IPv6-only systém macOS. Problém je ovšem s VPN, protože dnešní VPN klienti vypínají IPv6, ale pokud je počítač připojen místní IPv6-only sítí, zůstane úplně bez konektivity.

Na současných konferencích RIPE Meeting se už 85 % zařízení obejde bez IPv4 adresy. Všechna zařízení, která máte po kapsách, preferují režim IPv6-only. Výjimkou jsou počítače s Windows a Linuxem. I tohle se ale zřejmě brzy změní. Microsoft už pro Windows 11 zveřejnil ukázkovou verzi CLAT a připravuje se veřejná beta verze.

Podpora pro CLAT je také součástí vývojové verze Network Manageru 1.58. Využívá program eBPF pro překlad mezi IPv4 a IPv6. Není tedy potřeba žádný modul a mělo by to fungovat s běžným linuxovým jádrem. Program nahraný do jádra provádí překlad mezi oběma protokoly, ale je potřeba to zapnout volbou  ipv4.clat=auto.

Takto prováděný překlad je pro uživatele neviditelný, protože na rozhraní se objeví adresa rozhraní 192.0.0.1/32 a jako výchozí brána se pro IPv4 používá IPv6 nexthop. Otázkou je, kdy se tohle dostane do běžných distribucí a kdy to bude ve výchozím stavu zapnuté.

Jakmile se tato řešení dostanou do Windows a Linuxu, budou zbývat pokrýt kategorie IoT a Smarthome. Ta obvykle tvrdě selhávají na sítích bez DHCPv4. Tohle je ale problém jen v domácích sítích, ve firmách se taková zařízení obvykle nevyskytují nebo jsou v samostatných VLAN.

Zdá se, že se blíží rok, který bude možné označit jako rok IPv6-only desktopu. Nevím, jestli to bude příští rok nebo ten další. Počet zápůjček v DHCP pak klesne velmi blízko k nule a nasazení nativní IPv4 bude konečně volitelné.

Sítě IPv6-mostly možná pomohly nastartovat celý tenhle proces, ale možná jen přišly pozdě a zase zmizí v propadlišti dějin. Zřejmě se brzy dostaneme do stavu, kdy budou všechna běžná zařízení schopna fungovat v síti pouze s IPv6.