Android bude zřejmě umět DHCPv6, jak šlape IPv6 na Starlinku

Osmý ročník Semináře nejen o IPv6

Google dnes hlásí asi 43 % přístupů po IPv6, vloni to bylo asi 40 %. V AMS-IX tvoří IPv6 kolem čtyř procent objemu, ale roste stejně rychle jako IPv4. IPv6 nabízí bohužel stále jen jeden český mobilní operátor, ostatní jej ignorují, řekl na úvod Ondřej Caletka. Naopak Starlink už IPv6 nasadil a podporuje.

Bez IPv4 se stále ještě neobejdeme. Bez IPv6 se ovšem dá ještě pořád docela dobře žít. Na Seminář se 80 % uživatelů přihlásilo prostřednictvím IPv4 a 20 % po IPv6. To je ustálené číslo, které se příliš nemění.

Jako každý rok bylo možné se na konferenci přihlásit k Wi-Fi pomocí Turrisu Omnia. Síť přidělovala pouze IPv6 adresy, NAT64 zajišťoval nástroj Jool a DNS64 pak Knot DNS Resolver. Letos poprvé síť respektuje volbu 108 v DHCP dle RFC 8935, takže síť je IPv6-mostly.

Ondřej Caletka: přístupové sítě IPv6-mostly

Dlouho si lidé mysleli, že nejlepším přechodovým mechanismem je dual-stack, kdy jsou sítě IPv4 i IPv6 vedle sebe. IPv4 bude fungovat jako vždycky a IPv6 tu bude navíc. Když se nám ale IPv6 rozbije, máme problém. Proto vznikl mechanismus Happy Eyeballs, který sám zajistí návrat k IPv4.

Tento přístup je sice funkční, ale neřeší to, kvůli čemu IPv6 vlastně vznikla a nezbavíme se IPv4 adres. Jak bude síť růst, budou růst zároveň i nároky na počty adres IPv4 a nic jsme nevyřešili.

Je možné ovšem také postavit síť čistě na IPv6, kdy původní IPv4 funguje jen jako služba. Zařízením se zdá, že celý internet je dostupný po IPv6. Pokud tomu tak není, postará se kombinace NAT64 a DNS64 o překlad do původního typu sítě. Funguje to obvykle velmi dobře, až na okrajové případy, kdy to selhává.

V mobilních sítích to funguje velmi dobře, protože mobilní operátoři mají sílu ovlivnit to, jak se budou chovat mobilní telefony. Nejdále je v tom Apple, který už v roce 2016 donutil vývojáře opravit aplikace, aby na takové síti fungovaly správně. Mobil má v sobě překladač CLAT, aby uspokojil potřeby aplikací, které vyžadují na rozhraní přidělenou IPv4 adresu. Provoz se pak překládá do IPv6 a pak se znovu na hranici sítě pomocí NAT64 převede zpět do IPv4.

Problém ovšem zůstává u desktopů, kde je možné psát aplikace různými způsoby. Navíc desktopové operační systémy, kromě macOS, nemají CLAT. Je tedy možné síť v režimu IPv6-only provozovat alespoň pro mobilní zařízení? Sítě se rozšiřují, ale zejména o tato moderní zařízení. Vyčerpáváme tak zbytečně IPv4 i pro zařízení, která jej nepotřebují. Takto vznikly sítě IPv6-mostly.

Využívá se standardní DHCP, kde může zařízení signalizovat novou volbu 108 nazvanou IPv6-only Preferred. Pokud jí DHCP server nerozumí, normálně nabídne IPv4 adresu, klient ji potvrdí a začne používat. Pokud ale server této volbě rozumí, vrátí také volbu 108, signalizuje možnost nepoužití IPv4 na půl hodiny a poté se komunikace předčasně ukončí.

Podpora mezi zařízeními je překvapivě velmi široká, aktuální verze Android, iOS a macOS jsou připraveny. Během nejnovější konference RIPE meeting proběhlo sledování požadavků na DHCP a ukázalo se, že 79 % všech unikátních MAC adres volbu posílalo a bylo ochotno pracovat v síti IPv6-mostly. To je hodně, ale záleží to na zařízeních v konkrétní síti. Dá se předpokládat, že tady bude situace o něco horší, protože tady jsou uživatelé s Windows a Linuxem.

