Category: IPv6

Jak obejít nefunkční IPv6 na justice.cz

Jedním z nešvarů při nasazování IPv6 do provozu je neschopnost správců. Jednou z ukázek takové neschopnosti je implementace nasazení IPv6 na webové prezentaci Ministerstva spravedlnosti (dostupné na adrese portal.justice.cz). Pokud patříte mezi uživatele s funkční IPv6 konektivitou, na weby justice.cz se už téměř dva roky nemáte šanci dostat. Pojďme si shrnout příčiny a možné způsoby obejití tohoto problému.

Problém

by se dal charakterizovat tak, že někdy během roku 2010, ve snaze naplnit Usnesení vlády č. 727 ze dne 8. června 2009 (mimochodem, předně dva roky před World IPv6 Day :-)), správce Justice.cz tento portál „zprovoznil“ i pomocí protokolu IPv6. Od té doby je práce s tímto webem doslova utrpením – tedy pokud na svých klientských počítačích máte IPv6.

IPv6 má jak adresa www.justice.cz, tak i skutečná adresa portálu – portal.justice.cz. Adresy se ale liší, ale chování za nimi schovaných serverů je shodné, možná tedy ukazují na jeden počítač s více IPv6 adresami. Nebo na více počítačů se stejně špatným nastavením.

Při přístupu na Justice.cz se objevuje několik problémů:

  • MTU problémy: pokud máte IPv6 konektivitu s MTU nižším, než 1500 (jakýkoli tunel, včetně nativního IPv6 poskytovaného přes PPPoE u DSL přípojek), může dojít k navázání spojení, ale data od webserveru k vám nedorazí, protože routery v cestě zahazují ICMPv6. ICMPv6, zejména jeho zprávy Packet too big, jsou ovšem pro správné fungování IPv6 vyžadován. Nesprávné filtrování pak vede k tomu, že data od jedné nebo druhé strany TCP spojením neprojdou. O správném filtrování ICMPv6 si můžete přečíst např. v RFC4890. Tento problém se u webserveru Justice.cz vyskytoval dřív, dneska už je, zdá se, opraven (alespoň něco).
  • Problémy s navázáním spojení: pokud si tcpdumpem zachytíte pokus o přenos úvodní stránky justice.cz, můžete zaregistrovat chování, kdy data začnou přicházet právě 21 sekund po odeslání GET požadavku. Tato prodleva napovídá, že na straně justice.cz existuje problém s navazováním spojení (např. od webserveru k backend serveru), kdy po 21 sekundách dojde k přepnutí z jednoho IP protokolu na druhý. 21 sekund je timeout, který pro navázání TCP spojení existuje ve Windows. A justice.cz používá právě servery na platformě Windows. Data chodí v podivných 536 bajtových blocích, hluboko pod hodnotou minimálního IPv6 MSS. Zajímavé je, že tenhle problém se neprojeví při pokusu o stažení z Linuxu, kde se ale projevuje následující:
  • Problémy s „blokovým“ přenosem dat od serveru: tento problém jsem zaregistroval na tunelovaném i nativním připojení. Pokud se připojíte telnetem k IPv4 adrese portal.justice.cz, tcp port 80, a zašlete GET požadavek na adresu /Justice2/Uvod/u­vod.aspx (úvodní stránka portálu Ministerstva spravedlnosti), data k vám dorazí během mrknutí oka.Pokud to samé ale zkusíte po IPv6, budete pozorovat, jak přicházejí po cca dvoukilobajtových blocích (rychlostí 2 kB za sekundu!). Problém se neprojevuje na Windows, ale naopak je ho možné pozorovat na Linuxu, data v TCP chodí ve 1208 bajtových blocích.

Všechny zmiňované problémy by nevadily, pokud by šlo o neveřejné testování. Státní správa ale jde cestou ‚nejprve zveřejnit AAAA záznamy v DNS a pak odstraňovat problémy‘. Dvouleté testování si tedy naplno můžeme užívat my všichni, kdo již IPv6 využíváme.

Samozřejmě, dlouho to vydržet nejde, pokud s Justicí pracovat _potřebujete_. Správným řešením by bylo, z DNS odebrat AAAA záznamy, konfiguraci a konektivitu serverů opravit a pak AAAA záznamy do DNS vrátit. Jenže k tomu se MSp nemá. A proto přichází různé formy hacků.

Hacky

Využít můžete různé hacky. Např. pan Stanislav Petr z Hostingu 90 filtruje AAAA záznamy pro DNS jména portal.justice.cz a www.justice.cz, takže se klienti s IPv6 k Justici ani nepokoušejí připojit po IPv6. Jenže selektivní filtrování jen některých AAAA záznamů je featura, kterou ve většině rekurzivních DNS serverů nenajdete. Řešení pro nový BIND využívá volby filter-aaaa.

