IPv6

В темах 6–8 сетевой уровень рассматривался на примере IPv4: адрес из 32 бит, разбиение на подсети, заголовок, ARP для поиска соседа, ICMP для сообщений об ошибках, фрагментация на маршрутизаторах, таблица маршрутизации. Все эти механизмы работают и сегодня, однако одно их свойство оказалось непреодолимым ограничением: 32-битное адресное пространство содержит чуть более 4,29 млрд адресов, и к началу 2010-х годов свободные адреса в мировом реестре закончились. Протокол IP версии 6 (англ. Internet Protocol version 6, IPv6) был разработан в 1990-е годы как ответ на эту угрозу и стал стандартом Интернета в 2017 году ¹.

Было бы ошибкой считать IPv6 «тем же IPv4 с длинными адресами». Разработчики воспользовались сменой версии, чтобы пересмотреть решения, которые за двадцать лет эксплуатации IPv4 показали себя неудачными: заголовок стал фиксированной длины и лишился контрольной суммы, фрагментация переместилась с маршрутизаторов на отправителя, широковещательная рассылка исчезла и уступила место групповой, а протоколы ARP, ICMP-перенаправления и частично DHCP объединились в протокол обнаружения соседей поверх ICMPv6. Узел IPv6 способен сам построить себе глобальный адрес по объявлению маршрутизатора, без сервера адресов. Следствие для инженера: опыт IPv4 переносится на IPv6 лишь частично, и многие ошибки эксплуатации IPv6 — например, блокировка «ненужного» ICMP — возникают именно из-за механического переноса привычек.

Изложение построено так. Сначала обсуждается, почему понадобилась новая версия и что в ней изменилось принципиально. Затем рассматриваются адреса: запись, типы, адресный план и способы выбора идентификатора интерфейса. Третий раздел посвящён заголовку IPv6, цепочке расширяющих заголовков и обработке слишком больших пакетов. Четвёртый — ICMPv6 и протоколу обнаружения соседей, который заменяет ARP. Пятый — автонастройке узла: объявлениям маршрутизатора, SLAAC и DHCPv6. Завершает тему обзор маршрутизации IPv6, механизмов сосуществования с IPv4 и специфических вопросов безопасности. Примеры выводов команд получены в учебной топологии лабораторной работы 11: два хоста офиса h1 и h2, маршрутизатор r1 и сервер srv, адреса из документационного блока 2001:db8::/32 ².

Зачем понадобилась новая версия IP

Исчерпание адресов IPv4 и пределы обходных решений

Как было показано в теме 6, адреса IPv4 распределяются иерархически: организация IANA выделяет крупные блоки пяти региональным интернет-регистратурам (RIR), а те — провайдерам и организациям. Центральный пул IANA был исчерпан 3 февраля 2011 года, когда последние пять блоков /8 были разданы регистратурам. Региональные пулы закончились вслед за ним: в Азиатско-Тихоокеанском регионе (APNIC) — в апреле 2011 года, в Европе (RIPE NCC) последний блок /8 начали распределять в 2012 году, а в ноябре 2019 года регистратура объявила о полном исчерпании, в Северной Америке (ARIN) — в 2015 году.

Задолго до исчерпания стало ясно, что рост Интернета не остановится, и были предложены два направления. Первое — продлить жизнь IPv4: бесклассовая адресация CIDR (тема 6) позволила экономнее раздавать блоки, частные адреса RFC 1918 и трансляция адресов NAT (тема 14) — скрыть за одним публичным адресом целую сеть, а затем и трансляция на стороне провайдера (англ. Carrier-Grade NAT, CGNAT) — скрыть за одним адресом тысячи абонентов. Второе направление — новая версия протокола с бо́льшим адресным пространством. В 1994 году IETF выбрала проект, ставший IPv6; первая спецификация опубликована в 1995 году (RFC 1883), вторая — в 1998 году (RFC 2460), действующая — RFC 8200 (2017), имеющая статус стандарта Интернета STD 86 ¹.

Обходные решения IPv4 работают, но имеют цену. NAT разрушает сквозную адресуемость: узел за трансляцией не принимает входящие соединения без ухищрений, а протоколы, передающие адреса внутри данных, требуют специальных шлюзов. CGNAT вдобавок делит один адрес между многими абонентами, что затрудняет расследование инцидентов и работу сервисов, ограничивающих число запросов с адреса. Адреса IPv4 стали товаром со вторичным рынком. На этом фоне IPv6 предлагает адресное пространство из 2¹²⁸ ≈ 3,4·10³⁸ адресов, в котором вопрос дефицита снимается окончательно.

Что изменилось в IPv6 помимо длины адреса

Длина адреса выросла с 32 до 128 бит, но это лишь самое заметное изменение. Принципиальные отличия IPv6 от IPv4 можно сгруппировать так ¹¹⁴:

• Упрощённый заголовок фиксированной длины. Основной заголовок занимает ровно 40 байт и содержит 8 полей. Из него удалены длина заголовка, контрольная сумма и поля фрагментации; редко используемые функции вынесены в необязательные расширяющие заголовки, которые маршрутизатор, как правило, не просматривает.
• Фрагментация только у отправителя. Маршрутизатор IPv6 никогда не дробит пакет: слишком большой пакет отбрасывается, а отправителю возвращается сообщение ICMPv6 «Packet Too Big». Минимальный MTU любого канала, по которому передаётся IPv6, — 1280 байт.
• Нет широковещательной рассылки. Функции широковещания выполняют групповые (multicast) адреса, причём разрешение адресов соседей использует специальные группы, в которые входит лишь один-два узла сегмента.
• Обнаружение соседей вместо ARP. Поиск канального адреса соседа, проверка его достижимости, обнаружение маршрутизаторов, перенаправления и проверка уникальности адреса выполняются единым протоколом поверх ICMPv6.
• Автонастройка без сервера. Узел строит себе link-local адрес сам, а глобальный — по префиксу, объявленному маршрутизатором; сервер DHCPv6 нужен лишь там, где администратор хочет централизованно управлять адресами.
• Иерархия и агрегирование. Огромное пространство позволяет выдавать организациям блоки с запасом на десятилетия и строить адресный план по структуре сети, а не по нехватке адресов.

Важное следствие: IPv6 и IPv4 несовместимы на уровне пакетов. Узел, умеющий только IPv4, не может обратиться к узлу, имеющему только IPv6, без транслятора. Поэтому переход растянулся на десятилетия и опирается на механизмы сосуществования, которые рассматриваются в последнем разделе темы.

Состояние внедрения

Внедрение IPv6 шло медленно: выгоду получает сеть в целом, а затраты несёт каждый участник, которому, пока доступен IPv4 через NAT, переход не нужен. Тем не менее к середине 2020-х годов доля пользователей, обращающихся к сервисам Google по IPv6, по публичной статистике компании приблизилась к половине, а в ряде стран превышает её; мобильные операторы строят сети только на IPv6, а крупные поставщики контента поддерживают IPv6 повсеместно. Поэтому инженер обязан понимать IPv6 наравне с IPv4: в типичной сети оба протокола работают одновременно, и неисправность одного из них проявляется как «у части пользователей сайт открывается медленно».

Куда исчезли другие версии IP: от IPv5 до IPv9 и конкурс IPng

Естественный вопрос при знакомстве с IPv6: почему после четвёртой версии сразу последовала шестая, куда делись версии 5, 7, 8 и 9, и что означают упоминания «IPv8» или «IPv9» в литературе и новостях?

Номер версии протокола IP задаётся 4-битным полем Version в самом начале IP-заголовка, что допускает шестнадцать значений — от 0 до 15. Значения распределяются организацией IANA ¹⁵:

• Версии 0–3: экспериментальные протоколы межсетевого взаимодействия DARPA, разрабатывавшиеся в 1977–1979 годах в процессе разделения исходного протокола TCP на транспортный (TCP) и сетевой (IP) уровни. После завершения экспериментов эти номера были выведены из употребления, а стандартом стал IPv4 (RFC 791, версия 4).
• Версия 5 (ST / ST2 — Internet Stream Protocol): экспериментальный потоковый протокол реального времени, созданный в 1979 году (RFC 1190, обновлён как ST2 в RFC 1819 ¹⁶). В отличие от датаграммного IP, ST устанавливал ориентированные на соединение мультимедийные потоки с гарантированной полосой пропускания и бронированием ресурсов вдоль маршрута (предшественник RSVP и протоколов ATM). Пакеты ST имели в поле версии значение 5. Протокол не предназначался для замены IPv4, но номер версии 5 оказался официально занят в реестре IANA.

В начале 1990-х годов угроза исчерпания адресного пространства IPv4 и лавинообразный рост таблиц маршрутизации BGP заставили IETF инициировать конкурс IPng (IP Next Generation), зафиксированный в RFC 1752 ¹⁷. В конкурсе участвовало несколько альтернативных архитектур, каждой из которых присваивался свой номер версии:

• Версия 7 (TP/IX — The Next Internet, RFC 1475 ¹⁸): проект Роберта Ульмана (Robert Ullmann), предлагавший расширение адресов до 64 бит, замену заголовков TCP и UDP новыми версиями с 32-битными номерами портов и улучшенную обработку потоков. Позже проект эволюционировал в CATNIP.
• Версия 8 (PIP — P Internet Protocol, RFC 1621 ¹⁹): разработка Пола Фрэнсиса (Paul Francis, известного также как изобретатель концепции NAT). PIP разделял идентификацию узла и его маршрутный локатор и использовал цепочки директив пересылки для гибкой иерархической маршрутизации.
• Версия 9 (TUBA — TCP and UDP with Bigger Addresses, RFC 1347 ²⁰): предложение группы инженеров использовать уже готовый и стандартизованный Международной организацией по стандартизации (ISO) сетевой протокол CLNP (Connectionless Network Protocol, спецификация ISO 8473), поддерживающий адреса переменной длины NSAP (до 20 байт), и перенести поверх него транспортные протоколы TCP и UDP. Для TUBA был зарезервирован номер версии 9.
• Объединённый проект CATNIP (Common Architecture for the Next Internet Protocol, RFC 1707): попытка объединить лучшие черты TP/IX (версия 7), PIP (версия 8) и TUBA (версия 9) в универсальный конвергентный протокол.

Победителем отбора IPng в 1994 году стал проект SIPP (Simple Internet Protocol Plus) Стива Диринга и Боба Хиндена, объединивший концепции простого заголовка SIP с адресацией протокола IPAE. Для SIPP комитет IESG выделил свободный номер 6, ставший официальным названием нового стандарта — IPv6 ¹.

В истории сетевых технологий закрепились ещё два специфических феномена, связанных с номерами версий:

1. Первоапрельский RFC 1606 (1994 г.) «A Historical Perspective On The Usage Of IP Version Numbers» ²¹: сатирический документ, пародирующий споры вокруг версий протоколов и прогнозирующий «неизбежное исчерпание версий IP к 2143 году» из-за слишком быстрой смены стандартов от IPv4 до IPv9.
2. Китайский проект «IPv9» («Десятичная сеть» / Decimal Network): в конце 1990-х и начале 2000-х годов коммерческо-государственная группа в КНР анонсировала так называемый «китайский суверенный стандарт IPv9» с переменной длиной адреса (до 256 бит, записываемых десятичными цифрами) и собственной изолированной системой корневых серверов доменных имён. Проект не имел отношения к IETF (где номер 9 принадлежал TUBA), позиционировался как средство изоляции национального сегмента сети и был отвергнут международным инженерным сообществом как технически несовместимый с глобальным Интернетом.
3. P2P-протокол «IPv8» (проект Tribler / TU Delft): в современных академических кругах название «IPv8» иногда используется как имя собственное для децентрализованного оверлейного протокола аутентифицированных датаграмм нулевого доверия (англ. Zero-Trust authenticated datagrams). Он работает поверх транспортных протоколов UDP/IPv4/IPv6, идентифицирует узлы криптографическими ключами и строит пиринговые оверлеи с блокчейн-репутацией TrustChain, не претендуя на изменение пакетных заголовков маршрутизаторов Интернета.

Адресация IPv6

Запись адреса и правила сокращения

Адрес IPv6 записывается как восемь групп по 16 бит, каждая — четырьмя шестнадцатеричными цифрами, через двоеточие ²:

2001:0db8:000a:0001:0000:0000:0000:0100

Такая запись громоздка, поэтому допускаются два сокращения. Во-первых, ведущие нули в каждой группе можно опустить: 000a превращается в a, 0000 — в 0. Во-вторых, одну последовательность из нескольких подряд идущих нулевых групп можно заменить двумя двоеточиями ::. Применив оба правила, получаем 2001:db8:a:1::100. Сокращение :: допустимо только один раз: адрес 2001:db8::1::1 неоднозначен, поскольку нельзя определить, сколько нулевых групп скрыто в каждом из двух мест.

Свобода записи порождает проблему: один адрес может быть записан многими способами (2001:db8:0:0:1::1, 2001:db8::1:0:0:1, 2001:0DB8::1:0:0:1), что затрудняет поиск по журналам и сравнение конфигураций. RFC 5952 устанавливает каноническую форму, которой обязаны придерживаться программы при выводе адресов ³:

• ведущие нули в группе опускаются всегда;
• :: заменяет самую длинную последовательность нулевых групп; при равной длине — первую слева;
• :: не используется для одной нулевой группы: пишется 2001:db8:0:1:1:1:1:1, а не 2001:db8::1:1:1:1:1;
• шестнадцатеричные цифры записываются строчными буквами.

Рассмотрим пример. Адрес 2001:0db8:0000:0000:0001:0000:0000:0001 содержит две серии нулей по две группы. По правилу «самая длинная, при равенстве — первая» каноническая запись — 2001:db8::1:0:0:1. Проверить себя можно модулем ipaddress языка Python, который выводит адреса в форме RFC 5952:

import ipaddress
print(ipaddress.ip_address("2001:0db8:0000:0000:0001:0000:0000:0001"))
print(ipaddress.ip_address("2001:0DB8:0:0:0:0:0:0100").exploded)

2001:db8::1:0:0:1
2001:0db8:0000:0000:0000:0000:0000:0100

Префикс сети записывается так же, как в IPv4, через косую черту: 2001:db8:a:1::/64 означает, что первые 64 бита — номер сети. Отдельная сложность возникает в URL: двоеточие в нём отделяет номер порта, поэтому адрес IPv6 заключается в квадратные скобки:

http://[2001:db8:a:2::10]:8080/index.html

Типы адресов и их префиксы

Архитектура адресации IPv6 различает три вида адресов по способу доставки ². Индивидуальный (англ. unicast) адрес идентифицирует один интерфейс. Групповой (англ. multicast) — множество интерфейсов, и пакет доставляется всем членам группы. Адрес любой рассылки (англ. anycast) назначается нескольким интерфейсам, обычно разных узлов, но пакет доставляется одному из них — ближайшему с точки зрения маршрутизации. Синтаксически anycast-адрес не отличается от индивидуального: его «люборассылочность» определяется тем, что один и тот же адрес настроен в нескольких местах. Широковещательных адресов в IPv6 нет.

Тип индивидуального адреса определяется его префиксом. Основные блоки сведены в таблицу.

Локальный для канала (англ. link-local) адрес действует только в пределах одного сегмента: маршрутизатор никогда не пересылает пакеты с таким адресом получателя или отправителя в другой сегмент. Link-local адрес есть у каждого интерфейса с включённым IPv6, даже если глобального адреса нет, и именно с него узел ведёт служебный обмен: обнаружение соседей, объявления маршрутизаторов, сообщения протоколов маршрутизации. Поскольку префикс fe80::/64 одинаков на всех интерфейсах, адрес fe80::1 сам по себе не указывает, через какой интерфейс отправлять пакет. Поэтому при обращении к link-local адресу указывается идентификатор зоны (англ. zone index) — имя интерфейса после знака %:

ip netns exec h1 ping -6 -c 2 fe80::1%eth0

PING fe80::1%eth0(fe80::1%eth0) 56 data bytes
64 bytes from fe80::1%eth0: icmp_seq=1 ttl=64 time=0.098 ms
64 bytes from fe80::1%eth0: icmp_seq=2 ttl=64 time=0.057 ms

Уникальные локальные адреса (англ. Unique Local Addresses, ULA, RFC 4193) — аналог частных адресов IPv4 из RFC 1918, но с важным отличием. Организация не берёт общий для всех блок вроде 10.0.0.0/8, а генерирует случайный 40-битный глобальный идентификатор, получая префикс /48 вида fdXX:XXXX:XXXX::/48. Вероятность совпадения префиксов двух организаций ничтожна, поэтому при слиянии компаний или соединении сетей через VPN перенумерация, как правило, не требуется. ULA не маршрутизируются в Интернете и применяются для внутренних служб, которым не нужен выход наружу.

Глобальные индивидуальные адреса (англ. Global Unicast Addresses, GUA) маршрутизируются в Интернете. Сегодня IANA распределяет их из блока 2000::/3, то есть адреса начинаются с цифры 2 или 3. Блок 2001:db8::/32 зарезервирован для документации — им пользуется и настоящий курс.

Групповые адреса начинаются с ff. Следующие 4 бита — флаги, ещё 4 бита — область действия (англ. scope): 1 — интерфейс, 2 — канал, 5 — площадка, e — глобальная. Поэтому ff02::1 означает «все узлы данного канала», ff02::2 — «все маршрутизаторы канала», ff05::1:3 — «все серверы DHCPv6 площадки». Особая разновидность — групповые адреса запрашиваемого узла (англ. solicited-node), которые заменяют широковещание в протоколе обнаружения соседей; они рассматриваются в четвёртом разделе.

Наконец, каждый интерфейс IPv6 имеет одновременно несколько адресов: link-local, один или несколько глобальных (постоянный и временные), возможно ULA, а также состоит в нескольких группах. Это одно из главных отличий от IPv4, где интерфейс обычно имеет один адрес. Выбор адреса отправителя для каждого исходящего пакета выполняется по правилам RFC 6724: предпочитается адрес той же области действия, что и у получателя, не устаревший, с наибольшим общим префиксом.

Структура глобального адреса и адресный план

Глобальный индивидуальный адрес делится на три части ²: глобальный префикс маршрутизации, который выдаёт провайдер или регистратура; идентификатор подсети, которым распоряжается сама организация; идентификатор интерфейса (англ. Interface Identifier, IID), выбираемый узлом. Для всех глобальных адресов, кроме начинающихся с двоичных 000, идентификатор интерфейса имеет длину 64 бита, поэтому длина префикса сегмента локальной сети в IPv6 практически всегда равна /64. Это не рекомендация, а условие работы автонастройки: SLAAC строит адрес из 64-битного префикса и 64-битного идентификатора. Подсети длиннее /64 применяются лишь на звеньях «точка — точка» между маршрутизаторами (/127, RFC 6164) и для петлевых адресов (/128).

Структура адреса показана на рисунке ниже на примере адреса хоста h1 из лабораторной работы.

Типовые размеры выделений определяются политиками регистратур и рекомендациями IETF (RFC 6177): организация получает префикс /48, домашний абонент — от /56 до /48, отдельный сегмент — /64. Рекомендация RIPE NCC (документ RIPE-690) прямо советует выдавать бизнес-клиентам /48, а частным абонентам — /56. Посчитаем, что это означает для «Северного узла», получившего от провайдера блок 2001:db8:a::/48. На идентификатор подсети остаётся 64 − 48 = 16 бит, то есть 2¹⁶ = 65 536 подсетей /64. В каждой подсети 2⁶⁴ ≈ 1,8·10¹⁹ адресов. Задача адресного плана в IPv6, таким образом, противоположна задаче IPv4: экономить адреса не нужно, нужно сделать план читаемым и агрегируемым.

Удобный приём — кодировать структуру сети в 16 битах подсети по полубайтам, так чтобы границы совпадали с шестнадцатеричными цифрами. Например, первая цифра — площадка, вторая — назначение, две последние — номер сегмента:

Тогда все сети главного офиса агрегируются в один маршрут 2001:db8:a:1000::/52, все сети филиала — в 2001:db8:a:2000::/52, а правило межсетевого экрана «серверы главного офиса» записывается как 2001:db8:a:1100::/56. В учебной топологии лабораторной работы для краткости используются подсети 2001:db8:a:1::/64 (офис) и 2001:db8:a:2::/64 (серверная).

Идентификатор интерфейса: EUI-64, стабильные и временные адреса

Остаётся вопрос, откуда берутся младшие 64 бита адреса. Исторически первый способ — модифицированный формат EUI-64 (RFC 4291, приложение A) ². Из 48-битного MAC-адреса интерфейса строится 64-битный идентификатор: между третьим и четвёртым байтами вставляются байты ff:fe, а второй младший бит первого байта (бит U/L, «универсальный/локальный») инвертируется. Возьмём MAC-адрес хоста h1 52:54:00:11:01:10. Первый байт 0x52 = 0101 0010; после инверсии второго младшего бита получаем 0101 0000 = 0x50. Вставка ff:fe даёт 50:54:00:ff:fe:11:01:10, или в группах по 16 бит 5054:00ff:fe11:0110. Отсюда link-local адрес fe80::5054:ff:fe11:110, который действительно видим в выводе команды:

ip netns exec h1 ip -6 addr show dev eth0

2: eth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netns sw
    inet6 fe80::5054:ff:fe11:110/64 scope link
       valid_lft forever preferred_lft forever

Инверсия бита U/L объясняется удобством ручной настройки: у глобально уникального MAC-адреса производителя этот бит равен нулю, после инверсии в IID он становится единицей, а вручную назначенные короткие идентификаторы вроде ::1 получают нулевой бит, что означает «локально назначен» — и администратору не приходится писать ::200:0:0:1.

EUI-64 прост, но у него серьёзный недостаток: идентификатор интерфейса не меняется при смене сети. Ноутбук с одним и тем же MAC-адресом в офисе, кафе и дома получает адреса с одинаковыми младшими 64 битами, и любой сервер, видящий эти адреса, может отслеживать перемещения устройства. Кроме того, MAC-адрес раскрывает производителя сетевой карты, а знание OUI сужает пространство перебора при сканировании. Поэтому IETF рекомендует по умолчанию не использовать EUI-64 (RFC 8064) и предлагает два альтернативных механизма.

Стабильные семантически непрозрачные идентификаторы (RFC 7217) вычисляются как криптографическая хеш-функция от префикса сети, имени интерфейса, секретного ключа узла и счётчика попыток DAD ⁸. В одной и той же сети узел всегда получает один и тот же адрес — это удобно для журналов и правил доступа, — а при переходе в другую сеть адрес меняется непредсказуемо, и отследить устройство по нему нельзя. Временные адреса (RFC 8981) решают иную задачу: они случайны, имеют короткое время жизни (по рекомендации стандарта предпочтительное — сутки, действительное — двое суток) и периодически заменяются новыми ⁹. Узел использует их как адрес отправителя для исходящих соединений, а стабильный адрес — для входящих. В Linux выбор задаётся параметрами ядра addr_gen_mode (0 — EUI-64, 2 — стабильный по RFC 7217, 3 — случайный) и use_tempaddr (0 — временные адреса не создаются, 2 — создаются и предпочитаются для исходящих соединений) ¹³. Настольные дистрибутивы, как правило, включают временные адреса, а серверы и маршрутизаторы — нет. Вот как выглядит интерфейс хоста h2 после включения временных адресов и получения префикса от маршрутизатора:

inet6 2001:db8:a:1:ecdc:5c19:cf9c:c6a9/64 scope global temporary dynamic
   valid_lft 3596sec preferred_lft 3596sec
inet6 2001:db8:a:1:5054:ff:fe11:120/64 scope global dynamic mngtmpaddr
   valid_lft 3596sec preferred_lft 3596sec
inet6 fe80::5054:ff:fe11:120/64 scope link
   valid_lft forever preferred_lft forever

Временный адрес помечен словом temporary, а адрес, служащий шаблоном для порождения временных, — mngtmpaddr. Время жизни временного адреса здесь ограничено сверху временем жизни объявленного префикса (1 ч).

Заголовок IPv6 и обработка пакета

Основной заголовок

Основной заголовок IPv6 имеет фиксированную длину 40 байт: 8 байт служебных полей и два адреса по 16 байт ¹. Формат показан на рисунке ниже.

Назначение полей:

• Версия (англ. Version), 4 бита: число 6.
• Класс трафика (англ. Traffic Class), 8 бит: те же 6 бит DSCP и 2 бита ECN, что и в байте DSCP/ECN заголовка IPv4 (тема 7); используется для приоритизации и явного уведомления о перегрузке (тема 13).
• Метка потока (англ. Flow Label), 20 бит: отправитель помечает пакеты одного потока одинаковым значением, чтобы маршрутизаторы могли распределять потоки по равноценным путям (ECMP) без разбора заголовков транспортного уровня. Linux заполняет метку псевдослучайным значением, вычисленным из адресов и портов соединения (в захвате это видно как flowlabel 0x810f7).
• Длина полезной нагрузки (англ. Payload Length), 16 бит: число байтов после основного заголовка, включая расширяющие заголовки. В отличие от поля «Общая длина» IPv4, сам основной заголовок не учитывается.
• Следующий заголовок (англ. Next Header), 8 бит: тип заголовка, непосредственно следующего за основным. Значения те же, что в поле «Протокол» IPv4: 6 — TCP, 17 — UDP, 58 — ICMPv6, плюс номера расширяющих заголовков.
• Предел переходов (англ. Hop Limit), 8 бит: уменьшается на единицу каждым маршрутизатором; при достижении нуля пакет отбрасывается с сообщением ICMPv6 «Time Exceeded». Это прямой аналог TTL, переименованный в соответствии с реальным смыслом: счёт идёт по переходам, а не по секундам.
• Адрес отправителя и адрес получателя, по 128 бит.

Сравнение с заголовком IPv4 показывает, что изменилось по существу.

Удаление контрольной суммы делает обязательной контрольную сумму UDP: в IPv4 она могла быть нулевой, в IPv6 нулевое значение недопустимо, потому что иначе ни один уровень не защищал бы адреса от искажения (подробно о контрольной сумме и псевдозаголовке UDP — в теме 12).

Расширяющие заголовки

Функции, которые в IPv4 реализовывались опциями, в IPv6 вынесены в расширяющие заголовки (англ. extension headers), образующие цепочку: поле Next Header основного заголовка указывает тип первого расширения, поле Next Header первого расширения — тип второго, и так до заголовка транспортного уровня ¹. Стандарт определяет следующие расширяющие заголовки и рекомендуемый порядок их следования:

Принципиально, что все расширения, кроме Hop-by-Hop, обрабатывает только получатель, указанный в поле адреса назначения. Это позволило сделать пересылку на маршрутизаторе быстрой: ему достаточно просмотреть 40 байт фиксированного формата. Цепочку заголовков можно наблюдать на сообщении протокола обнаружения групп MLD, которое Linux рассылает при поднятии интерфейса:

:: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2,
   1 group record(s) [gaddr ff02::1:ff11:110 to_ex { }]

Здесь основной заголовок содержит Next Header = 0 (Hop-by-Hop), заголовок Hop-by-Hop несёт опцию Router Alert и указывает Next Header = 58 (ICMPv6). Практическое следствие для анализа трафика: фильтр icmp6 программы tcpdump проверяет лишь поле Next Header основного заголовка и такие сообщения не покажет — надо использовать более общий фильтр ip6.

Гибкость расширяющих заголовков обернулась и проблемами. Заголовок Routing типа 0 позволял отправителю указать произвольный список промежуточных узлов, что использовалось для усиления атак, и был запрещён в 2007 году (RFC 5095). Длинные цепочки расширений затрудняют работу межсетевых экранов и балансировщиков, которым нужно добраться до номеров портов, поэтому пакеты с расширяющими заголовками в Интернете нередко отбрасываются. Измерения показали, что заметная доля путей теряет пакеты с заголовками Fragment, Hop-by-Hop или Destination Options (RFC 7872). Поэтому на практике расширения используют внутри управляемых сетей (SRv6 у провайдеров, IPsec), а в Интернете их стараются избегать.

Фрагментация у отправителя и минимальный MTU

В IPv4 маршрутизатор, получивший пакет больше MTU исходящего канала, мог раздробить его (если не установлен флаг DF), и сборка выполнялась получателем (тема 7). IPv6 отказался от этой возможности: фрагментация на маршрутизаторе требует ресурсов, усложняет аппаратную пересылку, а потеря одного фрагмента губит весь пакет. Маршрутизатор IPv6 отбрасывает слишком большой пакет и посылает отправителю сообщение ICMPv6 «Packet Too Big» (тип 2) с MTU следующего канала ⁶. Отправитель запоминает уменьшенный MTU пути до данного получателя и далее либо уменьшает размер сегментов (TCP), либо фрагментирует пакеты сам, добавляя расширяющий заголовок Fragment. Этот механизм — обнаружение MTU пути (англ. Path MTU Discovery, PMTUD) — для IPv6 описан в RFC 8201 ¹² и, в отличие от IPv4, является единственным способом пропустить большой пакет через узкое звено.

Чтобы отправителю не приходилось начинать совсем вслепую, стандарт требует, чтобы каждый канал передавал пакеты IPv6 размером не менее 1280 байт; если канальный уровень не способен на это, он обязан сам фрагментировать и собирать кадры ниже уровня IP ¹. Узел, не желающий выполнять PMTUD, может просто не отправлять пакетов больше 1280 байт.

Рассмотрим числовой пример из лабораторной работы. На звене r1 — srv установлен MTU 1280 байт, на сегменте офиса — 1500. Хост h1 отправляет эхо-запрос с 1400 байтами данных. Размер пакета: 40 байт основного заголовка + 8 байт заголовка ICMPv6 + 1400 байт данных = 1448 байт, что больше 1280. Маршрутизатор r1 отбрасывает пакет и отвечает «Packet Too Big, mtu 1280». В сообщение об ошибке вкладывается начало исходного пакета — столько, чтобы сообщение не превысило минимальный MTU: 1280 − 40 − 8 = 1232 байта, поэтому длина полезной нагрузки сообщения равна 8 + 1232 = 1240 байт. Повторный запрос h1 фрагментирует сам. В первый фрагмент помещается 1280 − 40 − 8 = 1232 байта фрагментируемой части (смещение должно быть кратно 8 байтам, и 1232 = 154 · 8 подходит), во второй — оставшиеся 1408 − 1232 = 176 байт. Захват подтверждает расчёт:

2001:db8:a:1::10 > 2001:db8:a:2::10: ICMP6, echo request, id 39288, seq 1   (payload length: 1408)
2001:db8:a:1::1 > 2001:db8:a:1::10: ICMP6, packet too big, mtu 1280         (payload length: 1240)
2001:db8:a:1::10 > 2001:db8:a:2::10: frag (0x4e81cf1e:0|1232) ICMP6, echo request, id 35657, seq 1
2001:db8:a:1::10 > 2001:db8:a:2::10: frag (0x4e81cf1e:1232|176)

Запись frag (0x4e81cf1e:0|1232) означает: идентификатор фрагментированного пакета 0x4e81cf1e (32 бита против 16 в IPv4), смещение 0, длина данных 1232 байта. Сведения о сниженном MTU пути ядро хранит в кеше маршрутов и показывает командой ip -6 route get; в Linux такая запись по умолчанию устаревает через 600 с ¹³:

2001:db8:a:2::10 from :: via fe80::1 dev eth0 src 2001:db8:a:1::10 metric 1024 expires 596sec mtu 1280 pref medium

Отсюда главная эксплуатационная опасность IPv6: если сообщения Packet Too Big отфильтрованы где-то на пути, отправитель так и не узнаёт о малом MTU, и большие пакеты бесследно исчезают — возникает «чёрная дыра» PMTUD, знакомая по теме 7, но в IPv6 обойти её фрагментацией на маршрутизаторе уже нельзя. Типичный симптом — ping и установка TCP-соединения работают, а передача больших объёмов (загрузка страницы, копирование файла) зависает.

ICMPv6 и протокол обнаружения соседей

ICMPv6: сообщения об ошибках и информационные сообщения

Протокол управляющих сообщений ICMPv6 (RFC 4443) выполняет в IPv6 гораздо больше функций, чем ICMP в IPv4 ⁶. Номер протокола в поле Next Header — 58. Сообщения делятся на два класса: сообщения об ошибках (типы 0–127) и информационные (128–255). Кроме диагностики, на ICMPv6 построены протокол обнаружения соседей и протокол обнаружения групповых слушателей (англ. Multicast Listener Discovery, MLD), заменивший IGMP.

Таблица объясняет, почему перенос в IPv6 правила «ICMP не нужен, разрешим только ping» приводит к неработоспособной сети. Без NS и NA узлы не находят друг друга даже в одном сегменте, без RA не получают адреса и маршрут по умолчанию, без Packet Too Big теряют большие пакеты. Рекомендации по фильтрации ICMPv6 (RFC 4890) перечисляют сообщения, которые межсетевой экран обязан пропускать, — в лабораторной работе последствия ошибочного фильтра исследуются экспериментально.

Групповые адреса запрашиваемого узла

В IPv4 протокол ARP рассылает запрос «у кого адрес X?» широковещательно, и каждый узел сегмента обязан принять кадр, передать его операционной системе и разобрать, хотя ответить должен лишь один. В IPv6 широковещания нет, а запрос адресуется группе запрашиваемого узла (англ. solicited-node multicast address) — особому групповому адресу, построенному из искомого адреса ². Правило таково: к префиксу ff02::1:ff00:0/104 присоединяются младшие 24 бита индивидуального адреса. Узел обязан вступить в группу запрашиваемого узла для каждого своего индивидуального адреса.

Пример. У хоста h1 link-local адрес fe80::5054:ff:fe11:110; младшие 24 бита — 11:01:10, поэтому его группа — ff02::1:ff11:110. Глобальный адрес 2001:db8:a:1:5054:ff:fe11:110 порождает ту же группу, так как младшие 24 бита совпадают. Групповому адресу IPv6 соответствует групповой MAC-адрес Ethernet: к префиксу 33:33 присоединяются младшие 32 бита группы (RFC 2464). Для ff02::1:ff11:110 получается 33:33:ff:11:01:10.

Выигрыш объясняется тем, что сетевая карта фильтрует групповые кадры аппаратно: она принимает только кадры на те групповые MAC-адреса, в которые подписана операционная система. Поскольку 24 бита совпадают у разных узлов крайне редко, запрос получает и обрабатывает, как правило, ровно один узел — тот, кого ищут. Коммутаторы с поддержкой отслеживания MLD (англ. MLD snooping) идут дальше и вообще не передают такие кадры в порты, за которыми нет членов группы. Чтобы коммутаторы знали о членстве, узел при поднятии интерфейса рассылает отчёт MLDv2 на адрес ff02::16 — именно его мы видели в предыдущем разделе.

Разрешение адресов и проверка достижимости соседа

Протокол обнаружения соседей (англ. Neighbor Discovery Protocol, NDP, RFC 4861) объединяет несколько задач, решавшихся в IPv4 разными средствами ⁴: разрешение адреса IPv6 в канальный адрес (вместо ARP), проверку достижимости соседа, обнаружение маршрутизаторов и префиксов, перенаправления, обнаружение дубликатов адресов. Все сообщения NDP передаются в ICMPv6 и отправляются с Hop Limit = 255. Получатель обязан отбросить сообщение NDP, у которого Hop Limit меньше 255: такое значение доказывает, что пакет не прошёл ни через один маршрутизатор, а значит, отправлен из того же сегмента. Это простая, но эффективная защита от подделки сообщений NDP из удалённых сетей.

Разрешение адреса устроено так. Узел, которому нужно отправить пакет соседу с адресом X, но неизвестен его MAC-адрес, отправляет NS на групповой адрес запрашиваемого узла для X, вкладывая в опцию Source Link-Layer Address собственный MAC. Сосед отвечает индивидуальным NA с флагом S (англ. Solicited, «в ответ на запрос») и опцией Target Link-Layer Address. Схема обмена показана на рисунке.

Реальный обмен при первом ping хоста h1 к адресу шлюза fe80::1, захваченный на коммутаторе:

52:54:00:11:01:10 > 33:33:ff:00:00:01, ... (hlim 255, ...) fe80::5054:ff:fe11:110 > ff02::1:ff00:1:
    ICMP6, neighbor solicitation, length 32, who has fe80::1
      source link-address option (1), length 8 (1): 52:54:00:11:01:10
