Многоадресный фоновый трафик IPv6 (часть 3) — многоадресная рассылка и автоконфигурация стека IPv6 (продолжение)

• Многоадресный фоновый трафик IPv6 (часть 5) — протоколы обнаружения службы многоадресной рассылки IPv6 от Microsoft

Введение

В предыдущем посте этой серии мы рассмотрели некоторые ключевые аспекты автоматической настройки стека IPv6 на ПК с Windows 7: DHCPv6, префиксы IPv6, обнаружение соседей, ICMPv6 и объявления маршрутизатора. В этом посте мы рассмотрим, как многоадресная рассылка используется для автоматической настройки IPv6.

Говори, не кричи

Последние два типа пакетов ICMPv6 Neighbor Discovery (ND), которые вы обычно видите в локальных сетях Windows 7, Neighbor Solicitation и Neighbor Advertisement, предназначены для определения MAC-адресов. Вы, вероятно, знакомы с ARP из IPv4 — IPv6 заменяет ARP более эффективным механизмом, который Microsoft описывает следующим образом:

Адрес запрошенного узла облегчает эффективный запрос сетевых узлов во время разрешения адреса. В IPv4 кадр запроса ARP отправляется в широковещательную рассылку MAC-уровня, мешая всем узлам в сегменте сети, включая те, которые не используют IPv4. IPv6 использует сообщение Neighbor Solicitation для разрешения адресов. Однако вместо использования адреса всех узлов области локальной связи в качестве адресата сообщения Neighbor Solicitation, что может нарушить работу всех узлов IPv6 в локальной ссылке, используется многоадресный адрес запрошенного узла. Многоадресный адрес запрошенного узла состоит из префикса FF02::1:FF00:0/104 и последних 24 битов разрешаемого IPv6-адреса.

Вот пример, когда ПК с Windows 7 запросил MAC-адрес маршрутизатора IPv6. Роутер впервые заявил о себе через стандартную рекламу:

фигура 1

Затем ПК с Windows 7 отправил пакет Neighbor Solicitation на запрошенный адрес узла ff02::1:ff + ac:d7c7 (последние 24 бита IPv6-адреса маршрутизатора, как указано выше):

фигура 2

И маршрутизатор ответил на unicast-адрес link-local fe80 запрашивающей стороны:

Рисунок 3

Последнее и очень важное использование пакетов Solicited Node — это установление уникальности локального адреса канала IPv6. Вот в чем проблема: назначать себе адрес только для локальной сети в адресном пространстве fe80 во время загрузки — это хорошо, но как узнать, что кто-то еще не использует этот адрес? Вероятность конфликта хоть и минимальна, но существует. Решение состоит в том, чтобы отправить пакет Neighbor Solicitation на адрес запрашиваемого узла и использовать исходный IP-адрес:: (т. е. нулевой, потому что мы еще не уверены, что можем использовать желаемый адрес в поле Target). По всей вероятности, никто не ответит, и тогда хост узнает, что он может безопасно использовать предложенный адрес, но если случайно какой-то хост уже заявил адрес запрошенного узла, он ответит на этот вопрос, и первоначальный отправитель должен будет отступить и попробуйте использовать другой адрес.

Рисунок 4

Отчеты об обнаружении многоадресных прослушивателей

Последние многоадресные пакеты внутренней отчетности IPv6, которые вы часто будете видеть в локальных сетях Windows 7, — это отчетные сообщения Multicast Listener Discovery v2 (MLDv2). Мне не удалось установить их цель или найти какое-либо объяснение моделей трафика, которые я видел, и буду рад получить отзывы от сообщества.

MLDv2, версия IGMP для IPv6, представляет собой сложную тему, но, по сути, это протокол для информирования маршрутизаторов о том, что на данном канале есть узлы, заинтересованные в заданном многоадресном адресе. Поскольку групповая адресация не является передачей «точка-точка», маршрутизатор может узнать, следует ли передавать многоадресный трафик, только если он знает, что на следующем узле есть хотя бы один «заинтересованный слушатель». Может быть более одного заинтересованного слушателя, но все, что заботит маршрутизатор, это наличие хотя бы одного.

В локальных сетях Windows 7 слышен устойчивый гул пакета MLDv2 определенного типа, отчет прослушивателя, на локальный адрес многоадресной рассылки MLDv2 ff02::16. Существует два типа сообщений Report: Include (сообщает маршрутизатору, что узел заинтересован в трафике на заданный многоадресный адрес) и Exclude (был заинтересован в таком трафике, но больше не). Вот типичный «исключающий» пакет, который ПК отправляет, чтобы указать, что он больше не заинтересован в трафике на многоадресный адрес ff02::1:3 (LLMNR):

Рисунок 5

Первый вопрос, на который я не смог найти ответ, заключается в том, почему ПК вообще отправляет отчеты MLDv2 о локальном трафике на маршрутизатор. Для не -link-local многоадресной рассылки имеет смысл отправлять отчеты MLDv2, но для link-local трафика маршрутизаторы по определению никогда не собираются его пересылать, поэтому нет никакой очевидной пользы для маршрутизатора от инструкций в приведенном выше пакете. Возможно, этот пакет является побочным эффектом конструкции стека Microsoft IPv6, например, возможно, API-интерфейсы кодирования генерируют отчеты MLDv2 независимо от того, является ли рассматриваемый многоадресный адрес локальным для канала или нет.

Еще более любопытен типичный шаблон трафика: пакет отчетов MLDv2, которые попеременно включаются и исключаются. На снимке ниже почти дюжина чередующихся отчетов MLDv2 о включении/исключении, связанных с адресом ff02::1:3, за одну секунду до поиска LLMNR. Я не смог найти никакого документированного объяснения этой модели трафика или ее цели.

Рисунок 6

На этом мы завершаем наш обзор того, как Windows 7 использует многоадресную рассылку IPv6 для автоматической настройки стека. Во второй части нашей серии мы расскажем о сети с нулевой конфигурацией: для чего она используется, кто является игроками и почему вас это должно волновать.

• Многоадресный фоновый трафик IPv6 (часть 4) — Box Chatter — P2P Multicast и войны с нулевой конфигурацией
• Многоадресный фоновый трафик IPv6 (часть 5) — протоколы обнаружения службы многоадресной рассылки IPv6 от Microsoft