Hlavní navigace

IPv6 po deseti letech: svět je v třetině cesty, Česko se zaseklo

8. 6. 2021
Doba čtení: 14 minut

Sdílet

 Autor: Ondřej Caletka
Letos je to již deset let od chvíle, kdy proběhla první velká zkouška nasazení IPv6 ve velkém měřítku. Svět se za tu dobu posunul kupředu, přestože vše nejde úplně hladce. Česko bohužel zaspalo.

Ondřej Caletka: první český mobilní operátor s IPv6

Letošní šestý ročník konference byl už podruhé online, doufejme, že v této podobě to bude naposled. Během uplynulého roku došlo v Česku k jedné významné novince: první mobilní operátor spustil podporu IPv6. V září spustil potichu operátor O2 podporu IPv6 na mobilních datech.

Proti zvyklostem ostatních operátorů se tu používá plnohodnotný dual-stack. Je potřeba manuálně přístroje nakonfigurovat a změnit jejich APN. To se snad časem stane samo. V základním režimu jsou také blokovaná příchozí spojení.

O2 o této změně své zákazníky neinformovala. Hledal jsem informace na stránkách a nenašel jsem je. Je to věc, která se prostě stala a firma v tom nevidí žádný potenciál pro medializaci, což je podle mě škoda.

Radek Zajíc: IPv6 deset let poté

Je tomu právě deset let, kdy proběhla jednodenní akce s názvem World IPv6 Day, během které tehdejší největší světové internetové firmy zprovoznily své služby po IPv6. Zapojily se značky jako Google, Yahoo, Facebook, Akamai a za Česko například Seznam nebo Active 24.

Tehdejší dostupnost IPv6 byla velmi nízká, jen asi třetina procenta uživatelů byla schopná se ke Google připojit novým protokolem. Nejstarší data jsou z konce roku 2011 a naznačují, že situace byla lepší než v globálním měřítku. Čísla tehdy byla ale tak nízká, že mohou být velmi nepřesná.

Před deseti lety byly v podstatě všechny webové služby dostupné jen po IPv4 a pokud jste chtěli přistupovat po IPv6, museli jste si najít speciální doménu jako ipv6.google.com. Nebylo tak snadné zjistit, jak je IPv6 funkční a co je třeba zlepšovat.

V té době jste se reálně mohli dostat k IPv6 v některých datacentrech a tranzitních sítích. Pokud jste měli aktivní zájem, museli jste si pořídit tunel, což je způsob, jak po IPv4 přenést provoz IPv6. Všechny ostatní technologie uměly jen IPv4: mobilní sítě, domácí připojení, firemní sítě a podobně. U internetových portálů převládal strach z toho, jak moc je u uživatelů IPv6 rozbitá.

Z pohledu globální routovací tabulky měl internet zhruba 39 tisíc autonomních systémů. V IPv6 to bylo něco málo přes 3 tisíce. Jen jedna desetina sítí měla IPv6 alespoň v nějaké podobě, alespoň na úrovni globální routovací tabulky.

Proč nechtěli poskytovatelé nabízet podporu IPv6? Báli se rozbitosti (brokenness) nového protokolu u různých služeb, která by mohla poškozovat uživatele. Když se prohlížeč nespojil po IPv6, zkoušel to ještě nějakou dobu a pak se teprve připojil po IPv4. Zpoždění přitom mohlo být desítky sekund až minuty, podle použitého operačního systému.

Uživatelé se zájem o IPv6 často používali automatické tunely jako Teredo nebo 6to4. Míra jejich používání ale postupně klesala, dnes jsou ve výchozím stavu ve Windows vypnuté a nepoužívají se. Byly rozbité a jsou rozbité.

V té době neexistovala řešení na řadu systémů: detekce DNS64, výkonná implementace NAT64, podpora aplikací pro běh na síti pouze s IPv6, rozumná podpora pro IPv6 a delegaci prefixu a bezpečnost IPv6 na switchích. Mohl kdokoliv bez problémů používat IPv6? Spíš nemohl, pokud si vše nenakonfiguroval ručně. Problém byl v automatizaci a speciálních aplikací typu IPv6-only.

