Predavani MAC v relay agentech je i v RFC, jen malo podporovane na strane relay agentu i serveru (https://tools.ietf.org/html/rfc6939). IAID, DUID i MAC ovsem klienti mohou smadno zmenit, takze v pristupovych sitich spis budete chtit klienta identifikovat pomoci ID portu, ke kteremu je pripojen, napr. pomoci Option 37 (https://tools.ietf.org/html/rfc4649). To je ovsem zridka podporovane.
Absence podpory instalace delegovanych prefixu do routovaci tabulky je taky dobry fcuk-up.
Mikrotik dal nema funkce potrebne pro konzervovani IPv4 a podporu single-stack ISP siti (DS-Lite, MAP-E/T, lw4o6), takze ISP jsou nuceni provozovat dual-stackove pristupove site.
Celkove jsou kluci z Lotysska spis brzdou IPv6 u ISP, nez aby ji nejak realne podporovali. Snad se to s RouterOS v7 zmeni.
30. 11. 2019, 21:06 editováno autorem komentáře
Co je myšleno tím "bez závislosti na DUID"? Vždyť to je povinnost ... Přidělování dle MAC existuje jako neoficiální bastl do ISC DHCP (a to nevím, jestli to už neumřelo).
Přidělování prefixu z DHCPv6 je na mikrotiku v pořádku. Problém je spíš v tom, že vyžaduje i IAID - a s tím už člověk bojuje jen těžko. Jsou zařízení (TP-LINKy s logem IPv6 ready) co si generují IAID nový po každém rebootu. Tedy nejde udělat statický příděl. A pokud se porouchá (nebo blbne elektřina), tak je schopen vyčerpat pool poměrně rychle.
Kdysi měli chybu, že kašlali na RFC které říká, že DUID je prostě jen číslo ... které sice může něco znamenat, ale nemusí. Ale to už neplatí.
Obrovský problém je, že mikrotik sice má DHCP relay, který nedokáže zapsat přidělený prefix do routovací tabulky. A v této funkci nemá ani možnost spuštění scriptu. Takže je to funkce v podstatě nepoužitelná.
A asi obecně je problém v přidělování prefixů ta závislost na záznamu v routovací tabulce. Stačí reboot toho routeru a pokud se tam vyskytne chyba, po dobu platnosti přídělu (což je ve výchozím stavu 3 dny) klientovi ipv6 prostě nejede ... Mikrotiku tohle funguje v pořádku, ale už se mi stalo, že to nepřežilo upgrade software. A není možnost donutit klienty k renew (leda telefonem). Čili je nutné používat hodně nízký pronájem time (když to napíšu anglicky, je můj příspěvek spamem) jen tak pro jistotu.
U DSL a optiky CETINu to neni problem technologie, ale operatora (nenasadil IPv6) a koncovych zarizeni (casto distribuovanych operatorem).
Pak jsou technologie (stacky), kde je jasna vina na strane technologie - typicky Mikrotik RouterOS, ktery horko tezko dokaze pridelovat (bez zavislosti na DUID) prefixy klientskym zarizenim (ktera mohou byt OK).
S tou IPv6 na DSL je to ještě žalostnější:
- IPv6 nad infrastrukturou CETINu aktuálně nabízí 18 operátorů, IPv6 umí 6 z nich (Viridium, Metronet, Avonet, O2, T-Mobile, UVT), z toho automaticky všem a minimálně blok o velikosti /56 nabízí 2~3 operátoři (UVT, T-Mobile, Metronet) a s dalšími dvěma se na přídělu IPv6 o velikosti bloku /56 dá dohodnout (Viridium, Avonet)
- Spousta modemů pro zákazníky iPv6 neumí správně (ZyXELy) a operátoři nehledají takové modely, které by byly s IPv6 kompatibilní
- Největší operátor (O2) vyměnil čínské modemy s podporou IPv6 (Comtrend) za vlastní model bez podpory IPv6, což vedlo k poklesu procentuálního rozšíření IPv6 v jeho síti (cca. od půlky roku 2017: https://stats.labs.apnic.net/ipv6/AS5610?a=5610&c=CZ&x=1&s=1&p=1&w=30)
O IPv6 se šíří spousta FUD, i když zahraniční operátoři ukazují, že na PPPoE (=u nás DSL) a mobilech je IPv6 v dnešní době nasaditelné prakticky bez velkých nákladů a starostí. Jen je třeba někdy začít, samo se to nestane.