Протокол ICMPv6

ICMPv6 (Internet Control Message Protocol for IPv6) — служебный протокол, необходимый для корректной работы IPv6.

В IPv4 тоже был ICMP — его RFC имел номер 792, рядом с RFC 791 для самого IPv4. Номера неслучайно шли подряд: ICMP v4 был служебным протоколом, помогавшим IPv4 нормально существовать. Изначально он не задумывался как часть протокола, но уже на этапе стандартизации стало понятно, что без него никак.

Для IPv6 протокол ICMP уже является неотъемлемой частью протокола. Без него использовать IPv6 не получится. Все служебные механизмы, которые в IPv4 требовались отдельно, вынесены в этот специальный служебный протокол.

Код вложения (Next Header)

ICMPv6 имеет необычный код вложения. В IPv4 коды были такие:

Протокол	Код в IPv4	Код в IPv6
ICMP	1	58
TCP	6	6
UDP	17	17
ESP	50	50
AH	51	51

В IPv6 почти все коды сохранились, но единица зарезервирована под опции, а ICMPv6 получил новый номер Next Header = 58.

Формат заголовка

Формат заголовка аналогичен ICMPv4:

1. Тип сообщения (1 байт)
2. Код сообщения (1 байт)
3. Контрольная сумма (2 байта)
4. Данные, характерные для конкретного типа сообщения

Контрольная сумма вычисляется от IP-заголовка по тому же принципу, что и в IPv4 — дополнение до единицы (Internet Checksum).

Задачи ICMPv6

Все задачи, которые были в ICMP для IPv4, плюс дополнительные функции:

• Обнаружение канальных адресов соседей — заменяет ARP, Inverse ARP и другие протоколы. ICMPv6 сам умеет обнаруживать канальные адреса без отдельных служебных протоколов.
• Базовая автонастройка конечных узлов — заменяет часть функций DHCP. Можно назначить IP-адрес на интерфейс, прописать маршрут по умолчанию без дополнительных протоколов. Для продвинутых настроек можно использовать ICMPv6 + DHCPv6.
• Управление мультикастом — протокол MLD (Multicast Listener Discovery), заменяющий IGMP из IPv4, является частью ICMPv6. Несмотря на отдельную аббревиатуру, это часть большого Internet Control Message Protocol.
• Neighbor Discovery — обнаружение соседей.
• Router Discovery — обнаружение маршрутизаторов и базовая настройка узлов.

---

Типы сообщений ICMPv6

Тип сообщения указывает на глобальный характер содержимого. Старший бит определяет категорию:

• Типы 0--127 (старший бит = 0) — сообщения об ошибках
• Типы 128--255 (старший бит = 1) — информационные сообщения

Сообщения об ошибках

Тип 1: Destination Unreachable

Аналог типа 3 в ICMPv4. Генерируется, когда невозможно доставить пакет до получателя:

• порт недоступен
• канальный адрес не распознается
• маршрутизатор не знает маршрута в сеть

Далее уже кодом уточняется причина: недоступный порт UDP, отсутствие маршрута (no route to host), невозможность обнаружить канальный адрес получателя в connected-сети и т.д.

Тип 2: Packet Too Big

Специально отделен от Destination Unreachable. Если пакет не может пройти по линку из-за ограничения MTU, это не ошибка доставки — это указание отправителю переотправить пакет меньшего размера.

Сообщение содержит:

• Кусочек исходного пакета (чтобы отправитель понял, что именно не пролезло)
• Значение MTU на проблемном участке в явном виде

Например, вы отправляете пакет с MTU 1500, а на промежуточном линке MTU = 1400. Маршрутизатор возвращает Packet Too Big с указанием: "больше чем 1400 не пролезает". Отправитель заносит это в специальный список и при следующей отправке использует максимальный размер 1400 байт.

Таким образом, для каждого узла, с которым ведется взаимодействие, хранится отдельная запись о максимальном размере пакета (Path MTU Discovery).

Тип 3: Time Exceeded

Если у пакета закончился Hop Limit (аналог TTL), это тоже не ошибка доставки. Это означает, что пакет отправлен с недостаточными параметрами. Если бы отправитель выставил больший Hop Limit, пакет бы прошел.

