Управление групповым трафиком

Решив вопрос о совместимости на уровне отдельных полей, перейдем к совместимости формата сообщений в целом. По своему формату отчет MLDv2 в корне отличается от отчета MLDv1, так как он содержит переменное число записей о разных группах, а каждая запись имеет определенный тип и может содержать список источников. Лучшее, что мы можем сделать ради совместимости как однозначности интерпретации, — это полностью разделить отчеты MLDv1 и MLDv2. Для этого достаточно назначить отчету MLDv2 новый тип ICMPv6 (143).

Что же касается запросов, то их формат изменился не так радикально. Более того, он вполне отвечает модели расширения протокола MLD, когда новые данные помещаются в конец сообщения, после его совместимой части. Благодаря этому запрос MLDv2 может сохранить за собой тот же самый тип ICMPv6 (130). Если реализация поддерживает обе версии MLD, то ей просто определить версию запроса на входе: запрос MLDv1 всегда длиной 24 байта, тогда как длина запроса MLDv2 — от 28 байт и выше. Диапазон длин от 25 до 27 байт запретный и не отвечает никакой версии MLD.

Наконец, мы добрались до совместимого поведения сторон протокола. Здесь нас, в первую очередь, интересуют два случая: поведение слушателей MLDv1 в ответ на запросы MLDv2 и поведение маршрутизаторов MLDv2 в ответ на отчеты MLDv1. Это видно из таблиц совместимости Табл. 8.6 и Табл. 8.7.

В первом случае слушатель ответит отчетом MLDv1 о данной группе, или же целой серией отчетов обо всех своих группах, если запрос был общий. Тогда маршрутизатор MLDv2 сможет взять на заметку, что на канале есть как минимум один слушатель MLDv1, и включить режим совместимости.

Это естественным порядком приводит нас ко второму случаю. Маршрутизатор MLDv2 как более современный легко декодирует сообщение MLDv1, поэтому вопрос состоит в том, насколько усложнит реализацию режим совместимости. В частности, понадобится ли маршрутизатору MLDv2 отдельный алгоритм реакции на сообщения MLDv1? К счастью, нет, потому что по содержащейся в них информации отчет и итог MLDv1 — это лишь подмножество многофункциональных отчетов MLDv2. На самом деле, мы об этом уже говорили, так что сейчас нам осталось только составить таблицу соответствия — Табл. 8.8.

Таблица 8.8. Апгрейд" сообщений MLDv1 до MLDv2

Сообщение MLDv1	Эквивалент MLDv2
Отчет	IS_EX()
Итог	TO_IN()

Благодаря такому соответствию, маршрутизатор MLDv2 может обрабатывать отчеты и итоги MLDv1 по уже готовым правилам протокола MLDv2.

Помимо этих двух очевидных случаев взаимодействия сторон MLD, нам надо обратить внимание на "перекрестное опыление" слушателей и маршрутизаторов (Табл. 8.9). Ведь в принципе слушатели могут получать отчеты, а маршрутизаторы — запросы. К счастью, с первой частью проблем нет, так как отчеты MLDv2 направляются по специальному групповому адресу, и слушатели их не получат, независимо от их версии. Что касается реакции слушателя MLDv2 на отчет MLDv1, связанная с этим оптимизация (подавление отчетов) упразднена, и отчет можно безопасно игнорировать.

В то же время, маршрутизатор обязан реагировать на чужие запросы, так как на этом основаны процедуры выбора генератора запросов и последующей синхронизации с ним. Этот случай самый сложный, так как правила реакции маршрутизаторов на чужие запросы в MLDv1 и MLDv2 существенным образом отличаются. В частности, маршрутизаторы MLDv1 не смогут использовать дополнительную информацию из запроса MLDv2 для точной синхронизации с генератором.

Поэтому, ради устойчивой работы сети, мы объявим нежелательной смешанную конфигурацию с использованием маршрутизаторов MLDv1 и MLDv2 на одном канале. Точнее, пусть маршрутизатор MLDv2 использует только запросы MLDv1, пока на том же канале есть маршрутизаторы MLDv1 [§8.3.1 RFC 3810]. Это приемлемый компромисс, так как маршрутизаторов меньше, чем хостов, а их взаимозаменяемость выше. Если обновление хостов — процесс долгий , трудоемкий и требующий поэтапного подхода, переключение подсети^{5 В старом смысле этого термина: транзитная инфраструктура сети.} на MLDv2 можно провести за один шаг, например, путем установки на канал одного или нескольких новых групповых маршрутизаторов и временного отключения старых. Затем будет достаточно постепенно обновлять старые маршрутизаторы и возвращать их обратно в эксплуатацию.

