Mikrotik, IPv6 a dobrý oběd

27.9.2012 19:58 | Přečteno: 3985× | linux/unix | | poslední úprava: 27.9.2012 19:58

Ač už můžu protokolu IPv6 věnovat jen minoritu svého času, pustím se do dalšího lehce sarkastického a rádobyvtipného zápisku na toto téma. Navštívil mě jeden lektor MikroTik s cílem vyzkoušet schopnosti MikroTiku fungovat jako router pro IPv6 síť. A protože jsem se už dříve opíral do vyhášení World IPv6 Launch v době, kdy ještě nejsme na IPv6 připraveni ani po softwarové stránce, došel jsem si preventivně na dobrý oběd (lunch).

Nedávno vyšel nový NetworkManager 0.9.6 s mými opravami IPv6 a Linux 3.5 s opravou DNSSL, takže se distribuce s těmito verzemi balíků dá považovat za relativně IPv6 ready. Díky tomu máme k dispozici kompletní klientskou konfiguraci, která se dá použít k testování routerů a DHCPv6 serverů. Díky radvd a dhcpd6 (ISC DHCP) je tato klientská implementace otestovaná oproti funkčím konfiguracím IPv6 vycházejícím z různých metod automatické konfigurace.

Testovali jsme aktuální verzi MikroTik RouterOS (5.20) a řešili jsme jeho schopnost poskytovat automaticky konfigurovaný protokol IPv6 do domácí sítě pro stroje s linuxovou distribucí (upravená Fedora, NetworkManager >= 0.9.6, kernel >= 3.5) a Windows (sedmičky).

Vše v oznámení routeru

Nejjednodušší konfigurace je kompletně pomocí oznámení routeru. Adresa se konfiguruje pomocí SLAAC (autonomní doplnění prefixu) lokální směrování pomocí informace o prefixu, výchozí brána ze zdroje oznámení a DNS pomocí voleb v oznámení routeru. Linuxové jádro umí všechno kromě DNS, které zajišťuje NetworkManager (nebo jiný nástroj). O Windows je známé, že DNS v oznámení routeru nepodporují vůbec. RouterOS tuto volbu nabízí, nicméně radvdump prozrazuje, že ji ve skutečnosti vůbec neposílá.

DNS pomocí DHCP

To ještě není žádná tragédie. Alternativou k této možnosti je delegace konfigurace DNS na DHCP server. Dělá se to pomocí volby AdvOtherConfigFlag v oznámení routeru. Klient pak pošle jednoduchý Information Request DHCP serveru. DHCP server v RouterOS ovšem na tuto volbu nereagoval.

Adresa a DNS pomocí DHCP

Na DHCP se dá delegovat i získání adresy. Možnost zároveň získat informace o DNS je pak brána jako samozřejmost. Klient použije DHCP k získání adresy v případě, že v oznámení routeru dostane AdvManagedFlag. Směrování se stále řídí oznámením routeru. RouterOS s nakonfigurovaným rozsahem adres nereagoval ani na tento DHCP dotaz, tedy dotaz na IA_NA (adresu pro stroj v síti). Navíc konfigurace rozsahů adres nutně vyžaduje jak prefix (včetně délky prefixu), tak i „délku prefixu“, která navíc musí být delší (určovat menší síť), než délka specifikovaného prefixu. To napovídá, že se RouterOS snaží implementovat IA_PD, tedy pokročilou funkci, která zajišťuje delegaci menších prefixů vybíraných z větších. Ale základní funkce protokolu DHCPv6 jaksi nikde.

Je libo oběd nebo skutečný start IPv6 na MikroTiku?

Disclaimer: Může se stát, že jsme něco s nedostatkem dokumentace prostě netrefili. Pokud někdo předvede funkční konfiguraci sítě na MikroTiku s plnohodnotnou automatickou konfigurací v podobě vhodné pro provoz testovací IPv6-only sítě, odměna ho nemine.

V tuto chvíli tedy docházím k závěru, že současná verze Mikrotik RouterOS provozu IPv6-only sítě s automatickou konfigurací uzlů není schopná. Na dualstacku s IPv4 a IPv6 je nutné automatickou konfiguraci DNS řešit pomocí IPv4.

       

Komentáře

[Sten]

Mám Mikrotik s IPv6 RA a DNS posílá, ale je to trochu zmatené, posílá totiž IPv6 adresy uvedené v ip dns servers. To ale znemožňuje mít Mikrotik jako DNS cache či DNS server pro lokální síť v IPv6-only sítích. Tak snad v nové revizi RouterOS bude možné uvést ty DNS servery do RA ručně.

[pavlix]

A funguje to i když je kromě IPv6 nameserveru v dns servers i nějaký IPv4? Nicméně DHCP IPv6 DNS bude stejně potřeba kvůli Windows.

[Sten]

Ano, potom IPv6 může být adresa Mikrotiku a IPv4 adresa veřejného serveru a DNS cache pak na Mikrotiku funguje. Přesně tak to teď mám.

[belisarivs]

A co NAT na IPv6. Strasne dulezita vec.

Ted vazne, delate i nejake testy? Ja si vzpominam, kdyz jsem pomoci Tahi Testsuite (dafuq? Oni povazuji svoji praci na podporu IPv6 za dokoncenou a na konci roku bali?) testoval jak si s IPv6 umi poradit SLES. Nebylo to zas tak spatne.

Tusim, ze MIPv6 tomu moc neslo, ale jinak se to celkem dalo.

[pavlix]

Ted vazne, delate i nejake testy?

Tohle byl test (RouterOS). A vyšel negativně. Na NetworkManageru používám vlastní (převážně ruční) testy.

Oni povazuji svoji praci na podporu IPv6 za dokoncenou a na konci roku bali?

