Протокол DHCPv6

Мы разобрали вопросы, связанные со служебным протоколом ICMPv6. Посмотрели, что некоторые задачи в IPv6 ICMP успешно закрывает: обнаружение соседей, настройку IP-адресов для простых ситуаций.

Но есть случаи, когда механизм Neighbor Discovery позволяет получить адрес, но не позволяет использовать его полноценно. Для полноценной работы нужно что-то ещё -- например, выдать дополнительные опции. Шлюз по умолчанию может быть назначен через ND, но DNS-сервер придётся сообщить другим способом.

DHCPv6 как раз используется для таких задач: он выдаёт настройки, которые через Neighbor Discovery не назначаются.

Отличия DHCPv6 от DHCP для IPv4

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

Для сравнения: есть протоколы, которые в IPv4 и IPv6 почти одинаковы. Например, RIPv2 и RIPng -- формат пакета практически идентичен, разница только в размере адресов. А вот DHCPv6 использует совершенно другой формат передачи данных.

Причина в том, что DHCP для IPv4 использовал режим совместимости со старым протоколом BOOTP -- древним протоколом для бездисковой загрузки рабочих станций. DHCP для IPv4 был построен на его основе. Использовать для IPv6 режим совместимости с DHCPv4, который сам сделан в режиме совместимости с BOOTP, -- смысла особого не было.

Поэтому DHCPv6 использует свой формат пакета, который вообще не похож на DHCPv4. Но у него есть важное свойство: в нём тоже можно передавать опции. DHCPv4 брал BOOTP-сообщение и приклеивал к нему опции в TLV-формате. DHCPv6 делает то же самое, но без необходимости тащить за собой наследие BOOTP:

• Нет текстового поля имени хоста фиксированной длины 16 символов, которое добивалось нулями
• Нет поля физического адреса на 16 байт, куда MAC-адрес (6 байт) записывался с 10 байтами мусора

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

Мультикаст вместо бродкаста

Вместо бродкастов, которые использовались в DHCPv4, в DHCPv6 используется мультикаст.

В DHCPv4 при отправке запроса "я хочу получить адрес" происходило следующее:

1. Все узлы получали кадр с адресом получателя FF:FF:FF:FF:FF:FF
2. Все считали контрольную сумму кадра
3. Все смотрели EtherType 0x0800 -- протокол IP
4. IP считал свою контрольную сумму, видел адрес 255.255.255.255
5. Внутри UDP -- ещё одна контрольная сумма
6. И только после всего этого узел смотрел номер порта и понимал: "это не мне"

Столько вычислений, которых можно было бы избежать, отказавшись от бродкаста.

DHCPv6 использует два мультикастовых адреса:

Адрес	Scope	Назначение
ff02::1:2	Link-local (2)	Все DHCP-агенты в пределах канала
ff05::1:3	Site-local (5)	Все DHCP-серверы в пределах сайта (предприятия)

Двойка в адресе (ff02) означает scope в пределах канала, пятёрка (ff05) -- в пределах сайта.

Два сценария использования

Сценарий 1: у клиента нет маршрутизируемого адреса. Клиент отправляет запрос на ff02::1:2. Его получает relay-агент в том же канале. Агент пересылает запрос на DHCP-сервер, получает ответ и предлагает адрес клиенту от своего имени. Relay-агент при пересылке может модифицировать запрос -- например, записать порт, из которого получен запрос.

Сценарий 2: у клиента уже есть маршрутизируемый адрес (например, полученный через SLAAC). Клиент может обратиться напрямую к серверу на ff05::1:3, минуя агента. Это удобно, если нужны только опции.

Порты

Поскольку протокол изменился, порты тоже другие:

	DHCPv4	DHCPv6
Сервер	67	547
Клиент	68	546

Инкапсуляция в UDP сохранилась.

Два режима работы: Stateful и Stateless

Stateful DHCPv6

Работает так же, как в IPv4:

1. Сервер хранит базу адресов
2. Клиент приходит и просит адрес
3. Сервер записывает: "Васе выдан адрес fd00::2001"
4. Адрес выдаётся на ограниченный срок (аренда)
5. Клиент обязуется продлевать аренду или прекратить использование
6. Именно сервер решает, какой адрес выдать, на какой срок, и какие опции назначить

Для каждого клиента можно назначить индивидуальные опции (например, разные DNS-серверы). Поскольку сервер хранит состояние каждого клиента, это называется Stateful DHCP -- режим с сохранением состояния.

Stateless DHCPv6

Если у клиента уже есть адрес (полученный, например, через Neighbor Discovery), и ему нужны только настройки:

• Сервер не запоминает состояние клиентов
• Всем выдаётся одинаковый набор опций (DNS, настройки загрузки и т.д.)
• Нет необходимости различать Петю, Васю и Колю

Stateless DHCP -- режим без сохранения состояния. Предполагается, что у клиента уже есть IP-адрес.

Сообщения DHCPv6

Основные сообщения очень похожи на DHCPv4, только переименованы:

DHCPv4	DHCPv6	Описание
Discover	Solicit	Клиент ищет DHCP-сервер
Offer	Advertise	Сервер предлагает адрес
Request	Request	Клиент принимает предложение
Acknowledge	Reply	Сервер подтверждает выдачу

Смысл сохранился тот же самый, сообщения просто переименованы.

Дополнительные сообщения

