Кратко

  • HMIPv6 скрывает локальное перемещение за стабильной RCoA, которую MAP связывает с текущей LCoA.
  • Несколько доступных якорей — это набор возможностей; рабочее состояние требует точной связи между сессией, адресом, якорем, binding cache, туннелем и результатом доставки.

Список кандидатов не является текущим состоянием

Мобильный узел получает Router Advertisement с несколькими MAP options. У каждого якоря есть адрес, префикс, distance, preference и valid lifetime. Узел может зарегистрироваться более чем у одного MAP и использовать разные RCoA для разных групп correspondent nodes.

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

RFC 5380 не разрешает бесконтрольно строить многоуровневую цепочку. RCoA, полученную из префикса одного MAP, нельзя использовать как care-of address в Binding Update другому MAP. Иначе пакеты получат несколько уровней инкапсуляции, а эффективность ухудшится. Наличие правильных компонентов ещё не делает их произвольную композицию правильной.

Стабильный адрес переносит изменение внутрь

В HMIPv6 узел имеет RCoA на логической сети MAP и LCoA на текущем канале доступа. При перемещении внутри одного MAP-домена меняется только LCoA. Home agent и удалённые корреспонденты продолжают посылать трафик на RCoA.

MAP принимает эти пакеты, перехватывает их как локальный home agent, находит binding RCoA–LCoA и туннелирует к текущему местоположению. Для удалённой стороны движение становится прозрачным.

Прозрачность не уничтожает состояние. Она делает его локальным и менее видимым. Если cache указывает на старую LCoA, внешний адрес остаётся тем же, но доставку реализует уже неверная запись.

Поэтому инвентаря адресов недостаточно. Нужна текущая проекция: сессия → RCoA → MAP → LCoA → binding lifetime → security association → tunnel path → последнее наблюдение пакета.

Успешная регистрация имеет узкую семантику

Узел отправляет MAP локальный Binding Update. При успехе MAP сохраняет связь и возвращает Binding Acknowledgement. Узлу следует дождаться подтверждения перед регистрацией RCoA у других участников. Внешние bindings не могут иметь срок больше, чем локальный binding у MAP.

Подтверждение доказывает, что MAP принял состояние. Оно не доказывает, что пакет на RCoA был перехвачен, выбран правильный cache entry, туннель маршрутизируется до LCoA, узел получил и декапсулировал пакет, а приложение сохранило транзакцию.

Эти события образуют последовательность квитанций. Система, которая называет первое «доставкой», теряет место отказа и поощряет бессмысленные повторные регистрации.

Preference не выбирает истину

Preference выражает приоритет оператора. Distance участвует в процедуре выбора и не обязана быть измеренным числом переходов реального пути. Valid lifetime определяет срок объявления.

Нулевой lifetime — явный сигнал отказа: MAP нельзя выбирать, существующие bindings можно считать потерянными, нужен другой якорь. Если альтернативы нет, HMIPv6 использовать нельзя.

Положительный lifetime не является измерением нагрузки, потерь, достижимости LCoA или свежести cache. Отсутствие отрицательного сигнала нельзя превращать в положительную телеметрию. Политика выбора и здоровье forwarding требуют разных источников.

Междоменное движение временно создаёт двух владельцев

При переходе в другой MAP-домен меняется RCoA. Узел может сообщить прежнему MAP новый care-of address, чтобы тот перенаправлял пакеты, уже идущие к старому адресу. Администратор вправе ограничить такое forwarding за пределы домена.

Старый MAP теперь владеет временным мостом, новый — актуальным binding. Home agent и корреспонденты обновляются по своим таймерам. Контекст распределён не как постоянная архитектура, а как переходный процесс.

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

Инкапсуляция меняет допустимый пакет

Входящий и исходящий трафик туннелируется между узлом и MAP. При участии удалённого home agent возможна двойная инкапсуляция. RFC 5380 требует учитывать её при расчёте MTU для верхних уровней.

Небольшой Binding Update может пройти, а крупная прикладная нагрузка — нет. Состояние управления остаётся корректным, но физическая возможность доставки меняется. Это не утверждение о конкретной аварии; это обязательная граница проверки.

Нужно измерять репрезентативные размеры пакетов и наблюдать сигналы MTU. Проверка только коротким контрольным обменом создаёт ложное доказательство.

Аутентификация не назначает якорь владельцем результата

Связь узла и MAP должна включать взаимную аутентификацию, целостность и защиту от replay. MAP может ограничить допустимые on-link prefixes и отклонить LCoA из другой административной области.

Так определяется право записать binding. Но аутентифицированная запись не гарантирует маршрут, пропускную способность или работу приложения. Безопасность усиливает происхождение и целостность узкого сообщения; она не добавляет наблюдение за дальнейшими слоями.

Распределение функции и распределение ответственности

RFC 7429 рассматривает HMIPv6 как менее централизованный подход: локальный MAP сокращает сигнализацию к далёкому home agent. Одновременно документ отмечает пробелы в динамическом назначении и переносе якорей, discovery, selection и context transfer.

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

Единственная версия истины — это набор квитанций

Running-Code Primacy Хэн Лу требует отличать запись от её практического эффекта. MAP option говорит, что якорь объявлен. Binding Acknowledgement говорит, что состояние принято. Счётчик пакетов говорит, что определённая точка увидела трафик. Результат приложения говорит о полезной работе.

Истина о текущем якоре состоит не из одного поля, а из согласованной цепи discovery, selection, address formation, registration, cache retention, forwarding, path viability, endpoint processing и service outcome.

Якорей может быть много. Где находится единственная версия истины о текущем якоре — это уже вопрос управления.

Источники