Network Working Group B. Fenner
Request for Comments: 4605 AT&T Research
Category: Standards Track H. He
Nortel
B. Haberman
JHU-APL
H. Sandick
Little River Elementary School
August 2006
Network Working Group B. Fenner
Request for Comments: 4605 AT&T Research
Category: Standards Track H. He
Nortel
B. Haberman
JHU-APL
H. Sandick
Little River Elementary School
August 2006
Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）
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
摘要
In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information.
在某些拓扑中，不需要运行多播路由协议。对于设备来说，学习和代理组成员信息并简单地基于该信息转发多播数据包就足够了。本文档描述了一种仅基于Internet组管理协议（IGMP）或多播侦听器发现（MLD）成员信息的转发机制。
This document applies spanning tree multicast routing [MCAST] to an Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD)-only environment. The topology is limited to a tree, since we specify no protocol to build a spanning tree over a more complex topology. The root of the tree is assumed to be connected to a wider multicast infrastructure.
本文档将生成树多播路由[MCAST]应用于仅Internet组管理协议（IGMP）或多播侦听器发现（MLD）环境。该拓扑仅限于树，因为我们没有指定在更复杂的拓扑上构建生成树的协议。假设树的根连接到更广泛的多播基础设施。
In a simple tree topology, it is not necessary to run a multicast routing protocol. It is sufficient to learn and proxy group membership information and simply forward multicast packets based upon that information. One typical example of such a tree topology can be found on an edge aggregation box such as a Digital Subscriber Line Access Multiplexer (DSLAM). In most deployment scenarios, an edge box has only one connection to the core network side and has many connections to the customer side.
在简单的树拓扑中，不需要运行多播路由协议。只需学习和代理组成员信息，并根据该信息转发多播数据包就足够了。这种树状拓扑的一个典型示例可以在诸如数字用户线路接入多路复用器（DSLAM）之类的边缘聚合盒上找到。在大多数部署场景中，边缘盒只有一个到核心网络端的连接，并且有多个到客户端的连接。
Using IGMP/MLD-based forwarding to replicate multicast traffic on devices such as the edge boxes can greatly simplify the design and implementation of those devices. By not supporting more complicated multicast routing protocols such as Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), it reduces not only the cost of the devices but also the operational overhead. Another advantage is that it makes the proxy devices independent of the multicast routing protocol used by the core network routers. Hence, proxy devices can be easily deployed in any multicast network.
使用基于IGMP/MLD的转发在诸如边缘盒之类的设备上复制多播流量可以极大地简化这些设备的设计和实现。由于不支持协议独立多播（PIM）或距离向量多播路由协议（DVMRP）等更复杂的多播路由协议，它不仅降低了设备成本，而且还降低了操作开销。另一个优点是，它使代理设备独立于核心网络路由器使用的多播路由协议。因此，代理设备可以很容易地部署在任何多播网络中。
Robustness in an edge box is usually achieved by using a hot spare connection to the core network. When the first connection fails, the edge box fails over to the second connection. IGMP/MLD-based forwarding can benefit from such a mechanism and use the spare connection for its redundant or backup connection to multicast routers. When an edge box fails over to the second connection, the proxy upstream connection can also be updated to the new connection.
边缘盒中的健壮性通常通过使用到核心网络的热备盘连接来实现。当第一个连接失败时，边缘盒将故障切换到第二个连接。基于IGMP/MLD的转发可以受益于这种机制，并将备用连接用于到多播路由器的冗余或备份连接。当边缘盒故障切换到第二个连接时，代理上游连接也可以更新为新连接。
The IGMP/MLD-based forwarding only works in a simple tree topology. The tree must be manually configured by designating upstream and downstream interfaces on each proxy device. In addition, the IP addressing scheme applied to the proxying tree topology SHOULD be configured to ensure that a proxy device can win the IGMP/MLD Querier election to be able to forward multicast traffic. There are no other multicast routers except the proxy devices within the tree, and the root of the tree is expected to be connected to a wider multicast infrastructure. This protocol is limited to a single administrative domain.
基于IGMP/MLD的转发只能在简单的树拓扑中工作。必须通过在每个代理设备上指定上游和下游接口来手动配置树。此外，应配置应用于代理树拓扑的IP寻址方案，以确保代理设备能够赢得IGMP/MLD查询器选择，从而能够转发多播流量。除了树中的代理设备外，没有其他多播路由器，树的根将连接到更广泛的多播基础设施。此协议仅限于单个管理域。
In more complicated scenarios where the topology is not a tree, a more robust failover mechanism is desired, or more than one administrative domain is involved, a multicast routing protocol should be used.
在拓扑不是树、需要更健壮的故障切换机制或涉及多个管理域的更复杂场景中，应使用多播路由协议。
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]中所述进行解释。
This document is a product of the Multicast & Anycast Group Membership (MAGMA) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at magma@ietf.org and/or the authors.
本文件是互联网工程任务组内的多播和选播组成员（MAGMA）工作组的成果。征求意见，并应发送至工作组的邮件列表：magma@ietf.org和/或作者。
A proxy device's interface in the direction of the root of the tree. Also called the "Host interface".
树根方向上的代理设备接口。也称为“主机接口”。
Each of a proxy device's interfaces that is not in the direction of the root of the tree. Also called the "Router interfaces".
不在树根方向的每个代理设备接口。也称为“路由器接口”。
In IPv4 environments, for each multicast group, a group is in IGMP version 1 (IGMPv1) [RFC1112] mode if an IGMPv1 report is heard. A group is in IGMP version 2 (IGMPv2) [RFC2236] mode if an IGMPv2 report is heard but no IGMPv1 report is heard. A group is in IGMP version 3 (IGMPv3) [RFC3376] mode if an IGMPv3 report is heard but no IGMPv1 or IGMPv2 report is heard.
在IPv4环境中，对于每个多播组，如果听到IGMPv1报告，则组处于IGMP版本1（IGMPv1）[RFC1112]模式。如果听到IGMPv2报告但没有听到IGMPv1报告，则组处于IGMP版本2（IGMPv2）[RFC2236]模式。如果听到IGMPv3报告但未听到IGMPv1或IGMPv2报告，则组处于IGMP版本3（IGMPv3）[RFC3376]模式。
In IPv6 environments, for each multicast group, a group is in MLD version 1 (MLDv1) [RFC2710] mode if an MLDv1 report is heard. MLDv1 is equivalent to IGMPv2. A group is in MLD version 2 (MLDv2) [MLDv2] mode if an MLDv2 report is heard but no MLDv1 report is heard. MLDv2 is equivalent to IGMPv3.
在IPv6环境中，对于每个多播组，如果听到MLDv1报告，则组处于MLD版本1（MLDv1）[RFC2710]模式。MLDv1相当于IGMPv2。如果听到MLDv2报告但没有听到MLDv1报告，则组处于MLD版本2（MLDv2）[MLDv2]模式。MLDv2相当于IGMPv3。
When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a group membership on an interface. When a group is in IGMPv3/MLDv2 mode, the subscription is an IGMPv3/MLDv2 state entry, i.e., a (multicast address, group timer, filter-mode, source-element list) tuple, on an interface.
当组处于IGMPv1或IGMPv2/MLDv1模式时，订阅是接口上的组成员身份。当组处于IGMPv3/MLDv2模式时，订阅是接口上的IGMPv3/MLDv2状态条目，即（多播地址、组计时器、筛选器模式、源元素列表）元组。
The database maintained at each proxy device into which the membership information of each of its downstream interfaces is merged. The membership database is a set of membership records of the form:
在每个代理设备上维护的数据库，其每个下游接口的成员信息都合并到该数据库中。成员资格数据库是一组以下表格的成员资格记录：
(multicast-address, filter-mode, source-list)
（多播地址、筛选器模式、源列表）
Please refer to IGMPv3/MLDv2 [RFC3376, MLDv2] specifications for the definition of the fields "filter-mode" and "source-list". The operational behaviors of the membership database is defined in section 4.1.
有关“过滤模式”和“源列表”字段的定义，请参考IGMPv3/MLDv2[RFC3376，MLDv2]规范。第4.1节定义了成员资格数据库的操作行为。
A proxy device performing IGMP/MLD-based forwarding has a single upstream interface and one or more downstream interfaces. These designations are explicitly configured; there is no protocol to determine what type each interface is. It performs the router portion of the IGMP [RFC1112, RFC2236, RFC3376] or MLD [RFC2710, MLDv2] protocol on its downstream interfaces, and the host portion of IGMP/MLD on its upstream interface. The proxy device MUST NOT perform the router portion of IGMP/MLD on its upstream interface.
执行基于IGMP/MLD的转发的代理设备具有单个上游接口和一个或多个下游接口。这些名称是明确配置的；没有协议来确定每个接口的类型。它在其下游接口上执行IGMP[RFC1112，RFC2236，RFC3376]或MLD[RFC2710，MLDv2]协议的路由器部分，在其上游接口上执行IGMP/MLD的主机部分。代理设备不得在其上游接口上执行IGMP/MLD的路由器部分。
The proxy device maintains a database consisting of the merger of all subscriptions on any downstream interface. Refer to Section 4 for the details about the construction and maintenance of the membership database.
代理设备维护由任何下游接口上的所有订阅合并而成的数据库。有关成员数据库的构造和维护的详细信息，请参阅第4节。
The proxy device sends IGMP/MLD membership reports on the upstream interface when queried and sends unsolicited reports or leaves when the database changes.
代理设备在查询时在上游接口上发送IGMP/MLD成员资格报告，并在数据库更改时发送未经请求的报告或离开。
When the proxy device receives a packet destined for a multicast group (channel in Source-Specific Multicast (SSM)), it uses a list consisting of the upstream interface and any downstream interface that has a subscription pertaining to this packet and on which it is the IGMP/MLD Querier. This list may be built dynamically or cached. It removes the interface on which this packet arrived from the list and forwards the packet to the remaining interfaces (this may include the upstream interface).
当代理设备接收到目的地为多播组（源特定多播（SSM）中的信道）的分组时，它使用由上游接口和任何下游接口组成的列表，其中上游接口和任何下游接口具有与该分组相关的订阅，并且它是IGMP/MLD查询器。此列表可以动态生成或缓存。它从列表中删除该数据包到达的接口，并将该数据包转发给其余接口（这可能包括上游接口）。
Note that the rule that a proxy device must be the querier in order to forward packets restricts the IP addressing scheme used; in particular, the IGMP/MLD-based forwarding devices must be given the lowest IP addresses of any potential IGMP/MLD Querier on the link, in order to win the IGMP/MLD Querier election. IGMP/MLD Querier
请注意，代理设备必须是查询者才能转发数据包的规则限制了使用的IP寻址方案；特别是，基于IGMP/MLD的转发设备必须获得链路上任何潜在IGMP/MLD查询器的最低IP地址，以便赢得IGMP/MLD查询器选举。IGMP/MLD查询器
election rule defines that the Querier that has the lowest IP address wins the election. (The IGMP/MLD Querier election rule is defined in IGMP/MLD specifications as part of the IGMP/MLD behavior.) So in an IGMP/MLD-based forwarding-only environment, if non-proxy device wins the IGMP/MLD Querier election, no packets will flow.
选举规则定义具有最低IP地址的查询者赢得选举。（IGMP/MLD查询器选择规则在IGMP/MLD规范中定义为IGMP/MLD行为的一部分。）因此，在基于IGMP/MLD的仅转发环境中，如果非代理设备赢得IGMP/MLD查询器选择，则不会有数据包流动。
For example, the figure below shows an IGMP/MLD-based forwarding-only environment:
例如，下图显示了基于IGMP/MLD的仅转发环境：
LAN 1 --------------------------------------
Upstream | | Upstream
A(non-proxy) B(proxy)
Downstream |(lowest IP) | Downstream
LAN 2 --------------------------------------
LAN 1 --------------------------------------
Upstream | | Upstream
A(non-proxy) B(proxy)
Downstream |(lowest IP) | Downstream
LAN 2 --------------------------------------
Device A has the lowest IP address on LAN 2, but it is not a proxy device. According to IGMP/MLD Querier election rule, A will win the election on LAN 2 since it has the lowest IP address. Device B will not forward traffic to LAN 2 since it is not the querier on LAN 2.
设备A在LAN 2上的IP地址最低，但它不是代理设备。根据IGMP/MLD Querier选举规则，A将在LAN 2上赢得选举，因为它的IP地址最低。设备B不会将流量转发到LAN 2，因为它不是LAN 2上的查询器。
The election of a single forwarding proxy is necessary to avoid local loops and redundant traffic for links that are considered downstream links by multiple IGMP/MLD-based forwarders. This rule "piggy-backs" forwarder election on IGMP/MLD Querier election. The use of the IGMP/MLD Querier election process to choose the forwarding proxy delivers similar functionality on the local link as the PIM Assert mechanism. On a link with only one IGMP/MLD-based forwarding device, this rule MAY be disabled (i.e., the device MAY be configured to forward packets to an interface on which it is not the querier). However, the default configuration MUST include the querier rule, for example, for redundancy purposes, as shown in the figure below:
对于被多个基于IGMP/MLD的转发器视为下游链路的链路，有必要选择单个转发代理以避免本地环路和冗余通信。这条规则“背负”了IGMP/MLD查询者选举中的货运代理选举。使用IGMP/MLD查询器选择过程选择转发代理在本地链路上提供了与PIM断言机制类似的功能。在仅具有一个基于IGMP/MLD的转发设备的链路上，可以禁用该规则（即，该设备可以被配置为将分组转发到其不是查询器的接口）。但是，默认配置必须包括查询规则，例如，出于冗余目的，如下图所示：
LAN 1 --------------------------------------
Upstream | | Upstream
A B
Downstream | | Downstream
LAN 2 --------------------------------------
LAN 1 --------------------------------------
Upstream | | Upstream
A B
Downstream | | Downstream
LAN 2 --------------------------------------
LAN 2 can have two proxy devices, A and B. In such a configuration, one proxy device must be elected to forward the packets. This document requires that the forwarder must be the IGMP/MLD querier. So proxy device A will forward packets to LAN 2 only if A is the querier. In the above figure, if A is the only proxy device, A can be configured to forward packets even though B is the querier.
LAN 2可以有两个代理设备A和B。在这种配置中，必须选择一个代理设备转发数据包。本文件要求货运代理必须是IGMP/MLD查询人。因此，只有当A是查询者时，代理设备A才会将数据包转发到LAN 2。在上图中，如果A是唯一的代理设备，则A可以配置为转发数据包，即使B是查询者。
Note that this does not protect against an "upstream loop". For example, see the figure below:
请注意，这并不能防止“上游回路”。例如，请参见下图：
LAN 1 --------------------------------------
Upstream | | Downstream
A B
Downstream | | Upstream
LAN 2 --------------------------------------
LAN 1 --------------------------------------
Upstream | | Downstream
A B
Downstream | | Upstream
LAN 2 --------------------------------------
B will unconditionally forward packets from LAN 1 to LAN 2, and A will unconditionally forward packets from LAN 2 to LAN 1. This will cause an upstream loop. A multicast routing protocol that employs a tree building algorithm is required to resolve loops like this.
B将无条件地将数据包从LAN 1转发到LAN 2，A将无条件地将数据包从LAN 2转发到LAN 1。这将导致上游循环。需要采用树构建算法的多播路由协议来解决这样的循环。
This specification describes a protocol that works only in a simple tree topology. The tree must be manually configured by designating upstream and downstream interfaces on each proxy device, and the root of the tree is expected to be connected to a wider multicast infrastructure.
本规范描述了仅在简单树拓扑中工作的协议。树必须通过在每个代理设备上指定上游和下游接口来手动配置，并且树的根应该连接到更广泛的多播基础设施。
In order for senders to send from inside the proxy tree, all traffic is forwarded towards the root. The multicast router(s) connected to the wider multicast infrastructure should be configured to treat all systems inside the proxy tree as though they were directly connected; e.g., for Protocol Independent Multicast - Sparse Mode (PIM-SM) [PIM-SM], these routers should Register-encapsulate traffic from new sources within the proxy tree just as they would directly-connected sources.
为了让发送方从代理树内部进行发送，所有流量都被转发到根目录。连接到更广泛的多播基础设施的多播路由器应配置为将代理树内的所有系统视为直接连接；e、 例如，对于独立于协议的多播稀疏模式（PIM-SM）[PIM-SM]，这些路由器应该在代理树中注册封装来自新源的流量，就像它们直接连接的源一样。
This information is likely to be manually configured; IGMP/MLD-based multicast forwarding provides no way for the routers upstream of the proxy tree to know what networks are connected to the proxy tree. If the proxy topology is congruent with some routing topology, this information MAY be learned from the routing protocol running on the topology; e.g., a router may be configured to treat multicast packets from all prefixes learned from routing protocol X via interface Y as though they were from a directly connected system.
此信息可能是手动配置的；基于IGMP/MLD的多播转发无法让代理树上游的路由器知道哪些网络连接到代理树。如果代理拓扑与某些路由拓扑一致，则可以从拓扑上运行的路由协议中学习该信息；e、 例如，路由器可被配置为处理来自经由接口Y从路由协议X学习的所有前缀的多播分组，如同它们来自直接连接的系统一样。
This section describes an IGMP/MLD-based multicast forwarding device's actions in more detail.
本节更详细地描述了基于IGMP/MLD的多播转发设备的操作。
The proxy device performs the router portion of the IGMP/MLD protocol on each downstream interface. For each interface, the version of IGMP/MLD used is explicitly configured and defaults to the highest version supported by the system.
代理设备在每个下游接口上执行IGMP/MLD协议的路由器部分。对于每个接口，使用的IGMP/MLD版本都是明确配置的，默认为系统支持的最高版本。
The output of this protocol is a set of subscriptions; this set is maintained separately on each downstream interface. In addition, the subscriptions on each downstream interface are merged into the membership database.
该协议的输出是一组订阅；该集合在每个下游接口上单独维护。此外，每个下游接口上的订阅将合并到成员数据库中。
The membership database is a set of membership records of the form:
成员资格数据库是一组以下表格的成员资格记录：
(multicast-address, filter-mode, source-list)
（多播地址、筛选器模式、源列表）
Each record is the result of the merge of all subscriptions for that record's multicast-address on downstream interfaces. If some subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these subscriptions are converted to IGMPv3/MLDv2 subscriptions. The IGMPv3/MLDv2 and the converted subscriptions are first preprocessed to remove the timers in the subscriptions and, if the filter mode is EXCLUDE, to remove every source whose source timer > 0. Then the preprocessed subscriptions are merged using the merging rules for multiple memberships on a single interface (specified in Section 3.2 of the IGMPv3 specification [RFC3376] and in Section 4.2 of the MLDv2 specification [MLDv2]) to create the membership record. For example, there are two downstream interfaces, I1 and I2, that have subscriptions for multicast address G. I1 has an IGMPv2/MLDv1 subscription that is (G). I2 has an IGMPv3/MLDv2 subscription that has membership information (G, INCLUDE, (S1, S2)). The I1's subscription is converted to an IGMPv3/MLDv2 subscription that has membership information (G, EXCLUDE, NULL). Then the subscriptions are preprocessed and merged, and the final membership record is (G, EXCLUDE, NULL).
每条记录都是下游接口上该记录的多播地址的所有订阅合并的结果。如果某些订阅是IGMPv1或IGMPv2/MLDv1订阅，则这些订阅将转换为IGMPv3/MLDv2订阅。首先对IGMPv3/MLDv2和转换后的订阅进行预处理，以删除订阅中的计时器，如果筛选模式为排除，则删除源计时器>0的每个源。然后，使用单个接口上多个成员身份的合并规则（在IGMPv3规范[RFC3376]第3.2节和MLDv2规范[MLDv2]第4.2节中指定）合并预处理订阅，以创建成员身份记录。例如，有两个下游接口I1和I2，它们具有多播地址G的订阅。I1具有IGMPv2/MLDv1订阅，即（G）。I2具有具有成员信息（G，INCLUDE，（S1，S2））的IGMPv3/MLDv2订阅。I1的订阅被转换为具有成员信息（G、EXCLUDE、NULL）的IGMPv3/MLDv2订阅。然后对订阅进行预处理和合并，最终的成员记录是（G，EXCLUDE，NULL）。
The proxy device performs the host portion of the IGMP/MLD protocol on the upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1 querier on the upstream network, then the proxy device will perform IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly. Otherwise, it will perform IGMPv3/MLDv2.
代理设备在上游接口上执行IGMP/MLD协议的主机部分。如果上游网络上存在IGMPv1或IGMPv2/MLDv1查询器，则代理设备将相应地在上游接口上执行IGMPv1或IGMPv2/MLDv1。否则，它将执行IGMPv3/MLDv2。
If the proxy device performs IGMPv3/MLDv2 on the upstream interface, then when the composition of the membership database changes, the change in the database is reported on the upstream interface as though this proxy device were a host performing the action. If the proxy device performs IGMPv1 or IGMPv2/MLDv1 on the upstream interface, then when the membership records are created or deleted, the changes are reported on the upstream interface. All other changes are ignored. When the proxy device reports using IGMPv1 or IGMPv2/MLDv1, only the multicast address field in the membership record is used.
如果代理设备在上游接口上执行IGMPv3/MLDv2，则当成员数据库的组成发生变化时，将在上游接口上报告数据库中的变化，就像此代理设备是执行该操作的主机一样。如果代理设备在上游接口上执行IGMPv1或IGMPv2/MLDv1，则在创建或删除成员记录时，将在上游接口上报告更改。将忽略所有其他更改。当代理设备使用IGMPv1或IGMPv2/MLDv1报告时，仅使用成员记录中的多播地址字段。
A proxy device forwards packets received on its upstream interface to each downstream interface based upon the downstream interface's subscriptions and whether or not this proxy device is the IGMP/MLD Querier on each interface. A proxy device forwards packets received on any downstream interface to the upstream interface, and to each downstream interface other than the incoming interface based upon the downstream interfaces' subscriptions and whether or not this proxy device is the IGMP/MLD Querier on each interface. A proxy device MAY use a forwarding cache in order not to make this decision for each packet, but MUST update the cache using these rules any time any of the information used to build it changes.
代理设备根据下游接口的订阅以及该代理设备是否是每个接口上的IGMP/MLD查询器，将在其上游接口上接收的数据包转发到每个下游接口。代理设备根据下游接口的订阅以及该代理设备是否是每个接口上的IGMP/MLD查询器，将在任何下游接口上接收的分组转发到上游接口，并转发到除传入接口之外的每个下游接口。代理设备可以使用转发缓存，以便不对每个数据包做出此决定，但在用于构建数据包的任何信息发生更改时，必须使用这些规则更新缓存。
To support Source-Specific Multicast (SSM), the proxy device should be compliant with the specification about using IGMPv3 for SSM [SSM]. Note that the proxy device should be compliant with both the IGMP Host Requirement and the IGMP Router Requirement for SSM since it performs IGMP Host Portion on the upstream interface and IGMP Router Portion on each downstream interface.
为了支持特定于源的多播（SSM），代理设备应符合关于将IGMPv3用于SSM[SSM]的规范。注意，代理设备应符合SSM的IGMP主机要求和IGMP路由器要求，因为它在上游接口上执行IGMP主机部分，在每个下游接口上执行IGMP路由器部分。
An interface can be configured to perform IGMPv1 or IGMPv2. In this scenario, the SSM semantic will not be maintained for that interface. However, a proxy device that supports this document should ignore those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more importantly, the packets with source-specific addresses SHOULD NOT be forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these addresses.
可以将接口配置为执行IGMPv1或IGMPv2。在这种情况下，将不会为该接口维护SSM语义。但是，支持此文档的代理设备应忽略发送到SSM地址的IGMPv1或IGMPv2订阅。更重要的是，具有源特定地址的数据包不应转发到具有这些地址的IGMPv2或IGMPv1订阅的接口。
Since only the Querier forwards packets, the IGMP/MLD Querier election process may lead to black holes if a non-forwarder is elected Querier. An attacker on a downstream LAN can cause itself to be elected Querier, and as a result, no packets would be forwarded.
由于只有查询器转发数据包，如果非转发器被选为查询器，则IGMP/MLD查询器选择过程可能导致黑洞。下游LAN上的攻击者可使自己被选为查询者，因此不会转发任何数据包。
However, there are some operational ways to avoid this problem. It is fairly common for an operator to number the routers starting from the bottom of the subnet. So an operator SHOULD assign the subnet's lowest IP address(es) to a proxy (proxies) in order for the proxy (proxies) to win the querier election.
但是，有一些可操作的方法可以避免此问题。运营商通常从子网底部开始对路由器进行编号。因此，运营商应该将子网的最低IP地址分配给一个代理（proxy），以便代理（proxy）赢得更具查询性的选举。
IGMP/MLD-based forwarding does not provide the "upstream loop" detection mechanism described in Section 3. Hence, to avoid the problems caused by an "upstream loop", it MUST be administratively assured that such loops don't exist when deploying IGMP/MLD Proxying.
基于IGMP/MLD的转发不提供第3节中描述的“上游环路”检测机制。因此，为了避免“上游循环”造成的问题，必须在管理上确保在部署IGMP/MLD代理时不存在此类循环。
The IGMP/MLD information presented by the proxy to its upstream routers is the aggregation of all its downstream group membership information. Any access control applied on the group membership protocol at the upstream router cannot be performed on a single subscriber. That is, the access control will apply equally to all the interested hosts reachable via the proxy device.
代理向其上游路由器提供的IGMP/MLD信息是其所有下游组成员信息的集合。在上行路由器的组成员协议上应用的任何访问控制都不能在单个订户上执行。也就是说，访问控制将平等地应用于可通过代理设备访问的所有感兴趣的主机。
The authors would like to thank Erik Nordmark, Dave Thaler, Pekka Savola, Karen Kimball, and others for reviewing the specification and providing their comments.
作者要感谢Erik Nordmark、Dave Thaler、Pekka Savola、Karen Kimball和其他人审查了规范并提供了他们的意见。
[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月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[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月。
[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月。
[SSM] 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.
[SSM]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[MCAST] Deering, S., "Multicast Routing in a Datagram Internetwork", Ph.D. Thesis, Stanford University, December 1991.
[MCAST]Deering，S.，“数据报网络中的多播路由”，博士。论文，斯坦福大学，1991年12月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
Authors' Addresses
作者地址
Bill Fenner AT&T Labs - Research 1 River Oaks Place San Jose, CA 95134
比尔·芬纳AT&T实验室-加利福尼亚州圣何塞河橡树广场研究1号，邮编95134
Phone: +1 408 493-8505
EMail: fenner@research.att.com
Phone: +1 408 493-8505
EMail: fenner@research.att.com
Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01821
马萨诸塞州比勒里卡市海翔河北电600科技园大道01821号
EMail: haixiang@nortel.com
EMail: haixiang@nortel.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
Hal Sandick Little River Elementary School 2315 Snow Hill Road Durham, NC 27712
北卡罗来纳州达勒姆雪山路2315号哈尔桑迪克小河小学，邮编：27712
EMail: sandick@nc.rr.com
EMail: sandick@nc.rr.com
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）提供。