Šestého června 2012 je již druhý den IPv6, tentokrát nazývaný „World IPv6 Launch“ s podtitulem „this time it is for real“ (tentokrát doopravdy). Tento den pořádají CZ.NIC, EURid a NIX.CZ konferenci IPv6 Day v Národní technické knihovně v Praze.

Kdy jindy bychom měli zrevidovat podporu IPv6 ve Fedoře a v linuxových distribucích obecně než při „celosvětovém spuštění“. Serverové i klientské aplikace zpravidla IPv6 dávno podporují, zaměřme se tedy na systémovou infrastrukturu, tedy konfiguraci sítě a překlad jmen na adresy.

Router a server pro přidělování adres

Serverová strana je ta jednodušší část. Chová se jako aplikační software komunikující po TCP/IP a není zdaleka tak závislá na rozmarech jádra. Potěšující je fakt, že je ve Fedoře k dispozici vše, co je potřeba k obsluze všech běžných scénářů automaticky konfigurované sítě. Snad jediné, na co je potřeba při provozu těchto služeb dbát, je konfigurace firewallu.

Démon pro oznámení routeru

Démon jménem radvd zajišťuje pravidelné odesílání oznámení routeru dle přesné specifikace v souboru /etc/radvd.conf. Tento program nabízí velmi rozumné výchozí hodnoty, takže obsah konfiguračního souboru může být velmi krátký.

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    prefix 2001:db8:1:2::/64 {};
    RDNSS 2001:db8:1:2::ab {};
    DNSSL example.net {};
};

Takto napsaný konfigurační soubor poskytuje vše, co běžná síť potřebuje. Adresu si stanice doplní sama podle prefixu. Výchozí branou je odesilatel paketu. Seznam dns serverů a domén je v oznámení obsažen.

Jediný problém je ve výchozích dobách platnosti RDNSS a DNSSL, které jsou nesmyslně krátké. Jenže takto nesmyslně krátké mají být podle samotného RFC 6106. Nedostatky tohoto RFC jsou popsány v dokumentu, který se snad bude brzo probírat na půdě IETF.

Server pro přidělování adres

Konfigurace DHCP serveru pro místní síť je rovněž velmi jednoduchá.

/etc/dhcp/dhcpd6.conf:

subnet6 2001:db8:1:2::/64 {
    option dhcp6.name-servers 2001:db8:1:2::ab;
    option dhcp6.domain-search "example.net";
    range6 2001:db8:1:2::1:0000 2001:db8:1:2::1:ffff;
}

Aby ale byly tyto možnosti DHCP serveru využívány stanicemi na síti, musí k tomu být vyzvány oznámením routeru.

/etc/radvd.conf:

interface eth0 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    AdvOtherConfigFlag on;
    prefix 2001:db8:1:2::/64 {
        AdvAutonomous off;
    };
};

Rozdíl oproti předchozímu příkladu konfigurace radvd je v zapnutí AdvManagedFlag pro použití DHCP ke konfiguraci adres, zapnutí AdvOtherConfigFlag pro použití DHCP ke konfiguraci DNS a vypnutí AdvAutonomous na prefixu, aby nedošlo k autonomní volbě adresy stanicí. Navíc je vynechána konfigurace DNS, protože už je poskytnuta DHCP serverem.

DHCP server od ISC se neomezuje jen na přidělení adresy a předání dalších konfiguračních informací. Umí například routerům předávat celé prefixy pro sítě k nim připojené. Rovněž může být použit jako centrální server, který přijímá požadavky od stanic nepřímo prostřednictvím routerů s DHCP relay.

Automaticky konfigurovaná stanice

Strana stanice je naopak relativně komplikovaná a musí se umět vypořádat s různými situacemi, které na síti mohou vzniknout. Linuxové jádro řeší velkou část automatické konfigurace samo. Přesto je potřeba v uživatelském prostoru provozovat démona, který se postará o ten zbytek a případně doladí konfiguraci v jádře. Fedora 17 k tomuto účelu používá ve výchozím nastavení NetworkManager.

IPv6 v kernelu a SLAAC

Podpora protokolu IPv6 v linuxovém jádře má docela dlouhou historii - delší než jak dlouho já osobně s Linuxem pracuji. Jaderná implementace IPv6 má oproti IPv4 velký přesah. Jádro například implementuje automatickou konfiguraci linkových adres, globálních adres a směrování. Zpracovává tedy oznámení routeru a promítá ho do interních konfiguračních tabulek, které se dají zkoumat a modifikovat prostřednictvím netlinku.

