Кратко

  • RFC 9647, опубликованный в октябре 2024 года как документ Standards Track, определяет YANG 1.1-модель ietf-babel для управления Babel через IPv6. Модель совместима с NMDA и построена на основе RFC 9046, но её задача — описать управляемое состояние и наблюдаемую информацию, а не самостоятельно доказать корректность всей сетевой цепочки. (RFC 9647, RFC 9046)
  • Модель делает проверяемыми административное включение Babel, параметры протокола, интерфейсы, наборы MAC-ключей, объекты DTLS и состояние маршрутов, включая префикс, идентификатор маршрутизатора, соседа, полученную и вычисленную метрику, порядковый номер, следующий переход, признаки feasible и selected.
  • YANG-дерево не является доказательством исполнения. RFC 9647 отдельно указывает, что YANG не может само по себе обязать реализацию заполнить обязательные доступные только для чтения атрибуты информационной модели: их должна фактически предоставлять реализация.
  • Практическая проверка Babel требует связывать минимум десять свидетельств: версию модели и возможности, происхождение и время данных, наличие read-only состояния, классификацию интерфейса, эффективные настройки, криптографическую идентичность, результаты аутентификации, хронологию соседей и маршрутов, установку в RIB/FIB и реальную передачу пакетов.

От конфигурации к доказательству

В сетевом управлении существует устойчивая ловушка: доступное для чтения состояние часто принимают за полное описание действительности. Если YANG-хранилище показывает, что маршрут Babel выбран, возникает естественный вопрос: выбран где именно и в каком смысле?

RFC 9647 отвечает на более узкий, но важный вопрос: какие объекты управления Babel должны быть представлены в стандартизированной модели данных. Он не утверждает, что одна запись маршрута является самостоятельным доказательством работоспособности пути. Значение selected — это проекция внутреннего состояния реализации Babel в управляемую модель. Оно не является независимым измерением прохождения пакета, гарантией установки записи в аппаратную таблицу пересылки или подтверждением того, что удалённый адрес действительно достижим.

Именно поэтому RFC 9647 важен не как «панель управления маршрутизацией», а как слой наблюдаемости между намерением оператора и фактическим поведением протокола.

Документ определяет модуль ietf-babel версии YANG 1.1 и учитывает архитектуру Network Management Datastore Architecture (NMDA), описанную в RFC 8342. В такой модели важно различать предназначенное состояние, рабочее состояние и операционное представление. (RFC 8342)

Что RFC 9647 делает проверяемым

Модель охватывает несколько классов объектов.

Первый класс — глобальное управление Babel. Сюда относится включение протокола и связанные параметры. Лист enable имеет особенно важное эксплуатационное значение: в running и intended он выражает административное намерение, а в operational показывает фактическое рабочее состояние. Разница между этими двумя представлениями — уже отдельное доказательство, которое оператор должен учитывать.

Второй класс — интерфейсы. RFC 9647 позволяет описывать участие конкретных интерфейсов в Babel, связанные настройки и параметры поведения.

Третий класс — криптографическая защита. Модель включает наборы MAC-ключей и объекты DTLS. Она также учитывает защиту чувствительных данных через NACM, определённый в RFC 8341. Это означает, что доступ к секретным материалам должен контролироваться политиками доступа, а не просто отражаться в открытом operational datastore. (RFC 8341)

Четвёртый класс — маршруты. Состояние маршрута содержит поля, которые позволяют увидеть внутреннюю картину выбора: префикс, router ID, соседа, полученную и вычисленную метрику, sequence number, next hop, а также признаки feasible и selected.

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

Где заканчивается ответственность YANG

Одна из наиболее важных границ RFC 9647 находится не внутри структуры дерева, а в ограничениях самой модели.

YANG описывает данные, которые должны существовать в интерфейсе управления. Однако YANG не способен заставить реализацию действительно иметь или вычислять обязательную read-only информацию. RFC 9647 прямо отмечает, что наличие таких данных зависит от реализации.

Это различие имеет практическое значение. Пустое поле, отсутствующий объект или неполное operational состояние могут означать разные вещи:

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

Поэтому соответствие схеме нельзя автоматически считать соответствием эксплуатации.