Velkou změnu přineslo RFC 6555 zvané Happy Eyeballs, které vyřešilo problém rozbitosti. Klient už nemusí čekat na odpověď po IPv6, ale paralelně to zkusí také po IPv4. Pokud se mu nepodaří připojit po IPv6, dostane s k obsahu po IPv4 a nevadí to. Dostupnost této změny umožnila v roce 2012 pořádat IPv6 Launch a zprovoznit na mnoha službách IPv6 napořád. Dnes už to není primární důvod pro nezapnutí IPv6.

Další ze zásadních technologií, které se v průběhu let objevily, je 464XLAT. Umožňuje z klientského zařízení přistupovat k IPv4, pokud aplikace nepodporuje IPv6 nebo nepoužívá DNS pro překlad jména na IP. Pokud se tedy snaží připojit přímo k IPv4 adrese, zajistí CLAT překlad do IPv6, pošle ho skrz síť a PLAT v síti zase zajistí zpětný překlad. To pomohlo v nasazení IPv6 v mobilních sítích. Spousta aplikací byla rozbitá natolik, že na IPv6-only mobilních sítích nefungovala.

Skočíme do roku 2016, kdy IPv4 stále rostl lineárně a bylo k oznamováno 650 tisíc prefixů. Počet autonomních systémů vyrostl o 44 %, takže jich bylo asi 56 tisíc. Ve světě IPv6 byl nárůst větší, počet sítí se ztrojnásobil a počet prefixů se zvedl více než pětkrát. Stále jsme měli ale asi 12 tisíc autonomních systémů. To není zdaleka ani půlka. Růst začal navíc postupně zpomalovat.

Kdo už předtím zavedl IPv6, ten už u něj zůstal. Kdo jej zavést měl, jej nezavedl, například vládní služby. Ani některé nové služby jej tenkrát nepoužívaly, jako například Kubernetes, AWS nebo Azure. Podpora se začala zavádět až později a ještě v omezené podobě. Například Twitter už tenkrát existoval dlouho, ale dodnes IPv6 nezavedl. Oproti ostatním velkým službám je výrazně pozadu.

V roce 2016 už se začal projevovat fenomén, kdy více uživatelů přistupuje k IPv6 více z domova než z práce. Čísla se pohybovala globálně i v Česku okolo 10 %. Především kvůli nasazení na DSL sítích O2 a T-Mobile, které generují největší čísla. V ostatních přístupových sítích jste k dispozici IPv6 neměli.

V té době už existovaly výkonné implementace NAT64, rozumná podpora pro delegaci prefixů a podpora IPv6 v mobilním světě. Mohl tenkrát používat IPv6 kdokoliv? Pro mobilní sítě jste museli mít SIM z Polska, ale třeba na DSL jste používat IPv6 normálně mohli. Stejně tak v serverových aplikacích se situace zase posunula a provoz byl zase jednodušší.

Jak jsme na tom dnes, po deseti letech? Routovací tabulka pro IPv4 se pomalu blíží k 900 tisíc prefixů v 70 tisících autonomních systémech. Ve světě IPv6 jsme okolo 128 tisíc prefixů ve 21 tisíci autonomních systémech. Reálně tedy jen každý třetí autonomní systém využívá IPv6. Je ale vidět, že počet záznamů začíná logaritmicky růst. Prostor na zlepšení tu stále je, ale pokud používáte některého velkého poskytovatele, dostanete se k IPv6.

Google uvádí, že se k jeho službám připojuje asi třetina uživatelů. Rozkmit mezi uživateli v pracovní dny a o víkendech se zmenšil během pandemie, poté se zase troch roztáhl, ale je menší než v minulosti. Každý třetí uživatel využívá při přístupu k webovým službám IPv6 konektivitu.

Česko bohužel po úvodním startu zaspalo a dnes nás předstihly desítky jiných zemí v čele s Indií, kde má IPv6 více než 60 % uživatelů. Tam jsou hlavním důvodem mobilní sítě, kde všichni operátoři nabízejí IPv6 konektivitu. K 50% penetraci se blíží také například Německo, Malajsie, Belgie nebo třeba Řecko. V Česku jsme se zastavili někde okolo 15 %.

V některých zemích berou IPv6 vážně, patří mezi ně například Čína. Ta si rozhodnutím strany a vlády dala cíl, že do roku 2025 bude stoprocentně na IPv6. Zatím jsou na 23 %, ale mají našlápnuto a myslím si, že se ke sto procentům mohou skutečně přiblížit. Budou muset opustit IPv4 v přístupových sítích a začít fungovat IPv6-only.

