Seminář IPv6 je dnes už tradiční akce, která je pořádána od roku 2016 vždy 6. června. Příští rok vychází šestého na sobotu, takže si rovnou můžeme říct, že to bude 4. června,
zahájil seminář Ondřej Caletka z pořadatelského sdružení CESNET. Logo letošní akce odráželo fakt, že na stejný den vyšly 35. narozeniny hry Tetris.
Na letošní ročník se zaregistrovalo 196 návštěvníků, většina z nich do registrace uvedla, že jsou začátečníci. Celkem 13,7 % se zaregistrovalo přes IPv6. Vidíte, že přes šestku nějaký provoz skutečně teče.
Na konferenci byla opět dostupná síť, ve které byl dostupný jen protokol IPv6. Pro přístup do světa IPv4 byl k dispozici překlad pomocí NAT64.
Na konferenci bylo oficiálně představeno čtvrté vydání knihy Internetový protokol IPv6 od Pavla Satrapy. Knihu je možné zakoupit či stáhnout na webu Edice CZ.NIC.
Radek Zajíc: IPv6: from zero to hero
Showmax provozuje video službu na vyžádání, která je rozšířená především v Africe. Snažíme se jít hodně dopředu a nasazovat nejnovější technologie.
Konkurentem je Netflix, který se naopak zaměřuje na Spojené státy, kde je IPv6 velmi rozšířená a služba ji používá.
V lednu letošního roku přišel požadavek od operátora z Keni, který chtěl provozovat Showmax přes IPv6, aby tak ulehčil svému CG NAT. Rozhodli jsme se, že spustíme IPv6 alespoň na službách dostupných z venčí. To se dá udělat docela rychle a je to dobrý začátek.
V současné době ještě šestka na produkcí není, ale během jednoho nebo dvou měsíců by měla být.
Proč ale spouštět službu na IPv6, když v místní síti v kanceláři nový protokol není? V loňském roce jsme se rozhodli aktualizovat síť a spustili jsme dual-stack. Později jsme pro blázny a experimentátory přidali IPv6-only síť s NAT64.
Showmax používá servery od společnosti Hetzner, kde je každý server v samostatném L2 segmentu a dostává vlastní rozsah /64. Všechny adresy můžete používat, celý segment je routovaný na váš server. Tenhle způsob nám hodně zjednodušil život a umožnil nám udělat spoustu věcí.
Důležitou součástí projektu je také monitoring, protože bez dohledu by se mohlo snadno stát, že by se spustila podpora nového protokolu a ten by třeba uživatelům nefungoval. Užitečný je například nástroj Bloodbath, který sleduje propojení různých služeb mezi sebou a v barevné matici přehledně zvýrazňuje případné problémy.
GeoIP je způsob, jakým získat informace o konkrétní IP adrese: země, město, poskytovatel připojení a podobně. Poskytujeme video na požádání, tam jsou bohužel určitá regionální omezení.
Před deseti lety komerční databáze GeoIP od MaxMind žádné informace o IPv6 neobsahovala, dnes je situace jiná a informace už v ní dostupné jsou.
Pro logování se používá ELK, ve kterém bylo potřeba upravit jen pole client_ip. Kvůli nutnosti změny indexu byl datový typ změněn jen pro nově ukládaná data. Kibana ale nepochopila, že máme dva různé indexy. Nakonec jsme si vytvořili druhou skupinu, ve které máme jiná IP data.
Výsledek funguje velmi dobře a rychle, na dotaz ke konkrétní adrese či rozsahu dostane operátor okamžitě všechny informace o daných klientech.
Pro ochranu proti útoku se používá blokace pomocí Blackholingu, kdy se nástrojem ElastAlert agregují data podle IP adres a po překročení stanovené hranice je klient zablokován. Tohle nefunguje pro IPv6, protože potřebujeme agregovat jednotlivé adresy. Chceme blokovat podle rozsahů /64.
Pro IPv6 bylo potřeba také překonfigurovat komponenty HAProxy a Varnish, které na klientské straně poslouchají na šestce, ale do vnitřní infrastruktury zatím komunikuje po čtyřce. Interní komponenty zatím po IPv6 neběží, ale už musí umět pracovat se šestkovými adresami.
Samostatnou kapitolou je Docker, ve kterém dříve vše bez problému fungovalo, ve verzi 1.12.4 se ale poměry změnily. To jsou experti, kterým se podařilo rozbit localhost a link-local konektivitu.
Jediným způsobem, jak šestku do kontejneru opravdu dostat, je zprovoznit pro ně plnohodnotnou konektivitu.
Showmax pro zpracování obsahu používá zhruba 150 mikroslužeb. Ty bylo potřeba projít a zkontrolovat, jestli se při požadavku obsahujícím IPv6 adresu nemůže něco rozbit.
Ukázalo se, že většina věcí fungovala správně, kromě geolokačních dat, což bylo později opraveno.
V další fázi se správci rozhodli projít zkouškou ohněm a na jeden den publikovali v DNS AAAA záznamy vývojového prostředí. Žádný významný problém se neobjevil, proto bylo později rozhodnuto o trvalém provozu testovacího prostředí na IPv6. Nic se nerozbilo, zatím nám nepřišel žádný report, který by se vázal k IPv6.
Co bude dál? Během července by měla být spuštěna podpora IPv6 na produkci, ke konci roku bude následovat podpora na autoritativních DNS serverech, během roku následujícího by pak měla být podpora nasazena i na dalších službách uvnitř infrastruktury. Když budete nasazovat IPv6, nikdy nepředpokládejte, že něco nějak funguje. Ďábel je skrytý v detailech.
Ladislav Růžička: Adresní plánování: není nakonec /29 málo?
Když začne poskytovatel připojení připravovat adresní plán, nejprve by se měl zamyslet nad tím, co s přiděleným rozsahem. Na první pohled to vypadá, že adres je velmi mnoho. Škrtnete ale /64 přidělovaných do sítě a hned jste na polovině. Kolik tedy přidělit?
Dříve bylo doporučováno dávat uživatelům /48, ale to je podle Růžičky příliš mnoho. Ne pro uživatele, ale poskytovatel by takto velmi rychle svůj příděl vyčerpal.
V případě přídělu /32 by zůstal prostor na 65 tisíc zákaznických sítí. To pořád vypadá jako poměrně hodně, ale poskytovatel chce mít síť nějak rozumně rozdělenou.
Pro poskytovatele je důležitá hlavně routovací tabulka, která by neměla být zbytečně velká. Nechce mít 10 tisíc záznamů pro 10 tisíc klientů. Chce si síť rozsegmentovat a routovat velké rozsahy.
Z rozsahu /32 tak může například do segmentu poslat /40, což je 256 rozsahů /48. Zase mi ale zůstává jen 256 takových segmentů.
Pokud by takto poskytovatel připojoval například panelové domy, mohl by jich připojit jen 256. To je jedno město a vyčerpali jste si celou /32.
Pro koncovou síť je možné přidělovat jen /56, tím získáte 256krát větší prostor. Pro koncového klienta to stačí, měli byste v tomhle smyslu přemýšlet.
Jan Bětík: Soumrak automatických tunelů pro IPv6
Protokol Teredo vznikl na půdě Microsoftu a je kodifikován v RFC 4380. Snahou je rozšířit IPv6 mezi klienty, kteří nejsou připojeni do nativní sítě. Provoz se balí do UDP paketů v IPv4 a tuneluje se na nejbližší relay server. Používá se zde adresní prostor 2001::/32, do kterého se kóduje IPv4 adresa serveru, IPv4 adresa klienta a port.
CZ.NIC provozuje brány pro Teredo ve dvou lokalitách, za 24 hodin se tudy přenese v odchozím směru 12,3 GB provozu. Servery nepropagujeme do zahraničí, ale jen v NIX.CZ. Proto tam máme tak malý provoz, navíc od loňského roku provoz Teredo tlumíme.
Zajímavějším tunelovacím protokolem je 6to4, který byl standardizován v roce 2001. Jeho cílem je propojit ostrovy, ve kterých je dostupná IPv6 konektivita. CZ.NIC také provozuje 6to4 relay. Za 24 hodin se v příchozím směru přenese 4,1 TB dat a v odchozím 2,6 TB. Máme tam relativně velký provoz na fec0:0:0:ffff::/64, což je subnet určený pro autokonfiguraci DNS serverů. Je to natvrdo zadrátováno ve Windows.
Provoz na tyto adresy přichází převážně z Číny. Nejvíce provozu nám chodí na adresy Facebooku a Microsoftu.
Přes 25 % připojených sítí propaguje do internetu své šestkové prefixy, mezi největší patří Belgie, Řecko, Německo, Spojené státy, Indie, Uruguay a Vietnam. Podle Google se blížíme k 30% globální IPv6 penetraci. Za rok toto číslo navíc vyrostlo o 5 %.
Tunelovací technologie umožnily tlačit na poskytovatele připojení, aby začali implementovat IPv6 nativně. V Česku penetrace stoupá a my nechceme provozovat tunelovací technologie na věky věků. Postupně bude docházet k jejich útlumu a až nebudou potřeba, tak se vypnou.
Pokud poskytovatel IPv6 nenabízí, nebojte se ho bombardovat dotazy. Nakonec tam někoho naštvete a on se rozhodne vám zalepit pusu. V závěru budete spokojeni oba.
Jan Pokorný: Výkonnost open source implementací NAT64
NAT64 je nasazován v sítích, ve kterých je provozován pouze protokol IPv6. Spojení proti cíli s IPv6 probíhá běžným způsobem, protějšky podporující jen IPv4 se kontaktují pomocí bezestavového NAT. Cílová IPv6 adresa vznikne transformací původní IPv4 adresy. Pakety pak směřují do zařízení, které se chová jako NAT a překládá komunikaci z IPv6 do IPv4.
Aby byl provoz provoz na tyto adresy směrován, používá se princip DNS64, kdy jsou doménová jména překládána na IPv6 adresu NAT64. Výhoda tohoto mechanismu je, že je pro koncové zařízení zcela transparentní, klient dostává běžné IPv6 adresy, které ze svého pohledu může běžným způsobem kontaktovat.
K NAT64 je možné přidat ještě další komponentu zvanou 464XLAT, kdy se provádí dvojí překlad pro případ, kdy klient potřebuje kontaktovat skutečnou IPv4 adresu protějšku. Tyto pakety jsou přeloženy do IPv6 a směřují se do sítě. Tam proběhne zpětný překlad na IPv4 a odešle do internetu.
Toto už vyžaduje kooperaci s koncovým zařízením, které musí 464XLAT podporovat.
Existuje několik open-source implementací: v uživatelském prostoru jsou to Tayga a WrapSix, v linuxovém jádře pak existují Jool a Ecdysis. WrapSix má ale implementační problémy, a Ecdysis se od roku 2014 nevyvíjí. Zbývají tedy vlastně jen dvě řešení: Tayga a Jool.
Tayga se ovšem nevyvíjí zřejmě od roku 2011, což ale v případě implementace v uživatelském prostoru nevadí tolik, jako u jaderného modulu.
Testování výkonu různých implementací probíhalo na serveru s procesory Xeon D-1537 s 10GbE kartou a CentOS 7. K serveru byly připojeny dva počítače, které si spolu pomocí NAT64 předávaly data. Na použité platformě jsme schopni saturovat 10GbE linku už při paketech velikosti 500 bytů a více.
Při překladu mezi protokoly je dosahováno výrazně horších výsledků. Tayga dosáhla na 0,9 Gbps (0,15 Mpps), Jool na 8,6 Gbps (0,7 Mpps). Tayga je implementována jednovláknově a pokud chceme saturovat gigabit, je vícevláknovost zásadní podmínkou.
V implementaci Jool byla nalezena chyba, která je opravena ve verzi 4.0.1, pak bylo možné linku saturovat a dosáhnout přenosu až 1,14 Mpps.
Martin Huněk: Automatické objevování prefixů pro NAT64
DNS over HTTPS a DNSSEC jsou technologie, které brání hladkému nasazení NAT64. Současné řešení je kodifikované v RFC 7050, které se ptá na AAAA záznamy známých domén a snaží se detekovat prefixy pro NAT64. Tento mechanismus ale neřeší všechno: chybí priority prefixů, DNS64 musí běžet na DNS používaném klienty a je tu nebezpečí podvržení detekovaných informací.
Existují další možnosti jako je použití protokolu PCP nebo signalizace v DHCPv6. DHCPv6 není povinné a třeba v Androidu to nebude fungovat.
Připravuje se nový návrh standardu, který počítá s doplněním informací do RA.
Martin Huněk vytvořil vlastní návrh standardu, který by využíval SRV záznamů v globálním stromu. Výhodou je nasazení DNSSEC, správná funkce i na cizím DNS resolveru a podpora priorit.
Naopak nevýhodou je, že detekce nebude fungovat v případě, že klient vůbec nepoužívá DNS.
Tomáš Chott: IPv6 v metropolitní síti Praha1.net
Metropolitní síť Praha1.net buduje novou infrastrukturu na moderní úrovni. Od roku 2011 má vlastní ASN a s IPv6 se počítalo od začátku. Původně jsme používali Quagga, ale mělo to velkou spotřebu paměti. Poté jsme přešli na BIRD a zjistili jsme, že je to najednou hrozně nenáročné.
V průběhu implementace se přišlo jen na drobné konfigurační problémy v Linuxu, větší problémy byly ve Windows. Vyzkoušeli jsme to, odladili a funguje to.
Překvapením bylo, že v rámci platformy Cisco ASA je k dispozici plná podpora IPv6. Konfigurace je velmi jednoduchá a hlavně funkční.
Dodnes je minimální poptávka po IPv6, včetně firemních uživatelů. Ze začátku byla překážkou také velmi malá podpora u koncových routerů. Naráželi jsme na různé problémy, buď nám to nepřebíralo prefixy nebo nepřidělovalo adresu.
Celkově jsou problémy hlavně s DHCP, kdy se na rozdíl od IPv4 nepřiděluje na bázi MAC adresy. Vyzkoušeli jsme to ale staticky a všechno fungovalo.
V rámci BGP, iBGP a OSPF je nasazeno na 100 %, jádro sítě je na tom stejně dobře a agregace zhruba na 90 %. Největší problém je zatím v nasazení u koncových uživatelů, kde je síť jen asi na 1 %. Nechtějí to po nás ani firemní uživatelé, všichni se nás stále ptají jen na IPv4.
Ondřej Caletka: e-mailové služby na IPv6-only
Neběží.cz je web, který vznikl v roce 2012 jako osobní příspěvek ke světovému spuštění IPv6. Byla to jedna z deseti českých domén, které neměly IPv4 adresu.
Na webu byla od začátku kontaktní e-mailová adresa provozovaná na IPv6-only. Lidé nám chtěli poděkovat, že to je dobrý nápad, ale nedomailovali se. Napadlo mě, že by bylo dobré to automaticky testovat.
U e-mailu existuje řada různých problémů, které spolu nemusejí souviset: zda lze doručit zprávu po IPv6, zda umí protistrana přijmout zprávu po IPv6, zda je schopen přijímat zprávy s IPv6-only obálkovou adresou či s IPv6-only adresou odesílatele.
Vznikl tak automatický odpovídač na test@nebezi.cz, který odpoví z IPv4-only adresy pomocí dual-stack přenosu. Zároveň poštovní server pošle druhý mail z IPv6-only přenosu. Když se to nepovede, posílá se nedoručenka pomocí dual-stack přenosu.
Srdcem je běžný server Postfix, který má dvě osobnosti (personalities). První je dual-stacková, druhá IPv6-only. Výběr se provádí podle obálkové adresy odesílatele.
Poštu přijme procmail a předá ho do skriptu v Pythonu, který vygeneruje odpovědi či nedoručenky.
Situaci pokrývají RFC 2821 a RFC 5321. První říká, že pokud pro dané doménové jméno neexistuje MX záznam, má se hledat záznam typu A. Pokud se najde, pracuje se s ním, jako by šlo o MX záznam.
Druhé RFC je ve stavu návrhu a neurčuje konkrétně A záznam, ale obecně adresu.
Během roku 2012 bylo přijato zhruba 100 mailů z 88 domén. Velká část z nich kvůli chybě v konfiguraci neposlouchala na portu 25. Žádný freemail tenkrát nepodporoval doručení po IPv6.
Dnes je situace výrazně lepší a problém s přijímáním spojení po IPv6 mezi lety 2014 a 2016 úplně zmizel. Nejvíce mail serverů skončí na chybě “Host or domain name not found”.
Pavel Satrapa: IPv6 4. vydání
Pavel Satrapa na konci konference představil čtvrté vydání své knihy o IPv6, jejíž předchozí verze vyšla v roce 2011. Sleduji změny průběžně a když se objeví něco nového, zapracuji to. Nová je přibližně třetina knihy.
Připomínkami a radami přispěli Ondřej Caletka a Radek Zajíc, kniha má 464 stran. Elektronické verze knih je možné si stáhnout na webu knihy.nic.cz.
Klíčovou změnou je zapracování RFC 8200, které reálně mnoho nemění a hlavně shrnuje změny zavedené jinými RFC. IPv6 se také začalo konečně používat, což se odráží v řadě oblastí.
Statistiky Google ukazují přibližně 30 % návštěv po IPv6.
Mezi podstatné novinky patří také stabilní náhodné identifikátory podle RFC 7217, které vznikají jako haš různých údajů. Není žádný důvod, aby měly 64 bitů. Očekávám, že časem tato hranice padne a alespoň v části adresního prostoru budou identifikátory rozhraní kratší.
Další zajímavý vývoj proběhl v rozšiřujících hlavičkách, které na papíře vypadají dobře, ale v praxi trpí řadou problémů. Jednak jsou zneužívány pro různé útoky, také snižují pravděpodobnost doručení až o desítky procent a nově musejí být všechny v prvním fragmentu. Obecně je tu ale snaha se jim vyhýbat.
Novinkou je také algoritmus Happy Eyeballs, kterým aplikace minimalizuje následky nefunkčního spojení. Obstará si adresy z IPv4 i IPv6 a snaží se navazovat obě spojení, aby se vyhnula různým problémům.
Posun proběhl také u přechodových mechanismů, kdy došlo k posunu od propojování ostrůvků IPv6 k odstraňování IPv4. Současný trend je IPv4aaS – připojení jen po IPv6 a doručení IPv4 v podobě služby. Nově jsou v knize mechanismy 6rd, lightweight 4over6 a 464XLAT. Některé tunelovací protokoly a služby naopak odumřely. Prostor pro nezávazné koketování je dnes menší, ale zase přibývá poskytovatelů, kteří šestku nabízejí jako běžný protokol.
V knize je tak nová část o koncové síti bez IPv4. Zatím je to exotika, ale bude jich přibývat. Facebook například tvrdí, že ve svých datacentrech už IPv4 vůbec nemá.
Změny nastaly také v softwarových směrovačích, kde došlo k přechodu od Zebry přes Quagga až po FRRouting. Je tam ale víceméně jen ze sentimentálních důvodů, protože tuto oblast jednoznačně převálcoval BIRD.
Ostatní řešení vedle BIRD podle Satrapy nestojí za pozornost.
