DHCPv6

Несмотря на то, что IPv6 поддерживает автоматическую конфигурацию адресов (что и было одной из основных мотиваций создания DHCP для IPv4), использование DHCPv6^[1] даёт сетевому администратору больший контроль над назначениями адресов и позволяет конфигурировать более широкий набор параметров сетевых сервисов.

DHCPv6 может работать совместно с механизмом «stateless» (без сохранения состояния). Выбор способов конфигурирования определяется администратором сети посредством рассылки RA-сообщений (Router Advertisement) в сети IPv6. Также DHCPv6 позволяет клиентам запрашивать несколько IPv6-адресов, чего не было возможно реализовать в IPv4 и с помощью механизмов stateless-автонастройки.

Работа протокола осуществляется поверх транспорта UDP: клиент использует адрес link-local или определённый другими способами для передачи и получения DHCPv6-сообщений.

Серверы DHCPv6 слушают мультикаст-адрес, выделенный специально для обмена с клиентами. Клиенты в большинстве случаев отправляют свои сообщения на этот адрес, что избавляет их от необходимости знать уникальный (unicast) адрес DHCPv6-сервера заранее.

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

Как только клиент определяет адрес сервера, он может при определённых условиях отправлять ему сообщения напрямую, используя unicast-адрес.

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

• All_DHCP_Relay_Agents_and_Servers (FF02::1:2). — адрес link-local multicast, используемый клиентами для взаимодействия с агентами ретрансляции и соседними серверами. Все серверы и агенты ретрансляции входят в данную группу multicast.
• All_DHCP_servers (FF05::1:3). — адрес site-local multicast, используемый агентами ретрансляции для связи со всеми серверами на сайте или при отсутствии знаний об их unicast-адресах.

• Клиенты используют порт 546 UDP
• Серверы и ретрансляторы — порт 547 UDP

В таблице указаны основные типы DHCPv6-сообщений и их задачи:

Все сообщения DHCPv6 между клиентом и сервером имеют фиксированный формат заголовка и переменную область опций. Опции следуют друг за другом без заполнителей. Сообщение содержит следующие поля:

• Тип сообщения — определяет тип DHCP-сообщения.
• Идентификатор транзакции — уникальный номер обмена сообщениями.
• Опции — переменное содержимое.

Формат сообщения DHCPv6 между клиентом и сервером

Ретрансляторы пересылают сообщения между серверами и клиентами, находящимися вне одного сетевого сегмента.

Существуют два типа сообщений агента ретрансляции, но оба имеют идентичный формат:

• Тип сообщения. RELAY-FORW или RELAY-REPL
• Link-address. Глобальный или site-local адрес, используемый сервером для идентификации сегмента, с которого пришло сообщение от клиента.
• Peer-address. Адрес клиента или ретранслятора, от которого принято сообщение.
• Опции. Обязательно содержит Relay Message Options (опция вложенного сообщения); могут присутствовать и другие опции.

Каждый клиент и сервер DHCPv6 имеет уникальный идентификатор DUID. Серверы используют DUID для идентификации клиентов при подборе параметров конфигурации и для сопоставления IAs с клиентами. Клиенты используют DUID для идентификации сервера в сообщениям, требующих его уникального определения.

DUID рассматривается обеими сторонами как непрозрачное значение; его используют только для сравнения на равенство и не интерпретируют содержательно. DUID передаётся в поле опций (variable length) только когда это необходимо.

DUID состоит из двух октетов, указывающих тип, и произвольного (но ≤128 байт) последовательного содержимого.

Ассоциация идентификации (IA, англ. Identity Association) — структура, с помощью которой сервер и клиент группируют и управляют рядом связанных IPv6-адресов. Каждая IA состоит из уникального IAID и связанных данных конфигурации.

Клиент обязан создать отдельную IA на каждую сетевую интерфейсную карточку, для которой он запрашивает адреса через сервер DHCPv6. Каждая IA привязана к своей единственной интерфейсной карточке.

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

Сервер определяет назначаемые IA-адреса на основании:

• информации о сегменте сети (определяется по адресу источника или по полю link-address в сообщениях ретранслятора);
• DUID, предоставленного клиентом;
• других параметров, сообщённых клиентом или ретранслятором через опции.

Клиент может запросить временные адреса (RFC 3041). Для DHCPv6 обработка таких адресов ничем не отличается: временные адреса инкапсулируются в опцию IA_TA. На каждый префикс в сегменте выделяется не более одного временного адреса.

Клиент формирует IAs и запрашивает для них адреса у сервера, сначала создавая IA и присваивая ей IAID. Далее он отправляет SOLICIT с соответствующей опцией IA.