Proto nabízím druhý hack, funkční, pokud máte na routeru systém založený na GNU/Linuxu. Prostě pošlete klientovi TCP reset. V takovém okamžiku i ten nejhloupější Internet Explorer okamžitě přejde na IPv4 spojení! Z pohledu klienta praktické a funkční řešení, z pohledu správce pak řešení, které nejmíň zasahuje do infrastruktury a konfigurace routeru.

TCP reset lze vyřešit jednoduchým pravidlem ve firewallu (zmíním jen řetězec FORWARD, pokud potřebujete řešení pro přístup z lokálního serveru např. kvůli HTTP proxy, stačí místo -A FORWARD zapsat -A OUTPUT, stejně tak můžete v proměnné $WAN nastavit jakékoli rozhraní s přístupem do IPv6 internetu):

ip6tables −A FORWARD −o $WAN −d 2001:af0:ffee:200::/64 −p tcp −j REJECT −−reject-with tcp-reset

Prefix 2001:af0:ffee:200::/64 patří Ministerstvu spravedlnosti a jsou v něm obě IPv6 adresy Justice.cz, a možná i dalších, podobně špatně nastavených serverů. Věřím, že podobně půjdou nastavit i routery od Cisca, Juniperu, Brocade. Pokud podobné řešení na některé z těchto platforem používáte, podělte se o něj prosím v diskusi 🙂

Na závěr bych jen zdůraznil, že problém jsem reportoval loni v červenci po akci World IPv6 Day paní Hatlapatkové z MPO, která k oznamování podobně rozbitých webů státní správy vyzývala, ale nedočkal jsem se žádné reakce. Letos jsem týden před akcí World IPv6 Launch napsal na podatelnu Ministerstva spravedlnosti, ale doteď jsem bez reakce. Zatím posledním krokem tedy bylo zaslání mailu panu Novákovi z MPO, který letos vystoupil na konferenci IPv6 Day pořádané organizací CZ NIC a dalšími. Pan Novák promptně odpověděl, že problém předá MSp a bude trvat na vyřešení.

Jen doufám, že se dočkáme dne, kdy budou existovat weby funkční i bez podobných hacků.

P. S., pokud tohle čte někdo z GTS/MSp, kdo je za nastalou situaci zodpovědný, měl by se nad svým přístupem zamyslet. OK, kdyby to nefungovalo týden, tak nad tím mávnu rukou. Ale dva roky…?

SuperHosting.cz nemá kvalitní IPv6 konektivitu

Společnost SuperHosting (vystupující také pod obchodními názvy SuperNetwork, Peering.cz) je na českém internetu poměrně známá. Jednak službami, které nabízí (primárně server housing, tj. umístění serverů do datového centra a poskytování konektivity pro takové servery), tak i různými kontroverzními aktivitami, které se točí kolem zakladatele SuperHostingu, Zdeňka Cendry. O tom ale článek nebude. SuperHosting, který sám sebe označuje za největšího poskytovatele ob­sahu u nás, od října 2011 nabízí klientům i IPv6 konektivitu. Bohužel, za šest měsíců nebyl SuperHosting schopný navázat kvalitní IPv6 peering alespoň s členy NIX.cz.

Na problém jsem narazil ve chvíli, kdy Jabbim.cz zkušebně spustilo svůj jabber server po IPv6 na adrese ipv6.jabbim.cz. No, posuďte sami, jak vypadá traceroute ze tří různých českých autonomních systémů (všechny peerují v NIX.cz) na IPv6 adresu z rozsahu SuperHostingu:

z AS29134:

# traceroute –6 -I ipv6.jabbim.cz
traceroute to ipv6.jabbim.cz (2a01:28:ca:7­7::50), 30 hops max, 80 byte packets
 1 xxx
 2 xxx
 3 2001:1ab0:7­e1e:d150:8a43:e1ff:fed8:­f57f (2001:1ab0:7e­1e:d150:8a43:e1ff:fed8:f­57f) 2.138 ms 2.064 ms 1.935 ms
 4 2001:1ab0:b0f4::1 (2001:1ab0:b0f4::1) 1.996 ms 2.114 ms 2.103 ms
 5 2001:7f8:14::6e:1 (2001:7f8:14::6e:1) 1.901 ms 2.050 ms 1.905 ms
 6 10gigabitethernet5–2.core1.fra1.he.net (2001:470:0:213::1) 9.848 ms 10.007 ms 9.950 ms
 7 level3.gige-g2–15.core1.fra1­.he.net (2001:470:0:204::2) 10.368 ms 10.104 ms 10.139 ms
 8 vl-4060.car1.Dus­seldorf1.Level3­.net (2001:1900:5:­1::212) 13.607 ms 13.641 ms 13.590 ms
 9 vl-4061.car1.Ber­lin1.Level3.net (2001:1900:5:­1::22e) 24.376 ms 24.581 ms 24.440 ms
