Network Working Group H. Holbrook
Request for Comments: 4604 Arastra, Inc.
Updates: 3376, 3810 B. Cain
Category: Standards Track Acopia Networks
B. Haberman
JHU APL
August 2006
Network Working Group H. Holbrook
Request for Comments: 4604 Arastra, Inc.
Updates: 3376, 3810 B. Cain
Category: Standards Track Acopia Networks
B. Haberman
JHU APL
August 2006
Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast
使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）进行源特定多播
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications.
Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）是允许主机分别通知其相邻路由器其希望接收IPv4和IPv6多播传输的协议。源特定多播（SSM）是一种多播形式，其中接收器需要指定源的网络层地址和多播目的地地址，以便接收多播传输。本文档定义了“SSM感知”路由器和主机的概念，并澄清和（在某些情况下）修改了IGMPv3和MLDv2在SSM感知路由器和主机上的行为，以适应特定于源的多播。本文档更新了IGMPv3和MLDv2规范。
The Internet Group Management Protocol (IGMP) [RFC1112, IGMPv2, IGMPv3] allows an IPv4 host to communicate IP multicast group membership information to its neighboring routers. IGMP version 3 (IGMPv3) [IGMPv3] provides the ability for a host to selectively request or filter traffic from individual sources within a multicast group.
因特网组管理协议（IGMP）[RFC1112，IGMPv2，IGMPv3]允许IPv4主机将IP多播组成员信息传送到其相邻路由器。IGMP版本3（IGMPv3）[IGMPv3]使主机能够有选择地请求或过滤来自多播组内各个源的流量。
The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers similar functionality for IPv6 hosts. MLD version 2 (MLDv2) provides the analogous "source filtering" functionality of IGMPv3 for IPv6.
多播侦听器发现协议（MLD）[RFC2710，MLDv2]为IPv6主机提供了类似的功能。MLD版本2（MLDv2）为IPv6提供了类似IGMPv3的“源过滤”功能。
Due to the commonality of function, the term "Group Management Protocol", or "GMP", will be used to refer to both IGMP and MLD. The term "Source Filtering GMP", or "SFGMP", will be used to refer jointly to the IGMPv3 and MLDv2 group management protocols.
由于功能的通用性，术语“集团管理协议”或“GMP”将用于指代IGMP和MLD。术语“源过滤GMP”或“SFGMP”将用于共同指代IGMPv3和MLDv2组管理协议。
The use of source-specific multicast is facilitated by small changes to the SFGMP protocols on both hosts and routers. [SSM] defines general requirements that must be followed by systems that implement the SSM service model; this document defines the concrete application of those requirements to systems that implement IGMPv3 and MLDv2. In doing so, this document defines modifications to the host and router portions of IGMPv3 and MLDv2 for use with SSM, and presents a number of clarifications to their behavior when used with SSM addresses. This document updates the IGMPv3 and MLDv2 specifications.
通过对主机和路由器上的SFGMP协议进行微小更改，可以方便地使用特定于源的多播。[SSM]定义了实施SSM服务模型的系统必须遵循的一般要求；本文件规定了这些要求在实现IGMPv3和MLDv2的系统中的具体应用。在此过程中，本文档定义了对IGMPv3和MLDv2的主机和路由器部分的修改，以便与SSM一起使用，并对其与SSM地址一起使用时的行为进行了一些澄清。本文档更新了IGMPv3和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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In order to emphasize the parts of this document that modify the existing protocol specifications ([RFC2710, MLDv2, IGMPv3]), as opposed to merely clarify them, any protocol modifications are marked with the tag "MODIFICATION".
为了强调本文件中修改现有协议规范的部分（[RFC2710，MLDv2，IGMPv3]），而不仅仅是澄清这些规范，任何协议修改都标有“修改”标签。
This section defines the notion of an "SSM-aware" host and then goes on to describe the API requirements and the SFGMP protocol requirements of an SSM-aware host. It is important to note that SSM can be used by any host that supports source filtering APIs and whose operating system supports the appropriate SFGMP. The SFGMP
本节定义了“支持SSM”主机的概念，然后描述了支持SSM主机的API要求和SFGMP协议要求。需要注意的是，SSM可由任何支持源筛选API且其操作系统支持适当SFGMP的主机使用。SFGMP
modifications described in this section make SSM work better on an SSM-aware host, but they are not strict prerequisites for the use of SSM.
本节中描述的修改使SSM在支持SSM的主机上工作得更好，但它们不是使用SSM的严格先决条件。
The 232/8 IPv4 address range is currently allocated for SSM by IANA [IANA-ALLOCATION]. In IPv6, the FF3x::/32 range (where 'x' is a valid IPv6 multicast scope value) is reserved for SSM semantics [RFC3306], although today SSM allocations are restricted to FF3x::/96. ([SSM] has a more thorough discussion of this topic.) A host that knows the SSM address range and is capable of applying SSM semantics to it is described as an "SSM-aware" host.
IANA[IANA-ALLOCATION]目前为SSM分配了232/8 IPv4地址范围。在IPv6中，FF3x:：/32范围（其中“x”是有效的IPv6多播作用域值）保留给SSM语义[RFC3306]，尽管目前SSM分配仅限于FF3x:：/96。（[SSM]对此主题进行了更深入的讨论。）知道SSM地址范围并能够对其应用SSM语义的主机称为“SSM感知”主机。
A host or router may be configured to apply SSM semantics to addresses other than those in the IANA-allocated range. The GMP module on a host or router SHOULD have a configuration option to set the SSM address range(s). If this configuration option exists, it MUST default to the IANA-allocated SSM range. The mechanism for setting this configuration option MUST at least allow for manual configuration. Protocol mechanisms to set this option may be defined in the future.
主机或路由器可配置为将SSM语义应用于IANA分配范围以外的地址。主机或路由器上的GMP模块应具有设置SSM地址范围的配置选项。如果存在此配置选项，则它必须默认为IANA分配的SSM范围。设置此配置选项的机制必须至少允许手动配置。将来可能会定义设置此选项的协议机制。
If the host IP module of an SSM-aware host receives a non-source-specific request to receive multicast traffic sent to an SSM destination address, it SHOULD return an error to the application, as specified in [MSFAPI] (MODIFICATION). On a non-SSM-aware host, an application that uses the wrong API (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery of packets sent to an SSM address will not receive the requested service, because an SSM-aware router (following the rules of this document) will refuse to process the request, and the application will receive no indication other than a failure to receive the requested traffic.
如果支持SSM的主机的主机IP模块接收到接收发送到SSM目标地址的多播流量的非源特定请求，则应按照[MSFAPI]（修改）中的规定向应用程序返回错误。在不支持SSM的主机上，使用错误API（例如，IGMPv3的“join（g）”、“IPMulticastListen（g，EXCLUDE（S1））、MLDv2的“IPv6MulticastListen（g，EXCLUDE（S2））”请求发送到SSM地址的数据包的应用程序将不会收到请求的服务，因为支持SSM的路由器（遵循本文档的规则）将拒绝处理该请求，并且应用程序将不会收到除接收请求流量失败之外的任何指示。
This section defines the behavior of the SFGMP protocol module on an SSM-aware host, including two modifications to the protocols as described in [IGMPv3, MLDv2]. It also includes a number of clarifications of protocol operations. In doing so, it documents the behavior of an SSM-aware host with respect to sending and receiving the following GMP message types:
本节定义了支持SSM的主机上SFGMP协议模块的行为，包括[IGMPv3，MLDv2]中描述的对协议的两个修改。它还包括对协议操作的一些澄清。在此过程中，它记录了支持SSM的主机在发送和接收以下GMP消息类型方面的行为：
- IGMPv1/v2 and MLDv1 Reports (2.2.1) - IGMPv3 and MLDv2 Reports (2.2.2) - IGMPv1 Queries, IGMPv2 and MLDv1 General Queries (2.2.3)
- IGMPv1/v2和MLDv1报告（2.2.1）-IGMPv3和MLDv2报告（2.2.2）-IGMPv1查询、IGMPv2和MLDv1一般查询（2.2.3）
- IGMPv2 Leave and MLDv1 Done (2.2.4) - IGMPv2 and MLDv1 Group Specific Query (2.2.5) - IGMPv3 and MLDv2 Group Specific Query (2.2.6) - IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7)
- IGMPv2离开和MLDv1完成（2.2.4）-IGMPv2和MLDv1组特定查询（2.2.5）-IGMPv3和MLDv2组特定查询（2.2.6）-IGMPv3和MLDv2组特定查询和源特定查询（2.2.7）
An SSM-aware host operating according to [IGMPv3, MLDv2] could send an IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is operating in "older-version compatibility mode." This is an exceptional (error) condition, indicating that the router(s) cannot provide the SFGMP support needed for SSM, and an error is logged when the host enters compatibility mode for an SSM address, as described below. In this situation, it is likely that traffic sent to a channel (S,G) will not be delivered to a receiving host that has requested to receive channel (S,G).
根据[IGMPv3、MLDv2]运行的支持SSM的主机在“旧版本兼容模式”下运行时，可能会发送SSM地址的IGMPv1、IGMPv2或MLDv1报告。这是一种异常（错误）情况，表明路由器无法提供SSM所需的SFGMP支持，当主机进入SSM地址的兼容模式时，会记录一个错误，如下所述。在这种情况下，发送到信道（S，G）的通信量很可能不会发送到已请求接收信道（S，G）的接收主机。
[IGMPv3] and [MLDv2] specify that a host MAY allow an older-version report to suppress its own IGMPv3 or MLDv2 Membership Record. An SSM-aware host, however, MUST NOT allow its report to be suppressed in this situation (MODIFICATION). Suppressing reports in this scenario would provide an avenue for an attacker to deny SSM service to other hosts on the link.
[IGMPv3]和[MLDv2]指定主机可以允许旧版本报告抑制其自己的IGMPv3或MLDv2成员记录。但是，支持SSM的主机不得允许在这种情况下抑制其报告（修改）。在这种情况下，抑制报告将为攻击者提供一种途径，使其拒绝向链路上的其他主机提供SSM服务。
A host implementation may report more than one SSM channel in a single report either by including multiple sources within a group record or by including multiple group records.
主机实现可以通过在组记录中包含多个源或通过包含多个组记录在单个报告中报告多个SSM通道。
A Group Record for a source-specific destination address may (under normal operation) be any of the following types:
源特定目标地址的组记录（在正常操作下）可以是以下任何类型：
- MODE_IS_INCLUDE as part of a Current-State Record
- 模式是当前状态记录的一部分
- ALLOW_NEW_SOURCES as part of a State-Change Record
- 允许新源作为状态更改记录的一部分
- BLOCK_OLD_SOURCES as part of a State-Change Record
- 阻止旧源作为状态更改记录的一部分
A report may include both SSM destination addresses and non-source-specific, i.e., Any-Source Multicast (ASM) destination addresses, in the same message.
报告可以在同一消息中包括SSM目的地地址和非源特定的，即任何源多播（ASM）目的地地址。
Additionally, a CHANGE_TO_INCLUDE_MODE record may be sent by a host in some cases, for instance, when the SSM address range is changed through configuration. A router should process such a record according to the normal SFGMP rules.
此外，在某些情况下，例如，当通过配置更改SSM地址范围时，主机可能会发送更改为包括模式的记录。路由器应根据正常的SFGMP规则处理此类记录。
An SSM-aware host SHOULD NOT send any of the following record types for an SSM address.
支持SSM的主机不应为SSM地址发送以下任何记录类型。
- MODE_IS_EXCLUDE as part of a Current-State Record
- 模式_是_排除为当前状态记录的一部分
- CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record
- 将_更改为_排除_模式，作为过滤器模式更改记录的一部分
This is a MODIFICATION to [IGMPv3, MLDv2], imposing a restriction on its use for SSM destination addresses. The rationale is that EXCLUDE mode does not apply to SSM addresses, and an SSM-aware router will ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM range, as described below.
这是对[IGMPv3，MLDv2]的修改，对SSM目标地址的使用施加了限制。其基本原理是排除模式不适用于SSM地址，支持SSM的路由器将忽略SSM范围内的模式_is_EXCLUDE并将模式_更改为_EXCLUDE_模式请求，如下所述。
If an IGMPv1 Query, or an IGMPv2 or MLDv1 General Query is received, the SFGMP protocol specifications require the host to revert to the older (IGMPv1, IGMPv2, or MLDv1) mode of operation on that interface. If this occurs, the host will stop reporting source-specific subscriptions on that interface and will start using IGMPv1, IGMPv2, or MLDv1 to report interest in all SSM destination addresses, unqualified by a source address. As a result, SSM semantics will no longer be applied to the multicast group address by the router.
如果收到IGMPv1查询或IGMPv2或MLDv1一般查询，SFGMP协议规范要求主机在该接口上恢复到较旧的（IGMPv1、IGMPv2或MLDv1）操作模式。如果发生这种情况，主机将停止报告该接口上的源特定订阅，并将开始使用IGMPv1、IGMPv2或MLDv1来报告对所有SSM目标地址的兴趣，但不符合源地址的要求。因此，路由器将不再将SSM语义应用于多播组地址。
A router compliant with this document would never generate an IGMPv1, IGMPv2, or MLDv1 query for an address in the SSM range; thus, this situation only occurs either if the router is not SSM-aware, or if the host and the router disagree about the SSM address range (for instance, if they have inconsistent manual configurations).
符合本文档的路由器永远不会为SSM范围内的地址生成IGMPv1、IGMPv2或MLDv1查询；因此，只有当路由器不知道SSM，或者主机和路由器不同意SSM地址范围时（例如，如果它们具有不一致的手动配置），才会发生这种情况。
A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1 query for an SSM address (MODIFICATION).
如果主机收到SSM地址（修改）的IGMPv1、IGMPv2或MLDv1查询，则应记录错误。
In order to mitigate this problem, it must be administratively assured that all routers on a given shared-medium network are compliant with this document and are in agreement about the SSM address range.
为了缓解此问题，必须在管理上确保给定共享媒体网络上的所有路由器都符合本文档的要求，并就SSM地址范围达成一致。
IGMP Leave and MLD Done messages are not processed by hosts. IGMPv2 Leave and MLDv1 Done messages should not be sent for an SSM address, unless the sending host has reverted to older-version compatibility mode, with all the caveats described above.
主机不处理IGMP Leave和MLD Done消息。不应为SSM地址发送IGMPv2 Leave和MLDv1 Done消息，除非发送主机已恢复到旧版本兼容模式，并遵守上述所有注意事项。
If a host receives an IGMPv2 or MLDv1 Group Specific Query for an address in any configured source-specific range, it should process the query normally, as per [IGMPv3, MLDv2], even if the group queried is a source-specific destination address. The transmission of such a query likely indicates either that the sending router is not compliant with this document or that it is not configured with the same SSM address range(s) as the receiving host. A host SHOULD log an error in this case (MODIFICATION).
如果主机收到针对任何配置的源特定范围内的地址的IGMPv2或MLDv1组特定查询，则它应按照[IGMPv3，MLDv2]正常处理该查询，即使查询的组是源特定的目标地址。此类查询的传输可能表明发送路由器不符合本文档，或者未配置与接收主机相同的SSM地址范围。在这种情况下，主机应该记录一个错误（修改）。
If an SSM-aware host receives an SFGMP Group-Specific Query for an SSM address, it must respond with a report if the group matches the source-specific destination address of any of its subscribed source-specific channels, as specified in [IGMPv3, MLDv2].
如果支持SSM的主机收到针对SSM地址的SFGMP组特定查询，则如果该组与[IGMPv3，MLDv2]中规定的任何订阅的源特定频道的源特定目标地址相匹配，则该主机必须以报告进行响应。
The rationale for this is that, although in the current SFGMP protocol specifications a router would have no reason to send one, the semantics of such a query are well-defined in this range and future implementations may have reason to send such a query. Be liberal in what you accept.
其基本原理是，尽管在当前的SFGMP协议规范中，路由器没有理由发送查询，但此类查询的语义在此范围内定义良好，未来的实现可能有理由发送此类查询。在你接受的事情上要开明。
An SFGMP router typically uses a Group-and-Source-Specific Query to query an SSM channel that a host has requested to leave via a BLOCK_OLD_SOURCES record. A host must respond to a Group-and-Source-Specific Query for which the group and source in the query match any channel for which the host has a subscription, as required by [IGMPv3, MLDv2]. The use of an SSM address does not change this behavior.
SFGMP路由器通常使用特定于组和源的查询来查询主机通过BLOCK_OLD_SOURCES记录请求离开的SSM通道。根据[IGMPv3，MLDv2]的要求，主机必须响应特定于组和源的查询，查询中的组和源与主机订阅的任何通道匹配。SSM地址的使用不会改变此行为。
A host must be able to process a query with multiple sources listed per group, again as required by [IGMPv3, MLDv2]. The use of an SSM address does not modify the behavior of the SFGMPs in this regard.
主机必须能够按照[IGMPv3，MLDv2]的要求处理每个组列出多个源的查询。在这方面，SSM地址的使用不会修改SFGMP的行为。
Routers must be aware of the SSM address range in order to provide the SSM service model. A router that knows the SSM address range and is capable of applying SSM semantics to it as described in this section is described as an "SSM-aware" router. An SSM-aware router MAY have a configuration option to apply SSM semantics to addresses other than the IANA-allocated range, but if such an option exists, it MUST default to the IANA-allocated range.
路由器必须知道SSM地址范围，以便提供SSM服务模型。知道SSM地址范围并能够如本节所述对其应用SSM语义的路由器称为“SSM感知”路由器。支持SSM的路由器可能有一个配置选项，用于将SSM语义应用于IANA分配范围以外的地址，但如果存在此选项，则必须默认为IANA分配范围。
This section documents the behavior of routers with respect to the following types of SFGMP messages for source-specific destination addresses:
本节记录了路由器在源特定目标地址的以下类型SFGMP消息方面的行为：
- IGMPv3 and MLDv2 Reports (3.1) - IGMPv3 and MLDv2 General Query (3.2) - IGMPv3 and MLDv2 Group-Specific Query (3.3) - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4) - IGMPv1/v2 and MLDv1 Reports (3.5) - IGMPv1/v2 and MLDv1 Queries (3.6) - IGMPv2 Leave and MLDv1 Done (3.7)
- IGMPv3和MLDv2报告（3.1）-IGMPv3和MLDv2一般查询（3.2）-IGMPv3和MLDv2组特定查询（3.3）-IGMPv3和MLDv2组和源特定查询（3.4）-IGMPv1/v2和MLDv1报告（3.5）-IGMPv1/v2和MLDv1查询（3.6）-IGMPv2休假和MLDv1完成（3.7）
SFGMP Reports are used to report source-specific subscriptions in the SSM address range. A router SHOULD ignore a group record of either of the following types if it refers to an SSM destination address:
SFGMP报告用于报告SSM地址范围内的源特定订阅。如果路由器引用SSM目标地址，则应忽略以下任一类型的组记录：
- MODE_IS_EXCLUDE Current-State Record
- 模式为排除当前状态记录
- CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record
- 更改为排除模式过滤器模式更改记录
A router MAY choose to log an error in either case. It MUST process any other group records within the same report. These behaviors are MODIFICATIONS to [IGMPv3, MLDv2] to prevent non-source-specific semantics from being applied to SSM addresses, and to avoid reverting to older-version compatibility mode.
路由器可以选择在任何一种情况下记录错误。它必须处理同一报告中的任何其他集团记录。这些行为是对[IGMPv3，MLDv2]的修改，以防止非源特定语义应用于SSM地址，并避免恢复到旧版本的兼容模式。
A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per the normal SFGMP rules; Section 2.2.2 describes a legitimate scenario when this could occur.
根据正常的SFGMP规则处理从_到_INCLUDE _模式过滤器模式更改记录的更改；第2.2.2节描述了可能发生这种情况的合法场景。
An SSM router sends periodic SFGMP General Queries as per the IGMPv3 and MLDv2 specifications. No change in behavior is required for SSM.
SSM路由器根据IGMPv3和MLDv2规范定期发送SFGMP一般查询。SSM不需要改变行为。
SFGMP routers that support source-specific multicast may send group-specific queries for addresses in the source-specific range. This specification does not explicitly prohibit such a message, although, at the time of this writing, a router conformant to [IGMPv3, MLDv2] would not send one.
支持特定于源的多播的SFGMP路由器可以发送特定于组的查询，以查找特定于源的范围内的地址。本规范并未明确禁止此类消息，尽管在撰写本文时，符合[IGMPv3，MLDv2]的路由器不会发送此类消息。
SFGMP Group-and-Source-Specific Queries are used when a receiver has indicated that it is no longer interested in receiving traffic from a particular (S,G) pair to determine if there are any remaining directly-attached hosts with interest in that (S,G) pair. Group-and-Source-Specific Queries are used within the source-specific address range when a router receives a BLOCK_OLD_SOURCES Record for one or more source-specific groups. These queries are sent normally, as per [IGMPv3, MLDv2].
SFGMP组和特定于源的查询在接收者表示不再有兴趣接收来自特定（S，G）对的流量时使用，以确定该（S，G）对中是否有任何剩余的直接连接主机感兴趣。当路由器收到一个或多个源特定组的BLOCK_OLD_SOURCES记录时，在源特定地址范围内使用组和源特定查询。这些查询按照[IGMPv3，MLDv2]正常发送。
An IGMPv1/v2 or MLDv1 report for an address in the source-specific range could be sent by a non-SSM-aware host. A router SHOULD ignore all such reports and specifically SHOULD NOT use them to establish IP forwarding state. This is a MODIFICATION to [IGMPv3, MLDv2]. A router MAY log an error if it receives such a report (also a MODIFICATION).
源特定范围内地址的IGMPv1/v2或MLDv1报告可由不支持SSM的主机发送。路由器应忽略所有此类报告，尤其不应使用它们来建立IP转发状态。这是对[IGMPv3，MLDv2]的修改。如果路由器收到这样的报告（也是修改），它可能会记录错误。
An SFGMP router that loses the querier election to a lower version router must log an error, as specified by [IGMPv3, MLDv2].
根据[IGMPv3，MLDv2]的规定，SFGMP路由器在较低版本的路由器上失去查询器选择时必须记录错误。
An IGMPv2 Leave or MLDv1 Done message may be sent by a non-SSM-aware host. A router SHOULD ignore all such messages in the source-specific address range and MAY log an error (MODIFICATION).
IGMPv2 Leave或MLDv1 Done消息可由不支持SSM的主机发送。路由器应忽略源特定地址范围内的所有此类消息，并可能记录错误（修改）。
The specific protocol modifications described in this document are not known to create any security concerns that are not already present when IGMPv3 or MLDv2 is used with ASM-style multicast. The reader is referred to [SSM] for an analysis of SSM-specific security issues.
当IGMPv3或MLDv2与ASM样式的多播一起使用时，本文档中描述的特定协议修改不会产生任何安全问题。读者可参考[SSM]了解SSM特定安全问题的分析。
It is important that a router not accept non-source-specific reception requests for an SSM destination address. The rules of [IGMPv3] and [MLDv2] require a router, upon receiving such a membership report, to revert to earlier version compatibility mode for the group in question. If the router were to revert in this situation, it would prevent an IGMPv3-capable host from receiving SSM service for that destination address, thus creating a potential for an attacker to deny SSM service to other hosts on the same link.
重要的是，路由器不接受SSM目的地址的非源特定接收请求。[IGMPv3]和[MLDv2]的规则要求路由器在收到此类成员报告后，恢复到相关组的早期版本兼容模式。如果路由器在这种情况下恢复，它将阻止支持IGMPv3的主机接收该目标地址的SSM服务，从而使攻击者有可能拒绝向同一链路上的其他主机提供SSM服务。
The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve Deering, Toerless Eckert, and Pekka Savola for their input and careful review.
作者要感谢文斯·拉维亚诺、尼迪·巴斯卡、史蒂夫·迪林、无趾埃克特和佩卡·萨沃拉的投入和仔细的评论。
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[IGMPv2]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[IGMPv3]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[MSFAPI]Thaler，D.，Fenner，B.，和B.Quinn，“多播源过滤器的套接字接口扩展”，RFC 3678，2004年1月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[SSM]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，2006年8月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDv2]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[IANA-ALLOC] Internet Assigned Numbers Authority, http://www.iana.org/assignments/multicast-addresses.
[IANA-ALOC]互联网分配号码管理局，http://www.iana.org/assignments/multicast-addresses.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
Authors' Addresses
作者地址
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
休·霍尔布鲁克·阿拉斯特拉公司，邮政信箱10905，加利福尼亚州帕洛阿尔托市，邮编94303
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Brad Cain Acopia Networks
Brad Cain Acopia网络公司
EMail: bcain99@gmail.com
EMail: bcain99@gmail.com
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099
布莱恩·哈伯曼·约翰·霍普金斯大学应用物理实验室，马里兰州劳雷尔市约翰·霍普金斯路11100号，20723-6099
EMail: brian@innovationslab.net
EMail: brian@innovationslab.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。