Hlavní navigace

Ochrana infrastruktury před DDoS útoky a další témata z CSNOG 2019

Autor: Roman Prachař
Petr Krčmář

V Brně proběhlo druhé setkání komunity provozovatelů sítí, CSNOG. Tématem druhého dne byly především různé typy útoků na síťovou infrastrukturu, DNS servery a další prvky a hlavně způsoby jejich obrany.

Doba čtení: 18 minut

Sdílet

Radim Roška: Technické zajímavosti z implementace MPLS VPN a multicast VPN

Radim Roška na své přednášce hovořil o projektu ŘSD, jehož cílem bylo propojit 30 bodů kopírujících silnice a dálnice. Používají se například pro kamerové systémy, které jsou velmi důležité například při řešení dopravních nehod. Kvůli tomu musí být zajištěna vysoká spolehlivost.

Síť měla být realizována pomocí MPLS, součástí měl být multicast a na některých částech sítě také šifrování na L2. Původně měla být síť postavena na poměrně drahých routerech, nakonec ale stačil pokročilejší switch a byl zvolen Huawei S5720-HI. Má dostatečně velké tabulky a hodně 10GE portů.

Propojení bylo realizováno pomocí MPLS, použita byla jen jedna oblast OSPF a použit byl BFD. To je protokol, který umožňuje velmi rychle zjistit, že některý uzel nežije. Nad tím vším běží MP-BGP s route reflektory (RR). Pro multicast byl použit PIM SM.

Nad touto sítí pak byly na základě požadavků nasazeny tradiční L3VPN postavené na MPLS, L2VPN pomocí BGP AD VPLS a dynamický routing pomocí VFR OSPF. Některé části byly složitější, takže jsme potřebovali zavést dynamický routing.

Jiří Knapek: Adaptive mitigation of DDoS attacks using BGP Flowspec

O Flowspec se hodně mluví a začíná se hodně používat, ale řada správců o něm ještě neslyšela. Můžeme se s jeho pomocí bránit útoku, ale použít jej i ke sběru informací o útoku měnícím se v čase. Využít jej můžeme nejen na obranu proti DDoS, ale i proti dalším

Flowspec je vlastně rozšířením protokolu BGP a definují ho RFC 5575 a 7674. Umožňuje distribuovat firewallová pravidla. Podporuje klasické firewallové položky jako zdrojová a cílová adresa, IP protokol, zdrojový a cílový port, typ a kód ICMP, TCP flagy, délka paketů a podobně. Různí výrobci jsou v podpoře různě daleko, ale jde v každém případě o čistě softwarovou záležitost. Čím novější verze software je nasazena, tím větší je šance, že bude podporovat nejnovější vlastnosti. Podpora je také součástí routovacího démona BIRD 2.0.

Výhodou je chirurgická přesnost, kdy se zásahem do provozu nemusí omezit běžný provoz. Nemusíme vůbec měnit globální routovací tabulky, abychom ovlivnili svůj provoz. Provoz může být směrován na konkrétní IP adresu nebo poslat do VRF.

Při boji s DDoS je důležité mít dostatečná data o tom, co se v síti děje. K tomu je nutné získávat data z Flow exportu a při tom je potřeba používat dostatečně krátké časy pro získávání dat. V provozu se data ukládají ve směrovači jen do cache a průběžně se aktualizují. My si pak pomocí timerů pravidelně vynucujeme export těchto dat do collectoru. Čím častěji, tím lépe, ale musíme dát pozor, aby nám to příliš nezatížilo směrovač.

Pokud v datech objevíme útok, vznikne signatura útoku a na jejím základě se pak přidá pomocí BGP Flowspec do firewallu pravidlo a útok je zablokován. Pravidelně pak přepočítáváme statistiky a podle nich měníme pravidla. Záleží na tom, jak často potřebujeme pravidla upravovat, můžeme to dělat každou minutu nebo třeba po pěti minutách.

Pokud je útok příliš silný, je možné pomocí Flowspec informovat i směrovače nadřazeného poskytovatele připojení a ten pak může provoz filtrovat už u sebe. Můžeme krásně použít stejnou logiku a nástroje pro filtraci provozu ještě před naší sítí.

Champika Wijayatunga: Handling Abuse and Misuse in the DNS

V ekosystému DNS je spousta různých entit v různých vztazích: držitelé domén, registrátory, registry, DNS servery a další. Úloha ICANN spočívá především v koordinaci internetových identifikačních údajů. Máme smlouvy s některými z těchto entit, zejména asi s tisícovkou registrů gTLD. Ti zase mají své smlouvy s registrátory, ti zase s různými prodejci a ti na konci s držiteli domén.