10 vl-4041.car1.Pra­gue1.Level3.net (2001:1900:5:­1::2a2) 35.747 ms 35.937 ms 35.738 ms
11 vl-11.car2.Pragu­e1.Level3.net (2001:1900:5:­1::16a) 36.031 ms 35.414 ms 35.485 ms
12 sit-cat65a.superhos­ting.Level3.net (2001:1900:5:­2:2::912) 35.796 ms 35.440 ms 35.613 ms
13 2a01:28:b:1::2 (2a01:28:b:1::2) 36.539 ms 35.522 ms 35.552 ms
14 2a01:28:ca:77::50 (2a01:28:ca:77::50) 35.614 ms 35.460 ms 35.364 ms

z AS29208:

# traceroute –6 -I ipv6.jabbim.cz
traceroute to ipv6.jabbim.cz (2a01:28:ca:7­7::50), 30 hops max, 80 byte packets
 1 xxx
 2 xxx
 3 xxx
 4 xxx
 5 xxx
 6 76sit-te2–4.dialtelecom.cz (2001:4de8:d1­a1:1111:d::2) 7.685 ms 7.706 ms 7.688 ms
 7 76sit-te2–1.dialtelecom.cz (2001:4de8:d1­a1:1111:6::1) 8.040 ms 8.965 ms 8.976 ms
 8 2001:4de8:d­1a1:1111:1f::1 (2001:4de8:d1­a1:1111:1f::1) 8.001 ms 8.928 ms 8.976 ms
 9 2001:7f8:14::6e:1 (2001:7f8:14::6e:1) 7.653 ms 7.118 ms 7.118 ms
10 10gigabitethernet5–2.core1.fra1.he.net (2001:470:0:213::1) 23.861 ms 18.061 ms 18.070 ms
11 level3.gige-g2–15.core1.fra1­.he.net (2001:470:0:204::2) 15.701 ms 13.265 ms 13.256 ms
12 vl-4060.car1.Dus­seldorf1.Level3­.net (2001:1900:5:­1::212) 69.357 ms 69.368 ms 69.379 ms
13 vl-4061.car1.Ber­lin1.Level3.net (2001:1900:5:­1::22e) 135.705 ms 135.714 ms 135.711 ms
14 vl-4041.car1.Pra­gue1.Level3.net (2001:1900:5:­1::2a2) 39.934 ms 40.744 ms 40.801 ms
15 vl-11.car2.Pragu­e1.Level3.net (2001:1900:5:­1::16a) 40.272 ms 40.951 ms 38.308 ms
16 sit-cat65a.superhos­ting.Level3.net (2001:1900:5:­2:2::912) 39.893 ms 39.296 ms 39.761 ms
17 2a01:28:b:1::2 (2a01:28:b:1::2) 39.764 ms 41.321 ms 39.269 ms
18 2a01:28:ca:77::50 (2a01:28:ca:77::50) 38.764 ms 38.800 ms 39.856 ms

z AS43037:

# traceroute –6 -I ipv6.jabbim.cz
traceroute to ipv6.jabbim.cz (2a01:28:ca:7­7::50), 30 hops max, 40 byte packets
 1 xxx
 2 xxx
 3 2001:4de8:b­0ba:deac::1 (2001:4de8:b0­ba:deac::1) 1.723 ms 2.014 ms 2.161 ms
 4 2001:4de8:d­1a1:1111:21::1 (2001:4de8:d1­a1:1111:21::1) 2.057 ms 2.157 ms 2.551 ms
 5 2001:7f8:14::6e:1 (2001:7f8:14::6e:1) 1.598 ms 1.690 ms 1.935 ms
 6 10gigabitethernet5–2.core1.fra1.he.net (2001:470:0:213::1) 21.701 ms 20.876 ms 20.865 ms
 7 level3.gige-g2–15.core1.fra1­.he.net (2001:470:0:204::2) 10.015 ms 9.860 ms 9.896 ms
 8 vl-4060.car1.Dus­seldorf1.Level3­.net (2001:1900:5:­1::212) 13.629 ms 13.770 ms 13.864 ms
 9 vl-4061.car1.Ber­lin1.Level3.net (2001:1900:5:­1::22e) 24.085 ms 24.274 ms 24.364 ms
10 vl-4041.car1.Pra­gue1.Level3.net (2001:1900:5:­1::2a2) 35.238 ms 35.190 ms 35.155 ms
11 vl-11.car2.Pragu­e1.Level3.net (2001:1900:5:­1::16a) 35.035 ms 35.174 ms 35.062 ms
12 sit-cat65a.superhos­ting.Level3.net (2001:1900:5:­2:2::912) 35.246 ms 35.292 ms 35.262 ms
13 2a01:28:b:1::2 (2a01:28:b:1::2) 35.573 ms 35.443 ms 35.414 ms
14 2a01:28:ca:77::50 (2a01:28:ca:77::50) 35.276 ms 35.244 ms 35.214 ms

