Využití IPv6 pro směrování v IPv4, segment routing s SRv6, Den IPv6

Letošní Den IPv6 se konal už podesáté a podruhé se na jeho organizování podílely vedle organizace CESNET také CZ.NIC a NIX.CZ. Opět byla k dispozici Wi-Fi síť pouze s IPv6 a také IPv6-mostly, které byly šířeny z routeru Turris Omnia.

Akce obvykle probíhá 6. června, ale příští rok toto datum připadá na víkend. Sejdeme se tu zřejmě 4. června, ale to je potřeba ještě potvrdit, řekl během úvodu duchovní otec akce Ondřej Caletka.

Marian Rychtecký: Úvod do SRv6

Obvykle dnes směrujeme data do cíle podle cílové IP adresy a směrování je možné rozdělit na přímé a tunelované, třeba pomocí GRE, či dalších protokolů. Nejčastěji se směruje podle nejkratší cesty, kdy je možné dobře řídit datové toky, ale neškáluje to ve složitých sítích s mnoha službami.

Proti tomu MPLS dovoluje škálovat a je hodně flexibilní. Dnes je to naprosto vyzrálá věc, která je kompatibilní a podporuje řadu různých služeb. Nevýhodou je, že jde o velmi komplexní protokol, který je velmi náročná na práci správce. Podpora v cloudových prostředích je také velmi problematická.

Novým přístupem je takzvaný segment routing, během kterého se na zdrojovém uzlu rozhodne o tom, kudy data poputují do cíle. Rozhodujete už na začátku, takže si můžete říct, jestli chcete jít nejkratší cestou, nejvýhodnější cestou nebo nějak jinak. Tato informace je pak zakódovaná do každého paketu a průběžné routery se jí řídí.

Každý segment má unikátní identifikátor Segment ID (SID) a ve výchozím nastavení je provoz směrován nejkratší cestou. Tento přístup je kompatibilní s MPLS label stackem, protože se tu mezi L2 a L3 používají také labely. Přechod je tedy velmi jednoduchý, protože se tu používají stejné principy.

V MPLS je segment definován v takzvaném labelu. Příchozí paket dorazí na první router, který naplánuje cestu a do hlavičky rovnou vyplní seznam labelů označujících průchozí nody a linky. Labely jsou uloženy mezi payloadem a vrstvou L2. Dokážeme to nějak zjednodušit?

V SRv6 už se labely neukládají mezi použité vrstvy, ale využívá se tu standardní protokol IPv6. Instrukce jsou tedy uloženy ve formátu IPv6 adresy. Využívá se tu položka next-header, která dovoluje za hlavičku přidat rozšířenou hlavičku číslo 43, ve které je definována nová hlavička Segment Routing Header dle RFC 8754.

Tato sekce může obsahovat jednotlivá SID a přidat k nim další užitečné informace: last entry se kopíruje do cílové adresy a segments left pak ukládá počet dalších hopů, které budou následovat. SRv6 také definuje nový pojem lokátor, což je vlastně rozsah adres, které obsluhuje daný uzel.

Použité identifikátory ve formátu IPv6 adres jsou tedy rozděleny na lokátor konkrétního uzlu a zbytek je pak použit pro informaci o tom, co se má s provozem na daném uzlu stát. Lokátor se po cestě mění, až paket dorazí k cílovému uzlu. Ten pak podle cílového lokátoru pochopí, že je provoz určen pro něj, vybalí jej a použije.

Struktura SID se může lišit a alespoň teoreticky je možné libovolnou část „adresy“ využít pro lokátor a zbytek pro funkci, či konec vyplnit paddingem. Zdá se, že výrobci prvků nás budou tlačit do nějakého standardního rozdělení, ale není nutné ho používat.

Celé je to možné udělat ještě jednodušeji a použít μSID, což je varianta, která dovoluje opakující se informace komprimovat do takzvaného formátu μSID. Do jednoho identifikátoru se nám tedy vejde až šest instrukcí. Tím se nám celá situace zjednoduší, protože už budeme pracovat s cílovou adresou, která ale vlastně není adresou, ale identifikátorem.