Сообщение SOLICIT инициирует поиск серверов DGCPv6. Первая передача SOLICIT на интерфейсе задерживается случайным образом (0 — SOL_MAX_RT). Сервер отвечает ADVERTISE, подтверждая готовность.

Сервер может включить в ADVERTISE опцию предпочтения; по умолчанию значение — 0. Клиент анализирует все полученные ADVERTISE — выбирает наиболее предпочтительный (затем повторяет REQUEST на него).

Если SOLICIT содержит опции IA, сервер добавляет соответствующую информацию по ним в ADVERTISE. Если ни одна IA не может быть обслужена, сервер возвращает ADVERTISE только с кодом статуса NoAddrsAvail — такой ответ игнорируется клиентом. Ответ ADVERTISE всегда передаётся в unicast на интерфейсе получения SOLICIT.

Клиент собирает все ADVERTISE в течение RT секунд либо сразу переходит к REQUEST, если получен ADVERTISE с preference=255. Если не получено ни одного ответа — повторяет цикл.

Если в SOLICIT клиент указал Rapid Commit, сервер ответит REPLY с Rapid Commit.

Клиент начинает обмен с сервером для настройки или обновления информации. Процесс может запускаться системой при установке ОС, с превентивной целью, при конфигурировании уровня приложений или продлении срока жизни адреса.

В обычном жизненном цикле используются сообщения REQUEST, RENEW, REBIND, RELEASE, DECLINE. Для проверки привязки адресов к новому сегменту используется CONFIRM, а для получения только параметров — INFORMATION-REQUEST.

Сообщение REQUEST запрашивает адреса на IA и другие параметры. В поле опций передаются:

• идентификатор клиента (Client Identifier)
• идентификатор сервера (Server Identifier)
• список желаемых опций (Request Option)

Может указываться Reconfigure Accept.

Если сервер обнаружит несоответствие префикса в переданной в IA адресу — отвечает REPLY с кодом NotOnLink. Если не может назначить адрес — REPLY с NoAddrAvail.

Для каждой IA, по которой назначаются адреса, сервер указывает в ответе адреса и связанные параметры.

Если клиент сменил сегмент сети, назначенные ему ранее адреса могут быть некорректны. Для проверки клиент инициирует обмен CONFIRM/REPLY. Все относящиеся к интерфейсу IA перечисляются в CONFIRM. Сервер в ответе REPLY указывает, какие из адресов валидны для текущего сегмента.

Для продления срока жизни адреса из IA клиент отправляет RENEW исходному серверу. В сообщение включается IA с интересующей адресацией. Сервер по своей конфигурации определяет новые сроки, может добавить новые адреса или удалить (установив «lifetime=0»). Периоды T1 и T2 в IA регулируют периодичность обновлений.

На несогласованность сессии сервер отвечает REPLY с NoBinding; на успех — возвращает IA с новыми адресами и сроками.

Если время T2 истекло и RENEW не прошёл, клиент обращается через REBIND/REPLY к любому доступному серверу.

В отсутствие ответа клиент может запустить повторный SOLICIT/REQUEST либо использовать другие IA. Сервер валидирует полученную IA: если клиент не найден или адрес не подходит — адрес сбрасывается (lifetime=0); иначе выдаются новые сроки.

Для получения параметров конфигурации (например, DNS) без адреса используется INFORMATION-REQUEST. Обязательно указывать Client Identifier; если его нет — сервер не высылает специфичные параметры. Требуемые опции перечисляются явно.

Для освобождения адреса клиент посылает RELEASE своему серверу, указав соответствующие IA и Client Identifier. Использовать освобождаемый адрес для передачи RELEASE нельзя; при отсутствии REPLY клиент повторяет трансляцию RELEASE до завершения.

Приняв RELEASE, сервер валидирует IA и высвобождает адреса, делая их доступными для других клиентов; в ответ — REPLY с Success.

При обнаружении использования выданного адреса другим узлом клиент отправляет DECLINE. Сервер проверяет адрес, и если подтверждается пересечение — удаляет его из IA данного клиента и завершает ответом REPLY с Success.

Сервер может инициировать обмен с целью сообщения клиентам о новых параметрах (например, при обновлении сервиса).

Сообщение RECONFIGURE от сервера заставляет клиента начать RENEW/REPLY или INFORMATION-REQUEST/REPLY.