52:54:00:11:01:01 > 52:54:00:11:01:10, ... (hlim 255, ...) fe80::1 > fe80::5054:ff:fe11:110:
    ICMP6, neighbor advertisement, length 32, tgt is fe80::1, Flags [router, solicited, override]
      destination link-address option (2), length 8 (1): 52:54:00:11:01:01
52:54:00:11:01:10 > 52:54:00:11:01:01, ... fe80::5054:ff:fe11:110 > fe80::1: ICMP6, echo request, id 16412, seq 1
52:54:00:11:01:01 > 52:54:00:11:01:10, ... fe80::1 > fe80::5054:ff:fe11:110: ICMP6, echo reply, id 16412, seq 1

Флаги NA имеют следующий смысл: R (англ. Router) — отправитель является маршрутизатором; S — ответ на запрос; O (англ. Override) — получатель должен заменить имеющуюся у него запись о соседе. Заметим, что запрос ушёл на MAC-адрес 33:33:ff:00:00:01, построенный из младших бит fe80::1, а ответ — индивидуальный.

Результат разрешения хранится в кеше соседей (англ. neighbor cache), который в Linux просматривается той же командой ip neigh, что и таблица ARP (тема 7):

ip netns exec h1 ip -6 neigh

fe80::1 dev eth0 lladdr 52:54:00:11:01:01 router REACHABLE

Состояния записи определяет алгоритм проверки недостижимости соседа (англ. Neighbor Unreachability Detection, NUD) ⁴. Запись создаётся в состоянии INCOMPLETE, пока ответ на NS не получен. После NA она переходит в REACHABLE и остаётся в нём примерно 30 с (базовое значение ReachableTime, умноженное на случайный коэффициент от 0,5 до 1,5). Затем запись становится STALE: адрес известен, но его актуальность не подтверждена. Когда узлу понадобится отправить пакет по записи STALE, он отправляет его и переводит запись в DELAY, ожидая 5 с подтверждения «сверху» — например, ответного TCP-сегмента. Если подтверждения нет, запись переходит в PROBE, и узел посылает до трёх индивидуальных NS с интервалом 1 с; при отсутствии ответа запись удаляется (FAILED). Если же три групповых NS в состоянии INCOMPLETE остались без ответа, отправителю пакета возвращается ошибка «адрес недостижим». В отличие от ARP, NUD проверяет достижимость соседа, а не только знание его адреса, и позволяет узлу быстро обнаружить отказ маршрутизатора по умолчанию и переключиться на другой.

Сообщение Redirect (тип 137) маршрутизатор посылает узлу, когда пакет можно было отправить напрямую соседу или через другой маршрутизатор того же сегмента.

Обнаружение дубликатов адресов

Прежде чем начать пользоваться новым индивидуальным адресом — link-local, полученным через SLAAC или назначенным вручную, — узел проверяет, что адрес не занят. Эта процедура называется обнаружением дубликатов адресов (англ. Duplicate Address Detection, DAD) и описана в RFC 4862 ⁵. На время проверки адрес находится в состоянии «предварительный» (англ. tentative): узел не использует его как адрес отправителя и не отвечает на NS для него. Узел вступает в группу запрашиваемого узла и отправляет NS, в котором искомым адресом служит проверяемый, а адресом отправителя — неопределённый адрес :: (своего адреса у узла ещё нет). По умолчанию отправляется один такой NS (dad_transmits = 1), после чего узел ждёт 1 с. Если за это время пришёл NA для проверяемого адреса или чужой NS для того же адреса (другой узел проверяет тот же адрес одновременно), адрес признаётся дубликатом и не используется.

Конфликт адресов легко воспроизвести: назначим адрес 2001:db8:a:1::100 хосту h1, а через две секунды — тот же адрес хосту h2. Захват показывает DAD-запрос h2 и защиту адреса со стороны h1:

:: > ff02::1:ff00:100: ICMP6, neighbor solicitation, length 32, who has 2001:db8:a:1::100
      unknown option (14), length 8 (1):
        0x0000:  0705 1772 949f
2001:db8:a:1::100 > ff02::1: ICMP6, neighbor advertisement, length 32, tgt is 2001:db8:a:1::100, Flags [override]
      destination link-address option (2), length 8 (1): 52:54:00:11:01:10

Поскольку запрос пришёл с неопределённого адреса, h1 отвечает не индивидуально, а на группу всех узлов ff02::1, и без флага S. Опция с номером 14, которую tcpdump не умеет назвать, — случайное число (англ. nonce) из механизма улучшенного DAD (RFC 7527): по нему узел отличает собственный NS, вернувшийся к нему через петлю в сети, от чужого. В Linux он включён по умолчанию. Результат проверки на h2:

inet6 2001:db8:a:1::100/64 scope global dadfailed tentative

Адрес остался в состоянии tentative с отметкой dadfailed и не используется; ядро также пишет сообщение в системный журнал. Важно понимать ограничения DAD: проверка выполняется только при назначении адреса, поэтому узел, подключённый к сегменту позже (или вынутый кабелем на время проверки), конфликт не обнаружит. Кроме того, DAD задерживает готовность адреса примерно на секунду; в контейнерах и тестовых средах её иногда отключают параметром nodad, как сделано в лабораторной работе 12.

Автонастройка узла

Объявления маршрутизатора

В IPv4 узел получает адрес, маску, шлюз и DNS-серверы от сервера DHCP (тема 14) или из ручной настройки. В IPv6 основным источником сведений о сети служит сам маршрутизатор. Он периодически рассылает на адрес всех узлов ff02::1 объявление маршрутизатора (англ. Router Advertisement, RA, тип 134), а узел, только что поднявший интерфейс, может не ждать очередной рассылки и запросить объявление сообщением Router Solicitation (RS, тип 133) на адрес всех маршрутизаторов ff02::2 ⁴. По умолчанию узел отправляет до трёх RS с интервалом 4 с, а маршрутизатор рассылает незапрошенные RA с интервалом от 200 до 600 с.

Объявление маршрутизатора несёт сведения, которые в IPv4 приходили бы из DHCP. Ниже — RA, разосланное маршрутизатором r1 (программой dnsmasq) в лабораторной работе:

fe80::5054:ff:fe11:101 > ff02::1: ICMP6, router advertisement, length 88
   hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
     prefix info option (3), length 32 (4): 2001:db8:a:1::/64, Flags [onlink, auto], valid time 3600s, pref. time 3600s
     mtu option (5), length 8 (1):  1500
     source link-address option (1), length 8 (1): 52:54:00:11:01:01
     rdnss option (25), length 24 (3):  lifetime 3600s, addr: 2001:db8:a:2::53

Разберём содержимое по частям:

• Hop limit 64 — значение предела переходов, которое узлам рекомендуется ставить в исходящих пакетах.
• Флаги M и O (здесь оба сброшены, Flags [none]). Флаг M (англ. Managed address configuration) сообщает, что адреса выдаёт сервер DHCPv6; флаг O (англ. Other configuration) — что по DHCPv6 можно получить прочие параметры, например DNS-серверы.
• Router lifetime 1800 s — сколько секунд узел может считать отправителя маршрутизатором по умолчанию. Нулевое значение означает «я маршрутизатор, но не используйте меня по умолчанию». Предпочтение pref medium (RFC 4191) позволяет нескольким маршрутизаторам сегмента указать приоритет.
• Опция Prefix Information — префикс 2001:db8:a:1::/64 с флагами L (англ. on-link: адреса этого префикса достижимы напрямую, без маршрутизатора) и A (англ. autonomous: из префикса можно строить адрес через SLAAC), а также двумя временами жизни: действительным (англ. valid lifetime) и предпочтительным (англ. preferred lifetime).
• Опция MTU — рекомендуемый MTU канала.
• Опция Source Link-Layer Address — MAC-адрес маршрутизатора, избавляющий узлы от отдельного разрешения адреса.
• Опция RDNSS (англ. Recursive DNS Server, RFC 8106) — адреса DNS-серверов. Долгое время узлы, получившие адрес через SLAAC, не имели стандартного способа узнать DNS-сервер без DHCPv6; опция RDNSS закрыла этот пробел.

Обратим внимание на адрес отправителя: RA всегда отправляется с link-local адреса маршрутизатора, и именно этот адрес узел запишет как следующий переход маршрута по умолчанию. Маршрутизаторы IPv6 и их соседи общаются link-local адресами, и это обеспечивает устойчивость: при перенумерации сети (смене глобального префикса провайдером) маршруты по умолчанию на хостах остаются верными.

SLAAC: автонастройка адреса без сохранения состояния

Получив RA с префиксом, у которого установлен флаг A, узел строит адрес самостоятельно. Этот механизм — автонастройка адреса без сохранения состояния (англ. Stateless Address Autoconfiguration, SLAAC, RFC 4862) ⁵ — называется так потому, что маршрутизатор не хранит сведений о том, какие адреса заняты: он лишь объявляет префикс, а уникальность адреса каждый узел проверяет сам через DAD. Последовательность шагов показана на рисунке.

Пошагово:

1. При поднятии интерфейса узел строит link-local адрес fe80::/64 + идентификатор интерфейса и выполняет для него DAD.
2. Узел отправляет RS на ff02::2 с link-local адреса.
3. Маршрутизатор отвечает RA. Узел добавляет маршрут по умолчанию через link-local адрес маршрутизатора и маршрут к префиксу (флаг L).
4. Для каждого префикса с флагом A длиной 64 бита узел строит адрес «префикс + идентификатор интерфейса» и выполняет DAD.
5. Если включены временные адреса, узел дополнительно строит временный адрес со случайным идентификатором.

Результат автонастройки хоста h1 в лабораторной работе:

ip netns exec h1 ip -6 addr show dev eth0
ip netns exec h1 ip -6 route

inet6 2001:db8:a:1:5054:ff:fe11:110/64 scope global dynamic
   valid_lft 3597sec preferred_lft 3597sec
inet6 fe80::5054:ff:fe11:110/64 scope link
   valid_lft forever preferred_lft forever

2001:db8:a:1::/64 dev eth0 proto kernel metric 256 expires 3596sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::5054:ff:fe11:101 dev eth0 proto ra metric 1024 expires 1796sec hoplimit 64 pref medium

Слово dynamic и отсчитываемые времена жизни показывают, что адрес получен автоматически и будет жить, пока маршрутизатор продолжает объявлять префикс. Маршрут по умолчанию помечен proto ra и истекает через router lifetime. Два времени жизни адреса определяют его состояния. Пока не истекло предпочтительное время, адрес «предпочтительный» и используется для новых соединений. После него, но до истечения действительного времени, адрес становится «устаревшим» (англ. deprecated): уже установленные соединения продолжают им пользоваться, но новые выбирают другой адрес. По истечении действительного времени адрес удаляется. Этот механизм позволяет плавно перенумеровать сеть: маршрутизатор начинает объявлять новый префикс, а у старого объявляет нулевое предпочтительное время, и узлы постепенно переходят на новые адреса без разрыва существующих соединений.

Маршрутизатор сам не должен строить себе адреса по чужим RA и не должен принимать маршрут по умолчанию от соседних маршрутизаторов. В Linux это обеспечивается автоматически: при включённой пересылке (forwarding = 1) параметр accept_ra = 1 игнорируется, и объявления обрабатываются, только если явно задано accept_ra = 2 ¹³ — этот режим нужен, например, домашнему маршрутизатору, получающему адрес от провайдера.

DHCPv6 с сохранением состояния и без него

Протокол динамической настройки узла для IPv6 (англ. Dynamic Host Configuration Protocol for IPv6, DHCPv6, RFC 8415) работает поверх UDP: клиент использует порт 546, сервер — 547 ⁷. Клиент обращается к серверам по групповому адресу ff02::1:2 со своего link-local адреса, поэтому, в отличие от DHCP для IPv4, широковещание не требуется. Клиент и сервер идентифицируют себя уникальным идентификатором DUID (англ. DHCP Unique Identifier), а не MAC-адресом.

