ip.v6net.ru
Мы включили IPv6 в апреле 2011г.
Получение IPv6-адреса возможно несколькими путями:
(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-сервера. Впервые это было описано в RFC5006 — «IPv6 Router Advertisement Option for DNS Configuration» (сентябрь 2007г). Технология несложная: одна из опций в ND, а именно опция 25 выбрана для хранения информации о рекурсивном DNS-сервере. Также в этом TLV-наборе передается и время действия информации о данном DNS-сервере. В одном сообщении может содержаться несколько 128-битных IPv6-адресов DNS-серверов, их число определяется по полю length, которое содержит число байтов, с учетом того, что 32 бита (то есть 4 байта) отведено под «время жизни». Для продления-обновления информации о DNS-серверах хосты могут использовать RS-запросы. В документе также приведены некоторые меры безопасности: хост должен контролировать поле «длина», и если оно меньше 3, то опция и данные в ней — игнорируются. Далее: время жизни этой записи не должно превышать время жизни RA, так как при истечении второго, вся информация из RA считается (логично) недействительной.
В документе RFC6106 (ноябрь 2010) в RA добавляется опция 31, с доменными суффиксами.
В документе RFC8106 (март 2017), который был выпущен на замену 5006 и 6106, приведена самая свежая информация о состоянии RA IPv6.
Очевидное требование к оборудованию: устройство (роутер), генерирующий RA, должен поддерживать конфигурирование этих опций. На Cisco можно просто проверить наличие команды ipv6 nd ra dns server на нужном интерфейсе.
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)
У каждого сервера и клиента есть уникальный идентификатор, для того чтобы различать других клиентов и (или) серверы.
ИМХО самое интересное — это то, что relay может вставлять дополнительную информацию в запрос — Relay Agent Option ID
Структура простая:
2 байта: код опции = 31; 2 байта: длина опции Remote-ID плюс 4
4 байта: код производителя оборудования (зарегистрированный в IANA)
… и далее следует Remote-ID указанной длины, где может содержаться информация о интерфейсе (или номер порта).
То есть получается аналог Option-82 из IPv4 DHCP.
Поскольку проблема «привязки» трафика к клиенту будет наверняка очень важной, то наличие такой опции может серьезно помочь при работе с «сеансовыми» клиентами. Какой-либо информации о реализации данной опции в массовом оборудовании пока найти не удалось (на день написания этих строк).