У меня маршрутизированная /64 от моего провайдера, и я использую radvd. Мои клиенты (Linux, Windows) работают хорошо без дополнительной настройки, когда они подключены к маршрутизатору. Все они присваивают себе уникальные адреса с префиксом ISPs /64 через SLAAC для временного и постоянного (1) назначения адресов.
Я не использую DHCPv6 и не собираюсь этого делать. Как я узнал здесь, для клиентов SLAAC совершенно бесполезно, если они не имеют специальной конфигурации для использования назначенного адреса DHCP, потому что они, скорее всего, будут игнорировать его по умолчанию (2), что хорошо и в любом случае предпочтительнее. Я абсолютно не хочу делать какую-либо работу на "стандартных" клиентских машинах, которые подключаются к сети.
Итак, пункт (1) выше: адреса SLAAC IPv6, используемые клиентами, на самом деле не постоянны. Помещение их в Bind для DNS AAAA-записи работает ... на некоторое время. Это суть моей проблемы.
Я не могу понять, как заставить DNS-сервер заполнять свои записи на основе IP-адресов SLAAC.
Вопрос:
1) Может ли radvd запустить скрипт на RA, а затем перейти к шагу 2 ...
2) Из предыдущего шага я знаю, что у меня есть новый адрес FE80 для нового клиента. Как я могу получить глобальный IPv6-адрес этого клиента, который он назначил себе, используя его адрес FE80?
3) Затем я хотел бы обновить запись Bind DNS, указав его глобальный адрес IPv6, полученный на шаге 2.
Вышеперечисленные вещи, которые я пытаюсь выполнить, выглядят так, как будто они должны быть намазаны по всему Интернету - я изо всех сил пытаюсь выяснить, что я делаю неправильно, что делает мой вариант использования настолько редким. Есть ли уже механизм, который автоматически выполняет это, что я упускаю (имея в виду, что DHCPv6 исключен)?
С уважением и благодарностью
(2) Клиенты SLAAC Ubuntu определенно игнорируют назначения DHCPv6, даже когда radvd сообщает им об этом. На самом деле, Ubuntu (а может и больше) даже имеет старую ошибку при использовании в этой конфигурации, когда он фактически не добавляет маршрут, что делает соединение бесполезным без какого-либо ручного вмешательства. Я предполагаю, что эта ошибка имеет очень низкий приоритет, так как DHCPv6 в сочетании с radvd на самом деле не является рекомендуемым решением, и я прекрасно с этим справляюсь.