V režimu μSID už tedy adresy nemáme v hlavičce pod sebou, ale máme je vlastně v jednom poli, ze kterého se postupně odebírají jednotlivé části. Tím se adresa cíle zkracuje, až paket dorazí do cíle. Pokud potřebujete víc než šest položek SID, musíte se vrátit k rozšířené hlavičce a další instrukce vložíte do ní. Jakmile se tedy při zkracování dostaneme na konec a stále ještě počítadlo nedošlo do nuly, odstraní se celá původní hlavička a nahradí se následující hlavičkou, která obsahuje zbytek kroků. Takto je možné pokračovat až přes čtyři hlavičky.

Jakmile SRv6 nasadíte do své sítě, propaguje se uzel do sítě místním směrovacím protokolem (IGP) a oznámí svou adresu a případně další služby pomocí jednotlivých instrukcí. Pokud chcete, aby síť následovala nejkratší cestu, není potřeba vyjmenovávat všechny routery po cestě, ale jen průběžné kroky, ke kterým se budou hledat automaticky cesty nejkratší cestou. V ideálním případě vám tedy stačí jen jeden SID, koncového uzlu ve vaší síti.

Výhodou sémantiky standardní IPv6 adresy je, že je možné využít běžnou síť, která neví nic o SRv6. Proběhne tu jen vyhledání cílové adresy v běžné směrovací tabulce a paket se pošle tam. Až koncový uzel pak rozumí SRv6, provoz vybalí a pošle do běžné sítě podle funkce, která je přiřazena ke konkrétní službě.

Zatím jde o velmi mladý standard, jehož podpora se liší u různých výrobců. Doporučené adresování je z privátní alokace /24 z rozsahu FC00::/8. Pro NIX.CZ jsem zvolil FCCA:FE00::/24, nedoporučuje se alokace z veřejných globálních adres. Poslední dva čtyřbity je možné přidělit podle vlastních potřeb. Je možné to rozlišit podle různých Flex algoritmů, které dovolují vybrat jiný způsob doručování než nejkratší cestou, třeba podle latence – routery pak průběžně měří zpoždění napříč sítí a podle toho volí cestu.

Radek Zajíc: Routujeme IPv4 provoz prostřednictvím IPv6 sousedů

Obvykle se IPv6 nasazuje tak, že vedle IPv4 spustíme nový protokol a provozujeme takzvaný dual-stack. Technicky vzato je to přechodový mechanismus, protože se před třiceti lety předpokládalo, že se po nějaké době přejde jen na IPv6. Postupně ale vznikly další přechodové mechanismy jako NAT64/DNS64, DS-Lite, 464XLAT, MAP-T, MAP-E nebo IPv6-mostly.

Dalším přechodovým mechanismem je IPv6 next hops. Při klasickém směrování v IPv4 mají komunikující strany své MAC adresy a přidělené IP adresy. Pokud chceme komunikovat po místní síti, oslovíme své sousedy pomocí ARP a tím zjistíme vazbu mezi L2 a L3.

V případě, že cílový stroj není v dosahu, musíme nadefinovat takzvanou výchozí bránu, která říká, kam se má poslat provoz směřující k neznámým cílům. Zjistíme tak MAC adresu svého routeru, pošleme tam provoz a budeme doufat, že s ním router něco udělá.

Mezi routery je nutné také sestavit propojovací síť a přidělit do ní vlastní rozsah. Obvykle k tomu používáme rozsah /30, který obsahuje celkem čtyři adres, z nichž je možné dvě využít pro spojení routerů.

Je ale možné jako cílovou adresu použít IPv6 adresu, například link-local adresu. Můžeme pak říct, že routa na danou IPv4 adresu vede přes link-local adresu v IPv6. Objevování sousedů pak probíhá pomocí Neighbour Discovery (ND) místo původního protokolu ARP, provoz ale stále teče pomocí IPv4. Definováno je to v RFC 8950.

