Настройка сетевых адресов в IPv6

Настройку сетевых адресов можно сравнить с настройкой адресов и редактированием внешних связей в объектных файлах. Компилятор старается генерировать позиционно-независимый код, возлагая на редактор внешних связей настройку глобальных ссылок. В IPv6 предусмотрены определенные средства для "топологически-независимой" адресации (адреса, локальные в пределах подсети или организации, затребованные групповые адреса, получаемые отображением младшей части индивидуальных, и т.п.). Там же, где требуется глобальный адрес, необходимо либо соединить идентификатор сетевого интерфейса с топологическими префиксами, почерпнутыми из окружения, либо получить адрес "в готовом виде" от некоторого сервиса. Отметим, что без эффективных, автоматизированных средств настройки иерархическая организация адресов и связанные с ней методы маршрутизации практически перестают работать в силу чрезмерной сложности администрирования. Никто вручную не настраивает внешние ссылки в новых объектных файлах и не перенастраивает их после очередной компиляции.

Проблема настройки адресов распадается на две подпроблемы:

• начальная настройка (при включении в сеть нового узла);
• перенумерация (при внесении изменений в сеть).

В данном разделе мы уделим основное внимание методам автоматической начальной настройки (автоконфигурирования) адресов узлов. Эти методы можно применить и при перенумерации, если узел в начале работы динамически формирует свой адрес.

Автоконфигурирование может производиться двумя способами:

• без учета контекста (stateless), когда узел самостоятельно формирует свой адрес "с нуля";
• с учетом контекста (stateful), когда узел получает адрес от какого-либо сервиса, располагающего предварительно заданной информацией.

Бесконтекстное автоконфигурирование адресов

Идея бесконтекстного автоконфигурирования адресов, описываемого спецификациями [19], состоит в том, чтобы получить глобальный адрес путем объединения локальной составляющей (обычно это идентификатор сетевого интерфейса) и префикса подсети, известного маршрутизаторам (в IPv6 маршрутизаторы являются важным звеном автоматизации административных действий).

При автоконфигурировании адресов выполняется следующая последовательность действий:

• генерируется адрес, локальный для подсети;
• определяется уникальность этого адреса в пределах подсети;
• определяется способ автоконфигурирования;
• выясняются префиксы подсети;
• генерируется глобальный IP-адрес сетевого интерфейса.

Адрес, локальный для подсети, генерируется при активации (включении) сетевого интерфейса. Этот адрес, называемый на данном этапе пробным, формируется путем добавления шестнадцатеричного префикса FE8 (см. Рис. 10) к идентификатору интерфейса.

Прежде чем использовать пробный адрес, необходимо убедиться в отсутствии дублирования, то есть в уникальности пробного адреса в пределах подсети. Процедура выявления дублирования адресов является частью протокола выяснения смежности (Neighbor Discovery, ND, см. [20]). В ней используется затребованный групповой адрес, соответствующий пробному. Если никто посторонний не откликнулся на запрос с данным адресом, значит, пробный адрес можно переводить в разряд легальных. При обнаружении дублирования требуется ручное вмешательство в процесс конфигурирования.

Сформировав корректный IP-адрес, локальный в пределах подсети, узел достигает промежуточной цели, получая возможность общаться со смежными узлами и, в частности, с маршрутизаторами (если таковые имеются). Отметим, что наличие в IPv6 локальных и групповых адресов позволяет проводить автоконфигурирование исключительно IP-средствами, без привлечения протоколов типа ARP.

Чтобы определить способ конфигурирования (контекстное/бесконтекстное) и выполнить последующие действия, узлу необходимо затребовать информацию у маршрутизатора. В принципе, маршрутизаторы периодически рассылают так называемые афиширующие сообщения, содержащие конфигурационные данные; если узел не хочет ждать, он может послать требование к маршрутизаторам и получить быстрый ответ.

Формат афиширующих сообщений, также входящих в протокол выяснения смежности, заслуживает детального рассмотрения. Этот формат приведен на Рис. 14. При установленных флагах M и O должно применяться контекстное конфигурирование адресов и прочих сетевых параметров. В противном случае выполняется только бесконтекстное конфигурирование. Значения флагов определяет сетевой администратор.

