Už za čtyři měsíce nás čeká největší událost ve světě IP technologií. Šestého června se největší poskytovatelé obsahu na světě rozhodnou vypublikovat ve svých DNS záznamech i AAAA záznamy – tedy IPv6 adresy svých služeb. A nepůjde o jednodenní test, jako v roce 2011. Tentokrát už AAAA záznamy zůstanou v DNS nastálo a budou dostupné každému, kdo o ně požádá. Událost má název World IPv6 Launch („Světové spouštění IPv6“) a z významných českých firem se k projektu připojil zatím jen Seznam.cz, i když veřejně o tom tisková zpráva ještě nešla. Jak se ale poperou s AAAA záznamy webové prohlížeče, pokud jejich uživatel má rozbitou IPv6 konektivitu? Na to odpoví následující řádky!
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 trvání 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 nestěž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 s verzí Androidu 2.3.5 a CyanogenModem 9 s Androidem 4.0.3. Systém umí používat IPv6 na WiFi, Android 2.3 nepoužívá anonymizované adresy, Android 4 adresy anonymizuje. 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 (Gingerbread), resp. 534.3 (ICS), 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. Ani zařízení s Androidem 4 Ice Cream Sandwich na tom ale nejsou lépe, což je velmi smutné a nabízí otázku, kdy Google podporu přidá a jak dlouho potrvá zařazení opravy chování prohlížeče výrobcům zařízení, kteří, jak známo, už dnes svůj hardware nepodporují často už rok od uvedení na trh.
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 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 ledna 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.