Internet Engineering Task Force (IETF) H. Liu
Request for Comments: 5790 W. Cao
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 H. Asaeda
Keio University
February 2010
Internet Engineering Task Force (IETF) H. Liu
Request for Comments: 5790 W. Cao
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 H. Asaeda
Keio University
February 2010
Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
轻量级Internet组管理协议版本3（IGMPv3）和多播侦听器发现版本2（MLDv2）协议
Abstract
摘要
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account.
本文档描述了轻量级IGMPv3和MLDv2协议（LW-IGMPv3和LW-MLDv2），它们简化了IGMPv3和MLDv2的标准（完整）版本。还考虑了与IGMP和MLD的完整版本和以前版本的互操作性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5790.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5790.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Simplification Method Overview ..................................4
3.1. Behavior of Group Members ..................................5
3.2. Behavior of Multicast Routers ..............................5
4. LW-IGMPv3 Protocol for Group Members ............................6
4.1. Query and Report Messages ..................................6
4.2. Action on Change of Interface State ........................6
4.3. Action on Reception of a Query .............................7
4.4. LW-IGMPv3 Group Record Types ...............................7
5. LW-IGMPv3 Protocol for Multicast Routers ........................9
5.1. Group Timers and Source Timers in the Lightweight Version ..9
5.2. Source-Specific Forwarding Rules ..........................10
5.3. Reception of Current-State Records ........................10
5.4. Reception of Source-List-Change and
Filter-Mode-Change Records ................................12
6. Interoperability ...............................................13
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ......13
6.1.1. Behavior of Group Members ..........................13
6.1.2. Behavior of Multicast Routers ......................13
6.2. Interoperation with IGMPv1/IGMPv2 .........................14
6.2.1. Behavior of Group Members ..........................14
6.2.2. Behavior of Multicast Routers ......................14
6.3. Interoperation with MLDv1 .................................15
7. Implementation Considerations ..................................15
7.1. Implementation of Source-Specific Multicast ...............15
7.2. Implementation of Multicast Source Filter (MSF) APIs ......16
8. Security Considerations ........................................16
9. Acknowledgements ...............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Simplification Method Overview ..................................4
3.1. Behavior of Group Members ..................................5
3.2. Behavior of Multicast Routers ..............................5
4. LW-IGMPv3 Protocol for Group Members ............................6
4.1. Query and Report Messages ..................................6
4.2. Action on Change of Interface State ........................6
4.3. Action on Reception of a Query .............................7
4.4. LW-IGMPv3 Group Record Types ...............................7
5. LW-IGMPv3 Protocol for Multicast Routers ........................9
5.1. Group Timers and Source Timers in the Lightweight Version ..9
5.2. Source-Specific Forwarding Rules ..........................10
5.3. Reception of Current-State Records ........................10
5.4. Reception of Source-List-Change and
Filter-Mode-Change Records ................................12
6. Interoperability ...............................................13
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ......13
6.1.1. Behavior of Group Members ..........................13
6.1.2. Behavior of Multicast Routers ......................13
6.2. Interoperation with IGMPv1/IGMPv2 .........................14
6.2.1. Behavior of Group Members ..........................14
6.2.2. Behavior of Multicast Routers ......................14
6.3. Interoperation with MLDv1 .................................15
7. Implementation Considerations ..................................15
7.1. Implementation of Source-Specific Multicast ...............15
7.2. Implementation of Multicast Source Filter (MSF) APIs ......16
8. Security Considerations ........................................16
9. Acknowledgements ...............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
IGMP version 3 [2] and MLD version 2 [3] implement source filtering capabilities that are not supported by their earlier versions, IGMPv1 [4], IGMPv2 [5], and MLDv1 [6]. An IGMPv3- or MLDv2-capable host can tell its upstream router which group it would like to join by specifying which sources it does or does not intend to receive multicast traffic from. IGMPv3 and MLDv2 add the capability for a multicast router to learn sources that are of interest or that are not of interest for a particular multicast address. This information is used during forwarding of multicast data packets.
IGMP版本3[2]和MLD版本2[3]实现了其早期版本IGMPv1[4]、IGMPv2[5]和MLDv1[6]不支持的源筛选功能。支持IGMPv3或MLDv2的主机可以通过指定其确实或不打算从哪些源接收多播流量来告诉其上游路由器它想要加入哪个组。IGMPv3和MLDv2增加了多播路由器学习特定多播地址感兴趣或不感兴趣的源的能力。此信息在多播数据包转发期间使用。
INCLUDE and EXCLUDE filter-modes are introduced to support the source filtering function. If a host wants to receive from specific sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. If the host does not want to receive from some sources, it sends a report with filter-mode set to EXCLUDE. A source-list for the given sources shall be included in the Report message.
引入包括和排除过滤模式以支持源过滤功能。如果主机希望从特定来源接收，它将发送一个IGMPv3或MLDv2报告，并将过滤模式设置为包含。如果主机不希望从某些源接收，则会发送一个过滤器模式设置为“排除”的报告。报告信息中应包含给定来源的来源列表。
INCLUDE and EXCLUDE filter-modes are also defined in a multicast router to process the IGMPv3 or MLDv2 reports. When a multicast router receives the Report messages from its downstream hosts, it forwards the corresponding multicast traffic by managing requested group and source addresses. Group timers and source timers are used to maintain the forwarding state of desired groups and sources under certain filter-modes. When a group report arrives or a certain timer expires, a multicast router may update the desired or undesired source-lists, reset related timer values, change filter-mode, or trigger group queries. With all of the above factors correlating with each other, the determination rules become relatively complex, as the interface states could be frequently changed.
在多播路由器中还定义了包括和排除过滤器模式，以处理IGMPv3或MLDv2报告。当多播路由器从其下游主机接收到报告消息时，它通过管理请求的组和源地址转发相应的多播流量。组计时器和源计时器用于在某些过滤模式下保持所需组和源的转发状态。当组报告到达或某个计时器过期时，多播路由器可以更新所需或不需要的源列表、重置相关计时器值、更改筛选器模式或触发组查询。由于上述所有因素相互关联，确定规则变得相对复杂，因为界面状态可能频繁改变。
The multicast filter-mode improves the ability of the multicast receiver to express its desires. It is useful to support Source-Specific Multicast (SSM) [7] by specifying interesting source addresses with INCLUDE mode. However, practical applications do not use EXCLUDE mode to block sources very often, because a user or application usually wants to specify desired source addresses, not undesired source addresses. Even if a user explicitly refuses traffic from some sources in a group, when other users in the same shared network have an interest in these sources, the corresponding multicast traffic will still be forwarded to the network. It is generally unnecessary to support the filtering function that blocks sources.
多播过滤器模式提高了多播接收器表达其愿望的能力。通过使用INCLUDE模式指定感兴趣的源地址，支持特定于源的多播（SSM）[7]非常有用。然而，实际应用程序并不经常使用排除模式来阻止源，因为用户或应用程序通常希望指定所需的源地址，而不是不需要的源地址。即使用户明确拒绝来自组中某些源的流量，当同一共享网络中的其他用户对这些源感兴趣时，相应的多播流量仍将转发到网络。通常不需要支持阻止源的过滤功能。
This document proposes simplified versions of IGMPv3 and MLDv2, named Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2). LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.
本文档提出了IGMPv3和MLDv2的简化版本，命名为轻量级IGMPv3和轻量级MLDv2（或LW-IGMPv3和LW-MLDv2）。LW-IGMPv3和LW-MLDv2是标准IGMPv3和MLDv2的子集。
They support both Any-Source Multicast (ASM) and SSM communications without a filtering function that blocks sources. Not only are they compatible with the standard IGMPv3 and MLDv2, but also the protocol operations made by hosts and routers (or switches performing IGMPv3/ MLDv2 snooping) are simplified to reduce the complicated operations. Since LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2, hosts or routers that have implemented the full version do not need to implement or modify anything to cooperate with LW-IGMPv3/ LW-MLDv2 hosts or routers.
它们支持任意源多播（ASM）和SSM通信，无需阻塞源的过滤功能。它们不仅与标准IGMPv3和MLDv2兼容，而且简化了主机和路由器（或执行IGMPv3/MLDv2侦听的交换机）的协议操作，以减少复杂的操作。由于LW-IGMPv3和LW-MLDv2与IGMPv3和MLDv2完全兼容，因此实现完整版本的主机或路由器无需实现或修改任何内容即可与LW-IGMPv3/LW-MLDv2主机或路由器配合。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
In addition, the following terms are used in this document.
此外，本文件中使用了以下术语。
(*,G) join: An operation triggered by a host that wants to join a group G. In this case, the host receives from all sources sending to group G. This is typical in ASM communication.
（*，G）加入：由希望加入G组的主机触发的一种操作。在这种情况下，主机从发送到G组的所有源接收数据。这在ASM通信中是典型的。
(S,G) join: An operation triggered by a host that wants to join a group G, specifying a desired source S. In this case, the host receives traffic only from source S sending to group G.
（S，G）加入：由希望加入G组的主机触发的操作，指定所需的源S。在这种情况下，主机只接收源S发送到G组的流量。
INCLUDE (S,G) join: An operation triggered by a host that wants to join a group G under INCLUDE filter-mode, specifying a desired source S. Same meaning as (S,G) join.
INCLUDE（S，G）join：主机在INCLUDE filter模式下要加入组G，指定所需源S的操作。与（S，G）join的含义相同。
EXCLUDE (*,G) join: An operation triggered by a host that wants to join a group G under EXCLUDE filter-mode. Same meaning as (*,G) join.
EXCLUDE（*，G）join：主机在EXCLUDE filter模式下要加入组G时触发的操作。与（*，G）连接的含义相同。
EXCLUDE (S,G) join: An operation triggered by a host that wants to join a group G under EXCLUDE filter-mode, specifying an undesired source S. This operation is not supported by LW-IGMPv3/LW-MLDv2.
排除（S，G）加入：由主机触发的操作，该主机希望在排除筛选器模式下加入组G，指定不需要的源S。LW-IGMPv3/LW-MLDv2不支持此操作。
The principle is to simplify the host's and router's behavior as much as possible to improve efficiency, while guaranteeing interoperability with the full versions, and introducing no side effects on applications.
其原则是尽可能简化主机和路由器的行为以提高效率，同时保证与完整版本的互操作性，并且不会对应用程序产生任何副作用。
For convenience, this document mainly discusses IGMPv3, since MLDv2 inherits the same source filtering mechanism, but this document additionally shows MLDv2's unique specifications when needed.
为了方便起见，本文档主要讨论IGMPv3，因为MLDv2继承了相同的源代码过滤机制，但本文档在需要时还显示了MLDv2的独特规范。
LW-IGMPv3 inherits the service interface model of IGMPv3.
LW-IGMPv3继承了IGMPv3的服务接口模型。
IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list )
IPMulticastListen（套接字、接口、多播地址、筛选器模式、源列表）
In the lightweight protocol, INCLUDE mode on the host part has the same usage as the full version for INCLUDE (S,G) join, while EXCLUDE mode on the host part is preserved only for excluding null source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is described in Section 4.
在轻量级协议中，主机部件上的INCLUDE模式与INCLUDE（S，G）连接的完整版本具有相同的用法，而主机部件上的EXCLUDE模式仅保留用于排除空源列表，这表示IGMPv2/IGMPv1/MLDv1使用的（*，G）连接。第4节描述了LW-IGMPv3/LW-MLDv2的详细主机操作。
In IGMPv3, router filter-mode is defined to optimize the state description of a group membership [2]. As a rule, once a member report is in EXCLUDE mode, the router filter-mode for the group will be set to EXCLUDE. When all systems cease sending EXCLUDE mode reports, the filter-mode for that group may transit back to INCLUDE mode. The group timer is used to identify such a transition.
在IGMPv3中，路由器过滤器模式被定义为优化组成员的状态描述[2]。通常，一旦成员报告处于排除模式，组的路由器筛选器模式将设置为排除。当所有系统停止发送排除模式报告时，该组的筛选模式可能会转换回包括模式。组计时器用于识别此类转换。
In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can request an EXCLUDE (*,G) join, which can be interpreted by the router as a request to include all sources. Without the more general form of EXCLUDE requests, it is unnecessary for the router to maintain the EXCLUDE filter-mode, and the state model for multicast routers can be simplified as:
在LW-IGMPv3中，主机主要发送INCLUDE请求，还可以请求EXCLUDE（*，G）连接，路由器可以将其解释为包含所有源的请求。如果没有更一般形式的排除请求，路由器不需要保持排除过滤模式，多播路由器的状态模型可以简化为：
(multicast address, group timer, (source records))
（多播地址、组计时器（源记录））
Here a group timer is kept to represent a (*,G) join. Its basic behavior is: when a router receives a (*,G) join, it will set its group timer and keep the source-list for sources specified in the previously received source records. When the group timer expires, the router may change to reception of the listed sources only. The definition of the source record is the same as in the full version.
这里保留一个组计时器来表示（*，G）连接。它的基本行为是：当路由器接收（*，G）连接时，它将设置其组计时器，并保留以前接收到的源记录中指定的源的源列表。当组计时器过期时，路由器可能会更改为仅接收列出的源。源记录的定义与完整版本中的定义相同。
The elimination of the filter-mode will greatly simplify the router behavior. The details of router operation are described in Section 5.
过滤器模式的消除将大大简化路由器的行为。路由器操作的详细信息见第5节。
LW-IGMPv3 uses the same two sets of messages, Query and Report messages, as the full version protocols. There is no difference between the definition and usage of the Query message. But the report types in lightweight protocols are reduced because an operation that triggers EXCLUDE (S,G) join is omitted.
LW-IGMPv3使用与完整版本协议相同的两组消息，即查询消息和报告消息。查询消息的定义和用法没有区别。但是轻量级协议中的报告类型减少了，因为忽略了触发EXCLUDE（S，G）join的操作。
There are three Group Record Types defined in the full IGMPv3: the Current-State Record denoted by MODE_IS_INCLUDE (referred to as IS_IN) or MODE_IS_EXCLUDE (IS_EX), the Filter-Mode-Change Record denoted by CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and the Source-List-Change Record denoted by ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 inherits the actions on change of interface state and on reception of a query, but the IS_IN and IS_EX record types are eliminated and Current-State Records are replaced by other records. The following sections explain the details.
在完整的IGMPv3中定义了三种组记录类型：由MODE_IS_INCLUDE（称为IS_in）或MODE_IS_EXCLUDE（IS_EX）表示的当前状态记录，由Change_to_INCLUDE_MODE（to_in）或Change_to_EXCLUDE_MODE（to_EX）表示的过滤器模式更改记录，以及由ALLOW_NEW__SOURCES（ALLOW）表示的源列表更改记录或块旧源（块）。LW-IGMPv3继承更改接口状态和接收查询时的操作，但删除IS_IN和IS_EX记录类型，并用其他记录替换当前状态记录。以下各节解释了详细信息。
When the state of an interface of a group member host is changed, a State-Change Report for that interface is immediately transmitted from that interface. The type and contents of the Group Record(s) in that report are determined by comparing the filter-mode and source-list for the affected multicast address before and after the change. While the requirements for the computation are the same as for the full version, in a lightweight version host the interface state change rules are simplified due to the reduction of message types. The contents of the new transmitted report are calculated as follows (Group Record Types are described in Section 4.4):
当组成员主机的接口状态发生更改时，该接口的状态更改报告将立即从该接口传输。通过比较更改前后受影响多播地址的筛选器模式和源列表，可以确定该报告中组记录的类型和内容。虽然计算要求与完整版本相同，但在轻量级版本主机中，由于消息类型的减少，接口状态更改规则得到简化。新传输报告的内容计算如下（第4.4节描述了组记录类型）：
Old State New State State-Change Report Sent
----------- ----------- ------------------------
Old State New State State-Change Report Sent
----------- ----------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B)
包括（A）包括（B）允许（B-A），块（A-B）
INCLUDE (A) EXCLUDE ({}) TO_EX({})
INCLUDE (A) EXCLUDE ({}) TO_EX({})
INCLUDE ({}) EXCLUDE ({}) TO_EX({})
INCLUDE ({}) EXCLUDE ({}) TO_EX({})
EXCLUDE ({}) INCLUDE (B) TO_IN(B)
EXCLUDE ({}) INCLUDE (B) TO_IN(B)
As in the full version, to cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable]-1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]). (These values are defined in [2][3].)
与完整版本一样，为了覆盖一个或多个多播路由器丢失状态更改报告的可能性，以从范围（0，[未经请求的报告间隔]）中随机选择的间隔将其重新传输[鲁棒性变量]-1次以上。（这些值在[2][3]中有定义。）
As in the full version, when a lightweight version host receives a query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message [2][3]. The system may receive a variety of queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response.
与完整版本一样，当轻量级版本主机收到查询时，它不会立即响应。相反，它将其响应延迟随机时间量，以从接收到的查询消息[2][3]中的Max Resp代码派生的Max Resp time值为界。系统可能在不同接口上接收各种不同类型的查询（例如，一般查询、组特定查询以及组和源特定查询），每个查询可能需要自己的延迟响应。
Before scheduling a response to a query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the lightweight version host must be able to maintain the following state:
在调度对查询的响应之前，系统必须首先考虑预先调度的待决响应，并且在许多情况下调度组合响应。因此，轻型版本主机必须能够保持以下状态：
o A timer per interface for scheduling responses to General Queries.
o 每个接口都有一个计时器，用于调度对常规查询的响应。
o A per-group and interface timer for scheduling responses to Group-Specific and Group-and-Source-Specific Queries.
o 每个组和接口计时器，用于调度对特定于组以及特定于组和源的查询的响应。
o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query.
o 在对组和源特定查询的响应中报告的每个组和接口源列表。
LW-IGMPv3 inherits the full version's rules that are used to determine if a report needs to be scheduled. The difference is regarding the simplification of EXCLUDE filter-mode and the type of report as detailed in Section 4.4.
LW-IGMPv3继承完整版本的规则，用于确定是否需要安排报告。区别在于第4.4节详述的排除过滤模式和报告类型的简化。
Among the Group Record Types defined in the full IGMPv3, several record types are not used in LW-IGMPv3 as some of the processes related to the filter-mode change to the EXCLUDE mode are eliminated and some of the Report messages are converged into a record having a null source address list. All of the record types of Report messages used by the full and lightweight version protocols are shown as follows:
在完整IGMPv3中定义的组记录类型中，LW-IGMPv3中没有使用几种记录类型，因为与过滤模式更改为排除模式相关的一些过程被消除，并且一些报告消息聚合为具有空源地址列表的记录。完整版和轻型版协议使用的所有报告消息记录类型如下所示：
IGMPv3 LW-IGMPv3 Comments
--------- --------- -------------------------------------
IGMPv3 LW-IGMPv3 Comments
--------- --------- -------------------------------------
IS_EX({}) TO_EX({}) Query response for (*,G) join
IS_EX({}) TO_EX({}) Query response for (*,G) join
IS_EX(x) N/A Query response for EXCLUDE (x,G) join
是否为排除（x，G）联接的查询响应
IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join
INCLUDE（x，G）join的（x）ALLOW（x）查询响应中是否有_
ALLOW(x) ALLOW(x) INCLUDE (x,G) join
允许（x）允许（x）包括（x，G）连接
BLOCK(x) BLOCK(x) INCLUDE (x,G) leave
第（x）块第（x）块包括（x，G）块离开
TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join
（x）中的TO_到（x）中的TO_更改为包含（x，G）join
TO_IN({}) TO_IN({}) (*,G) leave
TO_IN({}) TO_IN({}) (*,G) leave
TO_EX(x) N/A Change to EXCLUDE (x,G) join
不适用于排除（x，G）联接的更改
TO_EX({}) TO_EX({}) (*,G) join
TO_EX({}) TO_EX({}) (*,G) join
where "x" represents a non-null source address list and "({})" represents a null source address list. For instance, IS_EX({}) means a report whose record type is IS_EX with a null source address list. "N/A" represents not applicable (or no use) because the corresponding operation should not occur in the lightweight version protocols.
其中，“x”表示非空源地址列表，“（{}）”表示空源地址列表。例如，IS_EX（{}）表示记录类型为IS_EX且源地址列表为空的报表。“N/A”表示不适用（或不使用），因为轻量级版本协议中不应发生相应的操作。
LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source address list. A multicast router creates the same state when it receives a Report message containing either IS_EX({}) or TO_EX({}) record types. Therefore, LW-IGMPv3 integrates the IS_EX({}) operation with the TO_EX({}) operation.
LW-IGMPv3不使用具有非空源地址列表的排除筛选器模式。多播路由器在接收到包含IS_EX（{}）或TO_EX（{}）记录类型的报告消息时，会创建相同的状态。因此，LW-IGMPv3集成了IS_EX（{}）操作和TO_EX（{}）操作。
When an LW-IGMPv3 host needs to make a query response for the state of INCLUDE (x,G) join, it makes a response whose message type is expressed with ALLOW(x), instead of using the IS_IN record type. Because the router's processing of the two messages is exactly the same, the IS_IN(x) type is eliminated for simplification.
当LW-IGMPv3主机需要对INCLUDE（x，G）join的状态做出查询响应时，它会做出一个消息类型用ALLOW（x）表示的响应，而不是使用is_IN记录类型。由于路由器对这两条消息的处理完全相同，因此为了简化，取消了is_IN（x）类型。
An LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN and TO_EX records are used for example in the following situation: the host first launches an application (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the host launches another application (AP2) that joins (*,G), and it sends TO_EX({}). In this condition, when AP2 terminates but AP1 keeps working on the lightweight version host, the host sends a report with TO_IN(x) record type for [Robustness Variable] times.
LW-IGMPv3主机不使用排除模式，而TO_IN和TO_EX记录用于以下情况：主机首先启动一个应用程序（AP1），请求包含（x，G）join，并发送ALLOW（x）。然后主机启动另一个加入（*，G）的应用程序（AP2），并将其发送到_EX（{}）。在这种情况下，当AP2终止，但AP1继续在轻量级版本主机上工作时，主机会发送一份报告，报告的（x）记录类型为[Robustness Variable]次。
Although an LW-IGMPv3 host adopts the four message types (ALLOW, BLOCK, TO_IN, and TO_EX) for simplification, using IS_EX({}) and IS_IN(x) (respectively, instead of TO_EX({}) and ALLOW(x)) in response to queries is not inhibited. This will not introduce the interoperation problem because the router process is, respectively, the same for the mentioned two message set, as long as the router implementation follows the rules given by full IGMPv3.
虽然LW-IGMPv3主机采用四种消息类型（ALLOW、BLOCK、TO_-IN和TO_-EX）进行简化，但在响应查询时使用IS_-EX（{}）和IS_-IN（x）（分别代替TO_-EX（{}）和ALLOW（x））并没有被禁止。这不会引入互操作问题，因为只要路由器实现遵循完整的IGMPv3给出的规则，路由器过程对于上述两个消息集分别是相同的。
The major difference between the full and lightweight version protocols on the router part is that in the lightweight version filter-mode is discarded and the function of the group timer is redefined. The states maintained by the lightweight router are reduced and the protocol operation is greatly simplified.
路由器部分的完整版本协议和轻量级版本协议之间的主要区别在于轻量级版本过滤器模式被丢弃，组计时器的功能被重新定义。轻量级路由器维护的状态减少，协议操作大大简化。
In lightweight and full IGMPv3 routers, a source timer is kept for each source record and it is updated when the source is present in a received report. It indicates the validity of the source and needs to be referred to when the router takes its forwarding decision.
在轻量级和完整的IGMPv3路由器中，为每个源记录保留一个源计时器，当源出现在接收到的报告中时，它会被更新。它指示源的有效性，并需要在路由器做出转发决定时引用。
The group timer being used in the full version of IGMPv3 for transitioning the router's filter-mode from EXCLUDE to INCLUDE is redefined in the lightweight protocols to identify the non-source-specific receiving state maintained for (*,G) join. Once a group record of TO_EX({}) is received, the group timer is set to represent this (*,G) group join. The expiration of the group timer indicates that there are no more listeners on the attached network for this (*,G) group. Then if at this moment there are unexpired sources (whose source timers are greater than zero), the router will change to receiving traffic for those sources only. The role of the group timer can be summarized as follows:
在IGMPv3的完整版本中，用于将路由器的过滤模式从排除转换为包括的组计时器在轻量级协议中重新定义，以识别为（*，G）连接维护的非源特定接收状态。一旦接收到TO_EX（{}）的组记录，组计时器就被设置为表示该（*，G）组连接。组计时器过期表示连接的网络上没有更多用于此（*，G）组的侦听器。然后，如果此时存在未过期的源（其源计时器大于零），路由器将更改为仅接收这些源的流量。组计时器的作用总结如下：
Group Timer Value Actions/Comments
------------------ --------------------------------------
Group Timer Value Actions/Comments
------------------ --------------------------------------
G_Timer > 0 All members in this group.
G_Timer>0此组中的所有成员。
G_Timer == 0 No more listeners to this (*,G) group. If all source timers have expired, then delete group record. If there are still source record timers running, use those source records with running timers as the source record state.
G_Timer==0此（*，G）组不再有侦听器。如果所有源计时器都已过期，则删除组记录。如果仍有源记录计时器在运行，请使用那些具有运行计时器的源记录作为源记录状态。
The operation related to the group and source timers has some differences compared to the full IGMPv3. In the full version, if a source timer expires under the EXCLUDE router filter-mode, its corresponding source record is not deleted until the group timer expires for indicating undesired sources. In the lightweight version, since there is no need to keep such records for blocking specific sources, if a source timer expires, its source record should be deleted immediately, not waiting for the time-out of the group timer.
与完整的IGMPv3相比，与组和源计时器相关的操作有一些差异。在完整版本中，如果源计时器在排除路由器筛选器模式下过期，则其相应的源记录不会被删除，直到组计时器因指示不需要的源而过期。在轻量级版本中，由于不需要保留此类记录来阻止特定源，因此如果源计时器过期，应立即删除其源记录，而不是等待组计时器超时。
A full version multicast router needs to consult IGMPv3 state information when it makes decisions on forwarding a datagram from a source, based on the router filter-mode and source timer. In LW-IGMPv3, because of the absence of the router filter-mode, the group timer and source timer could be used for such decisions. The forwarding suggestion made by LW-IGMPv3 to the routing protocols is summarized as follows:
基于路由器过滤模式和源定时器，完整版本的多播路由器在决定从源转发数据报时需要参考IGMPv3状态信息。在LW-IGMPv3中，由于没有路由器过滤模式，组定时器和源定时器可用于此类决策。LW-IGMPv3对路由协议的转发建议总结如下：
Group Timer Source Timer Action
------------ ------------------ -----------------------
Group Timer Source Timer Action
------------ ------------------ -----------------------
G_Timer == 0 S_Timer > 0 Suggest forwarding traffic from source
G_Timer==0 S_Timer>0建议从源转发流量
G_Timer == 0 S_Timer == 0 Suggest stopping forwarding traffic from source and remove source record. If there are no more source records for the group, delete group record
G_Timer==0 S_Timer==0建议停止从源转发流量并删除源记录。如果组没有更多的源记录，请删除组记录
G_Timer == 0 No Source Elements Suggest not forwarding traffic from source
G_Timer==0无源元素建议不转发来自源的流量
G_Timer > 0 S_Timer >= 0 Suggest forwarding traffic from source
G_Timer>0 S_Timer>=0建议从源转发流量
G_Timer > 0 No Source Elements Suggest forwarding traffic from source
G_Timer>0无源元素建议从源转发流量
When receiving Current-State Records, the LW-IGMPv3 router resets its group or source timers and updates its source-list within the group. For source-specific group reception state (when G_Timer == 0 and
当接收到当前状态记录时，LW-IGMPv3路由器重置其组或源定时器，并更新其组内的源列表。对于特定于源的组接收状态（当G_Timer==0和
S_Timer > 0), the source-list contains sources whose traffic will be forwarded by the router, while in non-source-specific group reception (when G_Timer > 0), the source-list remembers the valid sources to receive traffic from after toggling to source-specific reception state.
S_Timer>0），源列表包含其流量将由路由器转发的源，而在非源特定组接收中（当G_Timer>0时），源列表在切换到源特定接收状态后会记住要从中接收流量的有效源。
Although the LW-IGMPv3 host only sends a subset of the messages of the full version, the LW-IGMPv3 router should be able to process as many messages as possible to be compatible with the full version host. Note that if the report type is IS_EX(x) with a non-empty source-list, the router will treat it as the same type of report with an empty source-list. The following table describes the action taken by a multicast router after receiving Current-State Records. The notations have the same meaning as those in the full IGMPv3 protocol.
尽管LW-IGMPv3主机仅发送完整版本消息的子集，但LW-IGMPv3路由器应能够处理尽可能多的消息，以与完整版本主机兼容。请注意，如果报告类型为带有非空源列表的_EX（x），路由器会将其视为具有空源列表的相同报告类型。下表描述了多播路由器在收到当前状态记录后采取的操作。这些符号与完整的IGMPv3协议中的符号具有相同的含义。
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -----------
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -----------
G_Timer == 0 A IS_IN(B) A+B (B)=GMI
G_Timer == 0 A IS_IN(B) A+B (B)=GMI
G_Timer == 0 A IS_EX({}) A G_Timer=GMI
G_Timer == 0 A IS_EX({}) A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_EX({}) A G_Timer=GMI
G_Timer > 0 A IS_EX({}) A G_Timer=GMI
The above table could be further simplified since the processes are exactly the same for the two values of the G_Timer:
上表可以进一步简化，因为G_定时器的两个值的过程完全相同：
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ -----------
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI
A IS_IN(B) A+B (B)=GMI
A IS_EX({}) A G_Timer=GMI
A IS_EX({}) A G_Timer=GMI
Without EXCLUDE filter-mode, a router's process on receiving a Current-State Record is simple: when a router receives an IS_IN report, it appends the reported source addresses to the previous source-list with their source timers set to GMI. Upon receiving an IS_EX({}) report, the router sets the non-source-specific receiving states by resetting the group timer value and keeps the previous source-list without modification.
没有排除过滤模式，路由器接收当前状态记录的过程很简单：当路由器接收到is_IN报告时，它会将报告的源地址附加到上一个源列表，并将其源计时器设置为GMI。在接收到IS_EX（{}）报告后，路由器通过重置组计时器值来设置非源特定的接收状态，并保留以前的源列表而不进行修改。
On receiving Source-List-Change and Filter-Mode-Change Records, the LW-IGMPv3 router needs to reset its group and source timers, update its source-list within the group, or trigger group queries. The queries are sent by the router for the sources that are requested to be no longer forwarded to a group. Note that if the report type is TO_EX(x) with a non-empty source-list, the router will treat it as the same type of report with an empty source-list. The table below describes the state change and the actions that should be taken.
在收到源列表更改和过滤模式更改记录时，LW-IGMPv3路由器需要重置其组和源计时器，更新其组内的源列表，或触发组查询。这些查询由路由器发送，用于请求不再转发到组的源。请注意，如果报告类型为带有非空源列表的TO_EX（x），路由器会将其视为具有空源列表的相同报告类型。下表描述了状态更改和应采取的操作。
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -------------
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -------------
G_Timer == 0 A ALLOW(B) A+B (B)=GMI
G_Timer == 0 A ALLOW(B) A+B (B)=GMI
G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
G_Timer == 0 A TO_EX({}) A G_Timer=GMI
G_Timer == 0 A TO_EX({}) A G_Timer=GMI
G_Timer > 0 A ALLOW(B) A+B (B)=GMI
G_Timer > 0 A ALLOW(B) A+B (B)=GMI
G_Timer > 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer > 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B)
Send Q(G)
G_Timer > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B)
Send Q(G)
G_Timer > 0 A TO_EX({}) A G_Timer=GMI
G_Timer > 0 A TO_EX({}) A G_Timer=GMI
The table could be further simplified by merging duplicate lines:
可通过合并重复行进一步简化表格：
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ ----------------------
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ ----------------------
A ALLOW(B) A+B (B)=GMI
A ALLOW(B) A+B (B)=GMI
A BLOCK(B) A Send Q(G,A*B)
A BLOCK(B) A Send Q(G,A*B)
A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)
A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)
A TO_EX({}) A G_Timer=GMI
A TO_EX({}) A G_Timer=GMI
LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate gracefully with hosts and routers running IGMPv1/v2 or MLDv1.
LW-IGMPv3/LW-MLDv2主机和路由器必须与完整版本的主机和路由器进行互操作[2][3]。此外，LW-IGMPv3/LW-MLDv2主机和路由器必须与运行IGMPv1/v2或MLDv1的主机和路由器优雅地互操作。
LW-IGMPv3/LW-MLDv2 do not introduce any change on the message formats of the group Query and Report messages that the full version protocols use.
LW-IGMPv3/LW-MLDv2不会对完整版本协议使用的组查询和报告消息的消息格式进行任何更改。
An LW-IGMPv3 host's compatibility mode is determined from the Host Compatibility Mode variable, which can be in one of three states: IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its interface as LW-IGMPv3, its Host Compatibility Mode of that interface is set to IGMPv3, and the host sends a subset of IGMPv3 Report messages, which can be recognized by a multicast router running the full or the lightweight IGMPv3 protocol on the same LAN.
LW-IGMPv3主机的兼容模式由主机兼容模式变量确定，该变量可以处于三种状态之一：IGMPv1、IGMPv2或IGMPv3。当轻型主机在其接口上的行为为LW-IGMPv3时，该接口的主机兼容模式设置为IGMPv3，主机发送IGMPv3报告消息的子集，该消息可由在同一LAN上运行完整或轻型IGMPv3协议的多播路由器识别。
An LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and TO_EX(x) reports that are used by the full version. When an LW-IGMPv3/LW-MLDv2 router receives these Report messages from full version hosts, it MUST translate them internally to IS_EX({}) and TO_EX({}) respectively and behave accordingly.
LW-IGMPv3或LW-MLDv2路由器不直接处理完整版本使用的IS_EX（x）和TO_EX（x）报告。当LW-IGMPv3/LW-MLDv2路由器从完整版本主机接收到这些报告消息时，它必须在内部将它们分别转换为IS_EX（{}）和_EX（{}），并相应地进行操作。
Since the lightweight protocols can be treated as a parallel version of the full version of IGMPv3/MLDv2, its compatibility principle and method with the older version are generally the same as that of full IGMPv3/MLDv2.
由于轻量级协议可以被视为完整版本的IGMPv3/MLDv2的并行版本，因此其与旧版本的兼容性原则和方法通常与完整版本的IGMPv3/MLDv2相同。
The Host Compatibility Mode of an interface is set to IGMPv2 and its IGMPv2 Querier Present timer is set to Older Version Querier Present Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is received on that interface. The Host Compatibility Mode of an interface is set to IGMPv1 and its IGMPv1 Querier Present timer is set to Older Version Querier Present Timeout seconds whenever an IGMPv1 Membership Query is received on that interface.
接口的主机兼容性模式设置为IGMPv2，并且每当在该接口上接收到IGMPv2常规查询时，其IGMPv2查询器呈现计时器设置为较旧版本的查询器呈现超时秒（定义见[2]）。接口的主机兼容性模式设置为IGMPv1，并且每当在该接口上接收到IGMPv1成员资格查询时，其IGMPv1查询器呈现计时器设置为旧版本查询器呈现超时秒。
In the presence of older version group members, LW-IGMPv3 hosts may allow its Report message to be suppressed by either an IGMPv1 or IGMPv2 membership report. However, because the transmission of IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system, as a potential protection mechanism, the choice to enable or disable the use of backward compatibility may be configurable.
在存在旧版本组成员的情况下，LW-IGMPv3主机可能允许其报告消息被IGMPv1或IGMPv2成员报告抑制。然而，由于IGMPv1或v2数据包的传输降低了LW-IGMPv3系统的能力，作为一种潜在的保护机制，启用或禁用向后兼容性的选择可能是可配置的。
The behavior of an LW-IGMPv3 router when placed on a network where there are routers that have not been upgraded to IGMPv3 is exactly the same as for a full IGMPv3 router in this situation [2].
当将LW-IGMPv3路由器置于存在未升级到IGMPv3的路由器的网络上时，其行为与这种情况下完整IGMPv3路由器的行为完全相同[2]。
A full IGMPv3 router uses Group Compatibility Mode (whose value is either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate which version of IGMP protocol it applies to the group. This value is set according to the version of the received IGMP reports. When Group Compatibility Mode is IGMPv3, the lightweight router performs the LW-IGMPv3 protocol for that group.
完整的IGMPv3路由器对每个组记录使用组兼容模式（其值为IGMPv1、IGMPv2或IGMPv3）来指示它应用于该组的IGMP协议版本。该值根据收到的IGMP报告的版本设置。当组兼容性模式为IGMPv3时，轻量级路由器为该组执行LW-IGMPv3协议。
When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits this compatibility mechanism with the following rules:
当组兼容模式为IGMPv2时，LW-IGMPv3路由器将按照以下规则继承此兼容机制：
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v2 Report TO_EX({})
v2 Report TO_EX({})
v2 Leave TO_IN({})
v2 Leave TO_IN({})
When Group Compatibility Mode is IGMPv1, an LW-IGMPv3 router internally translates the following IGMPv1 and IGMPv2 messages for that group to their LW-IGMPv3 equivalents:
当组兼容模式为IGMPv1时，LW-IGMPv3路由器会在内部将该组的以下IGMPv1和IGMPv2消息转换为其LW-IGMPv3等价物：
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v1 Report TO_EX({})
v1 Report TO_EX({})
v2 Report TO_EX({})
v2 Report TO_EX({})
LW-MLDv2 hosts and routers MUST interoperate with hosts and routers running MLDv1. The method is the same as described in Section 6.2. The difference is that when an LW-MLDv2 router has a MLDv1 listener on its network, it translates the following MLDv1 messages to their LW-MLDv2 equivalents:
LW-MLDv2主机和路由器必须与运行MLDv1的主机和路由器互操作。方法与第6.2节所述相同。区别在于，当LW-MLDv2路由器的网络上有一个MLDv1侦听器时，它会将以下MLDv1消息转换为其LW-MLDv2等价物：
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
Report TO_EX({})
Report TO_EX({})
Done TO_IN({})
Done TO_IN({})
The lightweight protocols require no additional procedure for the implementation of the related protocols or systems, e.g., IGMP/MLD snooping, multicast routing protocol, and operation of application sockets, while the processing loads on the switches and routers that run IGMPv3/MLDv2 (snooping) and multicast routing protocols may be greatly decreased.
轻量级协议不需要额外的程序来实现相关协议或系统，例如IGMP/MLD侦听、多播路由协议和应用程序套接字的操作，而处理负载在运行IGMPv3/MLDv2（侦听）的交换机和路由器上多播路由协议可能会大大减少。
[8] specifies the requirements for the implementation of Source-Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight protocol follows the same rules as given in [8] except for the change of the message types due to the simplification.
[8] 指定在IGMPv3/MLDv2主机和路由器上实施源特定多播（SSM）的要求。轻量级协议遵循[8]中给出的相同规则，只是由于简化而改变了消息类型。
An LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e., TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for applications whose multicast addresses are in the SSM address range. An upstream LW-IGMPv3/LW-MLDv2 router MUST NOT establish forwarding state and MAY log an error on reception of them as described in [7].
对于多播地址在SSM地址范围内的应用程序，LW-IGMPv3/LW-MLDv2主机不应调用（*，G）join（即TO_EX（{}））和（*，G）leave（即TO_IN（{}））。上游LW-IGMPv3/LW-MLDv2路由器不得建立转发状态，并可能在接收到它们时记录错误，如[7]所述。
[9] defines the following Multicast Source Filter (MSF) APIs: (1) IPv4 Basic MSF APIs, (2) IPv4 Advanced MSF APIs, (3) Protocol-Independent Basic MSF APIs, and (4) Protocol-Independent Advanced MSF APIs.
[9] 定义以下多播源筛选器（MSF）API：（1）IPv4基本MSF API，（2）IPv4高级MSF API，（3）协议独立的基本MSF API，以及（4）协议独立的高级MSF API。
According to the MSF API definition, an LW-IGMPv3 host should implement either the IPv4 Basic MSF API or the Protocol-Independent Basic MSF API, and an LW-MLDv2 host should implement the Protocol-Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent Advanced MSF API, are optional to implement in an LW-IGMPv3/LW-MLDv2 host.
根据MSF API定义，LW-IGMPv3主机应实现IPv4基本MSF API或协议独立基本MSF API，LW-MLDv2主机应实现协议独立基本MSF API。其他API（IPv4高级MSF API和独立于协议的高级MSF API）是可选的，可在LW-IGMPv3/LW-MLDv2主机中实现。
The security considerations are the same as that of the full version of IGMPv3/MLDv2.
安全注意事项与完整版本的IGMPv3/MLDv2相同。
The authors would like to thank MBONED and MAGMA working group members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark Fine, Alfred Hoenes, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and Gong Xiangyang for their valuable suggestions and comments on this document.
作者要感谢MBONED和MAGMA工作组成员。特别感谢马歇尔·尤班克斯、郭峰、马克·费恩、阿尔弗雷德·霍恩斯、普拉尚特·金格兰、巴拉特·乔希、郭涛、王文东和龚向阳对本文件提出的宝贵建议和意见。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2] Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[3] Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC3810，2004年6月。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[5] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[5] Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[6] Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[7] Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，2006年8月。
[8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[8] Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[9] Thaler，D.，Fenner，B.，和B.Quinn，“多播源过滤器的套接字接口扩展”，RFC 3678，2004年1月。
Authors' Addresses
作者地址
Hui Liu Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China
中国北京海淀区上地信息产业基地新西路3号华为惠流技术有限公司，邮编100085
EMail: Liuhui47967@huawei.com
EMail: Liuhui47967@huawei.com
Wei Cao Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China
中国北京海淀区上地信息产业基地新西路3号华为大厦魏草华为技术有限公司，邮编100085
EMail: caowayne@huawei.com
EMail: caowayne@huawei.com
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
日本神奈川藤泽仁多5322-8520浅田惠夫大学媒体与治理研究生院
EMail: asaeda@wide.ad.jp
EMail: asaeda@wide.ad.jp