BABUT

важная ремарка: Client reconfiguration (RECONFIGURE) -вот это бодяга, точнее флаг в ней, отвечает за "принуждение"(на самом деле всё добровольно) клиента сменить адрес который ему выдали или выдавали прежде. но поскольку и это не реализовано, то изменение адреса резервации никак на клиенте не сказывается пока не истекут таймауты(ну или вручную на клиенте похерить и дать ему пинка) а ещё анекдот: в 2022 году isc прекращает поддержку своей предыдущей поделки- ну, как говорится, пожелаем им удачи

нашёл я причину чуда "непорочного зачатия"- оказался мой недосмотр. плюс на это наложился косяк с работой keenetic в режиме точки доступа- через вифи на порт wan(за которым висит опёнок в качестве роутера(у опёнка проблема с дровами к вифи-карточкам, да и вообще весь стэк 802.11 на уровне дна, того гляди тео его выпилит) со всеми сервисами сетевыми) проходили пакетики dhcp, а с бриджа не проходили. хз что это было, но сброс в дефолт и опять вход врежим точки исправили сие. за одно выявили другой косяк- в режиме роутера отключением dhcp в морде отрубается(наверное. однозначно не удостоверился) dhcpv4, а вот dhcpv6 жив-здоров и продолжает мешать, отвечая на запросы клиентов(а предложить-то им он ничего не может, так как не сконфигурирован). в связи с тем, что "чудо" перестало быть чудом, полез я читать ман к kea 2.2.0, и вот что там пишут: 9.17. DHCPv6 Server Limitations These are the current limitations of the DHCPv6 server software. Most of them are reflections of the current stage of development and should be treated as “not implemented yet”, rather than actual limitations. The server will allocate, renew, or rebind a maximum of one lease for a particular IA option (IA_NA or IA_PD) sent by a client. RFC 8415 allows for multiple addresses or prefixes to be allocated for a single IA. Temporary addresses are not supported. There is no intention to ever implement this feature, as it is deprecated in RFC8415. Client reconfiguration (RECONFIGURE) is not yet supported. бугага. ну хотя бы я прав насчёт самого рфц. а в рассылке kea-users мне сказали, что это невозможно %) но там такие же калеки как и я, разработчиков там нет. насчёт DUID- рфц прямо требует, чтобы клиент имел его один единственный. kea для нахождения mac клиента смотрит в первую очередь DUID, а потом уже прочие методы, поэтому не работает резервирование для виндового клиента. меняется(тут нельзя сказать, что "однозначно исправляется") через указание "mac-sources":["raw","ipv6-link-local","any"]

вряд ли это прокатит. вот у меня два фейса- эзернет и вифи, а duid винда отдаёт серверу один и тот же(от эзернета. даже если его вырубить, то винду это не останавливает %D), вне зависимости с какого фейса запрос посылать но даже сработай это, то как же с сервера на клиентах автоматически клонировать фейсы? особенно когда даже ip на этих клиентах нет %) а если ручками, то нахрена козе баян в виде dhcp?

поковырял dnsmasq- тоже не умеет несколько сетей. ну как бы задать их можно, но выдаётся только один- из первой. может дело в винде всё же? но вот же картинка говорит, что не в ней %\ да и фреймы смотрю- там только один адрес в ответе отдаётся

ну я же сразу сказал, что shared-network это не про несколько сетей, а про несколько пулов, которые логически объединяются в один, т.е. адреса могут назначаться из любого из них(на самом деле сперва исчерпывается первый, а потом уже начинает из следующего брать). просто дурацкое название, которое не отражает сути и запутывает и всё же то не был глюк. вот но я опять просрал при каких обстоятельствах это происходит T_T меня сейчас другая проблема дико выбешивает- то, что винда запрашивает предыдущий адрес, который ей назначался, и kea это одобряет. я не знаю как заставить kea этого не делать. ну а заставить винду так не делать- вообще без шансов, все эти release, renew- это всё мимо и не удаляют предыдущий адрес из.. ну где эта стерва их хранит(кстати, а где? ;)). у kea грохнул таблицу лизинга- всё, с чистого листа, но отказать в подтверждении запрошенного клиентом адреса- нет, не отказывает. из-за этого просто невозможно что-то тестить!

