Je tomu již více než rok, co jsem zde psal o snaze Evropské komise regulovat pod hlavičkou revize rámce pro elektronické podpisy a eID (tzv. eIDAS) rovněž oblast certifikátů pro webové stránky, tzv. SSL certifikátů. O tom, že projednávání návrhu tohoto nařízení bude běh na dlouhou trať, svědčí mimo jiné to, že i po roce a půl od jeho představení jsme stále daleko od jeho schválení. To se v ideálním případě očekává až před volbami do Evropského parlamentu, tj. v květnu 2014, s tím, že v platnost by tato, pro členské státy přímo účinná, legislativa vstoupila v platnost 1. ledna 2015.
V rámci projednávání návrhu na půdě Rady byla Česká republika mezi těmi, kteří hned na úvod projednávání nesouhlasili s rozšířením současné regulace rovněž o SSL certifikáty s tím, že postupně se k nám přidaly další státy. V současné době litevské předsednictví dokonce navrhuje vypuštění textu, jisté zmírnění požaduje rovněž Evropský parlament, konkrétně výbor ITRE (Výbor pro průmyslu, dopravu, výzkum a energetiku). Ten na svém říjnovém zasedání navrhl (viz tučný text) zohlednit rovněž zapojení internetové komunity (skrývající se v euro-slangu pod pojmem stakeholders) a vypracování analýzy dopadu.
|
Article 37 Requirements for qualified certificates for website authentication
|
Ponechme nyní stranou, zda by evropská legislativa měla obsahovat spojení jako „nejlépe“ (preferably) a raději se zaměřme na zohlednění zájmu internetové komunity. Text totiž v tomto ohledu hovoří o jejím zapojení, na druhou stranu však Evropská komise „znovu vynalézá“ kolo, když se v příloze č. IV snaží definovat obsahové náležitosti SSL certifikátů. Na tomto místě by však měla být zohledněna práce IETF a již existující RFC (Request For Comments), které jsou v prostředí Internetu obdobou klasických standardů.
Zmiňovaným SSL certifikátům se věnuje zejm. RFC 5246 a RFC 3039, které definuje mj. obsah certifikátů, tj. tu samou věc, o kterou se Komise snaží v příloze IV. Na tuto skutečnost upozornil na svém říjnovém zasedání rovněž RIPE, který svoji pozici vyjádřil v dopise adresovaném Evropskému parlamentu.
V rámci nadcházejících jednání bude důležité, aby se členské státy za návrh Předsednictví postavily, při jednání s Evropský parlamentem i Komisí regulaci certifikátů jasně odmítly a podpořily tím principy správy Internetu i dosavadní práce na IETF.
Jiří Průša
Služba CAPTCHA Help se dočkala řady změn
Službu CAPTCHA Help provozuje CZ.NIC od srpna tohoto roku. Za tuto poměrně krátkou dobu si už ale stihla najít své věrné uživatele; těch je aktuálně více než 200 a stále přibývají. Když k tomu přidáme cca 10 vyřízených požadavků týdně, můžeme směle tvrdit, že si své místo a zájemce našla. A právě proto, že se služba ukazuje jako perspektivní, pracují vývojáři na jejím vylepšování.
Vývojáři proto nedávno zveřejnili dokument nazvaný S CAPTCHA Help doplňkem o krok dál. Ten je rozdělený do jednotlivých kapitol – Instalace, Nastavení a Použití, předposlední díl je potom věnovaný roli operátora a poslední budoucnosti. V této závěrečné části vývojář Petr Závodský kromě jiného píše: „Ke službě CAPTCHA Help velice brzy přibudou doplňky pro další prohlížeče: Internet Explorer, Mozilla Firefox, Safari. Doplňky prohlížečů chceme také vylepšit o některé další funkcionality, např. dát uživateli možnost zvolit si rozsah screenované části kolem CAPTCHA obrázku. Služba bude také postupně optimalizovaná tak, aby uživatel obdržel odpověď do několika desítek sekund. CAPTCHA Help také začínají využívat zahraniční uživatelé a i na ně se proto postupně začínáme zaměřovat.“
Celý dokument je proložen řadou obrázků a postupů, jak se službou efektivně pracovat. Měl by tedy bez problémů posloužit všem, kteří se chystají nové funkcionality využívat.
Vilém Sládek
Videorozhovor pro ISOC: Jaromír Talíř představuje Knot DNS
V ISOC existuje projekt Deploy 360 Programm, který si klade za cíl překlenout propast mezi IETF standardy a jejich zavedením do praxe. Deploy360 Programm je zaměřený například na IPv6, DNSSEC nebo routing. V jeho rámci má na internetových stránkách ISOCu své místo také náš Knot DNS.
Tuto záložku nedávno rozšířila prezentace kolegy Jaromíra Talíře z poslední konference ENOG, která se týkala mimo jiné také toho, že připravovaná verze Knot DNS (1.4.0) bude umět podepisování DNSSEC. Na záložce najdete vedle ní také rozhovor s Danem Yorkem, o který se s vámi rádi podělíme i na našem blogu:
Vilém Sládek
Laboratoře CZ.NIC odhalily závažnou zranitelnost linuxového jádra
V rámci vývoje a testování softwaru pro nový router CZ.NICu Turris jsme objevili nebezpečnou chybu v linuxovém jádře, která umožňuje vzdáleně způsobit kernel panic; pád jádra lze vyvolat posláním vhodně zformátovaných IPv6 fragmentů. Podle našeho názoru má chyba potenciál na DoS útoky.
Ve skutečnosti se jedná o dvě chyby v různých částech Linuxového jádra, které mohou nastat při zpracování IPv6 datagramu s nekorektně vyplněným fragmentation headerem. První chyba je známá od května 2011 pod označením CVE-2011-1927 a byla opravena ve verzi 2.6.38.9 linuxového jádra. Nyní došlo k pravděpodobné regresi této chyby v aktuálních jádrech počínaje verzí 3.11 a v mailinglistu vývojářů síťových driverů a TCP/IP stacku už je k dispozici patch, který tuto chybu opravuje. Oprava bude pravděpodobně začleněna do nejbližší budoucí udržovací verze jádra.
Druhá chyba, která dosud nebyla známá, se netýká samotného sestavování fragmentů k předání vyšší vrstvě síťového modelu, ale týká se Netfilteru – Linuxového firewallu, který sestavuje IP packety (IPv4 i IPv6) jen virtuálně, aby o nich mohl rozhodnout podle pravidel v INPUT resp. FORWARD chainech v tabulce filter. Problém, na který jsme v Laboratořích CZ.NIC narazili je, že překrývající se fragmenty můžou vyvolat kernel panic za podmínky, že dochází k pokusu o virtuální sestavení datagramu a to pravděpodobně z velmi podobných důvodů, jako v případě první chyby.
Chybu jsme reportovali v mailinglistu a spolupracujeme na vytvoření patche s vývojáři Linuxového TCP/IP stacku a Netfilteru.
Tomáš Hlaváček
Pomsta za Internet?
Síťové sekci konference Intel European Research and Innovation Conference 2013 (program) jednoznačně vévodily dvě zkratky: SDN (Software Defined Networking) a NFV (Network Functions Virtualization). O SDN jsem už na tomto místě psal a na další příspěvek se chystám v souvislosti s účastí CZ.NIC v FP7 projektu NetIDE.
O virtualizaci síťových funkcí přednášeli především zástupci velkých telekomunikačních operátorů (Telefónica, Verizon) a firem, které jim navrhují infrastrukturu a dodávají služby. Mně osobně daly jejich příspěvky možnost nahlédnout pod pokličku sítí 4G LTE, o nichž, přiznám se, jsem toho dosud mnoho nevěděl. Ne že bych byl teď o mnoho moudřejší, ale jeden základní dojem jsem si přece jenom odnesl – tyhle sítě jsou v porovnání se standardním Internetem pekelně složité. Už jen ta záplava zkratek, namátkou: OSS, BSS, HSS, MME, PCRF, OTT, BRAS, SGSN, GGSN, VAS … Virtualizace je pak celkem pochopitelně jednou z cest, jak tento moloch zvládnout.
Přemýšlel jsem o tom, kde se ta složitost vlastně bere. Zčásti jde jistě na vrub známých nedostatků v reálném Internetu, jakými jsou třeba nefungující multicast či chabá podpora mobility. Hlubším důvodem je ale podle mého známý end-to-end princip, na němž jsou protokoly TCP/IP postaveny, tedy v podstatě hloupá a ne zcela spolehlivá síť, jež funguje díky tomu, že pokročilejší funkce jsou soustředěny v koncových stanicích. Je jasné, že v takové best-effort síti je obtížné nabízet zákazníkům diferencované služby a podle toho je pak také kasírovat.
Když tedy technologičtí experti předestírají vize budoucího Internetu jakožto sítě chytrých telefonů a jiných mobilních zařízení, musíme si uvědomit, že se nejedná jen o osvobození od kabelů, ale dost možná taky o podstatné změny v architektuře globální sítě – bude to vlastně ještě Internet, jak jej dnes známe?
Ladislav Lhotka
Nový projekt: DNS Collector sbírá a analyzuje provoz v DNS
Primární účel DNS (Domain Name System) je zprostředkovat překlad doménových jmen na adresy v síti. Ve zjednodušené formě – klient generuje dotazy a server poskytuje odpovědi. Jako takový tvoří DNS jednu z důležitých služeb v IP sítích. Ve většině případů začíná komunikace na internetu právě DNS dotazem. Stopy této komunikace lze nalézt na různých úrovních DNS hierarchie. Analýzou těchto stop (DNS dotazů) lze získat užitečné informace o stavu sítě a chování jejích uživatelů.
Sběr DNS dat
DNS provoz je potřeba extrahovat z celkového síťového provozu. Převážná část DNS provozu je přenášena nefragmentovanými UDP pakety. Abychom získali pokud možno celistvý pohled na přenášená data, je nutné u zbylého provozu provést defragmentaci paketů a provést rekonstrukci TCP spojení. Je také nutné se vypořádat s poškozenými pakety nebo nedokončenými datovými přenosy.
V DNS provozu na serverech obsluhujících .cz TLD převládá síťový protokol IPv4. V závislosti na objemu provozu a umístění serveru se jeho zastoupení pohybuje kolem 90 %. Výjimku tvoří server akuma, umístěný v Japonsku, u kterého je poměr IPv4/IPv6 převrácený. Na transportní vrstvě dominuje UDP.
Aplikace DNS Collector zjednodušuje zpracování DNS provozu tím, že je schopna poslouchat provoz na několika síťových rozhraních současně. V současné době k tomu využívá knihovnu libpcap. Zachycený síťový provoz je defragmentován. V případě TCP provozu je sledováno správné ustanovení a ukončení TCP relace. Přerušená TCP spojení nebo neúplné pakety jsou po čase zahozeny. Zrekonstruované surové (tak jak jsou přenášené po síti) DNS pakety jsou v závislosti na použité síťové a transportní vrstvě opatřeny daty z IPv4/IPv6 a UDP/TCP hlaviček. Takto připravená data jsou předána ke zpracování do modulů.
DNS Collector umožňuje zpracovávat také archivovaný provoz uložený v souborech na disku (ve formátu podporovaném knihovnou libpcap). V tom případě pak ale není možné současně zpracovávat archivovaný provoz s živým provozem ze síťových rozhraní. V současné době také není také možné zpracovávat více archivů (souborů) současně, protože doposud nebyl implementován mechanismus řazení paketů podle časových značek uložených v souborech. V případě, že je potřeba zpracovat více archivů současně, je nutné použít externí aplikaci jako je například mergecap nebo PCAPMerger.
Zpracování provozu v modulech
Modul je funkční jednotka, která se zabývá zpracováním surových DNS dat. Tyto data mu připravuje DNS Collector způsobem zmíněným v předcházející části. Moduly představují funkční abstrakci, umožňující izolovat jednotlivé činnosti nad DNS daty. Moduly si udržují vlastní kontexty, mohou tedy pracovat nezávisle na ostatních modulech.
Moduly lze nahrávat nebo uvolňovat za běhu celé aplikace. V porovnání se samostatnými aplikacemi provádějícími ekvivalentní činnost mají moduly výhodu menší režie. Všechny moduly totiž společně sdílí společnou vrstvu, která se stará o přípravu vstupních dat. Tato vrstva by v případě samostatných procesů musela existovat ve všech procesech.
DNS Collector neposkytuje žádné rozhraní pro parsování surových DNS dat. V závislosti na povaze zpracovávaných dat je možné implementovat vlastní jednoduchý parser DNS paketu, nebo v případě složitějších operací použít některou z existujících knihoven, jako je například ldns.
Detektor anomálií
Tento modul vychází ze samostatného projektu detektoru DNS anomálií. Původní samostatná aplikace prováděla statistickou analýzu části DNS provozu, která byla dostupná v úplných UDP paketech. Na základě vzájemné podobnosti zjištěných vzorů pak posuzovala, zda je provoz „normální“. Je nutné upozornit, že se jedná o hodnocení ve smyslu: normální je převažující chování. V tomto smyslu anomálie nemusí být nutně škodlivé, pouze se něčím vymykají charakteristice většiny. Díky použití v DNS Collectoru je možné zpracovávat data pocházející z fragmentovaných paketů a dat přenášených přes TCP.
Výstupem tohoto modulu je textové hlášení o detekovaných anomálních identifikátorech. Volitelným výstupem jsou soubory vykreslující výskyt detekovaných anomálií ve formátu vhodném pro zpracování gnuplotem.
Na následujících obrázcích je ukázka několika typů detekovaných anomálií. Data byla zachytávána a analyzována v desetiminutových intervalech 1. října na serveru dns-b-01. Grafy zobrazují zastoupení anomálního provozu v poměru k celkovém provozu. IP adresy jsou záměrně nahrazeny.
Na grafech je zobrazeno zastoupení provozu označeného jako anomální:
IP A – hromadné rozesílání emailů, provoz obsahuje dotazy na MX a adresy mailserverů
IP B – opakovaný dotaz se stejným ID v krátkém intervalu (300x během 2ms)
IP C, D, F, G – rekurzivní resolvery
IP E – DKIM spam-filter
IP H – opakované dotazy na adresy tří nameserverů, postupně se zvyšující ID dotazů
Spouštění skriptů v Pythonu
Ne každá analýza si zaslouží samostatný modul psaný v C. V případech, kdy není jisté, zda bude výsledek použitelný, je výhodnější použít jazyk s méně pracnou správou paměti a přívětivější správou datových struktur, který je vhodnější pro prototypování. Teprve v případě, kdy je ověřeno, že testovaný postup bude fungovat, bude nutné algoritmus přepsat do C nebo C++.
Pro účely rychlého návrhu slouží modul pro spouštění pythoních skriptů. Modul implementuje wrapper pro rozhraní DNS Collectoru. Toto rozhraní je pak možné využívat ve spouštěném skriptu. Samotný modul volá interpret jazyka Python (libpython). Kód wrapperu obaluje předávané C-čkové struktury a vytváří z nich PyObjecty. Za cenu snížení výkonu aplikace, v důsledku obalování datových struktur, je možné využívat všechny výhody dynamicky typovaného interpretovaného jazyka s automatickou správou paměti. Surová DNS data je možné v Pythonu zpracovávat pomocí pyLDNS (wrapper okolo LDNS).
Použití tohoto modulu není pro jiné účely, než je testování, doporučeno. Důvodem je samotná knihovna libpython. Tato knihovna nepodporuje více samostatných interpretů v rámci jednoho procesu. Libpython nepoužívá kontext pro předávání konfigurace interpretru; kontext interpretu existuje jako globální struktura(y) v prostoru procesu. Libpython sice implementuje něco, čemu říká sub-interpreter, ale jak sami tvůrci v dokumentaci uvádí, izolace těchto „pod-interpretrů“ není úplná. Při použití funkcí z nízkoúrovňových operací připouštějí jejich vzájemné ovlivňování.
Konfigurace
DNS Collector je možné spouštět na popředí z příkazové řádky. V tom případě je možné konfigurovat a používat pouze jedno síťové rozhraní či archiv a jeden modul. Tento režim slouží zejména k testování modulů nebo ke spouštění v dávkovém režimu pro postupné zpracování více archivů. Primární určení DNS Collectoru je být spuštěn jako daemon pro monitorování DNS provozu. V tomto případě je vhodnější používat konfigurační soubor, ve kterém je možné současně specifikovat nastavení několika síťových rozhraní společně s několika moduly.
Experimentální konfigurace NETCONFem
Pro použití ve vzdálených zařízeních je experimentálně implementována možnost konfigurace pomocí protokolu NETCONF. NETCONF je protokol založený na XML, umožňující konfiguraci síťových zařízení. Funkce NETCONF serveru je naprogramována s využitím knihovny libnetconf. Tato knihovna implementuje NETCONF server a klient a bezpečný komunikační SSH kanál.
DNS Collector na listopadové konferenci CZ.NIC
Pokud vás tento projekt zaujal a máte k němu otázky, můžete samozřejmě využít komentářového formuláře. Jestli se ale chcete dozvědět více a zeptat se přímo, doporučil bych vám, abyste si udělali čas na naši konferenci Internet a Technologie 13.2 (30. 11., MFF UK, Praha), v jejímž již brzy zveřejněném programu prezentace na toto téma bude.
Karel Slaný
Projekt Turris – pomozte nám vybrat antény
Velké úsilí věnujeme v rámci projektu Turris tomu, aby byl náš hardware co nejkvalitnější a co nejlépe sloužil jeho budoucím uživatelům. Pro domácí síť je jistě jednou z nejdůležitějších součástí Wifi, které šetří náklady na síťovou infrastrukturu, ale zejména umožňuje připojování mobilních zařízení jako jsou chytré telefony a tablety.
Abychom v této oblasti poskytli co nejlepší funkci, rozhodli jsme se pro řešení založené na velice kvalitním chipsetu od firmy Qualcomm Atheros, které nabízí 3×3 MIMO (multiple in, multiple out), laicky tři antény, a to jak v běžném pásmu 2,4 GHz (802.11b/g/n), tak v pásmu 5 GHz (802.11a/n), které není zdaleka tak zarušené. Uživatel si tak může podle vlastní potřeby vybrat, které pásmo mu z hlediska jeho vlastností a lokální situace lépe vyhovuje.
U Wifi ale kvalita spojení závisí nejen na použité elektronice, ale výrazně také na kvalitě použitých antén. Pokud uvažujeme běžné domácí použití, tak jsou nejpraktičtějším řešením všesměrové antény. Ty mají při běžných velikostech (do 20 cm) zisk mezi 2 a 5 dBi a pro běžný provoz v domácnosti jsou většinou naprosto dostačující.
Z výše zmíněných důvodů jsme plánovali dodávat s routerem Turris tři všesměrové antény, ideálně dvoupásmové, tedy schopné pracovat v pásmech 2,4 i 5 GHz. Tady jsme ale bohužel narazili na problém – nabídka dvoupásmových všesměrových antén je velice omezená a ceny dost vysoké. Je to pravděpodobně dané tím, že Wifi v pásmu 5 GHz zatím není příliš rozšířené a pro domácí použití, kde jsou vhodné všesměrové antény, není tak univerzálně použitelné (signál se hůře ohýbá a prostupuje stěnami, pro vnitřní použití je vhodnější ve velkých otevřených prostorách).
Z tohoto důvodu jsme se rozhodli obrátit na naše čtenáře s prosbou o pomoc. První prosba míří na případné výrobce nebo dodavatele antén, kteří by nám byli schopni nabídnout kvalitní antény odpovídající výše zmíněným parametrům. Budu rád, pokud se mi ozvete na adresu bedrich.kosata@nic.cz. Druhá prosba je určená širší veřejnosti, zejména již předregistrovaným zájemcům o router Turris. Pomocí Google Drive jsme připravili krátkou anktetu ohledně plánovaného použití Wifi a budeme rádi, pokud nám jejím vyplněním pomůžete vybrat nejlepší řešení.
Bedřich Košata
Perlička na závěr
Jako jeden z možných způsobů, jak obstarat vhodné antény za rozumnou cenu, jsme se obrátili přímo na několik čínských výrobců antén. Zatím se nám podařilo otestovat vzorky od jednoho z nich a výsledky byly tristní – v pásmu 5 GHz fungovala jejich „dvoupásmová“ anténa hůře, než anténa určená jen pro 2,4 GHz. Když jsme anténu rozebrali, zjistili jsme proč – v cca 15 cm těle je ukrytá maličká anténa konstrukcí podobná tomu, co se běžně používá jako interní anténa v levnějších Wifi routerech.
Na následujícím obrázku vidíte pro srovnání (zleva do prava) rozebranou standardní 2.4 GHz anténu, 5 GHz anténu, kvalitní dvoupásmouvou anténu (zde je bohužel vidět jen malá část, většina antény je součástí plastového krytu) a výše zmíněnou testovanou anténu. Je asi zřejmé, proč poslední uvedená v testech příliš neuspěla. (Obávám se, že pokud bychom si objednali místo 5 dBi verze 8 dBi, dostali bychom stejný produkt jen v delším plastovém obalu za vyšší cenu).
Obamacare má technické problémy kvůli chybě v jednotném přihlašování
Možná jste již v médiích zaznamenali, že Barack Obama připustil rozsáhlé technické problémy své zdravotnické reformy. Jeden z architektů protokolu OpenID Connect John Bradley k tomu na svém blogu napsal krátké shrnutí, ve kterém tvrdí, že jednou z příčin těchto problémů je zvolený způsob implementace jednotného přihlašování na hlavním webu healthcare.gov.
Velké instituce, zejména ve státní správě (samozřejmě myšleno mimo ČR), nejdou úplně rychle z dobou a pro jednotné přihlašování (anglicky „single sign-on“) v rámci svých digitálních agend používají léta prověřený protokol SAML. Platí to jak pro připravovaný systém propojení evropských digitálních identit STORK, kterého se účastníme, tak i pro systémy federální vlády Spojených států. SAML je předchůdce OpenID a psal jsem o něm i na našem blogu.
Příčinou problémů je nestandardní použití jednoho atributu protokolu SAML. To způsobuje, že poskytovatelé služeb zdravotního pojištění, kteří se chtějí napojit na centrální systém, musí aktualizovat svoje systémy, aby se nestandardnímu chování přizpůsobili.
U nás v České republice, kde v digitalizaci státní správy teprve dobíháme vyspělejší státy, a kde jsem si také užili své při startu různých centrálních registrů, může tato situace vyvolat lehký posměch. Ani ve Spojených státech se spouštění velkých projektů neobejde bez komplikací. Na druhou stranu je třeba ocenit, že tyto vyspělejší státy sáhnou radši po prověřeném standardu, než aby vymýšlely vlastní proprietární řešení. V České republice vedle mojeID, které je již používáno i městy a obcemi, nabízí jednotné přihlašování i systém datových schránek. Ten se však vydal cestou vlastního technického řešení a zatím jej využívá jen jeden subjekt.
Jaromír Talíř
První čtyři nové generické domény dostaly zelenou!
Trvalo to dlouho, proces byl hodně bolestný, ale už máme první výsledky. Proces, který byl mnohými nazýván největší inovací Internetu poslední doby, se dostal do závěrečné fáze. V pondělí 21. 10. ICANN oznámil, že čtyři nové generické domény dostaly zelenou a velmi krátce poté, ve středu zhruba ve 21:00 našeho času, byly tyto domény delegovány. Vzhledem k tomu, že nelatinkové domény nakonec dostaly v tomto procesu přednost, nelze předpokládat, že zrovna tyto domény budou v našich končinách nějak mimořádně populární. Jde konkrétně o:
- شبكة (xn--ngbc5azd) – arabské slovo pro „síť“
- онлайн (xn--80asehdb) – rusky „on-line“
- сайт (xn--80aswg) – rusky „webová stránka“
- 游戏 (xn--unup4y) – čínsky „hra“
Kdy přesně bude možné v těchto doménách provádět další registrace zatím není jasné. Určitou technickou zajímavostí je, že všechny čtyři domény byly delegovány včetně DS záznamů, tedy včetně DNSSEC, protože to je už u těchto nových domén povinnost.
Osobně jsem nikdy nebyl velkým příznivcem tohoto procesu a pořád nejsem příliš přesvědčen, že splní to, co se od něj očekávalo, tedy konkurenci zavedené superdoméně .com. Spíše se bojím, že nové domény přinesou chaos běžným uživatelům. Nicméně, pokud mi už nějaké z těchto domén dávaly smysl, tak to byly právě tyto nelatinkové varianty. Přeji tedy našim arabsky, rusky a čínsky mluvícím síťoobčanům, ať jim nové domény slouží.
Ondřej Filip
Za rok přibylo v ČR více než 100 tisíc uživatelů IPv6
V nedávném příspěvku na téma DNSSEC jsem se odkazoval na prezentaci Geoffa Hustona na RIPE 67. Dovolím si tento úspěšný koncept využít ještě jednou a krátce okomentovat jeho další prezentaci, tentokrát o IPv6. Geoff se pokusil ověřit závěr Google, že podíl IPv6 se za poslední rok zdvojnásobil. Ačkoliv se v absolutních číslech liší, což je poněkud paradoxní, protože opět využívá reklamní síť právě od Googlu, v hrubých rysech se jeho závěry shodují. Dle jeho měření stoupl podíl IPv6 z 0,45 % na 1,29 %, což je již výrazný nárůst.
Poměrně překvapivé je, že hlavním motorem tohoto růstu je Evropa a to konkrétně Evropa severní a Evropa východní (do které jsme řazeni i my). Osobně bych spíše očekával, že nejvyšší nárůst bude v regionu Asie-Pacifik, protože ten byl nedostatkem IPv4 adres zasažen jako první. Leč neděje se tak.
Podle metodiky Geoffa přibylo v České republice za rok více než 100 tisíc uživatelů IPv6, což je vzhledem k naší velikosti poměrně slušné číslo. Celosvětově jsme v penetraci IPv6 na desátém místě a podle všeho se o to nejvíce zasloužili tito tři poskytovatelé Internetu: CESNET, který zvýšil podíl IPv6 uživatelů z 20 % na 27 %, Telefónica CR (0 % -> 3 %) a Internethome (0 % -> 2 %). Veliká gratulace a doufejme, že obdobná statistika příští rok dopadne ještě lépe.
Ondřej Filip