Возможны два режима. В режиме с сохранением состояния (англ. stateful), который включается флагом M в RA, сервер выдаёт клиенту адреса и учитывает их аренду — так же, как DHCP в IPv4. Обмен состоит из четырёх сообщений Solicit, Advertise, Request и Reply (или двух при быстром режиме Rapid Commit). В режиме без сохранения состояния (англ. stateless), который включается флагом O, адрес клиент строит через SLAAC, а у сервера запрашивает только прочие параметры двумя сообщениями Information-Request и Reply. В лабораторной работе такой сервер DHCPv6 сообщает клиенту адрес DNS-сервера; в его журнале видно содержимое ответа:

dnsmasq-dhcp: 6099700 sent size: 10 option:  1 client-id  00:03:00:01:52:54:00:11:01:10
dnsmasq-dhcp: 6099700 sent size: 14 option:  2 server-id  00:01:00:01:32:5f:69:31:00:00:00:00:00:00
dnsmasq-dhcp: 6099700 sent size: 16 option: 23 dns-server  2001:db8:a:2::53
dnsmasq-dhcp: 6099700 sent size:  4 option: 32 information-refresh-time  1h

Важная особенность: DHCPv6 не сообщает клиенту маршрут по умолчанию и длину префикса. Маршрутизатор по умолчанию узел всегда узнаёт из RA, поэтому сеть с DHCPv6 без объявлений маршрутизатора работать не будет. Это частая ошибка при переносе опыта IPv4.

Третья функция DHCPv6 — делегирование префиксов (англ. Prefix Delegation, PD): маршрутизатор провайдера выдаёт абонентскому маршрутизатору не адрес, а целый префикс (например, /56), который тот делит на подсети /64 для своих сегментов. Именно так домашний маршрутизатор получает адресное пространство для домашней сети.

Выбор между SLAAC и DHCPv6 — вопрос политики. SLAAC проще и поддерживается всеми операционными системами. Stateful DHCPv6 даёт централизованный учёт адресов, но поддерживается не всеми клиентами: в частности, Android не реализует получение адресов по DHCPv6, опираясь на SLAAC. Поэтому распространённая конфигурация офисной сети — SLAAC с опцией RDNSS и, при необходимости, stateless DHCPv6.

Маршрутизация, сосуществование с IPv4 и безопасность

Маршрутизация IPv6

Принципы маршрутизации IPv6 те же, что изложены в темах 8–10: таблица с правилом наибольшего совпадения префикса, маршрут по умолчанию ::/0, статические маршруты и протоколы динамической маршрутизации. В Linux маршрутизатор IPv6 включается параметром net.ipv6.conf.all.forwarding = 1, а таблица просматривается командой ip -6 route. Отличие, бросающееся в глаза, — следующий переход обычно указывается link-local адресом с обязательным указанием интерфейса:

ip -n srv -6 route add default via fe80::1 dev eth0
ip netns exec h1 ip -6 route get 2001:db8:a:2::10

2001:db8:a:2::10 from :: via fe80::5054:ff:fe11:101 dev eth0 proto ra src 2001:db8:a:1:5054:ff:fe11:110 metric 1024 hoplimit 64 pref medium

Утилиты ping -6 и tracepath -6 работают так же, как их аналоги для IPv4; последняя дополнительно сообщает MTU пути:

 1?: [LOCALHOST]                        0.019ms pmtu 1500
 1:  2001:db8:a:1::1                                       0.064ms
 2:  2001:db8:a:2::10                                      0.032ms reached
     Resume: pmtu 1500 hops 2 back 2

Протоколы динамической маршрутизации получили версии для IPv6. OSPFv3 (RFC 5340) сохраняет алгоритм и типы областей OSPFv2 (тема 9), но работает поверх IPv6, использует для соседства link-local адреса и отделяет топологию от адресации: адресные префиксы вынесены в отдельные типы LSA. BGP (тема 10) переносит маршруты IPv6 благодаря многопротокольным расширениям MP-BGP (RFC 4760), в которых атрибуты MP_REACH_NLRI и MP_UNREACH_NLRI несут префиксы любого семейства адресов; одна BGP-сессия поверх IPv4 может передавать и маршруты IPv6.

Двойной стек и Happy Eyeballs

Основная стратегия перехода — двойной стек (англ. dual stack): узлы и маршрутизаторы одновременно поддерживают IPv4 и IPv6, имеют адреса обеих версий, а приложение выбирает протокол для каждого соединения. Выбор начинается с DNS: для имени сервера запрашиваются записи A (IPv4) и AAAA (IPv6) (тема 15), и стандартный алгоритм выбора адреса (RFC 6724) по умолчанию предпочитает IPv6.

Строгое предпочтение IPv6 создало проблему: если у клиента есть адрес IPv6, но путь IPv6 к серверу неисправен (неверный маршрут, чёрная дыра PMTUD), приложение ждёт таймаута соединения — десятки секунд — и лишь затем пробует IPv4. Пользователь видит «очень медленный Интернет». Решением стал алгоритм Happy Eyeballs (RFC 8305) ¹⁰. Клиент начинает соединение по IPv6 и, если за короткое время (рекомендуемое значение — 250 мс) оно не установлено, параллельно начинает соединение по IPv4; используется то, которое установится первым, а второе закрывается. Тем самым неисправность одного из протоколов стоит пользователю не более четверти секунды, а не десятков секунд. Алгоритм реализован в браузерах, в curl и в системных библиотеках macOS и iOS. Обратная сторона медали — Happy Eyeballs маскирует неисправности IPv6: сеть годами может работать с неисправным IPv6, и никто этого не замечает, пока не придётся отказаться от IPv4.

Трансляция и туннели

Когда у части узлов есть только один протокол, двойного стека недостаточно, и применяются трансляция или туннелирование.

Трансляция NAT64 (RFC 6146) позволяет клиентам, имеющим только IPv6, обращаться к серверам, имеющим только IPv4 ¹¹. Шлюз NAT64 владеет префиксом /96, обычно общеизвестным 64:ff9b::/96 (RFC 6052), и каждому адресу IPv4 сопоставляет адрес IPv6 вида «префикс + 32 бита адреса IPv4». Например, адресу 192.0.2.33 (в шестнадцатеричной записи c0.00.02.21) соответствует 64:ff9b::c000:221. Клиент отправляет пакет на этот адрес, шлюз переписывает заголовок IPv6 в заголовок IPv4, подставляя в качестве отправителя свой адрес IPv4 и запоминая соответствие портов — так же, как NAPT в теме 14. Чтобы клиент узнал синтетический адрес, используется DNS64 (RFC 6147): DNS-сервер, не найдя для имени записи AAAA, синтезирует её из записи A. Связка NAT64/DNS64 широко применяется мобильными операторами.

Сочетание NAT64/DNS64 не помогает приложениям, которые обращаются к литеральным адресам IPv4 или используют API сокетов только для IPv4. Для них предназначен механизм 464XLAT (RFC 6877): на самом клиентском устройстве работает транслятор без состояния CLAT, переводящий пакеты IPv4 приложения в IPv6, а в сети оператора — шлюз NAT64 (PLAT), переводящий их обратно в IPv4. Приложение видит обычный IPv4-адрес, а сеть оператора остаётся чистой IPv6-сетью. Именно так работает доступ к IPv4 у абонентов многих мобильных операторов.

Туннелирование решает обратную задачу: соединить островки IPv6 через сеть, работающую только по IPv4. В туннеле 6in4 (RFC 4213) пакет IPv6 целиком помещается в пакет IPv4 с номером протокола 41; концы туннеля настраиваются вручную. Автоматические механизмы 6to4 и Teredo оказались ненадёжными и выведены из употребления (6to4 — RFC 7526). Общие вопросы туннелей — накладные расходы, MTU, инкапсуляция — рассматриваются в теме 19.

Безопасность IPv6

IPv6 не делает сеть ни более, ни менее защищённой сам по себе, но меняет набор угроз. Распространённое заблуждение — «IPv6 безопаснее, потому что в нём обязательный IPsec»: в ранних спецификациях поддержка IPsec действительно требовалась, но использовать его никто не обязывал, а сейчас требование ослаблено до рекомендации.

Наиболее характерная угроза локального сегмента — подложные объявления маршрутизатора (англ. rogue RA). Любой узел сегмента может разослать RA и объявить себя маршрутизатором по умолчанию, перехватывая трафик соседей, — нередко без злого умысла, по ошибке конфигурации. Аналогично ARP-спуфингу в IPv4 (тема 18), возможна подделка NA. Защита строится на коммутаторе: функция RA Guard (RFC 6105) пропускает RA только с портов, к которым подключены настоящие маршрутизаторы, а отслеживание NDP сверяет адреса в NA с привязками. Криптографическая защита NDP SEND (RFC 3971) существует, но почти не реализована. Злоумышленники пытались обходить RA Guard, пряча RA за цепочкой расширяющих заголовков, поэтому реализации должны просматривать всю цепочку (RFC 7113).

Огромное адресное пространство меняет разведку. Перебрать подсеть /64 невозможно: при скорости миллион проб в секунду на это ушло бы 2⁶⁴ / 10⁶ ≈ 1,8·10¹³ с, то есть около 585 тысяч лет. Однако сканирование не исчезло, а изменилось (RFC 7707): атакующий ищет адреса с предсказуемыми идентификаторами (::1, ::2, адреса EUI-64 с известным OUI производителя, встроенные адреса IPv4), извлекает адреса из DNS, журналов и заголовков почты. Поэтому стабильные непрозрачные идентификаторы RFC 7217 полезны не только для приватности, но и для защиты от разведки.

Наконец, межсетевой экран обязан учитывать особенности протокола. Политика должна пропускать ICMPv6-сообщения NDP внутри сегмента и сообщения Packet Too Big из Интернета (RFC 4890), иначе сеть перестанет работать. А там, где IPv6 якобы «не используется», он почти наверняка работает: современные операционные системы включают его по умолчанию и строят link-local адреса, поэтому сегмент без контроля IPv6 открыт для подложных RA. Типичная ошибка — настроить фильтрацию для IPv4 (iptables) и забыть про IPv6 (ip6tables); в nftables семейство inet позволяет описать политику для обеих версий одной таблицей (тема 18).

Итоги темы

IPv6 появился как ответ на исчерпание адресов IPv4, но стал не просто расширением адреса, а переработкой сетевого уровня с учётом двадцатилетнего опыта. Адрес длиной 128 бит записывается восемью шестнадцатеричными группами с канонической сокращённой формой и делится на префикс маршрутизации, идентификатор подсети и 64-битный идентификатор интерфейса. Каждый интерфейс имеет несколько адресов разных областей действия — link-local, глобальные, временные, — а адресный план организации строится не из экономии, а из удобства агрегирования: блок /48 содержит 65 536 подсетей /64.

Основной заголовок упрощён до 40 байт фиксированного формата; редкие функции вынесены в цепочку расширяющих заголовков, которые обрабатывает только получатель. Маршрутизаторы больше не фрагментируют пакеты: отправитель узнаёт MTU пути из сообщений Packet Too Big и при необходимости фрагментирует сам, а каждый канал обязан передавать пакеты размером не менее 1280 байт. Отсюда следует первое практическое правило IPv6: ICMPv6 нельзя фильтровать по образцу ICMP для IPv4.

Протокол обнаружения соседей поверх ICMPv6 объединил функции ARP, обнаружения маршрутизаторов, перенаправлений и проверки уникальности адресов. Широковещание заменено групповыми адресами запрашиваемого узла, а проверка Hop Limit = 255 гарантирует, что сообщения NDP пришли из своего сегмента. Объявления маршрутизатора сообщают узлам префиксы, маршрут по умолчанию, MTU и DNS-серверы; узел строит себе глобальный адрес через SLAAC и проверяет его уникальность процедурой DAD, а DHCPv6 применяется там, где нужен централизованный учёт или делегирование префиксов.

Переход с IPv4 на IPv6 опирается на двойной стек с алгоритмом Happy Eyeballs, трансляцию NAT64/DNS64 и 464XLAT для сетей, где остался только IPv6, и туннели для островков IPv6 в IPv4-сети. Безопасность IPv6 требует внимания к локальному сегменту (подложные RA, RA Guard) и к фильтрации ICMPv6.

Тема завершает рассмотрение сетевого уровня. Сетевой уровень доставляет пакет до узла, но не до конкретной программы на нём и не гарантирует доставку. Как несколько приложений одного узла делят сетевой интерфейс, как поверх ненадёжных датаграмм строится надёжный поток байтов и как программа обращается к сети через сокеты — предмет темы 12, открывающей транспортный уровень.