Принципиальная разница:

• Destination Unreachable — сеть назначения принципиально недостижима
• Time Exceeded — можно было бы доставить, если отправить с другим TTL

Тип 4: Parameter Problem

Генерируется, когда пакет некорректно составлен. Например:

• В поле Payload Length указано ненулевое значение, а при этом присутствует опция Jumbo Payload
• Payload Length = 0, но Jumbo Payload отсутствует
• Jumbo Payload меньше 65 КБ

Другие пакеты до того же получателя при этом могут дойти нормально.

Информационные сообщения

Тип	Название	Назначение
128	Echo Request	Запрос ping
129	Echo Reply	Ответ на ping
133	Router Solicitation (RS)	Запрос информации о маршрутизаторах
134	Router Advertisement (RA)	Ответ маршрутизатора с настройками
135	Neighbor Solicitation (NS)	Запрос канального адреса соседа
136	Neighbor Advertisement (NA)	Ответ с канальным адресом
137	Redirect	Перенаправление трафика

В IPv4 Echo Request имел тип 8, код 0, а Echo Reply — тип 0, код 0 (странно, что они совсем непохожи). В IPv6 типы 128 и 129 идут рядом.

---

Neighbor Discovery Protocol (NDP)

NDP использует 5 типов сообщений: 133--137. Они делятся на две группы:

• Router Discovery (133, 134) — обнаружение маршрутизаторов
• Neighbor Discovery (135, 136) — обнаружение канальных адресов соседей
• Redirect (137) — перенаправление

Redirect (тип 137)

Если узел отправляет пакет маршрутизатору, а тот видит, что next hop находится в одной connected-среде с отправителем, маршрутизатор посылает Redirect. Узлу предлагается отправлять трафик напрямую на другой маршрутизатор, минуя промежуточный.

Это экономит ресурсы: без Redirect один и тот же пакет дважды проходит через интерфейс промежуточного маршрутизатора. Механизм существовал и в IPv4, но из-за проблем безопасности мало кто им пользовался. В IPv6 он сохранился, потому что в определенных ситуациях бывает полезен.

В NBMA-средах (например, Frame Relay) прямое взаимодействие между узлами может быть невозможно, и тогда Redirect не применяется.

---

Механизм обнаружения соседей (Neighbor Solicitation / Neighbor Advertisement)

Проблема широковещания

В IPv4 для обнаружения канальных адресов использовался ARP с широковещательной рассылкой. Все узлы в сети вынуждены были обрабатывать каждый ARP-запрос.

В IPv6 широковещания нет. Можно было бы использовать мультикаст-адрес "все узлы" (FF02::1), но тогда все равно все бы напрягались, а реальный обладатель IP-адреса — только один.

Solicited-Node Multicast Address (SNMA)

Вместо этого IPv6 использует Solicited-Node Multicast Address (SNMA) — группу узлов, у которых IP-адреса заканчиваются на одинаковые 24 бита.

Формат SNMA:

FF02::1:FF00:0/104

• FF — мультикаст
• 02 — scope = link-local (в пределах канала)
• ::1:FF — фиксированный префикс (104 бита)
• Последние 24 бита — берутся из IPv6-адреса

Пример: для адреса FE80::2AA:FF:FE28:9C5A последние 24 бита — 28:9C5A. SNMA-адрес: FF02::1:FF28:9C5A.

Почему SNMA эффективен

Если адреса генерируются по схеме Modified EUI-64, последние 24 бита берутся из части MAC-адреса (Vendor Assigned ID), которая назначается на заводе случайным образом. Вероятность совпадения последних 24 бит у двух устройств крайне мала. Поэтому в каждой SNMA-группе обычно находится всего один узел.

Даже если адреса назначены вручную и у нескольких узлов совпали хвосты — будет группа из 2--3 абонентов, а не все.

Маппинг SNMA в Ethernet

Мультикастовый IPv6-адрес отображается в мультикастовый MAC-адрес Ethernet по схеме:

33:33 + последние 4 байта IPv6-адреса

