Category: Sítě

Pomalé IPv6 tunely s modemem Compal od UPC/Vodafone

Kabelová síť Vodafone (dříve UPC) je druhá největší přístupová síť v ČR, hned po telefonní/DSL síti CETINu. Pokud na ní ale chcete využívat vlastní veřejnou IPv4 adresu, nedostanete se k nativní IPv6 konektivitě – tu nabízí jen režim DS-Lite, při kterém jste za operátorským CG-NATem. Nezbývá vám tedy jiná možnost než používat IPv6 tunely (např. od Hurricane Electric). Na prémiovém modemu Compal ale nikdy nedosáhnete rychlosti větší než cca. 20 Mbps.

O tomto problému se vlastně neví (nebo nahlas nemluví), ale přesto existuje. UPC nabízí linky s velkou rychlostí (např. nejvyšší tarif pro podnikatele a firmy je 500/50 Mbps, pro domácnosti 500/30 Mbps), a služby touto rychlostí obvykle běží – alespoň pokud se bavíme o protokolech TCP a UDP s využitím nativního routování v Compalu.

Co je vlastně prémiový modem Compal zač? Je to vlastně router Compal CH7465LG s chipsetem Intel Puma 6 s podporou EuroDOCSIS 3.0 (24×8, tj. schopen sdružit až 24 kanálů pro stahování a 8 kanálů pro odesílání), Wi-Fi 802.11ac, gigabitovými porty, telefonními porty (modem funguje jako jednoduchá gateway, kdy se klasický telefon připojí do telefonní zdířky a provoz je převeden do SIP/RTP). S modemem je reálné dosahovat i maximální rychlosti u nejvyšších nabízených tarifů (500/50 Mbps).

Compal můžete provozovat ve třech režimech:

  • Router v režimu nativní IPv6 s DS-Lite přístup k IPv4 síti (Compal funguje jako B4, tj. balí IPv4 provoz do IPv6 a posílá ho na AFTR gateway u operátora, kde je vybalen, zNATován a poslán do IPv4 světa)
  • Router v režimu nativní IPv4 (bez IPv6)
  • Bridge v režimu nativní IPv4 (bez IPv6)

Režim bridge je oblíbený u pokročilých uživatelů, protože ti tak mohou využít přidělenou veřejnou IPv4 adresu na svém routeru za Compalem. Ti nejpokročilejší uživatelé ale zároveň chtějí IPv6 – a to znamená použít tunelování IPv6 po IPv4.

Pokud pomineme tunelování pomocí Wireguardu nebo OpenVPN, nejdostupnější a nejčastěji používaná tunelovací služba je tunnelbroker.net od Hurricane Electric. Ta využívá protokol 6in4, tj. IP protokol 41, který technicky vzato leží a běží “vedle” TCP (IP protokol 6), UDP (IP protokol 17) či ICMP (IP protokol 1). Pokud vás zajímají další IP protokoly, jejich seznam naleznete na wikipedii.

Jak takový tunelovaný provoz vypadá? Inu, hned za IPv4 hlavičkou následuje IPv6 hlavička s kompletními daty.

11:48:31.464451 IP 213.220.x.x > 216.66.86.122: IP6 2001:470:6e:558::2.56534 > 2001:1488:ffff::63.80: Flags [.], ack 1303808, win 5748, options [nop,nop,TS val 3891015891 ecr 3911340140], length 0
11:48:31.464561 IP 216.66.86.122 > 213.220.x.x: IP6 2001:1488:ffff::63.80 > 2001:470:6e:558::2.56534: Flags [.], seq 1303808:1305216, ack 1, win 232, options [nop,nop,TS val 3911340141 ecr 3891015833], length 1408: HTTP

Bohužel v síti UPC s routerem Compal dochází k omezování provozu IP protokolu 41 na zhruba 20 Mbps v součtu (tj. download + upload). Zdá se, že jde o problém právě/pouze na Compalu, protože s čistým modemem Ubee EVM3206 k omezování nedochází (ověřeno v červnu 2020). A jelikož je ovlivněn veškerý provoz na IP protokolu 41 a ne konkrétní tunelovací server, nelze problém vyřešit např. výměnou tunelovacího serveru za jiný. Zároveň jde o problém roky ne(vy)řešený – kvůli němu jsem v červnu 2017 přecházel na DS-Lite, protože jen tak jsem byl schopen využít svou přípojku naplno. A to důležité: problém se projevuje i když máte Compal v režimu bridge.

Zmínka o pomalosti z dubna 2018.

Jak přesně se tedy omezení projevuje? Pokud začnete přenášet data po IPv6 skrze tunelované připojení, brzy si všimnete, že je rychlost opravdu hodně nízká (v porovnání s IPv4).

Stahování po IPv6 skrze tunnelbroker.net
Aktuální rychlost stahování po 6in4 (všimněte si řádku Other IP, to je tunelovací provoz).

Pokud zároveň začnete stahovat i odesílat data, je vidět zastropování na 20 Mbps.

Celková rychlost se drží pod 20 Mbps (řádka Total rates).

A protože IPv6 je často preferovaným protokolem, na stažení většího množství dat čekáte opravdu dlouho.

Když se naopak rozhodnete odesílat, rychlost odesílání po IPv6 je opět maximálně 20 Mbps (pokud to váš tarif umožňuje). Při odesílání po IPv4 je ale kapacita linky využita naplno (v tomto případě 50 Mbps).

Odesílání po IPv6, rychlost pod 15 Mbps.
Odesílání po IPv4 a plně saturovaný upstream (50 Mbps).

Jak problém reprodukovat? Je to vlastně prosté, potřebujete jen Linuxový stroj připojený přímo k Compalu v režimu bridge a dále účet na tunnelbroker.net. Na tunnelbroker.net požádáte o tunel a ten nakonfigurujete na Linuxovém stroji. Na tunnelbroker.net pak pokračujte do detailu tunelu a na záložce Example Configuration zvolte Linux-route2. To vám vygeneruje ukázkovou konfiguraci pro běžný stroj s Linuxem, která vypadá zhruba takto.

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.86.122 local 213.220.x.x ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:6e:558::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

