RFC: 3775
Оригинал: Mobility Support in IPv6
Другие версии: RFC 6275
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Шнитман Виктор Зиновьевич

11.7.3. Прием сообщений Binding Acknowledgement

После приема пакета, переносящего сообщение Binding Acknowledgement, мобильный узел должен (MUST) признать пакет годным в соответствии со следующими проверками:

  • Пакет соответствует требованиям аутентификации для сообщений Binding Acknowledgement, определенным в разд. 6.1.8 и 5. А именно, если сообщение Binding Update было послано домашнему агенту, то используется лежащая в основе защита IPsec. Если сообщение Binding Update было послано узлу-корреспонденту, то должна (MUST) присутствовать и иметь правомерное значение опция мобильности Binding Authorization Data.
  • Опция мобильности Binding Authorization Data, если присутствует, должна (MUST) быть последней опцией и не должна (MUST) иметь замыкающего заполнения.
  • Поле Sequence Number соответствует полю Sequence Number, посланному мобильным узлом на этот адрес места назначения в исходящем сообщении Binding Update.

Любое сообщение Binding Acknowledgement, которое не удовлетворяет всем этим проверкам должно(MUST) молча игнорироваться.

Когда мобильный узел получает пакет, переносящий правомерное сообщение Binding Acknowledgement, он должен (MUST) проверить поле Status следующим образом:

  • Если поле Status указывает на то, что сообщение Binding Update было признано годным (значение поля Status меньше 128), то мобильный узел должен (MUST) обновить соответствующий элемент в своем списке обновлений привязки для указания того, что сообщение Binding Update было подтверждено; тогда мобильный узел должен (MUST) прекратить посылку повторных сообщений Binding Update. Кроме того, если значение, указанное в поле Lifetime сообщения Binding Acknowledgement, меньше значения поля Lifetime, посланного в сообщении Binding Update, которое подтверждается, то мобильный узел должен (MUST) вычесть разницу между этими двумя значениями времени жизни из оставшегося времени жизни привязки, которое поддерживается в соответствующем элементе списка обновлений привязки (с минимальным значением времени жизни для элемента списка обновлений привязки, равным 0). Т.е., если значение времени жизни, посланное в сообщении Binding Update, было равно L_update, значение времени жизни, полученное в сообщении Binding Acknowledgement было равно L_ack, а текущее значение оставшегося времени жизни элемента списка обновлений привязки составляет L_remain, то новое значение оставшегося времени жизни элемента списка обновлений привязки должно стать равным

    max((L_remain - (L_update - L_ack)), 0)

    где max(X, Y) равно максимальному из значений X или Y. Результат этого шага заключается в том, чтобы правильно, с точки зрения мобильного узла, управлять оставшимся временем жизни привязки (которое поддерживается в соответствующем элементе списка обновлений привязки) так, чтобы оно правильно учитывало значение времени жизни, заданное в сообщении Binding Acknowledgement, но с учетом отсчета таймера, который начинал работать во время посылки сообщения Binding Update.

    Чтобы продлить время жизни, мобильные узлы должны (SHOULD) посылать новое сообщение Binding Update задолго до истечения этого периода времени. Это позволяет избежать нарушений связи, которые в противном случае могут стать причиной сетевых задержек или смещения времени.

  • Кроме того, если значение поля Status равно 1 (accepted but prefix discovery necessary — признано действительным, но требуется определение префиксов), мобильный узел должен (SHOULD) послать сообщение Mobile Prefix Solicitation, чтобы обновить свою информацию относительно доступных префиксов.

  • Если поле Status указывает на то, что сообщение Binding Update было признано негодным (значение поля Status больше или равно 128), то мобильный узел может предпринять шаги для устранения причины ошибки и повторной передачи сообщения Binding Update (с новым значением порядкового номера), что является предметом ограничения скорости, описанного в разд. 11.8. Если это не делается или не удается сделать, то мобильный узел в своем списке обновлений привязки должен отметить, что на это место назначения будущие сообщения Binding Update посылаться не должны (SHOULD NOT).

Обработка опции мобильности Binding Refresh Advice в сообщении Binding Acknowledgement зависит от того, откуда пришло подтверждение. Эта опция должна (MUST) игнорироваться, если подтверждение пришло от узла-корреспондента. Если оно пришло от домашнего агента, то мобильный узел использует поле Refresh Interval в этой опции как указание того, что он должен (SHOULD) пытаться обновлять свою регистрацию в домашнем агенте с указанным более коротким периодом времени.

Если подтверждение пришло от домашнего агента, то мобильный узел проверяет значение бита Key Management Mobility Capability (K). Если этот бит не установлен, мобильный узел должен (SHOULD) отказаться от соединений протокола управления ключами с домашним агентом, если они были. Мобильный узел может (MAY) также инициировать новое соединение управления ключами.

Если этот бит установлен, то мобильный узел должен (SHOULD) перенести свою собственную оконечную точку в соединениях протокола управления ключами, если они были. Новой оконечной точкой мобильного узла должен быть новый временный адрес. Для соединения фазы 1 IKE это означает, что пакеты, посылаемые на этот адрес с оригинальными идентифицирующими цепочками ISAKMP, считаются приемлемыми.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.