Кратко

  • RFC 2185 рассматривал достижимость IPv4 и IPv6 как два отдельных расчёта, даже когда туннель выглядел единственной обычной линией.
  • Передача достижимости в IPv6 была решением о размещении: маршрут выбирал инкапсулятор до того, как ответственность переходила к IPv4.
  • Видимый маршрут, резервный узел, успешная декапсуляция или доставка в одном направлении были ограниченными свидетельствами, а не доказательствами полномочий, симметрии или полного сервиса.

Маршрут должен был найти правильную границу

RFC 2185, опубликованный в сентябре 1997 года, описывал длительный переход с сосуществующими инфраструктурами IPv4 и IPv6. Под утечкой маршрута документ понимал объявление сетевой достижимости через границу областей маршрутизации. Маршруты IPv4 изучались протоколами IPv4, а IPv6 — протоколами IPv6; даже объединённая реализация не устраняла двойственность расчёта.

Карточка RFC Editor и IETF Datatracker задают важную границу выводов: документ имеет статус Informational, а не Internet Standard. Он описывает проект, возникший из работы ngtrans, но не доказывает масштабы внедрения, производительность в эксплуатации или завершение перехода.

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

RFC 1933 описывал механику перехода, включая MTU, фрагментацию и возврат ошибок ICMP. RFC 2003 определял IP-в-IP и предполагал, что выход умеет декапсулировать пакет. Эти документы объясняли оболочку. RFC 2185 задавал иной вопрос: какой маршрут приведёт пакет именно туда, где оболочка должна появиться.

Объявление достижимости назначало инкапсулятор

При автоматическом туннеле между хостами внешние адреса IPv4 извлекались из IPv4-совместимых адресов IPv6, и инкапсуляция происходила у источника. В модели настроенного шлюза хост отправлял внешнюю оболочку на IPv4-адрес двойного маршрутизатора, соединённого с магистралью IPv6; там заголовок снимался и продолжалась нативная маршрутизация IPv6. Настроенный адрес выбирал место смены ответственности.

Вариант «маршрутизатор — хост» делал полномочие ещё заметнее. Двойной маршрутизатор должен был внести в область IPv6 достижимость, соответствующую IPv4-совместимым назначениям. IPv6 вёл пакет к тому маршрутизатору, который опубликовал это обещание. Только после этого IPv4 отвечал за внешний участок.

Масштаб заставлял выбирать. Для небольшой периферийной сети IPv4 хватало агрегированного префикса. На границе крупной магистрали можно было загрузить в IPv6 всю таблицу IPv4, примерно удвоив состояние, либо вручную отбирать назначения, где предположительно находились системы IPv6. Первый вариант тратил ресурсы и расширял поверхность отказов; второй превращал человеческое мнение в постоянную эксплуатационную зависимость.

Резерв тоже не означал эквивалентный сервис. RFC описывал точные маршруты к предпочтительным узлам и покрывающий префикс, который мог отвести трафик к другому маршрутизатору после исчезновения точного маршрута. Это показывало лишь, что какой-то рекламодатель широкого префикса принял внешнюю оболочку. Из этого не следовали одинаковая политика, состояние туннеля, фильтры, MTU, ёмкость или продолжение IPv6.

Два направления могли использовать разные формы туннеля. Успешный прямой путь не моделировал обратный. Раздел безопасности предупреждал только о том, что туннелирование может нарушать правила межсетевых экранов базовой инфраструктуры; другие вопросы он не разбирал. Маршрутная доставка не была аутентификацией.

Каждому наблюдению — свой предел доказательства

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

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

Эта граница отделяет RFC 2185 от соседних историй. RFC 1955 предлагал ENCAPS, перенося другую абстракцию в заголовки автономных доменов, DNS и граничные маршрутизаторы. RFC 4213 позднее документировал базовые механизмы перехода и сохранил показательную модель: туннель считается одним переходом IPv6, но внешний TTL и путь IPv4 остаются независимыми. Особенность RFC 2185 — в указании того, кто должен свести два слоя.

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

Меморандум не доказал успех перехода. Его долговечный урок — точное место смены владельца обещания: IPv6 обещал правильный инкапсулятор, IPv4 — внешний выход, и только сквозной результат мог показать, что оба обязательства выполнены.