IPv6 Brokenness

IPv6 brokenness, tedy „rozbitá IPv6 konektivita“, je výraz, který skloňuje každý, kdo chce nabídnout službu po IPv6. Zjednodušeně jde o stav, kdy se uživatelův počítač domnívá, že má k dispozici funkční IPv6 konektivitu, ale odeslané pakety netrefí k cíli (webovému serveru). Obvykle to je důsledkem chybné konfigurace některého z lokálních směrovačů, případně automatické konfigurace a používání IPv6 tunelů na počítači uživatele.

IPv6 tunely se sice ve dnešních moderních operačních systémech používají (například Windows Vista/7 je konfigurují plně automaticky), ale aplikace by při absenci nativní (netunelované) konektivity neměla vůbec k IPv6 zdrojům přistupovat. Bohužel, v některých starších systémech nebo aplikacích jsou chyby a tunely jsou aktivně využívány, i když například nefungují (systém tunel nakonfiguruje, ale už neověřuje, jestli provoz z něj dojde do všech míst v internetu).

Chybná konfigurace směrovačů může pro změnu vést ke stavu, kdy si počítače v síti naivně myslí, že je dostupná nativní konektivita, ale provoz se do internetu vůbec nedostane.

Jsou ještě další případy, obvykle však kombinují chybnou síťovou konfiguraci a nefunkční tunely (například sdílení připojení ve Windows Vista automaticky odesílá do LAN sítě oznámení směrovače a pro ostatní PC se pak tváří jako IPv6 router).

Výsledkem všech takových situací je stav, kdy se uživatelův prohlížeč internetu pokouší otevřít stránku (nebo načíst obsah z internetu), ale protože konektivita nefunguje, snaží se spojení navázat opakovaně a intervaly mezi jednotlivými pokusy postupně prodlužuje. V extrémních situacích může pokus o načtení stránky s jedním AAAA záznamem na takové síti trvat i deset minut (!). Při více AAAA záznamech v DNS se pak doba pokusů o načtení adekvátně násobí.

Z uživatelova pohledu to znamená jediné: služba nefunguje, stránky se nenačítají. A právě tento problém vede poskytovatele obsahu k obezřetnosti a odmítání publikace AAAA záznamů v DNS.

World IPv6 Launch

Samozřejmě, správné řešení takových problémů by vyžadovalo zajistit, aby oznámení směrovače v síti neposílala neoprávněná zařízení, aby systémy nevytvářely automaticky IPv6 tunely, aby došlo k opravě příčiny. Jenže svět takhle nefunguje, spousta sítí má nedovzdělané správce, kteří odmítají tento problém řešit, nebo nedostatek financí na nákup aktuálního hardwaru, nebo se používají počítače se zakázanými aktualizacemi a tudíž k nim nejde protlačit aktualizace zakazující tunelovací mechanismy.

Problém slepice vs. vejce by tak nikdy nebyl vyřešen, protože vydavatelé obsahu by čekali na opravu systémů a sítí, a správci sítí by pro změnu nedělali nic, protože IPv6 přece žádný z vydavatelů obsahu nevyužívá. A tak vznikla loni myšlenka vyzkoušet, kolika uživatelů se doopravdy problém ‚rozbitosti‘ týká. Vše vyvrcholilo osmého června, kdy největší obsahoví hráči vypublikovali do DNS zmiňované AAAA záznamy a jejich uživatelé se s případně rozbitou sítí museli poprat (tj., museli zajistit nápravu, aby se na služby dostali). Po čtyřiadvaceti hodinách se u většiny organizací vše vrátilo do starých kolejí – AAAA záznamy z DNS zmizely a všichni se rozhodovali, jak dál.

Loni šlo pouze o jednodenní akci, ale protože počet stížností byl extrémně nízký (u Seznamu si dokonce na helpdesku nes­těžoval vůbec nikdo), rozhodly se zúčastněné společnosti akci letos zopakovat. Tentokrát to ale bude jinak: šestého června zveřejní AAAA záznamy v DNS a už je tam nechají. Pokud loni existovali uživatelé, kteří měli své sítě rozbité, a na ten jeden den to ‚přetrpěli‘, tentokrát budou muset konat a zajistit nápravu.

Letos se akce navíc účastní i někteří poskytovatelé připojení a (zatím dva) výrobci domácích routerů. Tedy, podpora je široká, zpátky už se nikdo nevydá.

