Network Working Group                                      W. Fenner
Request for Comments: 2236                                Xerox PARC
Updates: 1112                                          November 1997
Category: Standards Track

Internet Group Management Protocol, Version 2

Протокол IGMP v2

PDF

Статус документа

Этот документ содержит проект стандартного протокола для сообщества Internet и служит запросом для обсуждения в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (1997). All Rights Reserved.

Тезисы

Этот документ описывает протокол IGMPv2, используемый хостами IP для передачи маршрутизаторам сведений о принадлежности хостов к multicast-группам. Данный документ обновляет STD 5, RFC 1112.

Протокол IGMPv2 позволяет быстро передавать сведения о выходе из групп протоколу маршрутизации – это очень важно для широкополосных multicast-групп и/или подсетей с постоянно изменяющимся членством в группах.

Документ является результатом работы группы Inter–Domain Multicast Routing (междоменная маршрутизация группового трафика) в составе IETF. Комментарии к документу приветствуются и принимаются по адресу списка рассылок рабочей группы idmr@cs.ucl.ac.uk) и/или адресам авторов.

1. Определения

Слова обязательно (должно), недопустимо, требуется, следует, не следует, рекомендуется, возможно, необязательный (дополнительный, опциональный) в этом документе выделяются жирным шрифтом и должны трактоваться в соответствии с RFC 2119¹ [RFC 2119].

2. Введение

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

Подобно ICMP, протокол IGMP является частью IP и должен быть реализован на всех хостах, которые хотят получать групповой трафик IP. Сообщения IGMP инкапсулируются в дейтаграммы IP и использованием номера протокола IP = 2. Все описанные в документе сообщения IGMP передаются с TTL = 1 и содержат опцию IP Router Alert [RFC 2113] в заголовке IP. Все сообщения IGMP, относящиеся к хостам, имеют следующий формат:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     | Max Resp Time |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1. Type

В контексте взаимодействия между хостами и маршрутизаторами выделяют три типа сообщений IGMP:

0x11 = Membership Query (запрос на включение в группу)

Сообщения Membership Query делятся на два подтипа:

• General Query (запрос общего типа) используется для определения групп, члены которой находятся в подключенной сети.

• Group–Specific Query (связанный с группой запрос) служит для выяснения наличия в подключенной сети членов конкретной группы.

Сообщения разных подтипов отличаются адресом группы (Group Address), описанным в параграфе 2.4². Сообщения Membership Query далее будут для краткости обозначаться одним словом Query.

0x16 = Version 2 Membership Report(отчет о принадлежности к группе).

0x17 = Leave Group(выход из группы)

0x12 = Version 1 Membership Report(отчет о принадлежности к группе).

Сообщения этого типа поддерживаются для обратной совместимости с IGMPv1:

Далее в этом документе сообщения типа Membership Report будут для краткости обозначаться одним словом Report. Если версия протокола не указывается в документе, это означает, что информация относится к обеим версиям протокола.

Сообщения нераспознанного типа следует просто игнорировать. В новых версиях протокола IGMP, протоколов multicast-маршрутизации и т. п. Могут появляться новые варианты сообщений.

2.2. Max Response Time

Поле Max Response Time имеет смысл только для сообщений Membership Query и задает максимальное время задержки передачи отклика после получения запроса. Время задается в десятых долях секунды. Во всех остальных сообщениях отправитель должен устанавливать нулевое значение этого поля, а получатель игнорировать это поле.

Изменение значения этого поля позволяет маршрутизаторам IGMPv2 настраивать значение leave latency (время между выходом из группы последнего хоста и уведомлением протокола маршрутизации об отсутствии в хостов группе), как описано в параграфе 7.8. Это помогает также преодолевать выбросы трафика IGMP в подсети, как описано в параграфе 7.3.

2.3. Checksum

Контрольная сумма вычисляется как 16-битовое поразрядное дополнение суммы поразрядных дополнений для всех октетов сообщения IGMP (информационная часть пакета IP). При расчете контрольной суммы значение поля checksum принимается нулевым. Контрольная сумма вычисляется и помещается в пакет до его передачи. На приемной стороне контрольная сумма должна вычисляться заново, а полученный результат должен сравниваться со значением поля checksum в принятом пакете до начала обработки пакета.

2.4. Group Address

В сообщениях Membership Query это поле имеет нулевое значение для случаев General Query и содержит адрес группы, к которой относится запрос, в случае Group–Specific Query.

В сообщениях Membership Report и Leave Group поле адреса группы содержит IP-адрес группы, к которой относится отчет или запрос на исключение.

2.5. Прочиеполя

Отметим, что сообщения IGMP могут содержать более 8 октетов (особенно при появлении новых версий IGMP, в целях обеспечения обратной совместимости). Если поле Type задает один из известных типов, реализация IGMPv2 должна игнорировать лишние (сверх первых 8) октеты при обработке пакета. Однако контрольная сумма IGMP всегда должна вычисляться с учетом всех октетов информационного поля пакета IP (а не только для первых 8 октетов).

