Кратко

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

У обещания появился более точный предел

RFC 2344, опубликованный в мае 1998 года, требовал от внешнего агента, объявляющего обратное туннелирование, поддержки и прямой доставки, и доставки с инкапсуляцией. В RFC 3024, который заменил его в январе 2001 года, эти обязанности разошлись: первая осталась обязательной, вторая стала рекомендуемой.

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

Здесь есть и ловушка для читателя источников. В одном месте RFC 3024 сохранилась старая пометка о том, что код 79 еще не выделен. Однако раздел о назначениях и приложение с перечнем изменений уже описывают выделение. Нынешний реестр Mobile IP у IANA также подтверждает назначение кода. Отдельная устаревшая скобка не должна перевешивать эти свидетельства.

Почему выбор способа доставки заслуживал самостоятельного отказа? Потому что способы отличались не только числом заголовков. Они по-разному определяли, какие пакеты возвращаются в домашнюю сеть и кто может это выбирать.

Домашний адрес отправился в чужую сеть

В октябре 1996 года RFC 2002 описал мобильность IPv4 между подсетями с сохранением домашнего адреса. Домашний агент направлял входящие данные к адресу текущего местонахождения — care-of address. Корреспондент продолжал обращаться к прежнему адресу, хотя физическая точка подключения узла изменилась.

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

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

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

Подлинность адреса не означает уместность источника

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

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

Сам RFC 2827 признавал трудность для Mobile IP и указывал на обратное туннелирование. Поэтому конфликт не нужно изображать как выбор между отказом от мобильности и отказом от защиты. Можно разделить адрес, который обозначает участника внутренней коммуникации, и адрес, который описывает текущий участок переноса.

При этом фильтр не устанавливает личность каждого отправителя. Подмена адреса внутри разрешенного префикса может пройти эту проверку. Топологическая правдоподобность — полезное, но ограниченное свидетельство.

Пакету пришлось вернуться, чтобы продолжить путь

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

RFC 2003 объясняет основное разделение: внутренний IP-заголовок содержит адреса исходной коммуникации, внешний — адреса концов туннельного участка. Когда внешний агент отправляет пакет домашнему агенту, внешним источником служит его care-of address. Внутри остается домашний адрес мобильного узла.

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

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

Прямая доставка не оставляет того же выбора

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

При доставке с инкапсуляцией узел сначала заворачивает пакет для внешнего агента. Тот снимает эту оболочку и создает новую для домашнего агента. На первом, локальном участке внешним источником все еще остается домашний адрес мобильного узла. Care-of address внешнего агента становится внешним источником только на следующем участке.

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

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

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

Что именно согласует регистрация

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

Доставку с инкапсуляцией запрашивает расширение типа 130 с нулевой длиной. Его отсутствие означает прямую доставку. Добавлять его при сброшенном T нельзя. Положение расширения относительно расширений аутентификации задано спецификацией; внешний агент обрабатывает его и не пересылает в неизменном виде домашнему агенту.

Выбирается конкретный способ передачи от узла внешнему агенту. Расширение не является заявлением о поддержке со стороны всех промежуточных сетей. RFC 3024 прямо исключает решение общей задачи прохождения межсетевых экранов из своего объема.

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

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

Проверка соседства и проверка привязки

Запрос регистрации должен отправляться с TTL 255, а внешний агент проверяет, что значение осталось таким. Прохождение IP-маршрутизатора уменьшает TTL, поэтому правило ограничивает некоторые попытки выдать удаленный запрос за локальный. Но сосед на том же канальном сегменте не становится аутентифицированным только потому, что его пакет сохранил число 255.

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

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

В описании обновления состояния есть проверенное техническое исправление RFC 3024: вместо ответа регистрации нужно читать запрос регистрации. Это меняет не стиль изложения, а направление сообщения, на основании которого обновляется привязка. Точность истории зависит и от таких небольших исправлений.

Частное адресное пространство не исчезло

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

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

В ноябре 2010 года RFC 5944 по-прежнему отсылал к обратному туннелю в обсуждении входной фильтрации. Это свидетельство сохранения архитектурной задачи, а не оценка числа действующих установок.

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