Mikrotik IPv6 prefix-delegation

ludvik

Zkoušel jste někdo, zda jim to vůbec funguje (ROS 5.13)? Hraju si s tím proti (relativně) čistému linuxu - widedhcp6. A ať dělám, co dělám, linux si PD prostě nevezme. Vidím, že se dotazuje, ale mikrotik mu neodpoví ani "trhni si", prostě ani paket.

Pool definovaný je, IP přiřazenou interfacu také mám (a je v Used prefixes), v ND zapnuto jak Managed, tak Other Configuration.

Vše ostatní funguje, bezestavová konfigurace je ok.

ludvik

Dalším zkoumáním jsem zjistil, že je zjevně posílán trochu nestandardní DUID. Wide-dhcpd v roli serveru to nevadí, ale mikrotiku jo. Ten je z toho tedy zjevně z obliga.

zajdee

Když si hraješ s Prefix Delegation na Mikrotiku, povedlo se ti dostat přidělený prefixy do routovací tabulky? Nevidím pro takovou akci nikde volbu, DHCPv6 server vydá prefix, ale routerboard ho nedokáže naroutovat, protože v routovací tabulce ho nemá...

ludvik

Je to jako Static routa. Takže v OSPF musí být redistribute static, sice redistribuce nemám rád, ale v tomhle případě není asi jiná možnost.

zajdee

Teď koukám, že mi 5.14 přidala v jednu chvíli routu sama do routovací tabulky taky jako static, při předcházejících testech ale ne (první test byl, že jsem prefix .../64 dal na wlan a širší /56 jako dhcpv6 pool, načež mi dhcpv6 vydalo /62 pro klienta, ale nepřidalo ho do routovací tabulky, protože se překrývalo s tou /64 na wlan rozhraní; druhej test byl, že /56 se s /64 nepřekrýval a při tom se routa do routovací tabulky nainstaluje).

Možná by stálo za to, zkontaktovat vývojáře z Mikrotiku s připomínkou, že by automaticky instalovaná routa měla mít příznak Connected a ne Static, když už má i příznak Dynamic a instaluje/odebírá se automaticky při dhcp vydání/vrácení (při release dojde k automatickýmu odstranění routy).

ludvik

Jestli static, nebo connected asi moc roli nehraje. Mě spíš obecně rozčiluje, že musím mít nějakou redistribuci. Ono mít z poloviny routerů ASBR asi není zrovna ideální.

Kdyby tak šlo ten pool přihodit na rozhraní jako adresu /56, to by řešilo. Jenže to nejde.

zajdee

Pomohla by agregace rout, aby se v OSPFv3 distribuovaly jen celý prefixy... ale nejsem si jistej, jestli to mikrotikácký OSPFv3 umí.

ludvik

No jak na co by to pomohlo ...

Podle mě se ale tohle nezměnilo, agregovat můžeš na hranici area. A ani quagga sama neumí zatím arey v OSPFv3.

Pomohla by agregace rout, aby se v OSPFv3 distribuovaly jen celý prefixy... ale nejsem si jistej, jestli to mikrotikácký OSPFv3 umí.

ludvik

Takže z obliga mikrotik rozhodně není. Vypadá to, že si u nich někdo přečetl jenom kousek RFC 3315 a to samozřejmě nestačí.

Clients and servers MUST treat DUIDs as opaque values and MUST only

compare DUIDs for equality. Clients and servers MUST NOT in any

other way interpret DUIDs. Clients and servers MUST NOT restrict

DUIDs to the types defined in this document, as additional DUID types

may be defined in the future.

Z tohoto odstavce vyplývá, že jako DUID může být zjevně naprosto cokoliv. Mikrotik ale vyžaduje striktně formáty uvedené v tomto RFC (zkoušel jsem ovšem jen typ 3) a neakceptuje nic jiného. Kromě toho s tím zjevně ještě pracuje naprosto špatně, protože v Bindings ukáže jen posledních 6 bajtů toho DUID (tedy v případě typu 3 je to MAC), ale musí ukázat i ty 4 bajty před mackou. Je to sice lepší pro člověka, ale je to špatně.

Dalším zkoumáním jsem zjistil, že je zjevně posílán trochu nestandardní DUID. Wide-dhcpd v roli serveru to nevadí, ale mikrotiku jo. Ten je z toho tedy zjevně z obliga.

ludvik

Reakce supportu byla, že mi poslali odkazy na rc verzi 5.15 :-) Sice už mikrotik sežere (zjevně) libovolný formát DUID, ale stále s tím pracuje špatně. Pokud je to nějaký správný typ, ubere si z toho první 4 bajty. Pokud je to něco jiného, ubere první dva. By mě zajímalo, jestli mají vůbec nějakého fundovaného testera ... kromě nás zákazníků.

ludvik

A poslední zprávy:

Hello,

Thank you for information, glad to hear that now it works. The problem when you don't see full DUID will be fixed in one of the future versions.