Od pohledu je jasné, že veškerý provoz jde z uvedených autonomních systémů do NIXu, v NIXu ho přebírá Hurricane Electric (2001:7f8:14:­:6e:1), aby následně vaše pakety prohnal přes Německo, kde peeruje s Level 3 (dodavatel tranzitní konektivity pro SuperHosting). Až pak se data vrací do ČR.

Při zkoumání dostupnosti autonomního systému SuperHostingu to vypadá, že Level 3 je navíc jejich jediný poskytovatel tranzitní IPv6 konektivity. Že taková konfigurace není pro klienty dobrá, o tom není pochyb.

Výsledkem je, že kvalita IPv6 konektivity u SuperHostingu není ani zdaleka srovnatelná s kvalitou IPv4 konektivity. Rozhodně jde o něco, na čem by v SuperHostingu měli pořádně zapracovat, jinak jim takovou službu jejich klienti, kteří to s IPv6 budou myslet vážně, virtuálně omlátí o hlavu.

Jak obstojí webové prohlížeče na rozbitých IPv6 sítích?

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 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 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.

Aktualizováno: O2 a IPv6? Až naprší a uschne

Nemohl jsem si odpustit bulvarizující titulek. K sepsání tohoto miničlánečku mě vybudila reakce zástupců Telefóniky O2 na čtvrteční konferenci Internet a technologie ’09, kde se (mimo jiné) diskutovalo i na téma IPv6. A samozřejmě i to, že nejeden návštěvník tohoto blogu přichází z Google při hledání sousloví O2 a IPv6. Pojďme se tedy podívat, jak na tom náš největší maloobchodní poskytovatel konektivity je…

Ž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).

O náročnosti příprav a implementace IPv6 by mohl vykládat každý správce sítě, ve které protokol nové generace už dnes můžete používat. Rozhodně se to nedá zvládnout za měsíc. Všechny fáze (plánování, identifikace nekompatibilních zařízení, upgrade hardwaru a firmwaru, příprava adresního plánu, konfigurace sítě, testování a pilotní provoz a nakonec provoz komerční) zaberou u menších sítí minimálně několik měsíců, u větších půjde bezpochyby o roky.

Jaký je současný stav?

Telefónica O2 v dnešní době spravuje několik autonomních systémů, minimálně tyto tři:

  • 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

Z těchto tří autonomních systémů pouze jeden oznamuje do světa IPv6 prefix. Jde o autonomní systém 28725 a prefix 2001:41d8::/32. Podle toho se v bývalém Eurotelu s IPv6 experimentovalo – alespoň na té úrovni, že na páteři IPv6 konektivita byla.Bohužel, dnešní stav je tristní. Zatímco dříve měl Eurotel aktivní IPv6 tranzity a tak byla jeho síť dostupná po celém světě, dnes je tento prefix viditelný pouze v českém NIXu.

Proč tomu tak je?

Odpověď je jednoduchá. Telefónica se už pár měsíců snaží zkonsolidovat infrastrukturu Eurotelu a IOLu a postupně ruší všechny peeringy a tranzitní spojení, které bývalý Eurotel měl. Při pohledu do Looking Glass je vidět, že by dnes veškerý IPv6 provoz měl jít přes IP síť a autonomní systém IOLu.

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 (!).

Zmiňovaní pánové taktéž na můj dotaz, proč s tím něco nezkoušejí dělat, odpověděli „a kdo to zaplatí?“ – a já odpovídám: tvrdě to zaplatíte vy, až zbytek světa bude přecházet na IPv6, po IPv6 budou k dispozici služby a klienti ADSL nebudou mít možnost takové služby plnohodnotně využít. Je s podivem, že Telefónica O2 dnes považuje IPv6 za vysoce nadstandardní službu a od svých klientů (nikoli maloobchodních) by chtěli za IPv6 konektivitu připlácet nemalé peníze, zatímco ostatní operátoři (zmiňme Dial Telecom, Sloane, ČD Telematiku a mnohé další) dokáží alespoň na velkoobchodní úrovni IPv6 nabídnout – a bez příplatků (!). Samozřejmě, nelze čekat SLA na stejné úrovni, jako pro IPv4. IPv6 svět není dokonalý, bohužel.

Co s tím?

Zdá se mi, že v Telefónice úspěšně chrápou všichni zodpovědní – technici i manažeři. Zatímco odborníci na konferencích už roky varují před koncem IPv4 světa tak, jak ho známe, varují, že implementovat IPv6 je nutnost, a rok od roku prezentují děsivější grafy s blížícím se koncem dostupných IPv4 adres, Telefónica nedělá vůbec nic. A zřejmě jí to nevadí.

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.

Nedávné změny ve světě IPv6

Ač v září a říjnu byly poznat dozvuky letních měsíců a na poli IPv6 bylo poměrně klidno, rozhodl jsem se vyzobat a zrekapitulovat ty události, které za zmínku stojí. Pojďte si přečíst o zmatcích ohledně IPv6 a NATu, IPv6 jako potenciální hrozbě, o tom, zda má smysl IPv6 v systému vypínat a jak to správně udělat a o mnoho dalších tématech.

