Кратко

  • RFC 3344 разрешал мобильному узлу установить бит S, чтобы при принятии нового care-of адреса домашний агент сохранил предыдущие привязки мобильности.
  • При поддержке одновременных привязок агент посылал копию каждой перехваченной дейтаграммы на все активные адреса; успешная новая регистрация не доказывала исключительность пути или закрытие старого.

Таблицу мобильности удобно представлять одной перезаписываемой строкой: постоянный домашний адрес, текущий care-of адрес и срок. RFC 3344 допускал другую структуру. У одного домашнего адреса могло быть несколько действующих строк с независимыми сроками, а домашний агент мог отправлять трафик по всем сразу.

Множественность задавалась явно. Бит S в Registration Request означал simultaneous bindings. Мобильный узел включал его, когда просил сохранить предыдущие привязки. Без запроса или без поддержки новый адрес заменял прежний набор.

Care-of адрес был концом туннеля, а не доказательством места

Mobile IPv4 сохранял домашний адрес после ухода узла из домашней сети. Care-of адрес обозначал точку завершения туннеля. Это мог быть адрес чужого агента, который снимал инкапсуляцию, либо адрес, полученный самим мобильным узлом в посещаемой сети.

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

RFC 3344 прямо описывал узел в зоне нескольких чужих агентов. Если домашний агент разрешал одновременные привязки, он перехватывал дейтаграмму к домашнему адресу, создавал отдельную копию для каждого care-of адреса и инкапсулировал её в соответствующий туннель. Документ напоминал, что IP допускает дублирование и узел может получить несколько копий.

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

Коды 0 и 1 сообщали разные виды успеха

Код 0 в Registration Reply означал принятую регистрацию. Код 1 тоже был успешным, но сообщал, что одновременные привязки не поддерживаются. Текущий реестр IANA Mobile IPv4 сохраняет оба значения среди успешных ответов.

После запроса с S код 0 позволял старому и новому адресам сосуществовать. Код 1 принимал новый адрес без запрошенной множественности. Код 135 означал уже отказ: одновременных привязок оказалось слишком много.

Если панель сводит 0 и 1 к одному зелёному «зарегистрировано», она теряет решающий контекст. Чтобы объяснить будущий дубль или его отсутствие, нужны отправленный бит, код ответа, полный набор привязок, срок каждой строки и наблюдение на каждом туннеле.

Одна истёкшая строка не закрывала остальные

Нулевой срок имел две области действия. Если care-of адрес совпадал с домашним, агент удалял все привязки и прекращал мобильную услугу. Если был указан конкретный недомашний адрес, удалялась только эта строка, а остальные продолжали действовать.

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

Само истечение не порождало Registration Reply. Запись посетителя у чужого агента могла исчезнуть естественно. Молчание поэтому не доказывало остановку всех маршрутов, а удаление одной строки — полную недоступность узла.

Идентичный повтор запроса также не продлевал разрешение скрытно. При совпадении домашнего адреса, care-of адреса и Identification новый срок не мог выходить за первоначально выданный. Корреляция и защита от replay не становились новым договором.

Поздние документы дали каждому пути имя и политику

RFC 3344 вышел в августе 2002 года и заменил RFC 3220 в линии, начатой RFC 2002. В 2010 году его заменил RFC 5944, сохранив несколько регистраций и копирование дейтаграммы на каждый активный care-of адрес. Один редакционный erratum со статусом Held for Document Update и один отклонённый технический erratum не меняют этот механизм.

В Mobile IPv6 RFC 3775 разделил основной care-of адрес и временно сохраняемый предыдущий. RFC 5648 добавил Binding Identifier для независимого управления несколькими адресами. Экспериментальный RFC 7629 позже принёс в Mobile IPv4 явные идентификаторы, несколько туннелей и правила для отдельных потоков.

Сравнение показывает границу старого S. Он задавал полное копирование, а не выбор лучшего пути, балансировку или проверку здоровья. Старая привязка могла быть полезным резервом, пустой тратой полосы или чёрной дырой. Одна таблица не отвечала на этот вопрос.

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

Источники