13.09.2026 · Самуил Арсов · IPv6, MikroTik, Рутери

IPv6 prefix delegation в реална ISP мрежа (част 1): /60 за всеки клиент и връзката с IPv4 билинга

Тази поредица е за колеги, които въвеждат IPv6 в собствена мрежа — с граничен рутер, комутатори, радиолинкове и оптика. Не е ръководство „как се пуска IPv6“. Това е дневник на няколко дни работа, в който раздадохме префикси на първите бизнес клиенти и се сблъскахме с неща, които ги няма в документацията. Реалните адреси ще ви спестя: всички IPv6 префикси в текста са от документационния диапазон 2001:db8::/32, а IPv4 адресите — от 198.51.100.0/24.

Защо prefix delegation, а не SLAAC в клиентския VLAN

Бизнес клиентите ни почти без изключение имат собствен рутер — най-често MikroTik — и зад него няколко мрежи: офис, гости, камери, понякога отделни VLAN-и за различни отдели. Ако им дадем един /64 в споделения клиентски VLAN, те нямат какво да разпределят навътре. Затова всеки получава цял /60 чрез DHCPv6 prefix delegation — това са 16 отделни /64 мрежи, по една за всяка вътрешна мрежа на клиента. Границата на отговорност остава ясна: до WAN порта на клиентския рутер е наша, зад него — негова.

Как е направено на граничния рутер

Граничният рутер е MikroTik CCR2116 с RouterOS 7.24. Схемата е проста и нарочно строга:

от нашия /48 е заделен един /52 за клиентски делегации — 256 броя /60;
по един DHCPv6 сървър на всеки клиентски VLAN, в който има бизнес клиенти;
сървърите раздават само статични binding-и — непознато устройство не получава нищо.

/ipv6 pool
add name=pool1 prefix=2001:db8:100:1000::/52 prefix-length=60

/ipv6 dhcp-server
add name=vlan_65 interface=vlan65 address-pool=static-only prefix-pool=static-only \
    lease-time=1d rapid-commit=yes

/ipv6 dhcp-server binding
add server=vlan_65 address=2001:db8:100:1010::/60 prefix-pool=pool1 life-time=1d \
    duid=0x00030001021122334455 iaid=1 comment="198.51.100.57 Клиент А"

Настройка	Защо
`prefix-pool=static-only`	Префикс получава само клиент, за който ръчно има binding. Същата логика като при IPv4 — никакви динамични адреси в клиентския VLAN.
Маршрут към всеки `/60`	Рутерът сам слага динамичен маршрут към link-local адреса на клиентския рутер, щом binding-ът стане `bound`.
BGP анонсира само `/48`	DHCP маршрутите не са нито `connected`, нито `static`, а out-филтрите пускат само агрегата. Двойна защита срещу изтичане на `/60` към горните доставчици.
Blackhole за `/48`	Незаетите `/60` падат в него — трафик към тях не се връща към доставчика в цикъл.

DNS: съобщението, което ме подведе

В /ipv6 nd на граничния рутер всеки запис носи бележка:

;;; automatic dns option advertising is not started, re-apply dns config

DHCPv6 сървърът пък няма нито един DNS option. Първото ми заключение беше, че клиентите не получават IPv6 DNS. Документацията на MikroTik казва изрично, че DHCP сървърът подава DNS от /ip dns — но само за IPv4. За DHCPv6 не пише нищо. Съобщението в /ipv6 nd също не се среща нито в документацията, нито в changelog-овете, нито във форума.

Затова проверих от страната на клиента. На клиентски рутер в /ip dns IPv6 адресът на нашия резолвер стоеше в dynamic-servers, т.е. е получен, а не вписан. По-късно в запис на DHCPv6 обмена се видя и самият отговор на граничния рутер:

dhcp6 reply (... (rapid-commit) (DNS-server 2001:db8:100:2::6) (IA_PD IAID:2 ...))

DHCPv6 сървърът на RouterOS сам слага IPv6 сървърите от /ip dns в отговора. Съобщението в ND засяга само RDNSS в Router Advertisement, а RA-то клиентските рутери така или иначе игнорират — те са с forward=yes и accept-router-advertisements=yes-if-forwarding-disabled. Клиентският рутер после препредава DNS-а към своя LAN с RA.

Липсата на нещо в документацията на MikroTik не значи, че функцията липсва. Проверявай на пакетно ниво, преди да „поправяш“ работеща конфигурация.

Как IPv6 да разбере, че клиентът не е платил

Билингът управлява IPv4: налива статични DHCP lease-ове, а един скрипт на рутера на всеки час ги пуска или спира според списъка с платилите. За IPv6 билингът не знае нищо. Идеята беше binding-ът да се спира, когато се спре IPv4 lease-ът на същия клиент. Нужна е връзка между двете.

Защо не по MAC адрес

Първото, което идва наум: DUID-ът тип LL съдържа MAC адрес, IPv4 lease-ът също. Сравнихме ги за първите клиенти и се оказа, че не става:

Какво видяхме	Защо е проблем
MAC-ът в DUID-а не е на WAN порта	По подразбиране DHCPv6 клиентът на RouterOS е с `use-interface-duid=no` и прави DUID от системен MAC (обикновено на ether1), а не от порта, през който иска префикс.
DUID сочи към друг договор	Един клиент имаше два акаунта на два порта на същия рутер. DUID-ът беше от първия порт, а IPv6 минаваше през втория. Връзка по MAC щеше да спре грешната услуга.
Клиенти без IPv4 lease	Някои са с ръчно зададен IPv4 адрес — няма lease, с който да се сравни.

Решението: IPv4 адресът в коментара

Връзката е изрична: всеки binding започва коментара си с IPv4 адреса на клиента, например 198.51.100.57 Клиент А. Скриптът прочита адреса и го сверява със същия списък, по който спира IPv4. Binding без адрес в коментара не се пипа.

Паралелно на клиентските рутери сложихме use-interface-duid=yes, за да е DUID-ът предвидим. Внимание: щом DUID-ът се смени, статичният binding вече не познава клиента и той остава без IPv6, докато не се смени DUID-ът и на граничния рутер. Редът е: смяна на клиента → смяна на binding-а → renew.

Какво още не е направено. Спирането на IPv6 при неплащане засега е само подготвено — коментарите са сложени, но скриптът още не пипа binding-ите. Преди това трябва да се провери какво точно прави disable на binding: маха ли маршрута веднага и какво става с префикса, който клиентският рутер пази до изтичане на lease-а.

В следващата част — капаните от страната на клиентския рутер: IAID-ът, който не се вижда в конфигурацията, pool-prefix-length=68 и един клиент, който след рестарт не можеше да вземе префикс, въпреки че всичко беше наред.

Всички части от поредицата

Част 1: /60 за всеки клиент и връзката с IPv4 билинга — как граничният рутер раздава префикси, DNS през DHCPv6 и защо не по MAC
Част 2: IAID, pool 68 и заклещеният NDP — капаните в клиентския рутер
Част 3: Когато IPv6 се губи по пътя — радиа с IGMP snooping без querier и ONU-та, през които не минава
Част 4: Два неканени гости — DHCPv6 в мениджмънта на радиолинк, IGMP querier от чужд VLAN и чеклист