Кратко

  • RFC 5142 назначает тип 12 Mobility Header сообщению, которым уполномоченный домашний агент просит мобильный узел получить другого агента.
  • Протокол не решает, когда и кого перемещать: обслуживание и балансировка являются возможными локальными причинами.
  • Сообщение может передать упорядоченные альтернативные IPv6-адреса либо пустой список, запускающий поиск домашнего агента.
  • IPsec подтверждает происхождение и целостность сообщения, но не ёмкость, допуск или готовность пути у адресата.
  • Если отправляет текущий агент, Binding Update для удаления старой привязки служит подтверждением.
  • Это подтверждение фиксирует выход из старого состояния управления, а не появление нового работающего сервиса.
  • Поиск, Home Address, новые связи безопасности, регистрация, туннель, пакеты и прикладной результат требуют отдельных квитанций.
  • При отсутствии ответа старый агент не должен угадывать состояние узла и продолжает обслуживание до истечения привязки.
  • Темп должен зависеть от ресурсов нового агента либо быть намного ниже его возможности приёма; предел по умолчанию — одно сообщение в секунду.
  • Переход в другой домашний префикс способен сменить Home Address и оборвать существующие соединения после успешной регистрации.
  • Принятый Binding Acknowledgement доказывает состояние плоскости управления, а не сквозную доставку.
  • Руководству следует управлять поэтапным прибытием, сохраняя старый путь до подтверждения трафиком там, где это возможно.

Пригласить — не значит разместить

Не текущий домашний агент может обладать Security Association с мобильным узлом и отправить ему Home Agent Switch. В обычном случае такой отправитель указывает собственный адрес как предлагаемое место назначения. Мобильный узел, приняв предложение, направляет к нему Binding Update для создания домашней привязки; это обновление работает как подтверждение сообщения.

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

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

Минимальное сообщение оставляет будущие решения локальными

Home Agent Switch использует тип 12 Mobility Header. Он сообщает мобильному узлу, что следует прекратить пользоваться текущим домашним агентом и получить нового. RFC называет обслуживание, разгрузку, функциональное распределение и перенумерацию, однако механизм запуска находится вне спецификации.

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

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

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

IPsec проводит границу вокруг байтов

Для сообщения применяется IPsec между агентом и мобильным узлом. Требуется защита целостности ESP; конфиденциальность может скрыть перечень альтернатив. Эти механизмы подтверждают настроенного партнёра, целостность и защитные свойства обмена.

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

Журнал должен раздельно хранить личность отправителя, основание его полномочия, ресурсное наблюдение, выбравшее адресата, и более позднюю квитанцию адресата. Объединение всего этого в secure=true лишает систему возможности объяснить отказ.

Удаление старой привязки отвечает только старой стороне

Если сообщение приходит от текущего домашнего агента, мобильный узел перестаёт его использовать и посылает Binding Update, удаляющий старую привязку. RFC 5142 прямо называет это обновление подтверждением Switch-сообщения.

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

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

Управляемая цепочка различает: сообщение проверено; старая привязка удалена; кандидат выбран; безопасность установлена; новая привязка запрошена; ответ принят; туннель включён; первый пакет замечен; приложение продолжило работу. Каждая квитанция завершает только свою формулировку.

Молчание не выбирает причину

Домашний агент повторяет сообщение до соответствующего Binding Update. Интервал начинается с пяти секунд, растёт экспоненциально и ограничивается двадцатью секундами. Позднее можно продолжать с меньшей частотой без фиксированного конца.

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

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

Между обнаружением и трафиком находится вся передача

Документы о начальной настройке Mobile IPv6 разделяют адрес домашнего агента, Home Address и сведения авторизации либо IPsec-ассоциации, необходимые для регистрации. RFC 5026 систематизирует эти элементы. RFC 6610 и RFC 6611 дают способы обнаружения и предоставления информации. RFC 4640 описывает общую проблему загрузки.

Switch-сообщение не выполняет эти действия автоматически. Требуются выбор допустимого кандидата, решение по адресу, новая IKE/IPsec-связь, Binding Update, приемлемый Binding Acknowledgement, маршрут и туннель. Затем нужна фактическая передача пакетов, а для утверждения о непрерывности — наблюдение прикладного результата.

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

Скорость определяет приёмная сторона

Старому агенту дешевле отправить сообщение, чем новому выполнить криптографию, авторизацию, создать привязку и туннель. RFC 5142 требует обратной связи между ресурсами нового агента и последующими Switch-сообщениями либо максимума, заметно меньшего способности принимать регистрации. Значение по умолчанию — не более одного сообщения в секунду.

Это защитный предел, а не целевая производительность. Рост задержки IKE, отказов Binding Acknowledgement, времени установки туннеля или ожидания первого пакета должен замедлять источник. Адресат должен фактически управлять краном, иначе разгрузка одного узла перегрузит другой.

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

Источники

  1. RFC 5142, HTML
  2. RFC 5142, текст
  3. Запись RFC Editor
  4. IETF Datatracker
  5. История документа
  6. Поиск опечаток RFC 5142
  7. Параметры мобильности IANA
  8. RFC 3775: поддержка мобильности IPv6
  9. RFC 6275: поддержка мобильности IPv6
  10. RFC 4301: архитектура IP Security
  11. RFC 4303: Encapsulating Security Payload
  12. RFC 4877: Mobile IPv6 с IKEv2 и IPsec
  13. RFC 5026: начальная настройка Mobile IPv6
  14. RFC 6611: начальная настройка в интегрированном сценарии
  15. RFC 6610: DHCP-опции обнаружения домашней информации
  16. RFC 4640: проблема начальной настройки Mobile IPv6
  17. RFC 4192: перенумерация сетей IPv6
  18. Минимальная исходная спецификация, локальные будущие решения и добровольное принятие
  19. Уровни реальности, символическая власть и ясность
  20. Приоритет работающего кода