Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1862 / 145 | Длительность: 24:05:00
Лекция 7:

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

Соберем воедино все наши замечания и оформим их как процедуру 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]. Так узел достовернее убедится, что опасности конфликта нет.

По умолчанию параметр DupAddrDetectTransmits равен единице [§5.1 RFC 4862], и повтора нет.

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

Тем не менее, администратор узла может избирательно заблокировать DAD на интерфейсе, установив параметр DupAddrDetectTransmits в ноль [§5.4 RFC 4862].

Обратите внимание: проверка DAD — только для индивидуальных адресов. В частности, DAD никогда не применяют к адресам anycast, потому что те по определению не уникальны [§5.4 RFC 4862]. Между тем, DAD вполне способен обнаружить и предотвратить случай, когда узел назначает своему интерфейсу некий адрес А как индивидуальный, хотя тот уже назначен другим интерфейсам канала как anycast. Ведь, как мы обсудили в §5.3, принадлежность внешне индивидуального адреса IPv6 к anycast — это локальное знание обладающего им узла. В случае назревающего конфликта узел, который назначает себе индивидуальный адрес, просто получит объявления NA с O = 0, а не 1. Условие надежной работы этого механизма таково: MAX_ANYCAST_DELAY_TIME RetransTimer. Обратная ситуация, когда адрес А уже назначен узлу Y как индивидуальный, а сосед X пытается назначить его себе как anycast, приведет к тому, что назначение anycast завершится успешно, но все пакеты от соседей в адрес А пойдут исключительно узлу Y. Самостоятельно обсудите, можно ли обнаружить эту ситуацию автоматически. (Указание: не забудьте о возможном присутствии на канале ND proxy.)

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

С другой стороны, на канале NBMA процедура DAD полноценно работать не сможет, потому что нет возможности обратиться ко всем узлам такого канала сразу. Это ограничивает применимость к NBMA протоколов, которые зависят от работоспособности DAD. Такие протоколы автоматически выбирают идентификатор интерфейса и потому вдвойне обязаны проверить его на возможный конфликт. К этой категории относятся SLAAC (§5.4.2), расширения для конфиденциальности (§6.2), CGA (§6.3) и HBA (§6.8). Мы познакомимся с ними ниже, а сейчас просто запомним эту особенность: если адрес составляет сам узел, то ему необходим работоспособный механизм DAD.

Пожалуй, единственный случай, в котором требование DAD можно ослабить, — это когда уникальность адресов обеспечивает другой протокол. Уже известный нам пример — это внутриканальные адреса на канале PPP. Они содержат заведомо уникальные идентификаторы интерфейсов, согласованные с помощью IPV6CP (§4.1.2), и поэтому применение к ним DAD избыточно [§5 RFC 5072]. Тем не менее, прочим индивидуальным адресам даже на интерфейсах PPP может потребоваться проверка DAD [там же].

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

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

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

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

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

Как мы уже упоминали в §5.4.1, вариант DHCP для IPv6 известен под именем DHCPv6 [RFC 3315].

Рассмотрим простейший случай, когда на канале есть всего один выделенный маршрутизатор, а остальные узлы (хосты) получают от него сведения о префиксах и выбирают его маршрутизатором по умолчанию. Благодаря 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.

Мы имеем в виду именно список разных индивидуальных адресов, а не один адрес anycast, за которым стоят несколько маршрутизаторов.

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

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

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

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

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

Случай, когда оба флага сброшены (A = 0 и L = 0), сейчас не имеет смысла, но он может пригодиться для расширения протокола, когда у префикса появятся новые свойства.

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

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

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

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.