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

11.5.2. Формирование новых временных адресов

После определения того, что он переместился, мобильный узел должен (SHOULD) сгенерировать новый основной временный адрес, используя обычные механизмы IPv6. Это должно быть (SHOULD) также сделано, когда текущий основной временный адрес становится опротестованным. Мобильный узел может (MAY) сформировать новый основной временный адрес в любой момент времени, но он не должен (MUST NOT) посылать своему домашнему агенту сообщение Binding Update относительно нового временного адреса чаще MAX_UPDATE_RATE раз в секунду.

Кроме того, мобильный узел может (MAY) формировать новые не основные временные адреса даже, когда он не переключился на новый подразумеваемый маршрутизатор. В каждый момент времени мобильный узел может иметь только один основной временный адрес (который регистрируется в его домашнем агенте), но может (MAY) иметь дополнительный временный адрес для любого префикса или для всех префиксов на своем текущем линке. Более того, поскольку интерфейс беспроводной сети в действительности может позволить мобильному узлу в каждый момент времени быть достижимым более чем на одном линке, (например, в рамках диапазона беспроводного передатчика маршрутизаторов на более чем одном отдельном линке), мобильный узел может (MAY) иметь временные адреса более чем на одном линке в каждый момент времени. Использование более одного временного адреса в каждый момент времени описывается в разд. 11.5.3.

Как описано в разд. 4, чтобы сформировать новый временный адрес, мобильный узел может (MAY) использовать либо бесконтекстное [13], либо контекстное (например, DHCPv6 [29]) автоконфигурирование адресов. Если в пакетах, являющихся частью процесса автоконфигурирования адресов, мобильному узлу необходимо использовать адрес источника (отличный от неспецифицированного адреса), он должен (MUST) использовать «локальный для линка» адрес, а не свой собственный домашний IPv6-адрес.

Спецификация RFC 2462 [13] указывает, что при обычной обработке определения дублирования адресов, узел должен (SHOULD) задержать посылку начального сообщения Neighbor Solicitation на случайное значение, находящееся в диапазоне от 0 до MAX_RTR_SOLICITATION_DELAY. Поскольку задержка определения дублирования адреса может привести к существенным задержкам при конфигурировании нового временного адреса, когда мобильный узел перемещается на новый линк, мобильный узел предпочтительно не должен (SHOULD NOT) задерживать процедуру DAD при конфигурировании нового временного адреса. Мобильный узел должен (SHOULD) обеспечивать задержку в соответствии с механизмами, специфицированными в RFC 2462, если только поведение реализации не нарушает синхронизацию шагов, которые происходят до DAD в случае, когда несколько узлов испытывают передачу обслуживания в один и тот же момент времени. Такое разсинхронизованное поведение может проявляться из-за случайных задержек в протоколах L2 или драйверах устройств, или из-за используемого механизма определения перемещения.

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

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