V srpnu bylo na poli IPv6 poměrně klidno. Nejen já jsem trávil teplé letní dny spíše u kornoutu zmrzliny a odpočinkem. Během září a října se situace u ostatních mírně zlepšila, u mě však nikoli :-) V zaměstnání jsme měli takříkajíc frmol a tak na aktualizaci nebylo moc času. Pojďme se tedy vrhnout na změny, které by neměly Vašim očím utéct.

NAT a IPv6

Jedním z cílů IPv6 je pokud možno úplné vymýcení (a nezavlečení) překladů adres. Zatím se to daří velmi dobře, až na jednu výjimku. Jediným opravdu plánovaným využitím NATu je překlad mezi IPv6 a IPv4 světem – tedy v přechodovém mechanismu.Z ně­kolika nenápadných zpráv se však v nedávné době rozšířila fáma, že do IPv6 bude implementován NAT v takové podobě, v jaké ho známe dnes – tedy pro skrytí sítě počítačů s tzv. privátními adresami za jednu vnější (často veřejnou, ale ani to v poslední době nemusí být podmínkou) IP adresu. Tak přátelé, zachovejte klid, takhle to nebude. Alespoň doufám, zatím to tak nevypadá.

IPv6 jako bezpečnostní hrozba

Další bomba, kterou vypustili do světa ‚IT odborníci‘, se týká automaticky vytvářených IPv6 tunelů. Pokud máte počítač s rozumně starým operačním systémem (Windows, Linux, …), může se stát, že už dnes váš počítač dokáže využít IPv6 zdroje. K tomu může využít buď tunelovací mechanismus 6to4 (to v případě, že máte přímo na PC veřejnou IP adresu) nebo Teredo (kteréžto je automaticky aktivní pouze v operačních systémech Windows). Až sem jde o vlastnost systému, která možná nemusí být vítaná, ale rozhodně není kritická.

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čí.

Proto pokud se chcete podobnému nebezpečí vyhnout, zkontrolujte, zda váš firewall v počítači podporuje i IPv6, případně zakažte automatické vytváření tunelů.

Zakazování IPv6 protokolu

Mimo zákazu automatického vytváření tunelů může dojít i k situaci, že nemáte aktivní žádný tunel a váš poskytovatel internetového připojení nenabízí nativní IPv6 konektivitu a proto nemáte zájem IPv6 jakkoli v počítači mít. V moderních operačních systémech už však často IPv6 najdete a dokonce je i aktivní. Týká se to zejména Windows Vista, Windows Server 2008, rozumně mladých distribucí Linuxu a dalších *NIXových operačních systémů.

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.

Pokud už však opravdu musíte IPv6 zakázat, udělejte to pořádně, tedy editací systémového registru. Pokud totiž pouze odškrtnete zaškrtávátko před protokolem IPv6 ve vlastnostech síťového adaptéru, mohou vás potkat velké nepříjemnosti, zejména pokud používáte Windows Server 2008, SBS edici.

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

Podle oficiálního blogu ICANN, mezinárodní organizace pro přidělené internetové názvy a čísla, vede v zavádění IPv6 Afrika. Protože takovéto prohlášení od jedné z nejdůležitějších organizací na internetu má velkou váhu, chytla se ho okamžitě média. Ve skutečnosti však jde pouze o relativní čísla, kdy je porovnáván počet IPv6 prefixů a celkový počet čísel autonomních systémů konkrétního regionu.

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.

A tím se dostáváme k dalšímu bodu, kterým je

Nepodpora IPv6 v DSL síti Britského Telecomu

Ano, čtete správně. Když jsem nedávno dělal miniprůzkum mezi našimi ADSL operátory, nikdo z nich nebyl schopen IPv6 nabídnout ani odhadnout, kdy jej nabízet budou. Alespoň u nás bez problémů fungují různé 6to4, 6in4 a další tunelovací mechanismy.Ve Velké Británii jsou na tom uživatelé hůře. Nejen že jim operátoři (až na výjimky) IPv6 nedokážou nabídnout, ale dokonce nová síť (honosně nazvaná „21CN, Síť dvacátého prvního století“) tamního dominantního operátora, Britského Telecomu, oficiálně protokol IPv6 nepodporuje. To mimo jiné znamená, že Britský Telecom není schopen zaručit, že skrz jeho síť projdou v pořádku pakety, které mají co do činění s IPv6. A to jak nativním, tak tunelovaným.

A co kabeloví operátoři