Pro některé může být překvapením, že v jádře není podpora DNS. Takže ačkoli routery můžou předávat v oznámeních seznam rekurzivních DNS serverů (RDNSS) a seznam domén pro vyhledávání (DNSSL), jádro nemá kam tyto informace ukládat. Je tedy potřeba v uživatelském prostoru prozovovat nějakého démona. Tím démonem je ve Fedoře 17 standardně NetworkManager, a to jak na desktopu, tak na serveru. Existuje samostatná implementace konfigurace DNS jménem rdnssd, ale verze s podporou DNSSL zatím nebyla vydána.

DNSSL v jádře 3.3 nefunguje a nebude fungovat ani v jádře 3.4. Podpora by se měla objevit v jádře 3.5. Implementace DNSSL v NetworkManageru spoléhá na to, že jádro předá informaci o DNSSL do uživatelského prostoru, což se neděje. NetworkManager tedy implementuje něco, co mohlo být testováno pouze s patchovaným jádrem. Škoda jen, že se patche tehdy nedostaly do upstreamu.

RDNSS zase trpí problémy s expirací. Podle RFC 6106 se má doba platnosti nastavovat na hodnotu někde mezi maximálním intervalem odesílání oznámení routeru a jeho dvojnásobkem. To v kombinaci s nespolehlivou linkovou vrstvou (typicky 802.11 wifi) způsobuje předčasnou expiraci informace o nameserveru, na kterou navíc NetworkManager reaguje zahozením celého spojení včetně IPv4. Tento problém má více řešení a jedním z nich je vynucovat na stanici rozumnou minimální dobu platnosti.

Linuxové jádro se samo stará o konfiguraci směrování a výchozích bran podle oznámení routeru. To může být na škodu v případě, že se démon v uživatelském prostoru snaží z možných výchozích bran zvolit jednu konkrétní. Toto chování lze vypnout pomocí přes sysctl net.ipv6.conf.*.accept_ra_defrtr, ale jádro pak do uživatelského prostoru nepředává informaci o výchozích bránách, ze kterých si démon potřebuje vybrat. NetworkManager to momentálně obchází tím, že accept_ra_defrtr nechává povolené a přidává kopii vybrané výchozí routy s vyšší prioritou.

Konfigurace adres pomocí DHCPv6

Konfiguraci pomocí DHCP musí spustit démon v uživatelském prostoru (například NetworkManager), který od jádra dostane volby z oznámení routeru. Na jejich základě spouští DHCP klienta pro zjištění adresy, zjištění informací o DNS nebo obojího.

NetworkManager samotný momentálně trpí chybou, která může způsobit, že konfigurace adresy tiše selže. Jiná chyba způsobuje selhání přidávání výchozí brány při konfiguraci adres pomocí DHCP, ačkoli se směrování protokolu DHCPv6 vůbec netýká. Méně závažná je chyba, která způsobuje, že se použije DNS z DHCPv6, přestože to v oznámení routeru nastaveno není.

Multicast DNS

Pro lokální komunikaci se hodí mít možnost kontaktovat ostatní počítače podle jejich jména nezávisle na DNS serverech. K tomu slouží protokol mDNS, doména .local a software jménem Avahi.

Avahi na IPv6 funguje vcelku bez problémů, ale jeho podpora IPv6 je ve Fedoře i v upstreamu ve výchozí konfiguraci vypnutá, což je podle mě škoda. Navíc to už bylo v minulosti hlášeno jako chyba a opraveno.

IPv6 navíc poskytuje stálé linkové adresy, jejichž užitek by byl mnohem větší, kdyby byly přístupné i prostřednictvím jména. To by mělo být umožněno NSS modulem nss-mdns, který předává knihovně glibc informace z Avahi. Bohužel to ale vypadá, že glibc implementace NSS nepodporuje getaddrinfo - na rozdíl třeba od implementace ve FreeBSD, a tudíž nemůže vracet linkové adresy doplněné o název síťového rozhraní.

fe80::5054:ff:feeb:e9fb%eth0

Závěr

Implementace IPv6 v jádře funguje dobře včetně konfigurace adres. Konfigurace směrování není dostatečně flexibilní a neposkytuje démonům v uživatelském prostoru dostatečnou podporu. Konfigurace DNS je řešena pouze přes uživatelský prostor a od verze 3.5 by měla být plnohodnotná. Zmíněné chyby NetworkManageru budou opraveny v příští verzi, která by měla vyjít koncem června. O možném řešení problému s Avahi a glibc zatím nemám informace.

Opravy průběžně zveřejňuji ve větvi ipv6 gitovského repozitáře git.pavlix.net/NetworkManager a následně se objevují ve větvi master oficiálního repozitáře NetworkManageru na freedesktop.org.

Poděkování patří mému novému a zároveň prvnímu zaměstnavateli, který se rozhodl mi platit za hraní si s věcmi, o kterých zde píšu.