ipv6 Переанонсирование IPv6-префикса /64 от ISP в LAN

[AmiGO]

Приветствую всех!

Ситуация следующая: Ростелеком через GPON заходит на ZTE F670 в режиме моста, от него уже Ethernet-фреймы попадают на выделенный порт Keenetic Peak с 4.0.7, на котором уже поднята PPPoE-сессия.

Провайдер выдаёт только /64 на стыке (т.е. PPPoE-интерфейсе) с помощью SLAAC, на DHCPv6 запросы же как через PPPoE, так и через Ethernet интерфейс провайдера никакого ответа не поступает и ожидаемый /56 (согласно информации с version6.ru) не прилетает. Проверялся этот факт по мере роста сомнений в собственной вменяемости сначала на оригинальном ZTE F670 при поднятом PPPoE прямо с него, потом на микроте RB4011 с ROS 7.12.1 и ZTE снова возвращённом в бридж, потом на свежей полновесной генте и под конец мероприятия на всё том же F670, но уже "правильно поднастроенном", т.е. с полноценным доступом к busybox, iptables, ebtables, arptables и так далее - для исключения наличия какой-либо непонятной фильтрации с помощью файрволла или eBPF на стороне железки. Результат прежний: на DHCPv6 со стороны ISP ничего не отвечает.

Однако, т.к. провайдер всё-таки выдаёт полностью рабочий /64, которого мне вполне достаточно, возникла идея его переанонсировать в локальную сеть и выяснилось (в том числе после общения с поддержкой Keenetic), что такого мой Keenetic Peak не умеет и уметь не планирует.

Научить его этому благодаря наличию Entware оказалось довольно просто: занялся этим скрипт 01_wan_ipv6_config.sh(ахтунг! много башизмов!), закинутый в `/etc/ndm/wan.d/` + симлинк на него же в `/etc/cron.1min/`.

Для достижения искомого поведения, как видно из скрипта, оказалось достаточно конфига для установленного в Entware radvd, логика же для ndppd не понадобилась, т.к. всё работает и без пересылки NDP-пакетов. Помимо доработок напильником также потребовалось полностью удалить из конфига Keenetic корневую секцию `ipv6` с целью предотвращения запуска встроенного radvd.

Вот так выглядит избавленный от всего лишнего конфиг роутера: config.txt

 

Вопрос без TL;DR: могли бы вы, уважаемые разработчики, добавить в NDMS нативную возможность переанонсирования полученного от провайдера с помощью SLAAC IPv6 /64 префикса в LAN через тот же SLAAC или DHCPv6 на роутере без необходимости получения DHCPv6-PD /56 от провайдера? Спасибо.

P.S. Пример конфига radvd, который для этого используется у меня: radvd.conf и конфиг ndppd (у меня всё отлично работает и без него): ndppd.conf

[slomblobov]

Подобный функционал реализован при работе с модемами, т.к. он предусмотрен RFC 7278.
В этом случае мы точно знаем, что работаем с мобильной сетью, для которой предусмотрены немного другие правила. Однако в случае с некой проводной сетью не представляется возможным выяснить, что подобное ухищрение имеет место быть.
Делать его настраиваемым тоже довольно сложно ввиду сложности объяснения происходяшего и недолговременности существования подобных сетей.

[AmiGO]

@vst Спасибо огромное за ответ!

On 12/11/2023 at 12:27 AM, vst said:

Делать его настраиваемым тоже довольно сложно ввиду сложности объяснения происходяшего и недолговременности существования подобных сетей.

Могли бы пояснить? Я подключен не к микропровайдеру, а к Ростелекому, однако ну вот не даёт он DHCPv6-PD и у меня нет ни малейшего понятия о том, появится ли, т.к. тех.поддержка на вопросы физ.лиц по IPv6 не отвечает, зато за сеть я более-менее уверен, т.к. подключен к ней уже очень давно и в ближайший десяток лет на что-то иное переключаться не планирую.
Объяснений тоже не требуется, т.к. я и так всё понимаю, хочется лишь избавиться от костылей.

Если заглянуть в "Справочник команд", то можно заметить довольно обширное количество возможностей, не представленных в веб-интерфейсе, объяснить суть которых неподготовленному пользователю тоже весьма затруднительно, т.е. доступно всё только тем, кому это действительно необходимо. В качестве примера:

ipv6 local-prefix - настройка анонсов ULA
ipv6 pass - включение IPv6 pass-through
ipv6 subnet mode - выбор между SLAAC и DHCPv6

Ни одна из этих опций не представлена в веб-интерфейсе. Если запрашиваемый мой функционал уже реализован, то почему сложность вызывает добавление CLI-команды (скажем ipv6 prefix reuse <wan-iface>) которая позволила бы включить переанонсирование уже полученного ранее /64 IPv6-префикса?

Если взглянуть на changelog 4.1 draft, то там уже есть 4 "Requested by" и ещё большее количество "Reported by":

• The new Proxy connection options, which introduce connectivity over the UDP protocol, are now available from the Command Line Interface (CLI). [NDM-2971] [Requested by Skrill0]

• The Next Generation Web Interface (beta) component now allows changing HTTPS port on the Users and Access page. [NWI-3054] [Requested by dimon27254]

• The Kernel modules for Netfilter system component now includes vxlan support. [SYS-1028] [Requested by MrArtemSid]

