No prohlizece na PC to asi podporuji, ale co na mobilech? Jestli si dobre vzpominam, tak jsem nekde cetl, ze Android 2.3.x sice IPv6 podporuje ale prave pokud sestka nefunguje, tak to spadne a na ctyrku to zpatky neprejde. Jak je to u Androidu 4.x nevim. Windows Phone 7 vubec IPv6 nepodporuje a jak je to u WP8 jsem zatim nikde necetl.
Jinak doma jsem teoreticky na IPv6 temer pripravenej, akorat VOIP telefon mi jede pouze na IPv4, novejsi firmware s podporou sestky neexistuje. Kazdopadne u UPC to nemam jak vyzkouset, ale pry maji taky sva zarizeni otestovana, akorat to nespustili ke koncovym uzivatelum. :-/
Android i ve verzi 4 nejspíše Happy Eyeballs neumí, aspoň to před časem tvrdil na svém blogu Radek Zajíc.
Na druhou stranu, happy eyeballs jsou poměrně kontroverzní technika, která mimo jiné zapříčiňuje, žePodle mě by úplně stačilo správně nastavit tabulku priorit, tedy deprioritizovat Teredo a 6to4 (jako nejčastější zdroje rozbitosti) až pod nativní IPv4 a eventuálně do všech systémů vložit GUI s jednoduchým přepínačem „preferovat IPv4“/„preferovat IPv6“. Happy Eyeballs mělo smysl v době, kdy na IPv6 skoro nebyl obsah. Dneska, když je na IPv6 Google, Seznam, Facebook a Youtube, by uživatel těžko mohl nabýt pocitu, že závada je na straně služby a byl by tak donucen nefunkční IPv6 opravit. Třeba, až umřou Windows XP a drtivá většina klientských počítačů bude umět IPv6, přijde update, který zase Happy Eyeballs odstraní.
Dovolil bych si v té souvislosti dotaz:
Doma jsem si zprovoznil v celé síti IPv6 přes 6to4, klienty používají autokonfiguraci. Nebezi.cz běží ;), ale furt to píše, že Opera načítá stránky přes IPv4. Drbal jsem se s nastavením různých priorit v gai.conf (dle článku Krčmáře zde na webu, jinde na inetu, dle RFC), různě to přehazoval, ale furt to chce přes IPv4 (takže mi nejde želvička Kame).
Kde dělám chybu???
Děkuji.
To si rozumime dobre, pokud me skleroza neklame, tak vyvoj byl zhruba ten, ze FF proste preferoval IPv6 a kdyz timeoutovala, tak sel na IPv4. To vedlo k tomu, ze mamlasove s rozbitou siti museli cekat na timeout. Pak se to tusim zmenilo tak, ze cista instalace preferovala IPv4 a v about:config pribyl prepinac, kde bylo mozny zapnout preferenci IPv6. A teprve pak se objevilo to, ze zkousi obe varianty zaroven a spojeni navaze pres tu, kde prijde odpoved driv. A je dost pravdepodobny, ze driv prijde vzdy z IPv4 - specielne, pokud je 6tka pres tunel.
Jak konkretne to ma opera nevim, ale vim, ze neco takovyho ma taky.
Ale rozumíme :). Funkce getaddrinfo se dá volat různě a pořadí IPv4 a IPv6 určuje pouze při family=AF_UNSPEC. Aplikační hacky na souběžné IPv4 a IPv6 se dají dělat buď pomocí family=AF_INET / family=AF_INET6, nebo tím, že použiješ standardní AF_UNSPEC a ty rodiny si vyfiltruješ sám. V obou případech ale aplikace musí zvolit prioritu sama a tudíž se přestane chovat podle gai.conf.
Vše je o tom, že cokoli na způsob happy eyeballs zákonitě skončí ošklivým hackem nekopatibilním se stávajícími standardy pro konfiguraci pomocí gai.conf. Pak to dopadá tak, že je klientská strana při použití obou protokolů jeden velký bordel.
Celý klientský dualstack na mě působí dojmem, že je psát podle myšlenky: „Vždyť ono se to nějak poddá.“
Jinak gai.conf má vypadat takto, aby bylo 6to4 preferováno:
label ::1/128 0 label ::/0 1 #label 2002::/16 2 label ::ffff:0:0/96 4 label 2001:0::/32 7 precedence ::1/128 50 precedence ::/0 40 precedence 2002::/16 45 precedence ::/96 20 precedence ::ffff:0:0/96 10
Je důležité nemít nastaven štítek pro 6to4 prefix, jinak se 6to4 nepoužije pro žádnou adresu, která není také 6to4. Tabulka preferencí není kritická, ale je vhodně zvýšit prioritu 6to4 provozu nad nativní IPv6, protože v případě 6to4 připojení je spojení na 6to4 adresu efektivnější, než na nativní adresu.
Dle daného výpisu jsem gai upravil. Opera pořád upřednostňuje IPv4 (takže beze změny), akorát jí déle trvá zpracování stránky nebezi.cz - v něčem se tam rýpe. Nepřišel jsem na to, jak to opravit. U Iceweaselu to začalo hned fungovat - webové testy píšou upřednostnění IPv6 a Kame leze! Snad právě proto, že jsem to testoval hlavně v Opeře, jsem na to minule nepřišel. To mě docela Opera zklamala.
Děkuji moc.
6to4 má na Ethernetu MTU 1480 bajtů, výchozí MTU pro Ethernet je 1500; 1280 je minimum vyžadované IPv6. Pokud máte příliš dlouhé MTU, tak náročnější komunikace bude fungovat špatně (pokud je 6to4 relay nastaven správně) či vůbec.
Na Operu to ale vliv mít nebude, tam je problém, že používá vlastní resolver a žádné nastavování neumí.
<blockquote>Podle mě by úplně stačilo správně nastavit tabulku priorit, tedy deprioritizovat Teredo a 6to4 (jako nejčastější zdroje rozbitosti) až pod nativní IPv4</blockquote>
Toto již je výchozí nastavení.
Právě z toho důvodu jsou datové toky přes IPv6 tak nízké, třebaže tytéž statistiky ukazují, že klientů s IPv6 je značně více.
Pravda. nechal jsem se zmást tím novým RFC 6724. Jediná změna je, že 6to4 spojení je v současných implementacích nad nativní IPv4 (což mělo logiku, ale praxe ukázala velkou rozbitost), kdežto nové RFC ho dává pod. Ale tohle se projeví jen pro přístup na servery, které mají zveřejněnou 6to4 adresu a těch je minimum.