Кратко

  • RFC 9686 позволяет клиенту сообщить инфраструктуре DHCPv6 о самостоятельно созданном или статически настроенном IPv6-адресе. Адрес выбирает устройство; DHCPv6 его не назначает.
  • RFC 9915 описывает создание сервером lease для такой регистрации. Это серверное состояние, а не доказательство проверки адреса, долговременного хранения, личности либо авторизации.
  • Для SLAAC первоначальное вычисление NextAddrRegRefreshTime примерно на уровне 80 процентов Valid Lifetime с множителем 0,9–1,1 не планирует передачу обновления. Она планируется лишь при изменении Valid Lifetime сетью более чем на один процент.
  • Четыре часа — настраиваемый интервал обновления регистрации статического адреса по умолчанию, а не срок жизни самого адреса и не срок lease.
  • ADDR-REG-REPLY подтверждает получение сообщения и прекращает его повторы. Ответ не доказывает легитимность использования адреса, происхождение трафика или право применить меру.

Пробел, который нельзя толковать буквально

До RFC 9686 у DHCPv6-инфраструктуры не было общего стандартизованного способа узнавать обо всех адресах, самостоятельно созданных узлами. При SLAAC устройство выбирает адрес без назначения со стороны DHCPv6. Статический адрес также может появиться вне серверного процесса. Сеть пропускает трафик, а серверный учёт ничего о таком адресе не сообщает.

Опубликованный в декабре 2024 года RFC 9686 вводит регистрацию этих адресов через DHCPv6. Механизм добавляет наблюдаемость, но остаётся зависимым от поддержки клиента, конфигурации инфраструктуры, доставки сообщений и сохранности данных.

Поэтому пустой результат поиска допускает несколько объяснений. Поддержка могла не объявляться на соответствующем интерфейсе. Клиент мог не поддерживать механизм или не отправить сообщение. ADDR-REG-INFORM мог не достичь инфраструктуры регистрации. Запрос аналитика мог не учитывать правильный relay или место хранения. Журналирование могли явно отключить. Действующее состояние могло завершиться, а историческую запись — удалить. Наконец, система учёта могла обслуживать иной канал или административный участок.

Ни одно из этих объяснений нельзя вывести из пустого поля без дополнительных сведений. Отсутствие регистрации прежде всего описывает состояние найденных данных, а не состояние адреса на устройстве.

Поддержка обнаруживается на интерфейсе

Регистрация начинается с обнаружения возможности. Клиент запрашивает сведения о поддержке, а DHCPv6-инфраструктура сообщает о ней посредством OPTION_ADDR_REG_ENABLE в Advertise или Reply. Пока поддержка не обнаружена, клиенту запрещено регистрировать самостоятельно созданные адреса.

Это состояние не следует сводить к ответу одного заранее выбранного сервера. В среде с несколькими серверами клиент может обнаружить поддержку через соответствующий обмен на интерфейсе. После того как поддержка обнаружена, регистрация может продолжаться по правилам RFC 9686; последующее отсутствие опции в каждом отдельном ответе само по себе не следует читать как немедленную отмену уже обнаруженной возможности.

Для расследования поэтому важно восстановить не только конфигурацию конкретного сервера, но и состояние инфраструктуры, видимое клиенту на нужном интерфейсе в рассматриваемый период. Если поддержка там не была обнаружена, отсутствие ADDR-REG-INFORM является нормальным следствием протокола, а не признаком уклонения клиента или отсутствия адреса.

Содержание заявления клиента

Клиент передаёт самостоятельно созданный или статически настроенный адрес в ADDR-REG-INFORM. Сообщение содержит Client Identifier и IA Address. Регистрируемый адрес должен совпадать с исходным IPv6-адресом сообщения или, если оно прошло через relay, с peer-address внутреннего relay-заголовка.

Это правило связывает заявление с наблюдаемым контекстом доставки. Но оно не превращает Client Identifier в удостоверение личности и не подтверждает, что тот же узел породил каждый пакет с данным исходным адресом.

Серверу следует проверить, подходит ли адрес для канала или входит ли он в префикс, делегированный клиенту. Нормативное слово RFC 9686 — SHOULD. Проверка рекомендована, однако её нельзя считать выполненной только потому, что инфраструктура поддерживает регистрацию.

