Кратко

  • RFC 831 был опубликован в декабре 1982 года как предложение для обсуждения, а не стандарт или отчёт о внедрении. Он рассматривал доступ к европейской части SATNET для обслуживания при разделении сети.
  • Многосетевой хост Header Munger должен был обрабатывать source route и менять адреса в обоих направлениях, но не рассылать маршрутные обновления. Алгоритм шлюза не превращал его в общий транзитный шлюз.
  • Если старое оборудование не умело сформировать обратный source route, M запоминал соответствие, названное «soft state». Документ не задавал аутентификацию, истечение, удаление или аудит; из-за неоднозначности каждому узлу SATNET одновременно соответствовал только один американский хост.

Мягким было название, а не полный контракт

Запись появлялась, когда запрос от американского управляющего хоста H проходил через аварийный посредник M к цели в SATNET. Ответ без обратного source route попадал на сторону M1, а таблица подсказывала, к какому H его следует отправить. Этого хватало для узкой задачи, пока каждому объекту SATNET соответствовал только один источник в США.

При втором источнике контекста уже не хватало. Обычный ответ содержал цель SATNET, но не позволял различить два H. Ограничение «один одновременно» было не планом производительности, а прямым свидетельством потери информации в ключе.

Почему вообще понадобилась такая память, объясняет топология. В нормальном режиме H проходил через Internet к шлюзу B компании BBN, затем через SIMP S1 входил в SATNET, пересекал спутниковую сеть до S2 и достигал шлюза G в University College London. После разделения американские шлюзы не имели нормального пути к S2, G и терминальному контроллеру UCL. Пакет с обычным адресом отбрасывался, возможно с ICMP Unreachable.

Обратная связность тоже исчезала: H становился недостижим с британской стороны. Поэтому перенести запрос в европейский сегмент означало решить лишь половину задачи.

Robert Braden описал варианты в RFC 831. Меморандум называл обход «back door», но прямо говорил, что предложение тогда не предназначалось для стандартизации. Это проект для дискуссии, а не доказательство реального развёртывания или применения во время аварии.

Обход не должен был стать известен протоколу маршрутизации

Аварийная цепочка шла от H к шлюзу VAN, через IP-туннель VANNET к системе UCL, далее по UCLNET к G и S2. Специальный код допускался в H и/или конечной системе UCL, но не требовался в G, S2 или шлюзе VAN. Сложность оставалась у двух участников, согласившихся её нести.

Обычный конец туннеля U нельзя было просто сделать шлюзом. Тогда шлюз VAN мог бы узнать от U общий маршрут в UCLNET и направить через VANNET не только служебные пакеты, но и обычный трафик UCL или RSRE, который должен идти через SATNET. Локальное средство ремонта стало бы незапланированной дорогой для других.

Вместо этого вводился Header Munger M: сторона M2 в VANNET и сторона M1 в UCLNET. M выполнял алгоритм шлюза для обработки маршрута, заданного отправителем, однако в остальном действовал как два хоста и не посылал маршрутных обновлений.

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

Две переписи заголовка чинили разные разрывы

H мог достичь M2, поэтому направлял запрос туда. M заменял адрес источника на M1, адрес назначения — на S2 и отправлял пакет в UCLNET. Для европейской стороны оба видимых конца становились локально достижимыми.

S2 отвечал M1. Затем M ещё раз менял заголовок так, чтобы пакет мог пройти VANNET и Internet к H. Если заменить только назначение в прямом направлении, S2 не сможет вернуть ответ H. Если заменить только источник, исходный запрос не найдёт из США изолированную цель.

Переписывание меняло и следы. Журнал рядом с S2 мог назвать M1, а устройство перед туннелем — только M2. Полученный ответ доказывал работоспособность конкретной цепочки, но не личность оператора, не разрешение на действие и не успешное завершение обслуживания.

Позднейшая трансляция адресов даёт полезную рамку сравнения. RFC 3022 описал статические и динамические отображения и цену замены сквозного смысла IP-адреса состоянием внутри сети. Но RFC 831 не называл себя NAT, не доказывает изобретение NAT и не устанавливает прямую историческую родословную.

Три способа вернуть ответ

Первый вариант использовал фиксированные соответствия. M отвечал за набор адресов M1/M2, заранее связанных с американскими источниками и целями SATNET. Поведение было понятным, но каждая пара требовала предварительной настройки и адресного ресурса.

