Seminář o IPv6 byl organizován teprve podruhé, ale zájem o něj byl tak velký, že kapacita sálu byla brzy vyčerpána. Podle toho, kolik je tu lidí, se i tenhle seminář podařil. Alespoň co se týče návštěvnosti,
řekl na začátku Ondřej Caletka, organizátor ze sdružení CESNET. Letos se zaregistrovalo 363 návštěvníků, což zabralo největší posluchárnu v komplexu ČVUT. Pokud akce dále poroste, budeme mít problém s prostory. Ale to neznamená, že nemáte chodit. Přijďte i příště!
Většina registrovaných účastníků o sobě tvrdí, že jsou začátečníci. Oproti minulému ročníku nám poklesl počet uživatelů, kteří se registrovali po IPv6. Z 19 na 12 procent.
Na konferenci byla k dispozici IPv6-only síť, kterou šířil router Turris Omnia. Je tam i NAT64, takže by síť měla fungovat na všech normálních zařízeních. Vyzkoušejte ji určitě na svém mobilu.
V průběhu akce proteklo přes router celkem 18 GB dat, zajímavé je, že přes 55 % objemu bylo přeneseno pomocí IPv6.
Pavel Satrapa: úvod do IPv6
Historie IPv6 sahá do první poloviny 90. let, kdy začal internet rychle růst a bylo potřeba podstatně více adres. Stačí si prodloužit křivku růstu a zjistíte, že adresy dojdou okolo roku 2002.
Bylo tedy na čase se rozhodnout, zda aktualizovat IPv4 nebo vytvořit úplně nový protokol. Protože tenkrát bylo času poměrně dost, bylo rozhodnuto vytvořit nový protokol, který umožní zapracovat nové vlastnosti.
První specifikace pak vznikla v roce 1995 jako RFC 1883.
Cílem bylo především zajistit výrazně více adres, což vyžadovalo mimo jiné změnit podobu IP hlavičky. Vznikl systém rozšiřujících hlaviček, které dovolují řetězení hlaviček. Můžete tak přenášet informace pro každý router po cestě nebo jen pro cílový stroj.
Příkladem je například hlavička pro fragmentaci, která je na jednu stranu potřeba, ale přináší problémy.
Pavel Satrapa, TUL
Fragmentovat v IPv6 smí jen odesílatel, takže pokud po síti dorazí příliš dlouhý paket, zahodí se a pošle se ICMPv6 zpráva o tom, že je potřeba data zmenšit. Bohužel v mnoha sítích se tento provoz filtruje, takže se tato informace nemusí k odesílateli dostat.
Bohužel jsou rozšířující hlavičky zneužívány k různým útokům. Například se používají dlouhé řetězce hlaviček, pošlete jich třeba stovky, což zatěžuje firewally.
To je možné spojit s fragmentací a transportní hlavičku dát až do posledního fragmentu. Na to reaguje RFC 7112, které říká, že všechny hlavičky se musí vejít do prvního fragmentu. Zajímavé čtení je také RFC 7872, které vychází z měření, ukazujícího, že použití fragmentace zvyšuje pravděpodobnost zahození na 30 %. Můj soukromý názor je, že se fragmentace na internetu nebude používat vůbec. Na papíře to vypadá dobře, ale v praxi to naráží na řadu problémů.
Vytvoření IPv6 bylo primárně motivováno rozšířením adresního prostoru, proto se podle Satrapy autoři vyřádili
. Adresa je čtyřikrát delší než v IPv4 a je zapisována v šestnáctkové soustavě čtveřicemi číslic oddělenými dvojtečkou. Pamatuje se to velmi špatně, je potřeba to nějak automatizovat, například pomocí DNS.
Existují tři základní typy adres: individuální (unicast), skupinové (multicast) a výběrové (anycast). Ty první určují jedno rozhraní, druhé skupinu rozhraní a poslední umožňují data doručit nejbližšímu členovi. Absence broadcastu se řeší speciálními multicastovými skupinami.
Adresy jsou globální a skládají se ze čtyř částí: první kus prefixu přiděluje IANA, druhou RIR, třetí LIR a poslední velkou část si pak určuje správce sítě. IANA pro RIR dnes přiděluje sítě s prefixem /12, jednotlivé LIR pak dostávají /29 a zákazník pak dostává /48 až /64. Standardní délkou je /48, ale existují sítě, kde dostanete skutečně nejdelší možný prefix /64 pro jedinou podsíť.
Identifikátor koncového rozhraní se dříve vytvářel pomocí MAC adresy, což bylo nezapamatovatelné a hlavně bylo možné při putování sítěmi konkrétní stroj stále sledovat, protože měl konec adresy vždy stejný. Tak se vymyslelo náhodné přidělování identifikátoru. Z hlediska soukromí je to výborné, ale pokud máte spravovat nějakou síť, máte problém.
Je nutné logovat vazbu mezi krátkodobými náhodnými adresami a identitou uživatelů.
Změnu přineslo RFC 7217, které zavedlo identifikátory vytvářené z hašů z několika hodnot včetně prefixu sítě. V každé síti má stroj jinou adresu, ale v konkrétní síti má vždycky stejnou.
To zajišťuje soukromí a zjednodušuje to správu, protože z hlediska jednoho správce používá počítač vždy stejnou adresu.
Důležitou součástí IPv6 je objevování sousedů, což je jakýsi švýcarský nožík, který toho na síti řeší hodně. Vychází z ARP, který umožňuje hledat k adrese příslušnou linkovou adresu.
V IPv6 umožňuje ověřování dostupnosti sousedů, důležitou automatickou konfiguraci a detekci kolizních adres. Na rozdíl od ARP se ND neposílá všem, ale jde na skupinovou adresu vyzývaného uzlu. S velkou pravděpodobnosti bude oslovovaný v dané skupině sám, protože je pravděpodobné, že jen on má dané poslední tři bajty adresy.
Adresy jsou pak udržovány v cache sousedů, která aktualizuje informace o dostupnosti jednotlivých partnerů na síti.
Nastavení síťových parametrů v IPv6 probíhá dvěma způsoby: bezestavově a stavově. Tradiční způsob je autokonfigurace, je možné ji ale rozšířit i o podporu DHCPv6. Bohužel to autoři proti klasickému DHCP upravili kreativně tak, že se nedá téměř používat.
Při bezestavové konfiguraci (SLAAC) posílají všechny routery své ohlášení, ve kterém je možné najít například prefix sítě, MTU a nově také informaci o DNS. DNS tam dříve nebylo, ale když nemáte přístup k DNS, nemáte vlastně přístup k síti. Proto se tam později tato informace přidala.
Při použití DHCPv6 je základ podobný jako u IPv4, ale nevychází se z MAC adresy, ale z identifikátoru klienta DUID. Ten může být přidělený výrobcem, vygenerovaný a uložený operačním systémem nebo může být nějak odvozen z MAC. Problémem DHCPv6 je, že nenastavuje směrování, pro které je stejně potřeba na síti šířit ohlášení směrovače (RA). Další problém je, že široce podporované jsou jen DUID generované operačním systémem, což znamená, že při přeinstalaci měníte identifikátor. Zároveň, pokud třeba klonujete operační systém na víc strojů, kopírujete i identifikátor. Je to tak problematické, že jsme na to rezignovali.
Velkým tématem je bezpečnost v IPv6, kde se řeší různé falšování odpovědí, oznamování směrovače a podobně. Řešením je RA Guard (RFC 6105), který je implementován na centrálním L2 prvku (přepínači) a propouští jen zprávy od definovaných strojů. Je to velmi jednoduché a bezestavové. Pokud přijde například ohlášení směrovače od počítače, který být směrovačem nemá, prvek jej nepropustí k ostatním klientům.
Dalším bezpečnostním mechanismem je SEND, který přidává ke zprávám digitální podpisy. Je to takové těžkotonážní řešení, které klasicky naráží na distribuci klíčů a nedostatečné rozšíření implementací. Příliš to zatím nefunguje.
Funkčním řešením je SAVI (Source Address Validation Improvement, RFC 7039), které vytváří vazbu fyzického rozhraní a IPv6 adresy. Je například možné takto hlídat duplicity a nedovolit, aby si zařízení libovolně měnilo síťové údaje a například podvrhovalo zdrojovou adresu. Výhodou je, že není potřeba podporovat SAVI ve všech prvcích, ale jen v části sítě, do které se připojují klienti. Je to velmi použitelné a nosné řešení.
Pro období přechodu od IPv4 k IPv6 existuje řada různých mechanismů: dual stack, tunelování a překlad. Tunelování i překlady mají svá omezení a typicky se tu bojuje s fragmentaci a délkou paketů. Pakety se při použití těchto mechanismů zvětšují, takže je tu potenciál různých problémů a skřípe to.
Koncová zařízení dnes stále potřebují přístup k IPv4, protože řada služeb není ještě stále jiným protokolem dostupná. Pokud chce mít i IPv6 adresu, je možné nabídnout oba protokoly zároveň (dual stack), případně je možné šestku tunelovat na koncovém zařízení nebo překládat na routeru. Můžete tak zařízení připojit k oběma sítím a ono o tom ani neví.
Výhodou je, že nemusíte koncovému zařízení přidělovat vůbec IPv4 adresu.
Čím dál častěji se objevuje obrácené tunelování, protože IPv4 adres je skutečně málo, takže se poskytovatelé snaží hodně šetřit. Typickým zástupcem je DS Lite, kde je celá infrastruktura provozována na IPv6 a domácí routery uživatelů balí veškerý IPv4 provoz z lokální sítě do IPv6. Poskytovatel pak má centrální koncentrátor tunelů, kde mu běží i NAT.
Uživatelé pak mají ve své síti dual stack, ale poskytovatel na své infrastruktuře řeší jen IPv6.
Zajímavou alternativou je také NAT64 společně s DNS64. Taková síť byla spuštěna i přímo na konferenci. Klient dostane jen IPv6 adresu a celý IPv4 prostor je namapován do daného prefixu, takže se uživateli všechny zdroje na internetu tváří tak, jako by měly IPv6. DNS64 posílá uživateli generované IPv6 adresy i pro servery, které takovou adresu nemají. Na centrálním prvku se pak komunikace přemapuje do IPv4 a funguje to.
Podle Satrapy je to varianta funkční a prakticky prověřená.
IPv6 se postupně šíří, pod hlavičkou IPv6 fóra běží program IPv6ready, který umožňuje udělit certifikát připravenosti na nový protokol. Dnešní operační systémy se šestkou už počítají, stejně jako směrovače a aktivní prvky. Všichni dnes IPv6 podporují a umí a ve výchozím stavu je to zapnuté,
řekl na konci přednášky Pavel Satrapa.
V AMS-IX je dnes IPv6 provozu průměrně 55 Gb/s. To vypadá hodně, ale je to stále jen 1,7 % provozu.
Google tvrdí, že se k němu po IPv6 připojuje okolo 30 % uživatelů, o víkendu tento provoz ještě narůstá o několik procent. Je vidět, že domácí přípojky jsou na tom o něco lépe.
Podle informací 6lab.cisco.com vyrostl počet uživatelů v Česku od roku 2013 z 2 % na dnešních 10 %. Růst už není tak dramatický, ale v letech 2014 a 2015 jsme vyrostli asi pětkrát.
Tomáš Hlaváček: tunelování IPv6 dříve a nyní
Podle Tomáše Hlaváčka z CZ.NIC je IPv6 v České republice v koncových sítích už velmi dobře dostupné. Léta tu máme komerční poskytovatele, kterým šestka dobře funguje. Pokud jsme ale uzavřeni v IPv4-only síti, která nás z nějakého důvodu nepustí ven, nastupují tunelovací mechanismy.
Tunely je možné jednoduše rozdělit na ručně staticky konfigurované nebo automatické. Dříve se používaly tunely 6to4 nebo Teredo, které ale byly velmi nespolehlivé. Geoff Houston dělal před časem průzkum a ukázalo se, že 18 % paketů v 6to4 se nedostane k cíli. Kvůli nespolehlivosti se tedy dnes už příliš nepoužívá.
Tomáš Hlaváček, CZ.NIC
Velmi používaný je dnes 6in4, který je velmi velmi spolehlivý, používá jednoduchou statickou konfiguraci, ale vyžaduje veřejné IPv4 adresy a nefunguje za NAT. To řeší protokol AYIYA (Anything In Anything), který byl ale bohužel součástí uzavřeného řešení od SixXS a toto řešení už není dostupné. Tím jsou prakticky vyčerpány možnosti, kterých může použít přímo koncový uživatel a nepotřebuje k tomu součinnost svého poskytovatele připojení.
SixXS měl na svém konci 46 přístupových bodů ve 29 zemích a měl 38 tisíc aktivních uživatelů. Ukončení své činnosti vysvětloval dvěma argumenty: jednak je IPv6 už dobře komerčně dostupný a tunely dnes už slouží jen jako výmluva pro poskytovatele, kteří nechtějí nový protokol zavádět. Největší růst probíhal mezi lety 2008 a 2010, pak už služba stagnovala.
Ve špičkách služba přenášela přibližně 700 Mb/s. Podle Tomáše Hlaváčka je to tím, že poskytovatelé objemného obsahu se snaží vyhnout doručování pomocí tunelů. Protože používají CDN, mají velmi dobrý přehled o tom, kudy data tečou. Můžou se pak vyhnout adresám, které jsou ve skutečnosti za tunely.
Typicky mají pod kontrolou DNS a pro určité adresní rozsahy nedávají uživatelům AAAA záznamy.
Jelikož je služba už vypnutá, musí uživatelé přejít k jinému tunnel brokerovi, kterých ale příliš mnoho není: Hurricane Electric, IPv6Now, 6project.org a NetAssist. Nemá příliš smysl nasazovat mechanismy jako 6to4 nebo Teredo.
Je také možné si zařídit vlastní tunel například pomocí SSH nebo OpenVPN. Mám už informace o tom, že se v Česku objeví služba, která nabídne veřejně tunely pomocí nešifrovaného OpenVPN.
Michal Táborský: nasazení IPv6 v Mall.cz
Mall.cz je síť obchodu, která má více než 15 milionů návštěvníků. Ty obsluhuje pomocí 800 serverů generujících přibližně gigabit provozu. Z více důvodů máme svůj autonomní systém s číslem 44424. Zejména proto, abychom mohli přecházet mezi různými poskytovateli připojení.
Firma má v současné době tři poskytovatele připojení.
K přechodu se Mall rozhodl někdy v roce 2015. Chtěli jsme být připraveni na budoucnost a zároveň být na špičce.
Podle úvodních testů to vypadalo, že přechod na šestku nebude žádný problém. Nejprve jsme si to vyzkoušeli na interní síti, která je oddělená od běžných uživatelů.
Poté bylo potřeba zažádat o vlastní IPv6 rozsah, dohodnout se s poskytovateli připojení a provést nastavení na úrovní sítě – routery, firewally, BGP a podobně. Všichni naši poskytovatelé na to byli vlastně připraveni, takže všechno šlo poměrně hladce. Paradoxně nám nejvíc času nezabrala síťařina, ale úprava interních systémů.
Zejména bylo potřeba upravit databázové struktury, úložiště a software. Máme poměrně hodně vlastního i cizího software, takže jsme toho museli předělat poměrně hodně.
Martin Táborský, Mall.cz
Další problém vznikl na hraničním zařízení, které zároveň slouží jako load balancer. To bohužel neumí IPv6, takže jsme ho vyměnili za linuxový server. Pokud neroutujete více než 10 gigabitů, nepotřebujete na to speciální krabici. Stačí běžný Linux a pár síťovek.
Podobný problém nastal u jednoho z poskytovatelů připojení, u něj stačilo přeložit linku jinou cestou.
Zkušenosti za rok a půl provozu jsou velmi pozitivní. Z hlediska sítě jsme překvapivě nenarazili na žádný vážný problém, potíže nastaly v monitoringu.
Firma má tři externí monitoringy, které si ale s IPv6 nerozumí. Ani jeden z nich si nevšiml, že se k nám den a půl nedá dostat po IPv6. Museli jsme si dopsat vlastní řešení.
IPv6 tvoří u Mall.cz přibližně 4,8 % provozu, Mall.sk má ale jen 0,8 %. Slovensko je asi země IPv6 nepolíbená, protože velká část provozu je tvořena roboty, takže ve skutečnosti je to prakticky nula.
Michal Táborský si také postěžoval na závěr na horší úspěšnost geolokace, pokud uživatel přichází po šestce.
Ondřej Caletka: BCOP aneb jak nejlépe IPv6 nasazovat
BCOP (Best Current Operational Practice) je skupina operátorů v rámci RIPE komunity, kteří se snaží dokumentovat nejlepší současnou praxi chování na síti. Vytvářejí velmi koncentrované, hutné a dobře čitelné dokumenty, které mají okolo deseti stran a přečtete je během slabé hodinky.
Neřeší budoucnost, zaměřují se výslovně na současný stav.
Tato skupina pracuje na dokumentu shrnujícím správné postupy při přidělování adres [PDF], zejména při připojování koncových zákazníků. Špatná rozhodnutí během plánování může přinést zásadní potíže v provozu. Například velmi bolestivé přeadresování za provozu.
Důležité je, že při adresování je potřeba myslet ve velkém a není důvod zbytečně šetřit.
Cílovou skupinou tohoto dokumentu jsou poskytovatelé připojení nebo malé podniky. Typicky mají zkušenosti s IPv4, ale žádné zkušenosti s IPv6.
Zmíněné přidělování adres nemá v IPv4 žádné obdoby, protože se typicky nepřiděluje celý prefix a pokud už ano, je konfigurovaný ručně a staticky.
Ondřej Caletka, CESNET
Přidělování IPv6 prefixu je potřeba plánovat tak, aby vystačilo pro všechny případné budoucí potřeby zákazníka. Je potřeba přidělovat tak, aby rozsah stačil navždy a přehnané šetření není na místě.
I kdybychom přidělovali každému nově narozenému člověku vlastní /48 rozsah, vydrží nám to 480 let.
První případ se týká přidělování adres na WAN rozhraní, tedy na spojovací linku k zákazníkovi. Jednou variantou je přidělení /64 pro spojovací linku z rozsahu, který je odlišný od rozsahu používaného u samotného zákazníka. V závislosti na hardware je možné vytvářet spojovací linky v menším adresním rozsahu, ale je lepší vyhradit v adresním plánu rovnou /64, protože v budoucnu můžete chtít používat levnější zařízení, které bude mít s delšími prefixy problém.
Přesně takový způsob adresování používá pro své členy síť CESNET.
Další možností je použití link-local adresy, kdy nebude WAN rozhraní vůbec adresováno veřejnými adresami, ale je možné využít přímo adresu rozhraní v rozsahu fe80::/64. Tohle je dobrý způsob, ale musíte si být jisti, že tam zákazník připojí router a ne rovnou koncové zařízení. Pokud to zajistíte, bude to fungovat velmi dobře.
Naopak je silně nedoporučováno využití unikátních lokálních adres, protože můžou nastat například problémy s generováním ICMP paketů nebo objevováním MTU cesty.
Poslední možností je přidělení /64 přímo z prefixu přiděleného zákazníkovi. To je nejčistší z hlediska síťové topologie a směrování. Jeden zákazník je schovaný v jednom prefixu.
DHCPv6 umožňuje podle RFC 6603 přidělit rozsah a vyjmout z něj část pro spojovací adresy. Musí to ovšem podporovat koncová zařízení, což v situaci, kdy si zákazníci sami nakupují koncová zařízení, může být problém.
Dokument řeší také velikost přiděleného prefixu, přičemž říká, že používání násobků čtyřech bitů je praktické, protože jej lze vyjádřit v dobře čitelném formátu a delegovat na jednu DNS zónu. Pravidla regionálních registrů dovolují přidělit až /48 na zákazníka.
Minimální příděl je /64, ale to podle dokumentu není dlouhodobě udržitelný a nedovolí další dělení sítě. Naprosté minimum je přidělení několika /64 bloků, ideální je ale souvislý blok typu /56.
Nejpraktičtější je přidělit /48 pro všechny, protože to vytváří dostatečný prostor i pro velké zákazníky. Málokdo je tak velký, že by mu nestačil takový rozsah. Výhodou pak je, že máte jednotné řešení, které padne všem vašim zákazníkům.
Pokud se stanete LIRem, dostanete alokaci /29 a v takové je přes půl milionu podsítí rozsahu /48. Pokud z nich obsadíte alespoň 170 tisíc, tedy třetinu, máte nárok na přidělení další sítě /29.
Pokud navíc předem dokážete, že chcete nasadit IPv6 na obrovskou síť, dostanete kratší prefix rovnou. Adresy prostě jsou. Navíc jsou stále za stejnou cenu, neplatí se podle velikosti rozsahu.
Sítě ale neřídí jen technici, ale i obchodníci. Ti se pak ptají, jak je možné přidělovat malým klientům stejné rozsahy jako velkým firmám. Proto se obvykle firmám přiděluje /48 a domácím zákazníkům jen /56. Dobrý nápad je vyhradit na klienta rovnou /48 a přidělit mu jen /56. Pokud pak vyroste nebo se plány změní, nebudete muset přeadresovávat.
Platí přitom, že kdo poskytuje připojení zákazníkům, musí mít adresy alokované. Typicky vstoupením do RIPE NCC a získáním rozsahu /32 až /29. Jednou přidělené adresy už není možné sdílet s dalšími poskytovateli. Existují některé sítě, které takto fungují ilegálně.
Pokud poskytovatel přiděluje adresy zákazníkům, musí se stát LIRem.
Matěj Grégr: na cestě za standardem
Problém RFC standardů je, že jeho vytvoření vyžaduje několik kroků, včetně rozšíření řešení do světa. Původně to bylo definováno v RFC 2026, zjednodušeno pak v RFC 6410. Dnes existuje celá řada RFC standardů ve stavu experimental, informational nebo BCP, které neprošly žádnou diskusí a nejsou globálně uznávány.
Skutečný standard je definován tak, že existují alespoň dvě nezávislé interoperující implementace, nesmí existovat žádná errata, standard nesmí obsahovat zbytečné funkce zvyšující komplexitu a musí být vypořádány patenty. Různá RFC se přitom postupně aktualizují a překlápí do dalších nových RFC. Jednodušší věci už jsou ve frontě a čekají na nové číslo, ale například u path MTU discovery už to začalo skřípat.
Velký problém pak nastal v RFC 2460, který se týká adresního prostoru IPv6. Původní standard používá klasickou angličtinu a nově se používá speciální zápis jako MUST. Klasické must si někdo vykládá tak, že se to vlastně nemusí, protože to není napsáno kapitálkami.
Do kompletního přepisu se nikomu nechtělo, ale nakonec se to podle Grégra nějak usadilo
.
Matěj Grégr, VUT
Další potíže se týkaly rozšířených hlaviček, u kterých platí, že se na ně po cestě sítí nesahá. Někteří si ale řekli, že vkládání a mazání do tohoto pravidla není zahrnuto.
Dnes je tam nový text, který výslovně zakazuje i tyto úpravy. Bylo kolem toho spousta křiku i nářků a některé operace bylo potřeba začít dělat jinak.
Tyto problémy byly postupně vyřešeny a čeká se na vydání nového internetového standardu.
Další krvavé boje
probíhaly okolo RFC 4291, které se týká segmentování rozsahu IPv6. Jsou tam například obrázky, které říkají, že adresa se dělí na prefix a identifikátor rozhraní.
V tomto RFC je ale zároveň napsáno, že identifikátor rozhraní musí mít 64 bitů. Z toho plyne, že sítě využívající delší prefix nejsou v souladu se standardem. Ony se ovšem v praxi používají.
Obě strany sporu si proto vytvořily vlastní RFC a způsobuje to velké hádky. Konsenzus bude velmi těžký, na jedné straně stojí operátoři a na druhé straně stojí Google.
Připravuje se aktualizace RFC 4861, jehož standardizace ještě nebyla zahájena a lze očekávat spory například z hlediska délky prefixu. Podobně na tom bude RFC 4862, kde se bude opakovat pravidelná bitva SLAAC vs. DHCP. Vidíme ji každého čtvrt roku bez jakéhokoliv výsledku.
Teď jsme tedy v situaci, kdy jsou standardizované dokumenty RFC 2460, 4443, 3596 a 1981. Pokud tohle projde, budou ty nejdůležitější mechanismy označeny za internet standard. Pak budeme moci přistoupit ke standardizaci dokumentů, které upravují přenos IPv6. To ale můžeme udělat, až bude hotový základ.
Standardizace tedy stále ještě probíhá a podle Grégra budou probíhat ještě léta. Lze očekávat například zmíněnou debatu SLAAC vs. DHCPv6, tam se nic nemění. Pokud jedna z variant převáží, možná se dočkáme nějaké celkové standardizace.
Vše bude záviset na tom, jaký konsenzus se najde a jak dlouho bude debata trvat.
Martin Huněk: implementace IPv6 v síti Freenet Liberec
Freenet Liberec je komunitní síť, která je udržovaná neziskovou organizací. Pomocí 58 AP pokrývá šest obcí v okolí Liberce a má přes 800 členů. Podle Martina Huňka vlastně IPv6 nikdo nechce, nedá se na ní vydělat a může být jen zdrojem problémů. Když se něco rozbije, začnou vám lidi volat.
Problém je stále podpora v zařízeních, která je nekonzistentní, žádná nebo špatná.
První problém, který vás u IPv6 zarazí, je u delegace prefixu. Žádný linuxový DHCPv6 server nedělá routing,
varoval Huněk. Server totiž sice umí přidělit klientům adresu, ale nezařadí ji do routovací tabulky. Síť se pak rozbije, klienti adresu dostanou, ale data netečou.
Další potíže nastávají s identifikací pomocí DUID, který sice identifikuje hosta bez ohledu na rozhraní, ale je ukryté někde v systému v nějakém stavu. Nenašel jsem lepší způsob, jak DUID zjistit, než ho odchytit na síti nebo ho vyčíst v logu.
Problém také je, že není vždy perzistentní, přestože to standard vynucuje. Viděl jsem zařízení, které si identifikátor generuje při každém spojení znovu.
Martin Huněk, Freenet Liberec
Stejně tak podpora v různých AP není ideální, ve Freenetu používají UBNT Airmax AC, kde je podpora velkou novinkou. Člověk by řekl, že když je výrobce mladší než první RFC o IPv6, bude podpora samozřejmostí. Není to tak.
Podobně za RA Guard se v řadě zařízení připlácí, jinde je IPv6 velmi málo testovaná. Některá zařízení také neodpovídají RFC 6204 a RIPE-554.
Ani zařízení Turris Omnia neumožňuje v průvodci Foris nastavit k IPv6 vůbec nic. IPv6 tam funguje, ale nebylo by dobré ve webovém rozhraní zobrazit alespoň to DUID? Nedělá to nikdo, přesto by to bylo fajn.
Proč tedy IPv6 vlastně chtít? Samozřejmě hlavně proto, abychom měli dost adres. Vyhneme se tím i instalaci CGN u poskytovatele.
Podle Huňka mezi další výhody patří jednodušší load balancing, menší routovací tabulky, funkční multicast a paradoxně také kratší cesty. Hurricane Electris nabízí pro IPv6 tranzit zadarmo, takže prakticky všechno jde pak přes ně. Nám to zkracuje cestu o dva hopy.
V současné době je v libereckém Freenetu podpora dual stacku, k routování se používá BIRD a členům se přiděluje staticky /56 a na požádání až /48. Adres máme /29, takže není problém jich přidělit i více. Nevyděláváme ani na IPv4 adresách, pokud člen zdůvodní jejich použití, dáme mu bez problému další.
Koncová zařízení jsou obvykle podle Martina Huňka na IPv6 připravena, občas se jen chovají nekonzistentně, pokud není v RA ohlašována autokonfigurace. U levnějších zařízení jsou velmi často chyby, které nikdo neřeší.
Podle Martina Huňka je v IPv6 rozhodně budoucnost. Stejně budete muset přejít.
Radek Zajíc: jak bude vypadat nasazení IPv6 v mobilních sítích
Radek Zajíc se zabýval tím, jakým směrem se vydávají mobilní operátoři ve světě. V mobilní síti chceme dát zákazníkům přístup IPv6, ale beze ztráty přístupu k IPv4 internetu.
Existují dvě usnesení vlády, která doporučují státním institucím přístup k IPv6. Pokud jim budete poskytovat připojení k internetu, budou po vás požadovat IPv6 konektivitu. Pokud ji nebudete poskytovat, můžete být vyřazeni z tendru.
Novou oblastí je také IoT, kam jde velké množství SIM karet a firmy na nich chtějí veřejné adresy. Pokud máte nápojové automaty a chcete k nim přistupovat, budete potřebovat IPv6. Pokud je operátor neumí nabídnout, vypadává z výběru.
Podle Radka Zajíce se to už stalo. Šlo přitom o hodně SIM karet.
Hlavní důvody jsou pro operátora tři: splnění podmínek tendrů, zamezení odchodu zákazníků a zpřístupnění stále rostoucího světa IPv6. To hlavní, co vás zajímá, jsou úspory. Operátoři rádi vidí úspory, protože mobilní byznys se dnes týká hlavně dat.
Uživatelé postupně přecházejí z pevného připojení na mobilní data a jsou schopni vygenerovat velké množství spojení. Tím se vytěžuje CGN a je potřeba nakoupit další zařízení a přidělit více IPv4 adres. Hrozí tu exponenciální růst nákladů nebo složitosti sítě.
Radek Zajíc, ShowMax
Pokud zákazníkům v tomto stavu nabídnete IPv6, potřebujete méně IPv4 adres, protože se provoz přelije do nové sítě. Sníží se tím zátěž CGN a dlouhodobě je tu tedy potenciál pro snížení nákladů.
Standardy se vyvíjí i v mobilních sítích, zatímco od roku 2000 bylo nutné navazovat dvě různé spojení, od roku 2008 je možné navázat dual stackové spojení. Podpora v zařízeních i u operátorů je velmi špatná, takže dual stack v tomto režimu to téměř nikdo nepodporuje.
Proto se postupně operátoři začali upínat k DNS64 a NAT64. To by mělo zpřístupnit většinu IPv4 světa i v situaci, kdy má zákazník na zařízení nastavenou jen IPv6 adresu.
V roce 2013 pak přišlo 464XLAT. Tohle je zřejmě cesta, kterou většina operátorů plánuje jít.
Problém je v tom, že do mobilních sítí je připojené obrovské množství různých zařízení, kde je různá podpora IPv6.
Největší problém IPv6-only sítě nastává v případě, že se služba snaží přímo připojit k IPv4 adrese. Samotné zařízení má totiž jen IPv6 adresu a aplikace vyžadující IPv4 se tedy nemá kam připojit a nebude fungovat. Díky 464XLAT je na straně zařízení speciální software, který emuluje IPv4 konektivitu. Když se například Skype pokusí přistoupit k IPv4 socketu, 464XLAT pakety vezme, přeloží do IPv6 a pošle na NAT64.
Tam se pakety opět přeloží do IPv4 a pošlou do internetu. Tím se připojí i IPv6-neschopné aplikace.
Podpora 464XLAT je dnes v Androidu od verze 4.4, iOS od 9, Windows Phone 10. Na straně operátora je situace obvykle také velmi dobrá, protože už teď má ve své síti CGN. Velmi často to zařízení umí NAT64 a velmi často umí i 464XLAT. To znamená velké úspory.
Například T-Mobile v USA má dnes IPv6 už u více než 80 % uživatelů.
Radek Zajíc ukázal funkční příklad na několik let starém telefonu Xperia, na kterém je Android 5.1. Probíhá tam několikanásobný překlad, ale z hlediska telefonu fungují oba protokoly zároveň.
Předvedl, že i na takto starém zařízení fungují oba protokoly a test-ipv6.cz ukázal 10 bodů z 10.
Starší zařízení zůstanou stále připojena jen pomocí IPv4, nové přístroje budou používat IPv6-only doplněné o 464XLAT. Podobně to bude i na mobilním hotspotu, buď bude IPv4-only nebo IPv6 s 464XLAT.
Korporátní APN budou pravděpodobně připojena také jen do IPv6 a přístup do IPv4 si budou muset firmy řešit vlastním NAT64 a DNS64.
V Česku je podle Radka Zajíce situace velmi špatná, protože se neděje téměř nic. V T-Mobile proběhl pilotní projekt, ale nedostal prioritu managementu. U O2 jsou podle Zajíce snahy nabízet IPv6 alespoň korporátním zákazníkům. Je potřeba edukovat management a vysvětlit výhody. Náklady na straně operátorů jsou velmi malé.
