Po zhruba dvou týdnech provozu IPv6 je čas na krátké zhodnocení. S brokerem Hurricane Electric se za tu dobu nevyskytl žádný problém. V porovnání s IPv4 je rychlost o něco menší, nicméně se jedná o jednotky procent. To je pochopitelné, jelikož je protokol IPv6 tunelován a prochází dalšími body infrastruktury.

Při pohledu na poměr provozu IPv4 ku IPv6 (odečten zmíněný tunel), je vidět, že pro mnoho služeb je protokol IPv6 preferován. Samozřejmě ale pouze v případě, že je cílová služba dostupná přes IPv6. V současné době je však takových služeb odhadem 10 %. Zejména velké ICT společnosti podporují pro přístup oba dva protokoly.

Je škoda, že běžní poskytovatelé internetového připojení (zejména malí WISP) IPv6 nepodporují a snaží se jeho nasazení co nejvíce oddálit. Pokud se ale člověk zamyslí nad jejich důvody, je to logické. Veškeré informační systémy mají zavedené pro IPv4. Ať již databáze uživatelů s přidělenými prostředky, fakturační systémy, shapery a další potřebná infrastruktura je u nich léta zakonzervována v nějakém stavu a přidání podpory IPv6 by v takovém případě natropilo mnoho neplechy. Dalším důvodem je i změna pohledu na sítě a jejich topologii. U IPv4 měl každý zákazník přidělenu jednu IP adresu (ať dynamicky nebo staticky). V základním režimu jsou běžně dostupné komerční WiFi směrovače nastaveny tak, že obsahují IPv4 NAT. Za takovým směrovačem/bránou můžeme připojit mnoho zařízení. V případě IPv6 není použití technologie NAT doporučováno. Díky tomu je potřeba každému zákazníkovi přidělit místo jedné IP adresy (jako v případě IPv4) určitý rozsah. Ve většině případů se bude jednat o /64, ale pokud bude chtít zákazník provozovat složitější infrastrukturu, přijde na řadu rozsah /48. To je dáno tím, že veškerá zařízení v síti IPv6 dostanou veřejnou adresu. Tedy alespoň by měla.

V případě IPv4 a NAT stačilo na přístupovém/hraničním směrovači (WiFi router) také jednoduché nastavení stavového firewallu. V případě IPv6 je firewall složitější a pro více zařízení je potřeba kromě pravidel INPUT spravovat také FORWARD.

IP adresy

Na formát IP adres používaných v IPv6 si lze zvyknout velice rychle. Kromě lokálních linkových adres fe80::/10, které jsou automaticky na síťových rozhraních nastavovány, můžeme přidělit další. Tedy ty, které jsou z nám přidělenému rozsahu, tzv. globální. V mém případě např. 2001:470:XXXX:XXXX::/64. Dále existují, a v síti se používají, zejména multicastové adresy ff00::/8. S těmi ale při nastavování a práci z pozice běžného uživatele do styku nepřijdeme. V IPv6 se již nesetkáme s adresami broadcast, ty jsou nahrazeny právě multicastem.

Nesmím zapomínat na unikátní lokální adresy (ULA – Unique local address; rfc4193) fc00::/7. Ty jsou směrovatelné pouze v místních sítích. Můžeme je přirovnat k privátním IPv4 adresám 10.0.0.0/8 (třída A), 172.16.0.0/12 (třída B) a 192.168.0.0/16 (třída C).

Jak jsem již uváděl, pro provoz na lokální síti bez přístupu k internetu nemusíme žádné IP adresy nastavovat. Používají se lokální linkové, automaticky nastavené.

Při nastavování IPv6 ve své infrastruktuře jsem byl zpočátku zaskočen přidělenou IPv6 adresou mého konce tunelu, který je z jiného rozsahu než přiděleného /64. Pokud člověk běžně pracuje s rozsáhlejší infrastrukturou IPv4, je na takovou konfiguraci zvyklý. Pro můj účel jsem si ještě požádal o rozsah /48. To proto, že mám více LAN. Jak jsem tedy rozsah rozdělil?

Přiděleno: 2001:470:XXXX::/48
OpenVPN – tunely: 2001:470:XXXX:0001::/48
OpenVPN – lokalita 1: 2001:470:XXXX:0010::/48 (použité i jako prefix pro autokonfiguraci)
OpenVPN – lokalita 2: 2001:470:XXXX:0020::/48 (použité i jako prefix pro autokonfiguraci)
OpenVPN – lokalita 3: 2001:470:XXXX:0030::/48 (použité i jako prefix pro autokonfiguraci)
Veřejně dostupné služby – lokalita 1: 2001:470:XXXX:fef1::/48
Veřejně dostupné služby – lokalita 2: 2001:470:XXXX:fef2::/48
Veřejně dostupné služby – lokalita 3: 2001:470:XXXX:fef3::/48