Nasazení na straně sítě je velmi snadné, protože většina DHCP serverů podporuje definici vlastních voleb. Je pak možné volbu 108 aktivovat v konfiguraci a doplníte informace určující, na jak dlouho má být informace v síti platná. Je to velmi jednoduché a na DHCP serveru není potřeba žádná zásadní změna. Server ale musí mít volné adresy, které může klientovi nabídnout. Pokud má vyčerpaný pool, nebude signalizovat klientovi ani volbu 108.

Zásadní výhodou je, že v takové konfiguraci máte pouze jedno síťové prostředí a nejsou plýtvány IPv4 adresy. Přesto tam pořád jsou a stará zařízení je dostanou. I ta je ale budou používat minimálně, protože většina provozu půjde po IPv6. Zároveň je to ale nejkomplikovanější typ sítě, ve kterém je stále potřeba provozovat i IPv4 a k tomu ještě NAT64. Zůstávají problémy s interoperabilitou zařízení, takže pro běžného uživatele do domácí sítě to zatím ještě nelze doporučit.

Zvažte nasazení IPv6-mostly, pokud nepoužíváte NAT a plní se vám DHCP pool nebo jste velcí a dochází vám privátní IPv4 adresy za NATem. Bez problémů to bude v sítích, kde jsou provozována převážně mobilní zařízení nebo ta od Apple. Ideální řešení to tedy je do školní nebo korporátní sítě.

Pavel Valach: šestka.sin.cvut.cz

Sincoolka je kolejní klub na Sinkuleho a Dejvické koleji, kde se dobrovolníci starají nejen o blaho studentů, ale také o počítačovou síť. Máme asi 430 připojených členů, zhruba 20 z nich je aktivních a 5 z nich jsou administrátoři.

Samotná infrastruktura není nijak neobvyklá a zahrnuje síťové přepínače, Wi-Fi AP, linuxové servery, virtualizace, tiskárny a bezdrátový spoj Ericsson. Celá infrastruktura běží na IPv6, až na některé jmenovité výjimky. Ty jsou buď způsobeny omezením technologie nebo pouhým nedostatkem času. Jádro sítě tvoří prvky Juniper EX4600, přístupové prvky pak tvoří Juniper EX2300.

Celá síť používá poměrně malý prefix /57, což značí 128 sítí s prefixem /64. Je to dáno nějakými technickými omezeními, ale zatím jsme neměli potřebu to řešit. Veškerý použitý software má velmi slušnou podporu IPv6: ISC BIND, Knot DNS, Knot REsolver, Kea DHCPv6 a FreeRADIUS. Nasazení technologie RADIUS nám velmi pomohlo nejen s řízením přístupu do sítě, ale zároveň umožňuje sledovat provoz na síti.

Používané přepínače Juniper mají velmi dobrou podporu IPv6 a nepotřebují mít nastavenou IPv4 pro provoz. Většina jich ani nemá, některé je mají spíš historicky. Výjimkou je stack, kdy jsou prvky propojené do virtuálního šasi. Buď to nebude fungovat vůbec, nebo se vše rozbije prakticky každou změnou v konfiguraci.

Wi-Fi AP od společnosti Cisco nepotřebují vůbec IPv4 adresu k žádné své činnosti. Pozor na to, že nemůžete mít zároveň povolené přidělování adres pomocí DHCPv6 a povolit automatické přidělování pomocí SLAAC. Zařízení si pak bude neustále adresy měnit a bude se kvůli tomu restartovat.

Podobně také AP společnosti Ruckus umožňují pracovat v IPv6-only síti, ale i tady jsou některé menší problémy. Kontroler ale IPv4 vyžaduje zejména proto, že si stahuje z internetu licence a posílá telemetrii. Pokud jsou AP v duálním režimu, často používají ke komunikaci IPv4, i když by nemusela.

Klienti nemají s IPv6 už dávno žádný problém, už v roce 2015 bylo možné jednoduše zapnout DHCPv6. Nikdo si nestěžoval a okamžitě se asi třetina provozu přelila na IPv6. Obdobný efekt pak nastal při zapnutí SLAAC na Wi-Fi.