Сводная таблица совместимости между сторонами MLDv1 и MLDv2 будет такой, как показано в Табл. 8.10.

Таблица 8.10. Совместимость между сторонами MLD: сообщения какой версии использовать?

Хосты \ Маршрутизаторы	Только v1	Только v2	v1 и v2
Только v1	v1	Запросы v2, отчеты v1	v1
Только v2	v1	v2	v1
v1 и v2	v1	Запросы v2, отчеты v1 и v2	v1

А вот сравнительная таблица главных характеристик этих протоколов — Табл. 8.11.

Последним аспектом MLD, который мы не можем обойти вниманием, будет безопасность [§10 RFC 3810]. В какой степени этот протокол защищен от атак, и, с другой стороны, насколько опасны эти атаки? В отличие от ND, состояние стороны MLD зависит только от принятых ею сообщений MLD и не зависит от других внешних событий.

Поэтому единственный способ атаковать MLD — это подделка сообщений MLD. Главной мерой защиты от такой подделки будет изоляция канала от любых сообщений MLD извне. Действительно, по своему устройству MLD — стопроцентно внутриканальный протокол. Здесь можно пустить в ход весь арсенал доступных средств. Прежде всего, на выходе адрес источника сообщения MLD обязан быть внутриканальным за тем единственным исключением, что в отчете он может быть неопределенным. Тем не менее, отчеты с неопределенным адресом источника необходимы только для подготовки коммутаторов ЛВС на стадии SLAAC (§5.4.2) или DAD (§5.4.1), тогда как узлы IPv6 вполне могут игнорировать их на входе [§5.2.13 RFC 3810]. Действительно, сообщения ND, из которых состоят SLAAC и DAD, все равно не подлежат маршрутизации, и маршрутизаторам нет дела до членства слушателей в группах искомого узла и группе "все узлы канала". А позднее, когда узел назначит себе внутриканальный адрес, он повторит свои отчеты уже с определенным адресом источника. Поэтому на входе адрес источника в сообщении MLD должен быть внутриканальным, а иначе такое сообщение надо просто игнорировать.

Далее, все сообщения MLD несут опцию "сигнал маршрутизатору", и это существенно облегчает выделение этих пакетов из общего потока. Следовательно, на входе все узлы обязаны убедиться, что пакет MLD снабжен этой опцией.

Маршрутизаторам к тому же запрещено продвигать пакеты MLD куда бы то ни было. Продвижение MLD в другие каналы запрещено из соображений безопасности, а в тот же самый канал — ради устойчивости сети. Как мы уже отмечали, зацикливание группового трафика может иметь лавинный характер, когда каждая копия пакета рождает несколько копий следующего поколения и т.д. По этой причине MLD не защищают при помощи GTSM, а наоборот, устанавливают в пакетах MLD "предельное число шагов" равным 1. Ведь продвижение пакетов MLD в другие каналы уже заблокировано зонной архитектурой, тогда как продвижение в тот же самый канал она вполне допускает, как было сказано в §2.4.

Справившись с внешними врагами, мы можем перейти к врагам внутриканальным, а они, конечно, более опасны. Главная угроза исходит здесь от подделки или просто несанкционированной отправки запросов MLD. Для начала злоумышленник способен провести атаку на выборы генератора. Для этого ему достаточно вести передачу запросов с как можно меньшего внутриканального адреса, например, FE80:: или FE80::1. Заполучив роль генератора запросов, или параллельно с этой атакой, злоумышленник может подавить всякую маршрутизацию группового трафика в данный канал. Для этого ему достаточно периодически высылать запрос, ограниченный никому не интересной группой. Как нетрудно убедиться, в этом случае законные маршрутизаторы будут вечно пребывать в состоянии пассивных наблюдателей, а слушатели никогда не получат повод послать свои отчеты. В результате законные маршрутизаторы будут обманным способом убеждены в том, что никаких слушателей на канале просто нет.

В то же время, подделка отчетов MLD — это оксюморон, так как вступление в группу или просто начало ее приема — добровольная операция, доступная любому узлу канала. Конечно, злоумышленник может провести атаку типа "отказ в обслуживании", послав отчет о приеме большого числа групп, а вдобавок замести следы, подделав адрес источника. С первой частью этой атаки можно бороться, ограничив на маршрутизаторе число продвигаемых групп, — это все равно придется сделать из соображений устойчивости. Что касается подделки адреса источника, то здесь она не несет критической опасности, так как в MLD "личность" слушателя практически неважна, хотя ловить злоумышленника будет чуть сложнее.