Литература

1. Deering S., Hinden R. Internet Protocol, Version 6 (IPv6) Specification. — RFC 8200, IETF, 2017. https://www.rfc-editor.org/rfc/rfc8200
2. Hinden R., Deering S. IP Version 6 Addressing Architecture. — RFC 4291, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4291
3. Kawamura S., Kawashima M. A Recommendation for IPv6 Address Text Representation. — RFC 5952, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5952
4. Narten T., Nordmark E., Simpson W., Soliman H. Neighbor Discovery for IP version 6 (IPv6). — RFC 4861, IETF, 2007. https://www.rfc-editor.org/rfc/rfc4861
5. Thomson S., Narten T., Jinmei T. IPv6 Stateless Address Autoconfiguration. — RFC 4862, IETF, 2007. https://www.rfc-editor.org/rfc/rfc4862
6. Conta A., Deering S., Gupta M. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. — RFC 4443, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4443
7. Mrugalski T., Siodelski M., Volz B., Yourtchenko A., Richardson M., Jiang S., Lemon T., Winters T. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). — RFC 8415, IETF, 2018. https://www.rfc-editor.org/rfc/rfc8415
8. Gont F. A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). — RFC 7217, IETF, 2014. https://www.rfc-editor.org/rfc/rfc7217
9. Gont F., Krishnan S., Narten T., Draves R. Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6. — RFC 8981, IETF, 2021. https://www.rfc-editor.org/rfc/rfc8981
10. Schinazi D., Pauly T. Happy Eyeballs Version 2: Better Connectivity Using Concurrency. — RFC 8305, IETF, 2017. https://www.rfc-editor.org/rfc/rfc8305
11. Bagnulo M., Matthews P., van Beijnum I. Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. — RFC 6146, IETF, 2011. https://www.rfc-editor.org/rfc/rfc6146
12. McCann J., Deering S., Mogul J., Hinden R. Path MTU Discovery for IP version 6. — RFC 8201, IETF, 2017. https://www.rfc-editor.org/rfc/rfc8201
13. The Linux Kernel Documentation. IP Sysctl. — 2025. https://docs.kernel.org/networking/ip-sysctl.html
14. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
15. IANA. Internet Protocol Version Numbers. Registry. — 2025. https://www.iana.org/assignments/version-numbers/version-numbers.xhtml
16. Delgrossi L., Berger L. Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+. — RFC 1819, IETF, 1995. https://www.rfc-editor.org/rfc/rfc1819
17. Bradner S., Mankin A. The Recommendation for the IP Next Generation Protocol. — RFC 1752, IETF, 1995. https://www.rfc-editor.org/rfc/rfc1752
18. Ullmann R. TP/IX: The Next Internet. — RFC 1475, IETF, 1993. https://www.rfc-editor.org/rfc/rfc1475
19. Francis P. A Territorial Addressing and Routing Architecture. — RFC 1621, IETF, 1994. https://www.rfc-editor.org/rfc/rfc1621
20. Callon R. TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Protocol Next Generation. — RFC 1347, IETF, 1992. https://www.rfc-editor.org/rfc/rfc1347
21. Onions J. A Historical Perspective On The Usage Of IP Version Numbers. — RFC 1606, IETF, 1994. https://www.rfc-editor.org/rfc/rfc1606

Дополнительные материалы

Вопросы для самопроверки

1. Запишите в канонической форме RFC 5952 адрес 2001:0DB8:0000:0000:0000:0001:0000:0000 и объясните, почему :: нельзя использовать дважды.
2. Сколько подсетей /64 содержит блок /56, выданный домашнему абоненту? Сколько подсетей /64 в блоке /48?
3. Постройте link-local адрес EUI-64 для интерфейса с MAC-адресом 00:1a:2b:3c:4d:5e. Зачем инвертируется бит U/L?
4. Какую группу запрашиваемого узла и какой групповой MAC-адрес использует узел, разрешающий адрес 2001:db8:a:1::abcd:1234?
5. Какие поля заголовка IPv4 отсутствуют в основном заголовке IPv6 и почему без них можно обойтись?
6. Пакет IPv6 из 2000 байт (с заголовком 40 байт) нужно передать по пути с MTU 1280. Кто его фрагментирует, сколько получится фрагментов и сколько байтов данных будет в каждом?
7. Почему межсетевой экран, пропускающий из ICMPv6 только эхо-запросы и ответы, ломает связность даже внутри одного сегмента?
8. Узел получил RA с флагами M=0, O=1 и префиксом с флагом A=1. Как он получит адрес, маршрут по умолчанию и адрес DNS-сервера?
9. Почему DHCPv6 не может заменить RA полностью?
10. Что происходит с адресом, у которого истекло предпочтительное время жизни, но не истекло действительное? Как это используется при смене провайдера?
11. Чем стабильный идентификатор RFC 7217 отличается от EUI-64 и от временного идентификатора RFC 8981? Какую угрозу закрывает каждый из них?
12. Клиент с двойным стеком открывает сайт, у которого неисправен путь IPv6. Что увидит пользователь без Happy Eyeballs и с ним?
13. Как клиент, имеющий только IPv6, получает доступ к серверу с адресом 198.51.100.7 через NAT64/DNS64? Какой адрес он увидит в ответе DNS при общеизвестном префиксе?
14. Почему подложное объявление маршрутизатора — одна из главных угроз сегмента IPv6 и как от него защищаются?
15. Почему после IPv4 был принят именно стандарт IPv6, какие проекты разрабатывались под номерами версий 5, 7, 8 и 9 (ST2, TP/IX, PIP, TUBA) и почему китайский «IPv9» не является международным стандартом IETF?

Глоссарий темы

Шпаргалка по инструментам

Адреса, маршруты, соседи:

ip -6 addr show dev eth0                  # адреса и флаги: tentative, dadfailed, temporary, deprecated
ip addr add 2001:db8:a:1::10/64 dev eth0  # статический адрес (nodad — без проверки дубликата)
ip -6 route                               # таблица маршрутизации IPv6
ip -6 route add default via fe80::1 dev eth0
ip -6 route get 2001:db8:a:2::10          # маршрут, адрес отправителя, MTU пути из кеша
ip -6 route flush cache                   # забыть сведения PMTUD
ip -6 neigh                               # кеш соседей и состояния NUD
ip -6 neigh flush dev eth0
ip maddr show dev eth0                    # групповые адреса интерфейса

Диагностика:

ping -6 -c 3 2001:db8:a:2::10
ping -6 fe80::1%eth0                      # link-local — с указанием интерфейса
ping -6 -s 1400 -M do 2001:db8:a:2::10    # запретить фрагментацию у отправителя
tracepath -6 -n 2001:db8:a:2::10          # путь и MTU пути
ss -6 -tan                                # TCP-сокеты IPv6

Параметры ядра (sysctl net.ipv6.conf.ИНТЕРФЕЙС.ПАРАМЕТР, а также all и default):

Захват и фильтры:

tcpdump -ni eth0 -e -vv ip6                         # весь IPv6 с MAC-адресами
tcpdump -ni eth0 'icmp6 and ip6[40] >= 133 and ip6[40] <= 137'   # NDP (без расширяющих заголовков)
tcpdump -ni eth0 'udp port 546 or udp port 547'     # DHCPv6

Фильтры отображения Wireshark: icmpv6.type == 134 (RA), icmpv6.type in {135 136} (NS/NA), icmpv6.type == 2 (Packet Too Big), ipv6.fragment, dhcpv6, ipv6.addr == 2001:db8:a:1::10.

Python, модуль ipaddress:

import ipaddress
net = ipaddress.ip_network("2001:db8:a::/48")
print(net.num_addresses, len(list(net.subnets(new_prefix=52))))
print(ipaddress.ip_address("2001:db8::1").exploded)
print(ipaddress.ip_address("fe80::1").is_link_local)

Что почитать и посмотреть

1. RFC 8200. Internet Protocol, Version 6 (IPv6) Specification — действующая спецификация протокола. Короткий документ, который стоит прочитать целиком: формат заголовка, правила обработки расширений, фрагментация, требование к MTU 1280.
2. RFC 4861. Neighbor Discovery for IP version 6 — главный документ темы: форматы RS/RA/NS/NA/Redirect, алгоритм NUD и константы протокола (раздел 10). После лабораторной работы читается легко.
3. RFC 4862. IPv6 Stateless Address Autoconfiguration — SLAAC и DAD, времена жизни адресов, правила обработки префиксов.
4. RFC 4890. Recommendations for Filtering ICMPv6 Messages in Firewalls — таблицы «что пропускать обязательно, что можно, что нельзя»; основа правильной политики межсетевого экрана для IPv6.
5. RFC 7707. Network Reconnaissance in IPv6 Networks — как ищут узлы в огромном адресном пространстве; хорошее обоснование стабильных непрозрачных идентификаторов.
6. The Linux Kernel Documentation. IP Sysctl — описание всех параметров net.ipv6.conf.*, использованных в работе.
7. Hagen S. IPv6 Essentials. 3rd ed. — O'Reilly, 2014. Подробное учебное пособие по IPv6 с разбором захватов и вопросами внедрения.
8. Google IPv6 Statistics — ежедневная доля пользователей, обращающихся к Google по IPv6, по странам; наглядная картина внедрения.
9. RIPE NCC. IPv6 Address Allocation and Assignment Policy и документ RIPE-690 — практические рекомендации провайдерам по выдаче префиксов абонентам (/48, /56), стабильности префиксов и адресному плану.
10. APNIC Blog, рубрика IPv6 — статьи об измерениях внедрения IPv6, проблемах расширяющих заголовков и опыте операторов.
11. Википедия. IPv6 transition mechanism — обзор механизмов перехода (6in4, 6rd, NAT64, 464XLAT, DS-Lite, MAP) со ссылками на RFC.

Углубление (по желанию)

Почему IPv6 так долго внедряется

Спецификация IPv6 появилась в 1995 году, а доля пользователей IPv6 превысила 10 % лишь в конце 2010-х. Причина не техническая, а экономическая: проблема коллективного действия. Сеть, перешедшая на IPv6 первой, несёт затраты (обновление оборудования, обучение, двойная эксплуатация), но не получает выгоды, пока контент и клиенты остаются на IPv4. NAT при этом снимал остроту дефицита для каждого отдельного участника. Перелом наступил, когда затраты на IPv4 стали ощутимыми: мобильным операторам с десятками миллионов абонентов не хватало даже частного пространства 10.0.0.0/8 для CGNAT, а цена адресов IPv4 на вторичном рынке выросла в разы. Именно мобильные операторы и крупные поставщики контента — те, для кого экономика IPv4 хуже всего, — и стали двигателями внедрения. Корпоративные сети отстают сильнее всего: внутри организации NAT и частные адреса работают, и выгоды от перехода не видно.

Сеть только на IPv6 и параметр «IPv6-only preferred»

Двойной стек удваивает работу эксплуатации: два адресных плана, две политики межсетевого экрана, две версии каждой проблемы. Поэтому операторы и крупные организации (известный пример — внутренняя сеть Microsoft) переходят к сетям только на IPv6 с доступом к IPv4-ресурсам через NAT64. Мешают переходу устройства, не способные работать без IPv4. Компромиссом стал параметр DHCP для IPv4 «IPv6-only preferred» (опция 108, RFC 8925): клиент, умеющий работать только с IPv6 и 464XLAT, сообщает об этом серверу DHCPv4, и тот не выдаёт ему адрес IPv4, а старые устройства получают адрес как обычно. Так в одном сегменте сосуществуют современные клиенты без IPv4 и унаследованные устройства. Дополнительно опция PREF64 в RA (RFC 8781) сообщает узлам префикс NAT64, что избавляет их от необходимости угадывать его через DNS64.

Сегментная маршрутизация SRv6

Расширяющий заголовок Routing, скомпрометированный в 2007 году, получил вторую жизнь в виде сегментной маршрутизации поверх IPv6 (SRv6, RFC 8754 и RFC 8986). Источник — обычно пограничный маршрутизатор провайдера — помещает в заголовок Segment Routing список адресов IPv6, каждый из которых означает не просто узел, а инструкцию: «пройти через этот узел», «передать в такую-то VPN», «применить такую-то функцию». Транзитные маршрутизаторы пересылают пакет по обычному адресу назначения, а очередной узел списка выполняет инструкцию и подставляет следующий адрес. Так провайдер управляет путями трафика и строит VPN без отдельного протокола меток MPLS (тема 19). Пример показывает, как идея, отвергнутая в открытом Интернете, оказывается полезной внутри одного управляемого домена, где расширения IPv6 не отбрасываются по пути.