Původně síť podporovala generování IPv6 adres pomocí SLAAC, ale na firewallu byli klienti nuceni přepnout nastavení tak, aby byly adresy odvozovány od MAC. Je to jednodušší pro administrátory, ale bylo nutné psát návody, jak to nakonfigurovat v operačním systému.

Proto došlo později ke změně a adresy se začaly přidělovat po DHCPv6. Tohle bylo také přímočaré, ale nefungovalo to s Androidem. Ani DUID nebylo možné použít, proto byl nakonec nasazen démon dhcpy6d, který přiděluje IPv6 adresy pomocí MAC. Bohužel to stále neřeší problém s Wi-Fi.

Proto byl nakonec na Wi-Fi zapnut SLAAC, takže si zařízení přidělují adresy automaticky. Wi-Fi AP pak umožňují sledovat přidělované IP adresy a odesílat je RADIUS serveru. Jelikož jsou všichni uživatelé autentizováni, implementace byla velmi snadná. Sledujeme uživatelská jména, MAC adresy, relace a IPv6 adresy. Dokážeme tak každou adresu dosledovat až ke konkrétnímu uživateli.

Tomáš Tichý: emailové služby na IPv6 a IDN

IDN je způsob zapsání doménového jména, který dovoluje zapsat i jiné znaky než čistou latinku. Protože DNS ale povoluje jen omezenou skupinu znaků, musí dojít k transformaci pomocí takzvaného punycode. Pokud klient nepodporuje IDN, můžete název zkusit napsat pomocí punycode. U některých služeb ale nepomůže ani tohle.

CZ.NIC ovšem IDN v doméně nepodporuje, jediná doména s českými znaky je háčkyčárky.cz, kterou provozuje sám CZ.NIC. Tomáš Tichý si vytvořil e-mailovou adresu to@máš.marný.eu a rozhodl se otestovat jednotlivá řešení.

Většina desktopových klientů odmítla takový účet vůbec nakonfigurovat, případně došlo později k různým problémům, například s adresou v certifikátu. Běžnější je dnes webmailový přístup k mailu, kde se ukázalo, že na přijímací straně nebývá problém a kromě Seznamu pošta přišla. U odesílání je to horší, jen dvě služby ze šesti poštu s IDN odeslaly.

Podobně nastal problém u různých služeb, kterých bylo testováno celkem 60. Jen u šesti z nich se podařilo zřídit účet, dalších sedm vypadalo spokojeně, ale nikdy nepřišel registrační e-mail. V kombinaci s IPv6 byl poměr ještě horší. Obvykle se dozvíte, že používáte neplatnou e-mailovou adresu nebo se něco rozbije a e-mail stejně nedorazí.

Radek Zajíc: IPv6 v cloudu

Cloud může zahrnovat aplikace, platformy, infrastruktur a podobně. Z vašeho pohledu je to něco, o co se nestaráte a jen to používáte. Existuje také hybridní cloud, což můžou být dvě řešení různých poskytovatelů vedle sebe. Můžete mít ale také vlastní infrastrukturu ve svém datacentru.

Na okraji cloudových sítí se obvykle používá nějaké CDN, kde obvykle nebývá s IPv6 problém. Cloudflare nabízí podporu IPv6 od roku 2011 a ostatní se postupně přidávají. Pokud tedy používáte CDN, typicky je k dispozici podpora IPv6 už dávno.

Podobně je to i u load balancerů, které směrem k uživatelům obvykle IPv6 podporují. Jiná otázka je, jak se chovají load balancery směrem k aplikacím. Musíte si pohlídat, zda komunikace běží po IPv6 nebo se přejde na IPv4.

Síť v cloudovém prostředí bývá poměrně složitá, ale před uživatelem bývá tahle komplexita skrytá například za tunelem. Ne každý poskytovatel cloudového řešení má nastavenou IPv6 standardním způsobem, například Microsoft provádí na hranici sítě překlad z vnitřních adres na globální. Donedávna chtěli dokonce ještě za každou využitou IPv6 adresu na vnějším rozhraní platit měsíční poplatek.