To je hezké, že to balí v době, kdy jsou standardy stále ještě napsané tak, že je musím v NetworkManageru porušovat, aby třeba zrovna to DNS v RA fungovalo správě a nevypršelo dřív, než dostanu nové.

testoval jak si s IPv6 umi poradit SLES. Nebylo to zas tak spatne.

To věřím, jednu dobu disponovali nějakou certifikací na IPv6. Certifikace jsou z obchodního hlediska důležité, ale je fajn alespoň dodatečně opravit i tu implementaci.

Největší problém je s tou autokonfirací a tam mi pár lidí tvrdilo, že už to fungovalo. Tak jsem došel k závěru, že to bylo rozbito dodatečně. Ale během opravování jsem tento závěr přehodnotil a teď jsem přesvědčen o tom, že některé věci fungovat ani nemohly.

A kromě formální funkčnosti je ještě dobré aby věci do sebe zapadaly. Momentálně třeba GLIBC není schopné správně resolvovat link-local IPv6 a za určitých okolností nezvládne ani IPv6 localhosta, případně dokonce IPv4 localhosta.

Kernel se k IPv6 DNS staví tak, že to stačí přeposlat userspace. Taky špatně userspace potřebuje informace, ne pakety, ty si může démon vyzvednout jednoduše sám, a ty informace kernel okamžitě zahazuje a necachuje je po určenou dobu.

Je toho víc, některé věci se dají jednoduše obejít, jiné složitěji, ale to obcházení je většina práce s IPv6 v NetworkManageru.

[belisarivs]

Hm. Pekne. :-/ Cekal jsem, ze to bude teda lepsi.

Jak je na tom *BSD? Tahi se specializuje na nej.

[pavlix]

Jak je na tom *BSD? Tahi se specializuje na nej.

libc vypadá dobře, mají patch pro Avahi, takže je to jediný systém, kde multicast DNS funguje na link-local IPv6, tedy skutečný zero configuration networking. U kernelu si nejsem úplně jistý, čekal bych, že BSD na tom bude o něco lépe, ale když se podívám na linuxovou implementaci třeba IPsecu, tak ta se mi vyloženě líbí.

Ale, nevím o tom, že by BSDčkáři měli nějakého rozumného síťového démona. NetworkManager je možná chybový a neoblíbený (to první se teď hodně mění, a to druhé je problém důvěry a ta se nezískává ze dne na den), ale dokáže zajistit jak plnohodnotnou konfiguraci IPv6 od RA po DHCP, tak koordinaci dualstacku, tak koordinaci konfigurace více síťových rozhraní.

Dokud nebudou mít něco na této úrovni (a pokud možno méně chybového, ale na tom taky pracujeme), nedá se mluvit o plnohodnotné klientské implementaci IPv6. Tady mám pocit, že byl Microsoft o něco málo napřed, nevím jak Apple.

[Petr Tomášek]

To je hezké, že to balí v době, kdy jsou standardy stále ještě napsané tak, že je musím v NetworkManageru porušovat, aby třeba zrovna to DNS v RA fungovalo správě a nevypršelo dřív, než dostanu nové.

To jsem rád, že konečně přiznáváš, že IPv6 je zmršenej paskvil...

[pavlix]

Trolling is a art.

[pavlix]

A co NAT na IPv6. Strasne dulezita vec.

Zase tak důležitá věc to není, ve chvíli, kdy nejde autokonfigurace. Navíc není zatím úplně známo, jaké konfigurace NATu budou na IPv6 skutečně poptávané. Já zatím od mikrotiku nečekám zázraky, ale základní funkcionalitu domácího či malofiremního IPv6 routeru. Na druhou stranu už zvládá držet na IPv6 spoustu služeb a zvládá celkem funkci propojovacího a hraničního routeru. Od verze 5 umí IPv6 provoz omezovat.

[belisarivs]

A to jsem si myslel, ze vetou "Ted vazne" dam dostatecne najevo, ze si delam prdel z tech ocasu co to tak nutne potrebovali.

[pavlix]

Je několik use cases, kde je nějaká forma NATu nebo řešení à la TPROXY či inetd+netcat ku prospěchu. A je pár případů, kdy je nějaká forma NATu pro malého ISP levnější než standardní řešení (multihoming).

Když jede web, volá mnohem míň lidí a dá se problém v klidu řešit.

~Malý ISP, který si nosí callcentrum v kapse a je sám sobě technikem

[ludvik]

S tím domácím routerem bych byl opatrnější Neumí přijmout z DHCP jednu adresu (pro WAN) a PD pro LAN. Resp to neuměl o pár verzí zpět, teď nevím. Ale v každé případě neuměl přijmout defaultu (a já ji pro změnu do DHCP nacpat). Pokud to necháme na SLAAC narazíme na to, že je to router a ten má vypnutý příjem RA. A router to mít zapnuté prostě nesmí a nesmí To, že tohle chování lze vypnout a leckdy se to hodí mikrotik ignoruje.

Takže jako domácí router máme jednu jedinou možnost - konfigurovat IPv6 celé ručně.

Pokud mikrotik sloužil jako DHCP server a měl dávat PD, měl problém s formátem UUID. RFC si vyložil tak striktně, že jaksi zapomenul na tu třetí "libovolnou" možnost.

Dle mých zkušeností je to použitelné jen jako "infrastrukturní" router. To je v pohodě. A případně klientům dávat jen SLAAC. Nic víc od toho nechtít.

[pavlix]

A router to mít zapnuté prostě nesmí a nesmí

Citation needed.

Dle mých zkušeností je to použitelné jen jako "infrastrukturní" router.

Zajímavé. Mám za to, že přesně to jsem psal.