Pak budete mít funkční IPv6 konektivitu a můžete začít testovat, jestli problém stále existuje.

Zdá se, že se Vodafone po akvizici chytil, a problém začal řešit. Tak mu držme palce.

Napájíme VDSL modem Nokia F-010G-B pomocí PoE

Po nedávném zprovoznění remote DSLAMu v obci, kde mám jednu DSL přípojku, se mi podařilo domluvit upgrade na nejvyšší rychlostní profil, který dnes CETIN nabízí. Protože ale u nejvyššího profilu zároveň záleží doslova na každém metru kabelu mezi modemem a DSLAMem (s každým metrem se zvyšuje útlum vedení a snižuje dosažitelná rychlost DSL spojení), nebylo úplně vhodné přesouvat modem o 60 metrů dál do domovního datového rozvaděče. Zároveň jsem ale dospěl k rozhodnutí, že chci napájení modemu zálohovat – a nechci pro něj kupovat samostatnou UPS. Jak tohle všechno skloubit? Řešením je Power over Ethernet!

Pro nejvyšší DSL profil se u nás nabízí zatím jen několik modemů. O2 Smartbox (neumí bridge), Asus DSL-AC87VG (bohužel na něm nefunguje bridge), Zyxel VMG8823 (nemám reference) a několik měsíců byl u 365internet.cz k dostání i modem Nokia F-010G-B (umí i G.fast, a nakonec je ze všech uvedených modemů nejlevnější, ale bohužel už není dostupný).

Pořídil jsem Nokia F-010G-B ještě v době, kdy se koupit dal. Ve správnou chvíli (po migraci na remote DSLAM a VDSL, protože Nokia nepodporuje ADSL) jsem se rozhodl zprovoznit PoE. Jenže – ouha! Zatímco u běžných (vybavenějších) síťových zařízení většinou máte možnost napájet zařízení pomocí PoE přímo, DSL modemy obvykle PoE nepodporují. Alternativou je pořízení vhodného PoE splitteru, do kterého přivedete ethernetový kabel ze switche a z něj vyvedete ethernetový kabel k zapojení do datové zásuvky modemu a k tomu kabel pro napájení.

S Nokií se ovšem objevil zádrhel – zatímco běžné modemy a síťová zařízení používají nejčastěji napájecí napětí 12V s maximálním proudem 1A a tzv. barrel konektor o průměru 2,1 (vnitřní) resp. 5,5 mm (vnější), Nokia (a nejspíš i Alcatel Lucent, od kterého Nokia síťovou divizi odkoupila) používá speciální konektor.

Napájecí konektor na CPE ALU/Nokia
Napájecí konektor na CPE ALU/Nokia

Po intenzivním hledání se mi podařilo najít příspěvek na novozélandském fóru, podle kterého mělo jít o konektor Molex Micro-Fit 43025-0800 a kontakty Molex Micro-Fit 43030-0001. Jak jsem později zjistil, použít lze i kontakty 43030-0007 (liší se pouze balením, 0007 se dodávají v sáčku, 0001 na odstřihávací pásce; existují i další varianty, včetně pozlacených kontaktů – pro zájemce má GME u sebe datasheet).

Molex Micro-Fit 43025-0800
Molex Micro-Fit 43025-0800

Kontakt Molex 43030
Kontakt Molex 43030

Nastalo tedy hledání dodavatele – bohužel se nejedná o běžně dostupné zboží, nakonec jsem uspěl u Farnellu s konektorem (Molex 43025-0800) a u GME s kontakty (Molex 43030-0007).

Ještě bylo třeba vybrat vhodný PoE splitter – šel jsem cestou nejmenšího odporu a vybral TP-Link TL-PoE10R, který má přepínatelné výstupní napětí a podporuje i 12V/1A. To přesně souhlasí se specifikací na zdroji od modemu. Splitter překvapil jen tím, že bez zátěže na napájecím konektoru střídavě každou sekundu zapíná a vypíná napájecí výstup. Při připojení zátěže se tento problém neprojevuje a vše funguje tak, jak má. Splitter má na výstupu napájení  již zmiňovaný barrel konektor. Ke splitteru je pak dodáván i cca. 30 cm kabel, který má na obou stranách barrel konektor. Ten se mi ale nechtělo zbytečně kuchat, takže jsem pořídil další kabel v GESu, na jehož konec jsem nakrimpoval kontakty Molex 43030.

Zbývalo kontakty s nakrimpovaným kabelem vsunout do konektoru – k tomu je vhodné znát rozložení kontaktů na konektoru. To je naštěstí jednoduché, z osmi zdířek jsou zapojené jen dvě, poskytující “+” a “-“. Při pohledu zepředu je zapojení takovéto:

    +---+---+    
+---+---+---+---+
| - |   |   |   |
+---+---+---+---+
| + |   |   |   |
+---+---+---+---+

Následovalo zapojení napájecího konektoru do modemu a první zapnutí. K mému překvapení vše začalo ihned fungovat – switch vidí, že je připojeno PoE zařízení, začne splitter napájet, ten obratem napájí modem. Síť se spojila gigabitovou rychlostí. Switch hlásí odběr cca. 7 W ze 16 W alokovaných, PoE splitter běží v režimu 802.3af.

Délka ethernetového kabelu je cca. 60 metrů. Spojení se zdá být stabilní, modem se nerestartuje. Jestli by toto zapojení zvládlo napájet i G.fast FTTdp jednotku pomocí technologie Reverse power feeding není úplně jasné, ale protože u nás G.fast nemáme, nemusí nás to zatím trápit. 🙂

Pokud vás zajímá nákladová stránka, nebude to hezké počtení. Kombinace více dodavatelů s různým poštovným zvedla cenu řešení o necelých 250 Kč na celkových téměř 700 Kč.

