Network Working Group B. Haberman
Request for Comments: 4286 JHU APL
Category: Standards Track J. Martin
Netzwert AG
December 2005
Network Working Group B. Haberman
Request for Comments: 4286 JHU APL
Category: Standards Track J. Martin
Netzwert AG
December 2005
Multicast Router Discovery
多播路由器发现
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
Internet组管理协议（IGMP）和多播侦听器发现（MLD）窥探的概念要求能够识别多播路由器的位置。由于窥探不是标准化的，因此有许多机制用于识别多播路由器。然而，这可能导致多播路由器和来自不同供应商的窥探交换机之间的互操作性问题。
This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.
本文档介绍了一种允许发现多播路由器的通用机制。这种新的机制，多播路由器发现（MRD），引入了一种标准化的方法来识别多播路由器，而不依赖于特定的多播路由协议。
Table of Contents
目录
1. Introduction ....................................................3
2. Protocol Overview ...............................................3
3. Multicast Router Advertisement ..................................4
3.1. Advertisement Configuration Variables ......................4
3.1.1. AdvertisementInterval ...............................5
3.1.2. AdvertisementJitter .................................5
3.1.3. MaxInitialAdvertisementInterval .....................5
3.1.4. MaxInitialAdvertisements ............................5
3.1.5. NeighborDeadInterval ................................5
3.1.6. MaxMessageRate ......................................6
3.2. Advertisement Packet Format ................................6
3.2.1. Type Field ..........................................6
3.2.2. Advertisement Interval Field ........................6
3.2.3. Checksum Field ......................................6
3.2.4. Query Interval Field ................................7
3.2.5. Robustness Variable Field ...........................7
3.3. IP Header Fields ...........................................7
3.3.1. Source Address ......................................7
3.3.2. Destination Address .................................7
3.3.3. Time-to-Live / Hop Limit ............................7
3.3.4. IPv4 Protocol .......................................7
3.3.5. IPv6 Next Header ....................................7
3.4. Sending Multicast Router Advertisements ....................8
3.5. Receiving Multicast Router Advertisements ..................8
4. Multicast Router Solicitation ...................................9
4.1. Solicitation Packet Format .................................9
4.1.1. Type Field ..........................................9
4.1.2. Reserved Field ......................................9
4.1.3. Checksum Field ......................................9
4.2. IP Header Fields ..........................................10
4.2.1. Source Address .....................................10
4.2.2. Destination Address ................................10
4.2.3. Time-to-Live / Hop Limit ...........................10
4.2.4. IPv4 Protocol ......................................10
4.2.5. IPv6 Next Header ...................................10
4.3. Sending Multicast Router Solicitations ....................10
4.4. Receiving Multicast Router Solicitations ..................10
5. Multicast Router Termination ...................................11
5.1. Termination Packet Format .................................11
5.1.1. Type Field .........................................11
5.1.2. Reserved Field .....................................11
5.1.3. Checksum Field .....................................11
5.2. IP Header Fields ..........................................12
5.2.1. Source Address .....................................12
5.2.2. Destination Address ................................12
5.2.3. Time-to-Live / Hop Limit ...........................12
1. Introduction ....................................................3
2. Protocol Overview ...............................................3
3. Multicast Router Advertisement ..................................4
3.1. Advertisement Configuration Variables ......................4
3.1.1. AdvertisementInterval ...............................5
3.1.2. AdvertisementJitter .................................5
3.1.3. MaxInitialAdvertisementInterval .....................5
3.1.4. MaxInitialAdvertisements ............................5
3.1.5. NeighborDeadInterval ................................5
3.1.6. MaxMessageRate ......................................6
3.2. Advertisement Packet Format ................................6
3.2.1. Type Field ..........................................6
3.2.2. Advertisement Interval Field ........................6
3.2.3. Checksum Field ......................................6
3.2.4. Query Interval Field ................................7
3.2.5. Robustness Variable Field ...........................7
3.3. IP Header Fields ...........................................7
3.3.1. Source Address ......................................7
3.3.2. Destination Address .................................7
3.3.3. Time-to-Live / Hop Limit ............................7
3.3.4. IPv4 Protocol .......................................7
3.3.5. IPv6 Next Header ....................................7
3.4. Sending Multicast Router Advertisements ....................8
3.5. Receiving Multicast Router Advertisements ..................8
4. Multicast Router Solicitation ...................................9
4.1. Solicitation Packet Format .................................9
4.1.1. Type Field ..........................................9
4.1.2. Reserved Field ......................................9
4.1.3. Checksum Field ......................................9
4.2. IP Header Fields ..........................................10
4.2.1. Source Address .....................................10
4.2.2. Destination Address ................................10
4.2.3. Time-to-Live / Hop Limit ...........................10
4.2.4. IPv4 Protocol ......................................10
4.2.5. IPv6 Next Header ...................................10
4.3. Sending Multicast Router Solicitations ....................10
4.4. Receiving Multicast Router Solicitations ..................10
5. Multicast Router Termination ...................................11
5.1. Termination Packet Format .................................11
5.1.1. Type Field .........................................11
5.1.2. Reserved Field .....................................11
5.1.3. Checksum Field .....................................11
5.2. IP Header Fields ..........................................12
5.2.1. Source Address .....................................12
5.2.2. Destination Address ................................12
5.2.3. Time-to-Live / Hop Limit ...........................12
5.2.4. IPv4 Protocol ......................................12
5.2.5. IPv6 Next Header ...................................12
5.3. Sending Multicast Router Terminations .....................12
5.4. Receiving Multicast Router Terminations ...................12
6. Protocol Constants .............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
5.2.4. IPv4 Protocol ......................................12
5.2.5. IPv6 Next Header ...................................12
5.3. Sending Multicast Router Terminations .....................12
5.4. Receiving Multicast Router Terminations ...................12
6. Protocol Constants .............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
Multicast Router Discovery (MRD) messages are useful for determining which nodes attached to a switch have multicast routing enabled. This capability is useful in a layer-2 bridging domain with snooping switches. By utilizing MRD messages, layer-2 switches can determine where to send multicast source data and group membership messages [1] [2]. Multicast source data and group membership reports must be received by all multicast routers on a segment. Using the group membership protocol Query messages to discover multicast routers is insufficient due to query suppression.
多播路由器发现（MRD）消息可用于确定连接到交换机的哪些节点启用了多播路由。此功能在具有监听交换机的第2层桥接域中非常有用。通过利用MRD消息，第2层交换机可以确定向何处发送多播源数据和组成员身份消息[1][2]。多播源数据和组成员报告必须由一个网段上的所有多播路由器接收。由于查询抑制，使用组成员协议查询消息来发现多播路由器是不够的。
Although MRD messages could be sent as ICMP messages, the group management protocols were chosen since this functionality is multicast specific. The addition of this functionality to the group membership protocol also allows operators to have congruence between MRD problems and data forwarding issues.
尽管MRD消息可以作为ICMP消息发送，但选择了组管理协议，因为此功能是特定于多播的。将此功能添加到组成员协议中还允许操作员在MRD问题和数据转发问题之间保持一致。
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 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[3]中所述进行解释。
Multicast Router Discovery consists of three messages for discovering multicast routers. The Multicast Router Advertisement is sent by routers to advertise that IP multicast forwarding is enabled. Devices may send Multicast Router Solicitation messages in order to solicit Advertisement messages from multicast routers. The Multicast Router Termination messages are sent when a router stops IP multicast routing functions on an interface.
多播路由器发现由三条用于发现多播路由器的消息组成。多播路由器播发由路由器发送，以播发已启用IP多播转发。设备可以发送多播路由器请求消息以便从多播路由器请求广告消息。当路由器停止接口上的IP多播路由功能时，发送多播路由器终止消息。
Multicast routers send unsolicited Advertisements periodically on all interfaces on which multicast forwarding is enabled. Advertisement messages are also sent in response to Solicitations. In addition to advertising the location of multicast routers, Advertisements also
多播路由器在启用多播转发的所有接口上定期发送未经请求的广告。广告信息也被发送以响应请求。除了广告多播路由器的位置外，广告还包括
convey useful information concerning group management protocol variables. This information can be used for consistency checking on the subnet.
传达有关组管理协议变量的有用信息。此信息可用于子网上的一致性检查。
A device sends Solicitation messages whenever it wishes to discover multicast routers on a directly attached link.
当设备希望在直接连接的链路上发现多播路由器时，就会发送请求消息。
A router sends Termination messages when it terminates multicast routing functionality on an interface.
路由器在终止接口上的多播路由功能时发送终止消息。
All MRD messages are sent with an IPv4 Time to Live (TTL) or IPv6 Hop Limit of 1 and contain the Router Alert Option [4] [5]. All MRD messages SHOULD be rate-limited as per the MaxMessageRate variable.
发送所有MRD消息时，IPv4生存时间（TTL）或IPv6跃点限制为1，并且包含路由器警报选项[4][5]。所有MRD消息应根据MaxMessageRate变量进行速率限制。
Advertisement and Termination messages are sent to the All-Snoopers multicast address.
播发和终止消息被发送到所有窥探者的多播地址。
Solicitation messages are sent to the All-Routers multicast address.
请求消息被发送到所有路由器的多播地址。
Any data beyond the fixed message format MUST be ignored.
任何超出固定消息格式的数据都必须忽略。
Multicast Router Advertisements are sent unsolicited periodically on all router interfaces on which multicast forwarding is enabled. They are also sent in response to Multicast Router Solicitation messages.
在启用多播转发的所有路由器接口上，多播路由器播发会定期主动发送。它们也被发送以响应多播路由器请求消息。
Advertisements are sent
发送广告
1. Upon the expiration of a periodic (modulo randomization) timer
1. 周期（模随机）计时器到期时
2. As part of a router's start-up procedure
2. 作为路由器启动程序的一部分
3. During the restart of a multicast forwarding interface
3. 在重新启动多播转发接口期间
4. On receipt of a Solicitation message
4. 在收到邀请函时
All Advertisements are sent as Internet Group Management Protocol (for IPv4) or Multicast Listener Discovery (for IPv6) messages to the All-Snoopers multicast address. These messages SHOULD be rate-limited as per the MaxMessageRate variable.
所有播发都作为Internet组管理协议（对于IPv4）或多播侦听器发现（对于IPv6）消息发送到所有侦听器多播地址。这些消息应根据MaxMessageRate变量进行速率限制。
An MRD implementation MUST support the following variables being configured by system management. Default values are specified to make it unnecessary to configure any of these variables in many cases.
MRD实施必须支持系统管理配置的以下变量。指定默认值是为了在许多情况下不必配置这些变量中的任何一个。
This variable is the base interval (in integer seconds) between the transmissions of unsolicited Advertisements on an interface. This value MUST be no less than 4 seconds and no greater than 180 seconds.
此变量是接口上未经请求的广告传输之间的基本间隔（以整数秒为单位）。该值必须不小于4秒且不大于180秒。
Default: 20 seconds
默认值：20秒
This is the maximum time (in seconds) by which the AdvertisementInterval is perturbed for each unsolicited Advertisement. Note that the purpose of this jitter is to avoid synchronization of multiple routers on a network, hence choosing a value of zero is discouraged. This value MUST be an integer no less than 0 seconds and no greater than AdvertisementInterval.
这是每个未经请求的广告干扰AdvertisementInterval的最长时间（秒）。请注意，此抖动的目的是避免网络上多个路由器的同步，因此不建议选择零值。此值必须是不小于0秒且不大于AdvertisementInterval的整数。
The AdvertisementJitter MUST be 0.025*AdvertisementInterval
AdvertisementJitter必须为0.025*AdvertisementInterval
The first unsolicited Advertisement transmitted on an interface is sent after waiting a random interval (in seconds) less than this variable. This prevents a flood of Advertisements when multiple routers start up at the same time.
在接口上传输的第一个未经请求的广告在等待小于此变量的随机间隔（秒）后发送。这可以防止多个路由器同时启动时出现大量广告。
Default: 2 seconds
默认值：2秒
This variable is the maximum number of unsolicited Advertisements that will be transmitted by the advertising interface when MRD starts up.
此变量是MRD启动时广告接口将传输的未经请求的广告的最大数量。
Default: 3
默认值：3
The NeighborDeadInterval variable is the maximum time (in seconds) allowed to elapse (after receipt of the last valid Advertisement) before a neighboring router is declared unreachable. This variable is maintained per neighbor. An MRD receiver should set the NeighborDeadInterval to 3 times the sum of Advertisement Interval Field received plus the AdvertisementJitter calculated from the received Advertisement Interval Field. This ensures consistent behavior between multiple devices on a network.
NeighborDedinterval变量是在宣布相邻路由器不可访问之前（在接收到最后一个有效播发后）允许经过的最长时间（以秒为单位）。此变量按邻居维护。MRD接收器应将NeighborDedInterval设置为接收到的广告间隔字段加上从接收到的广告间隔字段计算出的AdvertisementJitter之和的3倍。这确保了网络上多个设备之间的行为一致。
Default : 3 * (Advertisement Interval Field + calculated AdvertisementJitter)
默认值：3*（广告间隔字段+计算的广告抖动）
The MaxMessageRate variable is the maximum aggregate number of messages an MRD implementation SHOULD send (per second) per interface or per management or logging destination.
MaxMessageRate变量是MRD实现在每个接口或每个管理或日志目的地（每秒）应发送的最大消息总数。
Default: 10
默认值：10
The Advertisement message has the following format:
广告信息的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Ad. Interval | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Interval | Robustness Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Ad. Interval | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Interval | Robustness Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field identifies the message as an Advertisement. It is set to 0x30 for IPv4 and 151 for IPv6.
类型字段将消息标识为广告。IPv4设置为0x30，IPv6设置为151。
This field specifies the periodic time interval at which unsolicited Advertisement messages are transmitted in units of seconds. This value is set to the configured AdvertisementInterval.
此字段指定以秒为单位传输未经请求的广告消息的周期时间间隔。此值设置为配置的AdvertisementInterval。
The checksum field is set as follows:
校验和字段设置如下：
1. For IPv4 it is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the Type field. For computing the checksum, the checksum field is set to 0.
1. 对于IPv4，它是IGMP消息的补码和的16位补码，从类型字段开始。为了计算校验和，校验和字段设置为0。
2. For IPv6 it is ICMPv6 checksum as specified in [6].
2. 对于IPv6，它是[6]中指定的ICMPv6校验和。
The Query Interval field is set to the Query Interval value (in seconds) in use by IGMP or MLD on the interface. If IGMP or MLD is not enabled on the advertising interface, this field MUST be set to 0. Note that this is the Querier's Query Interval (QQI), not the Querier's Query Interval Code (QQIC) as specified in the IGMP/MLD specifications.
查询间隔字段设置为接口上IGMP或MLD使用的查询间隔值（以秒为单位）。如果在广告界面上未启用IGMP或MLD，则此字段必须设置为0。请注意，这是查询器的查询间隔（QQI），而不是IGMP/MLD规范中指定的查询器查询间隔代码（QQIC）。
This field is set to the Robustness Variable in use by IGMPv2 [2], IGMPv3 [7], or MLD [8] [9] on the advertising interface. If IGMPv1 is in use or no group management protocol is enabled on the interface, this field MUST be set to 0.
此字段设置为广告界面上IGMPv2[2]、IGMPv3[7]或MLD[8][9]使用的稳健性变量。如果IGMPv1正在使用中或接口上未启用组管理协议，则此字段必须设置为0。
The IP source address is set to an IP address configured on the advertising interface. For IPv6, a link-local address MUST be used.
IP源地址设置为广告界面上配置的IP地址。对于IPv6，必须使用链路本地地址。
The IP destination address is set to the All-Snoopers multicast address.
IP目标地址设置为所有侦听器多播地址。
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTL和IPv6跃点限制设置为1。
The IPv4 Protocol field is set to IGMP (2).
IPv4协议字段设置为IGMP（2）。
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPv6标头由前一个标头中的下一个标头值58标识[6]。
Advertisement messages are sent when the following events occur:
出现以下事件时，将发送广告消息：
1. The expiration of the periodic advertisement interval timer. Note that this timer is not strictly periodic since the base AdvertisementInterval is varied at each interval by a random value no more than plus or minus AdvertisementJitter seconds.
1. 定期播发间隔计时器的过期时间。请注意，此计时器不是严格的周期性计时器，因为基本AdvertisementInterval在每个间隔上的变化随机值不超过正负AdvertisementJitter秒。
2. After a random delay less than MaxInitialAdvertisementInterval when an interface is first enabled, is (re-)initialized, or MRD is enabled. A router may send up to a maximum of MaxInitialAdvertisements Advertisements, waiting for a random delay less than MaxInitialAdvertisementInterval between each successive message. Multiple Advertisements are sent for robustness in the face of packet loss on the network.
2. 在第一次启用接口、重新初始化接口或启用MRD时，随机延迟小于MaxInitialAdvertisementInterval。路由器最多可发送MaxInitialAdvertisions广告，等待每个连续消息之间小于MaxInitialAdvertisiementInterval的随机延迟。为了在网络上面临数据包丢失时保持健壮性，发送了多个广告。
This is to prevent an implosion of Advertisements. An example of this occurring would be when many routers are powered on at the same time. When a Solicitation is received, an Advertisement is sent in response with a random delay less than MAX_RESPONSE_DELAY. If a Solicitation is received while an Advertisement is pending, that Solicitation MUST be ignored.
这是为了防止广告内爆。发生这种情况的一个例子是，许多路由器同时通电。当收到请求时，发送广告作为响应，其随机延迟小于MAX_response_delay。如果在广告悬而未决时收到了邀约，则必须忽略该邀约。
Changes in the Query Interval or Robustness Variable MUST NOT trigger a new Advertisement; however, the new values MUST be used in all future Advertisement messages.
查询间隔或稳健性变量的更改不得触发新的播发；但是，新值必须在将来的所有广告消息中使用。
When an Advertisement is sent, the periodic advertisement interval timer MUST be reset.
发送广告时，必须重置定期广告间隔计时器。
Upon receiving an Advertisement message, devices validate the message with the following criteria:
接收到广告消息后，设备根据以下标准验证消息：
1. The checksum is correct
1. 校验和是正确的
2. The IP destination address is equal to the All-Snoopers multicast address
2. IP目标地址等于所有窥探者的多播地址
3. For IPv6, the IP source address is a link-local address
3. 对于IPv6，IP源地址是链路本地地址
An Advertisement not meeting the validity requirements MUST be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
不符合有效性要求的广告必须以静默方式丢弃，并且可以按照MaxMessageRate变量以速率限制的方式记录。
If an Advertisement is not received for a particular neighbor within a NeighborDeadInterval time interval, then the neighbor is considered unreachable.
如果在NeightradInterval时间间隔内未接收到特定邻居的播发，则认为该邻居无法访问。
Multicast Router Solicitation messages are used to solicit Advertisements from multicast routers on a segment. These messages are used when a device wishes to discover multicast routers. Upon receiving a solicitation on an interface with IP multicast forwarding and MRD enabled, a router will respond with an Advertisement.
多播路由器请求消息用于从段上的多播路由器请求广告。当设备希望发现多播路由器时，使用这些消息。当在启用了IP多播转发和MRD的接口上接收到请求时，路由器将用广告进行响应。
Solicitations may be sent when these occur:
在下列情况下，可发送征集：
1. An interface is (re-)initialized
1. 接口已（重新）初始化
2. MRD is enabled
2. MRD已启用
Solicitations are sent to the All-Routers multicast address and SHOULD be rate-limited, as per the MaxMessageRate variable.
请求被发送到所有路由器的多播地址，并且应根据MaxMessageRate变量进行速率限制。
The Solicitation message has the following format:
邀请函的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field identifies the message as a Solicitation. It is set to 0x31 for IPv4 and 152 for IPv6.
类型字段将消息标识为请求。IPv4设置为0x31，IPv6设置为152。
The Reserved field is set to 0 on transmission and ignored on reception.
传输时保留字段设置为0，接收时忽略。
The checksum field is set as follows:
校验和字段设置如下：
o For IPv4 it is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the Type field. For computing the checksum, the checksum field is set to 0.
o 对于IPv4，它是IGMP消息的补码和的16位补码，从类型字段开始。为了计算校验和，校验和字段设置为0。
o For IPv6 it is ICMPv6 checksum as specified in [6].
o 对于IPv6，它是[6]中指定的ICMPv6校验和。
The IP source address is set to an IP address configured on the soliciting interface. For IPv6, a link-local address MUST be used.
IP源地址设置为请求接口上配置的IP地址。对于IPv6，必须使用链路本地地址。
The IP destination address is set to the All-Routers multicast address.
IP目标地址设置为所有路由器多播地址。
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTL和IPv6跃点限制设置为1。
The IPv4 Protocol field is set to IGMP (2).
IPv4协议字段设置为IGMP（2）。
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPv6标头由前一个标头中的下一个标头值58标识[6]。
Solicitation messages are sent when the following events occur:
在发生以下事件时发送请求消息：
o After waiting for a random delay less than MAX_SOLICITATION_DELAY when an interface first becomes operational, is (re-)initialized, or MRD is enabled. A device may send up to a maximum of MAX_SOLICITATIONS, waiting for a random delay less than MAX_SOLICITATION_DELAY between each solicitation.
o 等待随机延迟小于接口第一次运行时的最大请求延迟后，（重新）初始化或启用MRD。设备最多可发送MAX_请求，在每次请求之间等待小于MAX_请求延迟的随机延迟。
o Optionally, for an implementation specific event.
o （可选）对于特定于实现的事件。
Solicitations MUST be rate-limited as per the MaxMessageRate variable; the implementation MUST send no more than MAX_SOLICITATIONS in MAX_SOLICITATION_DELAY seconds.
请求必须根据MaxMessageRate变量进行费率限制；实现必须在最大请求延迟秒内发送不超过最大请求。
A Solicitation message MUST be validated before a response is sent. A router MUST verify the following:
在发送响应之前，必须验证请求消息。路由器必须验证以下各项：
o The checksum is correct.
o 校验和是正确的。
o The IP destination address is the All-Routers multicast address.
o IP目标地址是所有路由器的多播地址。
o For IPv6, the IP source address MUST be a link-local address.
o 对于IPv6，IP源地址必须是链路本地地址。
Solicitations not meeting the validity requirements SHOULD be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
不符合有效性要求的请求应自动放弃，并可根据MaxMessageRate变量以速率限制的方式记录。
The Multicast Router Termination message is used to expedite the notification of a change in the status of a router's multicast forwarding functions. Multicast routers send Terminations when multicast forwarding is disabled on the advertising interface.
多播路由器终止消息用于加快路由器多播转发功能状态变化的通知。当广告接口上禁用多播转发时，多播路由器发送终止。
The Termination message has the following format:
终止消息的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field identifies the message as a Termination. It is set to 0x32 for IPv4 and 153 for IPv6.
类型字段将消息标识为终止。IPv4设置为0x32，IPv6设置为153。
The Reserved field is set to 0 on transmission and ignored on reception.
传输时保留字段设置为0，接收时忽略。
The checksum field is set as follows:
校验和字段设置如下：
o For IPv4 it is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the Type field. For computing the checksum, the checksum field is set to 0.
o 对于IPv4，它是IGMP消息的补码和的16位补码，从类型字段开始。为了计算校验和，校验和字段设置为0。
o For IPv6 it is ICMPv6 checksum as specified in [6].
o 对于IPv6，它是[6]中指定的ICMPv6校验和。
The IP source address is set to an IP address configured on the advertising interface. For IPv6, a link-local address MUST be used.
IP源地址设置为广告界面上配置的IP地址。对于IPv6，必须使用链路本地地址。
The IP destination address is set to the All-Snoopers multicast address.
IP目标地址设置为所有侦听器多播地址。
The IPv4 TTL and IPv6 Hop Limit are set to 1.
IPv4 TTL和IPv6跃点限制设置为1。
The IPv4 Protocol field is set to IGMP (2).
IPv4协议字段设置为IGMP（2）。
The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header [6].
ICMPv6标头由前一个标头中的下一个标头值58标识[6]。
Termination messages are sent by multicast routers when
终止消息由多播路由器在以下情况下发送：
o Multicast forwarding is disabled on an interface
o 在接口上禁用了多播转发
o An interface is administratively disabled
o 接口已被管理禁用
o The router is gracefully shut down
o 路由器正常关闭
o MRD is disabled
o MRD已禁用
The sending of Termination messages SHOULD be rate-limited as per the MaxMessageRate variable.
终止消息的发送应根据MaxMessageRate变量进行速率限制。
Upon receiving a Termination message, devices validate the message. The validation criteria are the following:
接收到终止消息后，设备验证消息。验证标准如下：
o Checksum MUST be correct.
o 校验和必须正确。
o IP destination address MUST equal the All-Snoopers multicast address.
o IP目标地址必须等于所有窥探者的多播地址。
o For IPv6, the IP source address MUST be a link-local address.
o 对于IPv6，IP源地址必须是链路本地地址。
Termination messages not meeting the validity requirements MUST be silently discarded and may be logged in a rate-limited manner as per the MaxMessageRate variable.
不符合有效性要求的终止消息必须以静默方式丢弃，并且可以按照MaxMessageRate变量以速率限制的方式记录。
If the message passes these validation steps, a Solicitation is sent. If an Advertisement is not received within NeighborDeadInterval, the sending router is removed from the list of active multicast routers.
如果消息通过了这些验证步骤，则发送请求。如果在NeightradInterval内未接收到播发，则发送路由器将从活动多播路由器列表中删除。
The following list identifies constants used in the MRD protocol. These constants are used in the calculation of parameters.
下表列出了MRD协议中使用的常数。这些常数用于计算参数。
o MAX_RESPONSE_DELAY 2 seconds
o 最大响应延迟2秒
o MAX_SOLICITATION_DELAY 1 second
o 最大请求延迟1秒
o MAX_SOLICITATIONS 3 transmissions
o 最多邀请3次传输
As MRD is a link-local protocol, there is no circumstance in which it would be correct for an MRD receiver to receive MRD traffic from an off-network source. For IPv6, MRD messages MUST have a valid link-local source address. Any messages received without a valid link-local source address MUST be discarded. Similarly, for IPv4, the MRD receiver MUST determine if the source address is local to the receiving interface, and MUST discard any messages that have a non-local source. Determining what networks are local may be accomplished through configuration information or operational capabilities.
由于MRD是一种链路本地协议，因此MRD接收器从非网络源接收MRD流量是不正确的。对于IPv6，MRD消息必须具有有效的链接本地源地址。必须丢弃接收到的没有有效链接本地源地址的任何消息。类似地，对于IPv4，MRD接收器必须确定源地址是否是接收接口的本地地址，并且必须丢弃任何具有非本地源的消息。可以通过配置信息或操作能力来确定哪些网络是本地的。
Rogue nodes may attempt to attack a network running MRD by sending spoofed Advertisement, Solicitation, or Termination messages. Each type of spoofed message can be dealt with using existing technology.
流氓节点可能试图通过发送虚假广告、请求或终止消息来攻击运行MRD的网络。每种类型的欺骗消息都可以使用现有技术处理。
A rogue node may attempt to interrupt multicast service by sending spoofed Termination messages. As described in Section 5.4, all Termination messages are validated by sending a Solicitation message. By sending a Solicitation, the node will force the transmission of an Advertisement by an active router.
恶意节点可能试图通过发送伪造的终止消息来中断多播服务。如第5.4节所述，通过发送请求消息验证所有终止消息。通过发送请求，节点将强制活动路由器传输广告。
Spoofed Solicitation messages do not cause any operational harm. They may be used as a flooding mechanism to attack a multicast router. This attack can be mitigated through the rate-limiting recommendation for all MRD messages.
伪造的请求消息不会造成任何操作伤害。它们可用作攻击多播路由器的洪泛机制。可以通过对所有MRD消息的速率限制建议来缓解此攻击。
The Multicast Router Advertisement message may allow rogue machines to masquerade as multicast routers. This could allow those machines to eavesdrop on multicast data transmissions. Additionally, it could constitute a denial of service attack to other hosts in the same snooping domain or sharing the same device port in the presence of high-rate multicast flows.
多播路由器广告消息可允许流氓机器伪装成多播路由器。这可能允许这些机器窃听多播数据传输。此外，它还可能构成对同一窥探域中的其他主机的拒绝服务攻击，或在存在高速多播流的情况下共享同一设备端口。
The technology available in SEND [10] can be utilized to address spoofed Advertisement messages in IPv6 networks. IPv6 Multicast routers in an MRD-enabled network can use SEND-based link-local addresses as the IPv6 source address for MRD messages. When a switch receives an initial Advertisement, it can use the information in the SEND-based address to challenge the router to authenticate itself. It should be noted that this approach only applies to IPv6 networks.
SEND[10]中提供的技术可用于处理IPv6网络中的伪造广告消息。启用MRD的网络中的IPv6多播路由器可以使用基于发送的链路本地地址作为MRD消息的IPv6源地址。当交换机接收到初始广告时，它可以使用基于发送的地址中的信息来质询路由器进行自身身份验证。应该注意的是，这种方法仅适用于IPv6网络。
Another solution that supports both IPv4 and IPv6 is to use IPsec in Encapsulating Security Payload (ESP) mode [11] to protect against attacks by ensuring that messages came from a system with the proper key. When using IPsec, the messages sent to the All-Snoopers address should be authenticated using ESP. Should encryption not be desired, ESP with a null encryption algorithm and a symmetric authentication algorithm, such as HMAC-SHA-1, is viable. For keying, a symmetric signature algorithm with a single manually configured key is used for routers sending Advertisements. This allows validation that the MRD message was sent by a system with the key. It should be noted that this does not prevent a system with the key from forging a message and it requires the disabling of IPsec's Replay Protection. It is the responsibility of the network administrator to ensure that the same key is present on all possible MRD participants.
另一个同时支持IPv4和IPv6的解决方案是在封装安全有效负载（ESP）模式[11]中使用IPsec，通过确保消息来自具有正确密钥的系统来防止攻击。使用IPsec时，发送到所有窥探者地址的消息应使用ESP进行身份验证。如果不需要加密，则使用空加密算法和对称身份验证算法（如HMAC-SHA-1）的ESP是可行的。对于键控，路由器发送广告时使用带有单个手动配置密钥的对称签名算法。这允许验证MRD消息是否由具有密钥的系统发送。应该注意的是，这并不能阻止具有密钥的系统伪造消息，并且需要禁用IPsec的重播保护。网络管理员有责任确保所有可能的MRD参与者都有相同的密钥。
This document introduces three new IGMP messages. Each of these messages requires a new IGMP Type value. The IANA has assigned three new IGMP Type values to the Multicast Router Discovery Protocol:
本文档介绍了三条新的IGMP消息。每个消息都需要一个新的IGMP类型值。IANA为多播路由器发现协议分配了三个新的IGMP类型值：
+-----------+-----------------+--------------------------------+
| IGMP Type | Section | Message Name |
+-----------+-----------------+--------------------------------+
| 0x30 | Section 3.2.1 | Multicast Router Advertisement |
| 0x31 | Section 4.1.1 | Multicast Router Solicitation |
| 0x32 | Section 5.1.1 | Multicast Router Termination |
+-----------+-----------------+--------------------------------+
+-----------+-----------------+--------------------------------+
| IGMP Type | Section | Message Name |
+-----------+-----------------+--------------------------------+
| 0x30 | Section 3.2.1 | Multicast Router Advertisement |
| 0x31 | Section 4.1.1 | Multicast Router Solicitation |
| 0x32 | Section 5.1.1 | Multicast Router Termination |
+-----------+-----------------+--------------------------------+
This document also introduces three new MLD messages. Each of these messages requires a new ICMPv6 Type value. The IANA has assigned three new ICMPv6 Type values from the Informational range:
本文档还介绍了三条新的MLD消息。每个消息都需要一个新的ICMPv6类型值。IANA从信息范围中分配了三个新的ICMPv6类型值：
+-------------+-----------------+--------------------------------+
| ICMPv6 Type | Section | Message Name |
+-------------+-----------------+--------------------------------+
| 151 | Section 3.2.1 | Multicast Router Advertisement |
| 152 | Section 4.1.1 | Multicast Router Solicitation |
| 153 | Section 5.1.1 | Multicast Router Termination |
+-------------+-----------------+--------------------------------+
+-------------+-----------------+--------------------------------+
| ICMPv6 Type | Section | Message Name |
+-------------+-----------------+--------------------------------+
| 151 | Section 3.2.1 | Multicast Router Advertisement |
| 152 | Section 4.1.1 | Multicast Router Solicitation |
| 153 | Section 5.1.1 | Multicast Router Termination |
+-------------+-----------------+--------------------------------+
This document also requires the assignment of an All-Snoopers multicast address for IPv4. This multicast address is in the 224.0.0/24 range since it is used for link-local, control messages. The IPv4 multicast address for All-Snoopers is 224.0.0.106.
本文档还要求为IPv4分配所有侦听器多播地址。此多播地址位于224.0.0/24范围内，因为它用于链路本地控制消息。所有窥探者的IPv4多播地址为224.0.0.106。
A corresponding IPv6 multicast address has also been assigned. Following the guidelines in [12], the IPv6 multicast address is a link-local in scope and has a group-ID value equal to the low-order 8 bits of the requested IPv4 multicast address. The IPv6 multicast address is FF02:0:0:0:0:0:0:6A.
还分配了相应的IPv6多播地址。按照[12]中的指导原则，IPv6多播地址是作用域中的本地链路，其组ID值等于请求的IPv4多播地址的低位8位。IPv6多播地址是FF02:0:0:0:0:0:0:0:6A。
Brad Cain and Shantam Biswis are the authors of the original Multicast Router Discovery proposal.
Brad Cain和Shantam Biswis是最初的多播路由器发现方案的作者。
ICMP Router Discovery [13] was used as a general model for Multicast Router Discovery.
ICMP路由器发现[13]被用作多播路由器发现的通用模型。
Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas provided helpful feedback on various versions of this document.
Morten Christensen、Pekka Savola、Hugh Holbrook和Isidor Kouvelas就本文件的不同版本提供了有用的反馈。
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[4] Katz，D.，“IP路由器警报选项”，RFC 2113，1997年2月。
[5] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[5] 帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[6] Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[7] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[7] Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[8] Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[9] Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC3810，2004年6月。
[10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[10] Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[11] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[12] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[12] Haberman，B.，“IPv6多播地址分配指南”，RFC33072002年8月。
[13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[13] Deering，S.，“ICMP路由器发现消息”，RFC 1256，1991年9月。
Authors' Addresses
作者地址
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
布莱恩·哈伯曼·约翰·霍普金斯大学应用物理实验室美国马里兰州劳雷尔市约翰·霍普金斯路11100号20723-6099
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Jim Martin Netzwert AG An den Treptowers 1 D-12435 Berlin Germany
德国柏林吉姆马丁·内茨韦特股份有限公司
Phone: +49.30/5 900 80-1180
EMail: jim@netzwert.ag
Phone: +49.30/5 900 80-1180
EMail: jim@netzwert.ag
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。