ICANN se potýká také porušením těchto smluv při zneužití domén ke zlomyslným účelům. Doména může být k tomuto účelu rovnou zaregistrována nebo může být unesena legitimnímu držiteli. Registrace domény je automatizovaná a komunikace probíhá obvykle pomocí e-mailu. Je to snadné, což je dobré pro běžné uživatele, ale špatné z hlediska zneužití útočníky.

DNS dnes ohrožují zejména útoky odražené přes otevřené rekurzory či otrávení keše. CZ.NIC v tomhle hodně pomohl, protože se intenzivně zabývá rozšiřováním DNSSEC a připravil řadu různých nástrojů. DNS může být ovšem zneužit také přímo například k šíření informací o řídicích serverech pro botnety. Ohrožen může být ale i přímo klient, protože mu malware může změnit jeho rekurzivní DNS server a přesměrovávat mu pak provoz určený pro vybrané domény.

Při oznámení zneužité domény je zásadní nejprve posbírat co nejvíce informací. To můžeme udělat jak v samotné doméně, tak i v dalších databázích jako WHOIS. Z hlediska registrátora je zásadní udržovat v databázi přesná data. Kvůli GDPR je dnes velká část položek z databáze skryta. V budoucnu bude pravděpodobně WHOIS nahrazen nějakým jiným protokolem, například DAP.

Je důležité získat důkazy o zneužití domény jako jsou IP adresy, geokolační údaje, podrobnosti o registrátorovi. Poté je potřeba kontaktovat hosting nebo službu pro oznámení zneužití u daného registrátora. Pokud to nepomůže, je čas kontaktovat přímo registr.

ICANN nabízí vlatní nástroj DAAR (Domain Abuse Activity Reporting system), který umožňuje hlásit zneužití napříč různými registrátory a registry. Dovoluje se podívat do databází všech gTLD registrů, propojit je s reputačními daty a historickými záznamy.

Josef Verich: Potlačení nežádoucího provozu pomocí BGP Flowspec

CESNET se rozhodl ve své síti pro blokaci nežádoucího provozu nasadit Flowspec a zároveň chtěl data z něj předat také správcům a například lidem z bezpečnostního týmu CESNET-CERTS. Informace o provozu jsou sbírány v sondách na hraně sítě, agregovány a podle nich jsou vytvářena blokovací pravidla pro DDoS Protector. Ovládání je možné pomocí webového rozhraní nebo pomocí API. Kromě pravidel pro Flowspec je možné nasadit i RTBH. Flowspec vyžaduje nějaké prostředky, někdy je vhodnější nasadit blackholing.

Rozhraní je určeno také pro správce v připojených organizacích. V případě pravidel pro větší síťový rozsah, do kterého daná organizace také spadá, správce příslušná pravidla vidí, ale nemůže je upravovat. Může ale sám ve svém rozsahu zavádět pravidla, přičemž u RTBH stačí rozsah IP adres, u Flowspec je potřeba zadat také cílovou IP adresu v rozsahu organizace. Nemůže například zadat cílovou IP jiné připojené organizace.

Ne všechny routery umí všechny funkce Flowspec, například routery Nokia umožňují momentálně pouze kombinaci délka paketu a discard. Pokud použijeme délku paketu, umíme provoz jen zahodit. Cisco umožňuje také omezení provozu. Je potřeba také vědět, že fragmenty mají zdrojový a cílový port nastavený 0. Když to nevím, můžu omezit jen začátek toku, ale fragmenty budou procházet a útok pokračuje.

Řešení se používá nejen ve směru dovnitř, ale hlídá také provoz ze sítí. Máme hodně klientů, mezi nimi je řada studentů a dějí se různé věci. Univerzitní sítě jsou velké, mají rozsahy /16 a velmi rychlé připojení. Stává se, že jsou zařízení v síti zneužita třeba pro odražené útoky. Také těm pak síť Cesnet musí bránit.

Výhodou Flowspec je, že není potřeba nijak router konfigurovat, ani znát konkrétní platformu a její specifika. Pravidlo pošleme pomocí BGP a router vše zařídí, jak nejlépe umí.

Pomocí API je možné navíc Flowspec napojit na detekční programy. Automatizace je nutná, protože nám chodí stovky útoků denně. Zcela jasný útok se blokuje automaticky, na podezřelý provoz je upozorněn správce a ten pak rozhodne o blokaci ručně.