ProduktCena
Molex 43025-0800 (10 ks, Farnell)228,30 Kč vč. poštovného a deseti kontaktů, které zatím nedorazily
Molex 43030-0007 (20 ks, GME)40 Kč + 110 Kč poštovné
Kabel ke splitteru s barrelem (GME, 1 ks)37,90 Kč
PoE splitter TL-PoE10R (CzC)282 Kč
Modem Nokia F-010G-BK nezaplacení 🙂

V případě, že budete chtít pomocí PoE napájet zařízení se standardním kulatým konektorem, budete mít napájení pomocí PoE mnohem jednodušší (a levnější), budete totiž potřebovat jen PoE splitter a UTP patch kabel. Na závěr ještě přidávám fotografii neuměle naaranžovaného modemu s PoE splitterem.

Nokia F-010G-B napájený pomocí PoE
Nokia F-010G-B napájený pomocí PoE

Proč u nás nikdy nebude 3G pokrytí jako ve Francii

K českým mobilním operátorům často směřují výtky na 3G pokrytí. I když se totiž dnes díky sdílení sítí Telefóniky a T-Mobilu dostalo 3G i do malých měst a velkých vesnic, často signál mizí hned jak vstoupíte do budovy. Kritika tedy je oprávněná – 3G se sice rozšířilo, ale jeho použitelnost je místy opravdu špatná. Kritici nám za vzor často ukazují Francii, ale nejen tu, kde mají operátoři 3G síť s nesrovnatelně lepším pokrytím. Příčiny si rozebereme a vysvětlíme, proč už to u nás lepší nebude.

UMTS sítě a používané frekvence

Každá UMTS síť využívá jednu nebo víc tzv. nosných frekvencí o šířce 5 MHz. UMTS základnová stanice i mobilní telefon (terminál) se naladí na nosnou frekvenci a na ní pak spolu komunikují.

Technologie jako taková dokáže pracovat v různých frekvenčních pásmech, pokud tam pro ni existuje použitelný souvislý 5 MHz blok frekvencí. V počátcích bylo pro evropské UMTS sítě vyhrazeno duplexních 2×60 MHz v pásmu 2,1 GHz. Do tohoto pásma se tedy vejde celkem dvanáct nosných frekvencí. U nás tyto frekvence mají rovnoměrně rozděleni tři stávající operátoři, každý po čtyřech nosných (20 MHz), naplno je využívá zatím pouze T-Mobile.

Nevýhoda pásma 2,1 GHz je ale špatné prostupování do budov a převážně přímočaré šíření signálu – to vede ke zmiňovaným problémům s 3G v oblastech, kde je jen jedna 3G základnová stanice na vesnici s komplikovaným terénem.

Protože si operátoři sdružení v projektu 3GPP byli tohoto problému již dávno vědomi, prosadili do UMTS standardu verze 7.2.0 (3GPP R7) možnost používat pásmo 900 MHz, ve kterém již nějaký pátek v Evropě (ale i jinde) běží GSM sítě. Tato verze standardu vyšla už v prosinci 2005, tedy téměř před sedmi lety.

Nasazení UMTS v pásmu 900 MHz by operátorům mohlo pomoci vyřešit problém špatného šíření 3G signálu a vyhnout se nutné výstavbě velkého množství základnových stanic pro docílení rozumného pokrytí.

Použitelnost pásma 900 MHz pro UMTS

Využití UMTS 900 bránilo během let mnoho různých překážek. Zejména jde o fragmentaci spektra, legislativní překážky a nedostatek kompatibilního hardwaru.

Fragmentace a refarming spektra

Tou největší překážkou byla bezesporu fragmentace spektra: zatímco v UMTS 2,1 GHz pásmu byly v souladu se standardem operátorům již od začátku přidělovány souvislé 5 MHz bloky, 900 MHz pásmo bylo původně vyhrazeno pro GSM a již od počátku bylo děleno po úsecích dlouhých 0,2 MHz. E-GSM (rozšířené GSM) má takových úseků 60+125, P-GSM (podmnožina E-GSM) jen 125.

Z historických důvodů národní regulátoři přidělovali bloky „napřeskáčku“. Jak to dnes vypadá u nás, se můžete podívat na GSMwebu. V některých zahraničních zemích bloky byly operátorům přiděleny jako souvislé již na počátku, nebo v čase proběhl tzv. refarming frekvencí.

Refarming je proces, kdy dojde k přeskládání kanálů v GSM pásmu tak, aby každý operátor obdržel souvislý blok frekvencí o určité šířce. Takto přeskládané 900 MHz pásmo pak umožňuje snazší implementaci nových technologií, jako například právě UMTS v 900 MHz pásmu, nebo v budoucnosti LTE Advanced (složené z pásem 800 MHz, 900 MHz, 1800 MHz, 2100 MHz a 2600 MHz).

Jednou z dalších překážek refarmingu bylo i to, že se u nás část GSM pásma (60 E-GSM kanálů) uvolnila až v roce 2009. Přidělení těchto kanálů proběhlo losováním (vizte zprávu o přidělení těchto frekvencí) a nebylo podmíněno refarmingem pásma. Nově přidělované GSM kanály tedy nebyly připojeny k existujícím přídělům. Účelné využití pásma (s výhledem na budoucí aplikace) nebylo zajištěno.

Otázkou zůstává podpora E-GSM části pásma v GSM základnových stanicích. Je klidně možné, že toto pásmo například Vodafone kvůli zastaralému Siemens hardwaru nemohl použít – a tudíž by ani refarming GSM pásma nebyl možný. Zatímco O2 a T-Mobile mají od roku 2010 GSM síť na novém hardware, Vodafone s výměnou starého hardwaru začal až letos na jaře a obměna bude probíhat až do roku 2015.

V zahraničí refarming proběhl, zatímco u nás regulátor (jak je jeho zvykem) vyčkává na vzájemnou dohodu komerčních subjektů (operátorů). Spektrum zůstává nespojité a implementace UMTS 900 je nemožná.