Если сервер проводит такую проверку и она завершается неудачно, он обязан отбросить сообщение — MUST — и должен зарегистрировать сбой в журнале — SHOULD. Обязательное отбрасывание обусловлено отрицательным результатом фактически проведённой проверки. Это не безусловная гарантия того, что проверка включена в каждой конфигурации.

Принятая регистрация: четыре разных действия

После принятия ADDR-REG-INFORM сервер выполняет действия с неодинаковой нормативной силой.

Он обязан записать регистрацию в журнал, если журналирование не было явно отключено. Он должен, в смысле SHOULD, создать привязку Client Identifier к адресу. Он также должен — снова SHOULD — пометить адрес недоступным для назначения. Наконец, сервер обязан отправить ADDR-REG-REPLY.

Эти действия не следует объединять в расплывчатое утверждение, что адрес «полностью проверен и сохранён». Сервер способен корректно отправить обязательный Reply, хотя рекомендуемая привязка не создана. Журналирование могло быть отключено. Проверка соответствия каналу могла не выполняться. Исторические данные могли позднее исчезнуть согласно политике хранения.

ADDR-REG-REPLY подтверждает получение ADDR-REG-INFORM и прекращает повторную передачу этого сообщения клиентом. Он является квитанцией доставки на протокольном уровне, а не свидетельством личности, легитимности использования адреса, доступности узла или полномочий на санкцию.

Lease не меняет происхождение адреса

После того как RFC 9915 заменил RFC 8415, слово lease нельзя исключать из описания регистрации. Раздел 6.6 RFC 9915 описывает создание сервером lease для самостоятельно созданного адреса. Однако эта фраза не снабжена нормативным словом RFC 2119 MUST.

Не означает она и назначения адреса посредством DHCPv6. Сначала устройство выбирает адрес с помощью SLAAC либо получает его из статической конфигурации. Затем клиент сообщает о нём серверу. Lease представляет серверное состояние регистрации, а не акт выдачи адреса.

Наличие lease само по себе не доказывает, что сервер проверил соответствие адреса каналу или делегированному префиксу. Оно не гарантирует долговременного хранения записи, не удостоверяет устройство или человека и не подтверждает разрешённость использования адреса. Эти вопросы регулируются другими положениями протокола, конфигурацией и независимыми источниками.

Кроме того, lease следует отличать от binding. RFC 9686 лишь рекомендует — SHOULD — создать привязку Client Identifier к адресу. Поэтому при анализе необходимо отдельно установить, существовало ли серверное состояние регистрации, создавалась ли рекомендуемая привязка и сколько времени сохранялись соответствующие сведения.

Расчёт времени — ещё не передача

Для SLAAC-адреса клиент первоначально вычисляет NextAddrRegRefreshTime примерно как 80 процентов Valid Lifetime, применяя множитель от 0,9 до 1,1. Случайное отклонение снижает вероятность того, что множество клиентов будут действовать одновременно.

Но это вычисление само по себе не планирует передачу refresh. Оно создаёт внутреннее временное значение, необходимое для последующего принятия решения. Нельзя считать, что сразу после регистрации клиент ставит ADDR-REG-INFORM в расписание на номинальную отметку 80 процентов.

Передача обновления планируется только в том случае, если сеть изменяет Valid Lifetime более чем на один процент. При обычном ходе срока Valid Lifetime уменьшается вместе с прошедшим временем, тогда как ожидаемый момент истечения может оставаться прежним. Если значимого изменения нет, refresh может вообще не отправляться.

Отсюда следует важная граница для мониторинга: прохождение расчётного NextAddrRegRefreshTime без нового сообщения не является доказательством отказа. Для оценки нужны как минимум предыдущее и новое значения Valid Lifetime, времена их получения и расчёт ожидаемого истечения. Только после этого можно определить, возникло ли условие планирования передачи.

Для статически настроенного адреса RFC 9686 устанавливает настраиваемый интервал обновления регистрации; его значение по умолчанию составляет четыре часа. Этот интервал определяет, когда клиент повторяет регистрационное сообщение. Он не является ни Valid Lifetime статического адреса, ни продолжительностью lease, ни сроком хранения серверного журнала.

