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

Наконец-то мы можем составить форматы сообщений RS и RA. Сообщение RS [§4.1 RFC 4861] — это просто вызов, так что главную информацию несет сам факт отправки и приема этого сообщения. Тем не менее, мы учтем полученный в §5.1 опыт с форматом NS и позволим сообщению RS содержать опцию ND "канальный адрес источника" (SLLA), как показано на рис. 6.10. Действительно, раз хост занялся розыском маршрутизаторов, то он наверняка собирается начать сетевой диалог. Поэтому маршрутизаторы смогут поступить предупредительно и заранее создать для этого хоста запись NC в состоянии ПРОСРОЧЕННАЯ, чтобы позднее не тратить времени на его розыск. А вдобавок, на такой вызов RS можно будет ответить индивидуальным, а не групповым объявлением RA, чтобы не тревожить понапрасну другие узлы канала.

Конечно, у опции "канальный адрес источника" есть смысл, только если адрес источника IPv6 определенный, потому как вносить в NC неопределенный адрес было бы эксцентричным поступком. По стандарту, RS допустимо слать с неопределенного адреса источника, ::, чтобы избежать "проблемы курицы и яйца" [§4.1 RFC 4861], хотя, как нам кажется, хосту ничто не мешает назначить себе внутриканальный адрес и слать RS с него. Точнее, если хост не способен по какой-то причине назначить себе уникальный внутриканальный адрес, то у него будут те же самые сложности и с назначением себе других адресов.

Рис. 6.10. Вызов маршрутизатора — RS

Формат RA более богат [§4.2 RFC 4861]. Прежде всего, мы решили, что в нем должно быть поле "время жизни маршрутизатора". Пусть нулевое значение этого поля означает, что данный маршрутизатор не хочет, чтобы хосты вносили его в свои списки маршрутизаторов по умолчанию; а если данный маршрутизатор уже в списке, то его следует оттуда удалить.

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

• предельное число шагов IPv6 (§3.2) — значение по умолчанию в создаваемых хостом пакетах, если иное не указано приложением посредством сетевого API;
• время доступности соседа (в миллисекундах) — параметр BaseReachableTime (§5.1): основа для вычисления случайного параметра ReachableTime (тайм-аут записи NC в состоянии ДОСТУПНАЯ);

• период повтора — параметр RetransTimer (§5.1): пауза между повторными вызовами NS, пока на них нет ответа NA.

  Если маршрутизатор не настаивает на определенном значении какого-то из параметров, то пусть он помещает в это поле ноль.

По-видимому, выбор пал на BaseReachableTime и RetransTimer, потому что именно эти параметры мы бы стали подстраивать, если бы, к примеру, нам пришлось оптимизировать работу канала на несколько тысяч хостов. В таком канале накладные расходы на NUD можно понизить, подняв BaseReachableTime, а задержку отклика на сообщения NS, вызванную их высокой частотой, можно компенсировать, увеличив RetransTimer.

В принципе, эти поля можно было вынести в опции ND, как мы поступим с полем "MTU канала".

Если у хоста несколько интерфейсов, то данные параметры относятся к тому интерфейсу, через который было получено объявление RA [§6.3.2 RFC 4861].

Еще в объявлении RA есть два флага, M и O, которые служат для того, чтобы отсылать хосты к протоколу DHCPv6 за настройками. Установленный флаг M говорит, что адрес IPv6 хост может получить по DHCPv6, а не настраивать автоматически, тогда как установленный флаг O означает, что из DHCPv6 доступны дополнительные настройки, такие как адреса серверов DNS, SIP и проч. Поскольку DHCPv6 возвращает хосту все настройки сразу, флаг O при установленном флаге M избыточен.

Рис. 6.11. Объявление маршрутизатора — RA

Это была фиксированная часть RA, постоянной длины, — показана на рис. 6.11. Но мы, вообще-то, начинали с того, что хотели распространять список префиксов. Длина этого списка, очевидно, переменная, так что давайте поместим этот список среди опций ND.

Можно поступить еще проще: пускай одна опция содержит один префикс, как показано на рис. 6.12. Она так и называется: опция сведений о префиксе (Prefix Information Option, PIO) [§4.6.2 RFC 4861]. Если префиксов несколько, то в хвосте сообщения RA появится несколько опций PIO.

Рис. 6.12. Опция сведений о префиксе — PIO

По нашему плану, атрибутами каждого префикса будут его длина, действительное и предпочтительное времена жизни, а также флаги A и L, говорящие, в каких целях хостам можно использовать данный префикс: для автоматической настройки адресов, для ведения списка префиксов "на канале".

А если маршрутизатор заодно сообщит свой канальный адрес в опции "канальный адрес источника" (SLLA), то хостам не придется дополнительно разрешать его сетевой адрес — они сразу же смогут создать запись NC, хотя бы в состоянии ПРОСРОЧЕННАЯ. Так маршрутизатор "убьет нескольких зайцев" одним объявлением RA.

Еще одна опция ND, специфичная для сообщения RA — это "MTU канала" [§4.6.4 RFC 4861]. Она призвана помочь работе IPv6 поверх каналов с переменным значением MTU. Формат этой опции показан на рис. 6.13.

Рис. 6.13. Опция "MTU канала"

С какого адреса источника маршрутизатор должен вести рассылку RA? Ведь именно этот адрес хосты сохранят в своих списках маршрутизаторов по умолчанию, если "время жизни маршрутизатора" в объявлении RA больше нуля. Логично было бы использовать тот адрес, вероятность смены которого минимальна. Этим свойством обладает внутриканальный адрес, так как он не зависит от адресного плана сети, текущего провайдера Internet и проч. Поэтому маршрутизатор обязан рассылать RA с внутриканального адреса [§4.2 RFC 4861].

Распространение параметров IPv6 и ND в сообщениях RA влечет за собой еще одну проблему. Если канал обслуживают несколько маршрутизаторов, то вполне может оказаться, что по недосмотру они объявляют разные значения параметров. В этом случае объявления RA от разных маршрутизаторов будут непрерывно менять соответствующие настройки хостов, а флуктуации настроек чреваты нестабильностью в работе протоколов. По этой причине необходимо, чтобы все маршрутизаторы канала объявляли согласованные наборы параметров. В первую очередь, это касается численных параметров в фиксированной части RA, а также опции "MTU канала": их значения обязаны совпадать.

Разные маршрутизаторы вполне могут объявлять разные списки префиксов, но и здесь необходимо определенное единообразие. А именно времена жизни одного и того же префикса, объявляемого разными маршрутизаторами, должны совпадать, чтобы не было нежелательных флуктуаций в настройках хостов. В то же время, флаги префиксов вполне могут отличаться, потому что их можно объединить операцией "побитовое ИЛИ". К примеру, если префикс 2001:DB8:0:123::/64 объявлен одним маршрутизатором как доступный для автоматической настройки адресов (A = 1), а другим — как расположенный "на канале" (L = 1), то хосты вправе как внести его в свои списки префиксов, так и назначить себе адреса на его основе.