3. Описание протокола

Названия таймеров и счетчиков приводятся в квадратных скобках. Принятые по умолчанию значения таймеров рассмотрены ниже.

Термин «интерфейс» используется в этом документе для обозначения «основного (первичного) интерфейса в подключенную сеть». Если маршрутизатор имеет несколько интерфейсов в одну сеть, протокол будет использовать только один из таких интерфейсов. Хосты, напротив, должны выполнять действия применительно ко всем интерфейсам, которые связаны с группой.

Multicast-маршрутизаторы используют IGMP для получения информации о принадлежности хостов к группам в каждой из подключенных к маршрутизатору сетей. Multicast-маршрутизаторы ранят списки принадлежности к группам для каждой из подключенных сетей и используют таймер для каждого факта принадлежности к группе (наличия в группе хотя бы одного хоста подключенной к маршрутизатору сети), а не для всего списка членов групп. По отношению к каждой из подключенных сетей multicast-маршрутизатор может играть одну из двух ролей – Querier или Non–Querier. Обычно в каждой физической сети присутствует только один маршрутизатор Querier. Все multicast-маршрутизаторы при старте выбирают режим Querier для каждой из подключенных сетей. Если multicast-маршрутизатор видит сообщение Query от другого маршрутизатора с меньшим значением адреса IP, он должен переключиться для этой сети в состояние Non–Querier. Если маршрутизатор не слышит сообщений Query от других маршрутизаторов в течение периода [Other Querier Present Interval], он остается в состоянии Querier. Маршрутизаторы с периодом [QueryInterval] передают сообщения General Query в каждую из подключенных сетей, для которых данный маршрутизатор исполняет функции Querier, чтобы получить сведения о принадлежности к группам. При старте маршрутизатору следует передать [Startup Query Count] сообщений General Query с интервалами [Startup Query Interval] для того, чтобы быстро и надежно определить принадлежность к группам. Сообщение General Query адресуется группе all-systems (224.0.0.1) и передается с Group Address = 0, Max Response Time = [Query Response Interval].

Получив сообщение General Query, хост устанавливает таймер задержки для каждой группы (кроме all–systems), с которой он связан через интерфейс, принявший запрос. Для каждого таймера устанавливается случайное значение в диапазоне (0, [Max Response Time]) с использованием максимальной гранулярности, доступной для данного хоста. Значение [Max Response Time] берется из сообщения Query. При получении запроса Group–Specific Query хост устанавливает случайное значение таймера в диапазоне (0, Max Response Time] для запрашиваемой группы, если он принадлежит к этой группе на интерфейсе, принявшем сообщение. Если таймер для группы уже запущен, для него устанавливается случайное значение только в том случае, когда Max Response Time меньше времени, оставшегося до завершения отсчета работающего таймера. По завершении заданного для таймера времени, хост передает сообщение Version 2 Membership Report с multicast-адресом группы, установив IPTTL = 1. Если хост получает сообщение Report (версии 1 или 2) от другого хоста во время работы таймера, для этой группы таймер останавливается и сообщение Report не передается во избежание появления дубликатов.

Получив сообщение Report, маршрутизатор добавляет группу, с которой связано это сообщение в список принадлежности для сети, из которой получено сообщение Report и устанавливает таймер [Group Membership Interval] для принадлежности к группе. Повторные сообщения Report приводят к перезапуску таймера. Если за время отсчета таймера не будет получено ни одного отчета о принадлежности к данной группе, маршрутизатор предполагает, что эта группа не имеет локальных членов и не будет пересылать групповые пакеты от удаленных отправителей в соответствующую сеть.

Когда хост присоединяется к группе, ему следует незамедлительно передать сообщение Version 2 Membership Report для этой группы, если данный хост является первым членом этой группы в своей сети. Учитывая возможность потери или повреждения начального сообщения Membership Report рекомендуется передать 1 или 2 дополнительных копии этого сообщения с короткой задержкой [Unsolicited Report Interval]. Проще всего в таких случаях передать начальное сообщение Version 2 Membership Report и далее действовать как при получении запроса Group–SpecificQuery для данной группы с установкой соответствующего таймера.

Когда из группы выходит последний хост, который в ответ на Query передавал сообщение Membership Report для данной группы, этому хосту следует передать сообщение Leave Group по групповому адресу all–routers (224.0.0.2). Если выходящий из группы хост не является последним, кто отвечал на Query, этот хост может не передавать никакого сообщения, поскольку в группе остаются другие хосты. Такой поход позволяет снизить уровень трафика. Если хост не знает, является ли он последним в группе, этот хост может передавать сообщение LeaveGroup всякий раз при выходе из группы. Маршрутизаторам следует принимать сообщения Leave Group адресованные покидаемой группе для обеспечения совместимости с прежней версией данного стандарта. Сообщения LeaveGroup, адресуются группе all–routers, поскольку членам остальных групп нет нужды знать о выходе хоста из группы, однако адресация сообщения в покидаемую группу не принесет вреда.

