RFC 3376 - 互联网组管理协议, 第3版
- 状态: Proposed Standard
- 发布日期: October 2002
- Stream: IETF
- 更新了: RFC2236
- 被废弃: RFC9776
- 勘误: 无勘误
本备忘录的状态
本文档规定了互联网社区的互联网标准跟踪协议, 并请求讨论和改进建议. 请参考当前版本的 "Internet Official Protocol Standards" (STD 1) 以了解本协议的标准化状态. 本备忘录的分发不受限制.
版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
摘要
本文档规定了互联网组管理协议 (Internet Group Management Protocol, IGMPv3) 的第3版. IGMP 是 IPv4 系统用于向相邻组播路由器报告其 IP 组播组成员关系的协议. IGMP 第3版增加了对"源过滤 (source filtering)"的支持, 即系统能够报告只对接收来自特定源地址的数据包感兴趣, 或者对接收来自除特定源地址之外的所有源地址发送到特定组播地址的数据包感兴趣. 该信息可被组播路由协议用于避免将来自特定源的组播数据包传递到没有感兴趣接收者的网络.
本文档废弃了 RFC 2236.
目录
- 1. 简介
- 2. 请求 IP 组播接收的服务接口
- 3. 系统维护的组播接收状态
- 4. 消息格式
- 5. 组成员的协议描述
- 6. 组播路由器的协议描述
- 7. 与旧版本 IGMP 的互操作
- 8. 定时器、计数器及其默认值列表
- 9. 安全考虑
- 10. IANA 考虑
- 11. 致谢
- 12. 参考文献
- 附录 A. 设计原理
- 附录 B. 与 IGMPv2 的变更摘要
- 作者地址
1. 简介
互联网组管理协议 (Internet Group Management Protocol, IGMP) 由 IPv4 系统 (主机和路由器) 用于向任何相邻的组播路由器报告其 IP 组播组成员关系. 请注意, IP 组播路由器本身也可能是一个或多个组播组的成员, 在这种情况下, 它同时执行协议的"组播路由器部分" (收集其组播路由协议所需的成员信息) 和协议的"组成员部分" (向自己和其他相邻的组播路由器通知其成员关系).
IGMP 还用于其他 IP 组播管理功能, 使用的消息类型不同于用于组成员关系报告的消息类型. 本文档仅指定组成员关系报告功能和消息.
本文档规定了 IGMP 的第3版. 第1版在 [RFC-1112] 中规定, 是第一个广泛部署的版本, 也是第一个成为互联网标准的版本. 第2版在 [RFC-2236] 中规定, 增加了对"低离开延迟 (low leave latency)" 的支持, 即缩短了组播路由器了解到连接网络上不再有特定组成员所需的时间. 第3版增加了对"源过滤 (source filtering)" 的支持, 即系统能够报告只对接收来自特定源地址的数据包感兴趣 (这是支持源特定组播 [SSM] 所必需的), 或者对接收来自除特定源地址之外的所有源地址发送到特定组播地址的数据包感兴趣. 第3版设计为与第1版和第2版可互操作.
组播侦听器发现 (Multicast Listener Discovery, MLD) 以类似方式由 IPv6 系统使用. MLD 第1版 [MLD] 实现了 IGMP 第2版的功能; MLD 第2版 [MLDv2] 实现了 IGMP 第3版的功能.
本文档中大写的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 [RFC-2119] 中描述的方式解释. 由于缺少斜体, 本文档中通过在单词或短语两侧使用 "*" 字符来表示强调.
2. 请求 IP 组播接收的服务接口
在 IP 系统内, 存在一个 (至少在概念上) 服务接口, 上层协议或应用程序使用该接口要求 IP 层启用和禁用接收发送到特定 IP 组播地址的数据包. 为了充分利用 IGMPv3 的功能, 系统的 IP 服务接口必须支持以下操作:
IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list )
其中:
-
"socket" 是一个特定于实现的参数, 用于区分系统内不同的请求实体 (例如, 程序或进程); BSD Unix 系统调用的 socket 参数就是一个具体示例.
-
"interface" 是网络接口的本地标识符, 在该接口上要启用或禁用对指定组播地址的接收. 接口可以是物理的 (例如, 以太网接口) 或虚拟的 (例如, 帧中继虚拟电路的端点或 IP-in-IP "隧道" 的端点). 实现可以允许将特殊的 "未指定" 值作为接口参数传递, 在这种情况下, 请求将应用于系统的 "主" 或 "默认" 接口 (可能由系统配置建立). 如果希望在多个接口上接收相同的组播地址, 则需要为每个所需的接口分别调用 IPMulticastListen.
-
"multicast-address" 是请求所针对的 IP 组播地址或组. 如果希望在给定接口上接收多个组播地址, 则需要为每个所需的组播地址分别调用 IPMulticastListen.
-
"filter-mode" 可以是 INCLUDE 或 EXCLUDE. 在 INCLUDE 模式下, 只请求接收从 source-list 参数中列出的那些 IP 源地址发送到指定组播地址的数据包. 在 EXCLUDE 模式下, 请求接收从除 source-list 参数中列出的源地址之外的所有 IP 源地址发送到给定组播地址的数据包.
-
"source-list" 是一个无序列表, 包含零个或多个 IP 单播地址, 根据过滤模式的不同, 期望或不期望从这些地址接收组播. 实现可以对源列表的大小施加限制, 但该限制不得小于每个列表64个地址. 当操作导致超过源列表大小限制时, 服务接口必须返回错误.
对于给定的 socket、interface 和 multicast-address 组合, 在任何时候只能有一个过滤模式和源列表生效. 但是, 可以通过后续指定相同 socket、interface 和 multicast-address 的 IPMulticastListen 请求来更改过滤模式或源列表, 或两者都更改. 每个后续请求完全替换给定 socket、interface 和 multicast-address 的任何早期请求.
IGMP 的早期版本不支持源过滤器, 并且具有更简单的服务接口, 包括 Join 和 Leave 操作, 用于在给定接口上启用和禁用接收给定组播地址 (来自所有源) 的数据包. 新服务接口中的等效操作如下:
Join 操作等效于
IPMulticastListen ( socket, interface, multicast-address,
EXCLUDE, {} )
Leave 操作等效于:
IPMulticastListen ( socket, interface, multicast-address,
INCLUDE, {} )
其中 {} 是一个空源列表.
[FILTER-API] 中有一个提供本服务接口中概述功能的 API 示例.
3. 系统维护的组播接收状态
3.1. 套接字状态
对于已调用 IPMulticastListen 的每个套接字 (socket), 系统记录该套接字所需的组播接收状态. 该状态在概念上由一组以下形式的记录组成:
(interface, multicast-address, filter-mode, source-list)
套接字状态根据在套接字上每次调用 IPMulticastListen 而演化, 如下所示:
-
如果请求的过滤模式是 INCLUDE 且请求的源列表为空, 则删除与请求的接口和组播地址对应的条目 (如果存在). 如果不存在这样的条目, 则忽略该请求.
-
如果请求的过滤模式是 EXCLUDE 或请求的源列表非空, 则更改与请求的接口和组播地址对应的条目 (如果存在) 以包含请求的过滤模式和源列表. 如果不存在这样的条目, 则使用请求中指定的参数创建新条目.
3.2. 接口状态
除了每个套接字的组播接收状态外, 系统还必须为其每个接口维护或计算组播接收状态. 该状态在概念上由一组以下形式的记录组成:
(multicast-address, filter-mode, source-list)
对于给定接口, 每个组播地址最多存在一条记录. 此每接口状态派生自每套接字状态, 但当不同套接字对同一组播地址和接口具有不同的过滤模式和/或源列表时, 可能与每套接字状态不同. 例如, 假设一个应用程序或进程在套接字 s1 上调用以下操作:
IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
请求在接口 i 上接收发送到组播地址 m 的数据包, 仅当它们来自源 a、b 或 c 时. 假设另一个应用程序或进程在套接字 s2 上调用以下操作:
IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
请求在同一接口 i 上接收发送到同一组播地址 m 的数据包, 仅当它们来自源 b、c 或 d 时. 为了满足两个套接字的接收要求, 接口 i 必须接收从源 a、b、c 或 d 中的任何一个发送到 m 的数据包. 因此, 在此示例中, 接口 i 对于组播地址 m 的接收状态具有过滤模式 INCLUDE 和源列表 {a, b, c, d}.
在 IP 层从接口接受组播数据包之后, 其后续传递到侦听特定套接字的应用程序或进程取决于该套接字的组播接收状态 [并且可能还取决于其他条件, 例如套接字绑定到哪个传输层端口]. 因此, 在上面的示例中, 如果一个数据包到达接口 i, 目的地为组播地址 m, 源地址为 a, 它将在套接字 s1 上传递, 但不在套接字 s2 上. 请注意, IGMP 查询 (Query) 和报告 (Report) 不受源过滤的影响, 必须始终由主机和路由器处理.
基于套接字的组播接收状态过滤数据包是此服务接口的新功能. 以前的服务接口 [RFC1112] 没有描述基于组播加入状态的过滤; 相反, 在套接字上的加入只是导致主机在给定接口上加入一个组, 并且发往该组的数据包可以传递到所有套接字, 无论它们是否已加入.
从每套接字状态派生每接口状态的一般规则如下: 对于出现在任何套接字状态中的每个不同的 (interface, multicast-address) 对, 在该接口上为该组播地址创建一个每接口记录. 考虑包含相同 (interface, multicast-address) 对的所有套接字记录,
- 如果任何此类记录的过滤模式为 EXCLUDE, 则接口记录的过滤模式为 EXCLUDE, 接口记录的源列表是所有处于 EXCLUDE 模式的套接字记录的源列表的交集, 减去出现在任何处于 INCLUDE 模式的套接字记录中的那些源地址. 例如, 如果接口 i 上组播地址 m 的套接字记录是:
来自套接字 s1: ( i, m, EXCLUDE, {a, b, c, d} )
来自套接字 s2: ( i, m, EXCLUDE, {b, c, d, e} )
来自套接字 s3: ( i, m, INCLUDE, {d, e, f} )
则接口 i 上相应的接口记录是:
( m, EXCLUDE, {b, c} )
如果添加第四个套接字, 例如:
来自套接字 s4: ( i, m, EXCLUDE, {} )
则接口记录变为:
( m, EXCLUDE, {} )
- 如果所有此类记录的过滤模式都是 INCLUDE, 则接口记录的过滤模式为 INCLUDE, 接口记录的源列表是所有套接字记录的源列表的并集. 例如, 如果接口 i 上组播地址 m 的套接字记录是:
来自套接字 s1: ( i, m, INCLUDE, {a, b, c} )
来自套接字 s2: ( i, m, INCLUDE, {b, c, d} )
来自套接字 s3: ( i, m, INCLUDE, {e, f} )
则接口 i 上相应的接口记录是:
( m, INCLUDE, {a, b, c, d, e, f} )
当该组的所有套接字都处于 INCLUDE 状态时, 实现不得使用 EXCLUDE 接口记录来表示该组. 如果在计算接口状态源列表时达到系统资源限制, 则必须向请求操作的应用程序返回错误.
每当 IPMulticastListen 调用通过添加、删除或修改每套接字状态记录来修改套接字状态时, 就会 (重新) 评估上述派生接口状态的规则. 请注意, 套接字状态的更改不一定导致接口状态的更改.
4. 消息格式
IGMP 消息封装在 IPv4 数据报中, IP 协议号为 2. 本文档中描述的每个 IGMP 消息都以 IP 生存时间 (Time-to-Live) 为 1、IP 优先级为互联网控制 (Internetwork Control, 例如服务类型 0xc0) 发送, 并在其 IP 头部中携带 IP 路由器警告选项 (Router Alert option) [RFC-2113]. IGMP 消息类型由 IANA [IANA-REG] 注册, 如 [RFC-3228] 所述.
本文档中描述的 IGMPv3 协议涉及两种 IGMP 消息类型:
| 类型编号 (十六进制) | 消息名称 |
|---|---|
| 0x11 | 成员查询 (Membership Query) |
| 0x22 | 第3版成员报告 (Version 3 Membership Report) |
IGMPv3 的实现还必须支持以下三种消息类型, 以便与 IGMP 的早期版本互操作 (参见第7节):
| 类型编号 (十六进制) | 消息名称 | 参考文献 |
|---|---|---|
| 0x12 | 第1版成员报告 (Version 1 Membership Report) | [RFC-1112] |
| 0x16 | 第2版成员报告 (Version 2 Membership Report) | [RFC-2236] |
| 0x17 | 第2版离开组 (Version 2 Leave Group) | [RFC-2236] |
无法识别的消息类型必须被静默忽略. 其他消息类型可能由 IGMP 的更新版本或扩展、组播路由协议或其他用途使用.
在本文档中, 除非另有说明, 大写单词 "Query" 和 "Report" 分别指 IGMP 成员查询和 IGMP 第3版成员报告.
4.1. 成员查询消息
成员查询由 IP 组播路由器发送, 用于查询相邻接口的组播接收状态. 查询具有以下格式:
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 = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- . -+
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Max Resp Code (最大响应代码)
Max Resp Code 字段指定在发送响应报告之前允许的最长时间. 实际允许的时间称为最大响应时间 (Max Resp Time), 以 1/10 秒为单位表示, 并按如下方式从 Max Resp Code 派生:
如果 Max Resp Code < 128, 则 Max Resp Time = Max Resp Code
如果 Max Resp Code >= 128, 则 Max Resp Code 表示浮点值如下:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
Max Resp Time = (mant | 0x10) << (exp + 3)
较小的 Max Resp Time 值允许 IGMPv3 路由器调整"离开延迟" (从最后一个主机离开组到路由协议被通知不再有成员之间的时间). 较大的值, 特别是在指数范围内, 允许调整网络上 IGMP 流量的突发性.
4.1.2. Checksum (校验和)
校验和是整个 IGMP 消息 (整个 IP 负载) 的反码和的 16 位反码. 在计算校验和时, 校验和字段设置为零. 在接收数据包时, 必须在处理数据包之前验证校验和. [RFC-1071]
4.1.3. Group Address (组地址)
在发送通用查询 (General Query) 时, 组地址字段设置为零; 在发送组特定查询 (Group-Specific Query) 或组和源特定查询 (Group-and-Source-Specific Query) 时, 设置为被查询的 IP 组播地址 (参见下面的第 4.1.9 节).
4.1.4. Resv (保留字段)
Resv 字段在传输时设置为零, 在接收时忽略.
4.1.5. S Flag (抑制路由器端处理标志)
当设置为 1 时, S 标志向任何接收的组播路由器指示它们应抑制在听到查询时执行的正常定时器更新. 但是, 它不会抑制查询者选举或路由器作为组成员可能需要执行的查询的正常"主机端"处理.
4.1.6. QRV (查询者的鲁棒性变量)
如果非零, QRV 字段包含查询者 (即查询的发送者) 使用的 [鲁棒性变量 (Robustness Variable)] 值. 如果查询者的 [鲁棒性变量] 超过 7 (QRV 字段的最大值), 则 QRV 设置为零. 路由器采用从最近接收的查询中获得的 QRV 值作为它们自己的 [鲁棒性变量] 值, 除非最近接收的 QRV 为零, 在这种情况下, 接收者使用第 8.1 节中指定的默认 [鲁棒性变量] 值或静态配置的值.
4.1.7. QQIC (查询者的查询间隔代码)
查询者的查询间隔代码字段指定查询者使用的 [查询间隔 (Query Interval)]. 实际间隔称为查询者的查询间隔 (QQI), 以秒为单位表示, 并按如下方式从查询者的查询间隔代码派生:
如果 QQIC < 128, 则 QQI = QQIC
如果 QQIC >= 128, 则 QQIC 表示浮点值如下:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
QQI = (mant | 0x10) << (exp + 3)
不是当前查询者的组播路由器采用从最近接收的查询中获得的 QQI 值作为它们自己的 [查询间隔] 值, 除非最近接收的 QQI 为零, 在这种情况下, 接收路由器使用第 8.2 节中指定的默认 [查询间隔] 值.
4.1.8. Number of Sources (N) (源数量)
源数量 (N) 字段指定查询中存在多少个源地址. 在通用查询或组特定查询中, 此数字为零; 在组和源特定查询中为非零. 此数字受传输查询的网络 MTU 的限制. 例如, 在 MTU 为 1500 字节的以太网上, 包括路由器警告选项的 IP 头部占用 24 字节, 包括源数量 (N) 字段在内的 IGMP 字段占用 12 字节, 剩下 1464 字节用于源地址, 这将源地址数量限制为 366 个 (1464/4).
4.1.9. Source Address [i] (源地址)
源地址 [i] 字段是一个包含 n 个 IP 单播地址的向量, 其中 n 是源数量 (N) 字段中的值.
4.1.10. Additional Data (附加数据)
如果接收到的查询的 IP 头部中的数据包长度字段指示除此处描述的字段之外还存在其他数据字节, IGMPv3 实现必须在计算中包括这些字节以验证接收到的 IGMP 校验和, 但必须忽略这些附加字节. 在发送查询时, IGMPv3 实现不得包括此处描述的字段之外的附加字节.
4.1.11. Query Variants (查询变体)
查询消息有三种变体:
-
"通用查询 (General Query)" 由组播路由器发送, 用于了解相邻接口的完整组播接收状态 (即, 连接到传输查询的网络的接口). 在通用查询中, 组地址字段和源数量 (N) 字段都为零.
-
"组特定查询 (Group-Specific Query)" 由组播路由器发送, 用于了解相邻接口相对于单个组播地址的接收状态. 在组特定查询中, 组地址字段包含感兴趣的组播地址, 源数量 (N) 字段包含零.
-
"组和源特定查询 (Group-and-Source-Specific Query)" 由组播路由器发送, 用于了解是否有任何相邻接口希望接收从指定源列表中的任何源发送到指定组播地址的数据包. 在组和源特定查询中, 组地址字段包含感兴趣的组播地址, 源地址 [i] 字段包含感兴趣的源地址.
4.1.12. IP Destination Addresses for Queries (查询的 IP 目标地址)
在 IGMPv3 中, 通用查询以 IP 目标地址 224.0.0.1 (全系统组播地址) 发送. 组特定查询和组和源特定查询以等于感兴趣的组播地址的 IP 目标地址发送. 但是, 系统必须接受和处理 IP 目标地址字段包含分配给查询到达的接口的任何地址 (单播或组播) 的任何查询.
4.2. 第3版成员报告消息
第3版成员报告由 IP 系统发送, 用于向相邻路由器报告其接口的当前组播接收状态或组播接收状态的变化. 报告具有以下格式:
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 = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
其中每个组记录 (Group Record) 具有以下内部格式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- -+
. . .
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.1. Reserved (保留字段)
保留字段在传输时设置为零, 在接收时忽略.
4.2.2. Checksum (校验和)
校验和是整个 IGMP 消息 (整个 IP 负载) 的反码和的 16 位反码. 在计算校验和时, 校验和字段设置为零. 在接收数据包时, 必须在处理消息之前验证校验和.
4.2.3. Number of Group Records (M) (组记录数量)
组记录数量 (M) 字段指定此报告中存在多少个组记录.
4.2.4. Group Record (组记录)
每个组记录是一个字段块, 包含与发送者在发送报告的接口上对单个组播组的成员关系有关的信息.
4.2.5. Record Type (记录类型)
参见下面的第 4.2.12 节.
4.2.6. Aux Data Len (辅助数据长度)
Aux Data Len 字段包含此组记录中辅助数据字段的长度, 以 32 位字为单位. 它可以包含零, 以指示不存在任何辅助数据.
4.2.7. Number of Sources (N) (源数量)
源数量 (N) 字段指定此组记录中存在多少个源地址.
4.2.8. Multicast Address (组播地址)
组播地址字段包含此组记录所涉及的 IP 组播地址.
4.2.9. Source Address [i] (源地址)
源地址 [i] 字段是一个包含 n 个 IP 单播地址的向量, 其中 n 是此记录的源数量 (N) 字段中的值.
4.2.10. Auxiliary Data (辅助数据)
辅助数据字段 (如果存在) 包含与此组记录有关的附加信息. 本文档中指定的协议 IGMPv3 不定义任何辅助数据. 因此, IGMPv3 的实现不得在任何传输的组记录中包含任何辅助数据 (即, 必须将 Aux Data Len 字段设置为零), 并且必须忽略任何接收的组记录中存在的任何辅助数据. 辅助数据字段的语义和内部编码将由使用此字段的 IGMP 的任何未来版本或扩展定义.
4.2.11. Additional Data (附加数据)
如果接收到的报告的 IP 头部中的数据包长度字段指示除最后一个组记录之外还存在其他数据字节, IGMPv3 实现必须在计算中包括这些字节以验证接收到的 IGMP 校验和, 但必须忽略这些附加字节. 在发送报告时, IGMPv3 实现不得包括最后一个组记录之外的附加字节.
4.2.12. Group Record Types (组记录类型)
报告消息中可以包含多种不同类型的组记录:
-
"当前状态记录 (Current-State Record)" 由系统在接口上接收到查询时发送. 它报告该接口相对于单个组播地址的当前接收状态. 当前状态记录的记录类型可以是以下两个值之一:
值 名称和含义 1 MODE_IS_INCLUDE - 表示接口对于指定的组播地址具有 INCLUDE 过滤模式. 如果非空, 此组记录中的源地址 [i] 字段包含接口对于指定组播地址的源列表. 2 MODE_IS_EXCLUDE - 表示接口对于指定的组播地址具有 EXCLUDE 过滤模式. 如果非空, 此组记录中的源地址 [i] 字段包含接口对于指定组播地址的源列表. -
"过滤模式变更记录 (Filter-Mode-Change Record)" 由系统在本地调用 IPMulticastListen 导致特定组播地址的接口级状态条目的过滤模式发生变化 (即, 从 INCLUDE 变为 EXCLUDE, 或从 EXCLUDE 变为 INCLUDE) 时发送. 该记录包含在从发生变化的接口发送的报告中. 过滤模式变更记录的记录类型可以是以下两个值之一:
值 名称和含义 3 CHANGE_TO_INCLUDE_MODE - 表示接口已更改为指定组播地址的 INCLUDE 过滤模式. 如果非空, 此组记录中的源地址 [i] 字段包含接口对于指定组播地址的新源列表. 4 CHANGE_TO_EXCLUDE_MODE - 表示接口已更改为指定组播地址的 EXCLUDE 过滤模式. 如果非空, 此组记录中的源地址 [i] 字段包含接口对于指定组播地址的新源列表. -
"源列表变更记录 (Source-List-Change Record)" 由系统在本地调用 IPMulticastListen 导致特定组播地址的接口级状态条目的源列表发生变化 (不伴随过滤模式变化) 时发送. 该记录包含在从发生变化的接口发送的报告中. 源列表变更记录的记录类型可以是以下两个值之一:
值 名称和含义 5 ALLOW_NEW_SOURCES - 表示此组记录中的源地址 [i] 字段包含系统希望接收的附加源列表, 用于发送到指定组播地址的数据包. 如果变化是对 INCLUDE 源列表的变化, 这些是添加到列表中的地址; 如果变化是对 EXCLUDE 源列表的变化, 这些是从列表中删除的地址. 6 BLOCK_OLD_SOURCES - 表示此组记录中的源地址 [i] 字段包含系统不再希望接收的源列表, 用于发送到指定组播地址的数据包. 如果变化是对 INCLUDE 源列表的变化, 这些是从列表中删除的地址; 如果变化是对 EXCLUDE 源列表的变化, 这些是添加到列表中的地址.
如果源列表的变化导致同时允许新源和阻止旧源, 则为同一组播地址发送两个组记录, 一个类型为 ALLOW_NEW_SOURCES, 一个类型为 BLOCK_OLD_SOURCES.
我们使用术语"状态变更记录 (State-Change Record)" 来指代过滤模式变更记录或源列表变更记录.
无法识别的记录类型值必须被静默忽略.
4.2.13. IP Source Addresses for Reports (报告的 IP 源地址)
IGMP 报告使用目标子网的有效 IP 源地址发送. 尚未获得 IP 地址的系统可以使用 0.0.0.0 源地址. 请注意, LAN 上的多个系统可能同时使用 0.0.0.0 源地址. 路由器必须接受源地址为 0.0.0.0 的报告.
4.2.14. IP Destination Addresses for Reports (报告的 IP 目标地址)
第3版报告以 IP 目标地址 224.0.0.22 发送, 所有支持 IGMPv3 的组播路由器都侦听该地址. 在第1版或第2版兼容模式下运行的系统将第1版或第2版报告发送到报告的组地址字段中指定的组播组. 此外, 系统必须接受和处理 IP 目标地址字段包含分配给报告到达的接口的任何地址 (单播或组播) 的任何第1版或第2版报告.
4.2.15. Notation for Group Records (组记录的符号表示)
在本文档的其余部分, 我们使用以下符号来描述与特定组播地址有关的组记录的内容:
IS_IN ( x ) - 类型 MODE_IS_INCLUDE, 源地址 x
IS_EX ( x ) - 类型 MODE_IS_EXCLUDE, 源地址 x
TO_IN ( x ) - 类型 CHANGE_TO_INCLUDE_MODE, 源地址 x
TO_EX ( x ) - 类型 CHANGE_TO_EXCLUDE_MODE, 源地址 x
ALLOW ( x ) - 类型 ALLOW_NEW_SOURCES, 源地址 x
BLOCK ( x ) - 类型 BLOCK_OLD_SOURCES, 源地址 x
其中 x 是:
-
一个大写字母 (例如, "A") 表示源地址集合, 或
-
一个集合表达式 (例如, "A+B"), 其中 "A+B" 表示集合 A 和 B 的并集, "A*B" 表示集合 A 和 B 的交集, "A-B" 表示从集合 A 中删除集合 B 的所有元素.
4.2.16. Membership Report Size (成员报告大小)
如果报告中所需的组记录集不适合单个报告消息的大小限制 (由将发送该报告的网络的 MTU 确定), 则组记录将在所需数量的报告消息中发送, 以报告整个集合.
如果单个组记录包含的源地址太多以至于不适合单个报告消息的大小限制, 如果其类型不是 MODE_IS_EXCLUDE 或 CHANGE_TO_EXCLUDE_MODE, 则将其拆分为多个组记录, 每个组记录包含源地址的不同子集, 并在单独的报告消息中发送. 如果其类型是 MODE_IS_EXCLUDE 或 CHANGE_TO_EXCLUDE_MODE, 则发送单个组记录, 包含尽可能多的源地址, 剩余的源地址不报告; 尽管要报告哪些源的选择是任意的, 但最好在每次后续报告中报告相同的源集, 而不是每次报告不同的源.
5. 组成员的协议描述
IGMP 是一个非对称协议, 为组成员 (希望接收组播数据包的主机或路由器) 和组播路由器 (侦听 IGMP 消息并协调组播转发) 指定不同的行为. 本节描述适用于组成员的 IGMPv3 部分. (请注意, 路由器也可能是组成员.)
系统在支持组播接收的每个接口上执行本节中描述的协议. 每个接口上的协议涉及对两种类型事件的即时处理:
-
接口上组播接收状态的变化, 由本地调用 IPMulticastListen 定义引起.
-
接收到成员查询消息.
5.1. 接口状态变化时的操作
根据第 3.2 节中的规则, 调用 IPMulticastListen 可能导致接口的组播接收状态发生变化. 每次此类变化都会影响单个组播组地址的每接口状态.
接口状态的变化导致系统立即从该接口传输状态变更报告 (State Change Report). 状态变更报告的类型和内容按如下方式确定:
-
如果状态变化不显著, 例如组的过滤模式从 INCLUDE 移动到 INCLUDE 或从 EXCLUDE 移动到 EXCLUDE, 且源地址集保持不变, 则不生成报告.
-
如果状态变化显著, 则生成状态变更报告. 报告包含状态已变化的组的单个组记录. 组记录的类型和内容通过比较旧状态 (变化前的状态) 与新状态 (变化后的状态) 来确定, 如下表所示:
旧状态 新状态 发送的状态变更记录 INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B) EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) INCLUDE (A) EXCLUDE (B) TO_EX (B) EXCLUDE (A) INCLUDE (B) TO_IN (B) 符号 "ALLOW (B-A)" 表示状态变更记录携带一个源列表, 包含集合 B 中但不在集合 A 中的所有源地址. 符号 "BLOCK (A-B)" 表示状态变更记录携带一个源列表, 包含集合 A 中但不在集合 B 中的所有源地址.
如果为 ALLOW 或 BLOCK 记录计算的源列表为空, 则该记录将从状态变更报告中省略.
为确保状态变更报告被网络上的所有组播路由器接收, 系统以从范围 (0, [Unsolicited Report Interval]) 中选择的随机间隔重传报告 [Robustness Variable] - 1 次. [Robustness Variable] 是一个可调参数, 默认值为 2. [Unsolicited Report Interval] 也是一个可调参数, 默认值为 10 秒.
如果状态变更报告已计划传输, 并且接收到会导致生成当前状态报告 (Current State Report) 的查询 (参见第 5.2 节), 则丢弃待处理的状态变更报告, 改为发送当前状态报告. 当前状态报告必须包含状态变更报告中本应包含的所有信息.
5.2. 接收查询时的操作
当系统接收到查询时, 它首先检查查询是否有效. 要有效, 查询必须:
- 至少为 12 个字节长,
- 具有正确的 IP 校验和,
- 具有等于全系统组播地址 (224.0.0.1) 或被查询的特定组地址的目标 IP 地址.
如果查询无效, 则忽略它. 如果查询有效, 系统执行以下操作:
- 如有必要, 更新其查询者的定时器 (参见第 6 节).
- 确定是否需要响应查询.
以下小节描述响应不同类型查询的规则.
5.2.1. 接收通用查询时的操作
收到通用查询后, 系统检查每个接口以查看是否有任何组的任何组播接收状态. 对于具有状态的每个组, 系统计划发送当前状态报告.
报告包含该组的组记录. 如果该组的过滤模式为 INCLUDE, 则组记录的类型为 MODE_IS_INCLUDE; 如果过滤模式为 EXCLUDE, 则为 MODE_IS_EXCLUDE. 组记录中的源列表包含该组的源地址集.
报告计划在从范围 (0, [Max Resp Time]) 中选择的随机时间发送, 其中 [Max Resp Time] 是查询的 Max Resp Code 字段中指定的值.
5.2.2. 接收组特定查询时的操作
收到组特定查询后, 系统检查是否有查询中指定的组地址的任何组播接收状态. 如果没有, 则忽略查询.
如果该组存在状态, 系统计划发送当前状态报告. 报告包含该组的组记录, 按第 5.2.1 节所述构造.
报告计划在从范围 (0, [Max Resp Time]) 中选择的随机时间发送.
5.2.3. 接收组和源特定查询时的操作
收到组和源特定查询后, 系统检查是否有查询中指定的组地址的任何组播接收状态. 如果没有, 则忽略查询.
如果该组存在状态, 系统确定是否对查询中指定的任何源地址感兴趣. 系统对源地址感兴趣的条件是:
- 该组的过滤模式为 EXCLUDE, 或
- 该组的过滤模式为 INCLUDE 且源地址在源列表中.
如果系统对至少一个源地址感兴趣, 它计划发送当前状态报告. 报告包含该组的组记录, 按第 5.2.1 节所述构造.
报告计划在从范围 (0, [Max Resp Time]) 中选择的随机时间发送.
5.2.4. 接收设置了 "S" 标志的查询时的操作
如果接收到的查询中设置了 "S" (抑制路由器端处理) 标志, 系统不更新其查询者的定时器. 但是, 它仍按第 5.2.1 至 5.2.3 节所述响应查询.
6. 组播路由器的协议描述
IGMP 的目的是使每个组播路由器能够了解其每个直接连接的网络上哪些组播地址有侦听者. IGMPv3 还允许组播路由器了解侦听者感兴趣的源.
6.1. 查询者选举的条件
IGMPv3 与 IGMPv2 一致认为每个网络应该只有一个查询者 (Querier). 但是, IGMPv3 查询者和 IGMPv2 查询者可以在同一网络上共存. 选举协议与 IGMPv2 中相同:
- 最初, 每个组播路由器在其每个连接的网络上都作为查询者启动.
- 如果组播路由器听到来自具有较低 IP 地址的路由器的查询消息, 它必须在该网络上成为非查询者 (Non-Querier).
- 如果组播路由器在 [Other Querier Present Interval] 内未听到来自具有较低 IP 地址的路由器的查询消息, 它将恢复查询者的角色.
6.2. 查询者接收查询时的操作
当查询者接收到查询消息时, 它检查查询的源 IP 地址.
- 如果源 IP 地址低于其自己的 IP 地址, 路由器成为非查询者.
- 如果源 IP 地址大于其自己的 IP 地址, 路由器继续作为查询者.
- 如果源 IP 地址等于其自己的 IP 地址, 则忽略查询 (这是反射或环回).
6.3. 查询的发送
查询者定期发送通用查询以征求成员信息. 当它接收到某些类型的状态变更报告时, 它还发送组特定查询或组和源特定查询.
6.3.1. 通用查询
查询者定期向全系统组播地址 (224.0.0.1) 发送通用查询. 默认 [Query Interval] 为 125 秒.
通用查询用于刷新所有组和源的成员信息.
6.3.2. 组特定查询
当查询者接收到指示系统已离开组的状态变更报告 (例如, 过滤模式从 EXCLUDE 更改为 INCLUDE, 或源列表更改阻止了某个源) 时, 它向组地址发送组特定查询.
此查询用于确定是否有任何剩余系统对该组感兴趣.
6.3.3. 组和源特定查询
当查询者接收到指示系统不再对组的特定源感兴趣的状态变更报告 (例如, 阻止特定源) 时, 它发送组和源特定查询.
此查询用于确定是否有任何剩余系统对这些特定源感兴趣.
6.4. 报告的接收
组播路由器根据它们接收到的报告记录每个组和源的接收状态. 该状态按接口维护.
6.4.1. 当前状态记录的接收
当路由器接收到当前状态记录时, 它更新其组/源定时器.
- 如果记录是 MODE_IS_INCLUDE, 路由器刷新列出的源的定时器.
- 如果记录是 MODE_IS_EXCLUDE, 路由器刷新组定时器和排除的源 (如果有) 的定时器.
6.4.2. 过滤模式变更记录的接收
当路由器接收到过滤模式变更记录时, 它更新过滤模式和定时器.
- CHANGE_TO_INCLUDE_MODE: 如果路由器尚未处于 INCLUDE 模式, 则切换到 INCLUDE 模式, 并更新源定时器.
- CHANGE_TO_EXCLUDE_MODE: 路由器切换到 EXCLUDE 模式并更新组定时器.
6.4.3. 源列表变更记录的接收
当路由器接收到源列表变更记录时, 它更新源定时器.
- ALLOW_NEW_SOURCES: 路由器将新源添加到其列表并启动它们的定时器.
- BLOCK_OLD_SOURCES: 路由器可能会查询以查看其他系统是否仍然需要这些源, 然后再删除它们.
6.5. 切换路由器过滤模式
路由器对组的过滤模式根据组定时器和源定时器的状态在 INCLUDE 和 EXCLUDE 之间转换.
- 如果组定时器正在运行, 过滤模式为 EXCLUDE.
- 如果组定时器到期, 过滤模式切换到 INCLUDE.
6.6. 接收组离开消息 (IGMPv2) 时的操作
如果路由器接收到 IGMPv2 离开组 (Leave Group) 消息, 它就像接收到状态变更报告一样操作, 该报告指示离开消息中指定的组更改为 INCLUDE 模式 (有效地离开组). 这允许 IGMPv3 路由器与 IGMPv2 主机互操作.
7. 与 IGMPv1 和 IGMPv2 的互操作
IGMPv3 主机和路由器与尚未升级到 IGMPv3 的主机和路由器互操作. 这种兼容性通过查询者组播的周期性成员查询消息以及旧主机组播的第1版和第2版成员报告消息来维持.
7.1. IGMPv3 主机操作
IGMPv3 主机的行为取决于网络上的查询者使用的是 IGMPv3、IGMPv2 还是 IGMPv1.
7.1.1. 查询版本区分
成员查询消息的 IGMP 版本按如下方式确定:
- IGMPv1 查询: 长度 = 8 字节, Max Resp Code = 0.
- IGMPv2 查询: 长度 = 8 字节, Max Resp Code > 0.
- IGMPv3 查询: 长度 >= 12 字节.
7.1.2. 存在旧查询者时的行为
IGMPv3 主机可能被放置在查询者尚未升级到 IGMPv3 的网络上. 主机必须考虑这种可能性.
- 存在 IGMPv1 查询者: 如果 IGMPv3 主机接收到 IGMPv1 查询, 它必须以 IGMPv1 报告响应. 不支持源过滤.
- 存在 IGMPv2 查询者: 如果 IGMPv3 主机接收到 IGMPv2 查询, 它必须以 IGMPv2 报告响应. 不支持源过滤.
- 存在 IGMPv3 查询者: 如果 IGMPv3 主机接收到 IGMPv3 查询, 它以 IGMPv3 报告响应. 支持源过滤.
主机为每个接口维护一个兼容性模式变量, 该变量在接收到查询时更新. 如果接收到旧查询, 主机切换到相应的兼容性模式并设置定时器. 当定时器到期时, 主机切换回 IGMPv3 模式.
7.2. IGMPv3 路由器操作
IGMPv3 路由器的行为取决于网络上是否存在旧主机或路由器.
7.2.1. 存在旧主机
IGMPv3 路由器可能从旧主机接收 IGMPv1 或 IGMPv2 报告.
- 接收到 IGMPv1 报告: 路由器就像接收到该组的 IGMPv3 IS_EX({}) 报告一样操作. 它还必须忽略该组的任何离开组消息 (因为 IGMPv1 没有离开消息).
- 接收到 IGMPv2 报告: 路由器就像接收到该组的 IGMPv3 IS_EX({}) 报告一样操作.
当存在旧主机时, 路由器可能需要抑制受影响组的 IGMPv3 特定处理 (如源特定查询) 以确保兼容性.
7.2.2. 存在旧路由器
如果 IGMPv3 路由器与旧路由器在同一网络上, 查询者选举过程 (第 6.1 节) 确定哪个路由器成为查询者.
- 如果 IGMPv1 路由器存在并成为查询者, 所有路由器 (包括 IGMPv3 路由器) 必须作为 IGMPv1 路由器操作.
- 如果 IGMPv2 路由器存在并成为查询者, 所有路由器必须作为 IGMPv2 路由器操作.
- 如果 IGMPv3 路由器成为查询者, 它发送 IGMPv3 查询. 旧路由器会将这些视为无效的 IGMPv1/v2 查询 (或者如果它们部分兼容则处理它们), 但通常, 如果 IGMPv3 路由器必须与无法处理 IGMPv3 数据包的旧路由器共存, 则应配置为在 IGMPv1 或 IGMPv2 模式下运行.
7.3. 混合第1、2和3版主机
同一网络上可能有 IGMPv1、IGMPv2 和 IGMPv3 主机的混合.
- 如果查询者是 IGMPv3, 它发送 IGMPv3 查询.
- IGMPv3 主机以 IGMPv3 报告响应.
- IGMPv2 主机以 IGMPv2 报告响应.
- IGMPv1 主机以 IGMPv1 报告响应.
IGMPv3 路由器必须处理所有这些报告类型. 对于具有 IGMPv1 或 IGMPv2 成员的组, 路由器必须有效地将该组视为处于 EXCLUDE 模式且源列表为空 (即, "为此组发送所有内容"), 因为旧主机无法指定源过滤器.
8. 定时器、计数器及其默认值列表
这些定时器和计数器中的大多数都是可配置的. 如果使用非默认设置, 它们必须在单个链路上的所有路由器之间保持一致. 请注意, 括号表示查询消息中相应字段的值.
8.1. 鲁棒性变量 (Robustness Variable)
鲁棒性变量允许针对网络上的预期数据包丢失进行调整. 如果预期网络会丢失数据包, 则可以增加鲁棒性变量. IGMP 对 [Robustness Variable] - 1 次数据包丢失是鲁棒的.
默认值: 2
8.2. 查询间隔 (Query Interval)
查询间隔是查询者发送的通用查询之间的间隔.
默认值: 125 秒
8.3. 查询响应间隔 (Query Response Interval)
插入到周期性通用查询中的最大响应时间 (Max Resp Time).
默认值: 100 (10 秒)
8.4. 组成员间隔 (Group Membership Interval)
组成员间隔是组播路由器在决定网络上不再有组或特定源的成员之前必须经过的时间量.
值: ([Robustness Variable] * [Query Interval]) + [Query Response Interval]
8.5. 其他查询者存在间隔 (Other Querier Present Interval)
其他查询者存在间隔是组播路由器在决定不再有另一个应该成为查询者的组播路由器之前必须经过的时间长度.
值: ([Robustness Variable] * [Query Interval]) + ([Query Response Interval] / 2)
8.6. 启动查询间隔 (Startup Query Interval)
启动查询间隔是查询者在启动时发送的通用查询之间的间隔.
默认值: [Query Interval] 的 1/4
8.7. 启动查询计数 (Startup Query Count)
启动查询计数是在启动时发送的查询数量, 由 [Startup Query Interval] 分隔.
默认值: [Robustness Variable]
8.8. 最后成员查询间隔 (Last Member Query Interval)
最后成员查询间隔是插入到响应离开组消息而发送的组特定查询中的最大响应时间 (Max Resp Time).
默认值: 10 (1 秒)
8.9. 最后成员查询计数 (Last Member Query Count)
最后成员查询计数是路由器假定没有本地成员之前发送的组特定查询的数量.
默认值: [Robustness Variable]
8.10. 主动报告间隔 (Unsolicited Report Interval)
主动报告间隔是主机对组成员关系的初始报告重复之间的时间.
默认值: 10 秒
8.11. 旧版本查询者存在超时 (Older Version Querier Present Timeout)
旧版本查询者存在超时是在听到旧版本查询后将主机转换回 IGMPv3 模式的超时时间.
值: ([Robustness Variable] * [Query Interval]) + [Query Response Interval]
9. 安全考虑
我们考虑每种类型的伪造消息的后果.
9.1. 查询消息
来自 IP 地址低于当前查询者的机器的伪造查询消息将导致查询者选举发生. 这可能导致当前查询者停止发送查询并等待新查询者开始. 由于新查询者无效, 路由器上的查询定时器可能最终到期, 导致它们丢弃其成员信息.
通过发送具有小 Max Resp Code 的伪造查询, 可以进行拒绝服务 (DoS) 攻击. 这将导致 LAN 上的所有主机同时发送报告, 可能会使网络或路由器不堪重负.
9.2. 当前状态报告消息
伪造的报告消息可能导致路由器相信网络上有组的成员, 而实际上没有. 这可能导致组播流量不必要地转发到网络, 消耗带宽.
9.3. 状态变更报告消息
伪造的状态变更报告消息可能导致路由器相信系统已加入或离开组. 伪造的 "加入" 报告 (ALLOW 或 TO_IN) 会导致不必要的流量. 伪造的 "离开" 报告 (BLOCK 或 TO_EX) 可能导致路由器发送组特定查询, 如果没有有效主机及时响应, 路由器可能会停止转发该组的流量, 从而导致合法成员的拒绝服务.
9.4. IPsec
IPsec 认证头 (Authentication Header, AH) [RFC2402] 可用于保护 IGMP 消息. 使用 AH 时, 认证应用于整个 IP 数据包, 包括 IGMP 消息. 这可以防止 IGMP 消息的伪造. 但是, 组播的密钥管理很复杂, 是一个正在进行的研究领域.
10. IANA 考量
10.1. IGMP 消息类型
IANA 已将 IGMP 消息类型 0x22 分配给 "第 3 版成员报告 (Version 3 Membership Report)".
10.2. 组记录类型
IANA 已为 "IGMPv3 报告类型 (IGMPv3 Report Types)" (组记录类型) 创建了一个新注册表. 本文档中定义了值 0x01 至 0x06. 值 0x00 和 0x07 至 0xFF 可用于分配.
10.3. Max Resp Code
成员查询消息中的 Max Resp Code 字段是一个 8 位字段. 值在第 4.1.1 节中定义. 不需要注册表.
11. 致谢
我们感谢许多为 IGMPv3 的设计和文档做出贡献的人. 特别是, 我们感谢以下人员的贡献:
- Steve Deering, 他发明了 IP 组播并设计了 IGMP 的早期版本.
- Van Jacobson, 他为定时器机制的设计做出了贡献.
- Isidor Kouvelas, 他是早期草案的共同作者.
- IDMR 工作组的成员, 感谢他们的审查和评论.
12. 参考文献 (References)
12.1. 规范性参考文献 (Normative References)
- [RFC791] Postel, J., "互联网协议 (Internet Protocol)", STD 5, RFC 791, September 1981.
- [RFC1112] Deering, S., "用于 IP 组播的主机扩展 (Host Extensions for IP Multicasting)", STD 5, RFC 1112, August 1989.
- [RFC2119] Bradner, S., "用于在 RFC 中指示要求级别的关键词 (Key words for use in RFCs to Indicate Requirement Levels)", BCP 14, RFC 2119, March 1997.
12.2. 资料性参考文献 (Informative References)
- [RFC2236] Fenner, W., "互联网组管理协议版本 2 (Internet Group Management Protocol, Version 2)", RFC 2236, November 1997.
- [RFC2402] Kent, S. and R. Atkinson, "IP 认证头 (IP Authentication Header)", RFC 2402, November 1998.
- [RFC2933] McCloghrie, K., Farinacci, D., Thaler, D., and B. Fenner, "互联网组管理协议 MIB (Internet Group Management Protocol MIB)", RFC 2933, October 2000.
附录 A. 设计原理
A.1. "排除" 过滤模式
引入 "排除 (Exclude)" 过滤模式是为了支持 "源特定组播 (Source-Specific Multicast, SSM)", 同时仍保持与现有 "任意源组播 (Any-Source Multicast, ASM)" 模型的兼容性.
在 ASM 中, 主机加入组 G 并接收从发送到 G 的所有源的流量. 这相当于 EXCLUDE({}, G). 在 SSM 中, 主机加入特定信道 (S, G) 并仅接收从源 S 发送到组 G 的流量. 这相当于 INCLUDE({S}, G).
EXCLUDE 模式允许主机阻止来自 ASM 组的特定源, 这对于过滤掉不需要的流量很有用.
A.2. "包含" 过滤模式
"包含 (Include)" 过滤模式是 SSM 的主要模式. 它允许主机显式指定其希望接收的源集. 这简化了组播路由协议, 因为路由器只需构建源特定树.
A.3. 状态变更报告
发送状态变更报告是为了确保可靠性. 通过重复报告, 降低了它们丢失的概率. 这很重要, 因为 IGMP 在不可靠的传输 (IP) 上运行.
附录 B. 与 IGMPv2 的变更摘要
以下是从 IGMPv2 [RFC2236] 到 IGMPv3 的变更摘要:
-
源过滤: 主机能够指定它们想要接收的源 (INCLUDE 模式) 或它们想要阻止的源 (EXCLUDE 模式).
-
组记录类型: IGMPv3 报告包含组记录, 可以是不同类型 (当前状态、过滤模式变更、源列表变更) 以传达不同类型的信息.
-
成员报告格式: 报告格式已完全重新设计, 以支持单个消息中的多个组记录并携带源地址.
-
查询格式: 查询格式已扩展以支持组和源特定查询, 并携带鲁棒性变量和查询间隔 (QQIC).
-
Max Resp Code: Max Resp Code 字段已重新定义, 使用浮点表示支持更大的值.
-
查询者选举: 查询者选举机制保持不变, 但已澄清了处理旧版本的规则.
-
S 标志: 查询中的 "抑制路由器端处理 (Suppress Router-Side Processing)" 标志允许路由器在接收查询时抑制定时器更新, 这对于某些诊断或特殊配置很有用.