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

Чтобы помочь администратору в согласовании параметров, каждому маршрутизатору рекомендовано следить за объявлениями соседей, сравнивать их со своими и сообщать в системном журнале о найденных противоречиях [§6.2.7 RFC 4861].

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

Между тем, один префикс может включать в себя другой. Например, двоичный префикс 01 содержится в префиксе 0100, а префикс IPv6 2001:DB8::/32 — в префиксе 2001:DB8::/48. При этом префикс большей длины точнее, так как ему отвечает меньшее множество адресов. Когда такие префиксы находятся на одном канале, это тривиальный случай: множество адресов короткого префикса полностью содержит в себе множество адресов длинного префикса. Тем не менее, это разные префиксы, у каждого из которых свой набор флагов и свое время жизни. Например, префикс "на канале" 2001:DB8::/32 может устареть раньше, чем 2001:DB8::/48, и тогда адреса, составляющие разность этих множеств, окажутся "вне канала".

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

Маршрутизатору не возбраняется всегда направлять объявления RA по адресу "все узлы канала" независимо от того, шлет ли он это объявление по таймеру или по вызову [§6.2.6 RFC 4861, §5.5.1 RFC 4862]. Так злоумышленник или даже просто сбойный хост сможет вызвать целую бурю группового трафика. Чтобы этого не произошло, каждый маршрутизатор обязан ограничить частоту своих объявлений RA^{12 Параметр MIN_DELAY_BETWEEN_RAS, 3 с [§6.2.6 RFC 4861].} .

Тем не менее, проблема нежелательной синхронизации RA остается. С ней надо бороться, сделав время отправки RA случайным. Если RA по вызову, то надо внести случайную задержку, а если по таймеру, то достаточно сделать его интервал случайным [§6.2.4 и §6.2.6 RFC 4861]. Последний штрих состоит в том, чтобы вообще не слать RA по вызову, если задержка помещает его на оси времени после ближайшего RA по таймеру. Благодаря этим предосторожностям, групповая рассылка объявлений RA не повредит каналу даже при возникновении сбойных или злонамеренных хостов.

Последний вопрос, связанный с розыском маршрутизаторов, заключается в том, может ли узел IPv6 впоследствии отказаться от роли маршрутизатора. Согласно общепринятой модели [§6.2.1 RFC 4861], маршрутизатор IPv6 — это функция узла, которую можно избирательно включить или выключить на каждом из его сетевых интерфейсов, при условии что узел вообще способен быть маршрутизатором. Из соображений устойчивости и безопасности, по умолчанию эта функция выключена.

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

С явной информацией все довольно просто: достаточно разослать несколько раз объявление RA, в котором список параметров все тот же, но время их жизни нулевое. Так узел М заставит хосты удалить информацию о префиксах и исключить себя из списка маршрутизаторов по умолчанию.

Однако в памяти хостов все еще остаются записи DC, которые указывают на узел М. Подобные записи могли возникнуть, даже если М не был маршрутизатором по умолчанию, а значит, их нельзя убрать объявлением RA. Например, эти записи могли быть созданы по переадресовке другого маршрутизатора Н. В результате окажется, что хосты продолжают слать транзитный трафик через узел М, хотя тот его просто игнорирует. Если бы узел М вообще исчез, то сработал бы механизм NUD, и хосты бы вычистили устаревшие записи DC, связанные с недоступным соседом. Но в нашем случае узел М будет по-прежнему доступен, и образуется "черная дыра".

Чтобы разрешить это затруднение, нам пригодится флаг R в объявлении NA, который мы предварительно зарезервировали. Пусть узел устанавливает этот флаг в своих сообщениях NA, когда он маршрутизатор на данном интерфейсе, и сбрасывает, когда он просто хост. Тогда хосты-соседи смогут более надежно узнать об отказе узла М продвигать транзитный трафик. Как только флаг R в его сообщениях NA обнулится, полагается вычистить все записи DC, указывающие на узел М, потому что он добровольно сложил с себя полномочия маршрутизатора [§7.2.5 RFC 4861].

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

1. преобразует канальный адрес интерфейса в идентификатор интерфейса IPv6 длины N;

   Еще раз напомним себе, что N = 64 — это чисто административное решение, которое не следует "зашивать" в протоколы стека IPv6. Строго говоря, хост не обязан использовать канальный адрес интерфейса при выборе его идентификатора IPv6 [Приложение A RFC 4291], однако это повсеместная практика, если канальный адрес у интерфейса имеется.
2. создает пробный внутриканальный адрес IPv6, сцепляя префикс FE80::/(128-N) и идентификатор интерфейса, полученный на шаге №1;
3. проверяет пробный внутриканальный адрес на уникальность с помощью DAD;
4. если адрес уникальный, назначает его интерфейсу и устанавливает для него бесконечные времена жизни. В противном случае работа IPv6 через данный интерфейс невозможна и происходит останов процедуры [§5.4.5 RFC 4862];
5. возможно, посылает вызов RS группе "все маршрутизаторы канала", FF02::2;

