1. Один pool — одна длина делегируемого префикса
2. DHCPv6-PD в IPv6 задуман как делегирование маршрутизируемого пространства
3. Получать множество независимых `/64` вместо одного `/60` — плохая архитектура
4. RouterOS плохо поддерживает сложные DHCPv6-PD сценарии
5. RouterOS не позволяет вручную задавать IAID
6.`use-interface-duid=yes` привязывает DUID к интерфейсу
7. `prefix-hint` — это пожелание, а не требование
8. `prefix-hint` и `pool-prefix-length` — разные сущности
9. DHCPv6-PD не “раздаёт автоматически по портам”
10. `from-pool` — основной механизм автоматической выдачи `/64`
11. DHCPv6 relay не делит prefix
12. Через relay/interface separation можно эмулировать “нескольких клиентов”
13. Статические DHCPv6 binding чувствительны к изменению pool
14. RouterOS слабо валидирует пересечение IPv6 pool
15. Полученный `/56` не обязан существовать как явный “родительский pool”
16. IPv6 требует другого мышления, чем IPv4
17. Для сложных lab/router-сценариев нормальна иерархия
В RouterOS параметр `prefix-length` у IPv6 pool жёстко определяет размер подсетей, которые будут выдаваться из этого pool.
Один pool не может одновременно выдавать:
- `/64`
- `/60`
- `/62`
Пример:
- `pool-lan` → `prefix-length=64`
- `pool-routed` → `prefix-length=60`
DHCPv6-PD — это не “выдача одного LAN”, а делегирование downstream-router права самостоятельно резать подсети.
Нормальная модель IPv6:
- ISP выдаёт `/56` или `/60`
- downstream-router сам режет:
- `/64` для LAN
- `/64` для VLAN
- `/64` для transit
- дополнительные `/64` для внутренних сегментов
- `/64` — обычный L2/LAN сегмент
- `/60`, `/56`, `/48` — пространство для маршрутизатора
Технически можно заставить разные интерфейсы/relay/context выглядеть как отдельные DHCPv6-PD клиенты и получать отдельные `/64`.
Но это превращает сеть в набор независимых allocation вместо единой routed hierarchy.
Последствия:
- плохая агрегация маршрутов
- сложный renumbering
- неудобная policy routing
- сложный firewalling
- проблемы с summarization
- неудобный monitoring/IPAM
Проблема обычно не в IPv6 как технологии, а в реализации RouterOS.
Слабые места RouterOS:
- нет ручного IAID
- ограниченный контроль DUID
- слабая validation pool overlap
- неочевидное поведение binding
- poor hierarchical delegation tooling
- implicit/internal state
- слабый IPAM
- “один LAN + SLAAC”
- многоуровневом PD
- lab/router hierarchy
- mixed delegation sizes
- сложной маршрутизации
В DHCPv6 client RouterOS отсутствует параметр ручной настройки IAID.
IAID генерируется автоматически системой (обычно на основе интерфейса/внутреннего ID).
Из-за этого:
- сложно делать несколько независимых PD-запросов
- сложно управлять binding на сервере
- upstream-server часто считает разные запросы одним и тем же клиентом
При использовании:
Код: Выделить всё
use-interface-duid=yesЕсли:
- перенести DHCPv6 client на другой интерфейс
- изменить topology/interface mapping
Следствие:
- upstream DHCPv6-server перестаёт узнавать клиента
- ломаются static binding/prefix delegation
`prefix-hint`:
- * не гарантирует получение нужного размера префикса
- сервер может:
- проигнорировать hint
- выдать другой размер
- выдать другой prefix
Код: Выделить всё
prefix-hint=::/60“сервер обязан выдать `/60`”.
`prefix-hint`
Запрос upstream DHCPv6-PD server:
“желательно выдать мне такой размер prefix”.
`pool-prefix-length`
Локальная инструкция RouterOS:
“как нарезать уже полученный delegated prefix внутри pool”.
Это не связанные напрямую параметры.
При ручной адресации:
- `pool-prefix-length` может быть вообще не нужен.
RouterOS не делает:
“получил `/60` → автоматически выдал `/64` всем интерфейсам”.
После получения delegated prefix необходимо:
- настроить `from-pool`
- настроить ND/RA
- назначить IPv6 address/interface
- определить policy раздачи
Типичная схема:
- router получает `/56`
- pool режет на `/64`
- интерфейсы получают:
Код: Выделить всё
from-pool=pool-lanНо это уже локальная логика RouterOS, а не DHCPv6-PD itself.
DHCPv6 relay:
- не режет prefix
- не занимается subnetting
- не агрегирует delegation
- пересылает DHCPv6 сообщения
- добавляет link/interface context
Показать серверу, из какого сегмента пришёл запрос.
Практический workaround:
- разные VLAN
- разные relay-interface
- разные logical interface
- разные L2 domain
Иногда это используют для получения нескольких `/64`.
Но это:
- workaround
- а не нормальная routed IPv6 hierarchy.
Если изменить:
Код: Выделить всё
prefix-length- `invalid`
- `inactive`
Можно создать:
- overlapping pool
- overlapping delegated prefix
Конфликты проявляются позже:
- при выдаче prefix
- при маршрутизации
- при эксплуатации сети
В RouterOS delegated aggregate:
- может существовать как dynamic/internal state
- может использоваться как source для дочерних pool
Код: Выделить всё
/ipv6 pool add ...В IPv4 обычно:
- экономят подсети
- режут адреса максимально плотно
- `/64` считается стандартной LAN
- subnetting почти не экономят
- сеть строится вокруг routed hierarchy
- не интерфейс с адресом,
- а delegated routing domain.
Код: Выделить всё
ISP
|
/56
|
Main Router
|
+-- LAN ----------- /64
+-- Wi-Fi --------- /64
+-- Hypervisor ---- /64
+-- Lab Router A -- /60
+-- Lab Router B -- /60