V roce 2021 můžeme sledovat řadu podivností v souvislosti s IPv6. Například to, že geografická blízkost zemí nezaručuje podobnou úroveň nasazení: Portugalsko je na 37 % a sousední Španělsko jen na 3 %. Nasazení probíhá, ale v každé zemí jiným tempem.

Nové služby jsou spouštěny stále bez podpory IPv6. O2 na pevných službách i po devíti letech chybně nabízí uživatelům jen jeden prefix /64, proti tomu Starlink nabízí bez problémů /56.

Americké vládní instituce mají cíl mít v roce 2025 více než 80 % interních služeb na IPv6-only. Proti tomu české eGovernment nemá v roce 2021 na IPv6 ani svůj hlavní portál.

Podle Radka Zajíce se za dalších deset let budeme místo dual-stacku budeme víc potkávat s IPv6-only sítěmi a s IPv4-as-a-service. Cloud se díky zakázkám vlád naučí být IPv6-first a používat DNS64/NAT64. IPv4 v té době ještě nezmizí. Nezbavíme se jí tak rychle, to nejde.

Pavel Valach: Haló, tady IPv6. Vidíme se?

Že služba funguje po IPv6 automaticky neznamená, že bude fungovat také videohovor přes ni. To závisí na spoustě různých faktorů jako podpora na straně klienta, správně nakonfigurovaný signalizační server, media server, podpora STUN, TURN a ICE. Většina aplikací dnes funguje na NAT64, ale já se chci věnovat čistému IPv6 bez překladových mechanismů.

Test proběhl na IPv6 v síti CESNET a zároveň přes mobilní připojení od O2. Jako operační systémy byly využívány Ubuntu 21.04, Windows 10 Pro, Android 9 a Android 10. V nich běžely prohlížeče Mozilla Firefox a Google Chrome. U Firefoxu mám i nejnovější betu, ve které začala šestka z nějakého důvodu dobře fungovat.

Aplikace se může chovat různě, pokud má klient pouze IPv6 konektivitu. Může spadnout, nespojí se, fungují jen některé funkce nebo bude fungovat úplně normálně. Testovány byly platformy: Jitsi Meet, BigBlueButton, Nextcloud Talk, Cisco Webex, Zoom, Microsoft Teams a Google Meet. Bohužel Cisco Webex a Zoom se na IPv6-only síti ani nespojí. Ostatní byly schopny nějak fungovat.

Jitsi Meet se už od roku 2018 chlubí tím, že je plně připraven na IPv6. Důvodem jsou mobilní sítě, které dnes například ve Spojených státech už IPv6 umí. Bohužel Jitsi Meet na takové síti funguje jen částečně, funguje chat a signalizace, ale pro videohovor chyběl AAAA záznam na důležitém serveru.

Vlastní instalace Jitsi Meet fungovala mezi mobilními telefony bez problémů, horší to bylo u webové verze, která začala fungovat až s nejnovější vývojovou verzí Firefoxu.

Dalším testovaným řešením byl Nextcloud Talk, který funguje ve výchozím stavu jako čisté P2P řešení. Po IPv6 fungoval správně web, chat i signalizace, ale ne TURN server. P2P ani předávané hovory se proto nespojí po IPv6. Nepovedlo se mi to žádným způsobem zprovoznit.

Dalším svobodným řešením je BigBlueButton. Všechny komponenty by měly fungovat se šestkou, bohužel jejich testovací server neumožňuje spojit hovor. Neměl by to být prý problém, ale vyžaduje to další podrobnější testování.

Velké množství škol dnes k online výuce používá komerční řešení v podobě Microsoft Teams. Web i chat fungují po šestce, ale autorizační server podporu nemá. Jakákoliv operace směřující k přihlášení končí neúspěchem, čili je to nepoužitelné. K hovoru se také nemůžete spojit, místo toho je uživatel vrácen k chatu. Linuxová aplikace končí bez IPv4 adresy v restartovací smyčce.

Aplikace Google Meet byla naopak na IPv6 plně funkční, včetně kombinace se čtyřkovými klienty. Stejně tak Messenger od Facebooku je plně funkční, alespoň na Androidu. V desktopové verzi se mi nepodařilo uskutečnit hovor.