Лабораторная работа 11. IPv6 в учебной сети

• Раздел курса: тема 11 «IPv6»

Введение

В лабораторных работах 6–8 строилась и исследовалась сеть IPv4: адресный план, ARP и ICMP, маршрутизация через Linux-маршрутизатор. В настоящей работе к той же по устройству сети добавляется IPv6, и сеть начинает работать в режиме двойного стека. Задача работы — увидеть своими глазами механизмы, которые в теме 11 описаны как главные отличия IPv6: адреса, которые узел строит себе сам; обнаружение соседей через групповые адреса вместо широковещательного ARP; проверку уникальности адреса; автонастройку по объявлениям маршрутизатора; отказ маршрутизатора от фрагментации и сообщения Packet Too Big.

Почти каждый шаг работы сопровождается захватом трафика. Перед экспериментом требуется записать в журнал предсказание: какой адрес получит интерфейс, на какой MAC-адрес уйдёт запрос, какое состояние будет у записи соседа. После эксперимента предсказание сравнивается с наблюдением, и любое расхождение объясняется.

Работа состоит из базовой и продвинутой частей. Базовая часть (части 1–6) составляет основу работы: link-local адреса, NDP, DAD, глобальные адреса и маршрутизация, SLAAC и DHCPv6, поиск неисправности, вызванной неверной фильтрацией ICMPv6. Продвинутая часть (части 7–8) — по желанию: MTU 1280 и Packet Too Big, стабильные и временные идентификаторы интерфейса.

Цель работы

Освоить настройку и диагностику IPv6 в локальной сети с маршрутизатором и научиться объяснять по захвату трафика работу протокола обнаружения соседей и автонастройки адресов.

После выполнения работы можно будет:

• вычислить link-local адрес EUI-64 и группу запрашиваемого узла по MAC-адресу и проверить вычисление командами ip;
• объяснить по захвату обмен NS/NA при разрешении адреса и при обнаружении дубликата, назвать адреса отправителя и получателя на уровнях IP и Ethernet;
• назначить глобальные адреса IPv6, настроить маршрут по умолчанию через link-local адрес шлюза и проверить путь ping -6, tracepath -6, ip -6 route get;
• включить рассылку объявлений маршрутизатора, разобрать содержимое RA (флаги M/O, префикс, времена жизни, RDNSS) и объяснить, как из него получен адрес узла;
• найти и устранить неисправность, вызванную фильтрацией ICMPv6;
• наблюдать сообщение Packet Too Big и фрагментацию у отправителя и рассчитать размеры фрагментов (продвинутая часть).

Теоретический минимум

См. тему 11, разделы «Адресация IPv6», «Заголовок IPv6 и обработка пакета», «ICMPv6 и протокол обнаружения соседей», «Автонастройка узла». Ниже — сжатая справка.

Учебная топология: два хоста офиса подключены к программному коммутатору sw, маршрутизатор r1 соединяет офис с серверной, где стоит сервер srv.

  h1 ─┐
      ├─ sw (мост br0) ── r1 ───────────── srv
  h2 ─┘                  eth0      eth1

  сегмент «офис»                      сегмент «серверная»
  2001:db8:a:1::/64, 10.11.1.0/24     2001:db8:a:2::/64, 10.11.2.0/24

Команды работы:

Полезные фильтры. Захвата (tcpdump, BPF): ip6 — весь IPv6; icmp6 — ICMPv6 без расширяющих заголовков (сообщения MLD с заголовком Hop-by-Hop в него не попадут); ip6 and not icmp6 — всё, кроме ICMPv6. Отображения (Wireshark): icmpv6.type == 135 || icmpv6.type == 136 — NS и NA; icmpv6.type == 134 — RA; icmpv6.type == 2 — Packet Too Big; ipv6.fragment — фрагменты; dhcpv6 — DHCPv6.

Типы ICMPv6, встречающиеся в работе: 133 — RS, 134 — RA, 135 — NS, 136 — NA, 143 — отчёт MLDv2, 128/129 — эхо-запрос и ответ, 2 — Packet Too Big.

Перечень оснащения

• ОС: Ubuntu 24.04 (физическая или виртуальная машина либо WSL2).
• Пакеты (большинство установлено в лабораторной работе 1):

sudo apt install iproute2 iputils-ping iputils-tracepath tcpdump tshark wireshark \
     dnsmasq-base nftables isc-dhcp-client

• Архив окружения lr-env: скрипты up.sh, down.sh, ra.sh, break-icmpv6.sh, dhcp6-show.sh и README.md с описанием.
• Права администратора (sudo): пространства имён и захват трафика требуют root.
• Ресурсы машины — минимальные.

Порядок выполнения работы

1. Распакуйте архив, перейдите в каталог lr-env, сделайте скрипты исполняемыми: chmod +x *.sh.
2. Поднимите топологию: sudo ./up.sh. Скрипт сначала разбирает старую топологию, поэтому его можно запускать повторно, когда нужно вернуться к исходному состоянию.
3. Для краткости определите функцию оболочки и пользуйтесь ею во всех частях:

nx() { sudo ip netns exec "$@"; }
nx h1 ip -6 addr show dev eth0

4. Захват сегмента «офис» ведите на мосту: nx sw tcpdump -ni br0 -e -vv ip6 в отдельном терминале. Для разбора в Wireshark сохраняйте захват в файл (-w /tmp/lr11-partN.pcap) и откройте его на хосте.
5. В конце работы: sudo ./down.sh.

Базовая часть — части 1–6, продвинутая — части 7–8.

Часть 1. Link-local адреса и EUI-64

Задание

1. Не выполняя команд, вычислите по MAC-адресам из таблицы топологии link-local адреса EUI-64 хостов h1 и h2 и маршрутизатора r1 на eth0. Запишите вычисление для h1 по шагам: вставка ff:fe, инверсия бита U/L, запись группами по 16 бит.
2. Проверьте вычисление:

nx h1 ip -6 addr show dev eth0
nx h2 ip -6 addr show dev eth0
nx r1 ip -6 addr show dev eth0

Объясните, откуда у r1 два link-local адреса и почему у хостов нет глобальных адресов.

3. Проверьте связность по link-local адресу:

nx h1 ping -6 -c 2 fe80::1%eth0
nx h1 ping -6 -c 2 fe80::5054:ff:fe11:120%eth0

Объясните, зачем нужен суффикс %eth0. Почему в узле с несколькими интерфейсами без него обойтись нельзя, хотя в IPv4 адрес получателя однозначно определял интерфейс через таблицу маршрутизации? Посмотрите nx h1 ip -6 route и найдите маршрут fe80::/64.

4. Проверьте, что link-local адрес не маршрутизируется: попробуйте с h1 достичь link-local адреса сервера srv (вычислите его по MAC-адресу 52:54:00:11:02:10). Предскажите результат и объясните его.

Что должно получиться

Вычисление EUI-64 для h1 с промежуточными шагами и таблица «узел — вычисленный адрес — фактический адрес». Вывод ping по link-local адресу. Ответы на вопросы пунктов 3 и 4.

Часть 2. Обнаружение соседей в захвате трафика

Задание

1. Вычислите группу запрашиваемого узла для адреса fe80::1 и соответствующий групповой MAC-адрес. Проверьте, в каких группах состоит интерфейс h1:

nx h1 ip maddr show dev eth0

Найдите в выводе группу запрашиваемого узла для собственного адреса h1, группу всех узлов и соответствующие им MAC-адреса 33:33:….

2. Очистите кеш соседей на h1 и r1, запустите захват на мосту и выполните один эхо-запрос:

nx h1 ip -6 neigh flush dev eth0
nx r1 ip -6 neigh flush dev eth0
nx sw tcpdump -ni br0 -e -vv ip6           # в другом терминале
nx h1 ping -6 -c 1 fe80::1%eth0

3. В захвате найдите NS и NA. Для каждого сообщения выпишите: MAC-адрес отправителя и получателя, IPv6-адрес отправителя и получателя, значение Hop Limit (hlim), флаги NA, опцию с канальным адресом. Сравните с предсказанием из пункта 1. Сравните с обменом ARP из лабораторной работы 7: какие кадры в IPv4 были широковещательными и что пришло им на смену?
4. Объясните, почему все сообщения NDP имеют Hop Limit 255 и что сделает получатель с NA, у которого Hop Limit равен 254.
5. Понаблюдайте за состояниями записи соседа:

nx h1 ip -6 neigh show dev eth0           # сразу после ping
sleep 45; nx h1 ip -6 neigh show dev eth0 # через 45 с
nx h1 ping -6 -c 1 fe80::1%eth0; nx h1 ip -6 neigh show dev eth0

Объясните переходы REACHABLE → STALE → DELAY (или REACHABLE). Почему через 45 с запись гарантированно уже не в состоянии REACHABLE?

Что должно получиться

Таблица полей NS и NA с пояснениями, ответы на вопросы 3–5, последовательность состояний записи соседа с объяснением.

Часть 3. Обнаружение дубликатов адресов

Задание

1. Предскажите, какие кадры появятся в захвате, если на h1 вручную назначить адрес 2001:db8:a:1::100/64: адрес отправителя NS, адрес получателя на уровне IP и Ethernet, будет ли ответ.
2. Запустите захват и назначьте адрес:

nx sw tcpdump -ni br0 -e -vv ip6           # в другом терминале
nx h1 ip addr add 2001:db8:a:1::100/64 dev eth0
nx h1 ip -6 addr show dev eth0             # выполнить сразу и через 2 с

Объясните, почему сразу после назначения адрес помечен tentative и что это означает для его использования.

3. Создайте конфликт: назначьте тот же адрес хосту h2:

nx h2 ip addr add 2001:db8:a:1::100/64 dev eth0
nx h2 ip -6 addr show dev eth0

4. В захвате найдите NS от h2 и ответ h1. Объясните: почему источник NS — ::; почему NA отправлен на ff02::1, а не индивидуально; почему у NA нет флага S. Что за опция с номером 14 (unknown option (14)) присутствует в NS и зачем она нужна?
5. Удалите конфликтующий адрес на h2 и оба адреса проверки:

nx h2 ip addr del 2001:db8:a:1::100/64 dev eth0
nx h1 ip addr del 2001:db8:a:1::100/64 dev eth0

6. Вопрос для рассуждения: хост h2 был выключен в момент, когда h1 получил адрес, а затем включился с тем же статически настроенным адресом. Кто из них обнаружит конфликт и как? А если наоборот: оба узла давно работают с разными адресами, и администратор по ошибке меняет адрес h1 на уже занятый адрес h2? Сравните DAD с механизмом gratuitous ARP из лабораторной работы 7: какой из них защищает уже работающий узел, а какой — только вновь назначаемый адрес?

Что должно получиться

Предсказание и фактические кадры DAD с пояснением каждого поля; вывод ip -6 addr с отметкой dadfailed; ответы на вопросы 4 и 6 с результатом эксперимента.

Часть 4. Глобальные адреса и маршрутизация через r1

Задание

1. Назначьте хостам статические глобальные адреса и маршрут по умолчанию через link-local адрес шлюза:

nx h1 ip addr add 2001:db8:a:1::10/64 dev eth0
nx h2 ip addr add 2001:db8:a:1::20/64 dev eth0
nx h1 ip -6 route add default via fe80::1 dev eth0
nx h2 ip -6 route add default via fe80::1 dev eth0

Почему при указании link-local следующего перехода обязательно dev eth0? Что ответит ip, если его опустить?

2. Проверьте, что на r1 включена пересылка IPv6 (sysctl net.ipv6.conf.all.forwarding), и выполните:

nx h1 ping -6 -c 3 2001:db8:a:2::10
nx h1 tracepath -6 -n 2001:db8:a:2::10
nx h1 ip -6 route get 2001:db8:a:2::10

По выводу ip -6 route get назовите следующий переход, интерфейс и адрес отправителя, выбранный ядром. Почему адрес отправителя не link-local?