Jenže co s těmi, kteří své sítě nechtějí nebo nemohou měnit, a kteří opravdu jsou postiženi problémem ‚rozbitosti‘?

Happy Eyeballs

Pokud se k činu nemají správci (tedy není odstraněna příčina), nezbývá, než odstranit následek. A tady přichází ke slovu mezinárodní organizace IETF, standardizující protokoly, které se v internetu používají. Na půdě pracovní skupiny v6ops (má na starosti projednávání a práci na standardizaci všeho potřebného pro fungování IPv6) proto již loni v březnu vznikl návrh nového internetového standardu, s pracovním názvem Happy Eyeballs, doslovně přeložitelné asi jako „šťastné bulvy“, ale lepší překlad bude asi ‚úsměv na tváři‘.

Standard Happy Eyeballs, až bude schválen, by totiž doopravdy měl zajistit, aby se uživatel při práci s internetem nemračil kvůli tomu, že se mu stránka nenačítá. Aktuálně návrh standardu existuje už v sedmé verzi a i když ještě nebyl schválen, existuje už několik implementací v aplikacích.

Princip, jak má standard fungovat, je v podstatě jednoduchý: systém (nebo aplikace) si bude udržovat informace o úspěších při práci s jednotlivými internetovými protokoly (IPv4, IPv6) a následně podle toho při svém běhu jeden z protokolů preferovat. Při pokusu o připojení k internetovému serveru se nejprve pokusí o navázání spojení po preferovaném protokolu, a po určitém čase (200 – 300 milisekund) paralelně zkusí i druhý (třetí, …) protokol. Na správně nakonfigurované síti vždy alespoň jeden z protokolů bude funkční a tedy dojde k úspěšnému navázání spojení. Takové spojení bude pak použito pro komunikaci se serverem, zatímco ostatní paralelně probíhající pokusy o spojení budou ukončeny.

Když aplikace nebo systém implementuje Happy Eyeballs, projeví se to tak, že uživatel na rozbité síti po zadání internetové adresy prakticky nezpozoruje, že se stránka po IPv6 nenačítá. Včas totiž proběhne navázání spojení po IPv4 a následně i zobrazení stránky (načtení obsahu FTP složky, připojení k Jabber serveru, atd.).

A v takovou chvíli už ani poskytovatelé obsahu nebudou mít důvod IPv6 nespouštět.

Podpora v aplikacích

Happy Eyeballs je, jak jsem už zmiňoval, v některých aplikacích už podporován. Protože by ale pouhý výčet aplikací nebyl tolik zajímavý, rozhodl jsem se udělat test, jak se jednotlivé prohlížeče zachovají. Do testu jsem zahrnul i mobilní browsery, které jsem doma dokázal během dnešního odpoledne rozjet a otestovat. Testy jsem prováděl při připojení na domácí WiFi síť, kde mám konektivitu od IGNUM (prostřednictvím SixXS tunelu). Vždy jsem nejprve zjistil IPv6 adresu testovaného zařízení a následně jsem ho střídavě povoloval/zakazoval na IPv6 firewallu (ip6tables na Linuxu). ‚Velké‘ prohlížeče jsem testoval na svých Windows 7, ostatní operační systémy se chovají podobně. U velkých prohlížečů budu chování na různých operačních systémech rozepisovat.

Mobilní prohlížeče

BlackBerry

Jako první jsem si od ženy půjčil BlackBerry 9780. S tím byly testy hotové rychle. Prohlížeč (resp. asi systém?) totiž IPv6 vůbec nepodporuje, při načtení dual-stack stránky šel vždy po IPv4 a při pokusu o načtení IPv6-only stránky nenačetl vůbec nic. Tedy i když prohlížeč Happy Eyeballs nepodporuje, nehrozí vám při jeho používání problémy s nenabíhajícími stránkami.

Windows Mobile 6

Jako druhý přišel na řadu systém Windows Mobile 6 na stařičkém HTC TyTN I. Systém kupodivu IPv6 na WiFi podporuje, preferuje IPv6 konektivitu a používá anonymizované IPv6 adresy, ale vzhledem ke stáří integrovaného browseru (Internet Explorer Mobile 6.12) si při nefunkční konektivitě na načtení stránky počkáte. Každý publikovaný AAAA záznam prodlouží načítání o 280 sekund, tedy o necelých pět minut (systém se pokouší třikrát navázat spojení, každý ze tří pokusů vyšle TCP SYN paket a čeká postupně 3, 6, 12, 24 a 48 sekund na odpověď). Jiné prohlížeče jsem vzhledem ke stáří systému nesháněl.