U nabízených služeb je dnes podpora IPv6 velmi dobrá, obvykle se ke zdrojům dostanete i po IPv6. Poslední v tomhle ohledu byl Google, který podporu zavedl v roce 2022. Podpora tam je a je docela funkční.

Objektová úložiště docela dobře s IPv6 fungují, nejlépe je na tom Amazon S3. Musíte proto ale použít speciální hostname, ty výchozí umí jen IPv4. U databází je to až na menší problémy také v pořádku. Souborová úložiště jsou typicky implementací NFS, ale tady obvykle IPv6 nefunguje a musíte projít meziprotokolovým překladem.

Moderním tématem je dnes Kubernetes a v komunitě se vede debata o tom, jak jej správně provozovat. Každý kontejner vám bude konzumovat IPv4 adresu, takže si příliš nepomůžete. V případě Google a Azure je možné provozovat Kubernetes jen v režimu dual-stack.

Amazon vypadá na první pohled lépe, IPv6 funguje správně a do internetu odcházíte nativně. Když do toho ale přidáte problém s přístupem na IPv4, narazíte na velký hack. Virtuál má druhé síťové rozhraní s IPv4 adresou a odchozí provoz je překládán jednak na hostiteli, ale znovu také v síti. Není to úplně IPv6 only, ale tady jsme blízko.

Provoz sítě IPv6-only je dnes možný s omezeními pouze v AWS, kde je možné spustit aplikace v prostředí, kde je možné mít pouze IPv6 adresu. Pokud aplikace potřebuje do IPv4, může použít DNS64 a NAT64. K poskytovatelům je možné si přinést i vlastní adresy, což je řešitelné pro IPv4 i IPv6.

Mezi nejpopulárnější automatizační nástroje dnes patří Terraform a jen pro AWS je otevřeno 122 chyb týkajících se IPv6. V případě Azure jsou to čtyři chyby a u Google devět. Není z toho jasné, jestli kód pro Azure a Google je tak dokonalý, že v něm nejsou chyby, nebo ho nikdo nepoužívá. Vypadá to spíše na to, že se IPv6 více využívá u Amazonu a jinde tolik ne.

Cloud není všespásný a u IPv6 platí, že je hodně věcí na vás. Vy tvoříte adresní plány a musíte říct, která síť je veřejná, která je interní a podobně. U mnoha služeb je potřeba aktivně podporu zapnout, požádat si o IPv6 a aktivovat přístupová pravidla. Je to na vás, u všech tří poskytovatelů je podpora ve výchozím stavu vypnutá.

Mnoho služeb podporu IPv6 postrádá nebo jim chybí některé vlastnosti běžné v IPv4. Můžete pak chtít provozovat cloudovou službu v IPv6, ale jedna chybějící vlastnost vás zastaví. Vy pak musíte zvažovat, jestli vám stojí za to celou službu kvůli tomu předělat.

Ľubor Jurena: adresace IPv6 v síti hostingového a cloudového poskytovatele

Jak získat adresy pro IPv6? Můžeme ji získat od svého nadřazeného poskytovatele nebo se můžeme stát členem RIPE NCC a získat celý prefix jen pro sebe. Ten je pak možné dále dělit do jednotlivých podsítí nebo svým zákazníkům.

Často se stává, že správci sítí alokují IPv6 adresy stejným způsobem, na jaký jsou zvyklí z původního IPv4. Přidělují například 256 adres s prefixem /120, k čemuž ale není důvod a se SLAAC to pak nefunguje. Podobně se přidělují privátní bloky a po uživateli se pak chce NAT. Někteří poskytovatelé pak přidělují jen /64 s tím, že to uživateli musí stačit. Je pak problém předat adresy do podsítě.

V datových centrech je pak také častou praxí přidělení společného prefixu /64 pro všechny zákazníky a poté směrování konkrétních rozsahů na jednotlivé adresy. Stačí pak malá změna, třeba výměna MAC adresy a celé se to rozbije a je opět potřeba kontaktovat datacentrum a prosit o změnu. Nehledě na to, že v takto organizované síti je například problém s delegací podsítí.