Vodafone by přitom v případě proběhlého refarmingu mohl využít 5 MHz pro UMTS (jedna nosná) a 5 MHz pro GSM (25 kanálů), T-Mobile a O2 by mohly využít 5 MHz pro UMTS (jedna nosná pro každého) a 7,4 MHz pro GSM (37 kanálů).

Legislativní překážky

Zatímco technologická standardizace UMTS 900 proběhla již v roce 2005, legislativní standardizace byla ponechána v rukou národních regulátorů a na dohodě komerčních subjektů (operátorů). Toho si všimla Evropská unie, když v roce 2009 vydala direktivu, kterou nařizuje neutralizovat 900 MHz pásmo. Do té doby totiž v tomto pásmu nebyl povolen provoz jiné technologie, než GSM.

Členským státům direktiva doporučuje implementaci technologické neutrality 900 MHz pásma do národních právních řádů. Termín pro takovou implementaci vypršel 9. května 2010, u nás se ČTÚ rozhoupal včas a UMTS v pásmu 900 MHz umožnil změnou plánu využití rádiového spektra v prosinci 2009 (diskuse o změně tohoto plánu ukazuje, že o UMTS v 900 MHz nejspíš uvažoval Vodafone).

Poslední legislativní překážkou byla nutnost zažádat o změnu přídělu (licence k využívání) rádiových kmitočtů. Doposud totiž kmitočty v pásmech 900 a 1800 MHz byly na základě licence přiděleny pro využívání služeb založených na technologii GSM. Nově jsou frekvence tzv. technologicky neutrální, je na nich tedy možné provozovat jakoukoli technologii (GSM, UMTS, LTE), pokud tato nezpůsobuje rušení ostatních provozovaných technologií. O takovou změnu si společnosti Telefónica (1 a 2) a T-Mobile (1 a 2) požály až v dubnu 2012 a Vodafone v srpnu 2012 (1 a 2). Bohužel žádost na ČTÚ nepřistála kvůli UMTS 900, hybatelem byla možnost nasadit LTE na 1800 MHz.

Nedostatek kompatibilního hardwaru

Aby bylo možné zavádět UMTS v 900 MHz, je nutné v určitých oblastech omezit síť GSM – proto jsou dnes ve Francii oblasti, kde někteří operátoři mají pouze UMTS 900 a nikoli GSM. To ale nevadí, pokud je na trhu dostatek mobilních telefonů s podporou GSM i UMTS 900.

Dal jsem si tu práci a z katalogu Mobilmanie zjistil statistiku uváděných mobilů (pouze modely s podporou 3G): první mobily s podporou UMTS 900 se začaly objevovat v únoru 2008(Nokie N96, 3120 classic, 6220 classic, N78, 6210 Navigator).

Zatímco v roce 2008 podporovalo UMTS 900 pouze 21 z 86 uvedených 3G mobilů, v roce 2009 se poměr obrátil (74 ze 103 3G mobilů), rok 2010 přinesl 74 3G mobilů s UMTS 900 a 18 bez. V roce 2011 se objevilo 90 3G mobilů s UMTS 900 a 11 jen s klasickým UMTS na 2,1 GHz. Všechny UMTS 900 mobily pak podporují i klasické 2,1 GHz UMTS.

V roce 2012 podle katalogu Mobilmanie má podporu UMTS 900 už konečně kaž­dý uvedený mobil.

Z oblíbených zařízení má podporu iPhone 4 a novější (uveden v roce 2010), většina mobilů od Samsungu uvedených od roku 2009 do dneška, téměř všechny HTC uvedené od roku 2008 (kromě modelů Smart a Gratia), téměř všechny Nokie uvedené od roku 2008 (z populárních chybí E51 a N95, které jsou ale z roku 2007), a další.

Na nedostatek mobilů si tedy operátoři stěžovat nemohou, zvlášť ne ve chvíli, kdy UMTS mimo velká města začali zavádět až v roce 2011. Stejně tak se neobávám, že by výrobci 3G základnových stanic (Node B) nebyli schopni v roce 2011 dodávat hardware a software pro UMTS 900.

Promarněná šance – sdílení sítí

Protože výstavba 3G sítí, navíc v místech s nízkou hustotou obyvatel, je ekonomicky extrémně náročným projektem, rozhodly se společnosti Telefónica a T-Mobile po dlouhých jednáních a pilotním testování vybudovat 3G síť v řídce osídlených oblastech společně.

UMTS 900 by bývalo bylo pro takové účely jako stvořené – při stejném počtu základnových stanic (dohromady jich bude postaveno 980) by pokrytí bez problémů obsáhlo celé vesnice a jejich okolí. Dnes je často už ve vzdálenosti 1,5 km od základnové stanice signál v budovách příliš slabý a nepoužitelný.

Zároveň by projekt vyžadoval redesign a přeladění GSM sítě: vyhrazení části 900 MHz pásma pro UMTS by nutně znamenalo snížení počtu dostupných kanálů pro GSM. To by, opět, nemuselo způsobovat problémy, pokud by k tomu operátoři přistupovali zodpovědně (například vhodnou politikou dotovaných mobilů pro stávající zákazníky a zahrnutím pouze UMTS 900 mobilů do své nabídky).

Francii jsem na začátku textu nezmínil náhodou. Podle Wikipedie podporují všichni čtyři operátoři ve Francii UMTS na 900 a 2100 MHz. Stejně tak operátoři v řadě dalších zemí (Finsko, Rumunsko, Bulharsko, Estonsko, Polsko, atd.) zavedení UMTS 900 zvládli.

Bohužel u nás, ať už vinou pozdního uvolnění části E-GSM pásma, pasivity ČTÚ, nebo neochoty/strachu komerčních operátorů z refarmingu, zůstává v ČR 900 MHz pásmo pro UMTS nepoužitelné.

