Кратко

  • Главный код RFC 5177 становится успешным, если Home Agent настроил пересылку хотя бы для одного Mobile Network Prefix. Это не подтверждает успех остальных членов запроса.
  • Даже положительный ответ по конкретному префиксу не обнаруживает физическую петлю во вложенной мобильной сети и не доказывает, что накопленные туннельные заголовки оставили приложению достаточный MTU.

Вложенный Mobile Router работает одинаково, подключён ли он к фиксированному Access Router или к сети другого Mobile Router. Такая прозрачность удобна: каждый уровень может зарегистрировать своё текущее положение, не требуя мобильности от узлов за ним.

Но одинаковая локальная операция не создаёт глобального знания. RFC 5177 допускает произвольную глубину вложения и тут же фиксирует две границы: протокол не обнаруживает и не устраняет физические петли, а каждый уровень добавляет ещё один заголовок туннеля.

Успех относится к члену множества

В явном режиме каждый префикс находится в отдельном Mobile Network Request. Home Agent проверяет пару Home Address–префикс, затем пытается установить пересылку. Отсутствие полномочий даёт MOBNET_UNAUTHORIZED; недостаток ресурсов — MOBNET_FWDING_SETUP_FAILED; некорректная длина имеет собственный код.

Главный Registration Reply отвечает не на вопрос «готово ли всё», а на вопрос «готово ли хотя бы что-то». При одном успешном префиксе код равен нулю. Только провал всего множества приводит к HA_MOBNET_ERROR.

Поэтому один зелёный уровень вложенной сети может соседствовать с отказом другого префикса на том же Home Agent. А несколько локально зелёных уровней могут образовать глобально непригодный путь.

Петля не обязана выглядеть как ошибка регистрации

Физическая петля возникает в топологии соединённых мобильных сетей, а регистрация описывает привязку и пересылку для Mobile Router. Каждое устройство может выполнить своё правило, не имея доказательства ацикличности всей конструкции. RFC прямо предупреждает, что пересылка дейтаграмм в такой петле может быть заблокирована.

Это классический разрыв между правильной записью и правильным миром. Квитанция Home Agent не ложна; просто её наблюдаемая область уже, чем решение «сервис доступен».

Заголовки съедают полезный MTU

Для Foreign Agent Care-of Address входящий пакет уже может получить двойную инкапсуляцию. Каждый новый вложенный Mobile Router добавляет ещё один заголовок. Доступный MTU уменьшается, а приложения без нормального обнаружения MTU страдают особенно сильно.

Положительный per-prefix acknowledgement не измеряет итоговый размер пакета и не проверяет поведение приложения. Для этого нужны сведения о глубине вложения, выбранной форме Care-of Address, фрагментации или PMTU и реальные пробы.

Пропуск в обновлении меняет сеть

Есть и более ранняя граница. При обновлении существующей binding Home Agent удаляет любой ранее зарегистрированный префикс, которого нет в новом явном запросе, и отключает его пересылку.

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

Динамическое выделение не меняет модель доказательств

RFC 6626 разрешает запросить выделение, передав нулевой Prefix и необязательную подсказку длины. Home Agent может вернуть сеть или MOBNET_UNASSIGNED; несколько запросов обрабатываются раздельно. Выделенная сеть живёт столько же, сколько binding cache entry.

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

Надёжный отчёт должен двигаться снизу вверх: индивидуальный результат префикса, таблица и FIB, туннели каждого уровня, отсутствие петли, доступный MTU, пробный пакет и приложение. Пропуск ступени не ускоряет доказательство — он лишь делает его шире источника.

Источники