Windows Mobile 6 na síti s rozbitou IPv6 konektiviou nabídnou hodně nepříjemné zážitky. Implementaci Happy Eyeballs vzhledem ke stáří systému neočekávám.

Symbian S60 9.3, Feature Pack 2

Testy symbianového zařízení jsem prováděl na Nokii E72 s firmwarem 22.007, nepředpokládám ale, že se situace v novějších firmwarech změní k lepšímu. Systém umí používat IPv6 na WiFi i na 3G, i když u nás IPv6 na 3G ještě žádný operátor nenabízí. Na WiFi nepoužívá anonymizovanou IPv6 adresu a preferuje IPv4 před IPv6.

Testoval jsem integrovaný prohlížeč, Operu Mobile 11.10 a Operu Mobile 11.50 – všechny tři prohlížeče IPv6 uměly, ale použily ho jen, pokud adresa serveru neobsahovala A záznam (IPv4 adresu). Pokud server měl dual-stack konektivitu, systém vždy preferuje IPv4.

Otestoval jsem i Operu Mini, u které ale vzhledem k využívání serverů Opera Software pro rekódování obsahu nemůže dojít k brokenness stavu (servery Opery IPv6 nepodporují).

Tedy, na Symbianu můžete spokojeně surfovat a rozbitost IPv6 na síti vás trápit nebude.

Android

Testoval jsem na firemním HTC Wildfire s CyanogenModem 7 a verzí Androidu 2.3.5. Systém umí používat IPv6 na WiFi a nepoužívá anonymizované adresy. TCP timeouty v případě Androidu jsou nastaveny na 3–6–12–24–48–96 sekund a testované aplikace (integrovaný prohlížeč postavený na WebKitu/533.1 a Dolphin Browser HD 7.3.0) se pokoušejí spojit se serverem třikrát. Pokus o načtení IPv6 stránky tedy na každý AAAA záznam způsobí na síti s nefunkční IPv6 konektivitou celkem 570 sekund čekání (!). To je suverénně nejdelší interval čekání a uživatele od návštěvy stránky jednoznačně odradí (už po minutě zhasíná displej).

Android je na tom tedy s čekáním ještě hůř, než Windows Mobile 6. Vše by mohla zachránit podpora Happy Eyeballs – na rozdíl od prohlížeče ve Windows Mobile 6 u Androidu očekávám opravu v některé z dalších verzí prohlížečů nebo systému. Zařízení s Androidem 4 Ice Cream Sandwich bohužel zatím k otestování nemám, pokud se k nějakému dostanu, výsledky testu sem přidám.

iOS

Největším překvapením v testu mobilních prohlížečů byl rozhodně iOS od Applu. Ve verzi 5.0.1 systém podporuje IPv6 na WiFi, používá anonymizované adresy a integrovaný prohlížeč implementuje Happy Eyeballs! Tedy v případě sítí s rozbitou IPv6 konektivitou prakticky okamžitě přechází na IPv4 verzi stránky a uživatel nepozoruje žádné zdržení.

Safari na Apple iOS 5 tedy podporuje a preferuje IPv6 a zároveň nabízí výborný uživatelský zážitek. Ostatní výrobci by si měli vzít příklad, takhle se to má dělat.

‚Dospělé‘ prohlížeče

Dospělé prohlížeče jsou ty, které můžete běžně používat na svých stolních počítačích a noteboocích. Projdeme si postupně všechny dnes používané prohlížeče a zmíníme, jak se který chová. Všechny dospělé prohlížeče dnes podporují IPv6, pokud ji podporuje systém. To není automatické: Windows XP podporu pro IPv6 v sobě sice mají, ale uživatel ji musí doinstalovat. Pokud ji nainstalovanou nemá, problém rozbitosti ho trápit nebude.

Internet Explorer

Tento prohlížeč se ve všech verzích chová stejně. Happy Eyeballs neimplementuje a tak na síti s rozbitou IPv6 konektivitou čeká dle standardních timerů systému 21 sekund při připojení na adresu z každého obdrženého AAAA záznamu. Z uživatelského pohledu se stránka tedy po 21 sekundách načte žádaná stránka. Pokud ale stránka obsahuje ještě obsah z dalších adres (css styly, obrázky), trvá stažení obsahu dalších 21 sekund pro každý server.