Projekt sdílení sítí Telefóniky a T-Mobilu se blíží ke zdárnému konci (již běží více než 90 % plánovaných sdílených základnových stanic), který ale zároveň bude znamenatkonec rozvoje UMTS v ČR. Další rozvoj stávajícího 3G na 2,1 GHz je velmi nepravděpodobný, výstavba v řídce osídlených oblastech se prostě nevyplatí. Stejně tak se ale nevyplatí přestavba sdílené UMTS sítě na 900 MHz někdy v blízké budoucnosti – operátoři do výstavby 3G v uplynulých dvou letech investovali ohromný balík peněz a dokud se jim tyto finance nevrátí, nemůžeme očekávat žádné další investice.

UMTS 900 tak můžeme z povzdálí sledovat na hranicích s Německem a Polskem, případně na dovolené v zahraničí.

S nasazením u nás už jsem se rozloučil a naděje vkládám v rozvoj LTE. V 800 MHz pásmu totiž LTE nabídne to, co by zvládlo i UMTS 900 – široké pokrytí. A jako bonus ještě získáme vyšší kapacitu sítě a přenosové rychlosti.

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.

Jak používat stomegabitovou linku?

Kabelová společnost UPC začala s testováním stomegabitového připojení k internetu a ač není první v republice, rozhodně patří mezi největší poskytovatele. K tomu se váže i prostor, který je takové službě věnován v odbornějších médiích – na Živě, Lupě, Rootu, či jinde. Pár vyvolených redaktorů má službu k dispozici a postupně se dělí s námi méně šťastnými o své zkušenosti. K sepsání tohoto zamyšlení mě vedou články a diskuse na téma, jak vlastně lze tak rychlou přípojku využít.

Sto megabitů je na dnešní dobu pořád poměrně rychlá přípojka. Většina populace má dnes doma 2,4 GHz WiFi či ADSL přípojky s rychlostmi v řádu jednotek megabitů, ti šťastnější kabelový internet o rychlosti až tří desítek megabitů. Už při aktuálně nabízených rychlostech se mnozí ptají, jak službu vlastně využít „naplno.“

Jsem sosač

Můžete být sosači a snažit se linku využívat naplno. Brzy ale narazíte na docházející prostor na disku, v poličce s DVD, (tý)denní kvóty úložišť (Rapidshare), aj.

Pak vás přestane bavit vyhledávat další a další zdroje, protože DVD na stomegabitu stáhnete v ideálním případě do deseti minut. Celou sérii seriálu v 720p MKV ripu budete mít doma do hodiny. Všechny série někonečných seriálů v 720p MKV (jako třeba Simpsonovi) za den, v DivX za pár hodin.

A co dál?

Jsem běžný uživatel

Dál můžete (už jako běžný uživatel) tu linku využívat k normálním činnostem, občas něco stáhnout ohromující rychlostí a nestarat se, jestli jsou ta data vlastně na úložišti ve vedlejší místnosti nebo o pár set kilometrů dál v serverovně.

Když se k vám dostane odkaz na něco, co bude stát za stažení, tak si to prostě stáhnete a budete rádi, že nemusíte čekat celý den. Internetovou přípojku budete využívat nárazově – jednoduše až tehdy, kdy to bude potřeba nebo vhodné pro vás.

Ten druhý případ bude rozhodně mnohem častější. Dřív, když byly linky úzké, jsme všichni dlouhé hodiny čekali na stažení každého většího souboru. Když jsem před deseti lety na 33,6k modemu stahoval jednu písničku půl hodiny z Napsteru, nemohl jsem se dočkat, až ji budu mít doma. Nejen kvůli telefonním poplatkům, kdy jedna taková písnička vlastně stála nějakých osm korun (tři impulsy v čase mezi devátou večerní a sedmou ranní).

Není se čemu divit, že v době existence tarifu Internet 99 a jeho následníků (I2000, I2002 a dalších) jsme se snažili z linky vymáčknout maximum a co nejdříve se odpojit. Tohle chování plynulo z obav nad konečným telefonním účtem.

Bohužel to v nás zůstalo zakořeněné i po nástupu časově neomezených tarifů (ADSL, bezdráty, různé formy pevného připojení). Mnoho uživatelů se i dnes snaží vyždímat z linky maximum se slovy „když už si to platím, tak to chci využívat.“

A já se ptám: proč to chcete využívat naplno?

Smyslem časově a datově neomezené linky pro domácnosti není poskytnout vám možnost využívat linku maximální rychlostí čtyřiadvacet hodin denně, sedm dní v týdnu, 365 dní v roce. Každý poskytovatel konektivity pro domácnosti počítá s tím, že uživatelé budou používat linky nárazově, na základě toho dimenzuje svou infrastrukturu a nakupuje páteřní konektivitu. Na rozdíl od firemních zákazníků totiž běžné domácnosti nemají co neustále přenášet z internetu k sobě a zpět.

S tím, jak domácí přípojky zrychlují, postupně ubývá i lidí, kteří jsou schopni linku „vyšťavit.“ Nedávno jsem provedl experiment a na části bezdrátové sítě zrychlil uživatelům přípojky na čtyřnásobek. Vypozoroval jsem zajímavý efekt:

  • Ti, co používali internet „normálně“ (surfování, občas něco stáhnou, poslechnou rádio, kouknou do TV archivu, na youtube), internet i nadále používali stejným způsobem, jen se jim data načítala rychleji. Což nepoznali, pokud nestahovali opravdu velký objem dat.
  • Ti, co používali internet „agresivně“ („sosači“), měli svá data stažena rychleji a jejich linka oproti dřívějšku více času strávila „nicneděláním.“ U člověka, který dlouhodobě stojí v čelních příčkách statistiky sosačů, to bylo vidět nejvíc. Tu se objevila špička, následně poklesla, dlouho se nic nedělo, po pár hodinách se objevila další špička a tak to šlo pořád dokola.

Na příkladu sosače je dobře vidět, že s rychlou linkou opravdu nebudete mít potřebu „neustále sosat.“ Co si zamanete, to budete mít doma prakticky hned.

Jak tedy používat stomegabitovou linku?

