Приложения протокола розыска соседей

Допустим теперь, что маршрутизаторы М и Н рассылают объявления RA. Они адресованы группе "все узлы канала", так что хост А будет получать объявления не только от М, но и от Н. Поэтому маршрутизатор Н сможет оптимизировать направление трафика, объявив, что префикс 2001:DB8:777::/64 — "на канале" (L = 1). Тогда хост А зафиксирует 2001:DB8:777::/64 в своем списке префиксов, и трафик от А к Б пойдет по кратчайшему пути. Точно так же хост Б получит объявление RA от маршрутизатора М, поместит 2001:DB8:33::/64 в свой список префиксов, и обратный трафик от Б к А тоже пойдет напрямую.

Прекрасно, теперь хост IPv6 может в автоматическом режиме получать собственные адреса, адреса маршрутизаторов по умолчанию и префиксы "на канале". А как быть, если какие-то из этих параметров изменят свои значения в ходе работы сети? Ведь маршрутизаторы и префиксы вполне могут возникать и исчезать по желанию сетевого администратора. Очевидно, что в этом случае вся сеть должна подстраиваться к новым условиям, чтобы администратору не пришлось вручную вычищать старые параметры из конфигурации хостов. В противном случае ценность механизмов автоматической настройки IPv6 будет равна одному ломаному грошу, да и то в базарный день.

Решить эту задачу можно, если параметры хоста не будут вечными. Вот возможная схема [§6.3.5 RFC 4861, §5.5.3 и §5.5.4 RFC 4862]:

• в конфигурации хоста с каждым параметром связан таймер;
• в объявлении RA каждый параметр снабжен временем жизни;
• хост перезапускает таймер для тех параметров, которые приведены в RA;

• хост удаляет параметр из своих настроек, если:

  o

  его время жизни истекает по таймеру, или

  o

  объявление RA сообщает, что новое время жизни параметра нулевое.

Здесь под параметром мы понимаем автоматически настроенный адрес, или элемент в списке маршрутизаторов по умолчанию, или префикс "на канале". Конечно, автоматически настроенный адрес наследует свое время жизни у префикса с установленным флагом A, из которого он образован.

Добавление нового параметра проблем не вызывает. Автоматически составив пробный адрес из нового префикса с A = 1, хост должен всего лишь убедиться в его уникальности с помощью DAD, прежде чем назначит его интерфейсу (см. §5.4.1). Адрес нового маршрутизатора достаточно внести в список маршрутизаторов по умолчанию, чтобы можно было им воспользоваться, когда NUD обнаружит сбой текущего маршрутизатора (см. §5.2). Новым префиксом "на канале" (L = 1) можно пользоваться немедленно, как только он будет внесен в список префиксов (см. §5.2).

Будет ли так же проста процедура удаления этих параметров? Два последних вида параметров, маршрутизаторы по умолчанию и префиксы "на канале", определяют только мгновенное решение хоста, как маршрутизировать исходящий пакет, — они явным образом не влияют на долговременное состояние хоста. Более того, исчезновение маршрутизатора или префикса "на канале" — это внешнее событие, на которое хост повлиять неспособен. Поэтому параметры этих двух видов можно и нужно удалить, как только истечет время их жизни по таймеру или объявлению RA.

В то же время, у локального адреса IP свойства особенные. Во-первых, к нему привязаны протяженные во времени сеансы вышестоящих протоколов, а безусловное удаление адреса вызовет их обрыв. Во-вторых, хост все-таки сам управляет своими адресами, пусть даже на основании внешних сведений, таких как административная конфигурация или объявления RA. Благодаря этому перед хостом открывается возможность провести удаление просроченного адреса по более сложной, но менее болезненной процедуре.

Чтобы "прощание" прошло гладко, пусть хост расстается с просроченным адресом в два этапа [§1 и §5.5.4 RFC 4862].

Здесь не работает пословица: долгие проводы — лишние слезы.

Пока время жизни адреса еще не истекло, он доступен как для создания новых сеансов ,^{11 Определение сеанса остается на усмотрение вышестоящих протоколов.} так и для продолжения уже начатых. Такой адрес называют предпочтительным (preferred). Когда его время жизни истекает, адрес становится устаревшим (deprecated): с него больше нельзя устанавливать новые сеансы, но старые, тем не менее, продолжаются и завершаются — по крайней мере, мы на это надеемся.

Какое-то время спустя устаревший адрес превращается в недействительный (invalid), полностью исчезая с интерфейса; теперь незавершенные сеансы разрываются в аварийном порядке. В противоположность недействительному адресу, мы назовем адрес действительным (valid), пока он назначен интерфейсу. Предпочтительные и устаревшие адреса — действительные.

Осуществить подобную схему можно, связав с каждым адресом хоста два таймера, первый из которых отсчитывает предпочтительное время жизни адреса (preferred lifetime), а второй — действительное (valid lifetime). Предпочтительное время жизни не может превышать действительное, потому что недействительный адрес не может оставаться предпочтительным.

Чтобы реализациям IPv6 не пришлось делать большого различия между адресами, назначенными вручную и настроенными автоматически, пусть особое значение времени жизни означает бесконечность. Так как в объявлении RA время жизни будет представлено в виде двоичного беззнакового поля, пусть бесконечность обозначает максимальное значение этого поля, "все единицы". Тогда действительное и предпочтительное времена жизни смогут быть атрибутами всякого локального адреса, но некоторые адреса устаревать или исчезать никогда не будут.

Но даже адресам с конечным временем жизни не обязательно исчезать, пока их префикс анонсируется маршрутизатором. Как мы только что сказали, объявление RA вызывает перезапуск таймеров на соответствующих параметрах. Поэтому, например, если адресу оставалось жить 5 секунд, но пришло объявление RA, в котором время жизни соответствующего префикса 1 час, то таймер будет перезапущен с интервалом 1 час, и адрес в ближайшее время не исчезнет с интерфейса. Благодаря этому, объявления RA могут сколь угодно долго регенерировать автоматически назначенные адреса.

В результате жизненный цикл индивидуального адреса IPv6 выглядит, как показано на рис. 6.9. Состояния "недействительный" и "неназначенный" в нем — это, по сути, одно и то же. Можно для удобства полагать, что адрес переходит из первого во второе, когда его удаление с интерфейса полностью завершено: сеансы закрыты, структуры данных освобождены и проч.

Рис. 6.9. Жизненный цикл индивидуального адреса IPv6