Для SNMA FF02::1:FF28:9C5A MAC-адрес будет: 33:33:FF:28:9C:5A.

Если коммутатор поддерживает MLD snooping, он доставит кадр только на нужные порты. Если не поддерживает — разошлет всем (Unknown Multicast Flooding), но конечные узлы отбросят кадр на канальном уровне, не тратя ресурсы на разбор IP.

Процесс обнаружения соседа

1. Узел A хочет узнать канальный адрес узла B.
2. A отправляет Neighbor Solicitation из-под своего link-local адреса на SNMA-адрес узла B.
3. Все, кроме обладателя нужного IP-адреса, игнорируют запрос.
4. Узел B отвечает Neighbor Advertisement из-под своего link-local адреса на unicast link-local адрес узла A.
5. В ответе содержится MAC-адрес узла B.

Duplicate Address Detection (DAD)

На этом же механизме построена проверка адресов на конфликт. Когда узел хочет занять IP-адрес (назначенный вручную или придуманный автоматически):

1. Адрес переводится в состояние tentative
2. Отправляется NS из-под адреса :: (пустой, "я не знаю свой адрес") на SNMA-адрес проверяемого адреса
3. Если кто-то отвечает NA — адрес занят, использовать нельзя
4. Если никто не ответил — адрес свободен, переводится в состояние preferred

При DAD ответ (NA) идет из-под link-local на FF02::1 (все узлы), потому что запрашивающий не раскрыл свой адрес, и персонально ему ответить невозможно.

---

Neighbor Unreachability Detection (NUD)

NUD — механизм обнаружения недоступности соседей. В IPv4 такого штатного механизма не было.

Зачем нужен NUD

Если вы отправляете соседу данные по UDP и он не отвечает — непонятно, то ли приложение молчит, то ли сосед сдох. NUD решает эту задачу: отправляем NS, получаем NA — сосед живой; не получаем — сосед мертв.

Самый правильный способ проверить доступность соседа в одном канале — не ping, а NS/NA.

Если взаимодействие идет по TCP, протокол сам имеет встроенные таймеры проверки. Поэтому при наличии активного TCP-соединения сосед считается живым без дополнительных NS.

Состояния записей в кэше Neighbor Discovery

В IPv6 есть кэш Neighbor Discovery (аналог ARP-кэша в IPv4). Каждая запись может быть в одном из состояний:

Состояние	Описание
Incomplete	NS отправлен, NA не получен. Нормальное взаимодействие невозможно
Reachable	Есть свежее свидетельство доступности (NA или TCP-ответ). Все в порядке
Stale	Таймер reachable time истек, но данные соседу не отправляются. Сидим на попе ровно
Delay	Отправили данные соседу в состоянии stale, ждем подтверждения. NS отправляется неагрессивно
Probe	Агрессивно отправляем пачку NS, ждем хотя бы один NA
(запись удалена)	Сосед признан недоступным

Алгоритм работы NUD

1. Reachable -> (таймер reachable time истек) -> Stale
2. Stale -> (отправили данные, нет свидетельства доступности) -> Delay
3. Delay -> (таймер прошел, ответа нет) -> Probe
4. Probe -> (отправляем NS агрессивно, раз в секунду, ~10 штук)
   • Получен NA -> Reachable
   • Ни одного NA -> сосед признается мертвым, вышестоящий протокол уведомляется

NUD для удаленных узлов

NUD щупает только соседей в одном канале, но позволяет обнаружить проблемы и с удаленными узлами. Если узел A общается с узлом B через маршрутизатор R:

• A активирует NUD для link-local адреса R (next hop)
• Если R недоступен — трафик до B невозможен
• Если R доступен, но B недоступен — R сам выполнит NUD на своем интерфейсе в сторону B и пришлет A сообщение Destination Unreachable

---

Router Discovery (Router Solicitation / Router Advertisement)

Механизм работы

• Router Solicitation (RS) — отправляется из-под :: на FF02::2 (все маршрутизаторы)
• Router Advertisement (RA) — отправляется из-под link-local адреса маршрутизатора на FF02::1 (все узлы)

