Кратко
- RFC 3963 позволил Mobile Router менять внешнюю точку подключения одного или нескольких Mobile Network Prefix, не вовлекая внутренние узлы в мобильность. Положительное подтверждение с флагом R означало обработку и настройку пересылки, но не доступность каждого адресата.
- Явный, неявный и динамический режимы опирались на разные источники сведений о префиксах. Поэтому полномочие, маршрут, туннель, проверка узла, сессия и услуга должны иметь отдельные свидетельства.
Представим сеть в поезде или специальной машине. Датчики, терминалы и серверы продолжают использовать прежние адреса и один шлюз, когда транспорт переезжает из одной сети доступа в другую. Мобильным становится именно шлюз. Опубликованный в январе 2005 года RFC 3963 стандартизировал эту схему как NEMO Basic Support.
Покинув домашний канал, Mobile Router получал Care-of Address и направлял своему Home Agent сообщение Binding Update. Флаг R запрашивал режим мобильного маршрутизатора. Агент связывал постоянный Home Address с временным адресом и устанавливал пересылку для разрешённых Mobile Network Prefix. Двунаправленный туннель соединял агента с текущим местоположением маршрутизатора.
Успех имел узкое значение. Binding Acknowledgement со статусом ноль и R позволял считать, что агент обработал обновление и настроил пересылку префиксов. Ответ не опрашивал внутренние устройства, не сохранял их сессии, не оптимизировал путь и не выдавал прикладное разрешение. Это была квитанция плоскости управления.
Флаг задавал роль сообщения, а не личность отправителя
Маршрутизатор ставил R в запросе, Home Agent возвращал его при положительном решении. Бит указывал требуемую обработку, но сам никого не аутентифицировал. RFC 3963 требовал защищать сигнализацию между сторонами с помощью IPsec. Подлинность давала защищённая ассоциация, а R сообщал смысл операции внутри неё.
Поэтому запись «binding успешен» недостаточна. Для разбора нужны Home Address, Care-of Address, номер последовательности, срок жизни, H и R, точные опции префиксов, IPsec-ассоциация, код ответа, концы туннеля, добавленные и удалённые маршруты. Даже полный набор описывает пересылку, а не здоровье устройств за маршрутизатором.
Границу показывает семейство стандартов. RFC 3775 задавал основу Mobile IPv6 для отдельного хоста, позднее пересмотренную в RFC 6275. RFC 3963 поместил за мобильной точкой целую сеть. Объём представляемых адресов вырос, но способность наблюдать их — нет.
Один результат мог происходить из трёх источников
В явном режиме Binding Update содержал одну или несколько опций Mobile Network Prefix. Home Agent мог сверить их с Prefix Table, где указаны разрешённые для маршрутизатора префиксы. Решение было атомарным: если пересылку нельзя создать для каждого перечисленного префикса, нельзя пересылать ни один, а запрос отклоняется со статусом 141. Неавторизованный префикс приводил к 142.
Правило «всё или ничего» не позволяло одной квитанции скрыть частично перенесённую сеть. Но совпадение с таблицей доказывало только полномочие. Оно ничего не говорило о том, включён ли конкретный узел внутри блока.
В неявном режиме опции префикса не было. Home Agent использовал заранее настроенные сведения, а при их отсутствии отвечал 143. Внешне одинаковый успех мог основываться на данных текущего пакета или на записи во внешней системе. В журнале должны оставаться режим, версия конфигурации, её владелец и время наблюдения.
Динамический протокол маршрутизации через туннель создавал третий источник. Он позволял учить изменения, но мог раскрывать внутреннюю топологию, поэтому документ рекомендовал конфиденциальность ESP для таких сообщений. Фраза «маршрут установлен» без происхождения неоднозначна: статический ли он, явно запрошенный, неявно настроенный или изученный?
Особенно важна оговорка стандарта о статических маршрутах. Они сокращали сигнализацию, но могли оставаться после того, как связанный Mobile Router становился недоступен. Таблица могла точно хранить намерение и одновременно ошибочно выглядеть доказательством текущей жизни.
Прозрачность концентрировала зависимость
В базовом режиме трафик между Mobile Network Nodes и Correspondent Nodes проходил через Home Agent. Для нисходящего трафика агент инкапсулировал пакет к Care-of Address. Маршрутизатор проверял внешнего отправителя как своего агента, если это уже не обеспечивал туннельный IPsec, и убеждался, что внутренний адрес назначения принадлежит мобильному префиксу.
На восходящем пути Mobile Router фильтровал внутренние источники вне разрешённых префиксов, а Home Agent выполнял собственную топологическую проверку перед выпуском пакета. Это ограничивало подмену адреса, но не аутентифицировало пользователя и не принимало бизнес-решение.
Basic Support не определял оптимизацию маршрута для трафика мобильных префиксов. Вложенные маршрутизаторы могли образовать дерево и сложить несколько туннелей. RFC 4885, RFC 4886 и RFC 4887 систематизировали термины, цели и проблемы. RFC 4888 разобрал трудности оптимизации, а RFC 4889 — пространство решений. Работающий путь не обязательно был оптимальным.
Более поздние документы добавили соседние механизмы. RFC 5488 и RFC 6276 описывали делегирование префиксов DHCPv6 для мобильных сетей; RFC 6089 — flow bindings. Они расширяли цепь решений, но не превращали исходное подтверждение в проверку узлов.
Официальную историю фиксируют страница RFC Editor, поиск исправлений, IETF Datatracker и реестр IANA Mobility Parameters. Эти источники подтверждают статус документа, заявленные исправления и распределённые значения, но не внедрение и не качество конкретной реализации.
Эксплуатационный реестр должен хранить ступени отдельно: событие движения; два адреса; последовательность, время и флаги обновления; режим определения префиксов; источник полномочия; атомарное решение; подтверждение; IPsec; концы туннеля; каждую установку и отмену маршрута; проверки адресов; тесты префиксов; ответы узлов; продолжение сессий; результат услуги. Тогда успех одной ступени не переписывает остальные.
RFC 3963 переместил много адресов малым числом сообщений. Его более общий урок — не разрешать одному сообщению свидетельствовать о слишком большом числе ненаблюдаемых результатов.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