Eugene Bogomazov: Measuring Internet stability: Czech Republic, Slovakia and beyond

V Česku je podle databáze RIPE registrováno 712 ASN, na Slovensku je jich 196. Aktivních je ale jen 585 a 158. Více než polovina poskytovatelů v Česku skutečně oznamuje IPv6 rozsah, což je velmi dobré. Dvě AS mají dokonce jen IPv6 adresy.

Celkem je z Česka oznamováno 2193 prefixů IPv4 a 547 prefixů IPv6. Na Slovensku je to 741 IPv4 prefixů a 93 IPv6 prefixů. Největšími sítěmi z hlediska počtu podřízených sítí v Česku jsou UPC, SuperNetwork a T-Mobile. Seznam tu není, protože to je jen jedna síť a jeden zákazník. Tahle statistika má svá omezení. Na Slovensku jsou největší sítě GTS, Slovak Telekom a DTAG.

Mnoho operátorů nedělá tranzit, jsou připojeni k jednomu či více nadřazených poskytovatelů připojení. Jen 20 % operátorů je tranzitních, přibližně polovina poskytovatelů je navíc připojena jen k jednomu poskytovateli a nemají zálohu. Ti nejmenší operátoři jsou v Česku sdruženi v organizaci ISP Alliance, která má silnější pozici například ve vyjednávání peeringu. To je moc zajímavá aktivita, kterou jsem nikde jinde neviděl. Doufám, že se rozšíří i do dalších zemí.

Největšími peeringovými uzly v Česku jsou NIX.CZ a Peering.cz. Oba mají více než sto členů. Na Slovensku je to NIX.SK a SIX.SK, oba okolo 50 členů. Méně než 50 % sítí je v dané zemi připojeno k oběma velkým uzlům zároveň. Je to ale dobré kvůli vyšší stabilitě sítě.

Tomáš Kubina: Automated network OS testing

Systémy v síťových prvcích jsou čím dál komplexnější, neustále přibývá voleb, které se mohou různě ovlivňovat. Před nasazením v komplikovaných sítích je potřeba je otestovat na různé scénáře, aby se vyloučily nejrůznější chyby. Rozhodli jsme se, že svoje testy automatizujeme, protože je jich hodně, spousta kroků je nudných a zároveň tím vyloučíme uživatelskou chybu.

Pro tyto účely existuje řada nástrojů buď od jednotlivých výrobců nebo univerzálních. Nejlepším řešením je pravděpodobně open-source projekt NAPALM, který implementuje ovládání mnoha různých výrobců a pro uživatele jej vystavuje pomocí unifikovaného API. Původně to bylo určené pro enterprise prostředí, my jsme potřebovali doplnit některé další příkazy. Až bude nový kód dokončen, bude nabídnut původním autorům pro zařazení do projektu.

Příkladem je například reload test, který se připojí k routeru, získá jeho stav, provede reload a po 30 minutách zkontroluje, že jsou klíčové věci ve stejném stavu. Výhodou jednotného rozhraní NAPALM je, že se pro všechna zařízení chová stejně a dává stejné výsledky.

V budoucnu by bylo možné nasadit univerzální testovací nástroj Robot Framework, který je vysokoúrovňový a díky vlastnímu jazyku pro popis testů by mělo jít o jednodušší a snadno rozšířitelné řešení. Není to přímo určeno pro testování síťových prvků, ale zřejmě bychom to takto použít mohli. Ještě zvažujeme, jestli zůstat u původního řešení nebo přejít na nové.

Zbyněk Kocur: F-Tester: platforma pro měření parametrů TCP/IP sítí

F-Tester je platforma pro měření kvality sítí, ale ne pro běžného uživatele, ale spíše pro průmyslové sítě, kde hodně záleží na parametrech sítě. Je to výsledek několikaleté snahy a analýz prováděných u nás na ČVUT. Chodí k nám spousta zařízení od lidí mimo fakultu, kteří chtějí řešit nejrůznější problémy. Kromě běžných sítí to platí také pro optické sítě, NGA sítě, IoT, Industry 4.0 a podobně.

Výsledkem je hardwarové a softwarové řešení na bázi Linuxu. Základem je iPerf3 a vlastní nástroj FlowPing. Zavřeli jsme to do krabice, kterou můžeme připojit ke gigabitovému Ethernetu, plánujeme také variantu pro mobilní sítě, Wi-Fi a rychlejší Ethernet. Měřící systém je možné ovládat pomocí webového rozhraní, RPC nebo příkazové řádky po SSH.

