Кратко

  • RFC 10038 вышел в августе 2026 года как документ IETF Standards Track. Он определяет DHCPv6 option 149 для IA SRv6 Locator, option 150 для отдельного Locator и status code 23, сообщающий об отсутствии свободного ресурса.
  • Успешный Reply подтверждает созданный сервером binding внутри одной доверенной SR domain. Он не подтверждает локальную настройку, маршрут, IGP advertisement, выбор RIB, программирование FIB, поведение SID, фильтрацию, результат пакета, отзыв и готовность к повторной выдаче.

Представим, что два распределителя ресурсов работают рядом. DHCPv6 считает свой pool свободным, а старый оркестратор хранит тот же диапазон в отдельном реестре. Оба выдают одинаковый Locator разным узлам. Наличие уникального IAID в каждой DHCPv6-сессии не устраняет конфликт реальных полномочий: протокол различает association, но не согласует два независимых источника.

RFC 10038 задаёт узкий и полезный механизм. Он позволяет передать SRv6 Locator узлу SRv6 Segment Endpoint по DHCPv6 внутри единой доверенной SR domain. Управляемый CPE может физически находиться у заказчика и оставаться частью этой области. Новые номера опубликованы в реестре IANA DHCPv6 Parameters.

Контейнер OPTION_IA_SRV6_LOCATOR, code 149, несёт IAID, T1, T2 и вложенные options. В сообщении может быть несколько таких контейнеров; их IAID уникальны в отдельном от других IA типов пространстве. Внутри находится OPTION_IALOCATOR, code 150, с preferred lifetime, valid lifetime, Algorithm, LB-Len, LN-Len, Fun-Len, Arg-Len и минимально закодированным Locator.

Длина Locator равна LB-Len плюс LN-Len. Сумма четырёх длин не должна превышать 128, а длина Locator не может быть нулевой. Нарушение делает конкретную option недействительной. Корректность полей не сообщает, что маршрут уже работает.

Подсказка клиента не заменяет политику сервера

Клиент обычно отправляет T1, T2, preferred lifetime и valid lifetime нулевыми. Сервер игнорирует предложенные клиентом значения этих полей и определяет время сам. Ненулевые LB-Len и LN-Len вместе с :: могут подсказать желаемый размер, но не дают права требовать конкретный prefix, layout или срок.

Сервер по своей политике выбирает pool, количество Locators и возможность выдачи. При нехватке он возвращает NoSRv6LocatorAvail, status 23. Клиент обязан отбросить Locator, если preferred lifetime больше valid lifetime. Порядок нескольких Locators нельзя превращать в признак приоритета, резерва или класса услуги.

Базовый RFC 9915 определяет DHCPv6 Solicit, Advertise, Request, Reply, Renew, Rebind и Release. Эти сообщения подтверждают транзакцию и identity association. Они не содержат согласия маршрутизаторов импортировать новый prefix.

Сам Locator не равен обычному адресу хоста или готовому SID. RFC 8402 описывает архитектуру Segment Routing, а RFC 8986 — структуру SID и endpoint behaviors. Локальная выдача SID, применение нескольких Locators и advertisement отдельных SID оставлены за пределами RFC 10038. Узел сохраняет собственное решение о функциях.

После Reply начинается распределённое принятие маршрута

DHCPv6 relay или server может установить локальный маршрут Locator с next hop к запрашивающему узлу. Затем он может объявить маршрут обычным routing protocol. Это два самостоятельных действия. Успех DHCPv6 не гарантирует ни одного из них.

После origin соседние процессы применяют аутентификацию, import policy и расчёт topology. Одна RIB принимает путь, другая отклоняет. Затем платформа программирует FIB; здесь возможны задержка, недостаток ресурсов и ошибка. Маршрут на origin не представляет состояние каждого удалённого data plane.

Для Algorithm zero подходит обычная IPv6 prefix reachability. При ненулевом Algorithm требуются Locator TLVs, указанные RFC 10038. RFC 9350 показывает, как IGP Flexible Algorithms несут ограничения topology. Если автоматизация оставит только prefix, она сохранит адрес и потеряет смысл пути.

На endpoint действует RFC 8754 для IPv6 Segment Routing Header и RFC 8986 для поведения. Пакет может попасть на нужный узел, но не найти требуемый SID, выполнить другую функцию или быть отвергнутым filter. Выдача пространства, доставка к узлу и разрешение услуги остаются разными утверждениями.

Освобождение должно дойти до плоскости данных

После корректного Release распределитель обязан освободить binding, удалить локальный маршрут и отозвать ранее объявленный маршрут. Lease database, routing process, RIB, FIB и пакеты меняются неатомарно. Запись free не доказывает, что старая достижимость исчезла повсюду.

У IA нет отдельного срока поверх её Locators: она заканчивается, когда заканчиваются все они. T1 сначала возвращает клиента к исходному серверу; T2 позволяет обратиться к доступному. Lifetimes измеряются оставшимися секундами, а 0xffffffff означает бесконечность. Они измеряют административную действительность, не момент последнего пакета.

Агрегация меняет место контроля. Покрывающий маршрут может продолжать доставлять пакеты к делегирующему edge после отзыва more-specific Locator. Тогда edge обязан отбрасывать на клиентском интерфейсе трафик к prefixes, которые больше не делегированы. Иначе прежнее полномочие остаётся исполнимым за aggregate.

Перед повторной выдачей нужны: закрытый binding, удалённый локальный маршрут, отозванное объявление, проверка RIB/FIB в разных точках, удалённый старый SID, canary разрешённого и запрещённого поведения, известный последний пакет и quarantine. Только после этого ресурс действительно отделён от прошлого владельца.

Доверенная область не отменяет безопасность

Предположение о доверенной SR domain ограничивает сценарий, но не создаёт универсальное end-to-end шифрование DHCPv6 и не аутентифицирует каждый пакет. Без дополнительных мер возможны перехват, подмена и наблюдение. Пограничному CPE нужны filters на внутренних и внешних интерфейсах; инфраструктурное Locator space желательно отличать от обычных пользовательских адресов.

Несогласованные allocators способны дважды выдать один Locator, если pools не разделены. Лимит на клиента не останавливает участника, который изображает множество клиентов. RFC 7227 и RFC 8168 требуют осторожности при создании options и специальной address semantics; RFC 8987 добавляет эксплуатационные условия SRv6 Network Programming. Регистрация IANA унифицирует wire format, но не сертифицирует распределитель или filter.

Общий журнал связывает выдачу с последним пакетом

Для Locator следует сохранить DUID, IAID, порт или relay context, авторизацию, версию policy, запрос и выданный layout, transaction time, lifetimes, T1/T2, binding и владельца pool. Затем — локальные SID, маршрут и next hop в RIB/FIB источника, тип IGP advertisement, Algorithm и version, удалённые RIB/FIB observations, filters, разрешённые и запрещённые canaries. Завершение включает Release или expiry, withdrawal, last packet, quarantine и reuse.

Принцип Heng Lu о первичности работающего кода требует судить по этой исполненной цепочке. Различие между техническим суверенитетом и практическим контролем данных объясняет, почему владелец binding database не контролирует копии маршрута на других устройствах. Подход минимальной начальной спецификации и локальных последующих решений сохраняет распределённую ответственность: общий протокол задаёт обмен, а каждый оператор отвечает за принятие и последствия.

RFC 10038 точно говорит, что сервер выдал. Сеть должна отдельно показать, что она приняла и что затем убрала.