Google Chrome

Jde o první prohlížeč vůbec, který standard Happy Eyeballs implementoval. Podpora je v Chromu již od verze 11, tedy od loňského jara. Takto starý prohlížeč pravděpodobně již nikdo nepoužívá (Chrome se automaticky a tiše aktualizuje na pozadí), proto s Chromem nebudete mít problémy a stránky na dual-stackovaných serverech se vám načtou vždy během mrknutí oka.

Mozilla Firefox

Druhý prohlížeč, který oficiálně implementoval Happy Eyeballs. Podpora se objevila už ve verzi 7, ale byla implicitně vypnutá. Až verze 10, která vyšla na konci prosince 2012, podporu Happy Eyeballs automaticky zapíná. Každý uživatel s Firefoxem 10 tedy může v klidu surfovat a o úsměv na jeho tváři se postará prohlížeč.

Pokud chcete zůstat u Firefoxu 7, 8, či 9, pro klidné spaní si nastavte parametr „network.http.fast-fallback-to-IPv4“ v about:config na hodnotu „true“. Bez tohoto nastavení se i na vás vztahují následující řádky.

Firefox 6 a starší (včetně stále populárního Firefoxu 3.6) Happy Eyeballs nepodporují a proto se na rozbitých IPv6 sítích setkáte s čekáním, než všechny pokusy o spojení na IPv6 selžou. Ve Windows jde opět o zmiňovaných 21 sekund, v Linuxu cca 3 minuty, na MacOS cca 20 sekund.

Opera

Severská Opera se vyvíjí poměrně rychle a rychle získává i podporu nových webových technologií (HTML 5, CSS 3 a pod.), ale Happy Eyeballs nepodporuje ani v posledních verzích (Opera 11.61, Opera Next 12). Není známo, jestli autoři plánují podporu přidat. V jejich vlastním dobru by ale měli. Opery starší, než 10.50, měly ještě jeden nešvar: u dual-stackovaných serverů se pokoušely využít IPv6 konektivitu, i když v systému byla k dispozici jen konektivita tunelovaná.

Opera je u nás vcelku populární a tak dokud autoři neimplementují Happy Eyeballs, musí se sami její uživatelé postarat o to, aby jejich síť neměla rozbitou konektivitu. Jinak budou až dlouhé minuty čekat, než systém vzdá snahy o spojení na IPv6.

Safari

Jde o poslední prohlížeč, tentokrát z dílny Applu. U něj je situace o něco složitější. Na Mac OS X 10.7 (Lion) a novějších (až vyjdou) se Safari chová korektně a implementuje Happy Eyeballs. Bohužel, na ostatních systémech, včetně starších MacOSů, zůstává chování původní. Tedy uživatel s rozbitou konektivitou čeká a čeká, než se mu stránka načte.

Navíc u MacOS X starších, než 10.6 (Snow Leopard), dochází k podobnému problému, jako u Opery: systém preferuje tunelovanou IPv6 konektivitu před nativní IPv4 konektivitou. V nových systémech je toto ošetřeno.

Tedy, aktuální Safari na aktuálním MacOS X vám vrásky nezpůsobí, jiná kombinace ano. Pokud nechcete nebo nemůžete upgradovat na Lion, použijte alternativní prohlížeče (Chrome, Firefox).

Potřebujeme Happy Eyeballs?

Ano. Naše měření ukazují, že pořád až pět uživatelů z každých deseti tisíc může trpět problémem rozbité IPv6 konektivity. Toto číslo sice kontinuálně klesá, ale pořád není nulové a v milionech uživatelů nejde o zanedbatelné případy. Proto doufám, že se Happy Eyeballs rozšíří i do dalších produktů, které mohou využívat oba IP protokoly.

A šestý červen ukáže, kolika lidí se rozbitost týká doopravdy.

Že IPv4 adresy brzy dojdou, o tom nepochybuje nikdo. Do dvou let by to mělo potkat centrální autoritu pro přidělování IPv4 adres (IANA), posléze regionální registrátory a úplně nakonec i jednotlivé lokální registrátory (povětšinou poskytovatelé konektivity k internetu nebo poskytovatelé obsahu).

Jaký je současný stav?