Zařízení je vlastně aktivní sondou, umí vytvářet různé typy datových toků a sledovat, jak se síť bude při daném provozu chovat. Testy mohou probíhat mezi několika jednotkami, které mohou testovat proti sobě nebo proti centrálnímu serveru. V současné době umíme UDP i TCP, měříme propustnost, zpoždění a ztrátovost paketů. Tok je možné různě modelovat a modifikovat.

Základní stress test se snaží najít limit propustnosti dané sítě. To je základ, kde si osaháme linku, zjistíme propustnost, zpoždění a jaká bude asi chybovost. Z výsledků měření je možné odhadnout velikosti bufferů, jaká omezení jsou na lince nastavena a podobně.

Dále je možné provádět stability test, kdy se do sítě trvale posílá kontinuální datový tok, který by síť měla bez problémů přenést a sleduje, jak se síť chová. Pomocí dlouhodobého ICMP testu je pak možné sledovat ztrátovost paketů. Test může trvat hodiny, dny i týdny. Pak můžeme třeba vidět, že v některé dny se ztrátovost zhoršuje.

Testovat je možné i skutečnou službu či protokol, čímž se můžou odhalit například neduhy související s větším množstvím klientů na jedné síti. V průmyslové oblasti narážíme na jiné typy problémů, přenosové rychlosti jsou velmi nízké, ale pak se projeví například vlastnosti implementace TCP/IP stacku, který není pro podobnou linku optimalizovaný.

Ověřování propustnosti NGA linek probíhá s reálnými parametry TCP/IP, které by měly být schopné plně vytížit gigabitovou linku. Se standardně nastaveným TCP oknem se to podaří například jen ve chvíli, kdy bude RTT pod osm milisekund. Pokud bude delší, rychlost začne klesat. Testuje se třemi souběžnými datovými toky.

Tohle řešení je součástí velkého celku, který se jmenuje F-Lab, kde je možné v něm vytvářet různé typy sítí včetně simulace útlumu a rušení. Jsme tak schopni sledovat, jak síťové prvky snižují rychlost a jak se chovají při různých typech problémů.

Tomáš Podermański: Integrace DDoS Protectoru v prostředí propojovacího uzlu NIX.CZ

CESNET vyvíjí vlastní zařízení DDoS Protector, které se organizace rozhodla upravit pro použití v peeringovém uzlu a poté jej nasadila v NIX.CZ. Jde o hardwarově akcelerované zařízení s programovatelnými FPGA poli, které obsahuje několik algoritmů pro boj s DDoS útoky. Je to vlastně běžný počítač, do kterého je přidaná ta akcelerovaná karta. Celé je to v 1U šasi a spotřeba je 100 wattů.

Na začátku bylo potřeba vyzkoušet, jestli má smysl vůbec v propojovacím uzlu podobné zařízení nasazovat. Na první pohled to vypadá logicky, protože se tam schází velké množství provozu od různých operátorů. Na druhou stranu je na místě opatrnost, protože peeringový uzel je velmi důležitý bod, ve kterém nesmí docházet k žádným problémům.

Cílem tedy byl minimální zásah do infrastruktury uzlu a zachování rozhodování plně v rukou člena či zákazníka. NIX.CZ je neutrální uzel a nechce sám zasahovat do provozu mezi sítěmi. Důležitá je také zpětná vazba, aby bylo jasné, co je v síti po nasazení ochrany děje.

Peeringový uzel je chová jako velký switch, který vytváří L2 infrastrukturu pro výměnu dat mezi připojenými sítěmi. Routery naváží BGP relaci, pomocí které si vymění informace o sítích, pro které odbavují provoz. Tato spojení musí být navázána mezi všemi routery, což je mezi mnoha uživateli velmi složité a trvalo by to dlouho. Proto se v uzlech používají takzvané route servery, na které si každá síť naváže jen jedno spojení a není potřeba kontaktovat každý protějšek zvlášť. Skutečný provoz už ovšem probíhá mezi skutečnými routery.