Proč mám pro veřejně dostupné služby zvláštní rozsahy a nepoužívám ty, které jsou definovány jako „OpenVPN – lokalita X“? To proto, že má každá služba jinou IP adresu. A to i v případě, že všechny běží na jednom serveru. A proč? Protože nemusím adresami šetřit, jednoduše se hledají problémy a nastavuje firewall. Na příslušném serveru mám vytvořeny DUMMY rozhraní, na kterém je příslušná IP adresa zakončena. Tedy např. dummy0 pro 2001:470:XXXX:fef1::0101 a email, dummy1 pro 2001:470:XXXX:fef1::0102 a http, atd. U DUMMY rozhraní ale pozor na chování, ve výpisu statistik (např. ifconfig) jsou veškeré čítače nulové. Při nastavení firewallu nepracujeme s rozhraním dummyX, ale s virtuálním se zakončeným IPv6-in-IPv4 tunelem (v mém případě tun-ipv6). Při ladění pravidel doporučuji zapínat možnosti logování. Kromě správného nastavení firewallu doporučuji zaměřit se na konfiguraci jednotlivých služeb, zejména rozhraní a IP adres, na kterých služby naslouchají. Jednoduchý portmap, který lze použít pouze pro své rozsahy, lze najít na internetových stránkách HE.

Pokud budeme přes IPv6 přistupovat do internetu (myšleno bez NAT a překladů na IPv4), musí mít síťová rozhraní přiděleny adresy (tzv. globální), které jsou z nám přiděleného veřejného prostoru. K tomu používáme, kromě ručního/statického přidělení, funkci/vlastnost Router Discovery. Skrze RD se distribuují prefixy IP adres, směrování, MTU, adresy DNS serverů, apod. Při rozesílání prefixů lze tyto získat z lokální konfigurace nebo z nadřazeného směrovače. Ve druhém případě se prakticky o nic nemusíme starat. RD má však dva módy práce (nastavuje se v konfiguraci RD). Stateless a stateful. V módu stateless (viz NDP – Neighbor Discovery Protocol, SLAAC – Stateless Address Autoconfiguration) si IP adresy na základě prefixů přidělují sama koncová zařízení. V módu stateful se pro přidělování IP adres používá např. DHCPv6. V každém případě musíme pro využití RD na směrovači nainstalovat službu, která nám distribuci všech informací umožní. V GNU/Linux je to zejména radvd, bird6, v OpenWRT odhcpd. Mód stateful je vhodný pro řízené přidělování IP adres, DHCPv6, distribuci informací o doménách, automatických úpravách DNS záznamů, atd. Automatické přidělování IP adres pomocí DHCPv6 může být výhodné pro seskupování zařízení do určitých menších rozsahů. V takovém případě při konfiguraci firewallu na přístupovém hraničním směrovači nemusíme zadávat pro každou IP adresu zvláštní pravidlo, ale použijeme prefix (masku).

Ale pozor, RD démon musí být nainstalován a spuštěn na směrovači, který zpřístupňuje naši lokální síť např. do internetu. To z toho důvodu, že při distribuci výchozí brány klientům se bere v úvahu lokální linková adresa směrovače. Je možné směrovací záznamy distribuovat i jinak, ale to vyžaduje složitější nastavení a programové vybavení. Výchozí brána je také parametr, který nelze pomocí DHCPv6 nastavit.

Pokud chceme jednoduchou IPv6 síť bez DHCPv6 a podobných technologií, zvolíme při nastavování RD mód stateless. Ono je to se stavovou (stateful) a beze stavovou (stateless) konfigurací ještě o něco složitější. RD (SLAAC) odesílá v RA (Router Advertisment) příznaky A, M, a O. Těmi je klientovi oznámeno, zda má provést autokonfiguraci nebo požádat o pomoc DHCPv6. DHCPv6 podporuje beze stavovou autokonfiguraci (vlastně supluje SLAAC, ale přidává další užitečné možnosti) a stavovou (implementace DHCP, jak ji známe z IPv4). Ale opět zdůrazňuji, o výchozí bráně neinformuje DHCPv6 (DHCPv4 umí informovat o výchozí bráně IPv4), to má na starosti RD (např. bird, radvd, odhcpd, …).

