DHCP-SLAAC

SLAAC: немного теории.

Для начала берем и читаем RFC2462, 25 страниц, датированы декабрем 1998г. — и читаем про IPv6 Stateless Address Autoconfiguration. Много интересного:

все начинается с генерации link-local адреса для интерфейса, правило простое:

fe80::/64 плюс EUI-64.

Далее — он проверяется на уникальность. Если (что маловероятно) такой адрес уже есть — то автоконфигурирование заканчивается, нужно садиться за консоль.

Затем хост определяет, что ему нужно автоконфигурировать: адрес и доп.параметры, или только доп.параметры (DNS и прочее), и нужен ли вообще DHCP-сервер. Для этого используются RA (router advertisments). Разумеется, это верно только в случае, если хоть один роутер передает их в данный сетевой сегмент. В противном случае (при отсутствии сообщений от роутеров) потребуется stateful autoconfiguration. Это относится только к хостам, автоконфигурация роутеров не предусмотрена.

Кратко: получение IPv6-адреса возможно несколькими путями:

  1. Вручную
  2. Автоматически, без использования DHCP-сервера (stateles autoconfig, SLAAC)
  3. Полуавтоматически, с частичным использованием DHCP-сервера (stateles DHCP autoconfig)
  4. Автоматически, с использованием DHCP-сервера.

1. Тут все понятно. Нужно прописать адрес и маску (длину префикса), а также шлюз по умолчанию. Если в подсети имеются роутер, то возможно не придется конфигурировать шлюз, так как машина может получить его link-local адрес из RA. Адрес DNS-сервера придется сконфигурировать вручную.
2. Если в подсети есть роутер (роутеры), которые анонсят префиксы /64 в эту подсеть, то машина может самостоятельно сформировать свой IPv6-адрес из 64-битного префикса из анонсов и мас-адреса, в соответствии с алгоритмом EUI-64. Адрес шлюза также может быть взят из аноносов от роутеров (RA). Увы, но адрес DNS-сервера придется сконфигурировать вручную.
3. Адрес может быть назначен вручную или сформирован в соответствии с пунктом 2, а дополнительные параметры, такие как адрес DNS-сервера, можно запросить у DHCP-сервера. Такой вариант, судя по публикациям, существует пока только на бумаге. И — так же, как и в пункте 2, роутер должен анонсить префикс длиной 64 бит.
4. Тут тоже понятно, все параметры назначаются автоматически. Но! Нужно, чтобы DHCP-сервер «понимал» IPv6. Достоверно известно, что ISC DHCP, который используется практически во всех *NIX/NUX ОС, пригоден для данной задачи. Также есть много публикаций о том, что Windows DHCP server самых последних модификций не работает с IPv6.

Остается как-то автоматизировать получение IPv6-адреса DNS-сервера. Впервые это было описано в RFC-5006 — «IPv6 Router Advertisement Option for DNS Configuration» (сентябрь 2007г., то есть достаточно свежий документ). Технология несложная: одна из опций в ND, а именно опция 25 выбрана для хранения информации о рекурсивном DNS-сервере. Также в этом TLV-наборе передается и время действия информации о данном DNS-сервере. В одном сообщении может содержаться несколько 128-битных IPv6-адресов (то есть без сокращений) DNS-серверов, их число определяется по полю length, которое содержит число байтов, с учетом того, что 32 бита (то есть 4 байта) отведено под «время жизни». Для продления-обновления информации о DNS-серверах хосты могут использовать RS-запросы. В документе также приведены некоторые меры безопасности: хост должен контролировать поле «длина», и если оно меньше 3, то опция и данные в ней — игнорируются. Далее: время жизни этой записи не должно превышать время жизни RA, так как при истечении второго, вся информация из RA считается (логично) недействительной.

Одно плохо: какой-либо информации о реализации этой опции в RA найти не удалось…

DHCPv6.
(RFC 3315, июль 2003)

Сетевые основы:

DHCPv6 использует мультикаст-адреса:
Аll_DHCP_Relay_Agents_and_Servers (FF02::1:2) — Link-scoped мультикастовый адрес, используется клиентом для отправки запросов релеям и серверам.
All_DHCP_Servers (FF05::1:3) — Site-scoped мультикастовый адрес, используется релеем для переправки запросов серверам.

Серверы и релеи слушают запросы на UDP:547
Клиент слуашет ответы на UDP:546
Клиент всегда отправляет DHCP-запросы на адрес All_DHCP_Relay_Agents_and_Servers.

Обмен выглядит так:

Solicit:Client (link-local) ==> Server (ff02::1:2)
Client (link-local)        <== Advertise:Server (link-local)
Request:Client (link-local) ==> Server (ff02::1:2)
Client (link-local)        <== Reply:Server (link-local)

Основные типы сообщений (в скобках указан код):

SOLICIT (1)         Используется клиентом для поиска серверов.
ADVERTISE (2)      DHCPv6-сервер сообщает о себе в ответ на (1)
REQUEST (3)        Клиент запрашивает параметры у конкретного сервера
CONFIRM (4)        Клиент подтверждает, что получил адрес
RENEW (5)          Клиент просит сервер, от которого уже получил параметры, продлить время их действия
REPLY (7)           Ответ сервера с параметрами или подтверждение ранее выданных параметров
RELEASE (8)        Клиент сообщает серверу об освобождении ранее полученого адреса
DECLINE (9)        Клиент отклонил предложенный адрес, так как его уже кто-то использует
INFORMATION-REQUEST (11) Запрос от клиента к серверу на выдачу параметров (кроме адреса)

DHCP Unique Identifier (DUID)
У каждого сервера и клиента есть уникальный идентификатор, для того чтобы различать других клиентов и (или) серверы.

Судя по литературе, сейчас (июнь 2011) полную функциональность обеспечивает толко ISC DHCP сервер версии 4.2, работающий под ОС *BSD или Solaris. ISC DHCP сервер может работать только по IPv4 или по IPv6, но не может одновременно обслуживать два протокола.

 DHCP Relay, дополнительная информация из RFC 4649 — август 2006.

ИМХО самое интересное — это то, что relay может вставлять дополнительную информацию в запрос —  Relay Agent Option ID

Структура простая:

2 байта: код опции = 31; 2 байта: длина опции Remote-ID плюс 4

4 байта: код производителя оборудования (зарегистрированный в IANA)

— и далее — Remote-ID указанной длины, где может содержаться информация о интерфейсе (или номер порта).

То есть получается аналог Option-82 из IPv4 DHCP.

Поскольку проблема «привязки» трафика к клиенту будет наверняка очень важной, то наличие такой опции может серьезно помочь при работе с «сеансовыми» клиентами. Какой-либо информации о реализации данной опции в массовом оборудовании найти не удалось (на сегодняшний день).

Вот тут все изложено подробнее:

http://www.hotplug.ru/2012/01/nastrojki-ip-i-ipv6-v-freebsd-9-0/

SLAAC

DHCPv6


  *** Via IPv4 ***  

DHCP-SLAAC: 2 комментария

  1. Уведомление: Настройки ip и ipv6 в FreeBSD 9.0 | HotPlug Notes

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.