Когда Querier получает сообщение Leave Group для группы, члены которой связаны с принявшим сообщение интерфейсом, этот маршрутизатор передает [Last Member Query Count] сообщений Group–Specific Query в течение интервала [Last Member Query Interval] для покидаемой группы. В сообщениях Group-Specific Query устанавливается значение Max Response = [Last Member Query Interval]. Если в течение заданного времени не получено ни одного отклика, маршрутизатор предполагает, что ни один из хостов связанной с интерфейсом сети больше не входит в группу. В течение этого периода все переходы Querier -> non–Querier игнорируются и сообщения Group–Specific Query передает тот же самый маршрутизатор.

Маршрутизаторы non–Querier должны игнорировать сообщения LeaveGroup, а маршрутизаторам Querier следует игнорировать сообщения LeaveGroup, для которых нет членов группы на принявшем сообщение интерфейсе.

Когда маршрутизатор non–Querier получает сообщение Group–SpecificQuery и значение таймера принадлежности больше указанного в сообщении MaxResponseTime в [LastMemberQueryCount] раз, маршрутизатор устанавливает для этого таймера значение MaxResponseTime.

4. Совместимость с маршрутизаторами IGMPv1

Хост IGMPv2 может находиться в сети, где маршрутизатор Querier не поддерживает IGMPv2. В этом случае требуется выполнение ряда условий:

• Маршрутизатор IGMPv1 будет передавать пакеты GeneralQuery с MaxResponseTime = 0. Это значение должно интерпретироваться как 100 (10 секунд).

• Маршрутизатор IGMPv1 ожидает сообщений Version 1 MembershipReport в ответ на запросы и не будет принимать во внимание сообщения Version 2 MembershipReports. Следовательно, для каждого интерфейса должна сохраняться переменная состояния, описывающая какие из маршрутизаторов Querier для данного интерфейса используют IGMPv1 и IGMPv2. Значение этой переменной должно базироваться на факте наличия или отсутствия запросов IGMPv1 в последние [Version 1 Router Present Timeout] секунд. Недопустимо устанавливать значение переменной на основе последнего сообщения Query. Состояние переменной должно использоваться для выбора типа сообщений MembershipReport, передаваемых в ответ на запросы и без запросов.

• Хост IGMPv2 может не передавать сообщений Leave Group через интерфейс, для которого маршрутизатор Querier использует протокол IGMPv1.

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

• В присутствии IGMPv1-маршрутизаторов Querier должен использовать протокол IGMPv1. Использование IGMPv1 должно задаваться на административном уровне, поскольку не существует надежного способа динамического обнаружения присутствия в сети маршрутизаторов IGMPv1. Разработчики могут обеспечивать администратору возможность (способ) разрешить использование IGMPv1 при отсутствии явных указаний в параметрах конфигурации, но в принятой по умолчанию конфигурации должен использоваться протокол IGMPv2. При работе в режиме IGMPv1 маршрутизаторы должны передавать сообщения PeriodicQuery с MaxResponseTime = 0 и игнорировать сообщения LeaveGroup. Маршрутизатору следует также выдавать предупреждения при получении запросов IGMPv2, но частота передачи таких предупреждений должна быть ограничена.

• Если маршрутизатор не настроен явно на использование IGMPv1 и при этом слышит запрос IGMPv1, ему следует записать предупреждение в журнальный файл. Частота таких предупреждений должна быть ограничена.

5. Совместимость с хостами IGMPv1

Хост IGMPv2 может оказаться в подсети, где существуют хосты, которые еще не поддерживают IGMPv2. В этом случае следует выполнять приведенное ниже условие:

• Хост должен обеспечивать возможность подавления сообщений MembershipReport для версии 1 или 2.

Маршрутизатор IGMPv2 может оказаться в подсети, где существуют хосты, не поддерживающие протокол IGMPv2. В таких случаях возникают дополнительные требования:

• Если маршрутизатор получает сообщение Version 1 Membership Report, он должен установить таймер, чтобы отметить присутствие хостов версии 1, которые являются членами группы для интерфейса, через который принято сообщение. Значение таймера должно совпадать с [Group Membership Interval].

• Если хосты версии 1 присутствуют в отдельной группе, маршрутизатор должен игнорировать все сообщения Leave Group для этой группы.

6. Диаграмма состояний хоста

Диаграмма состояний хоста показана на рисунке. Хост может находиться в одном из трех состояний по отношению к любой из групп IPmulticast на любом из интерфейсов этого хоста:

• Состояние Non–Member – хост не принадлежит ни к одной из групп на данном интерфейсе. Это состояние является начальным для принадлежности к любой группе на любом из интерфейсов. От хоста в данном состоянии не требуется дополнительных ресурсов.

• Состояние DelayingMember – хост относится к какой-либо из групп на данном интерфейсе и запустил таймер задержки отчета для данного факта принадлежности.

• Состояние IdleMember – хост относится к какой-либо из групп на данном интерфейсе, но не имеет запущенного таймера задержки отчета для данного факта принадлежности.

Существует пять значимых событий, которые могут изменять состояние IGMP:

• Вхождение в группу (join group), когда хост решил присоединиться к группе на данном интерфейсе. Это событие может происходить только в состоянии Non–Member.

• Выход из группы (leave group), когда хост решил покинуть группу на данном интерфейсе. Это событие может происходить только в состоянии Delaying Member или Idle Member.

• Получен запрос (query received), когда хост получил корректное сообщение General Membership Query или Group–Specific Membership Query. Корректность сообщения Query означает, что оно содержит по крайней мере 8 октетов и имеет корректное значение контрольной суммы IGMP. Групповой адрес в заголовке IGMP должен быть нулевым (General Query) или указывать конкретную группу (Group–Specific Query).

Сообщения General Query применимы ко всем фактам принадлежности для интерфейса, принявшего Query. Сообщения Group–Specific Query относятся к фактам принадлежности к одной группе для интерфейса, принявшего Query. Сообщения Query игнорируются для состояния Non–Member.

• Получен отклик (report received), когда хост получил корректное сообщение IGMP Membership Report (версии 1 или 2). Корректное сообщение Report должно иметь размер не менее 8 октетов и корректную контрольную сумму IGMP. Сообщения Membership Report применимы только к фактам принадлежности к группе, указанной в Membership Report на интерфейсе, через который принято сообщение Membership Report. В состояниях Non–Member и IdleMember сообщения этого типа игнорируются.

• Истекло время ожидания (timer expired), когда завершился отсчет времени, заданного таймером задержки для группы на данном интерфейсе. Это событие может происходить только в состоянии Delaying Member.

Все прочие события (получение некорректных сообщений IGMP или сообщений, не являющихся Query или Report) игнорируются в любом состоянии.

В результате перечисленных выше событий может быть выполнено одно из семи действий:

• Передача отклика (send report) для группы на данном интерфейсе. Тип отклика определяется состоянием интерфейса. Сообщение Report адресуется группе, с которой связан отклик.

• Передача сообщения о выходе из группы (sendleave) на данном интерфейсе. Если интерфейс работает в режиме Querier и использует IGMPv1, эту операцию следует пропускать. Если не установлен флаг, говорящий, что хост является последним в группе, операцию можно пропустить. Сообщение Leave передается в группу ALL–ROUTERS (224.0.0.2).

• Установка флага (set flag), показывающего, что хост является последним в группе.

• Сброс флага (clear flag), указывающего, что хост является последним в группе.

• Запуск таймера (start timer) для группы на данном интерфейсе. Таймер устанавливается на период от 0 (исключая 0) до [Max Response Time] (значение Max Response Time задается в сообщении Query). Если отклик является незапрошенным, таймер устанавливается на время от 0 (исключая 0) до [Unsolicited Report Interval].

• Сброс таймера (reset timer) для группы на данном интерфейсе с установкой нового значения в интервале (0, Max Response Time], как описано для запуска таймера.

• Остановка таймера (stop timer) для группы на данном интерфейсе.

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

                              ________________
                             |                |
                             |                |
                             |                |
                             |                |
                   --------->|   Non-Member   |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  | leave group       | join group       | leave group
                  | (stop timer,      |(send report,     | (send leave
                  |  send leave if    | set flag,        |  if flag set)
                  |  flag set)        | start timer)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |                    |                 |
         |                 |<-------------------|                 |
         |                 |   query received   |                 |
         | Delaying Member |    (start timer)   |   Idle Member   |
    ---->|                 |------------------->|                 |
   |     |                 |   report received  |                 |
   |     |                 |    (stop timer,    |                 |
   |     |                 |     clear flag)    |                 |
   |     |_________________|------------------->|_________________|
   | query received    |        timer expired
   | (reset timer if   |        (send report,
   |  Max Resp Time    |         set flag)
   |  < current timer) |
    -------------------

Группа all–systems (224.0.0.1) рассматривается как специальный случай. Хост стартует в состоянии Idle Member для этой группы на каждом из своих интерфейсов, никогда не изменяет состояние и никогда не передает отчетов о принадлежности к этой группе.

Кроме описанных выше состояний хост может находиться относительно каждого из своих сетевых интерфейсов в одном из двух состояний:

• NoIGMPv1 Router Present (нет маршрутизатора IGMPv1), когда хост не принимает ни одного запроса IGMPv1 в течение интервала [Version 1 Router Present Timeout]. Это состояние является исходным.

• IGMPv1 Router Present (присутствует маршрутизатор IGMPv1), когда хост получил хотя бы один запрос IGMPv1 в течение интервала [Version 1 Router Present Timeout].

Существует два типа событий, способных изменить состояние:

• IGMPv1 query received (получен запрос IGMPv1), когда хост принимает запрос с MaxResponseTime = 0.

• timer expires (закончен отсчет по таймеру), когда истекает время, заданное для обнаружения маршрутизаторов IGMPv1.

Событие IGMPv1 query received вызывает единственное действие:

• set timer – установить для таймера его максимальное значение [Version 1 Router Present Timeout] с (пере)запустить таймер.

                              ________________
                             |                |
                             |                |
                             |   No IGMPv1    |
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |                |    |
                       |     |________________|    |
         timer expires |                           | IGMPv1 query
                       |      ________________     | received
                       |     |                |    | (set timer)
                       |     |                |    |
                       |     |                |    |
                        -----|     IGMPv1     |<---
                             |     Router     |
                             |    Present     |
                             |                |
                        ---->|                |----
                       |     |________________|    |
                       |                           |
                       | IGMPv1 query received     |
                       | (set timer)               |
                        ---------------------------

7. Диаграмма состояний маршрутизатора

Диаграмма состояний маршрутизатора показана на рисунке.

По отношению к каждой из подключенных сетей маршрутизатор может находиться в одном из двух состояний:

• Querier, когда этот маршрутизатор назначен для передачи сообщений IGMP Membership Query в данную сеть.

• Non–Querier, когда в данную сеть сообщения IGMP Membership Query передает другой маршрутизатор.

Перечисленные ниже события могут вызывать смену состояния маршрутизатора:

• query timer expired, когда заканчивается отсчет таймера для передачи запроса.

• query received from a router with a lower IP address, когда получено сообщение IGMP Membership Query от маршрутизатора той же сети, имеющего меньшее значение адреса IP.

• other querier present timer expired, когда заканчивается отсчет для таймера, определяющего время проверки наличия в сети другого маршрутизатора Querier с меньшим значением адреса IP.

Перечисленные события могут приводить к трем вариантам действия:

• Запуск таймера general queryдля подключенной сети.

• Запуск таймера start other querier present для подключенной сети со значением [Other Querier Present Interval].

• Передача сообщения General Query в подключенную сеть. Сообщение General Query передается по адресу группы all-systems (224.0.0.1) и имеет Max Response Time = [Query Response Interval].

                                      --------------------------------
                              _______|________  gen. query timer      |
  ---------                  |                |        expired        |
 | Initial |---------------->|                | (send general query,  |
  ---------  (send gen. q.,  |                |  set gen. q. timer)   |
        set initial gen. q.  |                |<----------------------
              timer)         |    Querier     |
                             |                |
                        -----|                |<---
                       |     |                |    |
                       |     |________________|    |
 query received from a |                           | other querier
 router with a lower   |                           | present timer
 IP address            |                           | expired
 (set other querier    |      ________________     | (send general
  present timer)       |     |                |    |  query,set gen.
                       |     |                |    |  q. timer)
                       |     |                |    |
                        ---->|      Non       |----
                             |    Querier     |
                             |                |
                             |                |
                        ---->|                |----
                       |     |________________|    |
                       | query received from a     |
                       | router with a lower IP    |
                       | address                   |
                       | (set other querier        |
                       |  present timer)           |
                        ---------------------------

Маршрутизатору следует начинать работу в состоянии Initial для всех подключенных сетей и сразу же переходить в состояние Querier.

Для отслеживания принадлежности хостов к группам маршрутизатор может поддерживать по отношению к каждой группе для каждой из подключенных сетей одно из 4 состояний:

• No Members Present, когда в сети, которая передает отчет для группы, отсутствуют члены данной группы. Это состояние является начальным для всех групп на маршрутизаторе и не требует ресурсов маршрутизатора.

• Members Present, когда в сети, которая передает сообщение Membership Report, есть члены данной группы.

• Version 1 Members Present, когда в сети, которая передает сообщение Version 1 Membership Report имеется хотя бы один хост IGMPv1, входящий в эту группу.

• Checking Membership, когда маршрутизатор получил сообщение Leave Group, но еще не получил Membership Report для этой группы.

Существует шесть типов событий, которые могут вызывать смену состояния маршрутизатора:

• v2 report received, когда маршрутизатор получает сообщение Version 2 Membership Report для группы на данном интерфейсе. Корректное сообщение Report должно иметь размер не менее 8 октетов и корректное значение контрольной суммы IGMP.