Na OpenWRT jsem se pral s konfigurací odhcpd. Klientům nebyla distribuována výchozí IPv6 brána. Následně jsem zjistil, že přes je OpenVPN přidáno směrování 2000::/3 dev tun0, které je využito pro stejný účel, ale o výchozí bránu se nejedná. Ta je ::/0 dev tun0. A bez nastavené výchozí brány na směrovači, odhcpd nastavuje parametr Router lifetime na 0. Takže klienti nenastaví žádnou výchozí bránu. Pokud je na směrovači výchozí nastavena správně, je i parametr Router lifetime nastaven na hodnotu > 0. V takovém případě se na klientovi jako výchozí brána nastaví IP adresa lokálního linkového rozhraní směrovače, ze kterého je příslušný prefix distribuován. U radvd tento problém není. Řeším to tak, že pro příslušného klienta na OpenVPN serveru (parametr client-config-dir) přidávám směrování push route-ipv6 ::/0 2001:470:XXXX:0001::1. Tím říkám, že má klient do své směrovací tabulky přidat výchozí IPv6 bránu směřující na OpenVPN server (adresa 2001:470:XXXX:1::1).

Výše uvedeným je vyřešena autokonfigurace IP adres. Pro servery a služby adresy přiděluji ručně (např. 2001:470:XXXX:fef1::1). Lépe se pamatují. Dalším zařízením přiděluje IP adresy server DHCPv6. Ten je také zapisuje do DNS.

Připravenost operačních systémů

IPv6 podporuje velké množství moderních operačních systémů. Pokud používáme Windows, OS s jádrem Linux, MacOS, BSD, Solaris, AIX, aj, nebudeme mít nejmenších problémů. V případě různých chytrých televizorů a jiné spotřební elektroniky můžeme narazit na různé nekompatibility nebo nepodporu IPv6. Většina těchto zařízení je sice postavena na jádře Linux, ale podporu IPv6 zapnutu nemá. To samé platí v případě rádoby IoT zařízení. Ty nezřídka pracují pouze přes IPv4. V mnoha případech není provoz zabezpečen (např. SSL/TLS). Je to dáno zejména použitými mikrokontroléry (MCU), které mají nízký pracovní kmitočet a omezenou paměť (programová FLASH např. 32 kB, RAM 8 kB, …). Dokáží ale pracovat na jednu malou baterii i několik let.

Z běžných operačních systémů jsem se setkal s problémy pouze u OS Android (testována verze 5.1.1). Zde jsou problémy v případě nasazení DHCPv6. Už samotná implementace DHCPv4 postrádá některé důležité vlastnosti, mezi které patří např. nemožnost distribuce informací o proxy serverech. Podpora DHCPv6 bohužel chybí úplně a plánovaná není ani ve verzi 6. Pokud tedy používáme DHCPv6, tzn. v Router Advertisment máme nastaven příznak M, nebude mít zařízení s OS Android žádnou globální IPv6 adresu. Tedy ani vygenerovanou z prefixu získaném z Router Discovery. To může být velký problém ve firemním prostředí. Momentálně jedinou volbou je instalace aplikace DHCPv6 Client. Ta ale pro svůj běh potřebuje zařízení s možností privilegovaného přístupu – root.

Více o podpoře IPv6 v různých operačních systémech lze nalézt na Wikipedii.

Podpora aplikací

Aplikační podpora záleží na ochotě programátorů využívat IPv6 i použitých programovacích jazyků. V některých případech se o podporu při programování nemusíme starat, protože vše necháme na operačním systému. Při použití nižších programovacích jazycích, nebo práci se síťovými protokoly ve větší hloubce, se již musíme zabývat i podporou IPv4 vs. IPv6. Zejména starší aplikace nejsou na IPv6 připraveny. V případě aplikací napsaných ve vyšším programovacím jazyce (Java, .NET, PHP, …) je podpora pravděpodobnější. Ale jak jsem napsal, často záleží na ochotě programátorů, kteří si s tímto dvacet let starým protokolem hlavu nelámou.

Pokud si ale necháme nějakou aplikaci naprogramovat na zakázku, určitě bychom měli mít podporu IPv6 zajištěnu. U velkého množství aplikací končí vývoj předáním zákazníkovi a celý projekt bývá zakonzervován. Opětovné spuštění se může stát velice drahou záležitostí.

 

Samozřejmě jsem také zpřístupnil webové stránky i přes IPv6:

Tím jsem vyčerpal své postřehy z nastavení a provozu IPv6.