Несколько часов, несколько истин

В расследовании приходится сопоставлять независимые временные шкалы.

Состояние lease относится к серверному сопровождению регистрации. Его наличие в определённый момент не доказывает использование адреса до или после этого момента.

Интервал обновления статической регистрации управляет повторной отправкой регистрационного сообщения. Четырёхчасовое значение по умолчанию нельзя использовать как замену сроку адреса или lease.

Valid Lifetime SLAAC-адреса описывает пригодность адреса на устройстве в рамках SLAAC. Его изменение участвует в решении о планировании обновления регистрации, но не тождественно сроку хранения данных сервером.

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

Фактическое использование адреса в трафике устанавливается наблюдением пакетов или потоков в интересующий период. Оно не выводится автоматически ни из lease, ни из Neighbor Cache, ни из данных точки доступа.

Сообщения, содержащие нулевой lifetime, также следует читать в точном протокольном контексте, не превращая их в универсальное доказательство окончательного удаления адреса с устройства. Серверное состояние, регистрационный обмен и конфигурация интерфейса остаются разными областями.

Контекст привязки не равен наблюдению трафика

Duplicate Address Detection, определённый в RFC 4862, помогает проверить вероятную уникальность IPv6-адреса на канале. Процедура не совершенна и не аутентифицирует устройство. Успешный DAD не называет владельца адреса и не подтверждает происхождение последующего трафика.

FCFS SAVI по RFC 6620 связывает IPv6-адрес с binding anchor. В рамках FCFS SAVI разрешёнными binding anchors являются только порты коммутатора. Такое состояние усиливает сведения о том, через какой порт адресу позволено выступать внутри контролируемого периметра, но не доказывает, что конкретный пакет действительно прошёл через этот порт. За портом также может находиться более одного логического или физического узла.

Neighbor Cache показывает состояние сопоставления соседа, а сведения системы доступа помогают установить сетевой контекст устройства или сессии. Они полезны для атрибуции канала, но не эквивалентны доказательству фактического использования адреса в интересующем трафике.

Наблюдение реального трафика требует отдельного источника: журнала firewall, IPFIX, packet capture либо прикладной телеметрии, фиксирующей соответствующий пакет или поток. Только такие данные отвечают на вопрос, наблюдался ли адрес как источник или назначение в конкретном обмене.

Client Identifier, SAVI, Neighbor Cache и аутентификация могут затем помочь связать это наблюдение с сетевым контекстом. Но ни один из них по отдельности не удостоверяет человека и не определяет допустимость применения меры.

Разбор отсутствующей записи

RFC 9099 рекомендует сопоставлять журналы приложений и IPFIX, Neighbor Cache, DHCPv6, SAVI, интерфейсы коммутаторов и маршрутизаторов, firewall, системы аутентификации и RADIUS accounting. RFC 9686 добавляет в этот набор сведения об адресах, которые DHCPv6 не назначал.

При отсутствии ожидаемой регистрации следует проверить:

  • была ли поддержка обнаружена клиентом на нужном интерфейсе;
  • поддерживал ли клиент регистрацию и мог ли получить объявление;
  • какие серверы и relay обслуживали соответствующую инфраструктуру;
  • сохранился ли внутренний peer-address;
  • достигал ли ADDR-REG-INFORM места обработки;
  • выполнялась ли рекомендуемая проверка link или делегированного префикса;
  • не был ли отказ записан отдельно от принятых регистраций;
  • было ли журналирование принятых сообщений включено;
  • создавался ли рекомендуемый binding;
  • существовало ли серверное состояние в момент события;
  • как долго сохранялись исторические журналы;
  • меняла ли сеть Valid Lifetime более чем на один процент;
  • сдвигался ли ожидаемый момент истечения;
  • не был ли четырёхчасовой параметр ошибочно принят за срок lease;
  • имеется ли отдельное пакетное или потоковое свидетельство трафика;
  • какие Neighbor Cache, SAVI, портовые и аутентификационные данные описывают контекст этого наблюдения;
  • охватывали ли источники фактический путь интересующего трафика.

Такой разбор не обещает идеальной атрибуции. Он позволяет определить, какой пробел возник: протокольный, конфигурационный, временной, архивный или топологический.

Источники