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

IPv6 prefix delegation в реална ISP мрежа (част 2): IAID, pool 68 и заклещеният NDP

Дотук в поредицата

В първа част описах как граничният рутер раздава по /60 на всеки бизнес клиент само чрез статични binding-и, как DNS-ът стига до клиентите през DHCPv6 и защо връзката с IPv4 билинга е по IPv4 адреса в коментара, а не по MAC. Тук са капаните, които излязоха при самото добавяне на клиенти.

IAID: задължителен и трябва да съвпада

Първият нов клиент трябваше да е рутинен. DUID-ът беше известен, VLAN-ът също. Добавянето на binding обаче спря веднага:

Script Error: missing value(s) of argument(s) iaid

На RouterOS 7.24 статичният binding иска IAID (Identity Association ID). Сложих iaid=0 с идеята, че сървърът гледа основно DUID-а. Не гледа само него. Симптомите при грешен IAID:

Къде	Какво се вижда
Граничният рутер	Binding-ът стои `waiting`, `last-seen=never`.
Клиентският рутер	DHCPv6 клиентът е `searching...`, в лога десетки пъти `dhcp,error couldn't acquire prefix`.
На кабела	Сървърът отговаря, но с `status-code NoPrefixAvail`.

fe80::...546 > ff02::1:2.547: dhcp6 solicit (... (IA_PD IAID:2 T1:0 T2:0))
fe80::...547 > fe80::...546: dhcp6 reply (... (IA_PD IAID:2 T1:0 T2:0 (status-code NoPrefixAvail)))

Клиентът питаше с IAID 2. След iaid=2 в binding-а веднага стана bound.

IAID-ът не се вижда в конфигурацията на клиентския рутер, ако не е зададен ръчно (custom-iapd-id), и не може да се предвиди по името на порта. При първите клиенти видяхме стойности 0, 1, 2, 3, 6 и 8 — включително различни стойности за ether1 на различни модели.

Три начина да се прочете IAID

Метод	Как и какви са ограниченията
Запис на клиентския рутер	Sniffer на WAN порта само за UDP 547, `renew`, после файлът се сваля и се чете с `tcpdump -vv`. Работи и без binding на сървъра — клиентът пак пита. Най-надеждният начин.
Запис на комутатор по пътя	На по-новите RouterOS устройства sniffer-ът може да е забранен от device-mode (`not allowed by device-mode`). Тогава записът на порта на комутатора понякога хваща заявката. Понякога не — CPU-то на комутатора вижда само част от multicast трафика, който чипът препраща хардуерно.
Lease файл на друг сървър	Ако клиентът някога е вземал префикс от друг DHCPv6 сървър, IAID-ът е записан там. Така намерихме IAID 6, след като 2 и 1 не станаха. Откъде се взе „друг сървър“ в нашата мрежа — в четвърта част.

/tool sniffer set filter-interface=ether1 filter-ip-protocol=udp filter-port=547 file-name=dhcp6cap
/tool sniffer start
/ipv6 dhcp-client renew 0
# ~40 секунди
/tool sniffer stop
/tool sniffer set file-name="" filter-interface="" filter-ip-protocol="" filter-port=""

$ tcpdump -nn -vv -r dhcp6cap | grep -o 'IA_PD IAID:[0-9]*'

`pool-prefix-length=68`: работи на 7.22, грешка на 7.24

Клиентският рутер слага делегирания /60 в локален pool, а LAN адресите се взимат от него с from-pool. На клиентите, където pool-prefix-length не беше зададен, pool-ът се създаваше с prefix-length=68. Защо точно 68 — не знам.

На RouterOS 7.22 адрес ::/64 from-pool от такъв pool си работеше.
На RouterOS 7.24 същото даваше невалиден адрес:

address pool error: bad preferred prefix length- requested 64, but pool has 68! (1)

И не само формално: от pool с 68 всяка LAN мрежа би била /68, а в /68 телефоните и компютрите не могат да си вземат адрес сами (SLAAC иска /64). Поправката е pool-prefix-length=64 на DHCPv6 клиента — но renew не пресъздава pool-а. Трябва release:

/ipv6 dhcp-client set 0 pool-prefix-length=64
/ipv6 dhcp-client release 0

IPv6 на клиента прекъсва за няколко секунди. Бизнес клиентите не го забелязват — всичко им работи и по IPv4. Затова pool-prefix-length=64 вече е част от стандартната настройка на всеки нов клиентски рутер, преди ъпгрейд, а не след него.

Клиентът, който се заклещи след рестарт

При един клиент, след рестарт на неговия рутер, DHCPv6 клиентът стоеше searching..., а на граничния рутер binding-ът беше bound с пресен last-seen. Заявките стигаха, отговорите не. Причината беше в NDP:

Отговорът на DHCPv6 сървъра е unicast към link-local адреса на клиента — за да го прати, граничният рутер трябва да знае MAC-а му.
Записът в /ipv6 neighbor беше failed — NS пакетите към клиента не стигаха.
Клиентът без префикс не праща IPv6 трафик, от който рутерът да научи MAC-а му.

Затворен кръг. Отпуши го един пинг от клиентския рутер към link-local адреса на граничния: клиентът прати NS, граничният научи MAC-а от него, и следващата DHCPv6 заявка мина.

/ping address=fe80::a00:27ff:fe00:1 interface=ether2 count=3

Тогава го записах като странност. Истинската причина беше, че multicast пакетите по този път просто се губеха — и това се оказа тема за цели две части.

В следващата част: как се търси къде по пътя се губи IPv6 multicast, защо MNDP лъже, че всичко е наред, и защо зад някои ONU-та IPv6 prefix delegation изобщо не тръгва.

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

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