Кратко

  • RFC 3053 отделил обращённый к пользователю Tunnel Broker, который разрешал запросы и заказывал конфигурацию, от Tunnel Server, завершавших туннели IPv6 поверх IPv4 и переносивших трафик.
  • Успешная регистрация, выдача адресов, обновление DNS или ответ о настройке не доказывали согласованность двух концов, прохождение инкапсуляции через IPv4 и обмен данными между приложениями.

В январе 2001 года подключение отдельного узла к складывавшемуся Интернету IPv6 могло потребовать ручной сборки настроенного туннеля. У пользователя уже была связь по IPv4. Поверх неё предстояло создать канал IPv6: указать оконечные адреса, префикс и маршруты, настроить интерфейсы, а часто и записи DNS. Каждый новый пользователь становился небольшим отдельным проектом для администратора.

RFC 3053 предложил сделать этот проект услугой. Пользователь обращался к доступному по IPv4 брокеру туннелей, подтверждал личность, передавал свой оконечный IPv4-адрес и получал параметры для запуска IPv6. Практическая выгода была очевидна: автоматизация вместо очереди вручную отредактированных запросов.

Однако документ получил статус Informational и не задавал нового протокола. Это была архитектурная схема. Возможно, её наиболее долговечный вклад — наглядное разделение удобной стойки обслуживания и машин с сетями, которые должны были исполнить данное у стойки обещание.

Брокер был точкой управления, но не обязательно путём пакетов

RFC отводил Tunnel Broker три основные обязанности. Там пользователи регистрировались и включали услугу. Брокер управлял созданием, изменением и удалением туннелей. Для масштабирования он распределял сетевые оконечные точки между одним или несколькими Tunnel Server и посылал приказ выбранному серверу.

У Tunnel Server была иная роль. Это подключённый к Интернету маршрутизатор с двумя стеками. По распоряжению брокера он создавал, менял или удалял свою сторону туннеля и мог учитывать статистику использования. Путь данных IPv6 поверх IPv4 проходил между клиентом и этим сервером. Он не шёл через брокер лишь потому, что брокер обслуживал учётную запись и форму заявки.

Разделение позволяло расти: одна административная служба распределяла работу между несколькими пересылающими устройствами. Вместе с тем оно разделяло доказательства. Запись в базе брокера показывала зафиксированное намерение. Доставленное управляющее сообщение — отправленный приказ. Состояние сервера — настроенный с одной стороны конец. Ни одна из этих квитанций сама по себе не показывала совместимую настройку клиента, пригодный путь IPv4 или вернувшийся пакет IPv6.

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

Полномочие предшествовало параметрам

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

После разрешения клиент передавал как минимум оконечный IPv4-адрес, желаемое имя DNS и свою роль — отдельный узел либо маршрутизатор. Затем брокер выбирал Tunnel Server и выделение IPv6, назначал срок жизни, мог обновить DNS, настраивал серверный конец и возвращал клиенту параметры и имена.

У каждого действия был ограниченный предмет. Аутентификация обосновывала решение позволить учётной записи запросить услугу. Она не доказывала, что заявленный адрес IPv4 принадлежит пользователю, остаётся доступным или пропускает инкапсулированный трафик. Выделение резервировало координаты IPv6 внутри службы брокера. DNS публиковал имя. Ни то ни другое не настраивало удалённый узел.

Клиенту всё ещё нужно было установить собственную сторону. Лишь после решения брокера, действия сервера и действия клиента текст называл туннель поднятым и работающим. И даже тогда «работа» была ожидаемым результатом схемы, а не трассой пакетов из каждой реализации.

Сценарий упрощал установку, заимствуя права root

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

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

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

За брокером тоже оставались независимые связи. Для управления сервером могли применяться защищённые команды RSH, безопасный SNMP или иная система. Для DNS — Dynamic DNS Update либо защищённые команды. RFC 3053 не сводил их в один протокол. Успех и безопасность каждого звена зависели от конкретной реализации.

Постоянная идентичность IPv6 на подвижном основании IPv4

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