Až ji budete mít k dispozici (nebo i pomalejší varianty, 30, 50, 70 megabitů), pochopíte sami. Práce s internetem se stane praktičtější. Nebudete tolik času trávit čekáním a víc se budete věnovat tomu, co vás zajímá/živí. Rychlou linku budete brát jako dnes auto – budete mít stále k dispozici a když budete chtít, tak ji prostě využijete.

Můj soukromý názor je, že procento lidí, kteří se dodnes snaží využít linku na 100%, se bude postupně snižovat. Ano, pořád to bude oněch 20% lidí, kteří vygenerují 80% provozu v síti. Ale už nebudou očekávat, že ze své linky dostanou plných (100 Mbit/8) * 86400 sek * 31 dní = 32 TB dat měsíčně…

Historie ADSL v ČR (5): Vytáčené ADSL a rušení limitů

Minulý týden O2 uvedlo novou koncepci služeb pro domácnosti, díky které jsme se po letech konečně dočkali možnosti pořídit si takzvané nahé ADSL, tedy ADSL bez hlasových služeb. Pojďme se ohlédnout do historie, jak se vlastně české ADSL vyvíjelo a čím vším muselo projít, aby se dostalo do dnešní podoby. Tentokrát se podíváme na významné roky 2007 a 2008, první pokus o nahé ADSL, vytáčené ADSL a konec datových limitů.

2007

Dvoumegabit standardem, osmimegabit vrcholem

První tři měsíce byly na poli ADSL poměrně klidné. TO2 připravovala novou velkoobchodní nabídku služeb ADSL (se zahrnutím požadavků regulátora), kterou v březnu představila  veřejnosti. Nejnižší nabízenou rychlostí se stává 2048 kbit/s, nejvyšší 8192 kbit/s. Nově se objevuje zmínka o poskytování internetu přes novější technologii ADSL2+, které bylo doposud více využito hlavně u O2TV.Posléze se objevuje i maloobchodní nabídka. Dvoumegabitová varianta stojí 475 Kč vč. DPH, s nejlevnějším hlasovým paušálem přijde tedy na 831 Kč.

O2 Duo Mobil – pokus o ADSL bez poplatku za pevnou

Protože už delší dobu uživatelé volali o možnosti pořídit si ADSL bez nutnosti placení hlasového paušálu, představila TO2 v dubnu 2007 službu O2 Duo Mobil. Nešlo však o nahé ADSL v pravém slova smyslu, ale o balíček služeb, ve kterém byla pevná linka, internet ADSL a mobilní hlasový tarif, přičemž mělo jít o atraktivní nabídku. Ta se ovšem u zákazníků příliš nechytla.O týden později, tedy v půlce dubna 2007, překonává TO2 hranici půl milionu aktivních ADSL přípojek.

Vytáčené ADSL

Dalším krokem vedle v historii našeho ADSL byla červnová nabídka takzvaného vytáčeného ADSL, obchodním jménem O2 Internet ADSL Start. Technicky šlo o ADSL přípojku účtovanou časově. V základu měl uživatel k dispozici dvě hodiny „datovacího času“ a cokoli navíc si připlácel minutovou sazbou. Připojení přitom ručně vytáčel/odpojoval na svém PC. Služba vydržela na trhu několik měsíců a pak ji TO2 bez halsitých oznámení přestala nabízet.

Zvýšení limitů ve FUP

Zatímco UPC, poskytovatel kabelového internetu, se rozhodl od července 2007 úplně zrušit objemové limity, Telefónica je pouze zvedla. Nejnižší tarif nabízí přenos až 10 GB dat plnou rychlostí, po překročení rychlost klesne poměrně brutálně z 2048 kbps na 64 kbps. U vyšších tarifů jde o pokles na 128 kbps.Ke konci roku 2007 hlásí TO2 570 tisíc ADSL přípojek. Zdá se tedy, že rok 2007 byl ve znamení opadlého zájmu o tento typ připojení, během roku došlo k nárůstu pouze o 60 tisíc přípojek.

2008

FUP: Limity odchází, nastupuje řízení provozu

Po nenápadných a drobných změnách ve velkoobchodní nabídce (mimojiné zrušení tarifu Start) oznámila TO2 v březnu roku 2008, že od dubna zruší objemové limity u všech variant jí nabízených ADSL přípojek. FUP jako takové ale nekončí, nově nastupuje tzv. řízení provozu.

Řízení provozu je jakási inteligentní technologie, která by měla prioritizovat běžný a interaktivní provoz a naopak do pozadí odsouvat provoz, který nemusí být bezprostředně vyřízen – hlavně různé peer to peer sítě, stahovací služby jako Rapidshare, atp.

To vše se ale týká pouze uživatelů, kteří využívají protokol PPPoE (PPP over Ethernet). Pokud v síti TO2 jsou ještě nějací uživatelé PPPoA (PPP over ATM), budou i nadále trpět původními limity. Cíl je jasný, zmigrovat všechny uživatele na PPPoE, usnadnit údržbu a zbavit se již delší dobu nenabízené ATM varianty.

Taktéž přestává TO2 maloobchodně nabízet služby Extreme (dříve Profi) s agregací 1:20, zde se tedy objevuje prostor pro konkurenční nabídky.

Spolu se zrušením FUP si vedení TO2 dává předsevzetí, že do pěti let (tj. do roku 2013) bude na českém trhu jeden milion ADSL přípojek.

Nadále však pokračuje pokles počtu pevných linek, ke konci prvního čtvrtletí 2008 jich bylo již jen 1,9 milionu. Objevují se první signály, že TO2 začíná pracovat na takzvaném nahém ADSL, tedy levnějším ADSL bez hlasových služeb. Následně se objevuje pracovní verze druhé analýzy trhu s broadbandem, ve které se ČTÚ chystá TO2 nabízení nahého ADSL nařídit.

V šestém, posledním dílu tohoto miniseriálu se zaměříme na aktuální nabídku, tedy osmimegabitové ADSL „pro každého“ a příchod nahého ADSL.