Маршрутизаторы периодически рассылают RA по расписанию (например, раз в 10 секунд). Но если узел проснулся и хочет получить настройки немедленно, он может отправить RS внепланово.

Опция Prefix Information

Внутри RA используются опции в формате TLV (Type, Length, Value). Ключевая опция — Prefix Information (тип 3, длина 4 блока по 8 байт = 32 байта).

Содержимое опции Prefix Information:

Поле	Размер	Описание
Type	1 байт	Значение: 3
Length	1 байт	Значение: 4 (блоков по 8 байт)
Prefix Length	1 байт	Длина маски (например, 64)
Флаги L, A	2 бита	См. ниже
Reserved		Нули
Valid Lifetime	4 байта	Время жизни адреса (в секундах)
Preferred Lifetime	4 байта	Время в состоянии preferred (в секундах)
Reserved	4 байта	Нули
Prefix	16 байт	Сам префикс сети

В одном RA может быть несколько опций Prefix Information — по одной на каждую сеть, настроенную на интерфейсе маршрутизатора.

Флаги в Prefix Information

Флаг L (On-Link)

• L = 1 — адреса из этого префикса считаются on-link (в одной канальной среде). Узлы могут обнаруживать канальные адреса друг друга через Neighbor Discovery и общаться напрямую.
• L = 0 — узлы из одной IP-сети не обязательно находятся в одном канале. Весь трафик направляется через маршрутизатор, даже если получатель в той же подсети. Полезно в провайдерских сценариях (аналог Private VLAN).

Флаг A (Autonomous / Autoconfiguration)

• A = 1 — узлы могут использовать этот префикс для SLAAC (Stateless Address Autoconfiguration): взять префикс, добавить к нему Interface ID и получить полный адрес.
• A = 0 — префикс передается информативно, автоматическое назначение адресов не предполагается.

Поля Router Advertisement

Помимо опций, сам заголовок RA содержит:

Поле	Описание
Cur Hop Limit	Рекомендуемый Hop Limit для клиентов
Флаги M, O	Управление DHCP (см. ниже)
Router Lifetime	Время жизни маршрутизатора как шлюза по умолчанию (в секундах). 0 = не использовать как шлюз
Reachable Time	Таймер для NUD: время, в течение которого сосед считается живым
Retransmission Timer	Интервал агрессивных проверок в NUD

Router Lifetime должен быть заведомо больше интервала рассылки RA. Например, если RA рассылается раз в 10 секунд, Router Lifetime можно поставить 30--35 секунд. Тогда потеря 1--2 RA не приведет к удалению шлюза по умолчанию из таблицы маршрутизации клиентов, а 3 потерянные подряд RA означают, что маршрутизатор сдох.

Срок жизни маршрутизатора и срок жизни префиксов (Valid/Preferred Lifetime) — это разные вещи. Маршрутизатор может быть признан мертвым, но адреса из его префиксов продолжат жить по своим таймерам.

Флаги M и O в Router Advertisement

Флаг M (Managed Address Configuration)

• M = 1 — адрес нужно получить по протоколу DHCPv6, а не придумывать через SLAAC
• M = 0 — используется SLAAC (Stateless Address Autoconfiguration)

Даже при M = 1, если в RA есть Prefix Information с флагом A = 1, узел может придумать адрес и по SLAAC тоже. Конкретное поведение зависит от операционной системы.

Флаг O (Other Configuration)

• O = 1 — нужно обратиться к DHCPv6-серверу за дополнительными настройками (DNS-серверы, адрес для загрузки образа и т.д.), но без получения IP-адреса
• O = 0 — дополнительные настройки через DHCP не нужны

Если M = 1, флаг O роли не играет — вы и так получите все настройки с DHCP-сервера вместе с адресом. Флаг O важен, когда M = 0: адрес придумываете сами через SLAAC, а за опциями идете на DHCPv6.

---

Отказоустойчивость шлюза по умолчанию

Проблема в IPv4

В IPv4 не было штатного механизма переключения между маршрутизаторами. Приходилось использовать протоколы FHRP (First Hop Redundancy Protocols):