Kabeloví operátoři jsou na tom o něco lépe, i když ani oni nemají na růžích ustláno. Podporu IPv6 v kabelových sítích oficiálně doplňuje totiž až standard DOCSIS 3.0. Migrace na nový standard si ovšem vyžádá nákladný upgrade síťového hardware na různých úrovních, od centrálních řídících prvků sítě až po koncové modemy. Vezmeme-li v potaz, že čeští operátoři mnohde pracují ještě s verzí (Euro)DOCSIS 1.0, není důvod migrovat na verzi 2.0, aby posléze při vyčerpání IPv4 adres migrovali na  verzi 3.0.

Hybatelé pokroku

Mezi hybatele pokroku můžeme jednoznačně zařadit aplikace, které uživatele motivují k zavádění IPv6 a tlačení na své poskytovatele, aby pokud možno poskytovali nativní IPv6 konektivitu. Mezi tyto hybatele můžeme zařadit např. webové služby či torrenty.

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.

Právě torrenty mohou být – pokud IPv6 implementuje i některý z velkých populárních torrent trackerů – dost velkým hybatelem. Jakožto peer-to-peer síť totiž naplno využijí možnosti přímé komunikace mezi dvěma IPv6 uzly, která v IPv4 kvůli všemožným NATům silně pokulhává.

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

Mnozí uživatelé produktů Microsoftu, kteří jsou zároveň zastánci IPv6 protokolu, zajisté dlouho vyhlíželi možnost využití IPv6 v operačním systému i v poštovním serveru Exchange. Po dlouhé době se konečně dočkali, první servisní balíček pro Microsoft Exchange 2007 konečně přidává rozumnou podporu IPv6. Ovšem pozor, to vše pouze na Windows Serveru 2008, pokud jste tedy uvažovali o tom, že budete používat Exchange 2007 na Windows Serveru 2003, IPv6 nebudete moci využít.I zde ale platí: pokud IPv6 naopak využívat nechcete, nezakazujte bezhlavě IPv6 ve vlastnostech síťového připojení.

Pavel Satrapa – IPv6, druhé vydání

Pokud jste hledali česky psané tištěné zdroje o IPv6, určitě vám neunikla kniha pana Pavla Satrapy, která je nazvaná prostě IPv6. Její první vydání z roku 2002 však už nekoupíte a její obsah taktéž není v některých částech aktuální.

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.

A jedna perlička: pan Satrapa v knize uvádní i adresu tohoto blogu jako jednoho z nejaktuálnějších míst na českém internetu, kde lze najít informace k IPv6. Pane Satrapo, děkuji!

Síťové programování a IPv6

Mezi mnoha Google Alerty mi na téma IPv6 přistál v e-mailové schránce i odkaz na zajímavou knihu o programování v IPv6 sítích.

IPv6 novinky v zemích Českých

A na konec jsem si nechal novinky, které se týkají IPv6 v zemích Českých. Není toho moc, vlastně jen jedna. Na začátku září obdržela IPv6 prefix společnost STARNET, s.r.o., která nabízí své služby v jižních Čechách. Ať už si prefix pořizují z nějakého konkrétního důvodu nebo jen pro testování, oznamují jej do globálních směrovacích tabulek již od třicátého září, čímž předbíhají většinu „velkých poskytovatelů.“

IPv6 sotva dělá setinu procenta internetového provozu

Podle Studie o průběhu implementace IPv6 činil loni IPv6 provoz ve špičce „zhruba setinu procenta všeho internetového provozu“, což se ze statistického pohledu „zhruba blíží množství nečistot, které ještě může obsahovat voda, aby byla označena za pitnou.“ Více než deset let od započetí migrace je to nepochybně ostuda. A situace se zřejmě nebude o mnoho zlepšovat. Ač já sám věřím, že Windows Vista bude jedním z hybatelů přechodu na IPv6, pořád jsou zde problémy s implementací IPv6 stacku. Asi mám štěstí (nebo protokol využívám tak málo), ale všechny mnou používané Visty fungují s IPv6 spolehlivě…

Seznam.cz testuje IPv6

Období letních prázdnin a dovolených není zrovna dobou, ve které bychom mohli očekávat významené změny na poli IPv6. Oproti nedávno zveřejněné tabulce IPv6 alokací se skoro nic nezměnilo – ti, kdo už konektivitu měli, ji mají stále, většina nováčků si dává v létě oddech. NetAir zprovoznil IPv6 tranzit a jeho IPv6 síť je tedy už dostupná ze světa (využívají konektivitu od Casablanky INT). A také Seznam.cz začíná pomaloučku testovat IPv6. Partnerem Seznamu je jeho dlouholetý poskytovatel tranzitní konektivity, firma Dial Telecom (dříve to byl Net4Net s původním názvem TransgasNet, kterého Dial Telecom pohltil zhruba před rokem).

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.

A teď tedy konkrétní adresy služeb:

A ještě jednou: jde o test. Nejde o produkční prostředí. Buďte prosím shovívaví :-)

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

ADSL a IPv6