• IPv6 local prefixes of the ULA fc00::/7 address space are now available for configuration on network interfaces. [NDM-3039] [Requested by fl4co]

Да, у меня счётчик сообщений на форуме не уходит за несколько сотен и Кинетиков у меня всего 4, а не целое море, как у некоторых вопрошающих, однако каких-либо иных отличий моей просьбы добавить запрошенный функционал от перечисленных выше я не наблюдаю.
На PC (Linux/macOS/Windows), при подключении напрямую, выдаваемый провайдером IPv6 функционирует нормально, на OpenWRT переанонсирование функционирует, на Микротиках тоже, а на Кинетиках - нет, поэтому я не очень понимаю ваше нежелание добавить хотя бы CLI-команду с учётом того, что всё это уже и так работает (по вашему же утверждению).
Мне видится весьма справедливым отметить мою просьбу "Reported by", а вовсе даже не "Requested by" если реализация когда-нибудь состоится.
 

Опять отчего-то очень много текста написалось...
TL;DR: Могли бы вы сделать CLI-командочку для переанонсирования префиксов, полученных не через DHCPv6-PD? Плиз, плиз.

P.S. ipv6 pass through невозможно использовать для PPPoE-интерфейсов - почему? Могли бы вы это тоже исправить?

(config)> ipv6 pass through PPPoE0 Homenet
Ip6::Pass error[39977461]: no such Ethernet interface: "PPPoE0".

Edited December 12, 2023 by AmiGO

[AmiGO]

@vst поможете?

[slomblobov]

Мы хотели бы выразить благодарность за предложение, которое вы представили нам. Однако, после тщательного рассмотрения, мы вынуждены отказать в его принятии. Функционал, предложенный вами, не соответствует RFC 7278, а также не вызвал достаточного интереса у других пользователей.

Мы ценим ваше участие и предложение, и возможно в будущем мы вернемся к этой идее. Мы надеемся на ваше понимание и готовы рассмотреть другие предложения от вас в будущем.

[AmiGO]

@vst Спасибо за ответ. Жаль. А по-поводу ipv6 pass through с PPPoE - тоже нет?

[slomblobov]

On 1/4/2024 at 10:52 PM, AmiGO said:

А по-поводу ipv6 pass through с PPPoE - тоже нет?

Функционал pass-through предполагает, что данные определенного типа прозначно передаются с одного интерфейса на другой. Однако в случае с PPP интерфейсами требуется клиент, который согласует канальный уровень(ipcp, ipv6cp) с концентратором. Реализация существования этого клиента с pass-through не планируется к реализации.

[avn]

В 08.12.2023 в 23:39, AmiGO сказал:

Приветствую всех!

Ситуация следующая: Ростелеком через GPON заходит на ZTE F670 в режиме моста, от него уже Ethernet-фреймы попадают на выделенный порт Keenetic Peak с 4.0.7, на котором уже поднята PPPoE-сессия.

Провайдер выдаёт только /64 на стыке (т.е. PPPoE-интерфейсе) с помощью SLAAC, на DHCPv6 запросы же как через PPPoE, так и через Ethernet интерфейс провайдера никакого ответа не поступает и ожидаемый /56 (согласно информации с version6.ru) не прилетает. Проверялся этот факт по мере роста сомнений в собственной вменяемости сначала на оригинальном ZTE F670 при поднятом PPPoE прямо с него, потом на микроте RB4011 с ROS 7.12.1 и ZTE снова возвращённом в бридж, потом на свежей полновесной генте и под конец мероприятия на всё том же F670, но уже "правильно поднастроенном", т.е. с полноценным доступом к busybox, iptables, ebtables, arptables и так далее - для исключения наличия какой-либо непонятной фильтрации с помощью файрволла или eBPF на стороне железки. Результат прежний: на DHCPv6 со стороны ISP ничего не отвечает.

Однако, т.к. провайдер всё-таки выдаёт полностью рабочий /64, которого мне вполне достаточно, возникла идея его переанонсировать в локальную сеть и выяснилось (в том числе после общения с поддержкой Keenetic), что такого мой Keenetic Peak не умеет и уметь не планирует.

Научить его этому благодаря наличию Entware оказалось довольно просто: занялся этим скрипт 01_wan_ipv6_config.sh(ахтунг! много башизмов!), закинутый в `/etc/ndm/wan.d/` + симлинк на него же в `/etc/cron.1min/`.

Для достижения искомого поведения, как видно из скрипта, оказалось достаточно конфига для установленного в Entware radvd, логика же для ndppd не понадобилась, т.к. всё работает и без пересылки NDP-пакетов. Помимо доработок напильником также потребовалось полностью удалить из конфига Keenetic корневую секцию `ipv6` с целью предотвращения запуска встроенного radvd.

Вот так выглядит избавленный от всего лишнего конфиг роутера: config.txt

 

Вопрос без TL;DR: могли бы вы, уважаемые разработчики, добавить в NDMS нативную возможность переанонсирования полученного от провайдера с помощью SLAAC IPv6 /64 префикса в LAN через тот же SLAAC или DHCPv6 на роутере без необходимости получения DHCPv6-PD /56 от провайдера? Спасибо.

P.S. Пример конфига radvd, который для этого используется у меня: radvd.conf и конфиг ndppd (у меня всё отлично работает и без него): ndppd.conf

Может у провайдера проверка на мак адрес используется?