с референсом не так-то всё очевидно: DHCP allows a client to receive multiple addresses. During typical operation, a client sends one instance of an IA_NA option and the server assigns at most one address from each prefix assigned to the link to which the client is attached. In particular, the server can be configured to serve addresses out of multiple prefixes for a given link. This is useful in cases such as when a network renumbering event is in progress. In a typical deployment, the server will grant one address for each IA_NA option (see Section 21.4). A client can explicitly request multiple addresses by sending multiple IA_NA options (and/or IA_TA options; see Section 21.5). A client can send multiple IA_NA (and/or IA_TA) options in its initial transmissions. Alternatively, it can send an extra Request message with additional new IA_NA (and/or IA_TA) options (or include them in a Renew message). и вроде бы как сказано, что "a client sends one instance of an IA_NA option and the server assigns at most one address from each prefix"(а всё общение между клиентом и сервером состоит или из двух сообщений, или из четырёх- об этом упомянуто в рфц, а значит сервер не может ответить несколькими сообщениями по одному IA_NA в каждом, единственный остающийся вариант- несколько IA_NA в одном ответе), но в то же время дальше всё запутывается. то, что сервер посылает клиенту по адресу из каждого префикса- это логично(но это не делается в kea), а вот то, что клиент может запросить несколько адресов- это сивый бред, так как клиент в принципе не может знать о наличии нескольких сетей. вообще, dhcp нужен как раз для ситуации, когда клиент вообще ничего не знает кроме своего мака, а потому как он может запрашивать что-то конкретное(а запрашивать несколько адресов- это запрашивать что-то конкретное)? единственное, что в такой ситуации можно варьировать- это отослать минимальный набор(т.е. один адрес из какой-нибудь сети, которые есть у сервера на этом фейсе) или отослать всё, что есть. но первый вариант не имеет практического смысла, ну разве что сократится трафик на несколько байт. так что как референсо реализовывать этот противоречивый бред?? зы: поковырял предыдущий сервер isc- он уже на стадии загрузки конфига отказывается обслуживать несколько сетей на одном фейсе, о чём прямым текстом и сообщает. kea хотя бы допускает такой конфиг. а по ссылке dhcpv4- такого добра навалом

рфц ничем тут не поможет, кроме как знанием о потенциальной возможности. да, наверное это прилетело через RA, а я не заметил и списал на kea.. ну просто это объяснение куда правдоподобнее того, что я двое суток не могу найти решение, которое уже было %D а разве не консорциум конкретно эти рфц сочиняет? вроде бы это они и есть. у меня к нему органическое неприятие с первого взгляда, ещё много лет назад. можно, конечно, прежнюю поделку isc поковырять, но она уже практически списана в утиль

этот то, что консорциум клепает на замену. оно, конечно, хорошо, но rad умеет только stateless, для чего и был создан, а я хочу stateful

и тут остапа осенило! но не сработало T_T можно же задать subnet как "::/0"- так прокатывает, у нас есть два пула из разных сетей, есть два адреса в списке резервации.. но из них выдаётся только один! да что за нах.. -_-

в документации такого нет. но я видел на фейсе винды два ipv6 адреса из двух заданных мною сетей. как я этого добился тогда- вообще не понимаю %\ вообще возможность выдать сразу несколько адресов есть, так как ip-addresses- это список в dhcpv6 , в отличии от ip-address в dhcpv4. но в одном блоке можно задать только одну subnet, пулов может быть несколько, но все из этой одной сети, следовательно и адреса должны быть(иначе ругается и не грузит) из неё же

не могу найти решение. вот хочу локальную fc00:, которая всегда есть и ни от чего не зависит. хочу 302:, которая актуальна только когда поднят yggdrasil и обращение идёт внутри её. хочу teredo, которая тоже есть не всегда. и может мой ублюдочный пров что-то своё подкинет. однако, минимум три. адрес из fc00: актуален только локально, адрес 302: актуален только в сети yggdrasil- эти адреса нельзя использовать за пределами их узкого мирка, т.е. с глобальных нельзя к ним и с них нельзя к глобальным. адреса тередо глобальны, но они зависят от ipv4 адреса внешки, который динамика, и их вообще может не быть. к одной сети никак не свести. так как заставить эту фашистcкую поделку учитывать реальность, а не жить в мире религиозных иллюзий её разработчиков? зы: shared networks- это не про то, это про расширения пула на несколько разных сетей, из которых будет выбран и выдан машине только ОДИН, а мне нужно несколько сразу, так как мои сети живут каждая в своём мире, друг о друге не знают и никак не пересекаются. определение нескольких сетей в конфиге принимается, но из них всегда выбирается только первая в списке. самое чудовищное в этой ситуации, что в самом начале мне как-то удалось сразу несколько адресов передать на фейс машине, но тот конфиг был утерян и я убей не могу его воспроизвести ((