Po obecném přehledu společností, které působí v ČR a mohly by umět poskytovat IPv6 konektivitu, jsem se vrhl na zjišťování, zda je někdo vůbec schopen poskytnout IPv6 na ADSL, tedy dnes pravděpodobně nejrozšířenějším typu připojení. A výsledek? Posuďte sami.

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í.

Rozhodl jsem se ale oslovit ty největší:

  • 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

Jde o jedenáct poskytovatelů, někteří se orientují převážně na firemní klientelu, někteří na domácnosti. Všem jsem na kontaktní e-maily technické podpory rozeslal následující e-mail (příp. jsem ten samý text zaslal přes webový formulář v kontaktních sekcích):

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ěď.

Zároveň jsem se rozhodl monitorovat rychlost odezvy – čistě ze zajímavosti. Dotazy jsem rozesílal v neděli odpoledne a nečekal jsem, že by někdo odpověděl. To ostatně ani nemám nikomu za zlé. Rozhodl jsem se tedy počítat rychlost odezvy od pondělních osmi hodin ráno.

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.

A ti ostatní? Ani po dvou pracovních dnech se nenamáhali napsat jedinou odpověď. Takže podpora IPv6 u nich zůstává neznámá.

PODCAST: Nevyčkávejte se zavedením IPv6

Zřejmě nadchází ten pravý čas a myšlenky na implementaci protokolu IPv6 do sítí a služeb provozovaných významnými hráči by měly být na pořadu dne. A to i pro společnosti, které v minulosti získaly velké rozsahy IPv4 adres a dnes je do změny nic netlačí. „To, že dnes máte adres dostatek a nebolí vás zaplatit něco navíc na upgrade vašich NATů, neznamená, že se vám potřeba implementace IPv6 vyhne,“ říká Chip Popoviciu, vedoucí technického oddělení společnosti Cisco a autor publikace „Strategie globálního přechodu na IPv6“. „Přechod na IPv6 by neměly doprovázet otázky jako ‚Co tím získáme‘, ale spíše ‚Co ztratíme, když nepřejdeme‘.“

Zmiňovaný podcast rozebírá možnosti, jaké mohou nastat, pokud společnosti budou i dále přehlížet IPv6 – ztráty partnerství, obtížnou implementaci nových technologií, atd.

Nejlepší strategie přechodu na IPv6 podle pana Popoviciu je postupná: nejprve (a to nejlépe nyní) je vhodné přechod pečlivě naplánovat, poté postupně zavádět IPv6 do jednotlivých částí sítí a nakonec na IPv6 zprovoznit i služby. „Nebude to hotové lusknutím prstu. Největším problémem nejsou datové sítě, ale různé firemní zásady, kompatibilita služeb a aplikací. Pokud začnete s integrací včas, můžete se věnovat kvalitnímu plánování strategie přechodu a pečlivé integraci.“

Zároveň varuje, že společnostem, které upgrade sítě odloží na neurčito, později vyletí náklady raketově vzhůru. Dnes lze plánování přechodu spojit s procesem pravidelné obměny hardware. Zároveň s tím lze zaměstnancům poskytnout potřebné kursy, aby přechod na IPv6 společnost zvládla s minimálními dodatečnými náklady.

Společnosti s působností po celém světě by měly obzvláště zvážit svou strategii přechodu – právě ty totiž pravděpodobně brzy narazí na rychlou adaptaci IPv6 v některých částech světa, zejména v Asii.

Pokud vládnete angličtinou, určitě neváhejte a podcast si poslechněte.

Via techtarget.com.au

Historie protokolu IP

V posledních měsících probíhá všemi více či méně odbornými weby nejeden článek skloňující pojem IPv6. V tomto článku bych chtěl shrnout, co to vlastně IPv6 je a proč je důležité.

K pochopení IPv6 je potřeba zabrousit o pár desítek let zpět do doby, kdy byl Internet v plenkách. V roce 1974 publikovali Vinton Cerf a Robert Kahn dokument, který popisoval protokol pro přenos dat. Z tohoto protokolu se během dalších pár let vyvinul protokol IPv4 – RFC, které jej popisuje, bylo vydáno v roce 1981. IPv4 popisuje způsoby, jak mají jednotlivé počítače propojené do sítě navzájem komunikovat.

IPv4 adresa vypadá tak, že každý bajt zapíšeme jako desítkové číslo a oddělíme je tečkou, tedy např.: 10.80.55.19

Protokol IPv4 byl navržen tak, že pro adresy odesilatele i příjemce používá čtyři bajty, tedy 32 bitů. V ideálním případě by tedy bylo možné do sítě připojit až 232 počítačů, tedy téměř čtyři a čtvrt miliardy. Jenže na konci sedmdesátých let nikdo s tak ohromným počtem počítačů nepočítal. V té době se počty připojených uzlů pohybovaly ve stovkách a počty „zasíťovaných“ organizací bylo možné spočítat na prstech několika rukou. Pracovní skupina, která spravovala IPv4 adresy, tehdy vymyslela poměrně jednoduchý způsob přidělování celých bloků adres jednotlivým organizacím. Zjednodušeně dostala každá organizace blok 16777216 IP adres a co si s nimi dělala, to už bylo jen na ní. Těchto rozsahů bylo k dispozici celkem 256, tedy pro max. 256 organizací (ve skutečnosti méně, protože část rozsahu byla vyhrazena pro speciální účely).