• ASN 5610, hlavní autonomní systém bývalého Internetu OnLine
• ASN 20884, používá se zřejmě pro interní účely v O2 (např. pro službu Carrier IP Stream)
• ASN 28725, autonomní systém bývalého Eurotelu

Proč tomu tak je?

Tahle změna je možná trošku pochopitelná z pohledu nákladů, nikoli však z pohledu technického. Ten, kdo o takovéto konsolidaci rozhodl, zahodil všechnu práci techniků Eurotelu. Síť IOLu IPv6 neumí a podle vyjádření pánů z Telefóniky na zmiňované konferenci ani neběží žádný interní projekt, který by měl tuto situaci změnit.

O IPv6 se v O2 na odpovědných místech nikdo nezajímá, zmiňovaní pánové se při dotazu, jestli s tím někdo něco alespoň zkoušel dělat a testovat IPv6, pouze ušklíbli a poznamenali „možná někde v labu…“

Mému kolegovi, který se zástupcem O2 o IPv6 jednal loni v létě, bylo přislíbeno, že snad ke konci roku (2008) by to jejich síť měla umět. Máme tu léto 2009 a ze strany IOLu není vidět absolutně žádný pokrok. Interně se IPv6 netestuje, peeringy ani tranzitní IPv6 konektivitu IOL nemá a ani mít nemůže, protože – ač jsou největším českým operátorem – dodnes nemají ani vlastní IPv6 prefix (!).

Co s tím?

Jako kdyby si snad ani manažeři neuvědomovali, že jde o jejich fatální selhání. Další ignorování IPv6 může totiž znamenat výrazný odliv zákazníků. A nemusí to trvat dlouho…

Za sebe mám jasno: chystám se sepsat dopis o tomto selhání a adresovat ho přímo generálnímu řediteli TO2 Czech Republic, panu Salvadoru Anglada Gonzalesovi. Jako (minoritnímu) akcionáři Telefóniky O2 se mi totiž tento přístup firmy k IPv6 nelíbí a protože dopisy adresované zákaznické podpoře končí zřejmě v koši a k vyššímu managementu se nedostanou, nezbývá než jít až k nejvyššímu řediteli…

Aktualizace 23. 6. 2009: V Telefónice se zřejmě chytli za hlavu a konečně začali konat. 19. června jim RIPE oficiálně přidělilo IPv6 prefix 2a00:1028::/32, bohužel zatím tento prefix není v globální routovací tabulce vidět. Ale i tak je dobře, že se konečně něco děje.

Výsledek (a taktéž datový tok IPv6 přes NIX.cz v průběhu dne a týdne) můžete posoudit na http://zajic.v.pytli.cz/nixcz/

Roční graf je k dispozici na http://nix.cz/cz/ipv6

• Aktuální verze RouterOSu (čím novější, tím lepší)
• Balíčky routing-test a mpls-test pro vaši architekturu (x86, mipsel, mipsbe, ppc)
• Znalost práce s konzolí
• Winbox, telnet  nebo SSH přístup ke konfigurační konzoli RouterOSu
• Troška trpělivosti, pokud se vše nepodaří napoprvé
• A samozřejmě, nakonfigurovanou IPv6 síť v RouterOSu, alespoň IPv6 adresy na rozhraních a výchozí bránu (nechcete-li ji distribuovat automaticky) 

Instalace balíčků

1. Nainstalujte aktuální verzi RouterOS (tradičním způsobem) a restartujte router
2. Poté si ve WinBoxu otevřete sekci Files a přetáhněte do ní balíčky routing-test a mpls-test z vaší platformy. Router restartujte.
3. Po restartu přejděte do sekce System-Packages. Povolte balíček routing-test a zakažte balíček routing. Router restartujte.
4. Po dalším restartu opět přejděte do Packages, povolte balíček mpls-test a zakažte balíček mpls. Router restartujte.

Konfigurace OSPFv3

Otevřeme si terminál (ve winboxu nebo přes SSH) a přejdeme do sekce /routing ospf-v3, kde si následně necháme vypsat stávající konfiguraci. Měla by být přítomná area backbone a výchozí (default) instance:

Následně nastavíme router-id a redistribuci cest (zde redistribuujeme statické cesty a „přímo připojené“ sítě):

Následně přejdeme do sekce /routing ospf-v3 interface a aktivujeme OSPFv3 na konkrétním rozhraní (případně na všech najednou pomocí rozhraní „all“, podle potřeby). Při následném výpisu pomocí příkazu print bychom již měli vidět spuštěné OSPFv3 (je označeno písmenkem D před názvem rozhraní):

