Кратко
- В предиктивном режиме FBU, HI/HAck, туннель и буфер могут быть готовы до ухода мобильного узла от предыдущего маршрутизатора. Это свидетельства подготовки, а не присутствия на новом канале.
- Подключение канала, DAD или назначение другой NCoA, обработка UNA, выпуск буфера, обычный binding Mobile IPv6, получение пакетов и результат приложения требуют отдельных подтверждений.
Преимущество возникает до физического события
FMIPv6 переносит часть IP-работы на время до переключения. Мобильный узел узнаёт параметры маршрутизатора возможной точки доступа, формирует предполагаемый care-of address и разрешает перенаправление. Новый маршрутизатор может принимать пакеты ещё до того, как устройство установит с ним связь.
Так и сокращается задержка. Но та же последовательность провоцирует ошибку: зелёный статус туннеля превращают в «хэндовер завершён». RFC 5268 не оптимизирует время самого переключения канала и не определяет радиосигнал, по которому было предсказано движение.
RFC 5568 сделал RFC 5268 устаревшим и должен использоваться как современная норма. При этом вопрос контроля не меняется: какая часть пути была подготовлена и какое последующее наблюдение подтвердило реальный переход?
Данные о кандидате — это координаты, а не факт присутствия
Сообщение RtSolPr передаёт предыдущему маршрутизатору один или несколько AP-ID. В PrRtAdv возвращаются AR-Info: канальный адрес, IP-адрес и префикс потенциального нового маршрутизатора. На их основе узел формирует предполагаемую NCoA.
Выбор кандидата опирается на специфичные для канала триггеры вне спецификации. Устройство может выбрать другую точку, не суметь подключиться или вообще не совершить переход. Поэтому корректный статус звучит как «кандидат разрешён в поколении G», а не «устройство находится у NAR».
Поколение обязательно входит в идентичность события. Повторная попытка может использовать тот же AP и префикс. Без номера поколения старый ответ начинает незаконно подтверждать новый переход.
FBack приходит на старом канале
В предиктивном режиме FBU отправляется PAR до переключения. Он запрашивает связь PCoA с предполагаемой NCoA и перенаправление трафика. Опция FMIPv6 Binding Authorization Data подтверждает право отправителя действовать в отношении старого адреса.
Затем PAR и NAR обмениваются HI и HAck. Новый маршрутизатор принимает адрес, заменяет его или отказывает. FBack, полученный до ухода, сообщает об обработке запроса и подготовке туннеля. Точка наблюдения всё ещё находится на прежнем канале.
Реактивный режим показывает границу с другой стороны. Если узел сначала подключился к новому каналу либо ушёл, не получив FBack, он отправляет UNA и отправляет или повторяет FBU. Без прежнего FBack узел не знает, был ли первый запрос обработан.
HI/HAck также не является датчиком присутствия. Это решение между маршрутизаторами, защищённое ассоциацией безопасности, созданной вне протокола. Оно легитимирует подготовку инфраструктуры, но не наблюдает устройство.
У NCoA есть происхождение и смена полномочий
Адрес, сформированный из префикса, сначала является предложением. NAR может выполнить Duplicate Address Detection, принять его либо назначить другую NCoA через HAck/FBack. После подключения конфликт всё ещё может проявиться в NAACK и потребовать нового FBU.
RFC 5268 допускает очень малую вероятность коллизии, но не нулевую. Отказ от DAD возможен лишь по явной политике развёртывания, например при контролируемом управлении адресами. Сам прогноз не доказывает уникальность; применимая граница описана в RFC 4862.
Аудит должен раздельно хранить предложенный узлом адрес, результат DAD или основание его пропуска, назначенный маршрутизатором вариант, адрес после подключения и адрес последующего обычного binding. Одно поле NCoA стирает происхождение и оставляет отвергнутому значению лишние полномочия.
UNA разрешает пересылку, но не подтверждает доставку
RFC 5268 прямо говорит: один лишь туннель не гарантирует получение пакетов после подключения, если NAR не может обнаружить присутствие мобильного узла.
После установления канала узел посылает Unsolicited Neighbor Advertisement с очищенным битом Override. NAR удаляет proxy-запись или переводит неполную запись neighbour cache в STALE, после чего может выпускать туннелированные и буферизованные пакеты.
UNA — сильное свидетельство на стороне подключения. Однако оно не доказывает сохранность всех пакетов, получение стеком устройства или непрерывность приложения. Link-up, UNA, изменение neighbour cache, открытие буфера, отправка, приём и приложение составляют последовательную цепочку.
Буфер способен перенести потерю во времени
Пакеты могут попасть на NAR раньше устройства и без буфера будут потеряны. В реактивном режиме потеря возможна и на PAR до обработки FBU. Буфер уменьшает окно, но создаёт вопросы ёмкости и темпа выпуска.
Мгновенный сброс большой очереди перегружает маршрутизатор, канал или терминал и вызывает новую потерю, джиттер и перегрузку. RFC 5268 задаёт поведение по исходной скорости поступления и допускает не более пяти пакетов подряд перед дозированной выдачей остальных.
Приём в буфер, сохранённый диапазон, переполнение, триггер, скорость выпуска, реально переданные и реально полученные пакеты — разные измерения. Пустая очередь доказывает только то, что маршрутизатор больше не хранит её содержимое.
RFC 5568 отделяет и поколение формата
Замена изменила wire format. В RFC 5268 HI и HAck были сообщениями ICMPv6; RFC 5568 использует сообщения Mobility Header. Современная реализация не должна посылать старую форму, хотя может разбирать полученные сообщения ради совместимости.
Поэтому запись «HI» без формата и поколения неоднозначна. RFC 5268 полезен как историческое свидетельство различия между подготовкой и прибытием, но не как разрешение внедрять устаревшее кодирование.
После подключения остаются и обычные обязанности Mobile IPv6. Предварительная настройка не заменяет Binding Update, Return Routability и соответствующие полномочия binding по RFC 6275.
Работающий код — это последовательность границ
Принцип Running-Code Primacy Лу Хэна переносит внимание с ярлыка «бесшовная мобильность» на фактические действия: кандидат, proxy advertisement, предполагаемый адрес, авторизация FBU, решение маршрутизаторов, туннель и буфер, подключение, UNA, подтверждение адреса, выпуск, binding, приём и результат приложения.
Слои реальности не взаимозаменяемы. Прогноз — не подготовка; подготовка — не подключение; подключение — не уникальность адреса; возможность пересылки — не доставка; доставка — не непрерывность приложения.
Быстрый хэндовер выигрывает время именно потому, что один слой идёт впереди другого. Доверять абстракции можно лишь тогда, когда этот разрыв виден, а каждое утверждение возвращается к поколению, режиму, происхождению адреса и последней доказанной границе.
Источники
- RFC 5268: Mobile IPv6 Fast Handovers
- Запись RFC Editor о RFC 5268
- RFC 5568: действующая замена
- RFC 4861: Neighbor Discovery for IPv6
- RFC 4862: IPv6 Stateless Address Autoconfiguration
- RFC 6275: Mobility Support in IPv6
- Реестр IANA Mobility Parameters
- Lu Heng: Running-Code Primacy
- Lu Heng: On Reality Layers
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