• v1 report received, когда маршрутизатор получает сообщение Version 1 Membership для группы на данном интерфейсе. Требования к корректности сообщений совпадают с версией 2.

• leave received, когда маршрутизатор получает сообщение IGMP Group Leave для группы на интерфейсе. Корректное сообщение Leave должно иметь размер е менее 8 октетов и корректное значение контрольной суммы IGMP.

• timer expired,когда завершается отсчет по таймеру, установленному для принадлежности к группе.

• retransmit timer expired, когда завершается отсчет по таймеру, установленному для связанного с группой запроса Membership Query.

• v1 host timer expired, когда заканчивается отсчет по таймеру, установленному для обнаружения присутствия в группе хостов версии 1.

В ответ на перечисленные выше события могут выполняться шесть вариантов действий:

• start timer для принадлежности к группе на данном интерфейсе и установка для этого таймера начального значения [Group Membership Interval], если таймер уже запущен.

• start timer* для принадлежности к группе на данном интерфейсе – этот альтернативный вариант действия устанавливает для таймера значение [Last Member Query Interval] * [Last Member Query Count], если данный маршрутизатор относится к типу Querier, или [Max Response Time (из пакета)] * [Last Member Query Count], если маршрутизатор относится к типу non–Querier.

• start retransmit timer для принадлежности к группе на данном интерфейсе (устанавливается значение [Last Member Query Interval]).

• start v1 host timer для принадлежности к группе на данном интерфейсе и сброс таймера в начальное значение [Group Membership Interval], если таймер уже запущен.

• send group–specific query для группы в подключенной сети. Группе, для которой передается запрос, отправляется сообщение Group–Specific Query и устанавливается Max Response Time = [Last Member Query Interval].

• notify routing + уведомляет протокол маршрутизации о наличии членов данной группы в подключенной сети.

• notify routing – уведомляет протокол маршрутизации об отсутствии членов данной группы в подключенной сети.

Диаграмма состояний маршрутизатора Querier показана на рисунке.

 ----------------------------|                |<-----------------------
|                            |                |timer expired           |
|               timer expired|                |(notify routing -,      |
|          (notify routing -)|   No Members   |clear rxmt tmr)         |
|                    ------->|    Present     |<-------                |
|                   |        |                |       |                |
|v1 report rec'd    |        |                |       |  ------------  |
|(notify routing +, |        |________________|       | | rexmt timer| |
| start timer,      |                    |            | |  expired   | |
| start v1 host     |  v2 report received|            | | (send g-s  | |
|  timer)           |  (notify routing +,|            | |  query,    | |
|                   |        start timer)|            | |  st rxmt   | |
|         __________|______              |       _____|_|______  tmr)| |
|        |                 |<------------       |              |     | |
|        |                 |                    |              |<----- |
|        |                 | v2 report received |              |       |
|        |                 | (start timer)      |              |       |
|        | Members Present |<-------------------|    Checking  |       |
|  ----->|                 | leave received     |   Membership |       |
| |      |                 | (start timer*,     |              |       |
| |      |                 |  start rexmt timer,|              |       |
| |      |                 |  send g-s query)   |              |       |
| |  --->|                 |------------------->|              |       |
| | |    |_________________|                    |______________|       |
| | |v2 report rec'd |  |                          |                   |
| | |(start timer)   |  |v1 report rec'd           |v1 report rec'd    |
| |  ----------------   |(start timer,             |(start timer,      |
| |v1 host              | start v1 host timer)     | start v1 host     |
| |tmr    ______________V__                        | timer)            |
| |exp'd |                 |<----------------------                    |
|  ------|                 |                                           |
|        |    Version 1    |timer expired                              |
|        | Members Present |(notify routing -)                         |
 ------->|                 |-------------------------------------------
         |                 |<--------------------
 ------->|_________________| v1 report rec'd     |
| v2 report rec'd |   |   (start timer,          |
| (start timer)   |   |    start v1 host timer)  |
 -----------------     --------------------------

Диаграмма состояний маршрутизатора Non-Querier имеет аналогичный вид, но маршрутизатор non-Querier не передает никаких сообщений и его состояния определяются полученными сообщениями. Отметим, что маршрутизаторы non–Querier не различают сообщений Membership Report версий 1 и 2.

                              ________________
                             |                |
                             |                |
                timer expired|                |timer expired
           (notify routing -)|   No Members   |(notify routing -)
                   --------->|    Present     |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  |                   |report received   |
                  |                   |(notify routing +,|
                  |                   | start timer)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |  report received   |                 |
         |                 |  (start timer)     |                 |
         | Members Present |<-------------------|     Checking    |
         |                 | g-s query rec'd    |    Membership   |
         |                 | (start timer*)     |                 |
    ---->|                 |------------------->|                 |
   |     |_________________|                    |_________________|
   | report received |
   | (start timer)   |
    -----------------

