Mnoho provozovatelů se již řadu let snaží převést většinu svých sítí na protokol IPv6, aby vyřešili nedostatek adres IPv4. Pro přístupové sítě koncových uživatelů to představuje problém, protože stále existuje mnoho starších zařízení, aplikací a/nebo služeb, které nemohou správně fungovat v prostředí pouze s IPv6. Sítě používající zároveň IPv4 i IPv6 (dual stack) poskytují pravděpodobně nejlepší uživatelský zážitek, ale na úkor toho, že vůbec neřeší nedostatek adres IPv4.
Mobilní telefony jsou připraveny, stolní počítače ne
Stav podpory IPv6-only se liší především podle typu zařízení, přesněji řečeno podle operačního systému. Obecně by neměl být problém poskytovat sítě pouze s IPv6 (s NAT64 a DNS64 pro podporu Legacy IP) pro mobilní operační systémy iOS a Android. V případě iOS nutí Apple všechny vývojáře aplikací publikovat pouze aplikace, které podporují provoz v síti pouze s IPv6.
Pro webové stránky používající přímo IPv4 adresy nebo servery, které nabízí IPv4 i IPv6, ale IPv6 ve skutečnosti nefunguje, existuje podpora Happy Eyeballs verze 2 (RFC 8305), která zmírňuje případné špatné zkušenosti uživatelů. Konečně, pro účely tetheringu ke stolnímu počítači je k dispozici také CLAT, takže připojená zařízení získají IPv4 i IPv6 navzdory tomu, že mobilní síť může běžet pouze na IPv6.
V případě systému Android je CLAT klíčovou funkcí zmírňující problémy s přístupovými sítěmi využívajícími pouze protokol IPv6. Díky tomu mohou nemodifikované starší aplikace fungovat bez větších problémů, protože z pohledu aplikace je zařízení stále připojeno k síti s dual stackem. Zařízení se systémy iOS i Android jsou masově po celém světě provozována v mobilních sítích pouze s protokolem IPv6, takže lze celkem bezpečně očekávat, že by nemělo dojít k žádným větším problémům.
Pokud jde o desktopové operační systémy, je situace méně uspokojivá. Uživatelé operačních systémů Windows, Linux a macOS mohou stále volně instalovat aplikace z různých zdrojů, včetně starších aplikací, které používají zastaralá API pouze pro IPv4. Takové aplikace nebudou fungovat, pokud nebude v síti zajištěna podpora IPv4. Zároveň na desktopech prakticky neexistuje CLAT, který by tyto problémy řešil. Pro Linux existuje skript clatd, ale není standardní součástí žádné běžné distribuce. Systém Windows sice obsahuje CLAT, ale ten se aktivuje pouze v případě, že je k počítači přímo připojen WWAN modem. Notebook se systémem Windows se tak může připojit k mobilním sítím pracujícím pouze s protokolem IPv6 a stále podporovat aplikace pracující pouze s IPv4.
Vzhledem k tomuto omezení desktopových operačních systémů by nasazení přístupových sítí pouze s protokolem IPv6 způsobilo určitému množství uživatelů problémy. Provozovatelé sítí jsou proto nuceni provozovat sítě s oběma protokoly, přestože značný počet zařízení již protokol IPv4 vůbec nevyžaduje.
Vypnutí protokolu IPv4 pomocí volby DHCP
Pro řešení této situace byla nedávno v dokumentu RFC 8925 standardizována pro DHCP nová volba číslo 108 nazvaná IPv6-only Preferred. Umožňuje zařízení signalizovat svou schopnost správně pracovat v síti pouze s protokolem IPv6. To se provádí vyžádáním této volby klientem během obvyklé transakce protokolu DHCP. Pokud DHCP server ví, že daná síť podporuje provoz pouze s IPv6, zahrne takovou volbu do odpovědi, což způsobí, že klient před přidělením adresy IPv4 transakci přeruší. Proto i přes skutečnost, že síť podporuje dual stack, jsou IPv4 adresy přiděleny pouze starším klientům, kteří volbu DHCP číslo 108 nepožadují. Tím je možné snížit spotřebu IPv4 adres.
Zajímalo mě, zda se tato nová volba DHCP již v dnešních zařízeních používá. Za tímto účelem jsem se rozhodl změřit množství zařízení požadujících tuto možnost ve Wi-Fi síti konference RIPE 84 v Berlíně v květnu 2022. Po celý týden jsem zachycoval zprávy DHCP do souboru PCAP. Poté jsem pomocí nástroje Scapy vytvořil jednoduchý analyzátor, který počítá, kolik jedinečných adres MAC požádalo o zmíněnou volbu 108. Zde jsou výsledky:
Celkem unikátních MAC adres: 1441 MAC adresy, které požádaly o volbu IPv6-only Preferred: 951 65%
Za předpokladu, že počet jedinečných MAC odpovídá počtu připojených zařízení, to znamená, že téměř dvě třetiny zařízení požadovaly podporu provozu pouze s protokolem IPv6. Vzhledem k tomu, že RFC 8925 je poměrně čerstvé, je to velmi pozitivní výsledek. Ukázalo se, že možnost DHCP vyžadují nejen všechna nejnovější zařízení se systémy Android a iOS, ale také nejnovější systémy macOS (12.0.1 a novější). Ani jedna z těchto platforem nemá přepínač, který by uživateli umožnil změnit výchozí chování. To by bylo znepokojivé zejména v případě systému macOS, kde lze stále spouštět starší aplikace využívající pouze protokol IPv4.
V systému macOS je CLAT
Ukázalo se, že inženýři společnosti Apple tuto obavu zvážili a skutečně CLAT do posledních verzí systému macOS zahrnuli. Aktivuje se pouze v případě, že jsou splněny tyto podmínky:
- Server DHCP odpoví s volbou IPv6-only Prefered a
- v oznámení směrovače je uvedena volba PREF64 (RFC 8781) obsahující prefix NAT64.
Druhý požadavek je docela zajímavý, protože všechna předchozí zmírnění problémů se sítěmi pouze s protokolem IPv6 v systému macOS používala zjišťování prefixu NAT64 pomocí DNS64 (RFC 7050). Protože však tento typ zjišťování využívá nezabezpečené DNS, jsou s ním spojené určité bezpečnostní obavy. Volba PREF64, přestože je také nezabezpečená, sdílí osud s ostatními konfiguračními parametry předávanými v ohlášení směrovačů, a proto jí lze důvěřovat o něco více. Jsou-li oba požadavky splněny, aktivuje se CLAT, což je vidět na výstupu příkazu ifconfig. Jeho funkci lze otestovat pokusem o ping na přímo zadanou adresu IPv4.
Nová volba DHCP je snadná, nová volba RA obtížnější
Abychom tedy mohli vytvořit správnou přístupovou síť preferující protokol IPv6, musíme nastavit jak novou volbu DHCP, která kompatibilním klientům říká, aby nepoužívali protokol IPv4, tak i novou volbu ohlášení směrovače, která předá prefix použitý pro NAT64. Dříve zmíněná volba je na většině serverů DHCP poměrně snadno dosažitelná, protože RFC 8925 nevyžaduje žádné zvláštní chování na straně serveru. Každý server DHCP, který podporuje definici vlastních voleb tedy můžeme nakonfigurovat tak, aby klientům, kteří o to požádají, nabízel volbu 108, obsahující pouze 32bitovou hodnotu časovače, jak dlouho má zůstat protokol IPv4 deaktivován.
Pokud jde o volbu PREF64 v oznámení směrovače, každý jednotlivý směrovač musí být aktualizován, aby tuto novou volbu podporoval. Naštěstí se podpora pomalu objevuje:
- Existuje prototypová implementace v jazyce Python,
- existuje žádost o zařazení do FRR,
- podpora byla přidána do radvd,
- existuje žádost o zařazení do démona odhcpd používaného v OpenWRT.
DNS64 je stále potřeba pro Safari a iOS
Vzhledem k tomu, že volba PREF64 v oznámení směrovače aktivuje CLAT, je lákavé zkusit spustit síť bez DNS64. V takovém nastavení by veškerý provoz IPv4 procházel právě přes CLAT. V systému Android to funguje bez problémů, stejně jako u většiny aplikací v systému macOS s jednou velkou výjimkou: Safari. Prohlížeč nějakým způsobem odmítá používat CLAT a bez DNS64 prostě nenačte žádné zdroje po IPv4, ani doménová jména, ani přímo adresy IPv4. Stejná situace platí i pro iOS. Pouze s PREF64 a bez DNS64 se většina aplikací nedostane ke zdrojům na IPv4.
To znamená, že síť preferující protokol IPv6 musí kromě NAT64, volby PREF64 v ohlášeních směrovačů a volby IPv6-only Preferred v DHCP používat také DNS64. To bude mít určitý dopad na starší zařízení, která tuto síť používají v režimu běžného dual stacku. Vzhledem k tomu, že IPv6 je obecně upřednostňováno před IPv4, budou díky DNS64 všechny aplikace připravené na IPv6 upřednostňovat použití NAT64 místo nativního IPv4.
Nativní IPv4 se tak bude používat pouze v okrajových případech, jako jsou starší aplikace využívající pouze IPv4 nebo používající přímo IPv4 adresy. Měřením množství nativního provozu IPv4 v síti lze zjistit, zda k takovým případům stále dochází a případně se rozhodnout IPv4 v určitém okamžiku zcela vypnout.
IPv6-mostly vypadá slibně
Z mých testů se zdá, že síť preferující pouze IPv6 plní svůj účel poskytovat co nejlepší uživatelský komfort při využití co nejmenšího množství prostředků IPv4. Na druhou stranu je zde určitá přidaná složitost nad rámec tradičních dualstackových sítí a nedochází zde k žádné přímé úspoře adres IPv4, protože protokol IPv4 musí být kvůli starším zařízením stále nasazen v celé síti.
V příštích letech však lze předpokládat, že množství nativního provozu IPv4 v takové síti klesne až do bodu, kdy nebude mít smysl IPv4 provozovat. Při nejméně příznivém scénáři lze počítat s tím, že požadavky na množství přidělených adres IPv4 nebudou dále narůstat. To je zásadní výhoda proti tradičnímu dual stacku, kde vzácné adresy IPv4 dostává i většina zařízení, která je už dnes nepotřebuje.
Původně napsáno pro RIPE Labs.