V BGP se pro tento typ spojení používá varianta BGP Unnumbered, kde se používají RA na objevování směrovačů, na které se pak naváže spojení a vymění se potřebné informace. Celá konfigurace pak může být postavena jen na IPv6 a adresy pro IPv4 se pak mohou objevit jen na nepoužívaných dummy rozhraních. Ve směrovací tabulce pro IPv4 je nutné mít uvedenu informaci o tom, jakou odchozí adresu má provoz používat. Vše je možné snadno nakonfigurovat například v démonovi Bird, v příkladech bylo použito propojení se zařízeními značky Arista.

Tohle řešení má výhodu v tom, že není potřeba používat privátní IPv4 rozsahy. Není tedy potřeba hledat nekolizní rozsahy, není nutné je evidovat a řešit chybný odchozí provoz z privátních adres. Tahle konfigurace vám také umožňuje zbavit se dual-stacku a eliminovat ze sítě IPv4. Z IPv4 adresy se pak stává jen identifikátor a neplní už funkci lokátoru.

Radim Friedel: Active Directory a SMB bez IPv4

Veřejné statistiky firmy Google ukazují určitý vzorec, podle kterého o víkendu stoupá využití IPv6 zhruba o čtyři procenta. Tahounem jsou mobilní operátoři a poskytovatelé domácích připojení, korporátní sítě jsou pozadu. Dostali jsme se do fáze, kdy naprostá většina operačních systémů v aktuálních verzích je připravena na provoz IPv6. Stejně tak poskytovatelé připojení i hosteři jsou připraveni dobře. Horší je to ve firemních sítích.

Adresní prostor pro IPv6 je nepředstavitelně obrovský. Kdybychom generovali 10 milionů kontejnerů za sekundu a každému přidělovali unikátní adresu, bude nám trvat více než 59 000 let, než vyčerpáme byť jediný rozsah /64. Myslíte, že nám to bude stačit? Já myslím, že ano.

Microsoft patří mezi velké propagátory šestky a první experimentální podpora se objevila už ve Windows 2000. Podpora se postupně vyvíjela a dostali jsme se do situace, kdy od WIndows 8 a Server 2012 máme stabilní podporu. Od Windows 10 je to výchozí protokol a Microsoft ho nedoporučuje vypínat. Podle výrobce může vypnutí IPv6 některé věci znefunkčnit. Ve Windows 11 se už počítá s provozem jen po IPv6 a je to protokol první volby.

Ve Windows XP SP2 byla přidána podpora pro Teredo a ISATAP, což mělo pomoci v přechodu na IPv6. Tohle bylo ukončeno až ve WIndows 10 verze 1803. V dnešních operačních systémech se už tyhle funkce vůbec nevyskytují.

Korporátní prostředí je vedeno tím, aby byl každý proces efektivní a na servis se vydávalo co nejméně peněz. Pokud ale IT oddělení přijde s požadavkem na více IPv4 adres pro nové služby, přicházejí ke slovu aukce IP adres. Jeden prefix /24 si dnes koupíte asi za 10 tisíc dolarů. To je ale jen půlka problému, hlavním úkolem je deratizace nově získaného rozsahu. Ty totiž bývají zanesené do různých block listů a spam listů, takže je někdy ani po letech není možné plnohodnotně používat.

Přechod na IPv6 se skládá z řady postupných kroků, kdy se z čisté IPv4 přesuneme k přechodovému mechanismu dual-stack a následovat může síť IPv6-mostly. Variantu IPv6-mostly můžeme v sítích s Windows rovnou diskvalifikovat, protože stále není dostupný CLAT. Podpora byla slíbena, očekává se její příchod v druhé polovině letošního roku.

