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

Пересмотр типов вещания IPv6. Вещание наугад — anycast

Поработав над розыском соседей, мы можем пересмотреть типы вещания в IPv6. Прежде всего, что произошло с широковещанием? До сих пор мы старательно избегали этой темы. Однако теперь мы убедились, что необходимость в широковещании полностью отпала благодаря обязательной поддержке группового вещания. Широковещание IPv4 опиралось на широковещание канального уровня, а с ним мы активно боремся, чтобы не расходовать впустую ресурсы сети. Обратиться же ко всем узлам IPv6 в определенной зоне всегда можно с помощью общепринятой группы "все узлы" (FF0x::1). Итак, в IPv6 нет широковещания; его функции выполняет групповое вещание.

А когда нет широковещания, то не нужны и особые широковещательные адреса. В частности, идентификатор интерфейса FFFF:FFFF:FFFF:FFFF (все биты установлены) никоим образом не зарезервирован.

Групповое вещание полезно для протоколов не только служебных, но и прикладных. Оно выручает в тех случаях, когда один пакет надо с минимальными затратами разослать нескольким узлам. Например, сервер NTP может передавать "сигналы точного времени" сразу группе клиентов; клиент DHCP может обратиться одним запросом к группе серверов и получить несколько предложений, а затем выбрать среди них наиболее подходящее.

Однако возникают похожие задачи, которые групповое вещание решить не может. К примеру, нет смысла создавать в организации группу серверов DNS хотя бы потому, что протокол DNS рассчитан на индивидуальное вещание и клиенту не будет никакой выгоды от нескольких ответов.

Также групповое вещание совершенно бессильно в протоколах, работающих поверх TCP. Тем не менее, сама концепция сетевой группы, когда за одним адресом стоят несколько узлов (точнее, интерфейсов), сохраняет свое значение и в этом случае. Скажем, в крупной организации можно было бы назначить всем серверам DNS или SMTP один "волшебный" адрес X, так чтобы клиент, независимо от местоположения в сети и не меняя настроек, всегда обращался бы к ближайшему серверу (см. рис. 6.1). С точки зрения источника пакета, это будет вещание наугад (anycast), по принципу "кому попало".

Рис. 6.1. Идея anycast для DNS

Тем не менее, роль случайности в этом типе вещания не так велика, как кажется источнику. Для простых протоколов, где весь сеанс состоит из обмена парой пакетов UDP по схеме "запрос-ответ", действительно неважно, в какой именно узел anycast попадет запрос. Между тем, TCP не играет в кости: для его работы надо, чтобы пакеты данного соединения попадали в один и тот же узел anycast хотя бы при условии постоянной конфигурации сети. Получается оксюморон: вещание наугад должно быть воспроизводимым (см. рис. 6.2).

Рис. 6.2. Anycast должен быть воспроизводимым

Как нам выполнить это противоречивое условие? Давайте попробуем свести задачу к двум крайним случаям. В первом из них источник и узлы anycast будут разбросаны по сети, так что они не окажутся соседями друг друга. Во втором же случае источник и все узлы anycast будут соседями по каналу.

В первом случае задачу можно решить обычной настройкой маршрутов в сети. Для простоты положим, что источник — это хост, у которого есть только маршрутизатор по умолчанию. По условию задачи, источник — не сосед ни одному из узлов anycast, а значит, первым шагом пакет попадет на маршрутизатор по умолчанию. Если у того будет маршрут для адреса anycast X в сторону ближайшего узла anycast N, то следующим шагом пакет достигнет его или хотя бы приблизится к нему и т.д. То есть достаточно выстроить на маршрутизаторах цепочку маршрутов, которая приведет пакет к ближайшему узлу anycast, как показано на рис. 6.3. Принципиально это ничем не отличается от процесса маршрутизации в сложной сети, где к данному адресату можно проложить более одного пути и потому пакеты от разных источников ходят к нему через совершенно разные участки сети. Следовательно, и осуществить такую схему можно теми же инструментами: статическими маршрутами или протоколом динамической маршрутизации.

Рис. 6.3. Трасса к адресу anycast

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

Согласно первому из них, маршрутизатор должен полагать, что адрес X — "на канале". Как сообщить эту информацию маршрутизатору, зависит от реализации. К примеру, можно назначить каналу между маршрутизатором и узлом anycast префикс X/64. Так или иначе, маршрутизатор проведет розыск адреса X, а узел anycast откликнется и получит пакет.

Второй подход состоит в том, чтобы каждому узлу anycast J назначить, помимо адреса X, обычный индивидуальный адрес . Тогда в таблице маршрутов последнего маршрутизатора достаточно будет создать маршрут , и по нему пакет достигнет узла anycast N. В этой схеме адрес вполне может быть внутриканальным, а хотя бы один такой адрес — это обязательный атрибут всякого интерфейса IPv6 (см. §2.5); так что назначать дополнительные адреса только ради работы anycast не придется. Сам же адрес можно назначить любому сетевому интерфейсу узла, включая "петлю", как это показано на рис. 6.4.

Рис. 6.4. Последний шаг к адресу anycast