• HSRP — проприетарный (Cisco), требует лицензию
• VRRP — стандартизирован, но проблемы с патентами
• GLBP — закрытый протокол Cisco
• CARP — не стандартизирован, нет RFC

Эти протоколы создают виртуальный MAC-адрес, который обслуживает один маршрутизатор, а второй стоит в резерве. При отказе основного резервный подхватывает работу. HSRP дополнительно умеет синхронизировать таблицы трансляции NAT между маршрутизаторами.

Решение в IPv6: Anycast + NUD

В IPv6 можно повесить один и тот же IP-адрес на два маршрутизатора — это штатное поведение:

1. Оба маршрутизатора используют адрес Subnet Router Anycast — адрес с нулевым Interface ID (например, FD00::/64)
2. У каждого маршрутизатора свой MAC-адрес
3. Клиент отправляет NS на этот адрес и получает NA от одного из маршрутизаторов
4. Если маршрутизатор умирает, NUD обнаруживает это
5. Клиент повторно отправляет NS — отвечает второй маршрутизатор с другим MAC
6. Клиент обновляет запись в кэше ND и продолжает работу

На Cisco для использования Subnet Router Anycast нужно указать ключевое слово anycast:

ipv6 address FD00::/64 anycast

Ограничения

Штатный механизм IPv6 обеспечивает переключение за ~5 секунд, даже при максимально агрессивных таймерах. Для субсекундного переключения по-прежнему нужны FHRP-протоколы (HSRP v2, VRRP, GLBP), которые все поддерживают IPv6 и могут обнаружить отказ за ~50 миллисекунд.

Но для обычной компании 5-секундная задержка при аварии вполне приемлема. Это дешевый механизм отказоустойчивости без дополнительных технологий.

Альтернативный подход: разные префиксы

Можно анонсировать с каждого маршрутизатора свой префикс. Клиенты получат адреса из обоих сетей и при отказе одного маршрутизатора переключатся на другой адрес. Менее элегантно, чем anycast, но работает.

---

Безопасность Neighbor Discovery

Проблема

В IPv4 ARP легко подделать — нет проверки, кто кому что послал. Любой мог заявить: "У меня такой IP, посылайте трафик мне."

В IPv6 та же проблема: если на канальном уровне мультикаст не поддерживается и NS/NA уходят широковещанием, злоумышленник может подслушать запрос и подделать ответ.

IPsec для NDP (нецелесообразно)

Теоретически можно защитить NDP с помощью IPsec, но для этого нужно прописать Security Associations попарно между всеми узлами. В сети из 100 узлов на каждом нужно настроить 99 записей с параметрами шифрования. Автоматически согласовать ключи (через IKE) невозможно — мы еще не знаем канальный адрес соседа. Поэтому IPsec для NDP абсолютно нецелесообразен.

SEND (Secure Neighbor Discovery)

SEND — механизм, позволяющий подписывать (не шифровать) сообщения Neighbor Discovery без IPsec. Основан на CGA (Cryptographically Generated Addresses):

• IPv6-адреса генерируются на основе пары ключей (открытый + закрытый)
• Только обладатель правильного закрытого ключа может сгенерировать корректный ответ на NS
• Открытый ключ передается в опции NDP
• Цифровая подпись передается в опции RSA Signature
• Для защиты от повторной атаки используются временные метки (Timestamp) и одноразовые числа (Nonce)

Вендорские механизмы

На практике проще использовать вендорские механизмы защиты. Например, на оборудовании Cisco можно запретить прием NA от соседей, которые не могли легитимно получить заявленный IP-адрес.

---

Заключение

ICMPv6 — ключевой протокол для работы IPv6. Он объединяет в себе функции, которые в IPv4 были разнесены по нескольким протоколам (ICMP, ARP, IGMP), и добавляет новые возможности: автонастройку адресов (SLAAC), обнаружение недоступности соседей (NUD), штатную отказоустойчивость шлюза по умолчанию через anycast.

В следующем уроке разбирается DHCPv6 — не все задачи DHCP из IPv4 можно решить средствами ICMPv6, и DHCPv6 позволяет делать некоторые вещи довольно удобно.