Network Working Group B. Haberman
Request for Comments: 3590 Caspian Networks
Updates: 2710 September 2003
Category: Standards Track
Network Working Group B. Haberman
Request for Comments: 3590 Caspian Networks
Updates: 2710 September 2003
Category: Standards Track
Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
多播侦听器发现（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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages.
当节点执行无状态地址自动配置时，为多播侦听器发现（MLD）消息选择合适的IPv6源地址存在问题。本文档旨在阐明选择用于MLD消息的IPv6地址的规则。
The original specification of the Multicast Listener Discovery Protocol (MLD) for IPv6 [RFC 2710] mandates the use of a link-local IPv6 source address for the transmission of MLD messages. In addition, MLD also requires nodes to send MLD Report messages when joining any IPv6 multicast group (except the All-Nodes address and addresses of scope less than 2).
IPv6多播侦听器发现协议（MLD）[RFC 2710]的原始规范要求使用链路本地IPv6源地址传输MLD消息。此外，MLD还要求节点在加入任何IPv6多播组时发送MLD报告消息（所有节点地址和作用域小于2的地址除外）。
These MLD requirements conflict with the use of IPv6 multicast within the Neighbor Discovery Protocol [RFC 2461]. For stateless autoconfiguration, as defined in [RFC 2462], a node is required to join several IPv6 multicast groups in order to perform Duplicate Address Detection prior to its use. Since the only address the node has is tentative, and cannot be used for communication, it does not have a suitable address to utilize as a source address.
这些MLD要求与邻居发现协议[RFC 2461]中IPv6多播的使用相冲突。对于[RFC 2462]中定义的无状态自动配置，节点需要加入多个IPv6多播组，以便在使用前执行重复地址检测。由于节点的唯一地址是暂定的，不能用于通信，因此它没有合适的地址用作源地址。
This document will clarify the IPv6 source address selection rules for use with MLD when no link-local addresses are available.
本文档将阐明在没有可用链路本地地址时用于MLD的IPv6源地址选择规则。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
In [RFC 2710], Section 3 requires that all MLD messages be sent with a valid link-local IPv6 source address. However, a node in the process of performing duplicate address detection for its link-local (LL) address will not have one available to use as a source address. For this reason, this document allows the unspecified address to be used as a source address for MLD messages being used during duplicate address detection.
在[RFC 2710]中，第3节要求使用有效的链路本地IPv6源地址发送所有MLD消息。但是，正在对其链路本地（LL）地址执行重复地址检测的节点将没有可用的地址作为源地址。因此，本文档允许将未指定的地址用作重复地址检测期间使用的MLD消息的源地址。
The discrepancies in the rules defined in [RFC 2710] and [RFC 2462] has led to implementation issues. Several IPv6 implementations skip sending MLD Report messages during duplicate address detection because they have no valid link-local address. This leads to operational problems when a node is attached to switches that perform MLD snooping. In this scenario, duplicate address detection (DAD) will complete successfully and collisions can occur once the address is put into use because switches may not have forwarded the DAD messages to all nodes on the link as required. This document fixes this problem by specifying that MLD reports are to be sent using an unspecified source address prior to DAD being started in order to ensure that messages sent to LL multicast addresses (e.g., including MLD) are forwarded to all appropriate nodes as required.
[RFC 2710]和[RFC 2462]中定义的规则的差异导致了实施问题。几个IPv6实现在重复地址检测期间跳过发送MLD报告消息，因为它们没有有效的链路本地地址。当节点连接到执行MLD窥探的交换机时，这会导致操作问题。在这种情况下，重复地址检测（DAD）将成功完成，并且一旦地址投入使用，就会发生冲突，因为交换机可能没有根据需要将DAD消息转发到链路上的所有节点。本文档通过指定在启动DAD之前使用未指定的源地址发送MLD报告来解决此问题，以确保发送到LL多播地址（例如，包括MLD）的消息根据需要转发到所有适当的节点。
An MLD speaking node is required to choose a suitable IPv6 source address for all MLD messages (Report, Done, and Query).
讲MLD的节点需要为所有MLD消息（报告、完成和查询）选择合适的IPv6源地址。
MLD Query messages MUST be sent with a valid link-local address as the IPv6 source address. If a node (router or host) receives a query message with an IPv6 source address set to the unspecified address (::), it MUST silently discard the message and SHOULD log a warning.
MLD查询消息必须以有效的链路本地地址作为IPv6源地址发送。如果节点（路由器或主机）接收到IPv6源地址设置为未指定地址（：：）的查询消息，则必须以静默方式放弃该消息，并应记录警告。
MLD Report and Done messages are sent with a link-local address as the IPv6 source address, if a valid address is available on the interface. If a valid link-local address is not available (e.g., one has not been configured), the message is sent with the unspecified address (::) as the IPv6 source address.
如果接口上有可用的有效地址，则发送MLD报告和完成消息时会使用链接本地地址作为IPv6源地址。如果有效的链路本地地址不可用（例如，尚未配置一个），则发送消息时会使用未指定的地址（：：）作为IPv6源地址。
Once a valid link-local address is available, a node SHOULD generate new MLD Report messages for all multicast addresses joined on the interface.
一旦有效链路本地地址可用，节点应为接口上加入的所有多播地址生成新的MLD报告消息。
Routers receiving an MLD Report or Done message with the unspecified address as the IPv6 source address MUST silently discard the packet without taking any action on the packets contents.
接收MLD报告或完成消息（未指定地址为IPv6源地址）的路由器必须在不对数据包内容采取任何操作的情况下自动丢弃数据包。
Snooping switches MUST manage multicast forwarding state based on MLD Report and Done messages sent with the unspecified address as the IPv6 source address.
窥探交换机必须根据MLD报告和以未指定地址作为IPv6源地址发送的已完成消息管理多播转发状态。
In RFC 2710, MLD Report and Done messages are required to have an IPv6 source address that is link-local. This memo augments that rule by allowing these messages to contain the unspecified address (::) as the source address.
在RFC 2710中，MLD Report和Done消息需要具有链接本地的IPv6源地址。此备忘录通过允许这些邮件包含未指定的地址（：：）作为源地址来扩充该规则。
The behavior of RFC 2710 implementations, when receiving a message with a source address of ::, is dependent upon how the implementation treats the unspecified address. That is, these messages will be dropped if the implementation does not consider the unspecified address to be link-local in scope.
RFC2710实现在接收源地址为：：、的消息时的行为取决于实现如何处理未指定的地址。也就是说，如果实现不将未指定的地址视为范围内的链接本地，则这些消息将被丢弃。
As the unspecified address is only used when there is no link-local address, RFC 2710 implementations discarding these packets will have no affect on the packet's sender as the use should only be for joining the link-local solicited-node multicast group [RFC 2462].
由于未指定的地址仅在没有链路本地地址时使用，因此丢弃这些数据包的RFC 2710实现对数据包的发送方没有影响，因为该使用应仅用于加入链路本地请求节点多播组[RFC 2462]。
There is an implication to senders with respect to joining other multicast groups prior to the activation of a link-local address. The dropping of Reports using the unspecified address as a source address could cause a lack of multicast traffic that is expected by the node. This black hole will be temporary until the node can send a Report with a valid link-local address.
在激活链路本地地址之前加入其他多播组对发送方有影响。删除使用未指定地址作为源地址的报告可能会导致缺少节点预期的多播通信量。这个黑洞将是暂时的，直到节点可以发送带有有效链接本地地址的报告为止。
General security issues related to MLD are discussed in [RFC 2710].
[RFC 2710]中讨论了与MLD相关的一般安全问题。
For hosts and routers, all received MLD messages from an unspecified source address are silently discarded. This is the required behavior from [RFC 2710] and is not changed by this document. Thus, the changes have no new security impacts.
对于主机和路由器，从未指定源地址接收的所有MLD消息都将被静默丢弃。这是[RFC 2710]中要求的行为，本文档未对其进行更改。因此，这些变化没有新的安全影响。
In the case of snooping switches, multicast forwarding state will be maintained based on Report and Done messages sent with the unspecified address as the source address. However, the security vulnerabilities in this scenario are similar to those describing forged messages in the security considerations section of [RFC 2710].
在侦听交换机的情况下，将根据以未指定地址作为源地址发送的报告和完成消息来维护多播转发状态。但是，此场景中的安全漏洞与[RFC 2710]的安全注意事项部分中描述伪造消息的漏洞类似。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC 2710]Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC 2461]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[RFC 2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC 2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
Brian Haberman Caspian Networks 753 Bridgewater Drive Sykesville, MD 21784
马里兰州赛克斯维尔布里奇沃特大道753号布赖恩·哈伯曼里海网络公司，邮编：21784
Phone: +1-410-552-1421
EMail: brian@innovationslab.net
Phone: +1-410-552-1421
EMail: brian@innovationslab.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。