самая первая заметка рассматривает применение IPv6 в сети провайдера, вторая заметка посвящена совместимости IPv4 и IPv6. в этой рассмтрим автоматическую конфигурацию узла.
вы наверное слышали про магию IPv6, что все в этом протоколе настраивается автоматически. так то оно так да только не совсем. полностью автоматически можно настроить адрес узла, шлюз по умолчанию, но этого мало. да эта основная настройка, но еще нужен как минимум настроить DNS сервер. в принципе это можно сделать вручную, но рассмотрим варианты автоматической настройки.
итак вы включили рабочую станцию что проходит первым делом? с сперва рабочая станция должна сформировать и установить уникальный адрес на линьке или и Link-Local адреса (LLA). сей час для этого используется механизм Randomized Interface Identifier (случайный идентификатор) для конфиденциальности. «Классический» EUI-64 на клиентских устройствах уже почти не встречается т.к. генерируется на основании MAC адреса который часто жёстко привязан к устройству. така привязка упрощает отслеживание, что по современным меркам недопустимо.
после того как был сформирован LLA нужно определить не принадлежит ли это адрес кому-то еще в нашей подсети. для того выполняется DAD (Duplicate Address Detection) запрос. оправляется Neighbor Solicitation (NS) message на multicast-адрес ff02::1:ffxx:xxxx (solicited-node multicast) для запрашиваемого адреса. если в течение таймаута не приходит ответ (Neighbor Advertisement — NA), адрес считается уникальным и назначается интерфейсу. если приходит ответ — значит, адрес уже занят, и ОС генерирует новый.
отлично у нас есть адрес уникальный на линьке. дальше узел отправляет ICMPv6 Router Solicitation (RS) на multicast-адрес ff02::2 (все роутеры) делается это с использованием уже проверенного LLA в качестве IPv6-адреса источника.
в ответ получает Router Advertisement (RA). в RA содержится префикс сети (Prefix Information) например, 2001:db8:1:1::/64. важно: передаётся только префикс (64 бита), шлюз по умолчанию (Default Router): LLA роутера, который разослал это RA. в принципе этой информации достаточно чтобы настроить сеть, но как вы видите нет информации о DNS сервере поэтому устанавливаются ещё флаги Managed Address (M-flag) и Other Configuration (O-flag).
здесь первая проблема: уязвимость RA-сообщений: злоумышленник может запустить на сети свой роутер и рассылать ложные RA, перенаправляя трафик или навязывая неправильные настройки. к счастью защитится довольно просто: нужно отбрасывать RA-сообщения, приходящие с абонентских портов, оставляя право рассылать их только доверенным портам, ведущим к вашим настоящим роутерам.
M-flag =0, O-flag=0. если оба флага равны нулю то IPv6 адрес генерирует из своего ID и префикса из RA. тоже используется механизм DAD. важно отметить что DHCPv6 использоваться не будет и дополнительные сервера, самый важный из них DNS не настраиваются, например должны быть прописаны вручную.
M-flag =0, O-flag=1 в этом случае адрес узла тоже будет сгенерирован случайным образом, но информация о дополнительных серверах будет получена от DHCPv6-сервера. происходит это так: узел делает HCPv6 Solicit/Information-Request запрос на multicast-адрес ff02::1:2 получает DHCPv6 Reply/Advertise и выполнят дополнительную настройку согласно полученной информации. важно отметить что RA лишь даёт команду куда обратиться за информацией, но не говорит к кому конкретно.
эти оба режима Stateless т.е не хранят какое-либо состояние на сервере: адрес генерируется случайным образам, а DHCP статически отдаёт информацию для дальнейшей конфигурации. даже если адреса генерируются на основании MAC процесс будет носить практически случайный характер, потому что на большинстве домашних роутеров МАС адрес легко поменять. именно потому что процесс будет носить случайный характер, эти режимы не устроят РКН: мы не знаем какое устройство в какой момент времени какой адрес использует. поэтому нужно использовать режим Stateful DHCPv6.
M-flag =1. в этом случае игнорирует префикс из RA для генерации GUA (глобального адреса) адреса. вся информация поступает от DHCPv6-сервера.
вот здесь можно развернутся. например выдавать адреса на основании DHCPv6 Relay Option 18 (Interface-ID) и Option 37 (Remote-ID). т.е. мы управляем какие адреса на каком порту коммутатора будут выдаваться. т.е. мы можем назначить довольно широкий пул адресов для конкретного порта например 64. т.е. 64 устройства к этому порту коммутатора могут быть подключены. при этом в биллинге мы можем сопоставить конкретного абонента с конкретным портом конкретного коммутатора. это то что нужно — РКН счастлив. да и лучше не мелочится уж отдавайте каждому абоненту группу в адресе — т.е. 16 бит (65536 адресов) — считать проще.
написано в соавторстве с deepseek.