Historie ADSL v ČR (6): 8 Mb/s a nahé ADSL

Minulý týden O2 uvedlo novou koncepci služeb pro domácnosti, díky které jsme se po letech konečně dočkali možnosti pořídit si takzvané nahé ADSL, tedy ADSL bez hlasových služeb. Pojďme se ohlédnout do historie, jak se vlastně české ADSL vyvíjelo a čím vším muselo projít, aby se dostalo do dnešní podoby. V posledním díle seriálu se podíváme na události nedávné, zrychlování základních přípojek až na 8 Mb/s a dlouho očeávané nahé ADSL.

Osm megabitů jako standard

V srpnu 2008 se objevuje nová velkoobchodní nabídka ADSL, ve které dochází ke značné redukci nabízených variant ADSL. Nově jsou nabízeny jen služby s rychlostí 8 a 16 Mbit/s.

Maloobchodní nabídka na sebe nenechala dlouho čekat a ještě před koncem srpna se konala tisková konference, kde došlo k jejímu odhalení. Protože i pro koncové uživatele zůstávají jen dvě rychlosti, kterých ale nejeden zákazník nedosáhne, byla tato nabídka překřtěna na AžDSL. Sama Telefónica uvádí, že na osmimegabitovou rychlost dosáhne až 60% z aktivně nabízených přípojek. Nahé ADSL se nekoná a nové rychlosti budou zpočátku nabízeny jen novým klientům, těm, kteří přejdou na některý z nabízených balíčků (Duo, Trio), nebo těm, kteří budou hodně trpělivě prosit na infolince. Ostatní se dočkají až při zrychlování, které je naplánováno na únor až duben 2009.

Celkový počet ADSL přípojek dosahuje na konci roku 2008 počtu 630 tisíc.

2009

Testování nahého ADSL

Přestože ČTÚ ještě nestihl vydat závazné nařízení o poskytování nahého ADSL, vrhla se TO2 v lednu do testování sama. Maloobchodní cena v pilotním provozu byla stanovena na 750 Kč vč. DPH.

Přichází velkoobchodní třímegabit

Když TO2 v březnu vydala novou velkoobchodní nabídku, nikdo nečekal, že se v ní objeví pomalejší služba, než 8 Mbit. A přesto: třímegabitové ADSL, které je možné poskytovat na ADSL i ADSL2+ infrastruktuře, je spíš určeno pro ty klienty alternativních operátorů, kteří jsou daleko od ústředny a na osmimegabitový tarif by ani zdaleka nedosáhli.

Opět po pár týdnů později spatřila světlo světa i maloobchodní nabídka. Tentokrát k žádnému výraznému překvapení nedošlo: Nahé ADSL je jedním z pilířů nové koncepce služeb, je možné si k němu přiobjednat hlasové služby za 99 Kč (tarif Standard), mobilní internet s 10 GB FUP za 150 Kč, O2TV Start zadarmo (s příplatkem za pronájem set-top boxu), zvýhodněnou O2 TV a další služby.

Nově přichází maloobchodní služba ADSL 16384/512 za 900 Kč. Na tuto službu budou migrováni všichni domácí uživatelé dřívějších vyšších tarifů, kteří mají dostatečně kvalitní vedení od ústředny.

Ohlašované 16384/768 kbps ADSL je v nabídce za 1 050 Kč a již podle názvu („O2 Internet Pro“) se jedná o špičku současné nabídky ADSL od TO2. Ti, kteří již 16 Mbit mají od září, budou zmigrování na tuto službu. Tím dojde k nárůstu ceny, původně stálo 16384/768 kbit ADSL 713 Kč a hlasový tarif Mini byl za 356 Kč, v součtu 1 069 Kč. Nově vyjde ta samá kombinace na 1 050 + 81, tedy 1 132 Kč.

Někteří domácí uživatelé možná budou novou podobou služeb zaskočeni. Pro koncového uživatele je totiž magická cenová hranice 500 Kč měsíčně za internetové připojení, kterou jen neradi překračují. ADSL je nově prezentováno jako základní služba (s cenou minimálně 750 Kč), ke které si můžete přikoupit „hlas“ za 81 nebo 99 Kč.

Uvidíme, jak domácí uživatelé na toto (optické) zdražení datových služeb, postavených na ADSL, zareagují.

Počet klientů ADSL byl na konci prvního čtvrtletí 2009 celkem 660 tisíc (a k tomu cca 50 tisíc zpřístupněných místních smyček, na kterých pravděpodobně poběží hlas a data alternativních operátorů).

Co bude dál?

Současná nabídka je z technického pohledu téměř to nejlepší, co lze z ADSL „vyždímat.“ Teoreticky je možné jít ještě dál, máte-li dobré vedení, není problém získat na linkové vrstvě až 24 Mbit na downstreamu a 1,3 Mbit na upstreamu. Prakticky však na takovou rychlost dosáhne jen velmi málo přípojek.

Při pohledu do minulosti je vidět, že Telefónica O2 aktualizuje svou velkoobchodní nabídku zhruba každých šest měsíců a každých 12 až 18 měsíců své služby zrychluje. Poslední zrychlení proběhlo v srpnu 2008, lze tedy očekávat, že v létě 2009 TO2 „dorovná“ nabídky konkurence – zejména kabelového připojení od společnosti UPC.

UPC v současnosti (květen 2009) nabízí dvě varianty služeb, 10/1 Mbit a 20/1,5 Mbit. ADSL může – máte-li dobré přístupové vedení – nabídnout až 24/1,3 Mbit, očekával bych tedy postupné zrychlení na „až“ 10 Mbit na downstreamu a 768 kbit na upstreamu pro nižší službu a „až“ 24 Mbit na downstreamu a „až“ 1280 kbit na upstreamu u dražší služby.

Cena zřejmě pokesne, protože fixní náklady se rozloží mezi více uživatelů. TO2 bude určitě i nadále pokračovat v akčních nabídkách, kterými bude chtít přetáhnout zákazníky konkurentních poskytovatelů – zejména bezdrátových.