Pavel Valach vyzkoušel i známé komunikátory pro koncové uživatele. Aplikace Signal, Skype, Slack a Discord se nejsou schopny na IPv6-only síti vůbec připojit. Telegram má funkční chat a signalizaci hovorů, ale sestavení hovoru se zasekne už při předávání klíčů.

Vítězem této kategorie jsou WhatsApp a Messenger, který na mobilních zařízeních funguje naprosto bez problémů. Spojení s desktopem se ale nepodaří. Zprovoznil jsem jen hovor mezi počítači, které na sebe přímo na sítí viděly.

IPv6 je dnes vlastně už mainstreamovou technologií, stále se objevují problémy, zejména s desktopem. V síti s přechodovými mechanismy vám většina produktů bude normálně fungovat. Problém budete mít jen na síti se samotnou IPv6.

Martin Huněk: autokonfigurace tisíckrát jinak

Na IPv4 používáme DHCPv4, což je ověřené a dlouho už neměnné. U IPv6 známe dva způsoby: bezestavový SLAAC a stavový DHCPv6. U prefixu je to jednoznačné: máme k dispozici DHCPv6-PD. Občas se objevují návrhy, jak přidat delegaci prefixu do RA. Zatím se to nikam dál nehnulo.

SLAAC byl původně velmi jednoduchý protokol, který uměl jen ohlášení brány a autokonfiguraci adres. Nyní už je to komplexnější, umí předávat i DNS, rekurzivní servery a domény. Dokonce se objevila i snaha přidat univerzální možnost přenést libovolná data. Výhodou je, že je to velmi jednoduché a pro klienty povinné. Nevýhodou naopak je, že přidělování adres je mimo kontrolu serveru a velmi špatně se klienti přidávají do DNS.

DHCPv6 umí stavovou i bezestavovou konfiguraci, původně šlo o jediný způsob, jak se klientům předávaly informace o DNS. Pro některé sítě je dnes DHCPv6 vlastně nepotřebný. Ne úplně každý ho také podporuje. Výhodou je, že přidělování adres je pod kontrolou, je možné snadno přidávat adresy do DNS a předávat více informací. Nevýhodou je nutnost použití DUID, kterého jsou v současné době čtyři typy. Použití DHCPv6 také není povinný a neřeší routování, takže síť stále vyžaduje SLAAC.

DUID může mít různou podobu, pracuje se na páté variantě: DUID-LLT, DUID-EN, DUID-LL a DUID-UUID. Ani výrobci síťových zařízení se nechovají standardně a třeba Ubiquiti si po každém restartu do roku 2018 vygenerovalo nové. Přiřazení adresy nebo prefixu pak není jednoduché. Obecně také spočívá problém v tom, že není snadné DUID v systému zjistit. Zatím jsem nenašel univerzální způsob, jak si ho přečíst napříč distribucemi.

Poskytovatel připojení v případě IPv6 neřeší jednotlivé adresy, ale musí přidělit celý prefix. Proto jej zajímají protokoly pro přidělování prefixu. V současné době je jedinou možností použití DHCPv6-PD, což je stavový protokol. Pokud přestane fungovat, nastává problém. Ještě horší to je, když funguje jen napůl. Má stejné výhody jako DHCPv6, může předávat spoustu informací a lze s ním například jednoduše plnit DNS.

Má ovšem také podobné nevýhody: není pro klienta povinný, ne každý ho implementuje správně a opět naráží na problémy s DUID. Jedná se o kritický protokol, protože s ním řešíme routování. Obvykle funguje správně v běžném režimu, jakmile ale po něm chceme nějaké speciality, jako přidělení více prefixů, už záleží na konkrétní implementaci.

Čas od času se objevují různé návrhy na nové autokonfigurační protokoly jako RA-PD nebo nejnověji 64share. Do bezestavového protokolu se snaží vměstnat stavovou informaci o tom, že je přiřazen nějaký prefix. Vychází z mobilních sítí, kde se podpora DHCPv6-PD příliš nevyskytuje a zřejmě se to v dohledné době nezmění. Princip je v tom, že se jednomu klientovi pošle delší prefix než /64. Výhodou je, že nemá v názvu DHCP a hlavně nepoužívá DUID. Nevýhodou je, že jde o rovnák na ohýbák, budou se v něm řešit stejné problémy jako v DHCPv6-PD a přijdou další nové problémy.