• Renew -- клиент продлевает аренду у конкретного сервера (юникастом)
• Rebind -- клиент пытается продлить аренду у любого сервера (мультикастом), если исходный сервер не отвечает. Аналогично механизму T1/T2 в IPv4: до времени T1 продление идёт юникастом, после T2 -- на всю сеть
• Release -- клиент сообщает серверу, что больше не будет использовать адрес (например, при перезагрузке). Сервер может отдать адрес другому
• Decline -- клиент отказывается от предложенного адреса, если Duplicate Address Detection обнаружил конфликт
• Reconfigure -- сервер просит клиента перезапросить настройки. Прямого сообщения "отбери адрес" нет: сервер посылает Reconfigure, клиент пытается продлить аренду, и тут сервер отказывает
• Confirm -- клиент проверяет, действительна ли ещё аренда (используется редко)
• Relay Forward / Relay Reply (типы 12 и 13) -- специальные сообщения между relay-агентом и сервером. В отличие от IPv4, где между агентом и сервером использовались те же Discover/Offer/Request/Acknowledge, в DHCPv6 это отдельные типы сообщений

Процедура получения адреса

Stateful-режим

Маршрутизатор отправляет Router Advertisement, в котором выставлен флаг Managed (M). Это означает: "получи адрес с DHCP-сервера". Возможно, RA не содержит Prefix Information, возможно, содержит -- неважно.

Клиент начинает обмен:

Клиент → Solicit   → Сервер
Клиент ← Advertise ← Сервер
Клиент → Request   → Сервер
Клиент ← Reply     ← Сервер

Stateless-режим

Аналогично, но вместо Request клиент посылает Information Request -- запрос только на опции, без адреса:

Клиент → Solicit             → Сервер
Клиент ← Advertise           ← Сервер
Клиент → Information Request → Сервер
Клиент ← Reply               ← Сервер

Rapid Commit

Механизм Rapid Commit позволяет сократить обмен вдвое -- с четырёх сообщений до двух:

Клиент → Solicit (с флагом Rapid Commit) → Сервер
Клиент ← Reply                           ← Сервер

Клиент в Solicit указывает, что готов сразу получить адрес. Если сервер поддерживает Rapid Commit, он пропускает Advertise и Request, сразу выдаёт адрес и помечает его как занятый. Клиент немедленно начинает его использовать.

Если у вас один сервер, то промежуточные Advertise и Request по сути избыточны -- сервер в любом случае резервирует адрес под клиента. Rapid Commit есть и в DHCPv4. Для работы нужна поддержка и на клиенте, и на сервере.

Prefix Delegation

Самая важная часть -- ради которой, по сути, этот модуль и создан.

Проблема

В IPv4 DHCP выдавал один адрес конечному узлу. Домашний роутер (CPE -- Customer Premises Equipment) получал один публичный адрес от провайдера, а за ним работал NAT:

Провайдерская сеть (PA-адреса: 203.0.113.0/24)
    │
    ├── CPE-1: получает 203.0.113.2
    │     └── Внутренняя сеть: 192.168.0.0/24 (NAT)
    │
    └── CPE-2: получает 203.0.113.3
          └── Внутренняя сеть: 192.168.0.0/24 (NAT)

Решение в IPv6

В IPv6 NAT не используется. CPE должна получить не один адрес, а целый префикс, который она будет раздавать клиентам во внутренней сети. Именно для этого существует Prefix Delegation.

Как это работает:

1. CPE получает адрес на внешнем интерфейсе (например, через SLAAC)
2. CPE отправляет DHCP-запрос с Prefix Delegation
3. DHCP-сервер провайдера выдаёт префикс, например 2001:db8:b5:01::/64
4. CPE начинает анонсировать этот префикс во внутренней сети через Router Advertisement с Prefix Information
5. Клиенты внутри сети генерируют себе адреса из полученного префикса (Modified EUI-64 или другим способом)

Провайдерская сеть (префикс /32)
    │
    ├── CPE-1: получает по PD префикс 2001:db8:b5:01::/64
    │     └── Клиенты: 2001:db8:b5:01::<interface-id>
    │
    └── CPE-2: получает по PD префикс 2001:db8:b5:02::/64
          └── Клиенты: 2001:db8:b5:02::<interface-id>

Крупные клиенты

Если клиент -- юрлицо с множеством внутренних сетей, он может получить более крупный префикс, например /48. Тогда CPE самостоятельно нарезает его на /64 и раздаёт по разным интерфейсам:

CPE получает 2001:db8:b5::/48
    ├── Интерфейс 1: 2001:db8:b5:01::/64
    ├── Интерфейс 2: 2001:db8:b5:02::/64
    └── Интерфейс 3: 2001:db8:b5:03::/64

Почему это жизненно важно

Без Prefix Delegation пришлось бы на каждую клиентскую железку заходить вручную и прописывать адреса -- фактически то же самое, что ручная настройка адресов в IPv4.

С Prefix Delegation провайдер раздаёт одинаковые CPE всем клиентам. Каждая железка:

• Преднастроена стандартным образом, без привязки к конкретному клиенту
• При включении автоматически получает уникальный префикс по DHCP
• Начинает раздавать его во внутреннюю сеть

Клиент может даже поставить собственный роутер -- он точно так же получит префикс через Prefix Delegation и начнёт раздавать адреса.

Итоги

В сети предприятия DHCPv6 нужен прежде всего для раздачи опций (DNS и т.д.) в Stateless-режиме. Адреса прекрасно раздаются через Prefix Information в RA. Если сервер перезагрузится, он не потеряет базу адресов (её просто нет), и не будет коллизий.

В провайдерских сетях DHCPv6 жизненно необходим для Prefix Delegation -- автоматической раздачи префиксов клиентским устройствам без ручной настройки каждой CPE.