V případě DDoS útoku se provoz valí z různých routerů a směřuje do routeru, za kterou je umístěno napadené zařízení. Z pohledu útočníka se pak podaří ucpat linku namnožením provozu z více stran. Tady právě přichází chvíle pro nás DDoS Protector. Ten by měl na sebe stáhnout škodlivý provoz a vyčistit ho tak, aby si se zbytkem koncová síť dokázala poradit sama. Je to obvykle velmi jednoduché ořezání provozu z nejaktivnějších adres až po přijatelnou úroveň. Na hrubý pytel hrubá záplata.

Používá se BGP komunita, která instruuje routery tak, aby data pro vybranou IP adresu posílal do DDoS Protectoru. Ten zase potřebuje znát skutečnou IP adresu cílového routeru, kterému má pak vrátit vyčištěný provoz. Jednoduše přidáme BGP komunitu vybrané routě a tím je to v podstatě vyřešené. Tím se přesměruje provoz, ale je potřeba zvolit typ ochrany proti danému útoku. To se opět provádí v rámci komunity, kde je možné nastavit typ mitigace a případně další doplňkové parametry.

Po prvních přípravách v loňském roce se letos začalo pracovat na implementace v projektu FENIX. To je vhodné prostředí, protože je tam menší množství sítí a dá se tam lecos vyzkoušet. Tahle fáze už je za námi. V druhé polovině letošního roku by měl proběhnout přesun do produkčního prostředí. Čeká nás integrace s RPKI, kdy nebudeme validovat u těchto speciálních rout k DDoS Protectoru. Nejvíce je ale potřeba testovat a mít nějaké další podněty z praxe.

Aktuální filtrační kapacita je 100 Gpbs, i když by bylo teoreticky možné použít na kartě ještě druhý port a tím získat dvojnásobnou kapacitu. Probíhá vývoj další generace karet, které jsou připraveny na 400 Gbps. Škálovat je možné ale i tím, že se použije více Protectorů a provoz se pak rozdělí pomocí load balancingu na L3 nebo pomocí ethernetového anycastu.

Frantisek Holop: Highlights of RIPE NCC Tools

RIPE Atlas je síť více než 10 tisíc síťových sond. V Česku je jich 255 a na Slovensku 48. Také existuje přibližně 500 větších sond, které se jmenují Anchor. Kolegové začali pracovat na virtuální verzi, aby těchto sond bylo více. Zatím jde o pilotní projekt, sondy už běží u Amazonu, připravuje se Google.

Úplnou novinkou jsou softwarové sondy, pro které se zatím připravuje infrastruktura. Z dalších novinek byla zmíněna podpora DNS cookies v API, nová dodávka docházejících sond verze 4, pracuje se na bezpečnostním auditu a připravují se nový způsob zpracování dat v cloudu.

RIPEstat je nástroj pro zobrazování informací o sítích. Nedávno byla navýšena kapacita a systém dnes odbavuje více než 70 milionů požadavků denně. Připravuje se také nové webové rozhraní, které bude přehlednější a bude velmi dobře fungovat na mobilu. Přidána byla také podpora validace RPKI, takže je na první pohled vidět, zda jsou ROA validní.

Webová stránka RIPE také dovoluje má nově funkci My Dashboard, kdy je možné si na ni přidat vlastní widgety s užitečnými informacemi. Chceme tam přidat další užitečné možnosti, ale bude je těžší implementovat. Zajímá nás zpětná vazba, co byste na stránce potřebovali.

Petr Palán: SpaceLab

SpaceLab vyvíjí motor pro malé družice, který jako palivo využívá zbytkovou atmosféru, kterou ionizuje a urychluje. Zajišťuje, že družice nespadne. Létá se v malých výškách mezi 220 a 350 kilometrech. Problém takové oběžné dráhy je, že vyžaduje neustálou energii pro udržování výšky. Běžný motor by tedy velmi rychle spotřeboval všechno palivo a spadl by.

V poslední době se hodně hovoří o připojení k internetu právě pomocí sítě družic. Je jasné, že čím níže budou přípojné body, tím bude připojení lepší. Zatím to sice nebude stejně dobré jako kabel, ale myslím si, že časem bude. Většina dnešních družic má stovky kilogramů, jsou drahé a je drahé je dostat nahoru. Motor cílí na zařízení o hmotnosti deset až dvacet kilogramů. Chceme ale, aby jich bylo hodně a zajistily by co nejlepší služby nejblíže k uživatelům.

Malé družice jsou dnes velmi levné a technologie je dostupná. Hlavním problémem tedy zůstává vynesení, které je stále ještě poměrně drahé. Ale to je jen otázka zájmu a nalezení skutečného použití, které je někdo ochoten zaplatit. Už zhruba letos na podzim by měl být k dispozici skutečný model, na kterém by mělo být možné simulovat vliv hustoty atmosféry v různých výškách.

