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

5.2.7. Обновление ключей узла и одноразовых номеров

Узлы-корреспонденты генерируют одноразовые номера через регулярные интервалы времени. Рекомендуется каждый одноразовый номер (указываемый индексом одноразового номера) поддерживать годным в течение, по крайней мере, MAX_TOKEN_LIFETIME секунд (см. разд. 12) после того, как он впервые был использован при создании ответа на сообщение обратной маршрутизируемости. Однако узел-корреспондент не должен (MUST NOT) считать приемлемыми одноразовые номера после MAX_NONCE_LIFETIME секунд (см. разд. 12) после первого использования. Поскольку разница между этими двумя константами составляет 30 секунд, удобным способом осуществления указанных выше времен жизни является генерация нового одноразового номера каждые 30 секунд. Тогда узел может продолжить принимать маркеры, которые были основаны на последних восьми (MAX_NONCE_LIFETIME/ 30) одноразовых номерах. Это приводит к тому, что маркеры оказываются годными в течение от MAX_TOKEN_LIFETIME до MAX_NONCE_LIFETIME секунд после того, как они были посланы мобильному узлу, в зависимости от того, был ли маркер послан в начале или в конце первого 30-секундного периода. Заметим, что узел-корреспондент может также попытаться генерировать новый одноразовый номер по запросу, или только если старые одноразовые номера были использованы. Это возможно до тех пор, пока узел-корреспондент отслеживает насколько давно одноразовые номера использовались впервые и не генерирует новых одноразовых номеров для каждого запроса обратной маршрутизируемости.

Из-за ограничений ресурсов, быстрого стирания обновлений или из-за перезагрузки узел-корреспондент может не всегда считать приемлемыми одноразовые номера, на которых основывались маркеры. Если индекс одноразового номера не признается годным, узел-корреспондент отвечает в подтверждении привязки кодом ошибки (136, 137, либо 138, как обсуждается в разд. 6.1.8). Тогда мобильный узел может повторить процедуру обратной маршрутизируемости.

Обновление Kcn должно (SHOULD) выполняться в то же время, что и обновление одноразового номера, так что индексы одноразовых номеров могут идентифицировать как одноразовый номер, так и ключ. Поэтому старые значения Kcn должны запоминаться до тех пор, пока хранятся старые значения одноразовых номеров.

Зная, что маркеры обычно предполагаются годными в течение MAX_TOKEN_LIFETIME секунд, мобильный узел может (MAY) их использовать после одного выполнения процедуры обратной маршрутизируемости до тех пор, пока не истечет время MAX_TOKEN_LIFETIME. После этого мобильный узел не должен (SHOULD NOT) использовать эти маркеры. Быстро перемещающийся мобильный узел может (MAY) повторно использовать последний маркер home keygen token от узла-корреспондента при переходе на новое местоположение, и непосредственно получить новый маркер care-of keygen token, чтобы продемонстрировать маршрутизируемость на новом местоположении.

Хотя в этом случае количество запросов и ответов из-за одновременной обработки проверок обратной маршрутизируемости не экономится, обмениваемых сообщений становится меньше, и потенциально длинный обмен запрос-ответ через домашнего агента аннулируется. Следовательно, такая оптимизация часто оказывается полезной. Мобильный узел, который имеет несколько домашних адресов, также может (MAY) использовать один и тот же маркер care-of keygen token для сообщений Binding Update, касающихся всех этих адресов.

Страница 17 из 120

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