В поле опций содержатся DUID сервера и клиента; дополнительно сервер может рекомендовать нужные опции через Request. Из-за риска атак типа отказ в обслуживании для RECONFIGURE обязательна DHCP-аутентификация. Передача RECONFIGURE осуществляется по unicast-адресу клиента; если он не известен — через RELAY-REPLY по ретранслятору.

Для каждого клиента создаётся отдельно RECONFIGURE; в случае отсутствия отклика допускаются повторы с удвоением REC_TIMEOUT вплоть до максимума после чего попытка считается неудачной.

Клиент, получив RECONFIGURE, реагирует RENEW или INFORMATION-REQUEST в соответствии с полученной инструкцией; новые RECONFIGURE игнорируются до завершения обмена.

При получении сообщения от клиента агент создаёт RELAY-FORWARD, заполняя Peer-Address адресом источника, инкапсулирует оригинальное сообщение (Relay Message), устанавливает Hop Limit в 32.

Link-address задаётся глобальным или site-local-адресом префикса сегмента клиента; Hop-Count изначально 0, для каждого ретранслятора увеличивается на 1.

Если агент получает RELAY-FORWARD c Hop-Count ниже лимита — повторяет процедуру с увеличением счётчика.

Сервер на RELAY-FORWARD отвечает RELAY-REPLY, инкапсулируя ответ для каждого следующего ретранслятора до клиента. Каждый агент извлекает вложенное сообщение из Relay Message и пересылает по Peer-Address.

Для предотвращения атак (отказ в обслуживании, несанкционированная конфигурация, атаки в открытых сетях) применяется механизм аутентификации сообщений DHCPv6, основанный на принципах аутентификации DHCPv4.

Аутентификация реализуется опцией Authentication, обеспечивающей подтверждение подлинности источника и целостности сообщения (обычно — не более одной Authentication-опции в сообщении).

Ретрансляторы и серверы могут защищать обмен через IPsec над IPv6. Для ретрансляции по разным цепочкам используются независимые ассоциации доверия.

Поле RDM (Replay Detection Method) определяет способ предотвращения replay-атак (например, метка времени).

Если поле Protocol в Authentication-опции равно 2, задействуется механизм задержанной аутентификации. Клиент запрашивает аутентификацию сообщением SOLICIT, сервер отдаёт ADVERTISE с challenge и MAC. Подсчёт MAC производится по алгоритму HMAC (MD5), который вычисляется по всему сообщению DHCPv6 с обнулённым полем MAC.

Клиент и сервер хранят набор ключей (идентификатор: <DHCP realm, DUID клиента, key-id>), каждый — с ограниченным сроком действия.

Аутентификация DHCPv6 для протокола DELAYED AUTHENTICATION

Протокол «Reconfigure Key Authentication» защищает клиентов от недружественных RECONFIGURE-сообщений. Сервер в первом обмене отправляет клиенту ключ Reconfigure, затем подписывает HMAC-ключом сообщения RECONFIGURE. Аутентификация передаётся через Authentication-опцию.

Протокол применяется только если не используется другая аутентификация и согласовано применение RECONFIGURE.

Аутентификация DHCPv6 для протокола RECONFIGURE KEY AUTHENTICATION

Протокол установления сеанса (SIP) — протокол управления приложений, обеспечивающий запуск/изменение/завершение мультимедиа-сессий. В DHCPv6 реализованы опции^[2], позволяющие клиентам SIP находить SIP-серверы для обслуживания исходящих запросов.

Опция может содержать несколько доменных имён, каждый из которых указывает на отдельную NAPTR-запись. Клиенты проверяют их в порядке приоритета.

Опция DHCPv6: список доменных имён SIP-сервера

Опция определяет список IPv6-адресов SIP-прокси, к которым клиент может обращаться, в порядке приоритета.

Опция DHCPv6: список IPv6-адресов SIP-сервера

В спецификации предусмотрены передачи списка DNS-серверов^[3] и доменов поиска.

Список DNS-серверов для рекурсивных запросов, отсортированных по приоритету.

Опция DHCPv6: список DNS recursivo

Список доменов поиска, используемых клиентом при разрешении имен. Отменяет любые другие механизмы разрешения.

Опция DHCPv6: список доменов поиска

Список всех актуальных опций для DHCPv6 представлен на сайте IANA^[4].

Узлы, получившие IPv6-адреса иными способами (автонастройка без состояния, ручная конфигурация), могут использовать stateless DHCPv6^[5] для получения настроек (например, списка DNS). Сервер stateless не выделяет адреса и не ведёт динамический учёт клиентов — он лишь возвращает параметры по запросу.

В stateless DHCPv6 используются сообщения:

• Information-Request
• Reply
• Relay-Forward
• Relay-Reply