Это полезное разделение: адресу и имени верхнего уровня не обязательно меняться вместе с нижним адресом доступа. Но непрерывность становилась согласованной операцией, а не свойством строки IPv6. Брокер должен был сохранить выделение, узнать пользователя, выбрать сервер, заменить конец, обновить затронутые записи и выдать новую клиентскую настройку. Нижняя сеть по-прежнему должна была достигать нового адреса.

Поэтому постоянный адрес IPv6 не означал постоянный путь. Это было обещание, подкреплённое записями и перенастройкой. Если запись брокера сохранилась, а пользователь не вернулся, выделение доказывало прошлое, но не текущую доступность.

Срок жизни был политикой уборки, а не признаком жизни

Активные туннели занимали память и процессор Tunnel Server. RFC советовал назначать каждому срок и удалять состояние по окончании, если клиент не попросил продлить его. Это ограничивало брошенные записи, но плохо совпадало с динамическим доступом: туннель мог числиться активным намного дольше сеанса IPv4.

Для ранней очистки рассматривались статистика трафика и доступности, удаление по бездействию и keep-alive. Любой такой сигнал требовал толкования. Молчание могло означать отключение, фильтрацию, бездействующего пользователя или неисправный обратный путь. Счётчик показывал байты, не обязательно доказывая, что у адреса находится прежний абонент. Полученный keep-alive подтверждал узкий момент, но не непрерывную доставку приложения.

Речь шла не только о потере ресурсов. Если пользователь отключился, не закрыв туннель, сервер мог продолжать посылать IPv6-трафик на старый IPv4-адрес. Провайдер уже мог отдать его другому абоненту. Устаревшее сопоставление превращалось в риск конфиденциальности.

Брокеру требовался не просто календарь истечения, а актуальное основание считать, кто занимает оконечную точку.

NAT сохранял право вето нижней сети

RFC 3053 прямо назвал ограничение: механизм мог не работать, если пользователь находился за NAT с частным IPv4. Брокер мог принять форму, проверить учётную запись и выделить пространство IPv6, а нижняя сеть всё равно не пропускала туннель.

Это показывает разницу между названием точки и её достижимостью. Частный адрес имеет смысл внутри сети пользователя, но не обязан быть координатой, куда способен отправить публичный Tunnel Server. Промежуточное устройство может не пропускать протокол 41. Уверенность плоскости управления и запись DNS не меняют этот факт пересылки.

Позднейшие туннельные и установочные механизмы работали в других средах и автоматизировали дополнительные переговоры. Нельзя задним числом приписывать их RFC 3053. Указать ограничение нижнего уровня — ещё не устранить его.

Защита управления не защищала переносимый разговор автоматически

RFC требовал защищать три административных взаимодействия: клиент с брокером, брокер с Tunnel Server и брокер с DNS. Среди вариантов были HTTPS, обычные учётные данные, AAA, безопасный SNMP и управление, защищённое IPsec.

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

В системе сосуществовало несколько полномочий. Пользователь мог просить туннель. Брокер мог настраивать сервер и отдельно менять зону DNS. Сервер пересылал пакеты согласно маршрутам. Ни одно разрешение не наследовало все остальные.

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

Настроенный туннель оставался цепочкой квитанций

Позднейшие стандарты добавили подробности. RFC 4213 определил поведение настроенных туннелей. RFC 4891 обсудил их защиту через IPsec. RFC 5572 задал конкретный Tunnel Setup Protocol. RFC 7059 сравнил семейства туннелей и их эксплуатационные компромиссы. Эти документы проясняют пространство решений, но не доказывают наличие всех поздних свойств в развёртывании RFC 3053.

Исторический урок уже. Брокер сделал подготовку понятной и повторяемой, но не слил участников. Регистрация, разрешение, выделение, публикация DNS, настройка сервера, настройка клиента, прохождение IPv4, маршрутизация IPv6, обратная достижимость и результат приложения остались разными переходами состояния.

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

Sources

Lu Heng не писал и не одобрял RFC 3053 либо связанные стандарты. Его эссе используются здесь как явно обозначенные аналитические линзы.