IPv6 v domácích směrovačích

Tato zařízení v sobě typicky kumulují celou řadu funkcí – ADSL modem, ethernetový přepínač, WiFi AP, směrovač, NAT, firewall, DHCP server, DNS server a nejspíš jsem ještě na něco zapomněl. To vše se snaží nabídnout v uživatelsky přítulném balení s (pokud možno) nulovou obsluhou.

Proti implementaci IPv6 v nich hovoří několik faktorů:

• Musí být co nejlevnější. Zákazníci tohoto typu zařízení jsou velmi citliví na cenu. Jakákoli komplikace, jako třeba IPv6, je pochopitelně prodražuje.

• Typickým uživatelem je naprostý laik. Ovládání by proto mělo být co nejjednodušší a jakákoli komplikace je překážkou.

• Trh nemá zájem, a to jak ze strany poskytovatelů ADSL připojení, tak ze strany jejich zákazníků.

Dobrou zprávou naopak je, že tato zařízení jsou poměrně často založena na Linuxu. Doplnění podpory pro IPv6 by proto nemělo představovat principiální problém. Otázkou samozřejmě je, jak by se zařízení mělo chovat a jaké funkce by mělo vykonávat.

Pracovní skupina IPv6 Operations se snaží výrobcům usnadnit situaci a pracuje na dvou dokumentech popisujících tato domácí zařízení:

• draft-ietf-v6ops-ipv6-cpe-router – obecný popis chování domácích směrovačů a požadavků na ně kladených,

• draft-ietf-v6ops-cpe-simple-security – základní zabezpečení pro připojenou koncovou síť.

Oba dokumenty se zabývají čistě světem IPv6 a až na výjimky neřeší vztah s IPv4, překlady paketů či tunelování. Základní chování by podle nich – celkem očekávaně – mělo silně připomínat stávající IPv4 zařízení.

Jeho pilířem je pochopitelně směrování IPv6 a podpora automatické konfigurace sebe sama i počítačů v lokální síti. Ta může mít dvě podoby – stavovou (DHCPv6) a bezstavovou. Dokument požaduje na straně WAN podporu obou typů, aby se zařízení mohlo zapojit do libovolného typu sítě. Pro stranu LAN jsou požadavky benevolentnější a výrobce si může vybrat jen jeden způsob automatické konfigurace.

Upřímně řečeno mi představa bezstavové konfigurace na straně WAN připadá jako poměrně absurdní. Ve vztahu k poskytovateli bych jednoznačně očekával použití DHCPv6. Zejména proto, že umožňuje předat i prefix koncové sítě a vytvořit tak základ pro přidělení globálních adres místním strojům. Pro poskytování konfiguračních údajů na straně LAN připadá nejspíše v úvahu kombinace bezstavové konfigurace adres na základě ohlášení směrovače, doplněná bezstavovým DHCPv6 s adresami DNS serverů a dalšími údaji.

Ohledně adresování dokument logicky požaduje, aby zařízení každému LAN rozhraní přidělilo standardní 64bitový prefix podsítě. Normální (alespoň doufejme) procedura bude, že pomocí DHCPv6 získá od poskytovatele 48bitový (případně 56bitový) globální prefix sítě a z něj pak jednotlivé části přidělí místním strojům. Jako záložní řešení se počítá s použitím unikátních lokálních adres (ULA podle RFC 4193), které jsou přímou analogií neveřejných IPv4 rozsahů 10.0.0.0/8 a spol. Na rozdíl od IPv4 ale nebudou překládány, slouží jen ke vzájemné komunikaci lokálních strojů v síti, která není připojena k IPv6 Internetu.

Sada bezpečnostních doporučení ve druhém ze zmiňovaných dokumentů se snaží o nalezení vhodné rovnováhy mezi uživatelským komfortem a bezpečností. Domácí směrovač by měl ochránit lokální síť před různými neplechami přicházejícími zvenčí. Ve stručnosti lze doporučení pro jeho chování shrnout do dvou základních bodů:

• Základní kontrola paketů: Měly by se zahazovat IPv6 datagramy s nepřípustnými adresami (falšovaná adresa odesilatele, různá omezení adres plynoucí ze specifikací IPv6) a hlavičkami (například směrovací hlavička typu 0).

• Stavový firewall transportní vrstvy: Podobně jako dnes by si zařízení mělo udržovat informace o probíhající komunikaci. Nový datový tok by mělo umožnit navázat jen směrem z lokální sítě ven do Internetu. Pakety v protisměru budou propuštěny, jen pokud se jedná o pokračování nějaké již probíhající konverzace.

Jinými slovy se předpokládá, že tato zařízení, podobně jako jejich současné IPv4 protějšky, budou volně prostupná jen směrem zevnitř. Tato asymetrie, původně vynucená vytvářením tabulky pro překlad IPv4 adres v NATu, se prosadila jako dodatečný bezpečnostní mechanismus a v této podobě už s námi zřejmě zůstane. Aplikacím se plete pod nohy, nicméně je už dnes vnímána jako součást každodenní reality a vývojáři se s ní musí nějak vyrovnat.

V dokumentu se jinak doporučuje, aby domácí směrovače byly spíše liberální a nebrzdily potenciální vývoj nových síťových služeb. Proto se například požaduje neomezovat tunelovanou komunikaci a VPN. Jedinou výjimkou jsou Teredo tunely, které by měly být blokovány, pokud je k dispozici nativní IPv6.

Samozřejmě je jedním z požadavků i možnost manuální konfigurace a změny uvedených pravidel. Na druhé straně ale dokument přiznává, že velká část zařízení tohoto typu nikdy ruku konfigurátora nepozná – uživatelé je koupí, zapojí a provozují bez jakéhokoli zásahu do nastavení. Proto je velmi důležité, aby se implicitně chovala co rozumněji.

V dokumentech pochopitelně najdete výše zmiňované obecné zásady rozpracované do řady konkrétních požadavků a pravidel. Vzhledem k tomu, že se jedná stále ještě o pracovní verze, lze očekávat dílčí změny. Základní myšlenky se ale nejspíš již měnit nebudou.

Přestože jsem v úvodu napsal, že tato část trhu je IPv6 nepolíbena, neplatí to absolutně. Již dnes existují domácí směrovače, které dokáží jeho podporu nabídnout. Známé jsou například výrobky firmy MikroTik. Na podzimním RIPE meetingu bylo prezentováno nasazení FRITZ!Box a ani Cisco Systems nestojí stranou se svým Cisco 877. Ovšem teď se čím dál tím víc vzdalujeme od představy levného, jednoduchého zařízení. Doba, kdy průměrná domácí krabička v ceně kolem tisíce korun nabídne výše popsané funkce, ještě zdaleka nenastala.