Интерфейсная политика: значение имеют детали

Babel работает не только с маршрутами, но и с характеристиками каналов. RFC 9647 отражает параметры, связанные с поведением интерфейсов, включая значения по умолчанию.

Для проводных интерфейсов стандартные настройки связаны с механизмом выбора через две из трёх условий и split horizon. Для беспроводных интерфейсов используются другие предпосылки: ETX без split horizon.

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

Таким образом, запись «интерфейс включён в Babel» недостаточна. Нужно доказать, какая именно политика применяется после учёта типа интерфейса, значений по умолчанию и локальных переопределений.

Настройки по умолчанию и скрытые связи

RFC 9647 описывает механизм настроек MAC и DTLS, которые применяются по умолчанию. Такие параметры могут добавлять ссылки на вновь созданные интерфейсы.

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

Практическая проверка должна включать:

  1. существование набора ключей или DTLS-объекта;
  2. корректность ссылки;
  3. факт применения к нужному интерфейсу;
  4. результат аутентификации соседнего обмена.

Особенно важно различать конфигурационную связь и фактический криптографический результат. Ссылка на ключ не является доказательством успешного MAC-проверочного процесса. Объект DTLS не является доказательством завершённого защищённого сеанса.

Маршрут selected и десять свидетельств

Для эксплуатационного аудита RFC 9647 полезно рассматривать не одну запись маршрута, а цепочку из десяти свидетельств.

Первое — версия модели и возможности. Нужно подтвердить revision модуля, поддерживаемые features и соответствие реализации ожидаемому набору возможностей. Сведения о YANG-параметрах и регистрации моделей дополняют этот слой. (IANA YANG Parameters)

Второе — datastore, происхождение и время. Любое состояние должно иметь контекст: откуда оно получено, какой datastore отражает и когда было актуально.

Третье — наличие обязательного read-only состояния. Нельзя предполагать, что отсутствующая информация эквивалентна нулевому значению.

Четвёртое — проверенная классификация интерфейса. Нужно установить, является ли канал проводным, беспроводным, туннельным или специальным резервным путём.

Пятое — эффективные настройки. Проверяются не только явные параметры, но и итоговая политика после применения defaults и overrides.

Шестое — MAC/DTLS-идентичность и привязка. Необходимо подтвердить, какие криптографические объекты применяются и где.

Седьмое — результаты аутентификации и handshake. Управляемое состояние должно быть сопоставлено с фактическим обменом.

Восьмое — хронология соседей и маршрутов. Последовательность событий важна: появление соседа, получение маршрута, изменение sequence number, пересчёт состояния.

Девятое — установка в RIB/FIB. Выбранный Babel маршрут должен быть сопоставлен с маршрутизирующей и пересылающей частью системы.

Десятое — передача пакетов, восстановление и независимая достижимость. Только внешний тест трафика и наблюдение после изменений показывают, что управление стало поведением.

Эта цепочка превращает RFC 9647 из простой схемы конфигурации в основу доказательной эксплуатации.

Безопасность: модель и протокол — разные уровни

Раздел безопасности RFC 9647 ограничен самой YANG-моделью. Он не заменяет требования безопасности протокола Babel.

Протокольные вопросы распределены по другим документам: RFC 8966 описывает Babel, RFC 8967 рассматривает MAC-аутентификацию, а RFC 8968 посвящён DTLS-защите. (RFC 8966, RFC 8967, RFC 8968)

Это важное разделение ответственности. YANG может показать, что объект защиты настроен. Но только протокол и наблюдение обмена могут подтвердить, что защита реально работает.

Практический предел автоматизации

RFC 9647 создаёт основу для автоматизации, но не устраняет необходимость инженерного контроля. Автоматизированная система может проверить наличие selected, сравнить intended и operational state, найти расхождения конфигурации и обнаружить отсутствие данных.

Однако автоматизация должна учитывать границу между намерением и результатом. Команда «включить Babel» не равна «маршрут распространяется». Маршрут в operational datastore не равен установленной записи пересылки. Запись в FIB не равна успешному прохождению пользовательского трафика.

Именно в этом месте RFC 9647 становится инструментом управления риском: он сокращает область неизвестного, но не отменяет необходимость доказательства.

Источники