Pavel Satrapa: Jak jsme na tom
Podle tržeb je Comcast největší operátor kabelové televize a druhý největší provozovatel placené televize na světě. Jeho přechod na IPv6 začal v roce 2005, protože jim došlo, že z IPv4 žádná další budoucnost nekouká, řekl na začátku přednášky Pavel Satrapa. Hned na začátku si řekli, že nechtějí žádné tunelování a chtějí šestku rovnou správně a nativně.
Zároveň se rozhodli implementovat postupně podle jednotlivých oblastí služeb.
Dnes má Comcast na šestce kompletně převedenou svou síť pro správu, přes kterou se dostanou ke 40 milionům zákazníků. Celkem 87 % zákazníků už používá dual-stack. V současné době od zákazníků 25 % provozu prochází po šestce a oni očekávají, že to velmi rychle půjde na dvojnásobek.
Pomůže k tomu také nasazení nových set-top boxů, kde už je 40 % zařízení převedeno výlučně na IPv6, koncem června to bude asi 15 milionů přístrojů.
Comcast ale není na konci cesty, ale spíše v polovině. Je sice téměř dokončen přechod na IPv6, ale nyní čeká síť postupné opouštění IPv4. Oni tvrdí, že čtyřka už by pro ně byla velkým omezením. Se šestkou je pro ně vše jednodušší.
Comcast je tak dnes vlastně výkladní skříní přechodu na IPv6.
Podle statistik Google přichází dnes 12 % požadavků po šestce. Na jednu stranu je to zklamání, protože podle Satrapy jsme už deset let měli být na 100 % (a možná o něco výše, jak vesele poznamenal), ale zároveň to ukazuje životaschopnost nového protokolu. Už se nedá tvrdit, že je to jen akademický koncept, který v praxi selhává.
Podle statistik AMS-IX je po šestce realizováno přibližně 1,5 % datových toků, což stále není příliš mnoho.
Ve srovnání s jinými státy na tom Česko není vůbec špatně, zajímavé ale je, že IPv6 u nás přidává v průměru 30ms zpoždění. Většina okolních států má zpoždění stejné nebo v řádu deseti milisekund. Osobně nechápu, proč to tak u nás je,
vyslovil Satrapa jednu z největších českých záhad světa IPv6.
Podle statistik CZ.NIC podporuje IPv6 necelá třetina domén (343 tisíc) a asi 15 % má IPv6 mail. Celkem 15 % dotazů na servery provozované CZ.NIC přichází po IPv6. To odpovídá přibližně dalším statistikám rozšíření IPv6.
Dobrou zprávou je, že pořád ještě držíme první místo z hlediska dostupnosti webového obsahu po IPv6 podle 6lab.cisco.com. Bohužel se moc nehýbeme, jsme už dlouho okolo 60 % a moc se to nemění.
Poměrně dobře je na tom Čína a Japonsko, které jsou vlastně tahouny IPv6.
Příslibem do budoucna je například přístup Apple, který chce od 1. června do App Store přijímat jen aplikace, které jsou schopné fungovat v čistě IPv6 síti. Uklidňují vývojáře, že pokud používají doporučené postupy, nebudou muset nic měnit. Jen v případě, že mají někde natvrdo vložené IPv4 adresy nebo volání, budou muset aplikace upravit.
iOS je tak na IPv6 připraven lépe než Android.
Další novinkou je Google DNS64 server pro veřejné použití. Zatím jde o betu, která běží na adrese 2001:4860:4860::6464. Pokud se dotážete na doménu nabízející pouze IPv4 záznam, Google vám přeloží adresu do standardního rozsahu 64:ff9b::/64, který je definován v RFC 6052. Pak si musíte na své síti zajistit překlad pomocí NAT64, který používá stejný prefix.
Z hlediska protokolu se toho za poslední roky příliš mnoho nezměnilo. Jsou to spíše kosmetické změny.
Vyšel standard SIIT-DC pro použití IPv6 v datových centrech, aby bylo možné provozovat infrastrukturu na šestce a pak provádět překlad do starého internetu. Dále byla například vylepšena detekce duplicit.
Velkým tématem v současnosti je zpracování řetězce rozšiřujících hlaviček, které vytváří nové problémy. Je to zneužíváno pro DoS útoky a způsobuje to poměrně zásadní ztrátovost paketů. Podle měření Geoffa Houstona z APNIC se ztratí až 25 % UDP paketů. Některé routery dnes začaly pakety s rozšiřujícími hlavičkami rovnou zahazovat.
Ve standardu budou pravděpodobně dále existovat, ale podle Satrapy jednoduše „zmizí po anglicku“. Podle mého názoru se postupně přestanou používat. Pokud máte své pakety rádi, nepoužívejte rozšiřující hlavičky v IPv6.
Tomáš Podermański: Strasti implementace CGN
CGN je NAT, který se neliší od NATu v domácím routeru, ale je provozován na úrovni operátorské sítě. Cílem je efektivnější využití přiděleného IPv4 prostoru tak, že každá adresa je sdílena více uživateli zároveň. Jde o technologii, která by podle představ mnohých měla být dávno mrtvá. Ale většina sítí ji musí nasadit, protože jim nic jiného nezbývá.
Problém šestky je, že i když je v síti nasazená, neřeší problém přístupu do čtyřkové sítě. Ještě velmi dlouho se pravděpodobně budeme s CGN setkávat.
Největší nevýhoda plyne z toho, že NAT je stavové zařízení s omezenými zdroji, které je možné zahltit dostatečně velkým množstvím požadavků.
Dalším známým problémem je narušení principu end-to-end konektivity, které pocítí všichni hráči počítačových her, provozovatelé IP kamer a podobně. Zároveň představuje potenciální zdroj problémů (single point of failure) a přináší problémy při sdílení mezi uživateli – pokud se adresa dostane na nějaký black list, jsou postiženi všichni uživatelé stejné adresy.
Operátoři ale CGN nasazují, protože umožňuje okamžité řešení problému nedostatku IPv4 adres. Zároveň je to příležitost k navýšení výnosu, což mají rádi všichni manažeři. Setkávám se s tím, že se uživatelům seberou jejich IPv4 adresy a pokud je potřebují, musí si za ně zaplatit.
Nasazení CGN umožňuje uvolnit velké množství adres, které je možné zpeněžit.
V sítích za NAT dochází často ke konfliktům běžných rozsahů z RFC 1918, kdy uživatelé za svým vlastním NAT používá stejné rozsahy jako přístupová síť. Proto vzniklo RFC 6598, které definuje rozsah 100.64.0.0/10 určený právě pro sítě používané za CGN. Nesmí se ovšem zase využívat v koncových sítích, jinak opět dojde ke konfliktu.
Další problém nastává při asymetrickém routování provozu, kdy NATovaný provoz odchází jinou cestou než přichází odpovědi. Příchozí router vůbec netuší, jak byl NAT prováděn a co má s provozem dělat.
Běžným řešením je synchronizovat oba NATy, ale výrobci to obvykle nedoporučují, protože to neškáluje a vyžaduje to velmi krátké propojení obou zařízení. Druhou variantou jsou dva samostatné routery, které pro NAT používají odlišné IP rozsahy. Správnou routovací politikou je zařízeno, aby se pakety vždy vracely správnou cestou. Tohle zase ale naráží na situaci, kdy jedno ze zařízení přestane fungovat – jeho roli sice převezme druhý router, ale ten začne překládat na jiné adresy a stávající TCP spojení popadají.
S NAT se komplikuje také dodržování povinnosti ukládat metadata o komunikaci uživatelů. Moderní boxy umí do netflow přidávat rozšiřující informace, podle kterých je možné identifikovat uživatele i za NAT.
Zvyšuje to ale množství dat, která je potřeba ukládat. S každou session se vlastně vytváří nové flow, což je problém zejména u velkých sítí.
Existuje ale rozšíření, které dovoluje router instruovat tak, aby konkrétní adrese přidělil vlastní blok portů. Tím pádem vznikne jen jeden logovací údaj. Pokud blok portů dojde, přidělí se automaticky další.
Při realizaci NAT je potřeba myslet také na dostatečné dimenzování výkonu. Přibývá tu nový parametr, kolik relací je schopen natující router zvládnout. Z našich měření vyplývá, že v průměru je potřeba odbavit trvale 40 relací na jednu adresu nebo 120 tisíc spojení na každý gigabit.
Zároveň je velmi intenzivně potřeba myslet na vhodný agregační poměr veřejných a privátních adres. V praxi máme ověřeno, že bez problémů funguje 1:1000. V některých konferencích se mluví o provozu s agregací až 1:10000.
Ondřej Caletka: Dual stack jako řešení přechodu?
Dual-stack je považován za nejlepší způsob přechodu na IPv6. Oba protokoly mohou neomezeně dlouho běžet vedle sebe, přináší to ale nový problém: všechno dvakrát. Je třeba řešit dvakrát adresování, konfiguraci služeb firewally a dohled. Zároveň se komplikují řešení problému uživatelů, protože je potřeba podrobně analyzovat, kde je problém s některými službami.
Nasazení IPv6 je práce navíc, kterou málo kdo ocení. Většina služeb nejprve zprovozní IPv4 a k šestce se dostane „někdy později“, což také ale nemusí být nikdy. Někdy se šestka dodatečně spustí, ale nikdo ji už pořádně nevyzkouší. Takže to sice nějak funguje, ale na IPv6-only síti se třeba na webu nenačtou styly, protože to server podávající statický obsah šestku nemá.
Řešením je provozovat v síti klasický single-stack, kde je druhý protokol nasazen jako jedna ze služeb. Je možné tunelovat šestku po čtyřce, ale to nemá budoucnost. Už budete muset navždy udržovat čtyřkovou síť, protože je to pro vás stále nosný protokol.
Druhá možnost je futuristická – překlopit celou síť do šestky a čtyřku po ní tunelovat či překládat. V každém překladu se ale něco ztratí, protože oba protokoly jsou odlišné. Otázkou je, jestli nám to vadí.
Jednou z technik je stará technika dual-stack lite, kterou používají velmi často například u kabelových televizí v Německu. Noví zákazníci už dostávají síť IPv6-only a k IPv4 přistupují po DS-lite.
Poměrně rozšířený (včetně Wi-Fi na této konferenci) je takzvaný NAT64 (čti: nat šest čtyři), který provádí zapouzdření celého IPv4 prostoru do IPv6 rozsahu. Pomocí DNS64 se uživatelé přesměrují do šestky i pro zdroje, které nový protokol neumí. Veškerý obsah se zdá být dostupný po IPv6 a síť pak provádí transparentní překlad. Často to používají mobilní sítě – například ve Slovinsku, USA, Polsku, Norsku a dalších státech.
Pro klienta je celá věc transparentní, ale musí být schopen odbavovat veškerý provoz na IPv6. To problém zejména u některých služeb jako Skype. Obecně klient musí používat DNS a ne se snažit spojit přímo s IPv4 adresou – žádnou nemá.
Tento problém se řeší pomocí 464XLAT, což je druhý překladač u klienta. Ten dovoluje vytvářet u klienta IPv4 síť, která je transparentně překládaná do skutečné IPv6-only sítě. Tohle je zabudováno například v Androidu, který to umí použít pro mobilní data, snad brzy i pro Wi-Fi.
Aby ale tato metoda fungovala, musí mít zařízení další překladovou IPv6 adresu, což je důvod, proč Android stále ještě nepodporuje přidělování adres pomocí DHCPv6. Dávejte nám prefixy, ne adresy, říkají vývojáři a je to vlastně globální trend v IPv6. Proto by měly koncové sítě používat autokonfiguraci pomocí SLAAC.
Tomáš Košňar: Implementace IPv6 v e-infrastruktuře CESNET
CESNET začal vytvářet IPv6 síť už v roce 1999, provoz byl zahájen 16. července. V roce 2001 jsme celou síť přestavěli, získali jsme oficiální prefix, zavedli strategii přidělování adres a přeadresovali jsme páteř.
V současnosti běží síť v dual-stacku v MPLS, multicast v6 je v globální tabulce stejně jako IPv4.
Z hlediska bezpečnosti jsou pro obě verze protokolu použitá stejná principiální řešení, odlišnosti v implementaci se týkají jen těch oblastí, kde se jednotlivé protokoly liší. Máme výhodu, že provozujeme tranzitní síť. Pro koncovou síť je potřeba řešit ještě mnoho dalších věcí.
Monitoring sítě je postaven přirozeně stejně jako v případě IPv4. Když to provozujeme déle než 15 let, ani nás nenapadne vymýšlet pro druhý protokol něco jiného. Vše je pro nás naprosto transparentní.
Většina monitoringu se odehrává pomocí SNMP a vlastního systému G3, který sbírá data z boxů, sleduje chování infrastruktury a vizualizuje anomálie. Monitorovací i obsahová část je doplněna o identifikátory týkající se IPv6.
Na perimetru sítě jsou umístěny hardwarové sondy, plošně v celé infrastruktuře je nasazen systém FTAS, který sbírá informace z různých zdrojů a dovoluje jejich klasifikaci a ukládání. Sledujeme nativní IPv6 provoz, žádné tunely a podobné přechodové mechanismy – ty vesele ignorujeme.
Správci CESNET tak mají velmi přesný přehled o využití svého IPv6 rozsahu, stejně jako o podílu objemu provozu v infrastruktuře a při komunikaci se zbytkem internetu. V odchozím směru máme 98,5 % na IPv4 a zbytek tvoří šestka.
V příchozím směru je poměr výrazně lepších 96:4.
V případě vnitřního provozu jde o více než 10 % dat, která jsou přenášena pomocí IPv6. Uvnitř sítě záleží jen na nás, jak si uvnitř komunity nastavíme pravidla a jak šestku podporujeme.
Podle Košňara platí, že čím blíže je nám v síti protistrana, tím roste šance, že se s ní spojíme po šestce.
Z hlediska bezpečnosti stále platí, že je IPv6 k útokům a skenům využíván výrazně méně než starší IPv4. Problém se skenováním je obrovský adresní rozsah. Zatímco za minutu jste schopni proskenovat velkou část čtyřkového rozsahu, u šestky vám to bude trvat celá desetiletí.
Martin Pustka: Slasti a strasti IPv6 v univerzitní síti
Při debatách o nasazování IPv6 často odpůrci argumentují tím, že není potřeba, protože na čtyřce všechno funguje. Dnes už ale není možné nový protokol ignorovat, protože dnešní operační systémy se snaží IPv6 získat například pomocí tunelu, v horší kvalitě. Pak se může stát, že pro něj jsou některé zdroje dostupné. I proto je potřeba implementovat IPv6 nativně.
Při nasazování IPv6 je potřeba myslet na to, že se budou v síti všechny procesy řešit dvakrát: firewally, monitoring, routování a další. Navíc se nemění jen síť, ale postupně se mění celé prostředí, s čímž je nutné počítat. Všechno je provázané se vším.
Jde o další protokol se starými i novými chybami, který navíc nemá proti IPv4 vždy stejnou podporu třeba v hardware.
Vždy je potřeba začít v síťové infrastruktuře a je potřeba si definovat, čeho chceme dosáhnout: zda systematické nebo rychlé nasazení. Jsem přítelem systematického nasazení, i když se někdy objeví požadavky na rychlé nasazení – ale práce kvapná, málo platná.
Při designu sítě je více než vhodné se držet pravidla, že se bude srovnatelně nasazovat IPv4 i IPv6.
Z hlediska připojení k internetu už dnes (kromě domácích sítí) nebývá problém získat připojení i do IPv6. Poskytovatelé dávají běžně /48 nebo /56 adres a ani rozdíly v síťových cestách IPv4/6 už nejsou tak rozdílné jako v minulosti. Před deseti lety byly rozdíly dramatické, protože se používaly hlavně tunely. Zatímco po čtyřce byla latence třeba 20 ms, po šestce byla až 50 ms. To už je naštěstí dávno minulostí.
Při pořizování zařízení je potřeba stále ještě hlídat, zda mají podporu IPv6 a na jaké úrovni. Stále jsou tu ještě výrobci, kteří řeší podporu pomocí software, takže při přechodu klesne propustnost ze stovek gigabitů na jednotky. Pokud máte třeba 48portový přepínač, máte vážný problém.
Stejně tak v případě Wi-Fi AP je potřeba hlídat podporu různých podpůrných technologií. Ty se dají doplnit softwarově, ale stává se, že novější firmware už nepodporuje starší zařízení.
V případě koexistence obou protokolů je podle Pustky stále nejlepší cestou dual-stack. Pro uživatele i správce je to nejjednodušší cesta. Nechtěl bych hledat problém v soustavě NAT64 a souvisejících technologií.
Nejrozumnější cestou podle něj je, že koncové sítě mají privátní IPv4 adresy a veřejné IPv6 adresy.
Na koncových stanicích je problém zejména v tom, že každý systém se chová trochu jinak. Uvažovali jsme třeba, že vypneme autokonfiguraci a zavedeme jen DHCPv6, ale není to možné. Každý systém je jinak aktuální, každý reaguje jinak.
Zároveň běžně zařízení používají více IPv6 adres a v čase je střídají. Vy je musíte evidovat, hlídat vazbu na fyzické adresy a ukládat o tom průběžně data.
V případě serverů (fyzických či virtuálních) obvykle nebývá se šestkou problém, výjimkou jsou cloudové služby. Nedávno jsme zkoušeli něco na Azure a zjistili jsme, že neumí IPv6. Stejně tak to má Amazon, většina funkcí jede čistě na čtyřce.
Většina uživatelů IPv6 vůbec nevnímá, ale jsou i tací, kteří ji vyžadují. Stejně tak jsou různí i správci – od úplného odmítání, až po milovníky, kteří by chtěli mít vše IPv6 only. Správcem se člověk stane ve chvíli, kdy zjistí, že jeho oblíbený IPv6 má své výhody i nevýhody. Někdy to trvá velmi dlouho.
Matěj Grégr: Jak se měří IPv6
Cílem prezentace bylo ukázat, proč vzniká dramatický rozpor mezi jednotlivými měřeními rozšíření IPv6. Existují totiž různé typy měření: u klientů je to sledování kompletní cesty mezi klientem a serverem, sledování prefixů na infrastruktuře nebo množství obsahu dostupného po IPv6.
Obsah se obvykle měří tak, že se měřicí body ptají na typ záznamu v DNS (A vs. AAAA). Děje se to pro web, mail a DNS. Zdrojem dat je nejčastěji žebříček milionu nejnavštěvovanějších domén Alexa. Problém tohoto zdroje je, že nevíme, jak je přesně vytvářen. Navíc je možné ho ovlivnit – na eBay si můžete za pár liber koupit posun v žebříčku, což je podezřelé.
Navíc hodně záleží na tom, kolik domén se při měření ze vzorku vybere – pokud jich vezmeme jen prvních 50, vyjde vám vysoká penetrace – téměř 40 %.
Návštěvnost je tady posuzována, protože se předpokládá, že když šestku nasadí významný web, ovlivní to více uživatelů Nelze ale předpokládat, že uživatel chodí jen na největší weby na světě. Dělali jsme vlastní měření a uživatelé chodí průměrně denně na 230 webů, medián je asi 180.
Používání žebříčku Alexa způsobuje další problémy: nevidíme asi třetinu webů, které mají zrovna poměrně nízkou dostupnost po IPv6. Výsledek takového měření je tedy vlastně uměle přepálený, protože ignoruje velkou část webů bez IPv6.
VUT Brno provádí vlastní měření dostupnosti webů po IPv6 a ukazuje se, že reálně uživatelé navštěvují asi 7 % webů po IPv6. To není příliš mnoho, ale zároveň se ukazuje, že existují už i weby, které jsou dostupné jenom po IPv6. Kromě testovacích webů a různých speciálních domén jsou to například CDN od Facebooku, které uživatelům se šestkou automaticky servírují 6only servery.
Správci se setkávají i s rozbitou IPv6 konektivitou. Konkrétně v případě .sk domén je 26 % domén inzerujících AAAA záznam nedostupných. Způsobuje to velký poskytovatel hostingu, který svým klientům nageneroval záznamy, ale ty jsou nefunkční. Hlásil jsem to asi před třičtvrtě rokem, potvrdili mi chybu, ale stále ji neopravili.
APNIC provádí kontinuální měření dostupnosti IPv6 z pohledu klientů. Vkládá měřicí kódy do reklam a pak sleduje, který uživatel je schopen přistoupit ke zdroji dostupnému pouze po IPv6. Největším tahounem v Česku je O2, které dává IPv6 všem svým klientům.
Prezentovány byly i statistiky VUT – přibližně 35 až 40 % provozu jde po IPv6. Velkým zdrojem jsou tu objemově významná videa z YouTube. Smutné je, že za rok se to prakticky nezměnilo, protože nepřibývá obsah. Zvýšit se to dá jedině tak, že zvýšíme počet uživatelů s IPv6.
Většina statistik podle Grégra nadhodnocuje reálný stav nasazení IPv6, díky tomu, že využívá jen malý dataset a ne reprezentativní vzorek. Pokud na síti nasadíte dual-stack, lze očekávat 40 % objemu dat přenášených po IPv6. Bohužel se to už dlouho nemění. Je ale možné si statistiky celkem libovolně přizpůsobit a ohýbat.
Martin Samek: Jak si Wi-Fi poradí s IPv6
V posledních letech došlo k velkým akvizicím mezi výrobci síťových prvků a výrobci bezdrátových prvků. Celá oblast se unifikuje a jednotlivé součásti se stávají komoditou. Většina hlavních hráčů na trhu s Wi-Fi řešeními postupně opouští vlastní vývoj RF chipsetů a využívají výrobky firem jako Broadcom a Qualcomm.
Výsledkem je, že produkty mají po hardwarové stránce stejné vlastnosti. Nemůžeme očekávat velké rozdíly, pokud má čip od Broadcomu určitou propustnost, nebudou ji mít výsledné výrobky jinou.
Rozdíly lze najít pouze v software, většinou v modifikovaném ovladači či funkcionalitách řešení.
Většina platforem je dnes založena na Linuxu, BusyBoxu a podobně. Stírají se nám i rozdíly mezi levnými a drahými řešeními.
Do testů se Martinu Samkovi podařilo získat celou řadu různých produktů:
- Aruba Mobility Controller 7210, AP.205
- Aruba Instant IAP-205
- CISCO Wireless Controller 5508
- Ruckus ZoneDirector 1200, R500
- Extreme Networks ExtremeWireless EWC-1
- Ubiquiti UniFi (starší AP)
- MiktoTik CapsMan2, wAP
- Fortinet FortiWLC 50D, AP320
Netestoval žádné síťové vlastnosti, propustnost a podobně. Zajímala ho vlastně jen podpora IPv6. Výsledky jsou dostupné v podrobné tabulce na Google Docs. Součástí je i přesná verze použitého firmware, u některých výrobků i desetinková verze znamená poměrně zásadní rozdíl.
Situace se také neustále mění, Extreme Networks tvrdí, že na konci června bude mít nový firmware se základní podporou IPv6. Stejně tak Aruba bude mít novou verzi do konci roku, naopak Ubiquiti UniFi zatím nesignalizuje žádnou blížící se podporu IPv6.
Jiří Průša: IPv6 a veřejná správa
Už v roce 2009 bylo přijato usnesení vlády č. 727, které říká, že všechny ústřední orgány státní správy mají povinnost zahrnout požadavky na IPv6 do výběrových řízení na síťové prvky. Jak už to tak bývá, dlouhou dobu se nic nedělo, ale postupně se začala IPv6 ve státní správě rozšiřovat.
V roce 2012 byla přijata Strategie Digitální Česko 2.0, která ukázala, že původní usnesení je málo a mělo by se dělat víc. Proto v roce 2013 vzniklo usnesení vlády č. 982, které rozšiřuje povinnost zahrnout požadavky na IPv6 do všech relevantních řízení, ne jen na síťové prvky. To zahrnuje třeba web hostingy, mailové servery a další služby.
Letos je pak připravován dotační program IROP 2.4, jehož součástí je i standard konektivity škol. Ten definuje, co je to bezpečné připojení k internetu. Součástí toho je i plná podpora připojení do veřejného internetu přes protokoly IPv4 i IPv6. Zatím nebyl dokument oficiálně vydán, ale vypadá to, že tyto požadavky v něm nakonec skutečně zůstanou.
Současný stav není nijak špatný, ministerstva mají po IPv6 dostupné všechny DNS servery, dvě třetiny mají dostupné i webové servery a více než tři čtvrtiny i mailové servery. Když to srovnáte s průměrem za českou doménu, jsou na tom minimálně ministerstva daleko lépe než zbytek českého internetu.
Jen tři ministerstva stále vzdorují: Ministerstvo kultury, Ministerstvo vnitra a Ministerstvo zemědělství. Z dalších institucí IPv6 nemají Státní báňská správa a Český statistický úřad. Z krajů vůbec IPv6 nepodporují Plzeňský a Ústecký. Zdálo by se, že usnesení nemají žádné sankce, ale může to být důvodem k napadení výběrového řízení a u EU projektů může dojít k neuznání nákladů.
V rámci projektu GEN6 (Governments ENabled with IPv6) vedl CZ.NIC mezinárodní benchmarking připravenosti veřejné správy na IPv6. V tuto chvíli máme celkem unikátní seznam téměř 3000 URL zaměřených na státní správu a je to porovnatelné napříč státy Unie.
Kompletní data jsou k dispozici na stats.nic.cz.
Překvapivě to vypadá, že státní správa na tom není vůbec tak špatně, jak by se mohlo zdát. Vyšlo nám, že Česká republika je na tom nejlépe. Předběhlo nás jen Estonsko, kde byl ale velmi malý vzorek zdrojů, které často běžely na jedné adrese.
František Vaněk: Nasazení IPv6 na UCEEB ČVUT
Přednáška se zabývala nasazením IPv6 v UCEEB ČVUT. Stavěli jsme úplně novou síť, takže jsme si mohli krásně hrát s nasazením IPv6.
Nakonec vzniklo několik samostatných segmentů: jeden čistě na IPv4, zejména kvůli kamerovému systému a dalšímu zařízení budovy, jeden naopak čistě na IPv6, kvůli připojení telefonů k Cisco CUCM a pak ostatní s dual-stackem.
Po nasazení se rychle ukázalo, že provoz po IPv6 je poměrně masivní. Běžně máme přes 50 %, měli jsme i den, kdy se průměr vyšplhal na 86 % provozu po IPv6. Například na HTTPS máme běžně mezi 70 a 80 % provozu po šestce.
Takovou síť musíte už skutečně poctivě monitorovat, nejde o nějaký experiment, ale naopak o plnohodnotnou komunikační infrastrukturu.
Pro monitoring se zde používá komerční nástroj Scrutinizer a svobodný FlowViewer původně vyvíjený pro NASA. Oba krmíme flows z MicroTiku CCR16 a dávají nám zhruba stejné údaje.
Z hlediska útoků přichází po IPv6 stále jen asi jeden ze sta. Trápí nás především skenování konkrétních portů: SSH, SQL a další.
Čím dál častěji se děje to, že proběhne sken na IPv4, poté proběhnou reverzní DNS dotazy a samotný útok pak už jde po IPv6.
Největší problémy zatím způsobují dočasné IPv6 adresy, výchozí chování Cisco telefonů po resetu a velice malá podpora reverzních IPv6 záznamů, takže nelze konsolidovat provoz do domén. Pokud máte server, dejte mu reverzní záznam i na IPv6 adresu.
Z hlediska hardware je situace také velmi různorodá. Zatímco u tiskáren (Xerox, HP, Canon…) nebývá vůbec problém a u kamerových systémů (Vivotek, Axis…) je situace také celkem slušná, u tabletů a mobilů je situace velmi různorodá. Novější verze Androidu už má částečnou podporu, ale třeba telefony s Windows jsou vysloveně katastrofa.
Stejně tak v případě průmyslové automatizace, různých čidel či infrastruktury budov je to podle Vaňka „zoufalá krize“. To se týká NTP hodin, SIP vrátníků, měřicích přístrojů, inteligentních senzorů, převodníků RS232/eth a podobně. V té naší počítačové části světa šestka celkem solidně funguje, ale jakmile sáhnete do průmyslové oblasti, rychle zjistíte, že tam šestka vůbec nefunguje.
Ondřej Surý: Můj život na IPv6-only
CZ.NIC často propaguje nasazování IPv6, proto se Ondřej Surý rozhodl experimentálně používat IPv6-only síť pro práci. Šlo o jednoduchou konfiguraci s NAT64 a DNS64, klientská stanice byla na Linuxu.
Většina důležitých věcí podle Surého bez problémů funguje: prohlížeč i SSH.
Jak napsat software, který na IPv6-only funguje? Určitě nespoléhat na pevnou velikost IP adresy na čtyři bajty, ale používat standardní knihovny getaddrinfo(3), které šestku umí od roku 1999. Většina linuxového software s tímto nemá dávno problém.
Naopak nefungují komerční (nenativní) software: Spotify (Linux Client), Skype, WhatsApp a Steam. Rád bych si doma zahrál nějaké hry, ale se Steamem na takové síti nemůžete.
Řešením je na klientské stanici nasadit už zmíněný 464XLAT, který z šestkové sítě zase dělá čtyřkovou. Lepší řešení: buďte slyšet! Dejte vědět dodavateli, že to opravdu chcete, aby o tom věděli.
ČLÁNKY DO MAILU