Cílový stav by pak měl být, že se v síti bude vyskytovat pouze IPv6. Ve firemních sítích je extrémní tlak na to, aby jejich provoz byl co nejefektivnější. Provozovat dva protokoly a starat se o ně, znamená zvýšené náklady. Pokud už potřebujeme čtyřku, je lepší ji provozovat jen jako službu. Takový model provozu se prosazuje na mobilních sítích, ale postupně se dostává i k poskytovatelům optických sítí.

Pokud se korporát rozhodne nasadit IPv6, přijde celá řada logických otázek: Máme dostatečnou konektivitu? Dostaneme adresy od poskytovatele? Nebyly by lepší nákladnější PI adresy? Jak budeme přiřazovat IPv6 adresy? Pak je tu spousta dalších otázek, jak budeme síť monitorovat a podobně.

Windows Server 2025 nevyžaduje při instalaci vůbec konektivitu a poté vše bez problémů funguje bez IPv4. Protokol se neodinstaluje, ale je možné ho deaktivovat. Poté je možné nakonfigurovat například statickou IPv6 adresu a další adresu můžeme dostat od routeru pomocí RA. Autokonfiguraci je možné také vypnout. V takovém stavu ale není možné systém aktivovat, Microsoft s připojením k aktivační službě po IPv6 nepočítá. Jakmile ale zprovozníte NAT64, aktivace proběhne.

Instalátor Windows 11 vyžaduje při instalaci konektivitu po IPv4. Pokud není k dispozici, není instalátor schopen proběhnout. Po zprovoznění NAT64 se opět všechno podaří. Ve výchozím stavu je zapnuté privacy extension, ale je možné jej také vypnout.

Z pohledu Active Directory nenarazíte na žádné překvapení, vše funguje predikovatelně a naprosto stejně, jako na IPv4. Vlastně k tomu není příliš co říct.

Podpora ve Windows je velmi dobrá, je problém vůbec najít něco, co nefunguje na síti s IPv6-only a NAT64. Je třeba ale používat také nějaký software a tady je podpora různá. Třeba populární Eset sice nainstalujete, ale už neaktualizujete.

Ondřej Caletka: Problémy s provozem interních služeb na IPv6-only

Svět byl dříve jednoduchý a interní služba běžela někde v kanceláři a když jste ji chtěli použít, museli jste být na stejném místě. Poté přišly VPN a bylo možné se ke službám v kanceláři dostat odkudkoliv. Dnes jsme ve stavu, kdy i interní služby běží v cloudu a může se k nim přihlásit každý. V praxi tedy jen ten, kdo je oprávněný ji použít.

Při stěhování RIPE NCC se zrušily všechny služby umístěné v kanceláři a i tam je dostupné jen připojení do internetu. Počítače zaměstnanců používají trvale VPN a mají tak dvě síťová rozhraní, přičemž jedním z nich se dostanou k firemním službám. Tento režim se hodí pro lidi sedící v jiných zemích a nečekaně jednoduché to pak bylo o během covidu, kdy museli všichni zůstat doma.

K VPN je možné se připojit po IPv4 i IPv6 a stejně tak uvnitř této virtuální sítě je možné provozovat IPv4 a IPv6. Používá se split tunel, aby všechna data všech uživatelů netekla přes VPN.

Postupně probíhá migrace přihlášení pomocí LDAP na Single Sign-On, přičemž ověření pomocí SSO je mnohem silnější, než ověřování uživatelů podle IP adresy. Když vám služba běží v cloudu, musíte předpokládat, že uživatelé mohou přijít z libovolné sítě.

Když se v RIPE NCC spouštěla nová služba, přišel logický nápad, spustit ji jen na IPv6. Objevily se drobné překážky, jako že systém správy konfigurace předpokládal dual-stack a stejně tak dohledový systém předpokládal, že každý stroj má IPv4 adresu. Tohle se dá ale opravit, takže se na tom začalo pracovat.