Následně můžete pomocí /routing ospf-v3 route print zkontrolovat, které cesty jste obdrželi pomocí OSPFv3, podobně /routing ospf-v3 neighbor print vypíše sousedící OSPFv3 routery a stav vzájemné synchronizace. Obecný přehled na IPv6 cesty lze získat též v sekci IPv6 → Routes ve Winboxu, případně pomocí příkazu /ipv6 route print v terminálu.

Hotovo

Máte-li další tipy a nápady k IPv6 na RouterOSu, podělte se o ně v diskusi!

Virtualizace

IPv6

Aby vše fungovalo i z pohledu uživatelů (tj. abyste si blog četli přes IPv6), bylo potřeba správně nakonfigurovat DNS zónu. S tím problém nebyl, dnešní DNS servery si s IPv6 vcelku rozumí. Tento blog používá pro DNS klasiku, DNS server BIND.

Aby to však nebylo tak jednoduché, rozhodl jsem se, že otestuji schopnost svého registrátora (Internet CZ, a.s.) a doménového registru (CZ.NIC) vložit do ccTLD zóny .cz tzv. IPv6 glue záznam.

DNSSEC

Pokud se vám však při pokusu o načtení zobrazuje chyba typu „Stránku nelze zobrazit“ a tento článek čtete v RSS čtečce nebo pomocí Google Cache, neváhejte a napište mi e-mail na adresu radek ZAVINÁČ zajic.v.pytli.cz, nápravu zjednám v nejbližším možném termínu.

NAT a IPv6

IPv6 jako bezpečnostní hrozba

Problém může plynout z toho, že ne všechny firewally si s IPv6 poradí, nemluvě o tom, že někteří uživatelé (mezi nimi i autor tohoto blogu) firewall nemají vůbec aktivní. Pak samozřejmě v případě existence výše zmíněných automatických tunelů může dojít k tomu, že porty, které máte otevřené, budou dostupné i potenciálnímu útočníkovi zvenčí.

Zakazování IPv6 protokolu

V případě systému Linux to sice může přinést kýžený efekt, kdy se počítač nezkouší připojit na IPv6 adresy, v případě systémů Windows Vista a Server 2008 jde však dle mého názoru o zbytečnost. Síťová vrstva Windows Vista a Server 2008 – jakkoli je zkriplená – má totiž jednu úžasnou schopnost či vlastnost. Když totiž nastavíte IPv6 síť mezi vaším počítačem a routerem, systém se pokouší zjistit, zda mimo lokální IPv6 konektivity máte i IPv6 konektivitu do internetu. A pokud ne, nevrací při běžné práci aplikacím AAAA záznamy a tyto se tedy na IPv6 adresy nepřipojují a tudíž by nemělo docházet k žádnému zpoždění při načítání stránek či podobných činnostech.

Afrika jako lídr v zavádění IPv6

Ve skutečnosti jde jen o důsledek efektu, kdy se Afrika k ‚internetizaci‘ dostala jako poslední a tak na ni dnes připadá jen malé procento ze všech přidělených čísel autonomních systémů a IPv4 adres. Kvůli různým tunelům dnes nelze jednoznačně říci, kdo v zavádění IPv6 vede, vezmeme-li ale absolutní počet čísel autonomních systémů, které oznamují do světa své IPv6 směrovací informace, bude na tom nejlépe asi Evropa. Není bez zajímavosti, že na druhém místě v počtu viditelných (ku všem přiřazeným) IPv6 prefixů je Německo, Česká Republika je „až“ devátá.

Zajímavým úhlem pohledu by taktéž mohlo být srovnání dostupnosti IPv6 koncovým uživatelům – tam bychom se asi moc vysoko neumístili, protože koncový uživatel u nás prakticky nemá šanci získat nativní IPv6 konektivitu – ani kabeloví operátoři ani poskytovatelé ADSL se do IPv6 nehrnou.

Nepodpora IPv6 v DSL síti Britského Telecomu

A co kabeloví operátoři

Hybatelé pokroku

