У меня маршрутизированная / 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 на самом деле не является рекомендуемым решением, и я прекрасно с этим справляюсь.