Poté byla připravena první verze a kolegové měli za úkol vše vyzkoušet. Některým uživatelům vše fungovalo, ale jiní se vůbec nemohli ke službě připojit. Ukázalo se, že stub resolver v macOS se snaží být chytrý a zjišťuje, jestli má vůbec konektivitu po IPv6. Pokud ne, tak si si řekne, že nemá smysl se ptát vůbec na záznamy typu AAAA. DNS se totiž umí vždy ptát jen na jeden typ záznamů, takže neexistuje žádná optimalizace a je třeba se zeptat zvlášť na oba.

Operační systémy macOS a Windows ale VPN nepovažují za plnohodnotné připojení a ignorují IPv6 adresu na něm. Není k tomu žádná dokumentace, předpokládám, že se to řídí rozhraním s výchozí bránou. Navíc je chování nekonzistentní a pro různá systémová API dostanete různé výsledky.

To je vlastně konec celého příběhu, bylo nutné se vrátit k dual-stacku. Služba je používána po IPv6 jen uživateli, kteří mají IPv6 konektivitu doma. Uživatelé bez šestky projdou po IPv4. Alespoň nám to ale umožnilo vyřešit různé problémy s provozem IPv6 na síti.

Ukázalo se například, že SSO systém Okta používá servery jen s IPv4 adresou. Byl proto vznesen požadavek na přidání podpory. Světe div se, Okta se nám ozvala, že připravuje pilotní provoz po IPv6 a chce to na nás vyzkoušet. Zejména proto, že má řadu klientů z americké administrativy, která má nařízeno IPv6 do budoucna používat.

Dalším problémem je systém Rapid7 InsightIDR, který umožňuje vyhledávat bezpečnostní incidenty. Jednotlivá zařízení provozují agenta, který sbírá logy o incidentech ze serverů. Je to ale navržené špatně a agenti potřebují pro komunikaci s centrálou IPv4.

Tyhle věci ale nejsou specifické pro RIPE NCC. Určitě nejsme jediní, kdo používá split VPN a Okta. Je rok 2025, těžko můžeme být první, kdo něco takového zkouší. Vláda Spojených států už vyžaduje padesát procent systémů, které budou funkční ze sítí s podporou jen protokolu IPv6.

S filtrací AAAA záznamů v operačních systémech by mohla pomoci IETF. Mohl by existovat návod na to, za jakých okolností je možné některé záznamy filtrovat. Ondřej Caletka pracuje na tom, aby vznikl návrh standardu, který bude v komunitě prodiskutován.

Maria Matějka: IPv6 jako občan druhé kategorie

Když se při pohovoru na místo programátora zeptáte na libovolnou IP adresu, dostanete obvykle různé IPv4 adresy. Já to chápu, učili se to ve škole. Když se zeptáte vyučujících, dozvíte se například: IPv4 je všude, IPv6 jen někde. Pravdu technicky má, ale kam se s tím dostaneme? Podobnou odpověď vám dá IT admin: Přidělit IPv6 adresu stojí úsilí, IPv4 je hned.

Stojí to nějakou práci, ale je možné to myšlení převrátit a nejprve se věnovat IPv6 a až poté zmínit IPv4. Na mojí alma mater, na MatFyzu, se na přednáškách používají cizí IPv4 adresy a localhost pro IPv6. V jiných předmětech se používají absurdní nebo vymyšlené adresy. Ani jedna adresa není z dokumentačního prefixu. Konkrétně ze 77 slidů je 44 o IPv4 a poté je 6 slidů o IPv4. To jsou symbolická čísla, ale není to důvod učit takhle. Podobně je to i na FEL ČVUT a na komerčních kurzech dodavatelů síťových prvků.

Co to znamená mít IPv6 na prvním místě? Začít musíme dokumentací, kterou vývojáři nemají obvykle čas řešit. Chybí systematický přístup a používají se náhodné IP adresy. Stejně tak je možné změnit výuku, protože základní principy jsou stejné a používá se stejný systém adresování nebo směrování. Je nutné vysvětlit multicast, místo ARP naučit ND a DAD, ale třeba SLAAC je zdarma. Nemusím ani vykládat složitou IPv4 hlavičku a není třeba řešit na první přednášce NAT.