Mezi webovými službami jednoznačně vyniká projekt ipv6porn.com, který si klade za cíl nabídnout uživatelům s IPv6 zdarma lechtivý obsah, za který by při použití pouze IPv4 museli na jiných serverech platit. Realizace tohoto projektu se ovšem neustále oddaluje a tak se objevily jiné projekty, které se snaží tuto myšlenku zrealizovat. U nás jde o server prujem.cz a na Novém Zélandu vznikl ipv6porn.co.nz, který se mi však (na rozdíl od našeho Průjmu) nepodařilo v prohlížeči ani načíst.

Mezi torrenty sice zatím není mnoho obsahu, který by uživatele nalákal, postupně se ale objevují služby, kde lze pomocí IPv6 získat různý obsah. Mezi prvními byl bezesporu IPv6 tracker na SixXS.org a nedávno se přidal i IPv6 tracker pro distribuci oblíbené linuxové distribuce Ubuntu.

Samotné trackery však nemohou fungovat bez kompatibilních klientů a tak přichází na scénu nová verze populárního klienta BitTorrent protokolu, program uTorrent. Ten ve své verzi 1.80 nabízí nejen kompatibilitu s IPv6 trackery, ale zároveň i možnost uživateli automaticky nainstalovat a nakonfigurovat IPv6 protokol a Teredo tunel.

Windows Server 2008, Microsoft Exchange 2007 Service Pack 1 a IPv6

Pavel Satrapa – IPv6, druhé vydání

Pavel Satrapa se proto rozhodl knihu aktualizovat o možnosti nových operačních systémů, změny a doplnění jak protokolu IPv6 samotného, tak různých podpůrných mechanismů (IPv6 a DNS, přechodové mechanismy NAT-PT, NAT64, atp.) a to vše nejprve konzultuje s vámi, potenciálními čtenáři!

Kniha vyjde v Edici CZ.NIC a její aktuální pracovní verze je dostupná na adrese http://knihy.nic.cz/ipv6/ – tamtéž můžete panu Satrapovi v komentářích pod jednotlivými kapitolami zanechat komentář a knihu tak obohatit.

Síťové programování a IPv6

IPv6 novinky v zemích Českých

Nejprve začneme rekapitulací:

Seznam.cz si o IPv6 prefix požádal v červnu letošního roku. Na začátku července jej od RIPE dostal. Poté bylo nějaký ten pátek ticho, až tento týden začal být vytrubován IPv6 prefix do světa 

Protože se jedná o úplně první test, moc od toho nečekejte. Je dostupná homepage, web Spolužáků a chat.lide.cz. Výběr stránek, které jsou zkušebně zprovozněny, byl a je náhodný. Jde o první krůček, který má demonstrovat, že to jde, když se chce.

Služby samotné zatím nebyly pro IPv6 nijak optimalizovány, v některých případech využívají své hlavní domény (tj. např. „www.spoluzaci.cz“) a tak i když do prohlížeče zadáte následující adresy, po chvilce se můžete ocitnout zpět na IPv4 verzi. V takovém případě se nebojte v adresním řádku opravit doménu na „šestkovou“ – obsah by se měl načíst. Názory mi můžete napsat do komentářů pod příspěvkem.

• Homepage – http://ipv6.seznam.cz/ a http://hp.ipv6.seznam.cz/
• Spolužáci – http://ipv6.spoluzaci.cz/
• Chat.Lidé.cz – http://chat.lide.ipv6.seznam.cz/

[Disclaimer: Autor příspěvku má v této akci prsty a nemůže proto působit nezaujatě]

Moc o tom není vidět ani slyšet, ale při pohledu pod pokličku zjistíme, že je přes IPv6 je dostupná část googlích služeb – ty, které běží na adrese „www.google.com“, dnes naleznete přístupné i na „ipv6.google.com“. Jde tedy např. o fulltextové hledání, Google Webmasters, Google Analytics a mnohé další. Naopak nejde o Google Code, hledání v obrázcích (images.google.com) a obecně služby, které mají vlastní doménu třetího řádu.

K IPv6-kompatibilním službám teď přidávají další – Google Cache, tedy funkcionalitu, pomocí které si můžete zobrazit stav stránky tak, jak jej Google zaindexoval.

Vyzkoušet si Google Cache přes IPv6 můžete i vy, potřebujete pouze IPv6 konektivitu, pak si otevřete www.google.com, vyhledejte nějaký text a po vyhledání v adresním řádku přepište „www.google.com“ na „ipv6.google.com“. Poté se odkazy na Google Cache promění na IPv6 odkazy:

Hledání:

Cache:

Další z projektů, které Google upravuje tak, aby byly kompatibilní s IPv6, je linuxový Virtual Server (Linux Virtual Server, IP Virtual Server). To má pod taktovkou Julius Volz ze švýcarské pobočky. Google tedy IPv6 nezanedbává, což je dobře pro něj i pro zbytek světa.

Aktualizace červen 2009: Tento článek je z roku 2008. V polovině roku 2009 je situace bohužel stejně tristní. Stav příprav na IPv6 u Telefóniky O2 jsem shrnul v článku O2 a IPv6? Až naprší a uschne. Doporučuji k přečtení.

Protože poskytovatelem ADSL může být téměř kdokoli, kdo má dostatečný kapitál, nebudu zmiňovat všechny ADSL providery. Ani to není v mých silách, zdroje v pevnolinkové části Telecomu (pardon, O2) nemám, a tak nevím, kolik ADSL poskytovatelů u nás vlastně působí.

• AVONET, s.r.o.
• ČRa, a.s.
• Dial Telecom, a.s.
• EMEA s.r.o
• GTS NOVERA a.s.
• INTERNET CZ, a.s.
• SkyNet, a.s.
• Telefónica O2 Czech Republic, a.s.
• Telekom Austria Czech Republic, a.s. (VOLný)
• Tiscali Telekomunikace Česká republika s.r.o.
• WIA

Subject: IPv6 konektivita na ADSL připojení

Dobrý den,

nabízí Vaše společnost IPv6 konektivitu u připojení přes technologii ADSL? Pokud ano, u jakých služeb, jak lze službu aktivovat, k jakým službám a jaké jsou poplatky? Pokud ne, budete IPv6 nabízet v dohledné době?

Předem děkuji za odpověď.

Nejrychleji, za dvě a půl hodiny, odpověděli ze společnosti WIA. IPv6 na ADSL nenabízí, ale hledají kompatibilní koncová zařízení a na páteři jim šestka funguje v testovacím režimu.

Po pěti hodinách přišla stručná odpověď ze společnosti Telekom Austria (VOLný) – toto neumožňují.

Po dvanácti hodinách (tedy v pondělí v osm večer) dorazil e-mail z AVONETu, ve kterém s lítostí oznamují, že službu neposkytují, časový horizont není znám, jisté ale je, že v nejbližších měsících poskytovat nezačnou.

Druhý den, po 25 hodinách, dorazila odpověď od O2. Informační hodnota nulová, operátor se tiketu zbavil s textem „V uvedené záležitosti kontaktujte prosím naši technickou podporu na 800 184 084“. Informační hodnota nulová, odpověď na konkrétně specifikovaný dotaz žádná.

Zavolal jsem tedy na linku technické podpory a zeptal se tam. Zatím neprobíhají žádné testy, v dohledné době se s tím nepočítá a výhled či plán do budoucna nemají. Co je smutné, operátor pronesl větu, že „I kdyby to bylo v plánu, operátoři o tom vědět nebudou“. Inu, komunikace v rámci firmy zjevně funguje stejně špatně, jako komunikace se zákazníkem po e-mailu.

O další hodinu později dorazil anonymní e-mail ze společnosti Tiscali Telekomunikace, ve kterém oznamují, že uvedené služby již nenabízí. Zvláštní, pravděpodobně tedy nabízeli, ale přestali. Nabízí se otázka proč…

Těsně před úterní jedenáctou hodinou dorazil i e-mail ze SkyNetu. IPv6 v dohledné době nabízet nebudou. Pokud se jejich postoj změní, budou informovat na webových stránkách.

Ve středu po půl desáté dorazila odpověď od firmy GTS Novera: O IPv6 pro ADSL vůbec neuvažují. Pro větší služby dělali nějaké testy, nicméně o nasazení v blízké budoucnosti neuvažují.

DOPLNĚNO: Dodatečně jsem našel ve spamkoši e-maily od Dial Telecomu a EMEA Telecomu:

Dial Telecom poskytuje služby ADSL.Way (zděděné po odkoupené InWay) na infrastruktuře O2, která dle sdělení Dial Telecomu IPv6 nepodporuje. Ve zbytku sítě IPv6 mají, což už ovšem víme 

EMEA Telecom používá jako dodavatele služeb společnost GTS, která se ovšem výše vyjádřila, že IPv6 podporovat u ADSL (zatím?) nehodlají. Takže ani u nich nepořídíme.

Suma sumárum