Тестируемая сервисная модель
Тип WAN-интерфейса: PPP[oE]
Способ назначения адресов на WAN-интерфейсе: SLAAC.
Подробности: префикс /64 для адресации PPP-линка анонсируется BRAS'ом в сообщении ICMPv6 RA с флагом(1) "Other". В самой опции PrefixInformation, содержащая в себе назначаемый /64 префикс, выставлен только флаг(2) "AutoConfig").
В соответствии с RFC 4861:
Способ назначения префикса для "домашней" сети клиента: DHCPv6-PD(1) означает, что "other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network"
(2) означает, что "this prefix can be used for stateless address configuration"
Особенность: каждому клиенту назначается префикс /63.
Согласно RFC 6204 "Basic Requirements for IPv6 Customer Edge Routers":
То есть очевидно, что делегируемый префикс вполне может быть короче, чем /64. В этом случае CPE(в нашем случае RT-N16) должен сам подробить этот более короткий префикс на /64.L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
Модель устройства: RT-N16,
Софт: RT-N16-1.9.2.7-rtn-r3702.trx
Настройки:
IPv6 Connection Type: Stateless
IPv6 Interface: WAN
LAN IPv6 Setting
Get IPv6 automatically? Yes
Advertise LAN Prefix? Yes
WAN IPv6 Setting
Get IPv6 automatically? Yes
WAN DNSv6 Setting
Get DNS Server automatically? Yes
Шаг 0. IPCP6 для назначения link-local адреса
Согласование параметров IPCP6: генерация interface-id с обоих сторон линка, согласование.
В моей конфигурации - согласование инициируется со стороны BRAS.
По результатам согласования обе стороны имеют уникальный interface-id. И обе стороны назначают link-local адрес на PPP-интерфейс (DAD - здесь не нужен).
Данный шаг завершается успешно.
Шаг 1. SLAAC для назначения Global Unicast адреса
SLAAC для PPP-линка. BRAS отсылает ICMPv6 RA с опцией PrefixInformation и вышеперечисленными флагами и префиксом /64.
RT-N16, получив это сообщение, генерирует интерфейсный адрес вида:
[полученный префикс][локальный interface-id]/64 и назначает его на PPP-интерфейс. (DAD - здесь не обязателен)
В целом - это и происходит.
...но возникает
Проблема 1:
Помимо link-local адреса и Global Unicast-адреса на ppp-интерфейсе со стороны RT-N16 появляется еще два очевидно "мусорных" адреса:
Например, вот такие:
Первый - постоянен и не меняется после реконнекта. Во втором-меняется значения второго байтаinet6 addr: ee3f:7b04:80:ab2a:214:4000:afe7:aa2a/128 Scope:Global
inet6 addr: ::6cdd:4200:ac85:4000:55d9:ec7f/128 Scope:Global
Проблема пропадает, если выбрать IPv6 Connection Type: DHCPv6
Однако, в nvram виден такой же мусор, как и в предыдущем случае:
Шаг 2. DHCPv6-PD для назначения IPv6-префикса на br0.[root@home etc]$ nvram get wan0_ipv6_addr_t
ee3f:7b04:80:ab2a:214:4000:afe7:aa2a
Для этого шага "Connection Type" следует поменять:
IPv6 Connection Type: DHCPv6.
Как упоминалось выше, в данном случае шаги 0 и 1 проходят успешно. Проблема 1 не наблюдается.
DHCPv6-PD отрабатывает, маршрутизатор получает префикс и успешно назначает его на интерфейс br0.
НО вот radvd этот префикс не анонсирует (и это Проблема 2) по следующей причине:
Стало быть, radvd требует именно /64, что, в принципе, тоже логично.Jan 1 04:00:16 dhcp6c[346]: add address 2001:db8:fffe:2:e2cb:4eff:fead:ede2/63 on br0
Jan 1 04:00:16 radvd[217]: attempting to reread config file
Jan 1 04:00:16 radvd[217]: prefix length should be 64 for br0
Jan 1 04:00:16 radvd[217]: resuming normal operation
Однако, в совокупности такое поведение ломает требование L-2 из RFC6204.
В связи с этим:
Предложение:
- В рамках IPC между dhcp6c и radvd реализовать дробление более короткого префикса на множество /64. Для назначения на br0 использовать первый из этих /64. В radvd передавать также первый из этих /64.
Вопросы:
- Мне пока не вполне понятно - как организовано IPC между dhcp6c и radvd ?
- Что скрывается за селектором "IPv6 Connection Type: Stateless" в конфиге ? Какое сочетание механизмов ?
Reply With Quote