Obvykle je možné vyložit nejprve IPv6. Nevidím důvod, proč by to nešlo. Je možné to určit jako základ. Spousta věcí je v IPv6 udělaná správně a pokud byla dodatečně doplněna do IPv4, je to často nesystematická podivnost. Učit IPv6 jako primární je možné, pokud máte čas předělat celé materiály.

Adam Kalisz: Úskalí práce s IPv6 v ekosystému Javy

Java standardně v dual-stackovém prostředí používá IPv6 socket, pokud je IPv6 k dispozici. V takové situaci bude Java poslouchat na mapované IPv4 adrese ::ffff:127.0.0.1. To může vést k celé řadě problémů, pokud používáte klasický localhost, nemusíte se připojit. Pokud ale přepnete preferIPv4Stack na true, nebude se vůbec komunikovat po IPv6.

Druhou související volbou je preferIPv6Addresses, která je také nastavená na false a říká, že při dostupné IPv6 se budou opět používat IPv4-mapované adresy. Pokud se nastaví při startu na true, bude použita IPv6 varianta ::1 a budou preferovány IPv6 adresy.

Přepínat toto chování je možné i za chodu programu, ale kontroluje se to jen při startu. Nebude vám to nic platné, po startu je to vytesané do kamene. V keši také zůstávají pozitivní překlady DNS jmen do zastavení JVM. Můžete se na hlavu stavět a resolvované záznamy jsou uloženy v paměti do vypnutí programu. Negativní odpovědi jsou ukládány po dobu 10 sekund.

Toto nastavení také ovlivňuje překlad jmen a mění pořadí použitých odpovědí získaných z resolveru. Je možné ale přepnout volbu na system , kdy se zachovává pořadí získané od operačního systému. Pokud žádné síťové rozhraní nemá IPv6 adresu v /proc/net/if_inet6 , systém předpokládá, že IPv6 není aktivní. Také se to detekuje jen při startu a pak už není žádný způsob, jak zjištěný stav zvrátit.

Na systémech je dobré také zkontrolovat, jak vypadají soubory /etc/hosts a /etc/resolv.conf. Může se totiž stát, že aplikace poslouchá na jiných adresách, než na jaké se překládá localhost. V tom případě se pak nemůžeme s aplikací spojit.

Zajímavá je neefektivita Javy při ukládání IP adres. Objekt Inet4Address používá dohromady 56 bajtů, přičemž adresa by se vešla do čtyř. Samotný objekt zabírá 24 bajtů a uvnitř je další objekt InetAddressHolder, který může obsahovat hostname a typ adresy. Režie je téměř patnáctinásobná proti samostatné adrese. Poměrně triviálně by bylo možné to snížit na 28 bajtů.

V případě IPv6 je to složitější, protože je vše naroubované na stávající infrastrukturu. Adresa zabírá dohromady 120 bajtů proti 16 bajtům adresy, což je více než sedminásobná režie. Inet6Address obsahuje InetAddressHolder zděděný od InetAddress a přidává Inet6AddressHolder. Ten navíc přidává rozsah platnosti a pole bajtů pro adresu. Pokud píšete třeba vlastní SIEM, doporučuji si to napsat nějak příčetněji.

Radek Zajíc: Windows, VLAN trunky a IPv6: věční nepřátelé

Windows mají IPv6 od roku 2006 nativně, předtím bylo možné na starších systémech podporu aktivovat. Podnikové sítě milují VLAN, což je způsob, jak segmentovat síť na nezávislé síťové bloky. Můžete mít síť pro hosty, pro servery, pro tiskárny a tak dále. Správci ale milují jednoduchou konfiguraci.

Na portu přepínače můžete mít hybridní konfiguraci, kdy na něj pošlete značkovanou VLAN a pak také neznačkovaný provoz, o kterém už nezjistíte, že patřil do nějaké VLAN. VLAN znamená v ethernetové hlavičce dva bajty, z nichž 12 bitů značí ID dané VLAN. Tohle rozšíření ale ovlivňuje to, jak Windows přistupují k IPv6.

