Aby określone urządzenie mogło komunikować się z innymi urządzeniami w Internecie przy użyciu trafnie nazwanego protokołu Internet Protocol (IP), musi mu najpierw zostać przypisany unikalny adres numeryczny. Wygląd tego adresu zależy od używanej wersji protokołu IP: IPv4 lub IPv6.
Wersja IPv4 została wdrożona po raz pierwszy w 1983 roku. To ta wersja zapoczątkowała współczesny Internet i pozostaje dominująca do dzisiaj. Wersja IPv6 pojawiła się już w 1998 roku, ale dopiero w ostatniej dekadzie zaczęła się coraz bardziej upowszechniać — poziom jej wdrożenia wzrósł z mniej niż 1% do poziomu między 30 a 40%, w zależności od tego, kto raportuje, co jest mierzy i w jaki sposób to robi.
Wraz ze wzrostem liczby połączonych urządzeń, która znacznie przekracza dostępną liczbę adresów IPv4, oraz rosnącymi kosztami wydatnie większa przestrzeń adresowa oferowana przez IPv6 powinna była zapewnić mu pozycję lidera. Jak zobaczymy, tak się jednak nie stało.
Cloudflare od wielu lat zdecydowanie opowiada się za wersją IPv6, a dzięki rozwiązaniu Cloudflare Radar uważnie śledzimy skalę jej wdrożenia w całym Internecie. Mający dopiero trzy lata Radar jest jeszcze stosunkowo nową platformą. Aby sięgnąć dalej w przeszłość, możemy zwrócić się o pomoc do naszych przyjaciół z APNIC1 — jednego z pięciu regionalnych rejestrów internetowych (RIR). Na podstawie ich danych, które sięgają 2012 roku możemy zauważyć, że wzrost poziomu wdrożenia protokołu IPv6 wyglądał na wykładniczy do połowy 2017 roku, po czym nastąpił okres, trwającego do dziś, wzrostu liniowego:
Proces wdrażania wersji IPv6 jest spowolniony brakiem zgodności obydwu wersji (urządzenia muszą mieć przypisane adresy IPv4 oraz IPv6), a także tym, że praktycznie wszystkie urządzenia w Internecie nadal obsługują protokół IPv4. Niemniej jednak, wersja IPv6 jest kluczowa dla przyszłości Internetu, w związku z czym niezbędne są dalsze działania na rzecz zwiększenia stopnia jej wdrożenia.
Cloudflare Radar, podobnie jak APNIC i większość innych obecnych źródeł, publikuje wartości odzwierciedlające przede wszystkim zakres, w jakim dostawcy usług internetowych (ISP) wdrożyli protokół IPv6 po stronie klienta. To bardzo ważny aspekt, który bezpośrednio wpływa na użytkowników końcowych, lecz istnieje także druga strona równania — strona serwera.
Mając to na uwadze, zapraszamy do wzięcia udziału w krótkim eksperymencie, którego celem jest przyjrzenie się skali wdrożenia IPv6 po stronie serwera oraz sprawdzenie, jak często klienty faktycznie (lub prawdopodobnie) są w stanie komunikować się z serwerami za pośrednictwem IPv6. W tych poszukiwaniach będziemy polegać na danych z systemu DNS, a rezultaty, jak to się mówi, mogą Cię zaskoczyć.
Wdrożenie protokołu IPv6 po stronie klienta (na podstawie ruchu HTTP)
Pod koniec października 2023 roku skala wdrożenia IPv6 w całym Internecie wynosiła, z perspektywy Cloudflare, około 36% całego ruchu, z niewielkimi wahaniami w zależności od pory dnia i dnia tygodnia. Po wykluczeniu botów szacunek wzrasta do nieco ponad 46%, podczas gdy nieuwzględnienie internautów powoduje jego spadek do około 24%. Te liczby odnoszą się do udziału żądań HTTP obsługiwanych przez IPv6 we wszystkich treściach umożliwiających korzystanie z tej wersji protokołu IP (ustawienie domyślne).
W tym ćwiczeniu najważniejsza jest liczba zarówno ludzi, jak i botów. Różnica w skali wdrożenia między tymi rodzajami ruchu ma wiele przyczyn — od zróżnicowanego poziomu obsługi IPv6 w bogatej gamie używanego oprogramowania klienta, przez różne poziomy wdrożenia IPv6 w wielu sieciach, z których pochodzi ruch, po zróżnicowaną wielkość takich sieci itp. Jest to jednak temat na inną okazję. Interesujące dane dotyczące konkretnego kraju lub sieci można znaleźć na platformie Cloudflare Radar oraz w naszym raporcie podsumowującym rok 2023.
Do tanga trzeba dwojga
Uważny Czytelnik może nam wytknąć, że dokonanie pomiarów po stronie klienta w równaniu klient‑serwer przedstawia nam jedynie połowę historii — aby klient zdolny do obsługi IPv6 mógł nawiązać połączenie z serwerem za pośrednictwem tego protokołu, serwer musi mieć również możliwość obsługi IPv6.
To nasuwa dwa pytania:
- Jaka jest skala wdrożenia protokołu IPv6 po stronie serwera?
- Na ile dobrze wdrożenie IPv6 po stronie klienta koreluje z wdrożeniem po stronie serwera?
Istnieje kilka możliwych odpowiedzi, w zależności od tego, czy mówimy o użytkownikach, urządzeniach, przesyłanych bajtach itp. Skupimy się na połączeniach (powód stanie się jasny za chwilę), a zadawane przez nas pytanie brzmi:
Jak często klient zdolny do obsługi IPv6 może używać tej wersji podczas łączenia się z serwerami w Internecie, przy typowych wzorcach użytkowania?
Typowe wzorce użytkowania obejmują internautów, którzy w ciągu dnia odwiedzają niektóre witryny częściej niż inne, bądź automatyczne klienty wywołujące interfejsy API. W celu uzyskania tej perspektywy zwrócimy się do systemu DNS.
I wtedy wchodzi DNS…
Zanim klient będzie mógł spróbować nawiązać połączenie z serwerem po nazwie, używając klasycznej (IPv4) lub nowocześniejszej (IPv6) wersji protokołu, musi odnaleźć adres IP serwera w książce telefonicznej Internetu, czyli w systemie nazw domen (DNS).
Wyszukiwanie nazwy hosta w DNS jest procesem rekurencyjnym. Aby znaleźć adres IP serwera, należy prześledzić hierarchię domen (składniki nazwy serwera oddzielone kropkami) na kilku autorytatywnych serwerach DNS, aż jeden z nich zwróci żądaną odpowiedź. Większość klientów nie robi tego jednak bezpośrednio, lecz zleca wykonanie tej operacji serwerowi pośredniczącemu zwanemu resolwerem rekurencyjnym. Cloudflare obsługuje jeden z takich resolwerów rekurencyjnych, z którego każdy może korzystać: 1.1.1.1.
Oto uproszczony przykład: gdy klient pyta resolwer 1.1.1.1 o adres IP, w którym rezyduje nazwa „www.example.com”, resolwer ten przepytuje główne serwery DNS o składnik „.com”, następnie pyta serwery DNS .com o składnik „example.com”, a na koniec pyta o nazwę „www.example.com” serwery DNS example.com, które na podstawie bezpośredniej wiedzy na ten temat udzielają odpowiedzi w postaci adresu IP. Aby przyspieszyć proces dla następnego klienta zadającego podobne pytanie, resolwer 1.1.1.1 buforuje (zapamiętuje na jakiś czas) zarówno ostateczną odpowiedź, jak i kroki pośrednie.
Oznacza to, że 1.1.1.1 może łatwo zliczać, jak często klienty próbują wyszukać adresy IPv4 (zapytania typu A) w porównaniu z tym, jak często próbują wyszukać adresy IPv6 (zapytania typu AAAA), gdyż obejmuje swoim działaniem większość obserwowalnego Internetu.
Ale skąd klient wie, kiedy pytać o adres IPv4 serwera, a kiedy o jego adres IPv6?
Krótka odpowiedź brzmi następująco: klienty mające dostęp do adresowania IPv6 po prostu pytają o obydwa adresy, kierując oddzielne zapytania A i AAAA do każdego serwera, z którym chcą się połączyć. Klienty zdolne do obsługi IPv6 będą priorytetowo łączyć się za pośrednictwem protokołu IPv6, gdy otrzymają niepustą odpowiedź AAAA, niezależnie od tego, czy otrzymają również niepustą odpowiedź A (co, jak zobaczymy, zdarza się prawie zawsze). Jeśli interesują Cię szczegóły, algorytm generujący tę preferencję nowoczesności nosi nazwę Happy Eyeballs.
Jesteśmy już gotowi, aby przyjrzeć się rzeczywistym danym...
Wdrożenie protokołu IPv6 po stronie klienta (na podstawie DNS)
Pierwszym krokiem jest ustalenie punktu odniesienia poprzez pomiar skali wdrożenia IPv6 po stronie klienta z perspektywy resolwera 1.1.1.1, a następnie porównanie go z wartościami pochodzącymi z żądań HTTP, od których zaczęliśmy.
Kuszącym pomysłem jest zliczanie, jak często klienty łączą się z resolwerem 1.1.1.1 przy użyciu protokołu IPv6, ale wyniki mogą być mylące z kilku powodów, przy czym najważniejszy z nich jest widoczny na pierwszy rzut oka: 1.1.1.1 to najbardziej zapadający w pamięć adres z zestawu adresów IPv4 i IPv6, których klienty mogą używać w zapytaniach DNS za pośrednictwem usługi 1.1.1.1. Najlepiej, gdyby klienty zdolne do obsługi IPv6 i używające 1.1.1.1 jako swojego resolwera rekurencyjnego miały skonfigurowane wszystkie cztery poniższe adresy IP, a nie tylko pierwsze dwa:
- 1.1.1.1 (IPv4)
- 1.0.0.1 (IPv4)
- 2606:4700:4700::1111 (IPv6)
- 2606:4700:4700::1001 (IPv6)
Jednak w przypadku konfiguracji ręcznej ludzie uważają adresy IPv6 za mniej zapadające w pamięć niż adresy IPv4, dlatego są mniej skłonni je konfigurować, uznając adresy IPv4 za wystarczające.
Pokrewnym, ale mniej oczywistym czynnikiem zakłócającym jest to, że wiele klientów zdolnych do obsługi IPv6 nadal będzie wykonywać zapytania DNS za pośrednictwem protokołu IPv4, nawet gdy mają skonfigurowane adresy IPv6 usługi 1.1.1.1, ponieważ rozprzestrzenianie zapytań na dostępne adresy jest popularną opcją domyślną.
Rozsądniejszym podejściem do oceny skali wdrożenia protokołu IPv6 na podstawie aktywności klientów DNS jest obliczenie stosunku liczby zapytań typu AAAA do całkowitej liczby zapytań typu A, przy założeniu, że klienty IPv6 zawsze wykonują obydwa rodzaje zapytań, o czym wspomniano wcześniej.
Z perspektywy resolwera 1.1.1.1 skala wdrożenia IPv6 po stronie klienta jest szacowana na 30,5% na podstawie wolumenu zapytań. Jest to nieco poniżej tego, co zaobserwowano na podstawie ruchu HTTP w tym samym okresie (35,9%), ale taka różnica między dwiema różnymi perspektywami nie jest zaskakująca.
Uwaga dotycząca czasów życia pakietu (TTL)
Odpowiedzi DNS są buforowane nie tylko przez resolwery rekurencyjne — także większość klientów DNS ma swoje lokalne pamięci podręczne. Przeglądarka internetowa, system operacyjny, a nawet domowy router przechowują odpowiedzi, aby w razie czego przyspieszyć kolejne zapytania.
Czas, przez który każda odpowiedź pozostaje w pamięci podręcznej, zależy od wartości pola czasu życia pakietu (TTL) zwracanej wraz z rekordami DNS. Jeśli znasz się na systemie DNS, możesz się zastanawiać, czy rekordy A i AAAA mają podobne wartości TTL. Jeśli wartości te są różne, możemy otrzymywać mniej zapytań dotyczących jednego z tych dwóch typów (ponieważ jest dłużej buforowany na poziomie klienta), co przekłamywałoby wyniki dotyczące wdrożenia.
Zaprezentowane wykresy kołowe przedstawiają podział minimalnych wartości TTL zwracanych przez 1.1.1.1 w odpowiedzi na zapytania typu A i AAAA. Widoczna jest pewna, aczkolwiek niewielka różnica między obydwoma typami.
Wdrożenie IPv6 po stronie serwera
Poniższy wykres pokazuje, jak często zapytania typu A i AAAA otrzymują odpowiedzi niepuste, co rzuca światło na kwestię wdrożenia protokołu IPv6 po stronie serwera i przybliża nas do szukanej odpowiedzi:
Skala wdrożenia protokołu IPv6 przez serwery jest szacowana na 43,3% na podstawie wolumenu zapytań, co jest wartością zauważalnie wyższą niż w przypadku obserwacji dotyczących klientów.
Jak często obydwie strony „dogadują się ze sobą”
Jeśli 30,5% wyszukiwań adresów IP obsługiwanych przez resolwer 1.1.1.1 mogłoby korzystać z adresu IPv6 do nawiązywania połączenia z zamierzonymi lokalizacjami docelowymi, ale tylko 43,3% tych zapytań otrzymuje odpowiedź niepustą, może nam to dać dobrą podstawę do oceny, jak często realizowane są połączenia IPv6 między klientem a serwerem — mniej więcej w 13,2% przypadków.
Potencjalny wpływ popularnych domen
Wdrożenie protokołu IPv6 po stronie serwera, mierzone na podstawie wolumenu zapytań dla domen z listy Top 100 platformy Radar, wynosi 60,8%. Jeśli wykluczymy te domeny z naszych ogólnych obliczeń, poprzednia wartość 13,2% spadnie do 8%. Jest to różnica znaczna, ale nie zaskakująca, ponieważ domen Top 100 dotyczy ponad 55% wszystkich zapytań A i AAAA kierowanych do resolwera 1.1.1.1.
Gdyby tylko kilka z tych bardzo popularnych domen wdrożyło dzisiaj protokół IPv6, znacznie wzrosła by obserwowana skala jego wdrożenia, a wraz z nią szansa na to, że klienty zdolne do obsługi IPv6 nawiązywałyby połączenia przy użyciu tego protokołu.
Uwagi końcowe
Obserwowanie skali wdrożenia protokołu IPv6 w całym Internecie może oznaczać różne rzeczy:
- zliczanie użytkowników mających dostęp do Internetu z możliwością obsługi IPv6,
- zliczanie urządzeń zdolnych do obsługi IPv6 lub oprogramowania na tych urządzeniach (klientach i/lub serwerach),
- obliczanie wolumenu ruchu sieciowego (w bajtach) przepływającego przez połączenia IPv6,
- zliczanie odsetka połączeń (lub indywidualnych żądań) za pośrednictwem IPv6.
W tym ćwiczeniu zdecydowaliśmy się przyjrzeć połączeniom i żądaniom. Mając na uwadze, że rzeczywistą sytuację można w pełni zrozumieć tylko poprzez przeanalizowanie kilku odmiennych perspektyw, odnotowaliśmy trzy różne wartości dotyczące wdrożenia IPv6:
- 35,9% (po stronie klienta) przy zliczaniu żądań HTTP obsługiwanych przez sieć CDN Cloudflare,
- 30,5% (po stronie klienta) przy zliczeniu zapytań DNS typu A i AAAA obsługiwanych przez resolwer 1.1.1.1,
- 43,3% (po stronie serwera) pozytywnych odpowiedzi na zapytania DNS typu AAAA, również z resolwera 1.1.1.1.
Połączyliśmy dane po stronie klienta i po stronie serwera z perspektywy DNS, aby oszacować, jak często połączenia z serwerami stron trzecich mogą być nawiązywane za pośrednictwem IPv6, a nie IPv4 — dzieje się tak w zaledwie 13,2% przypadków.
Aby poprawić te wyniki, dostawcy usług internetowych, chmurowych i hostingowych oraz korporacje muszą w podobnym stopniu zwiększyć tempo udostępniania protokołu IPv6 urządzeniom w swoich sieciach. Duże witryny internetowe i źródła treści również odgrywają kluczową rolę w umożliwianiu klientom zdolnym do obsługi IPv6 częstszego korzystania z tego protokołu, ponieważ 39,2% zapytań dotyczących domen z Top 100 platformy Radar (stanowiących ponad połowę wszystkich zapytań A i AAAA do resolwera 1.1.1.1) nadal otrzymuje odpowiedzi tylko z wykorzystaniem protokołu IPv4.
Internet nie jest jeszcze w pełni gotowy do pełnego wdrożenia IPv6. Konsekwentne wysiłki ze strony wszystkich zaangażowanych podmiotów mogą jednak przyczynić się do dalszych postępów, a być może nawet przyspieszyć ten proces.
Po stronie serwera firma Cloudflare od wielu lat pomaga w tych globalnych inicjatywach, oferując darmową obsługę IPv6 dla wszystkich domen. Po stronie klienta aplikacja 1.1.1.1 automatycznie umożliwia Twojemu urządzeniu korzystanie z IPv6, nawet jeśli Twój dostawca usług internetowych nie zapewnia obsługi tego protokołu. A jeśli zarządzasz siecią tylko z adresowaniem IPv6, korzystasz również z obsługi DNS64 oferowanej przez resolwer 1.1.1.1.
***
1Publiczny resolwer DNS (1.1.1.1) firmy Cloudflare jest obsługiwany we współpracy z APNIC. Więcej informacji na jego temat można znaleźć w oryginalnym wpisie zamieszczonym na blogu oraz w polityce prywatności dotyczącej 1.1.1.1.
2Więcej informacji na temat działania DNS można znaleźć w sekcji „Czym jest DNS?” naszej witryny internetowej. Jeśli preferujesz naukę poprzez praktykę, proponujemy zapoznanie się z wpisem „Mess with DNS” autorstwa Julii Evans.
3Każdy resolwer rekurencyjny domyślnie zna adresy IP 13 serwerów głównych. Cloudflare bierze również udział w operacjach na najwyższym poziomie DNS, dostarczając usługę anycast dla instancji E‑Root i F‑Root, co oznacza, że resolwer 1.1.1.1 nie musi sięgać daleko w ramach tego pierwszego kroku wyszukiwania.
4Podczas korzystania z aplikacji 1.1.1.1 wszystkie cztery adresy IP są konfigurowane automatycznie.
5Dla uproszczenia zakładamy, że liczba klientów korzystających wyłącznie z protokołu IPv6 jest nadal znikomo mała. Jest to zasadniczo rozsądne założenie, które znajduje potwierdzenie w innych zbiorach danych, do których mamy dostęp.
61.1.1.1, podobnie jak inne resolwery rekurencyjne, zwraca skorygowane wartości TTL: oryginalny TTL rekordu minus liczba sekund, które upłynęły od ostatniego zapisania rekordu w pamięci podręcznej. Puste odpowiedzi A i AAAA są buforowane przez czas określony w rekordzie Start of Authority (SOA) domeny, zgodnie ze specyfikacją RFC 2308.