Takové akce už probíhají (celorepublikové akce ADSL za 500 a 600 Kč měsíčně na rok, individuální slevy v krajích, „zátahy“ podomních prodejců, kteří jsou – nezávisle na stavu linky – schopni naslibovat uživatelům 8 Mbit v kterékoli vesnici) a zřejmě budou přibývat. V průběhu posledního čtvrtletí 2008 a prvního čtvrtletí roku 2009 totiž zřejmě díky těmto akcím opět došlo ke zvýšení zájmu o ADSL.

Případným zrychlením se ovšem ADSL dostane na úplný okraj svých technických možností a bude velmi záležet na vlastnosti „drátu,“ který k vám domů vede. V souvislosti s tím se už v minulosti objevily spekulace a domněnky, že TO2 bude postupně osazovat DSLAMy nejen na své HOST (místní) ústředny, ale i tzv. předsunuté ústředny (menší ústředny v obcích a v bodech sítě; jsou řízeny HOST ústřednou). Tím by se ADSL mohlo dostat mnohem blíž ke koncovým uživatelům a mohly by jim být nabídnuty lepší rychlosti.

Zároveň už TO2 testuje technologii VDSL2, která na kratší vzdálenosti od ústředny (do 1,6 km) nabízí rychlosti mezi sto megabity a desítkami megabitů a od vzdálenosti cca 1,6 km má shodné vlastnosti, jako ADSL2+. Zároveň konečně umožní zvýšit rychlost ve směru od uživatele (upstream, upload), po čemž nejeden zákazník dlouho volá.

Jaký bude další vývoj DSL technologií u nás, to ví jen sama Telefónica O2. My ostatní můžeme pouze odhadovat a doufat, že TO2 tentokrát nezaspí a vrhne se na nabízení zajímavých služeb včas a ne opět s křížkem po funuse, jak jsme v minulých letech tak často vídávali…

Historie ADSL v ČR (4): zpomalování, zdražování, O2 a O2TV

Minulý týden O2 uvedlo novou koncepci služeb pro domácnosti, díky které jsme se po letech konečně dočkali možnosti pořídit si takzvané nahé ADSL, tedy ADSL bez hlasových služeb. Pojďme se ohlédnout do historie, jak se vlastně české ADSL vyvíjelo a čím vším muselo projít, aby se dostalo do dnešní podoby. Dnes se zaměříme na zpomalování přípojek po vyčerpání FUP, zdražování hlasových přípojek a příchod O2 na scénu.

2006

Další zrychlování a změny ve FUP

V lednu 2006 představil Telecom další aktualizovanou verzi své velkoobchodní nabídky. Nejnižší nabízenou rychlostí se stalo 512 kbit/s. O dva týdny později přišla na řadu i maloobchodní nabídka, ve které kromě zvýšení rychlostí, množství přenesených dat, které je možno čerpat plnou rychlostí, změnil i způsob aplikace FUP.

Dřívější týdenní počítání přenesených dat a dvoustupňový pokles rychlosti byly změněny na měsíční cykly a jednorázový pokles. Po překročení dat „v ceně“ docházelo k poklesu rychlosti na „narrowband,“ 64/64 kbps u 512 kbps varianty, 128/128 kbps u všech ostatních.

V únoru je v provozu tři sta tisíc ADSL přípojek.

Zdražování podložek

V dubnu 2006 došlo ke zrušení regulace hlasových tarifů a následně k jejich zdražení. Během let 2005 až 2006 nebylo možné jako „podložku“ (minimální hlasový tarif) použít Home Mini, to se však s koncem regulace mění. Nejde však o Telefon Mini za 199 Kč bez DPH, ale o jeho „Expres/ADSL“ variantu za 299 Kč bez DPH. Po připočtení 19% DPH se minimální cena hlasového tarifu vyšplhala na 356 Kč, zatímco před zdražením stál tarif Standard 329 Kč. Tato změna tedy celkovou sumu za linku a ADSL zvýšila o 26 Kč.

Přichází Telefónica O2 Czech Republic, a.s.

Prvního července formálně zaniká společnost ČESKÝ TELECOM, a.s., novým názvem společnosti je Telefónica O2 Czech Republic, a.s. Nový operátor již integruje bývalý Eurotel, s. r. o. Transakce prodeje je tím tedy završena. I když značka Český Telecom bude ještě nějaký měsíc dožívat, novou firemní barvou se stává modrá a bublinkaté logo nás bude pronásledovat čím dál víc.

V červnu a červenci není uplatňována FUP, dochází totiž k upgradu zařízení, která FUP zajišťují.

Kolem 1. srpna dochází k překročení hranice čtyř set tisíc klientů broadbandového připojení.

O2 a O2TV na scéně

V září proběhne sjednocení firemních značek a log, Český Telecom už vůbec neexistuje. Služba Internet Expres se mění na O2 Internet Expres.Telefónica O2 zároveň (již pod svou značkou) uvádí novou službu: televizi přes IP (IPTV), kterou hodlá nabízet jen tam, kde má na ústřednách ADSL2+ DSLAMy.

Regulace a zvýšení velkoobchodních limitů

V listopadu vydává ČTÚ analýzu broadbandového trhu u nás, ve které konstatuje, že na trhu je hráč s monopolními praktikami (TOCR) a rozhoduje o uložení nápravných opatření. Ta se budou týkat počítání dat, měla by zajistit větší jistotu u alternativních ISP, kteří přeprodávají ADSL, zajistit jim garance a umožnit SLA. Nejeden bod z uložených opatření nebude dotažen do konce, TO2 se ale nic nestane.

O pár týdnů později zvyšuje TO2 limity ve velkoobchodní nabídce ADSL, čímž dává více prostoru alternativním operátorům.

Na konci roku 2006 je v provozu na 470 tisíc ADSL přípojek.

Příště si povíme o kroku stranou v podobě tzv. vytáčeného ADSL a konci datových limitů nejen u O2.