Když dostaneme vlastní prefix, měli bychom si nejprve vytvořit adresní plán. Ten by měl být velmi jednoduchý, aby ho dokázal pochopit náš nový správce nebo zákazníkův technik. Do prefixu je možné pro přehlednost integrovat další informace jako číslo VLAN, informaci o lokalitě a podobně.

Musíme také počítat s růstem do budoucna. Když po nás teď zákazník chce /56, dejme mu rovnou /48 a máme jistotu, že o něm dlouho neuslyšíme. Důležitým parametrem je také agregovatelnost. Nebudeme muset kouskovat směrovací tabulky, zjednodušíme si práci a zrychlíme konvergenci pro dynamické směrovací protokoly.

Lukáš Malý: satelitní internet Starlink a podpora IPv6

Starlink je družicová konstelace provozovaná společností SpaceX, která dnes čítá asi 4000 družic. Celá konstelace by měla být dokončena v roce 2027 a měla by zahrnovat 12 tisíc družic. Vedlejším nepříjemným efektem je vliv na astronomická pozorování a fotografování oblohy.

Pozice jednotlivých družic je možné sledovat na satellitemap.space. Existuje několik generací družic, ty novější mezi sebou komunikují pomocí laserového paprsku. Data takto doputují k nejbližšímu bodu, odkud mohou zamířit k některé z pozemních stanic.

První generace terminálu se jmenuje Circular Starlink Kit a byla dodávána se směrovačem UTR-201. Půl roku jsem to testoval a překvapilo mě, že je to velmi dobře použitelné. Také jsem si všiml, že nefunguje IPv6. Konfigurace probíhá skrze mobilní aplikaci, směrovač nemá žádné webové rozhraní.

Starlink je velmi kritizován za řadu nestandardů. První generace má například od antény neodpojitelný kabel a má neobvyklý PoE injektor. Směrovač druhé generace už vůbec ethernetové rozhraní nemá. Pokud ho chcete, musíte si dokoupit další kabel, který používá zvláštní konektory. U druhé generaci napájí anténu přímo samotný směrovač.

Zařízení je orientováno velmi uživatelsky, stačí jej vybalit z krabice, nasadit na trojnožku, propojit kabely a zapojit do zásuvky. Potřebujete pak jenom výhled na oblohu a zbytek si nastavíte jednoduše v mobilní aplikaci. Pro české uživatele je navíc Starlink velmi dobře lokalizován.

První generace směrovače podle dokumentace nepodporuje IPv6. Rozhodl jsem se ho tedy vyměnit, i když jsem se bál, jestli to vůbec půjde. Naštěstí si uživatelé aktivně vyměňují informace a zkušenosti s podobnými změnami.

Po výměně směrovače za pfSense začala podpora IPv6 fungovat prakticky okamžitě. IPv4 využívá CGNAT a uživatelské rozhraní získá privátní adresu z rozsahu 10.64.0.0/10, která je pak na hranici sítě přeložena na veřejnou adresu. IPv6 je pak přidělována pomocí DHCPv6 PD a uživatel dostane rozsah /56.

Zařízení je možné podrobně monitorovat pomocí protokolu gRPC, který využívá i oficiální mobilní aplikace. Lukáš Malý má vlastní řešení, které mu s pomocí Raspberry Pi či PC získává potřebná data a odesílá je do Zabbixu v internetu. Vše je ke stažení na GitHubu.

Latence se pohybuje průměrně mezi 30 a 50 milisekundami a zařízení dopředu ohlásí blížící se automatickou aktualizaci včetně následného restartu. Komunita sleduje verze firmware, které se objevují a reportuje je na webu StarlinkTrack.com. Starlink nikde neuvádí informace o tom, co které verze mění.

Běžné uživatelské zkušenosti jsou velmi dobré, občas se objevují mikrovýpadky. U takové služby to musíte očekávat, jinak byste byli bláhoví. Je jich ale jen velmi málo a jsou krátké. Pro práci je dobře použitelné, VPN mi nepadá a videokonference krásně běží. Reálné rychlosti se pohybují okolo 200/20 Mbps.