Из других полей упомянем Cur Hop Limit — подразумеваемое значение, которое узлы должны помещать в поле Hop Limit исходящих IP-пакетов. Cur Hop Limit дает нам пример автоконфигурирования неадресной информации. Еще одно поле аналогичного плана — Router Lifetime, задающее время (в секундах), в течение которого данный маршрутизатор целесообразно использовать в качестве подразумеваемого.

Основная информация афишируется посредством поля Options. В частности, именно туда помещаются префиксы подсети, необходимые для автоконфигурирования адресов. Способ представления префиксной информации показан на Рис. 15.

При установленных флагах L и A префикс может использоваться в процедуре автоконфигурирования в качестве начала глобального IP-адреса. Поле Valid Lifetime задает срок годности префикса (в секундах). Поле Preferred Lifetime определяет, как долго данный префикс является предпочтительным. Задание и учет подобных временных рамок - основа механизмов постепенного изменения топологии сети без нарушения ее работоспособности. Адреса (префиксы) с малым временем жизни являются нежелательными (см. Разд. Адресация в IPv6 ), новые соединения с такими адресами открывать не рекомендуется. Когда срок годности истекает, адрес становится некорректным.

Объединив префикс подсети и идентификатор интерфейса, узел получает глобальный IP-адрес, годный для Интернет-коммуникаций.

Контекстное автоконфигурирование адресов

Контекстное автоконфигурирование адресов реализуется на основе протокола динамического конфигурирования хостов (Dynamic Host Configuration Protocol, DHCPv6 или просто DHCP, см. [21]). Оно позволяет осуществлять распределение пула IP-адресов между множеством узлов с поочередным использованием одного адреса несколькими узлами.

Протокол DHCP построен в модели клиент/сервер. Он состоит из двух логических частей. Одна описывает доставку конфигурационных параметров от DHCP-сервера клиенту, другая - выделение узлам IPv6 адресов и ассоциированных ресурсов.

Взаимодействие между клиентом и сервером строится по схеме запрос/ответ. Из практических соображений нецелесообразно размещать в каждой подсети DHCP-сервер, поэтому вводится промежуточное звено — DHCP-ретранслятор, обслуживающий клиентов, неспособных напрямую обратиться к серверу (см. Рис. 16). Серверы и ретрансляторы называются агентами; с ними и взаимодействуют клиенты.

Прежде чем приступить к контекстному конфигурированию своего сетевого интерфейса, клиент, как и в бесконтекстном случае (см. Разд. Бесконтекстное автоконфигурирование адресов ), должен сгенерировать уникальный адрес, локальный в пределах подсети, и получить от маршрутизатора афиширующее сообщение с установленным флагом M (см. Рис. 14). Затем клиент должен узнать IP-адрес DHCP-агента. Для этого он посылает DHCP-требование по групповому адресу FF02:0:0:0:0:0:1:2 (всем агентам данной подсети), получая в ответ (на адрес, локальный в пределах подсети) афиширующее сообщение с необходимым адресом агента и, быть может, сервера. Располагая адресом DHCP-агента, клиент направляет ему запросы на получение (а в последующем и на освобождение) IP-адреса и других необходимых ресурсов. Сервер поддерживает базу данных выделенных ресурсов и посылают ответы на запросы. Кроме того, посредством особого вида сообщений серверы могут проинформировать клиентов об изменении конфигурации и о необходимости запросить новые значения изменившихся параметров.

Мы видим, что и здесь изначально заложенные в IPv6 возможности, такие как наличие адресов, локальных в пределах подсети, которыми узел может пользоваться сразу после включения или перезагрузки, позволяют естественным образом организовать взаимодействие с DCHP-сервером. (DCHP-сообщения представляют собой UDP-датаграммы, направляемые в порты с номерами 546/547.) Заранее распределенные групповые адреса (с соответствующей областью действия) также оказываются весьма полезными, устраняя необходимость широковещательных запросов.

Поддержка мобильности узлов в IPv6

Несомненно, в период действия спецификаций IPv6 значительная часть сетевых систем будут мобильными. Такие системы время от времени перемещаются за пределы корпоративной сети, подключаясь к Интернет по существу в произвольных местах. То есть в принципе они почти всегда доступны, но их текущий IP-адрес нередко меняется.

В проекте [22] сделана попытка модифицировать IP-уровень таким образом, чтобы для более высоких уровней протокольного стека TCP/IP перемещения мобильных систем оставались незаметными.

Выделяются три группы новых понятий:

• домашняя (основная) сеть и домашний IP-адрес мобильной системы;
• текущая сеть и текущий IP-адрес мобильной системы;
• домашний агент, замещающий мобильную систему в домашней сети на время путешествий и переправляющий по текущему адресу предназначенные для нее IP-пакеты.

Когда мобильная система подключается к сети, она обычным образом выполняет автоконфигурирование адресов, одновременно выясняя, находится ли она дома или в "чужой" сети. В последнем случае домашнему агенту (маршрутизатору, входящему в домашнюю сеть) направляется регистрационное сообщение, содержащее домашний и текущий адреса мобильной системы. После выполнения регистрации агент берет на себя функции представления системы в домашней сети с точки зрения протокола выяснения смежности (в частности, он отражает попытки дублирования домашнего IP-адреса), а, главное, он перехватывает IP-пакеты, направленные мобильной системе по домашнему адресу, и пересылает их по адресу текущему. Возникающие при этом потоки данных показаны на Рис. 17.

Такая схема работоспособна в принципе, но масштабируемой она не является. При большом числе мобильных систем и интенсивных потоках данных домашние агенты (в роли которых, напомним, выступают маршрутизаторы), рискуют захлебнуться. Чтобы этого не произошло, мобильная система, получив первые (переправленные агентом) пакеты от некоего удаленного узла, посылает и на данный удаленный узел свои домашний и текущий адреса. IP-уровень удаленного узла должен поместить полученную пару адресов в кэш и в последующих пакетах подставлять текущий адрес вместо домашнего. Трафик потечет напрямую, без вмешательства домашнего агента (см. Рис. 18), а платой за это будет просмотр кэша на каждый исходящий пакет. Можно провести аналогию между поддержкой мобильности узлов сети и механизмами виртуальной памяти. В обоих случаях видимые, логические адреса объектов остаются постоянными, в то время как их физическое расположение может изменяться. Кэширование позволяет эффективно преобразовывать логические адреса в физические.

С точки зрения реализации все сообщения, обеспечивающие поддержку мобильности, оформляются в виде дополнительных заголовков IPv6, обрабатываемых оконечными системами (см. Разд. Порядок заголовков ). Спецификации [22] вводят ряд новых заголовков, которые могут помещаться либо в пакеты с полезной TCP- или UDP-нагрузкой, либо входить в отдельные пакеты с нулевой длиной содержимого. В любом случае после обработки пакетов IP-уровнем мобильной или удаленной системы они выглядят так, как если бы взаимодействие происходило посредством домашнего адреса. Следовательно, для более высоких протокольных уровней перемещения мобильной системы остаются незаметными, а плата за это представляется вполне приемлемой.

На самом деле в механизмах поддержки мобильности имеется целый ряд тонкостей, на которых мы, однако, останавливаться не будем. Отметим лишь, что в [22] предусмотрена перенумерация домашней сети, когда меняется адрес домашнего агента. Если это произойдет, мобильной системе придется послать запрос по anycast-адресу "наиболее подходящего домашнего агента в сети", в ответ на который она получит обычный индивидуальный адрес агента. Таким образом, перспективное понятие anycast-адреса находит все более широкое применение.

Перенумерация маршрутизаторов

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

Основная идея спецификаций [23], описывающих средства для перенумерации маршрутизаторов, довольна проста. В ICMP-пакетах маршрутизаторам передаются команды управления префиксами, состоящие из трех компонентов:

• операция;
• сопоставляемый префикс;
• используемые префиксы.

Если сопоставляемый префикс входит в адрес какого-либо сетевого интерфейса маршрутизатора, к адресу применяется заданная операция с операндами — используемыми префиксами. Возможных операций три:

• добавить (с интерфейсом ассоциируются дополнительные префиксы);
• заменить (сопоставленные префиксы удаляются, новые устанавливаются);
• установить глобальные (заменяются все префиксы с глобальной областью действия).

Формат команд управления достаточно развит, чтобы обеспечить не только замену, но и вставку частей старых (сопоставленных) префиксов в новые. Новые префиксы снабжаются сроками годности и предпочтительности (см. Рис. 15), позволяющими маршрутизаторам управлять автоконфигурированием адресов. Очевидно, возможностей такого рода достаточно, чтобы обеспечить плавный переход на новые сетевые адреса. Для этой цели можно, например, снабдить старые префиксы небольшим сроком годности и еще меньшим сроком предпочтительности, добавив одновременно новые префиксы с неограниченными сроками годности и предпочтительности.

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