Ondřej Caletka: Autokonfigurace IPv6 v lokální síti
První přednáška se zabývala vlastností, která je u IPv6 pravděpodobně nejodlišnější proti klasickému IPv4. Řeší to každý, kdo má nějaké zařízení. Jak se toto zařízení dozví, jak se má v dané síti chovat?
V IPv4 platí, že každé rozhraní má jednu adresu, která se původně konfigurovala ručně. Později se objevily protokoly pro automatickou konfiguraci: BOOTP a později z něj odvozený DHCP.
To je dnes naprosto běžný stav, prakticky každá síť nabízí automatickou konfiguraci pomocí DHCP. Součástí tohoto řešení je i protokol ARP, který řeší objevování sousedů. Je závislý na všesměrovém vysílání, což bylo to jediné, co bylo v té době k dispozici. Multicast se objevil až mnohem později.
DHCP má několik nevýhod: takzvané broadcast storms velmi zatěžují všechny uzly na síti a stavový DHCP server si musí pamatovat přidělování adres, přičemž lze získat jen jednu adresu. Adres je málo, takže je potřeba hlídat, kdo jakou adresu dostal a že získal jen jednu.
Princip DHCP zároveň porušuje vrstvový model, protože protokol aplikační vrstvy konfiguruje síťovou vrstvu.
V IPv6 jsou adresy výrazně delší a je možné je rozdělit na síťový prefix a identifikátor rozhraní. U síťové části existuje hlubší dělení na jednotlivé sítě různých velikostí od RIR přes LIR až po koncovou podsíť. Identifikátor rozhraní pak určuje konkrétní zařízení v podsíti a dnes jde o náhodně generované číslo, které bylo v minulosti odvozené z MAC adres. Koncová zařízení mají zakázáno předpokládat konkrétní délku prefixu a musí být schopna pracovat s libovolnou délkou.
Existují různé druhy IPv6 adres: loopback ::1/128, globální unikátní 2000::/3, linkové fe80::/10, unikátní lokální fc00::/7 a skupinové ff00::/8. IPv6 neobsahuje univerzální lokální adresy, které by byly použitelné v libovolné síti. Obchází se tím kolize rozsahů, které známe třeba při použití VPN v IPv4. Řeší se to tak, že součástí prefixu je 40 náhodných bitů.
U IPv6 je také běžné, že na rozhraní je více adres. Rozhraní zařízení schopného s IPv6 pracovat má dokonce automaticky přidělenou linkovou adresu bez ohledu na okolí. V IPv6 sítích tedy má rozhraní minimálně dvě adresy: linkovou a odvozenou z prefixu oznamovaného směrovačem. Šestka se také musí zabývat objevováním sousedů, používá k tomu protokol ICMPv6, jehož funkce vlastně odpovídá starému protokolu ARP. Hlavní rozdíl je v tom, že zatímco ARP používá broadcast a vysílá pro všechny, ale ICMPv6 zavádí multicastovou skupinu pro vyzývaný uzel.
Dotaz pak putuje jen do skupiny, do které se musí přihlásit zařízení s adresou se shodnými posledními 24 bity. Je to vymyšleno tak, aby byl ve skupině počet počítačů blízký jednomu, takže je to sice multicast, ale obvykle oslovujeme jen jeden cílový stroj.
Síť pak může dotazy k objevování sousedů doručovat jen těm počítačům, u kterých to dává smysl.
Při připojení zařízení do nové sítě se nejprve vytvoří linková adresa v rozsahu fe80::/10 a přihlásí se do multicastové skupiny pro vyzývaný uzel. Poté se zařízení zeptá, zda v síti stejnou adresu nemá jiné zařízení. Pokud takového souseda neobjeví, adresu si přidělí a poté se začne v síti ptát po směrovači. Lokální adresy se používají pro následnou servisní komunikaci, ale je možné je používat k libovolné komunikaci v rámci linky. Zároveň neprocházejí přes směrovač, takže zůstávají jen uvnitř místní sítě.
Směrovač na dotaz (router solicitation) odpoví oznámením směrovače (router advertisment), ve kterém oznámí svou adresu spojové vrstvy, životnost a preferencí. Kromě toho může přidat informace o prefixech, MTU, informace o DNS a podobně. Směrovač se nám pak přidá do směrovací tabulky, ve které se objeví nová výchozí brána. Je běžné, že v síti může být víc směrovačů, na koncovém uzlu pak je, aby zjišťoval jejich dostupnost a posílal data správným směrem.
Součástí oznámení pak může být také informace o tom, zda se mají IPv6 nastavovat podle místního DHCPv6 serveru.
Jakmile počítač ví, kudy má posílat IPv6 datagramy, je čas nakonfigurovat na rozhraních adresy. Variant je více a vzájemně se nevylučují. Výsledkem je ale vždy jen jedna IP adresa. Maska podsítě je nastavena z ohlášení směrovačů.
Existují dva hlavní způsoby získávání adresy: SLAAC je součástí ohlášení směrovače, k síťovému prefixu se připojí identifikátor rozhraní. Je to automatické a bezestavové, každé zařízení se nakonfiguruje samo.
Druhou rozšířenou variantou je DHCPv6, které je velmi podobné klasickému DHCP, ale nenastavuje se zde ani maska a brána. Slouží to opět jen ke získání IPv6 adres.
V síti musí existovat server, který si pamatuje stav a přiděluje adresy podle interních pravidel. Identifikace uzlů se provádí pomocí DUID, který platí pro celý počítač a je obvykle náhodně vygenerovaný při prvním startu systému.
Identifikátor rozhraní se vytváří jednou ze čtyř metod: je vázaný na adresu spojové vrstvy, náhodným číslem bez vztahu k HW, proměnlivé náhodné číslo podle RFC 4914. Nejnovější řešení přináší RFC 7217, kdy je na rozhraní přiděleno náhodné číslo, které je ale platné jen pro danou síť. V dané podsíti je adresa stabilní, v jiných sítích je zcela jiná.
Hlavní výhodou DHCPv6 je, že umožňuje používat krátké adresy. Zároveň jedině pomocí tohoto protokolu je možné od poskytovatele získat celý rozsah pro přidělování v podřízené síti. Nevýhodou naopak je problematická identifikace stanic a také to, že je takto přidělena jen jedna adresa. Jedna vám nestačí kvůli virtualizaci, přechodovým mechanizmům a tetheringu.
Z mobilního operátora obvykle nevyrazíte víc adres, takže je potřeba používat něco, čemu se říká pseudobridge nebo proxy NDP. Je to jediný způsob, jak připojit za jedno zařízení s IPv6 konektivitou víc zařízení.
Radek Zajíc: IPv6 v síti menšího operátora
Největší nárůst rozšíření IPv6 proběhl v roce 2014, kdy podporu zavedla Telefónica a T-Mobile. Od té doby se nestalo vlastně nic, pořád se pohybujeme okolo 10 %.
Podle Zajíce je to především tím, že se často IPv6 nasazuje špatně nebo někteří operátoři neví, odkud začít.
Když se poskytovatel rozhodne zavést IPv6, musí se zamyslet nad některými praktickými otázkami. Nejdřív je třeba začít nějakým plánem, udělat si přehled o stavu zařízení v síti.
Jak je na tom páteřní síť, přístupová síť, nasazení u koncových zákazníků, monitoring, přístup k reverznímu DNS a podobně.
Vyřešit je také potřeba, kolik adres bude zákazníkovi přiděleno a jak to uděláte, jak postavíte adresní plán, jak získáte konektivitu od nadřazeného ISP a jak to vše nakonfigurovat. Úplně nejlepší je pak povolit IPv6 pro všechny zákazníky, protože oni se vás sami nikdy nezeptají.
Kde získat IPv6 adresy? Jednou z možností je stát se členem RIPE NCC, tedy stát se LIR. Stojí to 2000 eur a poté 1800 eur každý rok. Za to dostanete IPv6 prefix, ještě stále 1024 adres a také číslo ASN, abyste byli schopni je ohlašovat do internetu. Adresy pak musíte spravovat v RIPE databázi, kde si můžete rozsah dělit na další bloky.
Další variantou je, že požádáte svého nadřazeného poskytovatele připojení. Ten vám ale obvykle přidělí blok /48, což je málo a je problém je pak dělit mezi vaše zákazníky. Velmi častou chybou je, že váš poskytovatel adresy v RIPE databázi nijak neoznačí nebo je označí chybně jako blok adres pro koncové zákazníky. Vy je pak ale nesmíte dále přidělovat.
Pokud adresy máte, je na vás, abyste vytvořili adresní plán, který by měl být tvořen agregovatelnými hierarchiemi . Nešetřete adresami, není k tomu důvod. Naopak byste měli vytvořit prostor k dalšímu růstu, abyste mohli zákazníkům zvětšovat rozsah, pokud o něj požádají.
U konektivity dnes už problém prakticky není, dnes je schopen každý nadřazený poskytovatel nabídnout připojení i po IPv6. U páteřní a agregační sítě budete muset ověřit, že všechny prvky podporují potřebné technologie: BGP4+, OSPFv3, DHCPv6 a podobně. Musíte si také být jisti, že vaše technologie je schopna zpracovat IPv6 v hardware, abyste nezjistili, že vám IPv4 funguje rychle a IPv6 uroutuje jen 50 megabitů.
Přístupová síť by pak měla řešit first-hop-security, tedy aby se zákazníci nemohli ovlivňovat. Mohli by na sebe přesměrovat všechen provoz, posílat vlastní ohlášení směrovače a podobně.
Šestku je pak možné nasadit dvěma způsoby: do sítě nasadit IPv6 a IPv4 pak nasadit jako službu přístupové sítě. V síti je pak jen IPv6 a původní IPv4 se tuneluje. Mechanismů je celá řada, například DSLite nebo 464XLAT.
Koncová zákaznická přípojka by pak měla mít přiděleno nejméně /56, aby mohl síť dělit na další podsítě. Existuje spousta důvodů jako virtualizace nebo další zákaznický router. Vzhledem k tomu, že těch adres máte dost, nedává smysl přidělovat méně.
Adresy je možné konfigurovat staticky, nebo lépe pomocí DHCPv6, které vám dovolí také delegovat prefixy.
Nejhorší částí jsou klientské jednotky, protože různá zařízení podporují různou sadu vlastností. Třeba MikroTik umí fungovat v režimu klienta velmi dobře, ale pokud použijete Ubiquiti, je to výrazně horší.
Je potřeba také zajistit filtrování provozu, aby nebyli klienti posílat RA, odpovědi DHCPv6 serverů nebo provoz z cizích prefixů. Tohle všechno prostě zahoďte, tohle nemá klient vůbec posílat.
Ladislav Růžička: IPv6 na MikroTiku
Podle Ladislava Růžičky je podpora IPv6 v MikroTiku velmi dobrá. Ve výchozím stavu je ale podpora vypnutá a je potřeba ji zapnout. To znamená restartování routeru, což nikdo nebude dělat v deset dopoledne. Je potřeba se na to trochu připravit.
V první fázi je potřeba získat spojovací IPv6 adresu, obvykle se přiděluje v rozsahu /126. Ta se nastaví na rozhraní a poté je potřeba nastavit routování. U malých poskytovatelů je běžné, že nastaví staticky jednu výchozí routu. U větších je potřeba zapnout podporu BGP, která je úplně stejná jako u IPv4.
V tu chvíli máme v síti zapnutou IPv6 konektivitu a je potřeba si vytvořit vnitřní síť.
Nejdůležitější je připravit dobrý adresní plán. To vám zabere víc času než samotné nastavení routerů. Pokud to neuděláte pořádně, budete to několikrát předělávat.
Můžete například na panelový dům vyhradit /48 a na jednotlivého zákazníka pak /56. Podle tohoto plánu se pak nastaví DHCPv6 server, který už v dané VLAN začne přidělovat adresy. To je všechno, víc toho reálně nastavovat nebudete.
U klientského zařízení je pak potřeba opět zapnout balíček IPv6 a nastavit, na kterém rozhraní mají být přijímány prefixy. U klienta od MikroTiku můžeme nastavit další předávání prefixu, typicky v rozsahu /60. Vznikne tak prefix delegace za vaší prefix delegací.
Poté přidělíme adresu na vnitřní rozhraní a necháme oznamovat svůj směrovač.
V tu chvíli je už možné klienta připojit a vše začne fungovat. V záznamech DHCPv6 adres jsou pak vidět přiřazení adres včetně DUID jednotlivých zařízení. Nám se zařízení ohlásí a dostane IPv6 prefix, ale my jej pak musíme přepnout na statický záznam.
Aby bylo možné za domácí router připojit další router, musíme i na tom prvním spustit DHCPv6 server. Jinak další zařízení sice získá klientskou IPv6 adresu, ale už mu nebude přidělen prefix pro další síť.
Jan Vondráček: Nasazení IPv6 v eduroamu UPCE
Univerzita Pardubice začala nasazovat IPv6 ve chvíli, kdy bylo potřeba obnovit DHCP server pro eduroam. Neděláme rozdíl mezi drátovou a bezdrátovou sítí, takže když k nám přijedete na návštěvu, normálně se připojíte a přihlásíte svou eduroam identitou.
Hlavním důvodem byla terminace PAT, která znemožnila dohledávání incidentů. Zároveň je to zajímavá nová věc a my jsme si ji chtěli vyzkoušet. Řada věcí je tam jinak.
V přípravné fázi byla nejzásadnější debata týkající se rozdělování adres. Přidělujte adresy pro šestku úplně nově, nesnažte se kopírovat rozdělení z IPv4. Nebude to fungovat.
DHCP server pro běžné použití není potřeba, ale síťaři chtěli, aby byla oznamována i šestková adresa DNS serveru. Rozhodli jsme se vypnout autokonfiguraci a přidělovat adresy pomocí DHCPv6.
Poté bylo ještě potřeba nastavit RA guard kvůli ochraně uživatelů. Tím skončila přípravná fáze a bylo možné začít s nasazováním.
Všechny zásuvky v síti jsou autorizované, takže v případě incidentu je možné dohledat konkrétního uživatele. Nepotřebujeme vědět, jakou adresu má klient přidělenou, ale kterou kdy používal.
Stačí získávat ze SNMP tabulku sousedů z routeru. Životnost této tabulky je čtyři hodiny, stačí tedy logovat třeba jednou za hodinu. Tím je možné logovat párování MAC adres a přidělených IPv6 adres.
IPv6 podle Vondráčka jednoduše funguje, je možné ho bez problému plnohodnotně nasadit vedle IPv4. Nemáme zatím žádné IPv6 incidenty, máme ale vyzkoušeno, že je budeme schopni dohledat.
Martin Vicián: IPv6-only v interní infrastruktuře
IPv6-only infrastruktura je taková, kde na koncových zařízeních vůbec není IPv4 konektivita. V nějakém bodě budete muset čtyřku řešit, protože většina vašich zákazníků ještě šestku nemá, ale uvnitř sítě si můžete dělat, co chcete.
Obvykle se pak přechodový mechanismus nasazuje do sítě samotné a klienti o něm nemají tušení.
Velkou výhodou je, že odpadají problémy s IPv4: nepotřebujete NAT, přestávají kolidovat síťové rozsahy, interní služby nezávisí na zákaznících a jde o výborné edukační prostředí. Jelikož nemáme dual-stack, nemusíme udržovat dvě různé sítě.
Nevýhodou je stále ještě problematické použití některých služeb.
Zkušenosti v síti CZ.NIC jsou velmi dobré, vše nativní funguje: web, SSH, databáze, certifikáty od Lets Encrypt, monitoring a podobně. Nefungují repozitáře třetích stran, GitHub, stahování obsahu z některých serverů a například také oblíbený ping na čtyři osmičky.
V kancelářích je také možné IPv4 vypnout, ale bez přechodových mechanismů si ještě neporadíme, protože některé populární služby šestku nemají. Situace se ale zlepšuje, proti situaci před dvěma lety byla situace napravena u Spotify, Skype i WhatsApp. Pozor si musí dát vývojáři, kterým nebude fungovat například NAT ve VirtualBoxu, jinak funguje loopback a podobně.
Stále jsme ještě u IPv6-only sítě závislí na přechodových mechanismech jako NAT64/DNS64 nebo 464XLAT. DNS64 syntetizuje šestkové záznamy pro domény, které mají jen čtyřkový záznam. Poté se NAT64 postará o překlad komunikace s touto adresou přes IPv4.
Problém ale nastane v souvislosti s DNSSEC, protože syntentizované AAAA záznamy nejsou podepsané a jsou vyhodnoceny jako nevalidní. Díky mnoha podepsaným zónám v .CZ narazíte asi u třetiny domén.
Michal Žejdl: IPv6 v Sokolovské uhelné
Původně se v Sokolovské uhelné používal od roku 2009 tunel od SixXS, který ale využíval PoP ve slovinském Mariboru. Proto se o několik let později správci rozhodli oslovit své poskytovatele a po prvotních potížích se jim podařilo získat „negarantované“ připojení k IPv6. Nyní je společnost LIR, má vlastní rozsah a přiděluje je sama svým zákazníkům.
Z počátku se také používala autokonfigurace, což ale kvůli privacy extensions nedělalo dobrotu. Pokoušel jsem se na Windows vypnout privacy extensions, ale nikdy to nebylo stoprocentní a nevydrželo to dlouho.
Proto se správci nakonec rozhodli autokonfiguraci vypnout a nasadit DHCPv6.
Někteří klienti ovšem v tomhle stavu dělají problémy s tím, že neustále posílají renew. Klidně i stokrát za sekundu, netuším, proč se to děje. Takovým klientům musíme šestku vypnout.
Nejdříve to dělaly jen levné tiskárny HP, ale později se přidaly různé UPS, kamery, převodníky a další zařízení. Pozor je potřeba dát si na jednoduché klonování stanic s Windows, kdy se nezmění DUID. Funguje to, ale v logu je pak vidět, jak se ty stanice pak nemají rády.
Pro provoz sítě se používá open-source software: Linux jako router, ISC DHCP, Quagga pro BGP, OSPF i RA. Stává se nám, že jednou za pár měsíců spadne a nevypořádá se s chybou netlinku, kdy po startu nenabere všechny routy.
Správci proto zkouší BIRD, který nepadá a chová se celkově lépe, ale má jiné ovládání.
Pro automatickou evidenci adres a SNMP zařízení se v síti používá vlastní software nana, který usnadňuje každodenní práci nejen správcům sítě. Vstupem je pouze sonda, která chytá ARP a ND. Výstupem je pak prohledávatelná tabulka, ve které je zaznamenán současný stav celé sítě. Z posbíraných dat nyní plyne, že 70 % provozu směřujícího přes proxy ze sítě probíhá po IPv6.
Matěj Grégr: Standardizace IPv6 v IETF
Proč vlastně vytvářet standard pro IPv6, když už teď máme RFC? Ne všechna RFC jsou si rovna, některá jsou si rovnější.
Pokud je něco prohlášeno za internet standard, je to záruka, že je věc stabilní, vyzkoušená a nebude se už měnit.
Původní idea byla za internet standard prohlásit RFC dokumenty popisující základy protokolu IPv6 a některé navazující protokoly. Podařilo se to zatím se čtyřmi dokumenty: RFC 8200, 4443, 3596 a 8201. V minulém roce bylo rozpracováno ještě RFC 4291, ale tam to zatím nedospělo ke konsenzu.
Hlavní problém byl v rozdělení IPv6 adresy na prefix a identifikaci rozhraní, které je v RFC definováno na hranici 64 bitů. V praxi se to tak ale nepoužívá a existují dva nesmiřitelné tábory, které prosazují volnější variantu nebo naopak tu původní.
Například RFC 7217 obecně definuje identifikátor rozhraní pro SLAAC, ale není pevně nastaven počet generovaných bitů a je tak možné klidně generovat adresu rozhraní pro prefix delší než /64. Lidé z Google to nemají rádi, takže Android to určitě umět nebude. Naopak OpenBSD s tím nemá problém. Je to ale důvodem velkých sporů.
Novým standardem je RFC 8319, které upravuje maximální timeouty pro ohlašování routeru. Původní hodnoty se ukázaly jako velmi nevhodné například na Wi-Fi sítích. Snaha je posílat multicastové zprávy co nejméně. Neznamená to ale, že se nám něco dramaticky mění. Spíš nám teď standard dovoluje si časy ve své síti prodloužit.
Za RFC 8273 stojí Comcast, který každému klientovi posílá unikátní prefix. Pokud máte standardní síť, je RA doručována na všechna zařízení a ta si z něj vygenerují svou adresu. Comcast ale posílá odpovědi jen na linkovou adresu dotazujícího se zařízení a je tak možné každému zařízení poslat jednoznačný 64bitový prefix. Umožňuje to jednoznačně identifikovat klienta a také je od sebe oddělit na L2.
V připravovaném RFC 8305 se definuje nová verze standardu happy eyeballs, který klientovi dovoluje poslat na začátku komunikace zároveň dotaz na IPv4 i IPv6 a poté preferovat kvalitnější variantu. Jde spíš o nějakou aktualizaci, takže nás to nemusí příliš trápit.
Vývoj v tomto směru se zatím zastavil. Zatím není konsenzus, podařilo se dosáhnout marketingového prohlášení, že už jde o internetový standard a zbytek nikoho nezajímá. Podle mě to tak zůstane.
Tomáš Podermański: Čtvrtstoletí alternativ k IPv4
Ve většině síťových technologií se odrážejí stejná teoretická východiska:. Tím nejznámějším je hierarchické adresování, ale důležitá je i topologická nezávislost, která umožňuje různě řetězit body za sebe a stále to bude fungovat. Šestka to řeší velmi omezeně, ve čtyřce nám to řeší ty zpropadené NATy.
Dále je to end-to-end communication, což je vytvoření komunikačního kanálu mezi dvěma uzly s inicializací kterékoliv ze stran. Princip end-to-end argument zase říká, že síť by měla být co nejjednodušší a složité věci mají být implementovány v koncových zařízeních.
Pak jsou tu ještě praktické problémy, jako omezený adresní prostor nebo kompatibilita protokolů. Tohle je podle mě největší chyba, která se při přechodu na IPv6 udělala. Nepředpokládali, že to bude tak složité, proto jsme nezajistili kompatibilitu.
Podcenění tohoto principu má nepříjemné důsledky v tom, že sice dnes máme 20 % IPv6 konektivity, ale stále 100 % IPv4. Pořád tedy nemůžeme IPv4 vypnout. Kdyby byly oba protokoly kompatibilní, oba grafy by se sbližovaly a časem by se to překlopilo.
Už v roce 1992 Van Jacobson upozorňoval na to, že přechod na nový protokol by byl velmi komplikovaný. Uvědomil si to už v té době, kdy byl internet ještě relativně malý. Navrhl protokol LNAT, kdy by internet byl rozdělen na různé podsítě a mezi nimi by se provoz překládal.
V počátečních návrzích se ale s kompatibilitou nepočítalo, takže byly navrženy nové protokoly bez ohledu na původní protokoly. Kdyby se dneska ti lidé mohli vrátit do minulosti, jistě by se na to dnes dívali jinak.
Vznikly ale i kompatibilní návrhy jako EIP v RFC 1385, protokol LISP a mechanismus IPV4+4. Vychází z toho, že jednotlivé segmenty jsou běžné IPv4 sítě, mezi kterými jsou NATy. Ty přehazují pakety tak, aby měly v dané části sítě správné adresy.
Kromě toho vznikla ještě celá spousta dnes neznámých návrhů, které byly vlastně jen odprezentovány na konferenci a pak se na ně zapomnělo: RINA, IPNL a další.
Úplně jiný přístup pak zvolil protokol IPv10, jehož návrh se objevil v roce 2017. Když se na ten dokument podíváte, je to blábol. Nedává to příliš smysl. Vyvolalo to velkou diskusi na téma, co jsme všechno v IPv6 udělali špatně.
Často se objevují názory, že IPv6 vlastně nebylo možné vymyslet lépe. My jsme chtěli ukázat, že by to lépe šlo. Proto jsme vymysleli IP45.
V protokolu IP45 se adresy skládají z veřejné části doplněné o relevantní část adresy identifikující koncové zařízení v síti za NATem. Adresa se vám tak vlastně nafoukne o identifikátor zařízení.
Na začátku IP45 hlavičky je standardní IPv4 hlavička, poté je tam UDP datagram a následuje IP45 stack, kde jsou informace o zdrojové a cílové adrese. Adresa se tedy postupně nafukuje, jak paket putuje sítí a poté se z něj zase části odebírají.
Výhodou je, že celou tuto operaci je možné implementovat na zhruba deseti řádcích v IPtables.
Výhodou je, že klienti mohou být klidně za deseti NATy, jen servery musí být za NATem a zároveň BGW. Na klienty nemusíme sahat, ale na serverech se nám výrazně nafoukne adresní prostor. Když pak koncová zařízení budou IP45 podporovat, nic se neděje, budou adresy forwardovat i uvnitř své sítě a přechod bude hladký.
V současné době je připravený koncept a hotová implementace. V operačním systému je podpora hostů pro BSD, Linux, macOS a Windows. Zároveň existuje BGW jako modul do IPtables. Existují i patche pro utility jako tcpdump a Wireshak.
Vše je k dispozici na IP45.org včetně předkompilovaných balíčků. V současné době projekt spí, nikdo z velkých výrobců síťových zařízení ho nepodporuje.
Radek Zajíc: Jak bude vypadat domácí síť v roce 2025
Růst IPv6 podle Zajíce od roku 2012 nezastavuje, v některých státech to jde lépe než jinde, někde to tlačí například úřady. Belgie dosáhla 50 % za pět let, Spojené státy se za šest let dostaly na 40 % a rekordmanem je Indie, která za rok poskočila na 33 %. Při téhle rychlosti můžeme mít za šest let klidně 60% pokrytí.
Dobře se přechod daří v mobilních sítích, které na IPv6 konektivitu přecházejí docela dobře. IPv4 používají jaku službu, která zajišťuje konektivitu do starého internetu.
Myšlenka udělat z IPv4 službu je dobrá a je to zřejmě správná cesta vpřed. Je to i řešení pro domácí sítě, jak ukazuje třeba český operátor UPC.
Výhodou je, že při budoucím vypnutím bude možné prostě vypnout jednu službu bez složitého zásahu do infrastruktury.
V domácnosti je nyní možné dual-stack vypnout a používat jen IPv6. Za předpokladu, že to router umí a operátor nám nabídne kratší prefix než /64, je možné nakonfigurovat DNS64 a NAT64.
Otázkou je, jestli se některá služba v praxi rozbije.
Například zařízení od Apple disponují funkcí, která umožňuje na úrovni systémových knihoven přeložit komunikaci do IPv6. Umí to i Windows 10, ale z nějakého důvodu to umí jen pro mobilní sítě.
Aplikace se pak o připojení sama nezajímá a systém dokáže data správně odesílat i po IPv6-only síti. Všechno se pak bude zdát funkční.
Výjimkou jsou zařízení, která nepodporují IPv6 vůbec. Řekli byste si, že v roce 2018 taková situace nebude běžná, ale i dnes se s takovými přístroji setkáte.
Typicky jde o různou připojitelnou spotřební elektroniku: televize, kávovary, ledničky a podobně. Dokud taková zařízení budou existovat, nemůžeme se bez IPv4 obejít.
Podobně jsou na tom dnešní IoT přístroje, všechny bastlířské desky jako ESP8266 a podobně. Stejně tak existuje spousta špatně napsaných aplikací, které vám na IPv6-only sítích fungovat nebudou.
Co s tím? První variantou je ponechat v síti dual-stack, který byl původně myšlen jen jako přechodová varianta. Nebo je možné síť rozdělit na několik segmentů, kde různá zařízení oddělíte. Zhorší vám to ale uživatelský komfort, protože když budete mít telefon v moderní síti a televizi v jiné, přestane vám fungovat streamování videa.
Dobrou variantou je určitě hlasování peněženkou, ale je to dobré řešení jen pro geeky, kteří se umí v problematice zorientovat, zjistit si technické podrobnosti a vybere si zařízení schopné fungovat i za sedm let v IPv6-only síti. Dokud budeme mít zařízení, která IPv6 neumí úplně dobře, tak se čtyřce v síti nevyhneme. Podle mě budeme čtyřku v sítích ještě pořád mít.
Tomáš Podermański: Chyby geolokace IP adres a jejich řešení
Jak poznáte, že máte problémy s geokolací IP? Jednoho dne na vás třeba Google začne mluvit německy, rusky nebo rumunsky. Pokud jste ISP, tak jste možná začali používat IP adresy, které jsou špatně umístěné.
Pro koncového uživatele to může být problém: přestanou hrát některá videa na YouTube, v softwarových obchodech není možné koupit některé aplikace, nehrají pořady na webu ČT a podobně.
Řešení je velmi složité, neexistuje jednotný systém geokolace IP adres. Existuje spousta databází, jsou v nich různě čerstvá data a některé služby si sbírají a udržují vlastní data.
Doba řešení se pohybuje mezi jedním měsícem a rokem.
Šikovná je stránka IPlocation.net, která projde nejpopulárnější databáze a zobrazí podle nich geolokaci. V první řadě je pak dobré si dát do pořádku informace v RIPE databázi. Mohou tam být i GPS souřadnice, ale nemám pocit, že by to nějak zvlášť pomáhalo.
S opravováním je pak nutné obejít různé provozovatele databázi a u všech požádat o změnu. Formulář je možné dohledat také například na Google. Oni vám napíšou, že to zpracují a ať nečekáte odpověď. Podle mých zkušeností to ale vůbec nic nedělá. Nemá to žádný vliv.
Pokud jste dodatečně houževnatí, můžete založit ticket a nenechat se odbýt při jeho řešení.
Naopak vekou pochvalu si zaslouží Česká televize, která má pod každým videem tlačítko Pomoc, které otevře formulář s žádostí o pomoc. Tohle funguje skvěle, většinou dostanete odpověď do deseti patnácti minut a adresy jsou funkční.
Všechny tyhle problémy se týkají IPv4, v IPv6 je situace úplně jiná. Problémy tam žádné nejsou, protože platí, že kdo je závislý na geolokaci, ten vůbec službu na IPv6 neprovozuje.
Principy jsou v zásadě stejné, takže budou stejné i případné problémy.
Ondřej Caletka: RIPE IPv6 update
RIPE je otevřené fórum zájemců o rozvoj internetových sítí, bez formálního členství. Tato organizace také vytváří pravidla pro přidělování IP adres v daném regionu. Ta jsou pak uplatňována pomocí asociace RIPE NCC.
Dne 14. září 2012 byl otevřen poslední blok 185.0.0.0/8, 20. května 2014 se začaly přerozdělovat bloky vrácených do IANA. Objevili se ale chytráci, kteří si začali hromadně registrovat nové LIRy a získávat spoustu adres z posledních bloků.
Proto byla 23. července 2015 zavedena dvouletá čekací lhůta na převedení adres mezi LIRy.
Poslední blok byl už vyčerpán, ale ještě nejsme stále na suchu, protože se čerpají vrácené bloky. Zbývá nám tedy asi 8,6 milionu adres. Tempo čerpání je přibližně konstantní (přibližně 7000 adres denně). Extrapolace slibuje něco přes tři roky do úplného vyčerpání. Pak budeme ve stejné situaci, jako byl severoamerický registr už v roce 2015.
Pak už opravdu nebude možné v Evropě přidělovat další IPv4 adresy.
Vzdělávací oddělení RIPE NCC nabízí svým LIRům různá školení včetně IPv6 tréninků.
Radek Zajíc: Jak IPv6 nenasazovat
Přednáška se věnovala tomu, z čeho by si implementátoři neměli brát příklad. Příkladem je například komunikace s O2, která byla už mnohokrát upozorněna na to, že by měla dávat více adres než /56. V zásadě napsali: trhněte si nohou. Na firemní konektivitu dávají kratší prefix. Když jsme do kanceláře chtěli /48, tak nám napsali, že si za každý rozsah musíme připlatit 120 korun měsíčně.
Poskytovatel Poda sice dává větší rozsah, ale není možné dále delegovat část prefixu. Odpovídají, že je potřeba použít nějakou variantu NAT66. Proč, když se to dá dělat jinak?
Další chybou je dynamicky přidělovaný prefix, který se vám může kdykoliv změnit.
Nordic Telecon má nové licence na stavbu úplně nové mobilní sítě. Tahle firma se rozhodla, že postaví úplně novou síť čistě na čtyřce a někdy v budoucnu se budou šestkou zabývat.
Ani 406 milionů korun do licencí je nepřesvědčilo, aby síť postavili pořádně.
Nenuťte své uživatele používat problematické zařízení, třeba tím, že zakážete režim bridge. Někteří operátoři vám dodají router, který nemá všechny funkce a vy nemůžete použít své zařízení.
Stejně tak je problematické filtrování všech příchozích spojení. Principem internetu je posílání paketů mezi různými zařízeními. Zablokováním provozu protokolu jen uškodíte.