3. Сравните заголовки IPv4 и IPv6 одного и того же запроса. Запустите захват на мосту с ключом -e -vv и выполните по одному эхо-запросу к серверу по IPv4 и IPv6:

nx h1 ping -4 -c 1 10.11.2.10
nx h1 ping -6 -c 1 2001:db8:a:2::10

Заполните таблицу: длина кадра; длина заголовка IP; поле, указывающее транспорт (proto/next-header); TTL/Hop Limit в запросе и ответе на сегменте офиса; наличие контрольной суммы заголовка; метка потока. Объясните разницу длин кадров (должно получиться 20 байт). Почему Hop Limit ответа, захваченного в офисе, на единицу меньше, чем у запроса?

4. Отключите пересылку IPv6 на r1 (nx r1 sysctl -w net.ipv6.conf.all.forwarding=0), повторите ping -6 к серверу и опишите результат, затем включите пересылку обратно. Проверьте, что IPv4 при этом продолжал работать: двойной стек — это два независимых протокола.

Что должно получиться

Выводы ping, tracepath и ip -6 route get с пояснениями; заполненная таблица сравнения заголовков IPv4/IPv6; описание опыта с отключённой пересылкой.

Часть 5. SLAAC и DHCPv6 через объявления маршрутизатора

Задание

1. Верните топологию в исходное состояние (sudo ./up.sh), чтобы у хостов не было статических адресов. Проверьте значения параметров на h1 и r1:

nx h1 sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.forwarding
nx r1 sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.forwarding

Объясните, почему r1 не будет строить себе адрес по объявлениям, хотя accept_ra у него тоже равен 1.

2. Прочитайте ra.sh и предскажите содержимое RA в режиме slaac: флаги M и O, префикс и его флаги L и A, времена жизни префикса, время жизни маршрутизатора, адрес DNS-сервера. Предскажите глобальный адрес, который получит h1.
3. Запустите захват (сохраните его в файл для Wireshark), затем рассылку RA. Чтобы хосты отправили RS сразу, переподнимите их интерфейсы:

nx sw tcpdump -ni br0 -e -vv -w /tmp/lr11-slaac.pcap ip6   # в другом терминале
sudo ./ra.sh slaac
nx h1 ip link set eth0 down; nx h1 ip link set eth0 up
sleep 4
nx h1 ip -6 addr show dev eth0
nx h1 ip -6 route

4. В захвате найдите RS и RA. Разберите RA по полям (в Wireshark — раскрыв ICMPv6 и опции): флаги, router lifetime, Prefix Information с флагами и временами жизни, MTU, Source Link-Layer Address, RDNSS. Сравните с предсказанием. Найдите затем DAD для построенного глобального адреса.
5. Объясните по выводу ip -6 route: откуда взялся маршрут по умолчанию, почему его следующий переход — link-local адрес fe80::5054:ff:fe11:101, а не fe80::1 и не 2001:db8:a:1::1; почему у маршрута есть время истечения и каким полем RA оно задано.
6. Режим «без сохранения состояния». Перезапустите рассылку с флагом O и запросите параметры у сервера DHCPv6. Используйте прилагаемый сценарий dhcp6-show.sh, который только печатает полученные параметры и не меняет настройки вашей машины:

sudo ./ra.sh stateless
nx sw tcpdump -ni br0 -vv 'udp port 546 or udp port 547'   # в другом терминале
nx h1 dhclient -6 -S -1 -sf "$PWD/dhcp6-show.sh" \
     -lf /run/lr11-h1.leases -pf /run/lr11-h1.pid eth0

Найдите в захвате сообщения Information-Request и Reply, их адреса и порты. Какой параметр сообщил сервер? Сравните с журналом dnsmasq (sudo cat /run/lr11-dnsmasq.log). Почему клиент отправляет запрос на ff02::1:2, а не широковещательно, и с какого адреса?

7. Ответьте письменно: можно ли построить сеть, где узлы получают всё по DHCPv6 и маршрутизатор не рассылает RA? Чего узлам будет не хватать?

Что должно получиться

Предсказание и фактическое содержимое RA (таблица «поле — значение — смысл»), вывод адресов и маршрутов h1 с объяснением, обмен DHCPv6 и ответы на вопросы 5–7.

Часть 6. Сломать и починить: фильтрация ICMPv6

Задание

1. Убедитесь, что h1 и h2 получили адреса через SLAAC (если нет — sudo ./ra.sh slaac и подождите несколько секунд) и что h1 достигает глобального адреса h2 (nx h1 ping -6 -c 2 АДРЕС_h2).
2. Внесите неисправность: sudo ./break-icmpv6.sh. Содержимое скрипта до окончания диагностики не читайте.
3. Проверьте связность h1 → h2 по IPv6 и по IPv4. Сформулируйте симптом.
4. Проведите диагностику по методике «по пути пакета»: состояние записи соседа на h1 (ip -6 neigh), захват на мосту (какие запросы уходят, есть ли ответы), правила фильтрации на h2 (nx h2 nft list ruleset). Запишите гипотезы и проверку каждой из них.
5. Объясните механизм неисправности: какое именно сообщение отбрасывается, почему ping при этом не работает, хотя эхо-запросы и эхо-ответы разрешены, и почему IPv4 продолжает работать.
6. Исправьте правило так, чтобы сохранить замысел администратора (запретить лишнее ICMP), но не сломать IPv6: разрешите сообщения NDP (типы 133–137) и сообщения об ошибках, необходимые для работы (по крайней мере Packet Too Big, Time Exceeded, Destination Unreachable, Parameter Problem). Пример заготовки:

nx h2 nft delete table inet lr11
nx h2 nft -f - <<'EOF'
table inet lr11 {
  chain input {
    type filter hook input priority 0; policy accept;
    icmpv6 type { echo-request, echo-reply, destination-unreachable,
                  packet-too-big, time-exceeded, parameter-problem,
                  nd-router-solicit, nd-router-advert,
                  nd-neighbor-solicit, nd-neighbor-advert } accept
    meta l4proto ipv6-icmp drop
  }
}
EOF

Проверьте, что связность восстановилась. Сверьте свой список с рекомендациями RFC 4890 (см. раздел «Что почитать» в дополнительных материалах): какие ещё типы ICMPv6 вы бы разрешили и почему?

Что должно получиться

Симптом, ход диагностики (гипотезы, проверки, выводы), объяснение механизма неисправности и исправленный набор правил с проверкой связности.

Часть 7. MTU 1280 и Packet Too Big (продвинутая)

Задание

1. Уменьшите MTU звена r1 — srv до минимального для IPv6:

nx r1 ip link set eth1 mtu 1280
nx srv ip link set eth0 mtu 1280

Попробуйте уменьшить MTU r1 на eth1 до 1200 и посмотрите nx r1 ip -6 addr show dev eth1. Что произошло с адресами IPv6 на интерфейсе и почему? Верните MTU 1280 и убедитесь, что вручную назначенные адреса не вернулись сами; восстановите их:

nx r1 ip link set eth1 mtu 1280
nx r1 ip addr add fe80::1/64 dev eth1
nx r1 ip addr add 2001:db8:a:2::1/64 dev eth1

2. Рассчитайте: размер пакета IPv6 при ping -6 -s 1400; длину полезной нагрузки сообщения Packet Too Big, которое вернёт r1 (учтите правило «сообщение об ошибке не больше 1280 байт»); размеры данных в двух фрагментах при повторной отправке.
3. Запустите захват на мосту и выполните:

nx h1 ping -6 -c 2 -s 1400 -M do 2001:db8:a:2::10
nx h1 ip -6 route get 2001:db8:a:2::10
nx h1 ping -6 -c 2 -s 1400 2001:db8:a:2::10
nx h1 tracepath -6 -n 2001:db8:a:2::10

4. Сопоставьте захват с расчётом: Packet Too Big (кто отправил, кому, какой MTU указан, какова длина), фрагменты (идентификатор, смещения, длины, поле next-header основного заголовка). Объясните, кто фрагментировал пакет и почему не маршрутизатор. Объясните, что означает expires … mtu 1280 в выводе ip -6 route get.
5. Сломайте PMTUD: на r1 запретите отправку сообщений Packet Too Big (сообщения, порождённые самим маршрутизатором, проходят цепочку с хуком output), очистите кеш маршрутов на h1 и повторите эксперимент:

nx r1 nft add table inet pmtu
nx r1 nft add chain inet pmtu out '{ type filter hook output priority 0; policy accept; }'
nx r1 nft add rule inet pmtu out icmpv6 type packet-too-big counter drop
nx h1 ip -6 route flush cache
nx h1 ping -6 -c 2 -W 1 -s 1400 2001:db8:a:2::10
nx h1 ping -6 -c 2 -W 1 -s 1000 2001:db8:a:2::10
nx r1 nft list ruleset

Опишите симптом (сравните два размера), найдите по счётчику правила, сколько сообщений было отброшено, и объясните, почему в IPv6 «чёрная дыра» PMTUD опаснее, чем в IPv4. Удалите таблицу: nx r1 nft delete table inet pmtu.

Что должно получиться

Расчёт и его сравнение с захватом, объяснение работы PMTUD в IPv6, описание опыта с «чёрной дырой».

Часть 8. Стабильные и временные идентификаторы интерфейса (продвинутая)

Задание

1. Включите на h2 временные адреса и стабильные идентификаторы по RFC 7217 (секрет задаётся вручную, в реальной системе он генерируется при установке):

nx h2 sysctl -w net.ipv6.conf.eth0.use_tempaddr=2
nx h2 sysctl -w net.ipv6.conf.eth0.stable_secret=0123:4567:89ab:cdef:0123:4567:89ab:cdef
nx h2 sysctl -w net.ipv6.conf.eth0.addr_gen_mode=2
nx h2 ip link set eth0 down; nx h2 ip link set eth0 up
sleep 5; nx h2 ip -6 addr show dev eth0

2. Опишите полученные адреса: какой построен по RFC 7217 (флаг stable-privacy), какой временный; изменился ли link-local адрес; можно ли теперь по адресу узнать MAC-адрес h2.
3. Определите, какой адрес отправителя выберет h2 для соединения с сервером: nx h2 ip -6 route get 2001:db8:a:2::10, затем проверьте захватом ping -6. Объясните выбор с учётом use_tempaddr=2.
4. Переподнимите интерфейс ещё раз. Какой из адресов остался прежним, какой изменился? Объясните, почему это и есть желаемое поведение с точки зрения приватности и удобства администрирования.

Что должно получиться

Вывод адресов с пояснениями, выбранный адрес отправителя, сравнение адресов до и после переподнятия интерфейса.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Почему для link-local адреса необходимо указывать идентификатор зоны, а для глобального — нет?
2. Как связаны индивидуальный адрес, его группа запрашиваемого узла и групповой MAC-адрес? Почему NS, отправленный на такой групповой адрес, не обрабатывают все узлы сегмента, в отличие от запроса ARP?
3. Зачем сообщения NDP отправляются с Hop Limit 255 и почему получатель проверяет это значение?
4. Чем состояние STALE записи соседа отличается от INCOMPLETE? Что произойдёт при отправке пакета соседу в состоянии STALE?
5. Почему NS при обнаружении дубликата отправляется с адреса ::, а ответ на него — на ff02::1? Какие ограничения у механизма DAD?
6. Какие сведения узел получает из RA, а какие может получить только из DHCPv6? Можно ли обойтись в сети без RA?
7. Что означают флаги M, O, L и A? Какую конфигурацию узла даёт сочетание M=0, O=1, A=1?
8. Чем действительное время жизни адреса отличается от предпочтительного и как это используется при перенумерации сети?
9. Почему маршрутизатор IPv6 не фрагментирует пакеты и что происходит с пакетом больше MTU следующего канала? Почему фильтрация Packet Too Big опаснее в IPv6, чем фильтрация «Fragmentation needed» в IPv4?
10. Почему правило «разрешить из ICMPv6 только эхо-запросы и ответы» делает невозможным даже ping между соседями?
11. Зачем нужны временные адреса и стабильные идентификаторы RFC 7217, если адресов в подсети /64 настолько много, что перебрать их невозможно?
12. Почему маршрут по умолчанию в IPv6 указывает на link-local адрес маршрутизатора и какие преимущества это даёт?