Z hlediska poskytovatelů připojení je možné pro pevné použití nasadit DHCPv6-PD, ale v mobilních sítích se nepoužívá. Problémem také je, že jsme odstranili podporu EUI64, čímž jsme sice přinesli soukromí, ale odstranili pružnost.

Ondřej Caletka: programování aplikací pro IPv6, IPv4.5 i IPv10

Při programování software se objevují stále stejné chyby, které brání v nasazení IPv6. Chci na ně poukázat a budu doufat, že je časem programátoři přestanou dělat.

Problém spočívá v tom, že svět byl jednoduchý, dokud jsme měli jen IPv4. Požádali jste o IP adresu a všechno fungovalo hladce. Pak se ale objevil nový protokol a to nese požadavek na přepsání všech aplikací. Do 32 bitů prostě 128bitové adresy nedostanete. Nestačí jen rozšířit paměťové místo, protože taková náhrada by zrušila podporu pro IPv4.

Stále navíc nemůžeme říci že všichni mají IPv6. Někdo má jen IPv4, někdo má obojí a někdo má jeden z protokolů rozbitý. Správně napsaná aplikace by měla fungovat ve všech těchto kombinacích, aniž by vyžadovala zásah uživatele. Dobře napsaná aplikace by měla fungovat i s dalším protokolem, který se objeví. Udělejme tak univerzální rozhraní, aby použitá rodina IP adres byla jen implementačním detailem. Pouhou výměnou knihovny bychom měli být schopni vyměnit protokol.

Nestačí si ale říci, že vás IPv6 netrápí, protože všechny vaše služby běží jen na IPv4. Sítě s NAT64/DNS64 jsou realitou, najdeme je zejména u mobilních operátorů. Takže i když IPv6 ignorujete, uživatelé jej mohou mít. Apple to řeší tak, že aplikace bez podpory IPv6-only nejsou přijímány do App Store. Opačný přístup volí Android, který pomocí 464XLAT tento problém obchází. Telefon má vnitřně IPv4 adresu, kterou překládá do IPv6. I když aplikace otevře jen IPv4 socket, bude na IPv6-only sítí plně funkční. Na jiných platformách než na Androidu to zřejmě ale nikdy nebude implementováno.

Programátor by neměl přímo používat IP adresu, protože je tím předem zvolena rodina IP adres, kterou chcete používat. Ve většině případů to způsobí nefunkčnost, pokud dochází v sítí někde k překladu.

Chybou je také porovnávat textové podoby IP adres. To je možné dělat jen pokud jsou řetězce produkovány stejnou knihovnou s konzistentním výstupem. Existuje totiž více způsobů, jak zapsat IP adresy, které se pak neshodují. Například 8.8.4.4 je stejná adresa jako 8.8.1028 nebo 8.525316. U šestky je prostor pro různé interpretace ještě mnohem větší – můžeme použít velká či malá písmena, můžeme různě komprimovat části adresy nebo posledních 32 bitů adresy zapsat ve tvaru IPv4 adresy. Není tedy možné spoléhat na to, že porovnáte dva textové řetězce a výsledek dopadne podle očekávání.

MIF21_Dolejsova

Nejlepší je používat vysokoúrovňové funkce pro komunikaci po síti. Dnes už nemusíte ovládat přímo sockety, obvykle máte k dispozici nějaké vysokoúrovňové funkce, které kromě správného spojení dělají i další užitečné věci jako třeba Happy Eyeballs 2.0. Problém těchto API je v tom, že jsou vázané na konkrétní platformu. Pro přenositelnou aplikaci se hodí knihovna  libcurl.

Pro správné použití BSD socketů je potřeba používat správnou funkci getaddrinfo, která je navržená tak, aby byla v budoucnu rozšiřitelná pro další protokoly. Funkci předáme textové řetězce adresy a portu. Získáme pak seznam parametrů socketů seřazený podle preference. Klient se zkouší spojit na jeden po druhém, server naopak začne poslouchat na všech. Opačnou funkcí, která naopak umožňuje zjistit, na jakou adresu jste se připojili, je getnameinfo. Tahle rozhraní jsou postavena na adresy zapsané v textových řetězcích. Dá se předpokládat, že i další protokoly budou mít možnost podobného zápisu adresy.

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.