Jak internet rostl a připojených sítí a počítačů přibývalo, bylo nutné ustanovit nový způsob přidělování adres. I bylo stanoveno přerozdělit adresní rozsah a začít používat tzv. masku sítě. První polovina IPv4 adresního rozsahu zůstala nadefinovaná „postaru“ a ti, kdo již měli přidělen blok 16777216 IPv4 adres, o něj nepřišli, i když jej nevyužívali efektivně. Adresní prostor byl rozdělen na tzv. třídy:

  • Třída A, obsahovala 16777216 IPv4 adres (používala se pro adresy 0.0.0.0/8 – 127.255.255.255/8)
  • Třída B, obsahovala 65536 IPv4 adres (128.0.0.0/16 – 191.255.255.255/16)
  • Třída C, obsahovala 256 IPv4 adres (192.0.0.0/256 – 223.255.255.255/256)
  • Třída D byla vyhrazena pro Multicast (224.0.0.0 – 239.255.255.255)
  • Třída E byla označena jako rezervována do budoucna a nesměla být nikde využita (240.0.0.0 – 255.255.255.255)

Maska sítě je to, co v příkladech uvádím za lomítkem, a určuje, kolik bitů z celkových 32 určuje adresu sítě. Například pro IP adresu 10.80.25.18/8 je adresa sítě určena prvními osmi bity a v síti může být až 2(32–8)počítačů. Podobně do sítě 192.168.1.0/24 lze zapojit až 256 počítačů. (Ve skutečnosti je vždy nejnižší a nejvyšší adresa vyhrazena pro tzv. adresu sítě a broadcast adresu, takže počítačů lze zapojit o dva méně.) Některé operační systémy preferují zápis masky jako 255.0.0.0 pro /8 či 255.255.255.0 pro /24. Technicky jsou tyto zápisy ekvivalentní, ale například systém Windows si s „kratším“ zápisem /8 neporadí.

O pár let později se však ukázalo, že ani toto řešení nevyhovuje – mnohé organizace potřebovaly více než 256 adres, ale mnohem méně, než 65536 adres, tudíž žádaly o více bloků C. Obecně docházelo k nepříjemnému plýtvání adres. I bylo stanoveno, že bude tento systém zrušen a bude zavedeno tzv. beztřídní (classless) rozdělování adres. To umožnilo použít i jiné masky sítě, než jen /8, /16 a /24 a zefektivnilo přidělování IPv4 adres organizacím.

Zlo však již bylo dokonáno. Mnohé organizace si z minulosti nesou břímě obrovských IPv4 rozsahů, které nevyužívají naplno, ale vrátit je nemohou – musely by přečíslovávat své sítě. To by stálo stamiliony dolarů (naprostá většina organizací s velkými adresními bloky je ze Spojených států).

Ačkoli se loď s názvem IPv4 již začala potápět a svět zaplavovaly různě odvážné prognózy o nadcházejícím internetovém armageddonu (tedy vyčerpání dostupných IPv4 adres), objevila se technologie, která měla pomoci soudný den maximálně oddálit do doby, kdy bude nalezeno alternativní řešení problému. Tato technologie se jmenuje Network Address Translation, zkráceně NAT, česky se překládá jako „překlad adres“.

Už mnoho let totiž byly vyhrazeny tzv. privátní IPv4 adresní rozsahy (10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16), jejichž smyslem bylo využívat je v rámci interních sítí společností. Tyto adresy se nikdy nesměly objevit v globálním internetu. A právě toho využívá překlad adres. Organizaci stačí jedna jediná „veřejná“ IP adresa a všechny počítače v rámci vnitřní sítě za tuto adresu schová. O každém spojení zevnitř ven si uchovává záznam ve stavové tabulce a podle ní pak ví, která odpověď z internetu má být nasměrována na který počítač. (Režimů překladu adres existuje více, toto je však ten nejčastěji používaný a nejvíce zlý stav, protože umožňuje navázání komunikace jen jedním směrem, z vnitřní sítě do internetu. Opačně to nelze, při pokusu o spojení z internetu do vnitřní sítě nemá odesilatel možnost říci, kterému počítači ve vnitřní síti chce paket doručit.)

Ani překlad adres však nezastavil úbytek volných IPv4 adres a podle realistických odhadů a studií dojde k vyčerpání dostupných adres mezi roky 2011 až 2020.

A protože první z těchto roků je již poměrně blízko, začínají mnozí síťaři bít na poplach.

V dalším díle se podíváme na to, jak jsou na tom s IPv6 české společnosti.