Второй вариант применял source routing в обе стороны. RFC 791 определил Loose и Strict Source and Record Route. Отправитель перечислял промежуточные точки; в достигнутой точке следующий адрес становился IP-назначением, а текущий интерфейс попадал в запись. Умеющий развернуть запись получатель мог построить ответный путь.

G поддерживал source routing, но S2 и терминальный контроллер могли не уметь обращать записанный маршрут. Поэтому предпочтительным был гибрид. H задавал обход в прямом пакете. M при обработке запоминал связь H с целью SATNET. Обычный ответ к M1 затем возвращался к H по этой связи.

Вот это соответствие документ и называл «soft state». Нельзя дописывать ему свойства из других архитектур. RFC 831 не указывает период обновления, таймер истечения, правило удаления, восстановление после сбоя или журнал. Не определено и право создавать запись.

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

Один физический канал и четырнадцать цифр

VANNET опирался на коммутируемую X.25-службу, где платил вызывающий. Обычно UCL открывал туннель от U, а соединение с M2 должна была инициировать американская сторона. Направление вызова одновременно определяло ответственного за запуск и получателя счёта.

В UCL была одна физическая линия PSS. Чтобы U и M делили её, требовались разные X.25-подадреса. Шлюз VAN должен был поддерживать четырнадцатизначные, а не только двенадцатизначные адреса X.121. Две дополнительные цифры на нижнем уровне могли решить судьбу всей IP-схемы.

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

Хост нёс обязанности выполняемого шага

Позднейший RFC 1122 разрешил хосту быть промежуточным пунктом source route, но потребовал шлюзоподобной обработки TTL, ICMP и опций. Пересылка к нелокальной цели должна была включаться настраиваемым переключателем, по умолчанию выключенным, и ограничиваться политическими фильтрами.

Так формализовалась роль M. Размещение кода на хосте не уменьшало последствия промежуточной пересылки. Обязанность следовала за действием, а не за этикеткой машины.

Операционная норма менялась не сразу. RFC 1812 в 1995 году всё ещё требовал от маршрутизаторов поддержки source-route-опций в пересылаемых пакетах и допускал переключатель отбрасывания, который не был включён по умолчанию. Это историческая исходная точка, не современная рекомендация.

RFC 6274 позднее перечислил обход межсетевых экранов, доступ к иначе недостижимым системам, скрытые соединения, разведку топологии и истощение ресурсов и признал риск выше диагностической пользы. Рекомендацией стало отбрасывание по умолчанию. RFC 7126 отметил, что повсеместная фильтрация сделала LSRR почти бесполезным для диагностики, и потребовал отдельного документированного управления опцией с обычным состоянием drop.

Наличие механизма в опубликованном документе не обязывает независимого оператора пропускать его. Аварийная схема RFC 831 зависела и от добровольного согласия каждой сети на пути.

Позднее слово middlebox не отвечает на вопрос «кто разрешил»

RFC 3234 позднее назвал middlebox посредника, который делает больше обычной IP-маршрутизации, в том числе преобразует или отводит поток. Аналитически M похож на такое устройство: меняет заголовки, хранит соответствие, добавляет отказы и конфигурацию. В RFC 831 этого термина не было.

Классификация говорит о действии, но не о полномочии. Кто мог вызвать M, какие цели допускались, когда состояние прекращалось, кто отвечал за очистку? Слово «шлюз» было бы ещё опаснее, потому что намекало бы на общий транзит, который проект намеренно исключал.

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

Достижимость не подтверждала право на обслуживание

RFC 831 не определял аутентификацию, авторизацию цели, шифрование, служебные команды, согласование изменений или подтверждение результата. “Back door” в меморандуме — название запасного пути, а не свидетельство атаки. Однако всякий альтернативный путь пересекает границу, которую обычная топология больше не пересекает.

Необходимо разделять четыре вывода: запрос достиг входа; субъект установлен; цель и действие разрешены; конечное приложение подтвердило результат. Ответ, который M сумел вернуть, поддерживает первый вывод и не заменяет остальные.

Сохранившаяся ценность RFC 831 — в отказе расширить власть из-за аварии. Специальный код локализован, обычный трафик не должен менять путь, узел восстановления не предлагает себя как транзит.

Запасной вход оставался входом именно потому, что не объявлял себя маршрутом.