Původně nebylo v plánu vyvíjet vlastní družici, ale v Evropě nikdo nic podobného nedělá a většina podobných projektů běží ve Spojených státech a Asii. V Evropě trochu sušíme, což je určitě škoda. Proto se ukázalo, že bude potřeba vyvinout svou vlastní satelitní platformu.

Výsledkem by měl být open source projekt evropského standardu, který by měl mít reálné nasazení. Měl by vzniknout nějaký otevřený internet, který bude dostupný i na místech, kde dnes běžná konektivita není. Časový harmonogram počítá s tím, že v roce 2020 bude dostupný první prototyp a bude možné jej otestovat ve vesmíru. V roce 2021 by se měla začít připravovat síť a v roce 2022 by měla být síť spuštěna. Dnes se vyrábějí nízké počty velkých zařízení, ale nikdo nemá nastaveny procesy na výrobu stovek malých družic.

V tuhle chvíli se hledají především nápady na využití testovací družice. Nečekáme, že někdo přijde s hotovým rádiem. Potřebujeme vymyslet, co se skutečným zařízením ve vesmíru. Co byste chtěli nechat zadarmo vyslat na oběžnou dráhu? Druhá výzva spočívá v promyšlení konkrétní formace družic sloužících pro pokrytí Země připojením k internetu. Zhruba touhle dobou za rok budeme vědět, kde budeme lítat a kde můžeme postavit pozemní stanice.

Žaneta Vinopalová: New Top Level Domains and the Issue of Universal Acceptanceighting talks

Před rokem 2013 bylo v DNS jen 22 generických domén nejvyšší úrovně. První nové generické domény se objevily v roce 2013 a dnes je jich více než 1200. Zbývá už jen 17 domén k delegaci, aby byl tento projekt ukončen. Dnes je v těchto doménách registrováno 9 % všech světových domén.

Existuje několik kategorií domén: geografické, firemní značky a pak samostatná skupina IDN domén používajících jiná písma. To je důležité pro velkou část uživatelů, protože 67 % světové populace ve svých jazycích nepoužívá latinku.

Tyto novinky jsou součástí širšího projektu Universal acceptance, který se snaží zajistit, aby byly všechny domény z technického hlediska rovnocenné a fungovaly s nimi všechny služby a nástroje.

Radek Zajíc: nenechte si rozbít IPv6

Pokud máte IPv6 a aktivně ji používáte, typicky řešíte problém, jak dostat adresy ke koncovým uživatelům. Postaru se nakonfigurovalo statické routování mezi dvěma sítěmi. Operátor si obvykle myslí, že to stačí a nemůže se to rozbít. Stalo se ale například, že se rozbila konektivita, ale operátor si toho pak nevšiml. Určitě zákazníky monitorujte, abyste si byli jistí, že všechno funguje a konektivita je funkční. Dnes už řada velkých služeb IPv6 používá a když se uživateli šestka rozbije, přestanou mu fungovat.

Pro konfiguraci se používá také DHCPv6, ve kterém je možné delegovat prefix pro koncovou síť. Stává se ale, že síť sice dostane přidělený rozsah, ale operátor mu ho zapomene naroutovat. Pak si zařízení myslí, že IPv6 existuje a je možné ji použít, ale data neprocházejí.

Další problém může nastat u subdelegace, kdy se za sebe zřetězí několik routerů, které si vzájemně rozdělí adresní prostor. Problém nastane, když restartujete prostřední router. Ten za ním bude stále používat původní adresy, ale data opět netečou.

Operátoři bohužel stále ještě k IPv6 přistupují laxněji než v případě IPv4. Narazil jsem na problém, kdy O2 nefungovalo spojení s Vodafone. Trvalo jim dva týdny než to opravili. Kdyby byl podobný problém na IPv4, psala by o tom všechna média. Na IPv6 si toho ale ještě dnes většina lidí nevšimne. Když už si toho ale někdo všimne, měli byste to opravit rychle.

Provoz po IPv4 a IPv6 by měl být směrován stejným směrem, důležité je aktivně monitorovat důležité body, je nutné mít funkční proces hlášení a řešení problémů s IPv6. Největší problém není v tom, že bych nedokázal zjistit, že se něco rozbilo. Pak ale přichází otázka, kam to nahlásit a pak je potřeba čekat na opravu.