IPv6 на MikroTik — практические тезисы и подводные камни

[ROOT]

Темы
 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-сценариев нормальна иерархия 

---

 1. Один pool — одна длина делегируемого префикса
В RouterOS параметр `prefix-length` у IPv6 pool жёстко определяет размер подсетей, которые будут выдаваться из этого pool.

Один pool не может одновременно выдавать:

• `/64`
• `/60`
• `/62`

Для разных размеров префиксов нужны отдельные pool.

Пример:

• `pool-lan` → `prefix-length=64`
• `pool-routed` → `prefix-length=60`

Это соответствует нормальной IPv6-иерархии, но реализация в RouterOS неудобна и плохо масштабируется.

[anchor=2 goto=wrap]2. DHCPv6-PD в IPv6 задуман как делегирование маршрутизируемого пространства
DHCPv6-PD — это не “выдача одного LAN”, а делегирование downstream-router права самостоятельно резать подсети.

Нормальная модель IPv6:

• ISP выдаёт `/56` или `/60`
• downstream-router сам режет:
  
  • `/64` для LAN
  • `/64` для VLAN
  • `/64` для transit
  • дополнительные `/64` для внутренних сегментов

То есть:

• `/64` — обычный L2/LAN сегмент
• `/60`, `/56`, `/48` — пространство для маршрутизатора

[anchor=3 goto=wrap]3. Получать множество независимых `/64` вместо одного `/60` — плохая архитектура 

Технически можно заставить разные интерфейсы/relay/context выглядеть как отдельные DHCPv6-PD клиенты и получать отдельные `/64`.
Но это превращает сеть в набор независимых allocation вместо единой routed hierarchy.

Последствия:

• плохая агрегация маршрутов
• сложный renumbering
• неудобная policy routing
• сложный firewalling
• проблемы с summarization
• неудобный monitoring/IPAM

Это workaround ограничений RouterOS, а не нормальный IPv6 design.

 4. RouterOS плохо поддерживает сложные DHCPv6-PD сценарии 
Проблема обычно не в IPv6 как технологии, а в реализации RouterOS.

Слабые места RouterOS:

• нет ручного IAID
• ограниченный контроль DUID
• слабая validation pool overlap
• неочевидное поведение binding
• poor hierarchical delegation tooling
• implicit/internal state
• слабый IPAM

IPv6 в RouterOS работает нормально для:

• “один LAN + SLAAC”

Но при:

• многоуровневом PD
• lab/router hierarchy
• mixed delegation sizes
• сложной маршрутизации

начинаются ограничения платформы.

 5. RouterOS не позволяет вручную задавать IAID 


В DHCPv6 client RouterOS отсутствует параметр ручной настройки IAID.
IAID генерируется автоматически системой (обычно на основе интерфейса/внутреннего ID).
Из-за этого:

• сложно делать несколько независимых PD-запросов
• сложно управлять binding на сервере
• upstream-server часто считает разные запросы одним и тем же клиентом

 6.`use-interface-duid=yes` привязывает DUID к интерфейсу 

При использовании:

Код: выделить все

use-interface-duid=yes

DUID зависит от интерфейса RouterOS.
Если:

• перенести DHCPv6 client на другой интерфейс
• изменить topology/interface mapping

то DUID может измениться.

Следствие:

• upstream DHCPv6-server перестаёт узнавать клиента
• ломаются static binding/prefix delegation

Само по себе “перетыкание кабеля” DUID обычно не меняет.

 7. `prefix-hint` — это пожелание, а не требование 

`prefix-hint`:

• * не гарантирует получение нужного размера префикса
• сервер может:
  
  • проигнорировать hint
  • выдать другой размер
  • выдать другой prefix

Пример:

Код: выделить все

prefix-hint=::/60

не означает:
“сервер обязан выдать `/60`”.

 8. `prefix-hint` и `pool-prefix-length` — разные сущности 

`prefix-hint`
Запрос upstream DHCPv6-PD server:
“желательно выдать мне такой размер prefix”.

`pool-prefix-length`
Локальная инструкция RouterOS:
“как нарезать уже полученный delegated prefix внутри pool”.

Это не связанные напрямую параметры.
При ручной адресации:

• `pool-prefix-length` может быть вообще не нужен.

 9. DHCPv6-PD не “раздаёт автоматически по портам” 

RouterOS не делает:
“получил `/60` → автоматически выдал `/64` всем интерфейсам”.

После получения delegated prefix необходимо:

• настроить `from-pool`
• настроить ND/RA
• назначить IPv6 address/interface
• определить policy раздачи

Автоматической магии нет.

 10. `from-pool` — основной механизм автоматической выдачи `/64` 

Типичная схема:

• router получает `/56`
• pool режет на `/64`
• интерфейсы получают:

Код: выделить все

from-pool=pool-lan

Именно это создаёт ощущение “автоматической раздачи”.
Но это уже локальная логика RouterOS, а не DHCPv6-PD itself.

 11. DHCPv6 relay не делит prefix 

DHCPv6 relay:

• не режет prefix
• не занимается subnetting
• не агрегирует delegation

Relay только:

• пересылает DHCPv6 сообщения
• добавляет link/interface context

Его задача:
Показать серверу, из какого сегмента пришёл запрос.

 12. Через relay/interface separation можно эмулировать “нескольких клиентов” 

Практический workaround:

• разные VLAN
• разные relay-interface
• разные logical interface
• разные L2 domain

могут заставить upstream DHCPv6-server воспринимать один роутер как несколько независимых downstream-client.
Иногда это используют для получения нескольких `/64`.
Но это:

• workaround
• а не нормальная routed IPv6 hierarchy.

 13. Статические DHCPv6 binding чувствительны к изменению pool 
Если изменить:

Код: выделить все

prefix-length

у используемого pool, то static binding с несовместимой длиной prefix могут перейти в:

• `invalid`
• `inactive`

RouterOS предупреждает об этом плохо или не предупреждает вовсе.

 14. RouterOS слабо валидирует пересечение IPv6 pool 
Можно создать:

• overlapping pool
• overlapping delegated prefix

без явных ошибок.

Конфликты проявляются позже:

• при выдаче prefix
• при маршрутизации
• при эксплуатации сети

 15. Полученный `/56` не обязан существовать как явный “родительский pool” 
В RouterOS delegated aggregate:

• может существовать как dynamic/internal state
• может использоваться как source для дочерних pool

Без явного:

Код: выделить все

/ipv6 pool add ...

То есть `/56` — это скорее граница delegated address space, чем обязательно отдельный объект конфигурации.

 16. IPv6 требует другого мышления, чем IPv4 
В IPv4 обычно:

• экономят подсети
• режут адреса максимально плотно

В IPv6:

• `/64` считается стандартной LAN
• subnetting почти не экономят
• сеть строится вокруг routed hierarchy

Основная сущность IPv6:

• не интерфейс с адресом,
• а delegated routing domain.

 17. Для сложных lab/router-сценариев нормальна иерархия вида 

Код: выделить все

ISP
  |
 /56
  |
Main Router
  |
  +-- LAN ----------- /64
  +-- Wi-Fi --------- /64
  +-- Hypervisor ---- /64
  +-- Lab Router A -- /60
  +-- Lab Router B -- /60

Именно под такую модель проектировался DHCPv6-PD.