Кратко

  • draft-ietf-spring-sid-as-source-address-00 опубликован 7 сентября 2026 года и получил статус документа рабочей группы SPRING. Это принятие темы в работу, а не RFC, окончательное согласие или проверка заявленной реализации.
  • Вместо loopback-адреса входного PE проект предлагает ставить во внешний IPv6-источник соответствующий сервисный SID. Тогда адреса прямого и обратного направлений образуют понятную фильтру пару.
  • Запись в таблице доказывает соответствие текущей сессии, но не личность узла или клиента. Сам проект предупреждает об ухудшении трассируемости, внутренней подмене SID и перегрузке состояния.

Обычная схема выглядит логично только в одном направлении. Входной PE инкапсулирует клиентский пакет и указывает свой loopback как внешний IPv6-источник. Удалённый VPN-сервис обозначается SID: непосредственно в поле назначения при best effort либо последним элементом SRH при Segment Routing Policy. Экран, понимающий SRv6, извлекает конечное назначение и строит тройку или пятёрку для состояния.

В ответе другой PE ставит другой loopback, а сервисный SID первой стороны становится конечным назначением. Значения не меняются местами зеркально. Если фильтр требует, чтобы источник ответа совпал с назначением запроса, две половины разговора выглядят независимыми. Маршрут может быть исправен, но ответ или ICMP-сообщение всё равно будет отброшено.

Проект меняет смысл источника. Определив L3 VPN, PE выбирает сервисный SID, который удалённая сторона ожидает для этого потока, и ставит его во внешний источник. Партнёр повторяет действие в обратном направлении. SID в поле источника ведёт себя как обычный IPv6-адрес и не запускает endpoint-функцию. Для таблицы возникает нужная симметрия.

Вместе с ней исчезает простая привязка к входному PE. Поле становится классификатором сервиса, выбранным маршрутизатором. Совпадение означает, что пакет подошёл к существующей записи при данном парсере и наборе правил. Оно само по себе не показывает корпус-отправитель, клиентский доступ, право на SID или отсутствие подмены.

Три масштаба SID показывают экономику решения. Вариант на VRF не требует дополнительного поиска, но сводит несколько CE к одному видимому источнику. Вариант на attachment circuit разделяет подключения без нового lookup. Вариант на префикс даёт более точную атрибуцию, однако заставляет PE искать клиентский адрес источника внутри VRF и может влиять на пересылку. Рекомендуемый порядок — префикс, AC, VPN/VRF — одновременно задаёт качество различения и цену.

Раздел безопасности не позволяет принять симметрию за доверие. Locator-префиксы обычно маршрутизируются внутри домена, поэтому внутренний узел может попытаться отправить пакет с чужим сервисным SID и воспользоваться правилом, доверяющим такому префиксу. Быстрая смена программируемых SID способна ускорить создание и старение сессий, истратить таблицу и вызвать переполнение. Разрешённые потоки, права происхождения, защита от подмены, жизненный цикл и лимиты состояния остаются отдельными механизмами.

У ICMP другая доказательная роль. SRv6 Ping может использовать End SID как внешний источник для проверки обратной достижимости. Транзитный узел может вернуть ошибку от SID, при обработке которого произошёл сбой, помогая head-end найти сегмент. Для VPN входной PE всё равно обязан обработать вложенный заголовок верхнего уровня по RFC 8986, чтобы внутренний ICMP дошёл до CE. Полезная локализация не аутентифицирует репортёра и не устанавливает первопричину.

Сжатие вводит зависимость от разбора. В RFC 9800 последний элемент routing header может отличаться от адреса, полученного конечной точкой, а сжатый список может находиться в destination без SRH. Новый проект рекомендует оставить конечное назначение несжатым последним элементом SRH. Если фильтр восстановит разный смысл назначения в двух направлениях, верный выбор источника на PE не спасёт сессию.

Заявление о реализации тоже ограничено. New H3C указывает CR16000 и CR19000 с версией 7.1.119 и выше, покрытие всех разделов и зрелость Production. Запись всё ещё относится к предшествующему Draft-13 и не содержит особого опыта эксплуатации. В логике RFC 7942 сам текст предупреждает: IETF не проверяла сведения участника и не одобряет продукт. Это свидетельство заявленного работающего кода, не независимый тест соответствия, совместимости или масштаба.

Разделение реальностей у Heng Lu помогает не расширять вывод. Статус рабочей группы — координация. Правило на PE — конфигурация. Пакет и строка таблицы — наблюдение. Доставка и доказуемая атрибуция — результат. Достоверность одного уровня не подписывает следующий.

Поэтому новость состоит не в появлении «правильного» адреса. SPRING приняла в работу осознанную замену семантики, уменьшающую ложные блокировки. Полная квитанция должна связать поколение SID, разрешённые PE, фактическую гранулярность, версию парсера, запись состояния, пакет и доставку клиенту. Тогда можно честно сказать: «ответ совпал с сессией», не превращая это в «источник установлен».

Источники

  1. IETF Datatracker — SID as source address in SRv6
  2. Проект рабочей группы 00
  3. Datatracker — предшествующий проект
  4. Редакция 13 предшествующего проекта
  5. SRv6 Security Considerations, редакция 16
  6. RFC 8402 — Архитектура Segment Routing
  7. RFC 8754 — IPv6 Segment Routing Header
  8. RFC 8986 — Программирование сети SRv6
  9. RFC 9252 — BGP Overlay Services на SRv6
  10. RFC 9259 — OAM в SRv6
  11. RFC 9800 — Сжатые списки сегментов SRv6
  12. RFC 7942 — Разделы о состоянии реализации
  13. Heng Lu — Running-Code Primacy
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Reality Layers