Кратко

  • Входной пограничный маршрутизатор должен был получить из DNS адреса автономных доменов, поместить исходную датаграмму во внешний IP-заголовок, а выходной — снять оболочку и вернуть неизменный пакет обычной маршрутизации.
  • Отказ от изменений на хостах переносил затраты: требовались новая DNS-запись для каждого имени, адреса и маршруты доменов, обработка на двух границах и двадцать дополнительных байтов на каждую транзитную датаграмму.
  • RFC 1955 имеет статус Informational и прямо отделяет публикацию от принятия идей IPng. Проект предполагал глобальную уникальность внутренних IPv4-адресов, не обсуждал безопасность и не является свидетельством внедрения.

Миграция стала меньше по числу участников

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

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

Документ называет это преимуществом: хосты и большинство маршрутизаторов можно не менять, новые интернет- и маршрутные протоколы не обязательны, адреса внутри пакета не переводятся. Но уменьшился список обновляемых устройств, а не объем нового смысла. DNS должен был связать имена с доменами, границы — построить и снять оболочку, координаторы — выделить адреса доменов, а операторы — маршрутизировать их.

RFC был опубликован в июне 1996 года, хотя сам текст относит предложение к январю 1992-го, к группе ROAD, и говорит о первоначальном электронном письме. Позже материал подали в ответ на запрос RFC 1550. Важнейшее ограничение сформулировано в самом документе: публикация не означает, что направление IPng приняло эти идеи. Перед нами архив проектного выбора, а не протокол внедрения.

Два срока, которые нельзя было сложить

В начале 1990-х давление шло с разных сторон. Номера сетей класса B расходововались неэффективно. Маршрутные таблицы, вычислительная нагрузка и человеческая работа по их контролю росли. Полное исчерпание 32-битного пространства оставалось более дальней, но фундаментальной угрозой.

ROAD разделял действия на немедленные, кратко-, средне- и долгосрочные. Этапы следовало начинать одновременно: ближайший предел не ждал завершения новой архитектуры. Для краткосрочных мер изменение всех хостов было неприемлемо. RFC 1955 продолжил эту логику и назвал решение среднесрочным — оно должно было удержать сеть в рабочем состоянии, пока выбирается и развертывается долгосрочный вариант.

Так появляется обещание «выиграть время». Оно скромно, потому что не объявляет ENCAPS окончательным устройством Интернета. И оно масштабно, потому что обещает меньшие таблицы и широкую совместимость. Эти свойства нельзя превращать в факты задним числом. В зафиксированных источниках нет инвентаря установок, замеров, пакетных трасс или результатов межоператорской совместимости.

DNS задавал внешнее место назначения

Входной маршрутизатор должен был изучить источник и назначение внутреннего пакета и запросить в DNS соответствующие AD-адреса. Они становились источником и назначением внешнего заголовка. Междоменный транзит мог выбирать путь по оболочке, не зная подробностей каждой внутренней сети.

Для AD-адресов предлагалось зарезервировать несколько номеров сетей классов A и B. Часть значения обозначала особое пространство, оставшаяся часть — конкретный домен. Несколько таких пространств могли объединять домены в «commonwealths»: внутри группы сохранялись детальные маршруты, а другие группы представлялись укрупненно.

Пограничные маршрутизаторы должны были вводить нужные AD-адреса во внутридоменную маршрутизацию транзитных сетей. Обычный маршрутизатор тогда пересылал внешний пакет как знакомый IP-трафик, не понимая специальной роли адреса. BGP, IS-IS или OSPF упоминались как возможные средства расчета путей. Эта свобода оставалась свойством проекта, а не доказательством совместимости.

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

Нет перевода адресов — но есть состояние

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

Однако сохранность байтов не делала границу без состояния. Вход зависел от соответствия имени домену. Вся система зависела от распределения AD-идентификаторов и внешних маршрутов. Выход должен был распознать момент снятия заголовка. Безошибочно сохраненный пакет может оказаться безошибочно сохраненным не в том месте.

Сохранялось и базовое предположение: внутренние IPv4-адреса еще долго останутся глобально уникальными. Документ рассматривал сочетание AD- и IP-адреса как возможный будущий глобальный идентификатор. Но при неизменных хостах тогда потребовался бы NAT на границе. Чтобы избежать NAT, пришлось бы научить хосты самим искать соответствие и выполнять инкапсуляцию. Продолжение проекта нарушало бы одну из первоначальных границ. Компромисс был отложен, а не отменен.

Самая заметная цена составляла двадцать байтов

RFC 1955 прямо называет двадцатибайтовый внешний IP-заголовок для транзитного трафика и дополнительную обработку на входной и выходной границах. Эта часть счета видна в каждом пакете. Менее заметны записи DNS, распределение AD-номеров, членство в группах, маршруты внешней абстракции и диагностика двух уровней назначения.

Текст не задает полного порядка для времени жизни кэша, отрицательных ответов, проверки подлинности отображения, одностороннего обновления границ, Path MTU, фрагментации, отнесения ICMP-ошибок или завершения перехода. Вопросы безопасности прямо не обсуждаются. Из этих пробелов не следует, что схема обязательно неработоспособна. Следует другое: описание формата не доказывает эксплуатационную систему.

Более поздние документы об IP-in-IP подробнее определяли механику оболочек, а первая спецификация IPv6 зафиксировала иной результат процесса IPng. Они дают материал для ограниченного сравнения, но не подтверждают прямое происхождение от ENCAPS.

CIDR разместил агрегацию в другом месте

CIDR отвечал на рост таблиц топологическим распределением адресов и агрегируемыми префиксами с масками. Его цена приходилась на правила выделения, поддержку протоколов, привязку к провайдеру и необходимость перенумерации ради более чистой агрегации. Внешнего AD-заголовка на каждую транзитную датаграмму он не добавлял.

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

Предложение, конфигурация и доставка — разные доказательства

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

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

Рамка слоев реальности разделяет предложенный номер, опубликованную запись, загруженное состояние, выпущенную оболочку, исполненный маршрут, снятый заголовок и полученный сервис. Они связаны, но не равны. RFC 1955 полезен тем, что позволяет увидеть соблазн заменить одно доказательство другим.

Источники и пределы вывода

Идентичность и статус документа подтверждает запись RFC Editor о RFC 1955, а механизм и оговорки — RFC 1955. Контекст ROAD задает RFC 1380, запрос IPng — RFC 1550. Отдельную стратегию CIDR описывает RFC 1519, а современную альтернативу перевода — RFC 1631. Без утверждения о происхождении более поздние границы сравнения дают первая спецификация IPv6 и IP-in-IP. Аналитическую рамку составляют Running-Code Primacy, Minimum Initial Specification и Reality Layers.

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