Кратко

  • В RFC 1475 64-битный идентификатор прямого маршрута понимал только выдавший его маршрутизатор следующего перехода; на каждом хопе значение обычно заменялось.
  • Нулевое или недействительное значение возвращало обработку к обычному поиску назначения, а агрегация, смена маршрута, поток и преобразование протокола требовали нового решения.
  • Статусы Experimental и Historic, а также развитие идеи в CATNIP описывают историю документов, но не доказывают внедрение или путь конкретного пакета.

Идентификатор пережил объявление — маршрут мог не пережить

Сопутствующий протокол RAP позволял маршрутизатору объявить соседу маршрут вместе с 64-битным числом. В момент объявления маршрут должен был действительно находиться в таблице пересылки отправителя. Но сеть меняется: запись удаляется, уведомление об отзыве уходит по каналу, уже отправленные пакеты продолжают движение. У каждого события свои часы.

Эта проблема времени встроена в RFC 1475, опубликованную в июне 1993 года. Документ описывал TP/IX, также названный Internet Protocol version 7. Предложение расширяло адреса, меняло транспортные поля и пыталось совместить обычную пересылку дейтаграмм с более быстрыми маршрутными и потоковыми механизмами. Для этого каждая дейтаграмма получала forward route identifier длиной 64 бита.

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

Следовательно, число несло прошлое утверждение о локальном состоянии. Его подлинность как следа объявления не гарантировала актуальность объекта при следующем использовании.

A, B и C заменяли значение, а не продолжали его

RFC приводит цепочку от хоста X к хосту Y через маршрутизаторы A, B и C. C сообщает B о маршруте к Y и передаёт свой внутренний идентификатор. Для B это непрозрачный объект. B строит маршрут через C, а затем сообщает A другой идентификатор — уже из внутреннего пространства B.

Первую дейтаграмму X посылает с нулём. A выполняет обычный поиск по адресу назначения, выбирает B, записывает идентификатор B и отправляет пакет. B понимает свою ссылку, находит маршрут через C, заменяет поле идентификатором C и пересылает дальше. C использует выданную им самим ссылку, обнуляет поле и доставляет пакет к Y. Хост назначения узнаёт свой адрес и игнорирует маршрутный идентификатор.

Одно и то же поле последовательно принадлежит разным органам толкования. На выходе A оно отражает то, что B ранее сообщил A. На входе B оно может быть ключом к текущему объекту B. На выходе B там уже число C. У назначения обязательного смысла у поля нет.

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

Ноль не означал отсутствие достижимости

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

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

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

RFC прямо говорила, что вопросы безопасности не рассматриваются. Проверка диапазона, выравнивания и назначения — не аутентификация, не авторизация и не контроль целостности. Локальная ссылка не становится полномочием только потому, что имеет допустимую форму.

Агрегация требовала уточнения

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

Изменение маршрута создавало ту же границу во времени. Если таблицы менялись, пока дейтаграммы были в полёте, какой-то маршрутизатор должен был решить, как вновь поставить каждую из них на «рельсы». Поле в пакете не замораживало систему управления. Между выпуском указателя и его предъявлением объект мог исчезнуть или получить иной смысл.

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

Поток оставался частным объектом

TP/IX разрешал вместо идентификатора маршрута использовать идентификатор потока. Каждый маршрутизатор мог хранить частный объект потока, связанный с маршрутом, на котором поток был создан. Дейтаграммы могли входить в поток и выходить из него.

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

Локальная свобода была преимуществом: не требовалось стандартизировать структуру таблиц каждого производителя. Но та же свобода не позволяла внешнему сборщику объявить число самодостаточным доказательством.

RAP не мог устранить окно отзыва

RFC 1476 описывала Route Access Protocol, распределявший эти маршруты. Команда Add Route должна была соответствовать маршруту, реально загруженному в базу пересылки отправителя на момент объявления. Получатель помещал предложенный идентификатор в дейтаграммы, отправляемые обратно этому партнёру.

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

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

Преобразователь обнулял чужую ссылку

TP/IX стремился позволить узлам IPv4 и IPv7 обновляться в любом порядке, поэтому предусматривал преобразование. Опция “Don't Convert” ограничивала поведение маршрутизаторов на проводе, но принимающий хост всё ещё мог преобразовать данные внутри своей процедуры. Фрагменты, прошедшие разными путями и попавшие к разным преобразователям, могли быть потеряны. Гибридный IPv7-адрес также не доказывал нативную реализацию IPv7.

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

Historic закрывает строку документа, а не измеряет каждый опыт

Запись RFC Editor теперь помечает RFC 1475 как Historic. RFC 1752 зафиксировала развитие TP/IX в CATNIP, сочла CATNIP слишком неполным для выбора и рекомендовала 128-битный SIPP как основу IPng. Позднее RFC 6814 формально отменила RFC 1475 при очистке устаревших опций IPv4. RFC 791 сохранилась как базовая спецификация IPv4.

Эта цепочка отвечает на вопросы о предложении, сравнении и документальном решении. Она не доказывает, что никто не реализовал отдельный механизм или что конкретная экспериментальная сеть его не испытывала. Обратное тоже верно: публикация RFC и название «The Next Internet» не доказывают производственное внедрение.

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

Источники