Кратко

  • RFC 10038 вводит DHCPv6 identity association для локаторов SRv6: IAID, структуру локатора, preferred и valid lifetime, T1/T2, привязку на сервере и явный статус отсутствия доступного ресурса.
  • Действительная Reply приводит к настройке локатора на клиенте, но локальный маршрут и его объявление — отдельные необязательные действия. Локальные SID, применение нескольких локаторов и объявление SID не входят в область документа.
  • Редакторами RFC выступили Weiqiang Cheng и Changwang Lin; Ruibo Han, Daniel Voyer и Geng Zhang — соавторы, Yuanxiang Qiu — участник. Это коллективный стандарт, а не свидетельство единоличного изобретения или внедрения.

Хронология инцидента может выглядеть безупречно до одной строки. Клиент пересёк T1 и отправил Renew. Затем наступил T2. Valid lifetime закончился, сервер удалил привязку. Однако маршрут исчез позже — или не исчез вовсе.

Если в журнале остаётся только prefix, установить причинную цепочку трудно. RFC 10038 решает первую часть задачи: даёт выделению локатора SRv6 идентичность, структуру и часы. Вторая часть — связь аренды с маршрутом, политикой и наблюдаемым трафиком — остаётся работой оператора.

Документ опубликован в августе 2026 года на треке стандартов IETF. Он определяет IA_SRV6_LOCATOR, IA Locator и NoSRv6LocatorAvail, чтобы отсутствие доступного локатора было явным результатом, а не неразличимым молчанием.

Авторство столь же конкретно. Weiqiang Cheng и Changwang Lin — редакторы, Ruibo Han, Daniel Voyer и Geng Zhang — другие авторы, Yuanxiang Qiu — участник. Сохранённый 31 августа 2026 года профиль IETF называл Cheng Chief Architect of IP Networks в China Mobile Research Institute, председателем SRv6 Operations и автором девяти RFC. Эти сведения подтверждают публичную роль в стандартизации, но не внедрение в China Mobile или другой названной сети.

IAID сохраняет причинность

IAID отличает одну association клиента от других. T1 задаёт момент обращения к исходному серверу для продления, T2 — момент, после которого можно обратиться к любому доступному серверу. Вложенная опция содержит preferred и valid lifetime, длины частей locator block, locator node, function и argument, а также Algorithm.

Поэтому расследованию нужны клиент, IAID, relay, сервер, ответ, структура и остаток времени. Renew и Rebind должны продолжать известный объект, а не создавать строку без происхождения. Release или истечение срока заканчивают привязку; сервер возвращает prefix в pool и удаляет запись.

Между действительным и просроченным состоянием есть переходы. Локатор может перестать быть preferred, оставаясь valid. Клиент может пройти T1, но ещё не T2. Двоичный показатель скрывает, был ли сбой неожиданным или система уже находилась в известном окне восстановления.

Получив действительную Reply, клиент настраивает локатор. Но RFC не определяет создание локальных SID, применение нескольких локаторов и объявление SID. Запрещено выводить назначение сервиса из порядка локаторов. Общий протокол переносит явные поля, а не неявные приоритеты.

У маршрута другая временная линия

Раздел 5.5 разрешает relay или серверу установить соответствующий локальный маршрут. Next hop должен указывать на запрашивающий клиент. Затем устройство может объявить маршрут обычным протоколом маршрутизации.

Эти действия не следуют автоматически из действительной привязки. Сервер может видеть аренду, а RIB — не иметь route. RIB может обновиться, но FIB — отклонить программирование. Экспортная политика может остановить объявление. Объявление может не сойтись на всех маршрутизаторах. Даже полная сходимость не подтверждает SID и SR policy на CPE или прохождение пакета.

Algorithm определяет форму объявления. Ноль допускает обычную IP reachability. Ненулевое значение требует Locators TLV из RFC 9352 или RFC 9513. Если система отбросит поле и объявит любой prefix одинаково, она потеряет условие вычисления.

Для каждой стадии нужен собственный timestamp: серверная привязка, настройка клиента, RIB, FIB, объявление, сходимость, SID, policy, фильтры, пакетное наблюдение. IAID и locator связывают их, но не выравнивают часы задним числом.

Release проверяет, завершилась ли история

После Release локатор должен быть освобождён, локальный маршрут удалён, прежнее объявление отозвано. По окончании lease сервер также возвращает prefix и удаляет привязку. В распределённой системе это несколько событий, а не одна атомарная кнопка.

Сервер владеет association, доступ — next hop, routing — объявлением и сходимостью, CPE и контроллеры — SID, policy и cache. Нужно доказать, какие состояния зависели от завершившегося IAID и когда каждый потребитель перестал считать их действительными.

Агрегация меняет видимый результат. Оператор может объявлять aggregate для экономии RIB. После окончания конкретной аренды aggregate способен остаться. Делегирующий маршрутизатор тогда отбрасывает пакеты к prefix, который больше не делегирован.

Следовательно, aggregate present не означает individual lease valid. И сохранение aggregate не означает, что отзыв нарушен. Проверка объединяет актуальный набор делегирований, область aggregate и обработку конкретного адресного пространства на границе.

Доверенная область не отменяет угрозы

Модель предполагает единую trusted SR domain. CPE управляется оператором или доверенным партнёром; даже на площадке клиента устройство и порты остаются в административной области оператора.

При этом DHCPv6 по умолчанию не даёт сквозного шифрования. Возможны перехват, подмена и прослушивание. Несколько механизмов выделения должны использовать непересекающиеся pools, иначе один locator может оказаться у разных устройств. Лимит на клиента не мешает злоумышленнику полностью, если он изображает множество клиентов.

Пограничный DHCPv6-клиент обязан фильтровать внутренний и внешний интерфейсы. Слово trusted в конфигурации не доказывает управление портами, разделение адресного пространства и текущие правила. Доверие — исполняемое условие.

Восстановить не заявление, а результат

Running-Code Primacy Хэна Лу ставит запись на правильное место: lease описывает административный факт, но не создаёт route. Minimum Initial Specification требует общего строгого минимума для совместимости и безопасности, не забирая будущие решения у локального оператора.

RFC 10038 стандартизирует коды, форматы, часы и поведение client/server/relay. Она не выбирает план SID, агрегацию и сервисную политику каждой сети. За границей стандарта начинаются локальные доказательства.

Воспроизводимая цепочка соединяет client identity, IAID, relay, server, locator, structure, Algorithm, T1/T2, lifetime, binding, настройку, route, announcement, convergence, SID, policy, filters и ограниченный packet test. Для Release ту же цепочку проходят в обратную сторону.

«Локатор выделен» — точный вывод. «Маршрут установлен и распространился» — другой. «Пакет дошёл в проверенных условиях» — третий. Коллективная работа Cheng и соавторов делает первый вывод проверяемым, не присваивая ему остальные.

Источники