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

Соберем воедино все наши замечания и оформим их как процедуру DAD, в ходе которой узел А проверяет пробный адрес П на интерфейсе И:

1. узел А вступает на интерфейсе И в следующие группы:

   а)

   "все узлы канала", FF02::1;

   б)

   группа искомого узла, отвечающая адресу П (группа Г);
2. узел А в фоне ожидает сообщений ND;
3. узел А направляет группе Г вызов DAD, то есть NS касательно адреса П с неопределенным адресом источника;
4. узлы, уже занявшие адрес П ,^{7 Их может быть несколько, если адрес П назначен им как anycast.} если таковые есть, отвечают на вызов DAD объявлениями NA (S = 0), направляя их группе "все узлы канала";
5. узел А отказывается назначить себе адрес П и ожидает ручного вмешательства оператора, если до истечения тайм-аута приходит хотя бы одно из таких сообщений ND: а)

   чужой вызов NS с неопределенного адреса касательно адреса П;

   б)

   объявление NA об адресе П;

6. DAD дает отрицательный результат, если истекает тайм-аут .^{8 Параметр RetransTimer, по умолчанию RETRANS_TIMER (1 с) [§6.3.2 RFC 4861].}

Поскольку сообщения ND могут теряться, а именно отсутствие сообщений означает отрицательный результат, процедуру DAD следует повторить несколько раз .^{9 Параметр DupAddrDetectTransmits, всего 1 раз [§5.1 RFC 4862].} Так узел достовернее убедится, что опасности конфликта нет.

Вооружившись такой процедурой DAD, мы можем проверять любые индивидуальные адреса IPv6, а не только составленные автоматически. Поэтому пусть узел IPv6 выполняет DAD перед назначением каждого индивидуального адреса независимо от того, настроен ли он вручную или получен автоматически [§5.4 RFC 4862]. Так DAD поможет выявлять ошибки в настройке сети и минимизировать ущерб от них.

Процедура DAD универсальна по отношению не только к адресам, но и к каналам. Ведь она основана на протоколе ND, а тот поддерживает все каналы с групповым вещанием, а не только широковещательные каналы, подобные Ethernet. Как следствие, и процедура DAD применима ко всем каналам этого типа без исключения. Это как раз тот случай, когда ND полезен даже на каналах "точка-точка".

Располагая DAD, узел IPv6 уже способен сам назначить внутриканальные адреса своим сетевым интерфейсам. Так узел может самостоятельно, без вмешательства оператора, выполнить то требование §2.5, что у каждого сетевого интерфейса IPv6 должен быть внутриканальный адрес [§2.1 RFC 4291]. Это важный шаг на пути к автоматической настройке адресов большей области, так как после него узел может свободно общаться со своими соседями.

Кроме того, внутриканальных адресов уже достаточно, чтобы смогла работать простейшая сеть без маршрутизаторов, такая как была показана на 2.2. То есть мы походя "создали" для IPv6 механизм, аналогичный динамической настройке адресов 169.254.0.0/16 в IPv4 [RFC 3927].

Розыск маршрутизаторов и префиксов

Теперь пришло время сделать то, что мы уже давно внесли в наш план, а именно обеспечить централизованное управление конфигурацией хостов IPv6 в пределах канала.

Первым шагом в этом направлении давайте поручим какому-то из узлов-соседей распространение информации о префиксах подсети, назначенных данному каналу. Этой информацией в любом случае должны располагать маршрутизаторы канала, поэтому они и будут идеальными кандидатами на роль ее распространителей, а дополнительные источники этой информации, такие как серверы DHCP, нам сейчас не понадобятся.

Рассмотрим простейший случай, когда на канале есть всего один выделенный маршрутизатор, а остальные узлы (хосты) получают от него сведения о префиксах и выбирают его маршрутизатором по умолчанию. Благодаря ND мы уже решили несколько важных задач, так что пусть распространение информации о префиксах будет очередным подмножеством ND [§6 RFC 4861]. Оформить его можно следующим образом:

• маршрутизатор время от времени рассылает группе "все узлы канала", FF02::1, особое сообщение ND, которое мы назовем объявление маршрутизатора, сокращенно RA (router advertisement);
• узел может запросить объявление RA, не дожидаясь периодической рассылки, с помощью другого сообщения ND, которое мы обозначим как вызов маршрутизатора, сокращенно RS (router solicitation); вызов RS логично направить группе "все маршрутизаторы канала", FF02::2.

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

В §5.2 мы запланировали, что список маршрутизаторов по умолчанию и список префиксов в хостах IPv6 тоже можно будет настраивать автоматически. Однако, пока еще не принято окончательных решений касательно протокола, нам следует осознать, что "самореклама" маршрутизаторов, объявление префиксов и автоматическая настройка адресов — это взаимосвязанные, но все же разные механизмы, основанные на протоколе ND. Поэтому нам не следует объединять их в один монолитный блок. Рассмотрим сейчас каждый механизм по отдельности.

Розыск маршрутизаторов (router discovery) — это интересная возможность, которая существовала, но так и не получила распространения в IPv4 [RFC 1256]. На практике есть два способа сообщить хосту IPv4 адрес маршрутизатора по умолчанию: или он указывается в административном порядке ,^{10 Возможно, централизованно на сервере DHCP или BOOTP.} или хост выбирает его, участвуя в протоколе маршрутизации, таком как RIP или OSPF. Если же мы желаем построить сеть с резервированием, когда маршрутизаторов по умолчанию несколько, то у нас остается только второй путь, а это означает лишние хлопоты по настройке и поддержке службы RIP или OSPF на каждом хосте.

Для IPv6 мы уже "создали" механизм на основе NUD, с помощью которого хост IPv6 может выбрать "живой" маршрутизатор из списка, не прибегая к другим протоколам кроме ND; это произошло в §5.2. Поэтому хост IPv6 вполне готов работать со списком маршрутизаторов по умолчанию вместо единственного адреса, как это было в IPv4.

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

Перейдем к следующему из намеченных нами механизмов, а именно к розыску префиксов (prefix discovery). Есть ли у него другие применения, кроме автоматической настройки адресов? Иными словами, какие еще префиксы могут быть интересны хосту? Конечно же, это префиксы "на канале". Ведь, как мы обсудили в §5.2, префикс подсети IPv6 не всегда автоматически находится "на канале", и наоборот, вполне возможны префиксы "на канале", не совпадающие с префиксом подсети. Мы даже отметили себе на будущее, что эти сведения могли бы распространять маршрутизаторы, если бы у нас был походящий механизм.

Сейчас мы как раз над ним работаем, и возможность сообщать узлам префиксы "на канале" возникает у нас естественным образом. Для этого будет достаточно, чтобы в объявлении RA каждый префикс сопровождали его атрибуты. В частности, префикс может обладать такими свойствами:

• быть пригодным для автоматической настройки адресов;
• находится "на канале";
• и то, и другое.

То есть (а) и (б) — это независимые свойства префикса, и потому каждое из них заслуживает отдельного флага длиной один бит. Обозначим флаг автоматической настройки как A, а флаг "на канале" как L.

Как и прочая информация в сообщениях RA, сведения о префиксах "на канале" вполне могут исходить от нескольких маршрутизаторов. Рассмотрим это на примере сценария, где канал обслуживают два маршрутизатора, и каждый из них отвечает за свой префикс "на канале", как показано на рис. 6.8. Теперь сведения о префиксах "на канале" полностью рассредоточены, так что маршрутизатор М больше не играет роль единственного координатора и не может выслать переадресовку, когда хост А вручает ему очередной пакет для хоста Б. Ведь информация, что 2001:DB8:777::/64 на канале, находится у маршрутизатора Н. В отсутствие объявлений RA, пакеты от А к Б пойдут окольным путем, посетят маршрутизаторы М и Н и даже проделают часть пути по Internet, хотя А и Б — соседи по каналу!

Рис. 6.8. Два маршрутизатора на канале, и у каждого своя подсеть