Jan Vondráček: eduroam IPv6 only?
Na univerzitě v Pardubicích bylo v plánu oddělit eduroam od zbytku sítě, odlehčit firewallu a ušetřit. Přivedlo mě to na zajímavou otázku, zda je potřeba na IPv6 používat firewall pro koncové klienty.
Adresy se velice často mění a lokální firewall je dnes nainstalován na většině koncových počítačů. Provozujeme to tak už rok a problémy nepozorujeme.
K nasazení byl použit linuxový server, který dělá NAT64 a je mnohem levnější než hardwarové komerční řešení. Zvolil jsem Jool, protože to je jediný hotový nástroj, který to zvládne.
V Debianu je vše připraveno tak dobře, že přežije i aktualizaci systému.
Dále je potřeba server pro DNS64, ke kterému je možné použít BIND nebo třeba Knot Resolver. Já jsem použil BIND, protože ho dobře znám.
Jako DHCP server pak byla nasazena Kea, která nahrazuje zastaralý ISC DHCP. Pro logování překladů IP adres byl použit conntrackd. Jde o úsporné řešení, ale loguje to jak ďábel.
Většina aplikací funguje velmi dobře, i když i velké služby vyžadují NAT64 a nemají nativní podporu IPv6. Obrovská bída je to na herních konzolích, které nemají podporu IPv6, ale ani třeba WPA Enterprise.
Pomohlo by používat IPv6-mostly, kdy se klient může dobrovolně vzdát IPv4 adresy, pokud ji nepotřebuje.
Například u videoslužeb jsou také nepříjemné problémy, protože tyto služby vyžadují použití stále stejné adresy, jinak vás zablokují pro podezření z podvodu. Jool má parametr, který zajistí, aby měl stejný uživatel pořád stejnou adresu.
Problémem takto organizované sítě je použití VPN. Klient si totiž nenastaví IPv4 routu a přestane fungovat spojení se sítěmi, které jsou IPv4-only. Jediným řešením je CLAT, který ale funguje správně jen na macOS.
Z toho důvodu bylo potřeba zůstat v síti u dual-stacku.
Ondřej Caletka: IPv4-mapované IPv6 adresy
IPv4-mapovaná IPv6 adresa je adresa jako každá jiná. Používá pevný prefix ::ffff:0:0/96, který je doplněný o IPv4 adresu. Používají se pro kompatibilitu IPv6 socketů s IPv4, což přesahuje z oblasti sítí do oblasti programování.
Staré klientské aplikace volaly funkci socket, poté použily connect a pak se už jen posílají a přijímají data. Moderní aplikace musejí implementovat rozhodnutí ohledně adresní rodiny a poté se opět zavolá socket s jinými parametry. Výběr se provádí správě pomocí standardní funkce getaddrinfo.
Na serveru je situace trochu komplikovanější. V původním IPv4 řešení se opět zavolá socket, poté použije bind a listen. V případě IPv6 je možné opět použít stejné řešení, ale je třeba mít vícevláknovou aplikaci, která bude paralelně vedle sebe používat IPv4 i IPv6 socket. Je také možné připravit neblokující multitasking a poté funkci select vybírat správný socket a obsluhovat IPv4 i IPv6 klientů.
Pokud jste klient, víte, jak se chcete připojit. Když jste ale server, musíte očekávat, že se vám budou klienti připojovat po obou protokolech. Tohle řešení je ale složité a musí existovat jednodušší řešení.
To se jmenuje „kompatibilita IPv6 socketů s IPv4“.
Díky tomu mohou IPv6 sockety za určitých okolností obsluhovat i IPv4 spojení. Aplikace pak používá pouze IPv6 sockety a vidí tedy pouze IPv6 adresy.
Nedochází tu ale k žádnému překladu, počítač stále vytváří IPv4 nebo IPv6 pakety a žádný překladač v cestě není.
Správná aplikace by ale měla jít raději cestou dvou samostatných socketů. Používání kompatibility s IPv4 se nedoporučuje, protože ani dnes nelze spoléhat v systémech na přítomnost podpory IPv6. Pokud vám někdo v jádře IPv6 zakáže, nevytvoříte IPv6 socket.
Kompatibilita je v Linuxu a macOS ve výchozím stavu zapnutá, naopak ve Windows je vypnutá a například v OpenBSD ji nelze ani zapnout. Přenositelné aplikace tedy musejí hodnotu vždy nastavit.
Pozor také na to, že povolená kompatibilita blokuje otevření IPv4 socketu.
IPv4-mapované IPv6 adresy slouží jen k tomu, jak nacpat 32bitové adresy do 128bitové kolonky. Slouží k reprezentaci jen uvnitř počítače a do sítě by se nikdy neměla dostat.
Vložit je například do DNS by byla veliká hloupost. Proč byste něco takového dělali?
Přesto to lidé dělají.
Například jedna německá banka publikuje A záznam s běžnou IPv4 adresou a také AAAA záznam s mapovanou IPv6 adresu odpovídající stejné IPv4 adrese. Důvodem podle provozovatele je, že na autoritativní servery chodila spousta nezodpovězených AAAA dotazů. Proto prý vyplnili nějakou adresu a v dual-stacku jim všechno fungovalo.
Je to hloupost? Ondřej se rozhodl to vyzkoušet a překvapivě zjistil, že se jeho počítač připojuje na takto zapsanou adresu v AAAA záznamu. Výsledek závisí na operačním systému, prohlížeči a typu sítě. Všechna zařízení se ptala jak na AAAA, tak i na A záznamy.
Nelze tedy ušetřit množství dotazů vložením IPv4 adresy do AAAA záznamu.
Podobné problémy u klientů zakryje technologie Happy Eyeballs, ale takto špatně nastavený AAAA záznam vám rozbije DNS64. Lze to řešit nastavením DNS64 tak, aby ignorovalo AAAA záznamy s adresami mimo Global Unicast.
Výrobci operačních systémů nebo prohlížečů by mohli také filtrovat tyto adresy v resolveru.
Radek Zajíc: Častá překvapení při zavádění IPv6
GitHub před časem překonfiguroval svou serverovou stranu tak, aby místo IPv4 socketů začal používat IPv6 sockety. IPv4 adresy se tedy začaly jevit jako IPv6. Bohužel neaktualizovali access listy, které s novým tvarem nepočítaly.
V aplikaci je možné přepisovat adresy do původního stavu, nebo je možné v rámci přizpůsobení IPv6 upravit aplikaci tak, že začne poslouchat na obou socketech. Je to lepší varianta, protože se vám pak nebude na různých systémech chovat aplikace jinak.
To je jeden z příkladů, který ukazuje, že IPv6 není totéž jako IPv4 a obvykle nestačí jen podporu zapnout. Musíte přemýšlet o tom, co se uvnitř aplikace děje a jak to ovlivní provoz.
Když IPv6 vznikala, byla povinnou součástí podpora pro IPsec. Postupně se podpora dostala do IPv4 a povinnost pro IPv6 zmizela. S IPv6 nebudete mít automaticky bezpečnější síť. Záleží na tom, jak si bezpečnost sami zařídíte.
Podobně IPv6 nijak automaticky nezlepšuje ani výkon sítě, záleží na tom, jak má operátor síť nakonfigurovanou. Záleží také na schopnosti síťové platformy, kterou používáte.
V routeru může chybět například podpora pro offloading týkající se IPv6, to se ale zlepší výměnou zařízení.
Dual-stack je od začátku míněn jako přechodový mechanismus. Cílem je se IPv4 zbavit a používat jen IPv6. Potřebujeme tedy ještě v síti IPv4? Jsou popularizátoři, kteří tvrdí, že už ne.
Ve skutečnosti záleží na tom, jaká zařízení v síti používáte. Spousta zařízení bez IPv4 fungovat nedokáží, protože nemají podporu IPv6.
Ještě stále tedy obvykle IPv4 potřebujeme.
Ne vždycky je také jasné, co přesně znamená „mít IPv6“. Řadu lidí může překvapit přítomnost link-local adres na síťových rozhraních. Ty umožňují komunikaci v rámci místní sítě. Nespojíte se s nimi ale mezi různými sítěmi nebo do internetu.
Stejně tak například připojení pomocí 6to4 není plnohodnotným připojením k internetu. Kolísá kvalita připojení a většina provozovatelů bran už je vypnula. Posledním provozovatelem je Hurricane Electric. Ta technologie prostě nemá budoucnost a doporučuji ji nepoužívat.
Mít IPv6 by tedy mělo znamenat, že máte adresy z globálně routovatelného unicastu (GUA), adresy jsou registrované na konkrétního poskytovatele a máte funkční konektivitu do IPv6 internetu. Provoz může být veden tunelem, což může být plnohodnotné a funkční řešení.
V IPv4 sítích se běžně používá překlad z privátních adres, které nejsou globální. Mají se tedy v IPv6 používat místní ULA adresy? Asi by to nějak fungovalo, ale tyto adresy jsou určeny pro vnitřní použití a neměly by se takto používat.
V IPv6 je také potřeba nějak přidělovat adresy. Protože Android nepodporuje DHCPv6, je relevantní kombinace SLAAC a RDNSS.
Jde o jedinou skutečně všude funkční variantu, která dokáže uživatelům nastavit IP adresu a DNS resolver.
SLAAC funguje tak, že se klient dozví místní blok adres a sám si zkonstruuje svou adresu. Jaké adresy si ale nastaví? V IPv4 nastavujete, jaké adresy se mají klientům přidělovat. Tady nic takového není.
Router v IPv6 vezme adresy přidělené poskytovatelem, přidělí zbytek do 64 bitů pro síť a zbytek adresy si pak přidělují klienti.
Je možné mít síť s delším prefixem než /64, což ale nefunguje s automatickou konfiguraci SLAAC. Použitelné to je kdykoliv, když nepoužíváte SLAAC.
Můžete tak ale získat mnohem více adres pro jednotlivé sítě.
Routery je možné za sebe řetězit, přičemž si delegují postupně části prefixu sítě. Pokud ale některý router po cestě restartujeme, on na delegaci zapomene a komunikace z podřazené sítě přestane fungovat.
Dokud si navazující routery neřeknou o nové adresy, budou používat staré prefixy a nebude to fungovat.
Martin Huněk: IPv6 jako řešení pro slučování IPv4 sítí
Občas se stane, že se poskytovatelé slučují, protože se například společnosti vzájemně pohltí. Všichni také řeší nedostatek IP adres a musejí proto používat CGNAT a privátní adresy.
IPv6 pak obvykle není v síti reálně nasazeno.
IPv4 vzniklo mezi léty 1978 a 1981. První nasazení přišlo v roce 1983 v síti ARPANET.
První informace o nedostatku adres se objevila už v RFC 1338 z roku 1992. Začal se řešit problém, že adres tříd B velmi rychle ubývá.
V roce 1994 pak vznikl návrh překladu adres NAT v RFC 1631, přičemž od začátku šlo o krátkodobé řešení. Od začátku se předpokládalo, že dlouhodobým řešením bude přechod na nový protokol používající delší adresy.
O tomto problému tedy víme už třicet let.
S překladem adres se začaly masivně používat privátní adresy podle RFC 1918, což jsou 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Následně se zjistilo, že se adresy v různých sítích překrývají, proto byl rezervován rozsah 100.64.0.0/12, který je určen pro CNAT.
Tohle celé funguje, dokud nepotřebujeme podobné privátní sítě slučovat. Můžeme použít NAT a adresy mezi sítěmi překládat, což nám udělá problémy v DNS. Musíme počítačům na jedné straně překladu odpovídat jinak než počítačům na druhé straně.
Pro opačný směr pak můžeme přidat další NAT. Nemůžeme tím navíc pokrýt celý rozsah, musíme si vybrat, odkud kam chceme přistupovat.
Druhým řešením může být VPN, přičemž klient může být připojený jen k jedné z nich. Jakmile mám více sítí, přibývá mi klientů a různých cest do různých sítí.
Žádné skutečné řešení tohoto problému v IPv4 neexistuje.
Skutečným řešením je přechod na IPv6, ale stále tu máme ještě IPv4, kterého se zbavit nemůžeme. Můžeme ovšem nasadit NAT64, který nám pak slouží k přístupu do IPv4 sítě. Můžu mít NAT64 u každého poskytovatele a je možné do sítě přistupovat pomocí IPv6 adres.
Jak se bude postupně šířit IPv6, budeme se překladů přirozeně zbavovat.
Tohle řešení bylo funkční, ale pak proběhla další akvizice – celá skupina byla koupená jiným operátorem. Vymýšleli jinou variantu, ale nakonec se ukázalo, že tohle je jediné rozumné řešení.
Výhodou je, že řešení s NAT64 dobře škáluje pro další podobné sítě.
Ukázalo se, že to je dobré a funkční řešení. Dlouhodobým řešením je IPv4 vůbec nepoužívat, překlad adres má být krátkodobé řešení.
Krátkodobě už to řešíme třicet let. Pokud si chcete ušetřit práci, používejte IPv6.
Karel Hradecký: Zavádění IPv6 v dual-stack ve středně velké IT firmě
Karel Hradecký ve své přednášce popsal zavedení IPv6 ve vývojářské firmě, která není poskytovatelem připojení ani služeb a funguje jako konzument připojení k internetu. Zvolili jsme proto PI adresy, protože nechceme být LIR.
Tyto adresy mají určitá omezení, například není možné přidělovat podsítě dalším subjektům.
O adresy byl požádán poskytovatel připojení, vyřízení trvalo přibližně týden a příděl byl k dispozici. Předpokládal jsem, že poskytovatelé místních přípojek jsou dnes už připravení a my jsme hrozně pozadu.
Ukázalo se, že v koncových sítích není IPv6 samozřejmostí a uživatelé se snadno do firemní sítě nepřipojí. Pouze malinko přes čtvrtinu našich lidí doma k dispozici šestku má.
Více než polovina uživatelů ale šestku mít nakonec může, pokud si nakonfigurují vlastní síť.
Firma provozuje poměrně velké množství interních sítí a postupně v nich začala nasazovat IPv6. Uživatelské zařízení je nejprve připojeno do hostovské sítě a teprve po autentizaci pomocí 802.1× je přepojeno do privilegované sítě. U některých zařízení ale zůstaly nakonfigurovány i staré adresy a zařízení se neuměla rozhodnout, kudy bude fungovat.
To se vyřešilo vyšší prioritou oznámení RA z privilegované sítě.
Nakonec přechod proběhl velmi hladce a nedošlo ani k žádnému výpadku. Toho jsem se hodně bál, že způsobíme půldenní výpadek a dostaneme za uši.
Přesto ještě není hotovo, nejprve bylo nasazováno do uživatelských sítí, zbývá řada dalších interních sítí. Neděláme to žádným velkým třeskem, nové sítě už děláme s IPv6, staré zatím necháváme žít.
Dalším krokem je postupné vypínání IPv4, což ušetří práci s dvojitou konfigurací. Zatím ještě není jednoduché čtyřku vypnout, uvidíme, jak to bude vypadat v roce 2032.
Budou se muset připravit operátoři a všichni budeme muset zajet k rodičům, aby jim šestka jela.
Radim Friedel: Minimalistický IPv6 lab
Šestka je tu s námi desítky let, setkat se s ní můžeme například ve firemním prostředí. Státní správa nebo některé společnosti vyžadují IPv6.
Může jít ale také o ekonomické důvody, protože dnes například v cloudu platíme za přidělení IPv4 adres.
Jako vždy záleží na lidech. Můžeme potkat správce, který chce dojít do důchodu a šestku už potkat nechce. Pak tu ale máme nadšence, jako je Radek Zajíc, kteří vidí šestku všude.
Pak jsou tu reálná nasazení, kde uživatelé používají šestku a ani o tom nevědí.
Konkrétním případem může být stahování souborů z NAS od společnosti Synology, na kterém je možné uživateli nasdílet odkaz, odkud dokáže stahovat vzdáleně soubor. Na jedné lince mu to může stahovat dvěma megabajty za sekundu, na pomalejší lince to pak může jet sedmkrát rychleji.
Rozdíl je v IPv6, protože tu služba umí a pokud ji podporuje klientská síť, funguje stahování mimo přetíženou relay a mnohokrát rychleji.
Bohužel například společnost T-Mobile nepodporuje na mobilní ani optické síti IPv6 a už ani neodpovídá na související dotazy. Mně vloni jejich operátor slíbil, že to bude určitě do konce roku 2024.
Překážky mohou být ale i na straně poskytovatele služby, například web iPrima umí jen IPv4, ale video přenáší ze serverů ČRa, které jsou dostupné na IPv6. Ve skutečnosti pak tedy IPv6 používáte, i když to není na první pohled vidět.
Naopak web televize Nova už je dostupný po IPv6, stejně jako třeba YouTube.
Při nasazování nových technologií na síti je dobré pracovat mimo produkční síť. Dokonce mimo domácí síť, protože nejhorší jsou děti, kterým nejede YouTube.
Je proto potřeba mít jakousi laboratoř, kterou můžeme libovolně rozbít a postavit znovu. Existuje celá řada různých řešení, které mohou být pro začátečníky různě náročná.
Je možné použít linuxovou distribuci VyOS, která staví na Debianu a plnohodnotně podporuje IPv6 včetně NAT64. Další ingrediencí by měla být nějaká virtualizace, na které si můžete vše vyzkoušet a třeba si to odvézt na chatu a tam pokračovat.
Velkou překážkou stále zůstává podpora na straně poskytovatele, který buď IPv6 nepodporuje nebo má často chybnou implementaci. Pamatujete na 365internet? Ti tak dlouho odmítali šestku, až skončili.
Řešením je v takové situaci využít tunelu. Můžete nasadit výbornou službu od Hurricane Electric, která ale vyžaduje veřejnou IPv4 adresu. Pokud jste za devatero naty, nemůžete je použít.
V takové situaci můžete použít route64.org, který umí použít různé tunelování jako WireGuard nebo OpenVPN. V Česku je doporučovaný tunel od vpsFree.cz, kde stačí požádat o tunel a jste připraveni začít objevovat svět IPv6.
Poté je třeba nakonfigurovat místní síť a začít posílat RA s prefixem pro koncové stroje. Protože se chceme připojit i k IPv4, zbývá zprovoznění NAT64 buď přes některou veřejnou službu nebo přímo na místním routeru.
Tomáš Tichý: Potíže s tunely HE
V březnu roku 2022 se v Česku objevila služba HBO Max, která se ale později přepnula do angličtiny a služba se domnívala, že je uživatel ve Spojených státech. Později se ale služba přejmenovala na Max a mně se to rozbilo.
Problém byl v tunelované konektivitě, na které bylo potřeba zablokovat přístup na některé IPv6 adresy a vše začalo fungovat správně. Dnes už to problém není, už fungují nativně po šestce.
Stejný problém se pak opakoval na Disney Plus. Zase jsem musel zablokovat nějaké IPv6 rozsahy.
I na dalších webech se občas objevují problémy: Wikipedie pro registraci blokuje celý rozsah HE. Google zase vyžaduje potvrzení, že uživatel není robot. Tam to ale není problém, bylo jen potřeba potvrdit, že nejsem robot a zase to funguje.
(Autorem fotografií je Petr Krčmář.)