Windows totiž požírají VLAN tagy, takže vám do počítače dorazí dvě různá oznámení směrovače a systém si nastaví různé prefixy. Systém si ale musí vybrat zdrojovou adresu pro odchozí pakety a také bránu, přes kterou provoz pošle. Adresa se vybírá náhodně, pokud si systém vybere správnou, tak vše funguje. Když si vybere špatnou, tak vám provoz neodchází.

Proč se tohle neděje na IPv4? Protože tam se používá DHCP a když pošlete požadavek do jedné VLAN, vrátí se vám odpověď z té samé. Vy sice slyšíte provoz i z těch ostatních, ale ten můžete ignorovat. Jediné správné řešení je na zařízení před stanicí zajistit, aby k němu dorazila jen ta jedna netagovaná správná VLAN.

Tomáš Tichý: Hrajeme si s IPv6

Tomáš Tichý si pořídil několik herních konzolí a rozhodl se u nich otestovat, jak si poradí s různě nastavenou sítí používající IPv6. Například Nintendo Switch OLED vůbec nic o IPv6 neví a všechno funguje jen po IPv4. V testu IPv6 jsem dostal nulové skóre.

Sony Playstation 5 Pro nahlásí, že nedokáže fungovat v síti, kde není nakonfigurovaná IPv4. Microsoft Xbox Series Selže zase na tom, že se nedokáže připojit k DHCP serveru. U Steam Decku je potřeba přepnout do režimu plochy s KDE, kde je možné IPv6 zapnout. Ze síťového hlediska pak vše funguje, ale má to drobnou nevýhodu: nezahrajete si po síti žádnou hru, protože Steam tvrdí, že nejste připojeni.

Podobná je situace u herních obchodů nainstalovaných přímo ve Windows. Na síti s DNS64/NAT64 se všechny nainstalují, ale jen některé se doinstalují a funguje jich už jen menšina. Na čisté IPv6 už nefunguje vůbec nic, dozvíte se, že nejste připojeni k internetu. U Microsoftu se není možné ani přihlásit, protože přihlašovací stránka služby Live funguje jen po IPv4.

Radim Friedel: Schrödingerova IPv6

Cloudflare z Česka vidí necelých 25 % provozu po IPv6, což není příliš dobré. Pro představu taková pokročilá země jako Pákistán má 22 %. V Asii už jsou v takovém stavu, že CG-NAT mají tak přetížené, že provoz po IPv4 je několikanásobně pomalejší než ten po IPv6. Cena velkých řešení pro NAT je vysoká, dolarová cena začíná na šestimístných částkách.

Podle Cloudflare má v Česku mobilní operátor O2 zhruba polovinu uživatelů připojených po IPv6, v případě Vodafone je to skoro 38 %. T-Mobile má nějakých 12 procent. Přitom Radim Friedel upozorňuje na to, že i ukrajinští mobilní operátoři dokázali během války spustit podporu IPv6 a dostat ji k mnoha uživatelům. Řekli byste, že mají jiné starosti, ale tohle je pro ně podle všeho velmi důležité.

Původně se na sklonku roku 2023 mluvilo o tom, že T-Mobile už brzy spustí podporu IPv6. Poté mi bylo slíbeno, že prvního dubna to bude. Teď T-Mobile tvrdí, že už to funkuje, ale ještě IPv6 všichni nemají. Říkají nám, že musíme počkat na vlnu. Tak čekáme.

Všechny nové SIM už mají zapnutou šestku, můžete udělat kolečko a SIM si vyměnit. V opačném případě si musíte počkat, T-Mobile tvrdí, že by vše mělo proběhnout do srpna. IPv6 se ale v mobilní síti používá už delší dobu, ale jen na VoLTE. To je ale běžné, že se šestka používá k nějakému konkrétnímu účelu.

(Autorem fotografií je Petr Krčmář.)