Кратко

  • В RFC 1476 входное предложение проходило пять решений: приёмный фильтр, обновление метрик и опций, агрегацию, выбор активного маршрута и выходной фильтр для конкретного соседа.
  • Класс неизвестной опции мог сохранить её, удалить, оставить маршрут только локально или отбросить его целиком; это управляло совместимостью, но не доказывало доверие, пересылку или доставку.

У объявления не было прямой дороги в FIB

RFC 1476 описывала экспериментальный Route Access Protocol. Авторы хотели применить один дистанционно-векторный подход и в изолированной LAN, и в международной операторской сети. Жёсткая граница между внутренней и внешней маршрутизацией уступала место конкретной административной политике.

Наиболее важна не широта замысла, а схема процедуры. Маршруты приходили от RAP-соседей, из статической конфигурации, интерфейсов и других протоколов. Они проходили входной фильтр и агрегацию, образуя базу кандидатов. Из неё выбирались активные записи для IP forwarding database. Затем ещё один фильтр определял, какие активные записи отправить каждому соседу.

Карточка RFC Editor подтверждает документ, дату и Experimental-статус. Она не подтверждает работающий процесс, установленную запись или прошедший пакет.

Первое решение могло уничтожить будущий кандидат

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

RFC отмечала асимметрию времени. Если позже расширить фильтр, уже отброшенные объявления могут не появиться: сосед не обязан повторять их. Новая конфигурация доказывает готовность принять, но не наличие маршрута.

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

Второе решение задавало цену непонимания

RAP увеличивал distance, складывал delay и cost, а для MTU и bandwidth сохранял минимум пути. Известная политика могла заставить отбросить маршрут. Для неизвестной опции результат определял её класс.

Класс 0 разрешал использовать и распространять маршрут, требуя передавать опцию неизменной. Класс 1 разрешал использование и распространение без опции. Класс 2 оставлял маршрут для локального использования, запрещая дальнейшую передачу. Класс 3 требовал отбросить маршрут. Обязательной для понимания всеми была только дистанция в заголовке.

Класс не подтверждал подлинность. Он не удостоверял отправителя, содержание или безопасность реакции. Тип и класс были независимы, поэтому разные реализации могли выбрать разные классы для одного типа. Формат иногда позволял вывести неизвестное значение в журнал, но читаемое представление не давало смысла. Класс 1 не обещал конфиденциальности: тип можно было заменить null и отправить остальное описание.

Существующая статья про неизвестные опции IPv6 владеет битами skip/discard/report, а статья про BGP Partial — непрозрачной передачей optional-transitive атрибута. У RAP другая граница: неизвестная опция меняла место маршрута во всей локальной цепочке решений.

Ограничение источника, допустимое использование и открытая среда

Source Restriction перечислял источники, которым разрешено использовать маршрут. Если на уровне пересылки действовали фильтры безопасности, RAP должен был отразить их в информации о маршруте. Иначе пакет выбирал бы привлекательный путь и молча исчезал на последнем фильтре.

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

AUP обозначал кооперативную политику допустимого использования — например, запрет коммерческого трафика. RFC прямо отрицала, что это защитный барьер, подобный фильтру пересылки. Public предупреждал о broadcast-среде, где трафик могли читать посторонние приёмники. Разрешённый источник, разрешённая цель и открытость физической среды отвечали на разные вопросы.

Третье решение сокращало таблицу и объяснение

Более подробные маршруты через одного соседа иногда можно было включить в широкое предложение. Но RFC 1476 не требовала автоматической агрегации в каждом возможном случае. Политические атрибуты могли запретить её или привести к отбрасыванию кандидата.

RFC 1338 даёт контекст supernetting и тогдашнего давления на масштаб таблиц. RAP добавлял информационную цену: уменьшение состояния могло лишить следующего соседа различий, нужных его собственной политике. По одному агрегату нельзя восстановить полный состав и свойства участников.

Четвёртое решение создавало активный маршрут

После агрегации кандидаты RAP сравнивались с маршрутами из других источников, например RIP. Локальная политика могла использовать любое сочетание атрибутов и опций, выбирая записи для базы пересылки.

RFC 1058 была дистанционно-векторным ориентиром RIP, RFC 1247 — link-state ориентиром OSPF. RAP рассчитывал сосуществовать с ними, а не автоматически принимать результат каждого.

Запись в базе RAP не доказывала запись в FIB. Даже запись FIB не подтверждала, что конкретный пакет совпал с ней, вышел через нужный интерфейс или был принят дальше.

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

Выходной фильтр выбирал только часть активных маршрутов и мог создавать отдельный набор для каждого peer. Локально используемый маршрут мог не показываться одному соседу. Другой мог уйти без опции класса 1. Маршрут класса 2 не покидал локальную систему.

Отправитель также должен был отражать packet filters в предложении, чтобы сосед не направлял трафик в black hole. Нормативная фраза — не квитанция исполнения. Нужны действующий фильтр, точная отправленная форма, решение соседа и наблюдение данных.

Работающий TCP не означал работающий RAP

Соседи RAP держали одно симметричное TCP-соединение на порту 38 и не подтверждали каждую команду отдельно. Poll и No Operation проверяли жизнь на уровне самого RAP.

RFC не советовала полагаться лишь на TCP keepalive: он показывал, что удалённый TCP принимает данные, но не что процесс RAP жив. После разрыва каждая сторона должна была удалить все маршруты, предложенные соседом. Реальный факт удаления всё равно требовал журнала.

Последнее средство против циклов имело пределы. Distance и Trace обеспечивали в итоге разрыв при отсутствии повторяющейся ошибки, а не быструю сходимость. Постоянно возникающая ошибка могла создавать цикл заново.

Документ описывал развилки, а не внедрение

Соседняя RFC 1475 и её информационная запись помещают RAP в архитектуру TP/IX. Предыдущая статья уже закрепила за собой private next-hop identifier и время Add/Purge. Здесь предмет иной: пять локальных полномочий после получения предложения.

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

Такое чтение следует эссе Heng Lu о первичности работающего кода, минимальной исходной спецификации и локальном будущем решении и слоях реальности. Объявление доказывает вход в механизм решений. Оно не наследует авторитет фильтра, FIB, экспорта и результата.

Источники