6. по мере получения объявлений RA сканирует опции PIO [§5.5.3 RFC 4862]:

   а)

   игнорирует опцию, если в ней сброшен флаг A;

   Опция PIO с A = 0 может пригодиться для заполнения списка префиксов "на канале", если у нее L = 1; но мы сейчас говорим только об автоматическом назначении адресов сетевому интерфейсу.
   б)

   игнорирует опцию, если префикс внутриканальный;

   в)

   игнорирует опцию, если действительное время жизни префикса меньше предпочтительного;

   г)

   если префикс еще не назначен:

   i)

   игнорирует префикс, если сумма длин префикса и идентификатора интерфейса не равна длине адреса IPv6, 128 бит;

   ii)

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

   iii)

   создает пробный адрес, сцепляя префикс из RA и идентификатор интерфейса из шага №1;

   iv)

   проверяет пробный адрес на уникальность с помощью DAD;

   v)

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

   д)

   иначе, если префикс уже назначен в составе ранее созданного адреса:

   i)

   устанавливает предпочтительное время жизни адреса согласно опции;

   ii)

   устанавливает действительное время жизни на основании опции (см. примечание).

Хотя вопрос о безопасности ND мы еще не обсуждали, уже сейчас понятно, что без дополнительных механизмов защиты сообщения ND уязвимы к обычной подделке. Подделка RA, помимо прочего, позволяет провести очень простую атаку типа "отказ в обслуживании", когда хост получает RA, в котором действительное время жизни его текущих префиксов очень короткое. В результате хост сбрасывает свои адреса и некоторое время остается полностью недоступен. Обратите внимание, что хост не нужно "бомбардировать" — достаточно единственного фальшивого RA. Чтобы блокировать этот вектор атаки, стоит ограничить возможность RA сокращать действительное время жизни адресов [§5.5.3 RFC 4862]. Суть этого ограничения довольно проста, ее иллюстрирует рис. 6.14. Прежде всего, RA может беспрепятственно удлинять время жизни адреса. Например, если к приходу RA адресу оставалось жить 5 минут, а новое время жизни 10 минут, то таймер адреса будет установлен на 10 минут. Если же RA на самом деле пытается сократить время жизни адреса, то оно может укоротить его только до 2 часов. К примеру, если адресу оставалось жить 1 час, а новое время жизни 10 минут, то адрес проживет целый час. Если адресу оставалось жить 3 часа, а новое время жизни 45 минут, то адрес проживет 2 часа. И только если новое время жизни больше 2 часов, оно вступит в силу как есть. Когда у нас появится надежная защита сообщений RA от подделки, это ограничение можно будет снять. Иными словами, ограничение действует только на те сообщения RA, подлинность которых никак не подтверждена. Кроме того, оно действует только на действительное время жизни как наиболее уязвимый параметр, тогда как предпочтительным временем жизни адресов можно управлять без ограничений.

Рис. 6.14. Защита от атаки на время жизни адреса

Хост выполняет шаг 6 в фоне, пока интерфейс активен, так как периодические объявления RA сообщают текущую конфигурацию данного канала, а она может изменяться по желанию администратора сети. Маршрутизатор может сам назначить своим интерфейсам внутриканальные адреса, выполнив шаги 1–4; шаги 5 и далее — только для хостов [§4 RFC 4862].

У такого механизма автоматической настройки адресов есть одна любопытная особенность: ни маршрутизатор, ни хост не фиксируют назначение адреса в долговременной памяти. Когда хост включают, он проводит процедуру автоматической настройки с самого начала и, как нетрудно убедиться, получает тот же самый набор адресов, пока постоянны его канальный адрес и конфигурация маршрутизаторов. Можно сказать, что у такого механизма нет внутреннего состояния. Поэтому полностью его называют так: автоматическая настройка адресов без внутреннего состояния, сокращенно SLAAC (stateless address autoconfiguration) [RFC 4862].

Важное условие работы SLAAC — чтобы канал поддерживал групповое вещание на сетевом уровне. Если это не так, то и SLAAC на таком канале работать не сможет.

Как и всякий сложный автоматический механизм, SLAAC должен быть, в идеале, полностью управляемым, а по меньшей мере — отключаемым. У оператора узла должна быть возможность блокировать работу SLAAC на сетевом интерфейсе, если она нежелательна по тем или иным соображениям. Это касается как хостов, так и маршрутизаторов. Хост должен быть готов работать с ручными настройками, игнорируя объявления RA. Что же касается маршрутизатора, то рассылка RA может повлиять на конфигурацию многих хостов, и поэтому ее надо вообще отключить по умолчанию^{14 Параметр AdvSendAdvertisements, по умолчанию FALSE [§6.2.1 RFC 4861].} [ ] и включать явным образом только при необходимости и только после надлежащей настройки всех параметров объявления RA.