První generace terminálu stála 12 000 Kč a měsíční provoz stál 2500 Kč. Postupně se to zlevnilo na 1400 Kč měsíčně. Druhá generace terminálu stojí okolo 8 000 Kč a měsíčně se za službu platí 1700 Kč s daní. Nemusíte platit pořád, služba je připravená na to, že ji můžete kdykoliv vypnout a některé měsíce neplatit.

Martin Huněk: DHCPv6 na Androidu?

SLAAC je původní bezestavová konfigurace, která původně sloužila pouze k nastavení adres. Je to jednoduché, povinně implementované a původně se používal standardní identifikátor EUI-64.

Proti tomu DHCPv6 je nepovinný a například Android ho nepodporuje. Pokud očekáváte, že se do vaší sítě budou připojovat mobilní telefony, nemůžete používat jen DHCPv6. Výhodou je, že umí přenášet mnohem více informací a máme ho více pod kontrolou.

DHCPv6 PD (prefix delegation) je stavový protokol a je to jediný způsob, jak zajistit autokonfiguraci prefixu. Když to nefunguje, máte problém. Není to sice routovací protokol, ale routuje to. Ne každý ho bohužel implementuje správně.

V rámci IETF se dnes pracuje na tom, aby si o prefix mohl požádat i klient. Druhý dokument pak popisuje, jak tuto možnost směrovač klientovi signalizuje. Oba tyto návrhy jsou z dílny Google. V principu to funguje velmi podobně jako delegace prefixu do sítě. Router přidělí adresu, zařídí routování a přidělí klientovi rozsah /64.

Takto přidělený prefix je off-link, takže není použito vyhledávání sousedů (ND). Zároveň je méně náročný na paměť, kdy stačí jedna routa místo sedmi záznamů v ND cache. Zařízení pak může používat libovolný počet adres z přiděleného rozsahu.

Návrh tvrdí, že většině velkých sítí by měl stačit prefix /32. Zároveň ale RIPE NCC povoluje maximální velikost ASSIGNED prefixů na /48. Tím se z toho stává ekvivalent /16 u IPv4, takže pokud vám to nestačí, můžete rovnou začít předělávat adresní plány.

Každý klient má dostat minimálně /64, autoři se nenechávají přesvědčit na delší prefix mezi /80 a /120. Tím se dostáváme do situace, kdy v IPv6 máme nedostatek prefixů. Návrh ale zároveň neřeší skutečný problém s mnoha adresami na klientech. Návrh zmenšuje prostor v IPv6 s faktorem 2⁶⁴.

V Androidu tedy pravděpodobně DHCPv6 bude, ale pouze v této variantě. Klasické řešení v něm není a nebude. Diskuse je spíše formální a autoři nechtějí připustit prodloužení prefixu. Stejně bude potřeba v praxi změnit IPv6 stack v zařízení, takže je možné rovnou přidělovat i jiný suffix pomocí jiného identifikátoru.

K oslavě bohužel není příliš důvod. Taková implementace DHCPv6 v Androidu částečně pomůže, protože bude mít síť kontrolu nad přidělováním adres a bude je moci logovat. Bohužel nám to zbytečně zmenšuje adresní prostor globálního internetu.

Ľubor Jurena: SLAAC Privacy Extensions

SLAAC je nejjednodušší způsob generování IPv6 adresy. Princip je velmi jednoduchý: host pošle žádost na všechny směrovače a zpět dostane seznam prefixů, které jsou k dispozici. Připojí svůj identifikátor rozhraní a vytvoří si tím celou adresu. Následně se detekuje, zda takovou adresu už nepoužívá nikdo jiný. Pokud ne, začne se adresa používat.

Jako identifikátor rozhraní se dříve používal EUI-64, což je modifikovaná MAC adresa. Výhodou je, že správce může snadno identifikovat konkrétní zařízení. Nevýhodou je, že je takto možno sledovat uživatele přesouvajícího se mezi sítěmi.

Sledování má pomoci rozšíření Privacy Extensions dle RFC 4941, kde se identifikátor rozhraní začne generovat náhodně a neustále se mění. Druhou možností je Stable Private Addresses dle RFC 7217, což je stabilní adresa vygenerována náhodným 128bitovým identifikátorem, který je uložen v konfiguračním souboru a při každém startu se znovu načte. Podpora je součástí systemd-networkd i NetworkManagera.

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