Nietypowo nie będzie o Linuksie, a o Windows, który bardzo rzadko pojawia się na tym blogu. Konkretnie o Windows 8 i IPv6.
Przy okazji wykładu na PLNOG na temat happy eyeballs[1] dowiedziałem się, jak to robią w Windows 8. Otóż Windows 8 określa, czy ma dostęp do sieci IPv6 poprzez pobranie pliku. Z serwera Microsoft[2]. A następnie cache’uje wynik na… bagatela 30 dni. Wystarczy, że w momencie sprawdzania sieć IPv6 albo serwer Microsoftu nie będą dostępne i żegnamy się z IPv6. Na miesiąc. Poza tym, to, że udało się połączyć z serwerem Microsoft nie oznacza, że istnieją trasy do wszystkich innych hostów IPv6. Więc rozwiązanie „takie sobie” (taki ładny eufemizm, zamiast sporej ilości przekleństw w kierunku twórców pseudostandardów w Microsoft).
W trakcie prezentacji przyszedł mi do głowy dirty hack (rozmowa po prezentacji sugeruje, że jak najbardziej powinien działać), który spowoduje, że system Windows będzie zawsze myślał, że ma dostęp do sieci IPv6. Do pliku hosts dopisujemy linię, która powoduje, że ipv6.msftncsi.com jest rozwiązywany na adres IPv4. Czyli plik jest pobierany z serwera IPv4, czyli system zawsze będzie próbował korzystać z IPv6. Tak, popsuje to mechanizm happy eyeballs (ale i tak był zepsuty). Może się przydać np. testerom, albo zwyczajnym fan(atyk)om IPv6.
Przy okazji, w prezentacji pojawia się Your task – check ipv6.msftncsi.com availability, które po sprawdzeniu pachnie mi lekkim FUDem. Przy sprawdzeniu co pięć minut dwóch rzeczy: pingowania po domenie i możliwości pobrania pliku, w ciągu 48h[3] nie zdarzył mi się ani jeden błąd. A dodatkowo sprawdzam przez tunel od HE, czyli potencjalny element, który może zawieść. Być może wyglądało to kiedyś gorzej i się poprawiło. To, że coś jest potencjalnie OKDR nie oznacza, że jest takie w praktyce. Bo wydaje się działać. Zresztą wystarczy zrobić farmę serwerów z adresem anycast i będzie to działać. Warto też sprawdzić:
host ipv6.msftncsi.com
ipv6.msftncsi.com is an alias for ipv6.msftncsi.com.edgesuite.net.
ipv6.msftncsi.com.edgesuite.net is an alias for a978.i6g1.akamai.net.
a978.i6g1.akamai.net has IPv6 address 2001:2030:0:f::d59b:9892
a978.i6g1.akamai.net has IPv6 address 2001:2030:0:f::d59b:9888
Czyli nie tyle serwery Microsoft, co Akamai (pozdrowienia dla f.). Nie jedno, ale 2 IP. Prawie na pewno rozproszone geograficznie i z wykorzystaniem anycastu. Nie zmienia to faktu, że dostępność tych IP nie oznacza dostępności po IPv6 każdego innego hosta („dziury” w routingu).
Źródła:
1. Prezentacja Krzysztofa Mazepy z EURONOG I PLNOG 2012 pt. IPv4 vs IPv6 IPv4 vs. – Happy Eyeballs.
2. Windows 8 moves to IPv6 Internet.
[1] Jest tylko po angielsku, więc w telegraficznym skrócie dla niespikających: w momencie połączenia host próbuje się łączyć po IPv6 i IPv4, jeśli ma łączność o zbliżonym opóźnieniu po obu protokołach, to preferuje IPv6. Zaleta jest taka, że w przypadku braku dostępności IPv6 nie czeka kilku(nastu/dziesięciu) sekund na timeout – użytkownik dostaje praktycznie bez opóźnienia content i oczka się cieszą.
[2] Konkretnie http://ipv6.msftncsi.com/ncsi.txt Zawartość jest stała i jest to po prostu Microsoft NCSI Jak widać wyżej, serwer jest Akamai.
[3] Tak, wiem, bardzo mała próbka, będzie aktualizowane wyniki z dłuższego okresu poniżej.
PS Kiedyś opisywałem, jak sprawdzić IP komputera pod różnymi systemami. Dodałem informację o sprawdzaniu łączności po IPv6.
UPDATE: Miała być statystyka z dłuższego okresu, to będzie. Minęło 16 dni. W tym czasie, przy sprawdzeniach co 5 minut, zanotowałem 75 braków odpowiedzi na ping i 26 błędów w pobraniu pliku przez WWW. Ale! Co minutę sprawdzam też, czy drugi koniec tunelu się pinguje po IPv6. Po wyeliminowaniu równoczesnego braku odpowiedzi z końca tunelu i błędów do hosta MS, zostało 49 błędów pingowania i 0 (zero) błędów pobrania pliku przez WWW. Czyli raczej błędy tunelu, niż rozwiązania MS. Jakby się ktoś zastanawiał, jak to możliwe, że plik się pobrał, przy braku odpowiedzi na ping do hosta – zapewne kwestia dłuższego timeoutu.