8. Список таймеров и принятые по умолчанию значения

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

8.1. Robustness Variable (устойчивостькошибкам)

Значение Robustness Variable позволяет настроиться на ожидаемую вероятность потери пакетов в подсети. Для подсетей с большей вероятностью потери пакетов устанавливается большее значение Robustness Variable. Протокол IGMP устойчив к потере до (Robustness Variable-1) пакетов. Robustness Variable не может иметь значение 0, не рекомендуется также использовать значение 1. По умолчанию используется значение 2

8.2. Query Interval (интервал между запросами)

Значение Query Interval определяет интервал между передачей запросов General Queries от маршрутизатора Querier. По умолчанию используется значение 125 секунд.

Изменяя значение параметра [Query Interval], администратор может регулировать число сообщений IGMP в масштабе подсети. Большее значение параметра соответствует меньшему числу сообщений IGMP от маршрутизаторов Querier.

8.3. Query Response Interval (интервал между откликами)

Периодические запросы General Query передаются с интервалом Max Response Time. По умолчанию для параметра [Query Response Interval] используется значение 100 (10 секунд)

Изменяя значение параметра [Query Response Interval], администратор может управлять уровнем выбросов трафика IGMP в масштабе подсети (большее значение параметра соответствует меньшим выбросам, а отклики от хостов будут приходить с более продолжительными интервалами). Интервал (в секундах), задаваемый параметром [Query Response Interval], должен быть меньше значения [Query Interval].

8.4. Group Membership Interval (длительность участия в группе)

Параметр Group Membership Interval задает интервал времени, по истечение которого multicast-маршрутизатор принимает решение об отсутствии членов группы в сети. Значение параметра должно определяться, как

 Robustness Variable * Query Interval + Query Response Interval

8.5. Other Querier Present Interval (интервал ожидания другого Querier)

Параметр Other Querier Present Interval задает интервал времени, который должен пройти до того, как multicast-маршрутизатор сможет принять решение об отсутствии других групповых маршрутизаторов, которым следует выполнять функции Querier. Значение параметра должно определяться, как

 Robustness Variable * Query Interval + Query Response Interval/2

8.6. Startup Query Interval (интервал между стартовыми запросами)

Параметр Startup Query Interval задает интервал между сообщениями General Query, передаваемыми маршрутизатором Querier рот старте. По умолчанию используется значение Query Interval/4.

8.7. Startup Query Count (счетчик стартовых запросов)

Параметр Startup Query Count задает число сообщений Query, передаваемых при старте с интервалами Startup Query Interval. По умолчанию совпадает со значением Robustness Variable.

8.8. Last Member Query Interval

Параметр Last Member Query Interval задает интервал Max Response Time (максимальное время отклика), помещаемый в сообщения Group-Specific Query, передаваемые в ответ на сообщения Leave Group, а также интервал между передачей сообщений Group-Specific Query. По умолчанию используется значение 10 (1 секунда)

Это значение можно менять для настройки параметров задержки в сети (leave latency). Уменьшение значения параметра будет снижать продолжительность времени обнаружения потери последнего члена группы.

8.9. Last Member Query Count (число запросов Group-Specific)

Параметр Last Member Query Count задает число сообщений Group-Specific Query, предаваемых до того, как маршрутизатор констатирует отсутствие локальных членов группы. По умолчанию совпадает с Robustness Variable.

8.10. Unsolicited Report Interval (интервал между отчетами без запроса)

Параметр Unsolicited Report задает интервал времени между повторами отчета о принадлежности хоста к группе. По умолчанию 10 секунд.

8.11. Version 1 Router Present Timeout

Параметр Version 1 Router Present Timeout задает интервал ожидания возможности передачи сообщений IGMPv2 после получения запроса Version 1 Query (400 секунд).

9. Получатели сообщений

В таблице приведена классификация описанных в документе сообщений по группам адресатов.

Тип сообщения	Группа адресатов
General Query	ALL-SYSTEMS (224.0.0.1)
Group-Specific Query	Группа, к которой относится запрос
Membership Report	Группа, к которой относится запрос
Leave Message3	ALL-ROUTERS (224.0.0.2)

10. Вопросы безопасности

Ниже рассмотрены возможные последствия поддельных сообщений каждого типа.

Сообщения Query

Обманное сообщение Query от машины, IP-адрес которой меньше текущего значения Querier, будет передавать функции Querier атакующему. Если тот больше не будет передавать сообщений Query, значения параметра Other Querier Present будет ограничивать время существования обманного Querier. В течение этого периода если атакующий будет игнорировать сообщения Leave, трафик может направляться в группы без участников в течение периода [Group Membership Interval].

Обманное сообщение Query, отправленное в группу с участниками, будет заставлять членов группы сообщать о своем участии в группе. Это вызовет дополнительный трафик в ЛВС, но не создаст проблем для протокола.

Сообщения Report

Обманное сообщение Report может вынудить multicast-маршрутизаторы предполагать наличие членов группы в подсети, где их нет. Обманные сообщения Report из локальной подсети не имеют смысла, поскольку присоединение хоста к группе в общем случае не является привилегированной операцией, поэтому локальный пользователь может тривиальным путем добиться того же результата без применения обманных сообщений. Обманные сообщения Report от внешних источников могут создавать некоторые проблемы. Ниже рассмотрены два варианта защиты от них:

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

• Игнорировать сообщение Report без опции Router Alert [RFC 2113] и требовать от маршрутизаторов отказа от пересылки сообщений Report (это не означает требования обобщенной фильтрации на пути пересылки, поскольку пакеты уже имеют опцию Router Alert). Это решение не обеспечивает совместимости с более ранними версиями, которые не требовали использования опции Router Alert.

Обманное сообщение Version 1 Report может перевести маршрутизатор в состояние «version 1 members present» (имеются участники с версией 1), при котором он будет игнорировать сообщения Leave. Это может породить передачу трафика в пустые группы на период до [Group Membership Interval]. Существует два способа защиты от обманных сообщений v1 Report.

• Для защиты от пришедших извне сообщений v1 Report отчеты игнорируются, если нет возможности установить, что пакет получен из подсети, связанной с принявшим его интерфейсом. В этом случае сообщения v1 Reports от мобильных хостов с адресами, не относящимися к данной подсети, будут игнорироваться.

• В конфигурационных параметрах маршрутизаторов устанавливается опция полного игнорирования сообщений Version 1. Это приведет к отказу от автоматической совместимости с хостами Version 1, поэтому таким методом следует пользоваться лишь в случаях критической важности быстрого выхода (fast leave). Данное решение защищает и от обманных пакетов версии 1 из локальной подсети.

Сообщения Leave

Обменное сообщение Leave может вынудить Querier передавать запросы Group-Specific для соответствующей группы. Это повышает нагрузку на каждый маршрутизатор и всех участников группы, но не вызывает потерь легитимного трафика. Существует два способа защиты от обманных сообщений Leave, полученных извне.

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

• Игнорировать сообщения Leave без опции Router Alert [RFC 2113] и требовать от маршрутизаторов отказа от пересылки сообщений Leave (это не означает требования обобщенной фильтрации на пути пересылки, поскольку пакеты уже имеют опцию Router Alert). Это решение не обеспечивает совместимости с более ранними версиями, которые не требовали использования опции Router Alert.

11. Подтверждение авторства

Разработчиками протокола IGMPv2 являются RosenSharma и SteveDeering.

12. Литература

RFC 2119 Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

RFC 2113 Katz, D., “IP Router Alert Option,” RFC 2113, February 1997.

RFC 1112 Deering, S., “Host Extensions for IP Multicasting”, STD 5, RFC 1112, August 1989.

13. Приложение I – отличия от IGMPv1

Поля Version и Type, использованные в IGMPv1, объединены в одно полу Type.

Для сообщений Version 2 Membership Report выделены новые значения IGMP Type, позволяющие маршрутизаторам различать отчеты хостов IGMPv1 и IGMPv2.

Для сообщений IGMPv2 Leave Group выделено новое значение IGMP Type.

Сообщение Membership Query изменено с включением в неиспользуемое поле нового значения Max Response Time. Спецификация IGMPv2 задает механизм выбора запрашивающего (Querier). В IGMPv1 этот выбор был отдан на откуп протоколу групповой маршрутизации и для разных механизмов применялись разные протоколы. Это могло приводить к появлению в сети нескольких запрашивающих, поэтому в IGMPv2 был добавлен механизм выбора. Однако это влечет за собой необходимость мер предосторожности для случаев, когда маршрутизатор IGMPv2 пытается сосуществовать с маршрутизатором IGMPv1, использующим другой механизм выбора. В частности, это означает, что маршрутизатор IGMPv2 должен поддерживать возможность работы в режиме IGMPv1 для конкретной сети, если это задано в конфигурации. Требуемые действия включают:

• установить во всех запросах Max Response Time = 0;

• игнорировать сообщения Leave Group.

Спецификация IGMPv2 смягчает требования к проверке корректности сообщений Membership Query и Membership Report. При обновлении реализации следует удалять все проверки, которые больше не требуются.

Спецификация IGMPv2 требует наличия опции IP Router Alert [RFC 2113] во всех пакетах, описанных в данном документе.

14. Адресавтора

William C. Fenner

Xerox PARC

3333 Coyote Hill Road

Palo Alto, CA 94304

Phone: +1 650 812 4816

EMail: fenner@parc.xerox.com

---

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

15. Полное заявление авторских прав

Copyright (C) The Internet Society (1997). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских паравах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.